headers
Bonatti, Chris | 4 Feb 2002 20:11

RE: MIXER Impact on CMS-X400


Hi Jim,

  I'm glad to have your input on this.  Some responses are embedded below.

Chris

On Wed, 30 Jan 2002 14:11:36 +0000, Jim Craigie <Jim.Craigie <at> clearswift.com> wrote:
> 
> Chris,
> 
> Sorry that it has taken so long for me to find the time to reply.
> 
> As you note in your message, RFC2156 explicitly limits its 
> scope to the X.420 Interpersonal Messaging System, and 
> "not to wider application of X.400".  Your text for 
> inclusion in the drafts should state this.
> 
> Since RFC2156 does not specify how to gateway X.400 
> content types other than IPMS, it is not sufficient to say 
> "translation must be limited to the envelope fields only " 
> - unless you spell out the detail implementors will not 
> produce consistent behaviour. Your drafts (or an addendum 
> to MIXER) need to state precisely which parts of RFC2156 
> are applicable when gatewaying of the content types 
> defined in x400transport and x400wrap is to be performed.

  I'm becoming convinced of this too.  I guess I imagined that the distinction between envelope handling and
content handling was self-evident enough to not have to connect the dots.  However, if we're going to
explicitly cite MIXER, I guess we need to tighten this down.  Harald Alvestrand has pointed out that the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Housley, Russ | 5 Feb 2002 20:55

53rd IETF Agenda Topics


S/MIME WG:

I am putting together the agenda for the 53rd IETF.  If you would like a 
slot on the S/MIME WG agenda, please send me email.

Russ

P.S. The Draft Agenda fro 53rd IETF is available at 
http://www.ietf.org/meetings/agenda_53.txt
Permalink | Reply | 0 comments |
headers
The IESG | 6 Feb 2002 00:17
Picon
Favicon

Document Action: Use of ECC Algorithms in CMS to Proposed Standard


The IESG has approved the Internet-Draft 'Use of ECC Algorithms in CMS'
<draft-ietf-smime-ecc-06.txt> as an Informational RFC.  This document is
the product of the S/MIME Mail Security Working Group.  The IESG
contact persons are Jeffrey Schiller and Marcus Leech.
Permalink | Reply | 0 comments |
headers
The IESG | 6 Feb 2002 00:31
Picon
Favicon

Document Action: Use of ECC Algorithms in CMS to Informational


The IESG has approved the Internet-Draft 'Use of ECC Algorithms in CMS'
<draft-ietf-smime-ecc-06.txt> as an Informational RFC.  This document is
the product of the S/MIME Mail Security Working Group.  The IESG
contact persons are Jeffrey Schiller and Marcus Leech.
Permalink | Reply | 0 comments |
headers
Peter Gutmann | 8 Feb 2002 05:07
Picon
Picon
Picon
Favicon

Re: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt


>The key wrap algorithms defined in [3DES-WRAP] and [AES-WRAP] cover the of
>wrapping a Triple-DES key with another Triple-DES key and wrapping an AES key
>with another AES key, respectively.  This document specifies two similar
>mechanisms.  One specifies the mechanism for wrapping an HMAC key with a
>Triple-DES key, and the other specifies the mechanism for wrapping an HMAC key
>with an AES key.

Given that RFC 3211 specifies a universal algorithm for wrapping any key in any
other key, is there any need to create special-case x-in-y wrap RFCs of this
kind?  This draft seems entirely superfluous, since a standards-track RFC
containing an algorithm which does what's in the draft already exists.

Peter.
Permalink | Reply | 3 comments |
headers
Housley, Russ | 8 Feb 2002 16:23

WG Last Call: draft-ietf-smime-aes-keywrap-00.txt


Dear S/MIME WG Members:

This message announces Working Group Last Call for aes-keywrap.  The two 
authors have independently written implementations of the specification, 
and the implementations interoperate.  This indicates that the 
specification contains the necessary detail.

	Title		: AES Key Wrap Algorithm
	Author(s)	: J. Schaad, R. Housley
	Filename	: draft-ietf-smime-aes-keywrap-00.txt
	Date		: 06-Feb-02

The intent is to publish aes-keywrap as an Informational RFC.

Please review aes-keywrap, and post any comments to the ietf-smime <at> imc.org 
mail list by Saturday, 23 February 2002.  Unless traffic on the mail list 
indicates otherwise, I will
send these to the IESG shortly after WG Last Call closes.

Russ
Permalink | Reply | 3 comments |
headers
Housley, Russ | 8 Feb 2002 16:31

WG Last Call: draft-ietf-smime-hmac-key-wrap-00.txt


Dear S/MIME WG Members:

This message announces Working Group Last Call for hmac-key-wrap.  The two 
authors have independently written implementations of the specification, 
and the implementations interoperate.  This indicates that the 
specification contains the necessary detail.

	Title		: Wrapping an HMAC key with a Triple-DES Key
			:	or an AES Key
	Author(s)	: J. Schaad, R. Housley
	Filename	: draft-ietf-smime-hmac-key-wrap-00.txt
	Date		: 06-Feb-02

The intent is to publish hmac-key-wrap as an Informational RFC.

Please review hmac-key-wrap, and post any comments to the 
ietf-smime <at> imc.org mail list by Saturday, 23 February 2002.  Unless traffic 
on the mail list indicates otherwise, I will
send these to the IESG shortly after WG Last Call closes.

Russ
Permalink | Reply | 0 comments |
headers
Peter Gutmann | 8 Feb 2002 17:46
Picon
Picon
Picon
Favicon

Re: WG Last Call: draft-ietf-smime-hmac-key-wrap-00.txt


"Housley, Russ" <rhousley <at> rsasecurity.com> writes:

>Please review hmac-key-wrap, and post any comments to the ietf-smime <at> imc.org
>mail list by Saturday, 23 February 2002.

I've already posted my thoughts on this earlier on - why is this being
published when there's already a standards-track RFC which specifies an
algorithm for the same thing?

Peter.
Permalink | Reply | 0 comments |
headers
Housley, Russ | 8 Feb 2002 18:06

Re: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt


Peter:

The minutes from the S/MIME WG session at the IETF meeting last December 
include the following:

    The first issue dealt with the problem of wrapping an HMAC key with a
    Triple-DES, RC2 or AES key.  Currently, one password-based key management
    includes a defined method for this operation.  A new draft is to be
    prepared to define a mechanism.

Clearly, the people at the meeting felt that the key wrap algorithm in RFC 
3211 was intended for used with password-derived KEKs.

Russ

At 05:07 PM 2/8/2002 +1300, Peter Gutmann wrote:

> >The key wrap algorithms defined in [3DES-WRAP] and [AES-WRAP] cover the of
> >wrapping a Triple-DES key with another Triple-DES key and wrapping an 
> AES key
> >with another AES key, respectively.  This document specifies two similar
> >mechanisms.  One specifies the mechanism for wrapping an HMAC key with a
> >Triple-DES key, and the other specifies the mechanism for wrapping an 
> HMAC key
> >with an AES key.
>
>Given that RFC 3211 specifies a universal algorithm for wrapping any key 
>in any
>other key, is there any need to create special-case x-in-y wrap RFCs of this
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Rescorla | 8 Feb 2002 18:41

Re: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt


pgut001 <at> cs.aucKland.ac.nz (Peter Gutmann) writes:

> >The key wrap algorithms defined in [3DES-WRAP] and [AES-WRAP] cover the of
> >wrapping a Triple-DES key with another Triple-DES key and wrapping an AES key
> >with another AES key, respectively.  This document specifies two similar
> >mechanisms.  One specifies the mechanism for wrapping an HMAC key with a
> >Triple-DES key, and the other specifies the mechanism for wrapping an HMAC key
> >with an AES key.
> 
> Given that RFC 3211 specifies a universal algorithm for wrapping any key in any
> other key, is there any need to create special-case x-in-y wrap RFCs of this
> kind?  This draft seems entirely superfluous, since a standards-track RFC
> containing an algorithm which does what's in the draft already exists.
I must admit, I've got the same question. If the argument is that
3211 is somehow inadequate, it seems to me that the fix would be to 
design an adequate mechanism, not to write a separate draft for each
encryption algorithm/key pair.

-Ekr

--

-- 
[Eric Rescorla                                   ekr <at> rtfm.com]
                http://www.rtfm.com/
Permalink | Reply | 0 comments |

Gmane