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

["Jim Schaad" <[e-mail]>]

After long discussions with Russ and Peter over the last week, I have
come up with the following list of items that need clarification.

1. How OIDs are assigned for key wrap algorithms.  Under the current
naming scheme the following items are identified by the assigned OID:
1) The exact key wrap algorithm to be used (including padding done to
the data), 2) The block encryption cipher applied during the key wrap
algorithm and 3) The purpose for which the embedded key is to be used.

2. Should a common key algorithm (including padding) be used for all
128-bit block cipher algorithms.  (i.e. should the AES and the HMAC key
wrap algorithm be identical including padding).

3. Should we update any current or existing documents based on any new
understandings that we arrive at.

COMMENTARY:

1.  I find that the third item in assign a key OID to be at present
insecure and and not really enforcable.  It is a feature which is not
currently present in PKCS#1 v1.5 and is far better covered for the DH
case by the fact that the CEK (i.e. destination) algorithm is used for
the KEK derivation process.  I was not really aware until I spoke to
Russ that the third item was even present in the OID definition and have
therefore never even thought to enforce it in my code in any way.  

2.  Russ, please address the following for me.  Is it really the CEK not
the KEK block encryption algorithm that should be protected during the
DH key derivation process?  If they are the same as is presently true it
is not an issue, but is of interest if you use an HMAC algorithm rather
than a CEK algorithm.

3.  I believe that there is an element of simplicity gained from having
a common key wrap algorithm for the AES key sizes.  I do not currently
believe that there is a benefit to breaking backwards compatablility to
achive the same effect with the 64-bit block size algorithms.

Conclusions:

I think that changing the OID assignment method should be looked at for
the 128-bit block algorithms, but we should not change our current
course for 64-bit block algorithms.  This does mean that we need to
change both AES-keywrap and HMAC-keywrap, but need input from the list,
from Russ and Peter and from NIST (the current AES key wrap algorithm
definers).

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Peter Gutmann
> Sent: Saturday, February 16, 2002 12:08 AM
> To: [e-mail]
> Subject: RE: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
> 
> 
> 
> "Jim Schaad" <[e-mail]> writes:
> 
> >It is true that the wrapping algorithm in RFC 3211 exists 
> and could be used
> >for the HMAC wrapping process.  However the pure Triple-DES 
> wrap algorithm was
> >required to implement CMS, and it is still a required algorithm for
> >impliementing Diffie-Hellman key management in the cmsalg. 
> 
> ... which virtually nothing implements.  Hardly a strong 
> argument for using it.
> 
> >Given that it is a required algorithm, it seems to be a good 
> base to expand
> >on.
> 
> But it still has the problem that every single little 
> variation requires a
> completely new RFC to handle it, whereas the RFC 3211 wrap 
> covers any algorithm
> type and key combination.  You implement it once, and it 
> works for everything.
> 
> (In fact the 3211 wrap is parameterised, something I added at 
> your insistence,
>  so there's no reason it can't be adapted to do whatever you need).
> 
> >The AES key wrap algorithm is currently on track to become 
> the standard key
> >wrap algorithm for use with AES.  Again, given that it is 
> expected to be the
> >standard algorithm, it seems to be a good base to expand on.
> 
> It's yet another special-case variation which people have to 
> implement.
> 
> >I personally have some security reservations about the key 
> wrap algorithm
> >given in RFC 3211. Triple-DES key wrap received significant 
> peer review.
> >[etc]
> 
> See my private reply.
> 
> Peter.
> 




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1R0fGI27721 for ietf-smime-bks; Tue, 26 Feb 2002 16:41:16 -0800 (PST)
Received: from frankenstein.nwlink.com (pop.nwlink.com [209.20.130.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1R0fE327717 for <[e-mail]>; Tue, 26 Feb 2002 16:41:14 -0800 (PST)
Received: from revelation (ip28.c229.blk1.bel.nwlink.com [209.20.229.28]) by frankenstein.nwlink.com (8.11.3/8.11.3) with ESMTP id g1R0fEK26144; Tue, 26 Feb 2002 16:41:14 -0800 (PST) (envelope-from [e-mail])
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Peter Gutmann'" <[e-mail]>, <[e-mail]>
Cc: "Russ Housley" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
Date: Tue, 26 Feb 2002 16:39:25 -0800
Message-ID: <001d01c1bf27$3c3ceca0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

After long discussions with Russ and Peter over the last week, I have
come up with the following list of items that need clarification.

1. How OIDs are assigned for key wrap algorithms.  Under the current
naming scheme the following items are identified by the assigned OID:
1) The exact key wrap algorithm to be used (including padding done to
the data), 2) The block encryption cipher applied during the key wrap
algorithm and 3) The purpose for which the embedded key is to be used.

2. Should a common key algorithm (including padding) be used for all
128-bit block cipher algorithms.  (i.e. should the AES and the HMAC key
wrap algorithm be identical including padding).

3. Should we update any current or existing documents based on any new
understandings that we arrive at.

COMMENTARY:

1.  I find that the third item in assign a key OID to be at present
insecure and and not really enforcable.  It is a feature which is not
currently present in PKCS#1 v1.5 and is far better covered for the DH
case by the fact that the CEK (i.e. destination) algorithm is used for
the KEK derivation process.  I was not really aware until I spoke to
Russ that the third item was even present in the OID definition and have
therefore never even thought to enforce it in my code in any way.  

2.  Russ, please address the following for me.  Is it really the CEK not
the KEK block encryption algorithm that should be protected during the
DH key derivation process?  If they are the same as is presently true it
is not an issue, but is of interest if you use an HMAC algorithm rather
than a CEK algorithm.

3.  I believe that there is an element of simplicity gained from having
a common key wrap algorithm for the AES key sizes.  I do not currently
believe that there is a benefit to breaking backwards compatablility to
achive the same effect with the 64-bit block size algorithms.

Conclusions:

I think that changing the OID assignment method should be looked at for
the 128-bit block algorithms, but we should not change our current
course for 64-bit block algorithms.  This does mean that we need to
change both AES-keywrap and HMAC-keywrap, but need input from the list,
from Russ and Peter and from NIST (the current AES key wrap algorithm
definers).

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Peter Gutmann
> Sent: Saturday, February 16, 2002 12:08 AM
> To: [e-mail]
> Subject: RE: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
> 
> 
> 
> "Jim Schaad" <[e-mail]> writes:
> 
> >It is true that the wrapping algorithm in RFC 3211 exists 
> and could be used
> >for the HMAC wrapping process.  However the pure Triple-DES 
> wrap algorithm was
> >required to implement CMS, and it is still a required algorithm for
> >impliementing Diffie-Hellman key management in the cmsalg. 
> 
> ... which virtually nothing implements.  Hardly a strong 
> argument for using it.
> 
> >Given that it is a required algorithm, it seems to be a good 
> base to expand
> >on.
> 
> But it still has the problem that every single little 
> variation requires a
> completely new RFC to handle it, whereas the RFC 3211 wrap 
> covers any algorithm
> type and key combination.  You implement it once, and it 
> works for everything.
> 
> (In fact the 3211 wrap is parameterised, something I added at 
> your insistence,
>  so there's no reason it can't be adapted to do whatever you need).
> 
> >The AES key wrap algorithm is currently on track to become 
> the standard key
> >wrap algorithm for use with AES.  Again, given that it is 
> expected to be the
> >standard algorithm, it seems to be a good base to expand on.
> 
> It's yet another special-case variation which people have to 
> implement.
> 
> >I personally have some security reservations about the key 
> wrap algorithm
> >given in RFC 3211. Triple-DES key wrap received significant 
> peer review.
> >[etc]
> 
> See my private reply.
> 
> Peter.
> 



Received: by above.proper.com (8.11.6/8.11.3) id g1QLxcu24321 for ietf-smime-bks; Tue, 26 Feb 2002 13:59:38 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g1QLxa324317 for <[e-mail]>; Tue, 26 Feb 2002 13:59:36 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 26 Feb 2002 21:59:22 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA10252 for <[e-mail]>; Tue, 26 Feb 2002 16:59:30 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g1QLxae12446 for <[e-mail]>; Tue, 26 Feb 2002 16:59:36 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <F4N5MXPH>; Tue, 26 Feb 2002 16:57:27 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.107]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F4N5MXPF; Tue, 26 Feb 2002 16:57:25 -0500
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 26 Feb 2002 16:57:57 -0500
Subject: draft-ietf-smime-rfc2633bis-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Blake:

I have some comments on rfc2633bis-00.  I hoped to get to this document 
sooner, but the RSA Conference last week was quite hectic.

Title Page.  Please add a line to the heading that indicates that this 
document, when approved, will obsolete RFC 2633.

Overall.  Please change "draft" to "specification."  This will avoid a 
bunch of last minute changes when we want to progress from Internet-Draft 
to Standards-Track RFC.

Overall.  Please change "content encryption key" to "content-encryption 
key" to harmonize the terminology with RFC 2630 (and RFC 2630bis).

Overall.  Please change "privacy" to "confidentiality" throughout the 
document to align with the definitions in RFC 2828.  In each case, 
sentences will require slight rewording.

Section 1.  Please add a subsection that describes the changes since RFC 2633.

Section 2.5, 2nd paragraph.  The formatting got messed up.  Please turn 
into a list of bullets.

Section 2.5.1, 1st paragraph.  Please delete references to trusted 
timestamping services.  If you wish, add a section that references the 
attributes associated with such a service.

Section 2.5.2, 6th paragraph.  Please fix the URL by removing the extra space.

Section 2.7.1. Please line up the bullets that begin the 3rd and 4th 
paragraphs.

Section 3.1. The current wording (rightly) prevents the encryption of RFC 
822 header.  However, there should be some discussion about the protection 
of this header information.  There was a very long discussion of this topic 
on the list, and the conclusions need to be documented here.

Section 5.  Please replace the "[TBD]" with a sentence of warning about the 
Million Message Attack and a reference to RFC 3218.  Similarly, 
implementors of Diffie-Hellman should be warned about small subgroups and 
given a reference to RFC 2785.

ASN.1.  Several of the types defined here are already in cmsalg.  We should 
trim the module to the minimum set of types.

Enjoy,
   Russ 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1QJHCK20138 for ietf-smime-bks; Tue, 26 Feb 2002 11:17:12 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g1QJHB320134 for <[e-mail]>; Tue, 26 Feb 2002 11:17:11 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 26 Feb 2002 19:16:57 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA27876; Tue, 26 Feb 2002 14:17:05 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g1QJGwp28442; Tue, 26 Feb 2002 14:16:59 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <F4N5M4AR>; Tue, 26 Feb 2002 14:02:05 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.27]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F4N5M4AN; Tue, 26 Feb 2002 14:02:01 -0500
From: "Housley, Russ" <[e-mail]>
To: Tony Capel <[e-mail]>
Cc: Terry Harding <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 26 Feb 2002 14:03:23 -0500
Subject: RE: Order of signing and compression operations. 
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tony:

You are correct. I assumed lossless compression.

Russ


At 01:57 PM 2/26/2002 -0500, Tony Capel wrote:
>Terry
>
>Of course, this assumes the use of lossless compression, and zlib as
>proposed by Peter as the mandatory-to-implement algorithm in the
>compression proposal satisfies that.
>
>However in the future, and for some applications, one might wonder if a
>lossy compressor might be favoured (e.g. JPEG if you are signing images
>emitted by a surveillance camera).
>
>In this case of course, it must be: compress then sign
>
>Tony Capel,
>Comgate Engineering Ltd.
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Housley, Russ
> > Sent: February 26, 2002 11:21 AM
> > To: Terry Harding
> > Cc: [e-mail]
> > Subject: Re: Order of signing and compression operations.
> >
> >
> >
> > Terry:
> >
> > A general rule of thumb: sign before compress.
> >
> > Another general rule of thumb: sign before encrypt.
> >
> > There are exceptions to both rules.  However, the idea is to
> > sign what you
> > say, not what you transmit.  In the compression context, the
> > exception may
> > arise when the content is huge and there is a large difference
> > between the
> > following:
> >
> >          Hash( Compress( content ) )
> >          Compress( Hash( content ) )
> >
> > In this situation, you ought to consider application context and
> > the reason
> > for the signature.  For example, if an arbitrator is going to
> > resolve any
> > dispute, and that arbitrator understands the compression and signature
> > technologies, then either order is okay.
> >
> > Russ
> >
> >
> > At 03:25 PM 2/25/2002 -0700, Terry Harding wrote:
> >
> > >All,
> > >
> > >Does the S/MIME group have a preference on the order of operations when
> > >signing and compressing a S/MIME
> > >message when using the compressed data content type for cms.
> > >
> > >Should compression occur before signing or should signing occur before
> > >compression or maybe it does not matter.
> > >
> > >Any guidance by the S/MIME group would be greatly appreciated.
> > >
> > >Terry Harding
> > >Cyclone Commerce
> >
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1QJGWc20117 for ietf-smime-bks; Tue, 26 Feb 2002 11:16:32 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g1QJGU320112 for <[e-mail]>; Tue, 26 Feb 2002 11:16:30 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 26 Feb 2002 19:16:16 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA27539; Tue, 26 Feb 2002 14:15:54 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g1QJFnj28133; Tue, 26 Feb 2002 14:15:49 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <F4N5MT5A>; Tue, 26 Feb 2002 13:48:41 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.27]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F4N5MTZ8; Tue, 26 Feb 2002 13:48:38 -0500
From: "Housley, Russ" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 26 Feb 2002 13:04:30 -0500
Subject: S/MIME WG Finished: draft-ietf-smime-aes-keywrap-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeff & Marcus:

The S/MIME WG is fininshed with draft-ietf-smime-aes-keywrap-00.txt.  The 
intent is to publish this document as an Informational RFC.  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

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1QIqbi19708 for ietf-smime-bks; Tue, 26 Feb 2002 10:52:37 -0800 (PST)
Received: from mx2.magma.ca (mx2.magma.ca [206.191.0.250]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1QIqZ319704 for <[e-mail]>; Tue, 26 Feb 2002 10:52:36 -0800 (PST)
Received: from mail1.magma.ca (mail1.magma.ca [206.191.0.252]) by mx2.magma.ca (Magma's Mail Server) with ESMTP id g1QIqZdN024051; Tue, 26 Feb 2002 13:52:35 -0500 (EST)
Received: from tony (ottawa-hs-209-217-122-183.s-ip.magma.ca [209.217.122.183]) by mail1.magma.ca (Magma's Mail Server) with SMTP id g1QIqZvt011052; Tue, 26 Feb 2002 13:52:35 -0500 (EST)
From: "Tony Capel" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, "Terry Harding" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Order of signing and compression operations. 
Date: Tue, 26 Feb 2002 13:57:00 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Terry

Of course, this assumes the use of lossless compression, and zlib as
proposed by Peter as the mandatory-to-implement algorithm in the
compression proposal satisfies that.

However in the future, and for some applications, one might wonder if a
lossy compressor might be favoured (e.g. JPEG if you are signing images
emitted by a surveillance camera).

In this case of course, it must be: compress then sign

Tony Capel,
Comgate Engineering Ltd.

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Housley, Russ
> Sent: February 26, 2002 11:21 AM
> To: Terry Harding
> Cc: [e-mail]
> Subject: Re: Order of signing and compression operations.
>
>
>
> Terry:
>
> A general rule of thumb: sign before compress.
>
> Another general rule of thumb: sign before encrypt.
>
> There are exceptions to both rules.  However, the idea is to
> sign what you
> say, not what you transmit.  In the compression context, the
> exception may
> arise when the content is huge and there is a large difference
> between the
> following:
>
>          Hash( Compress( content ) )
>          Compress( Hash( content ) )
>
> In this situation, you ought to consider application context and
> the reason
> for the signature.  For example, if an arbitrator is going to
> resolve any
> dispute, and that arbitrator understands the compression and signature
> technologies, then either order is okay.
>
> Russ
>
>
> At 03:25 PM 2/25/2002 -0700, Terry Harding wrote:
>
> >All,
> >
> >Does the S/MIME group have a preference on the order of operations when
> >signing and compressing a S/MIME
> >message when using the compressed data content type for cms.
> >
> >Should compression occur before signing or should signing occur before
> >compression or maybe it does not matter.
> >
> >Any guidance by the S/MIME group would be greatly appreciated.
> >
> >Terry Harding
> >Cyclone Commerce
>
>



Received: by above.proper.com (8.11.6/8.11.3) id g1QGL4B13665 for ietf-smime-bks; Tue, 26 Feb 2002 08:21:04 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g1QGL2313661 for <[e-mail]>; Tue, 26 Feb 2002 08:21:02 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 26 Feb 2002 16:20:48 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA15299 for <[e-mail]>; Tue, 26 Feb 2002 11:20:55 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g1QGL0Y13922 for <[e-mail]>; Tue, 26 Feb 2002 11:21:00 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <F4N5MQ8J>; Tue, 26 Feb 2002 11:18:49 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.98]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id F4N5MQ81; Tue, 26 Feb 2002 11:18:43 -0500
From: "Housley, Russ" <[e-mail]>
To: Terry Harding <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 26 Feb 2002 11:20:45 -0500
Subject: Re: Order of signing and compression operations. 
In-Reply-To: <00d701c1be4b$496d9eb0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Terry:

A general rule of thumb: sign before compress.

Another general rule of thumb: sign before encrypt.

There are exceptions to both rules.  However, the idea is to sign what you 
say, not what you transmit.  In the compression context, the exception may 
arise when the content is huge and there is a large difference between the 
following:

         Hash( Compress( content ) )
         Compress( Hash( content ) )

In this situation, you ought to consider application context and the reason 
for the signature.  For example, if an arbitrator is going to resolve any 
dispute, and that arbitrator understands the compression and signature 
technologies, then either order is okay.

Russ


At 03:25 PM 2/25/2002 -0700, Terry Harding wrote:

>All,
>
>Does the S/MIME group have a preference on the order of operations when
>signing and compressing a S/MIME
>message when using the compressed data content type for cms.
>
>Should compression occur before signing or should signing occur before
>compression or maybe it does not matter.
>
>Any guidance by the S/MIME group would be greatly appreciated.
>
>Terry Harding
>Cyclone Commerce


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1Q1LL315182 for ietf-smime-bks; Mon, 25 Feb 2002 17:21:21 -0800 (PST)
Received: from c1plenaexi01.commerceone.com (mail.commerceone.com [12.22.60.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1Q1LJ315177 for <[e-mail]>; Mon, 25 Feb 2002 17:21:19 -0800 (PST)
Received: by c1plenaexi01.commerceone.com with Internet Mail Service (5.5.2653.19) id <FK5KPWNK>; Mon, 25 Feb 2002 17:22:59 -0800
Message-ID: <[e-mail]>
From: "Ahmed, Zahid" <[e-mail]>
To: [e-mail]
Subject: RE: Order of signing and compression operations. 
Date: Mon, 25 Feb 2002 17:21:10 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BE63.DFD20F90"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1BE63.DFD20F90
Content-Type: text/plain;
	charset="iso-8859-1"

If you sign a compressed S/MIME message, then from an
application standpoint what is the meaning of signing
a compressed MIME payload component or compressed MIME
main body part?

A receiving application may expect that signing party
is cognizant of what is being sent in the SMIME message.
However, if the content that is signed is first compressed,
then the receiving party can not assume that that was the
case.

Hence, I would recommend that there be explicit processing
rules where we expect that sending SMIME apps first sign
the SMIME message part(s) and then compress. Receiving
applications first de-compress the message and then 
verify the signature(s).

-----Original Message-----
From: Terry Harding [mailto:[e-mail]]
Sent: Monday, February 25, 2002 2:25 PM
To: [e-mail]
Subject: Order of signing and compression operations. 



All,

Does the S/MIME group have a preference on the order of operations when
signing and compressing a S/MIME
message when using the compressed data content type for cms.

Should compression occur before signing or should signing occur before
compression or maybe it does not matter.

Any guidance by the S/MIME group would be greatly appreciated.

Terry Harding
Cyclone Commerce

------_=_NextPart_001_01C1BE63.DFD20F90
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: Order of signing and compression operations. </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>If you sign a compressed S/MIME message, then from an</FONT>
<BR><FONT SIZE=2>application standpoint what is the meaning of signing</FONT>
<BR><FONT SIZE=2>a compressed MIME payload component or compressed MIME</FONT>
<BR><FONT SIZE=2>main body part?</FONT>
</P>

<P><FONT SIZE=2>A receiving application may expect that signing party</FONT>
<BR><FONT SIZE=2>is cognizant of what is being sent in the SMIME message.</FONT>
<BR><FONT SIZE=2>However, if the content that is signed is first compressed,</FONT>
<BR><FONT SIZE=2>then the receiving party can not assume that that was the</FONT>
<BR><FONT SIZE=2>case.</FONT>
</P>

<P><FONT SIZE=2>Hence, I would recommend that there be explicit processing</FONT>
<BR><FONT SIZE=2>rules where we expect that sending SMIME apps first sign</FONT>
<BR><FONT SIZE=2>the SMIME message part(s) and then compress. Receiving</FONT>
<BR><FONT SIZE=2>applications first de-compress the message and then </FONT>
<BR><FONT SIZE=2>verify the signature(s).</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Terry Harding [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Monday, February 25, 2002 2:25 PM</FONT>
<BR><FONT SIZE=2>To: [e-mail]</FONT>
<BR><FONT SIZE=2>Subject: Order of signing and compression operations. </FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2>All,</FONT>
</P>

<P><FONT SIZE=2>Does the S/MIME group have a preference on the order of operations when</FONT>
<BR><FONT SIZE=2>signing and compressing a S/MIME</FONT>
<BR><FONT SIZE=2>message when using the compressed data content type for cms.</FONT>
</P>

<P><FONT SIZE=2>Should compression occur before signing or should signing occur before</FONT>
<BR><FONT SIZE=2>compression or maybe it does not matter.</FONT>
</P>

<P><FONT SIZE=2>Any guidance by the S/MIME group would be greatly appreciated.</FONT>
</P>

<P><FONT SIZE=2>Terry Harding</FONT>
<BR><FONT SIZE=2>Cyclone Commerce</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1BE63.DFD20F90--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PMPDj11679 for ietf-smime-bks; Mon, 25 Feb 2002 14:25:13 -0800 (PST)
Received: from sawgrass.cyclonesoftware.com (sawgrass.cyclonesoftware.com [12.34.72.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PMPB311675 for <[e-mail]>; Mon, 25 Feb 2002 14:25:11 -0800 (PST)
Received: from THARDINGLAPTOP (ip68-3-48-129.ph.ph.cox.net [68.3.48.129]) (authenticated) by sawgrass.cyclonesoftware.com (8.11.2/8.11.0) with ESMTP id g1PMP9d12817 for <[e-mail]>; Mon, 25 Feb 2002 15:25:09 -0700
Message-ID: <00d701c1be4b$496d9eb0$[e-mail]>
From: "Terry Harding" <[e-mail]>
To: <[e-mail]>
Subject: Order of signing and compression operations. 
Date: Mon, 25 Feb 2002 15:25:04 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

Does the S/MIME group have a preference on the order of operations when
signing and compressing a S/MIME
message when using the compressed data content type for cms.

Should compression occur before signing or should signing occur before
compression or maybe it does not matter.

Any guidance by the S/MIME group would be greatly appreciated.

Terry Harding
Cyclone Commerce



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PLda010090 for ietf-smime-bks; Mon, 25 Feb 2002 13:39:36 -0800 (PST)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PLdZ310085 for <[e-mail]>; Mon, 25 Feb 2002 13:39:35 -0800 (PST)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <D642C8KN>; Mon, 25 Feb 2002 16:39:31 -0500
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "SMIME WG (E-mail)" <[e-mail]>
Subject: v2.0.1 S/MIME Freeware Library (SFL) Now Available
Date: Mon, 25 Feb 2002 16:39:30 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

Getronics Government Solutions has delivered Version 2.0.1 of the 
S/MIME Freeware Library (SFL) source code.  The SFL source code files 
are freely available at <http://www.getronicsgov.com/hot/sfl_home.htm>.
The v2.0.1 SFL fixes bugs present in the v2.0 SFL (see below).  It also
includes enhancements to the CertificateBuilder utility.

The SFL implements the IETF S/MIME v3 RFC 2630 Cryptographic Message 
Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications. 
It also implements portions of the RFC 2633 Message Specification and 
RFC 2632 Certificate Handling document.  When used in conjunction with
the Crypto++ freeware library, the SFL implements the RFC 2631 
Diffie-Hellman (D-H) Key Agreement Method specification.  It has been 
successfully tested using the Microsoft (MS) Windows NT/98/2000/XP, Linux
and Sun Solaris 2.8 operating systems.  Further enhancements, ports and 
testing of the SFL are still in process.  Further releases of the SFL
will be provided as significant capabilities are added. 

The SFL has been successfully used to sign, verify, encrypt and decrypt 
CMS/ESS objects using: DSA, E-S D-H, 3DES algorithms provided by the 
Crypto++ library; RSA suite of algorithms provided by the RSA BSAFE 6.0
Crypto-C and Crypto++ libraries; and Fortezza suite of algorithms provided
by the Fortezza Crypto Card.  The v2.0.1 SFL uses the v1.3 R8 Enhanced
SNACC ASN.1 C++ Library to encode/decode objects. The v2.0.1 SFL release 
includes: SFL High-level library; Free (a.k.a. Crypto++) Crypto Token 
Interface Library (CTIL); BSAFE CTIL; Fortezza CTIL; SPEX/ CTIL; PKCS #11
CTIL; MS CAPI v2.0 CTIL; v1.3 R8 Enhanced SNACC ASN.1 Compiler and Library;
test utilities; test drivers; and test data.  All CTILs were tested as 
Dynamically Linked Libraries (DLL) using MS Windows.  The Fortezza, BSAFE
and Crypto++ CTILs were tested with the respective security libraries as
shared objects using Linux and Solaris 2.8.  

The SFL has been successfully used to exchange signedData and envelopedData 
messages with the MS Internet Explorer Outlook Express v4.01, Netscape
Communicator 4.X, Entrust and Baltimore S/MIME products.  Signed messages
have been exchanged with the RSA S/MAIL and WorldTalk S/MIME v2 products. 

The SFL has also been used to perform S/MIME v3 interoperability testing
with 
Microsoft that exercised the majority of the features specified by RFCs 
2630, 2631 and 2634.  This testing included the RSA, DSA, E-S D-H, 3DES, SHA
and Fortezza algorithms.  We used the SFL to successfully process all of 
the SFL-supported sample data included in the S/MIME WG "Examples of S/MIME 
Messages" document.  We also used the SFL to generate S/MIME v3 sample 
messages that were included in the "Examples" document.

The use of the v2.0.1 SFL is described in the v2.0 SFL Application 
Programming Interface (API) and v2.0 SDD documents.  The v2.0 SMP 
Components Setup Manual that describes the component installation
procedures for the v2.0.1 SFL, v2.0.1 Certificate Management Library (CML),
and v1.3 R8 Enhanced SNACC libraries.  The use of the v2.0.1 CTIL API is
described in the v2.0 CTIL API document. 


The following enhancements are included in the v2.0.1 SFL and CTIL releases
(compared with the v2.0 releases):

1) Fixed bug regarding the SFL ASN.1 decoding of security labels that 
do not include any security categories.  

2) Fixed memory management errors that we discovered during memory leak
testing of the release version of the SFL library that could not be 
detected while testing the debug version. 

3) Enhanced MS CAPI CTIL to work with Datakey crypto service provider
and smart card.

4) Enhanced CTILs by re-structuring to load the CSM_CSInst certificate
after the initial creation.

5) Fixed a bug that impacted interoperability testing between messages
protected using the Microsoft CAPI CTIL and Crypto++ CTIL.  

6) Tested RSA BSAFE 6.0 Crypto-C library using v2.0.1 SFL, CML and 
BSAFE CTIL on MS Windows, Sun Solaris, Linux.


CERTIFICATE BUILDER Enhancements (used to create X.509 certificates):  

1) Added functionality to create a SubjectKeyIdentifier 
value by hashing the public key in the cert.   

2) Added logic to copy the signer SubjectKeyIdentifier
into the produced certificate AuthKeyIdentifier extension.

3) Added support for populating AltSubjectName extension.

4) Self-signed certificates can now be generated.  

5) Added ability to populate certificatePolicy qualifier fields.

6) Corrected bugs.


We are still in the process of enhancing and testing the SFL.  Future 
releases may include: additional PKCS #11 CTIL testing; finish 
CertificateBuilder command line utility; enhancing 
CertificateBuilder to support creation of Attribute Certificates; 
add "Certificate Management Messages over CMS" ASN.1 encode/decode 
functions; add enhanced test routines; bug fixes; support for other 
crypto APIs; and support for other operating systems. 

The SFL is developed to maximize portability to 32-bit operating 
systems.  In addition to testing on MS Windows, Linux and Solaris 2.8, 
we may port the SFL to other operating systems.


The following SFL files are available from 
<http://www.getronicsgov.com/hot/sfl_lib.htm>:

1) SFL Documents: Fact Sheet, Software Design Description, API, CTIL 
API, Software Test Description, Implementers Guide, Overview Briefing
and Public License.     

2) smimeR2.0.1.tar.gz:  Source code, MS Windows project files and 
Unix makefiles for SFL Hi-Level library.

3) snacc13r8rn.tar.gz (source code and binaries available from Getronics 
Enhanced SNACC web page: <http://www.getronicsgov.com/hot/snacc_home.htm>): 
Source code, MS Windows project files and Unix makefiles for
v1.3 R8 Enhanced SNACC ASN.1 Compiler and Library that has been enhanced by
Getronics to implement the Distinguished Encoding Rules.  Source code is
compilable for Linux, Solaris 2.8 and MS Windows NT/95/98/2000/XP. This
file includes a sample test project demonstrating the use of the SNACC
classes.  

4) smCTIR2.0.1.tar.gz:  Source code, MS Windows project files and 
Unix makefiles for the following CTILs: Test (no crypto), Crypto++, BSAFE, 
Fortezza, SPEX/, PKCS #11 and MS CAPI v2.0.  The CTIL source code includes
PKCS #12 software developed by the OpenSSL Project for use in the OpenSSL
Toolkit <http://www.openssl.org/>

5) sm_CTIL_MGR_R2.0.1.tar.gz: Source code, MS Windows project files and 
Unix makefiles for the CTILManager library that provides CTIL-related 
processing services used by the SFL, ACL and CML.

6) smTest2.0.1.tar.gz: Source code, MS Windows project files and 
Unix makefiles for test drivers used to test the SFL.  This file includes 
sample CMS/ESS test data and test X.509 Certificates.  It also includes 
the CertificateBuilder utility that can be used to create X.509
Certificates.


All source code for the SFL is being provided at no cost and with no 
financial limitations regarding its use and distribution. 
Organizations can use the SFL without paying any royalties or 
licensing fees.  Getronics is developing the SFL under contract to 
the U.S. Government.  The U.S. Government is furnishing the SFL
source code at no cost to the vendor subject to the conditions of 
the "SFL Public License".

On 14 January 2000, the U.S. Department of Commerce, Bureau of 
Export Administration published a new regulation implementing an update 
to the U.S. Government's encryption export policy 
<http://www.bxa.doc.gov/Encryption/Default.htm>.  In accordance with 
the revisions to the Export Administration Regulations (EAR) of 14 Jan 
2000, the downloading of the SFL source code is not password controlled.

The SFL is composed of a high-level library that performs generic CMS 
and ESS processing independent of the crypto algorithms used to 
protect a specific object.  The SFL high-level library makes calls to 
an algorithm-independent CTIL API.  The underlying, external crypto
token libraries are not distributed as part of the SFL 
source code. The application developer must independently obtain these 
libraries and then link them with the SFL.  
 
The SFL uses the CML and Enhanced SNACC ASN.1 Library to encode/decode
certificates, ACs, CRLs and components thereof.  The CML is freely
available at: <http://www.getronicsgov.com/hot/cml_home.htm>.

The SFL has been successfully tested in conjunction with the Access
Control Library (ACL) that is freely available to everyone from: 
<http://www.getronicsgov.com/hot/acl_home.htm>.

The National Institute of Standards and Technology (NIST) is providing 
test S/MIME messages (created by Getronics) at 
<http://csrc.nist.gov/pki/testing/x509paths.html>.  
Getronics used the SFL to successfully process the NIST test data.

NIST is using the SFL and CML as part of the NIST S/MIME Test 
Facility (NSMTF) that they are planning to host (see 
<http://csrc.ncsl.nist.gov/pki/smime/>).  Vendors will be able to use
the NSMTF to help determine if their products comply with the
IETF S/MIME v3 specifications and the Federal S/MIME v3 Client Profile.  

The SFL has been integrated into many applications to provide CMS/ESS
security services.  For example, the SFL was integrated into a security
plug-in for a commercial e-mail application that enabled the 
application to meet the Bridge Certification Authority Demonstration 
Phase II requirements including implementing ESS features such as
security labels.

The Internet Mail Consortium (IMC) has established an SFL web page
<http://www.imc.org/imc-sfl>.  The IMC has also established an SFL
mail list which is used to: distribute information regarding SFL
releases; discuss SFL-related issues; and provide a means for SFL
users to provide feedback, comments, bug reports, etc.  Subscription
information for the imc-sfl mailing list is at the IMC web site
listed above.

All comments regarding the SFL source code and documents are welcome.  
This SFL release announcement was sent to several mail lists, but 
please send all messages regarding the SFL to the imc-sfl mail list 
ONLY.  Please do not send messages regarding the SFL to any of the IETF 
mail lists.  We will respond to all messages sent to the imc-sfl mail 
list.

============================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
============================================ 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PKWW008370 for ietf-smime-bks; Mon, 25 Feb 2002 12:32:32 -0800 (PST)
Received: from wfhqex03.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PKTD308273; Mon, 25 Feb 2002 12:29:13 -0800 (PST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Subject: v1.3 R8 Enhanced SNACC Freeware Now Available
Date: Mon, 25 Feb 2002 15:29:03 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: v1.3 R8 Enhanced SNACC Freeware Now Available
Thread-Index: AcG+PAdHt68nl6ieT1mtbbNlAvBOvA==
From: "Pawling, John" <[e-mail]>
To: "ietf-pkix@imc. org (E-mail)" <[e-mail]>, "SMIME WG (E-mail)" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1PKTD308274
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

Getronics Government Solutions has delivered the v1.3 R8 Enhanced SNACC
Abstract Syntax Notation One (ASN.1) Compiler, C++ library and C library
source code compilable for Linux, Sun Solaris 2.8 and Microsoft (MS) 
Windows NT/98/2000/XP.  The Enhanced SNACC software is freely available
to everyone from: <http://www.getronicsgov.com/hot/snacc_home.htm>.  The
v1.3 R8 Enhanced SNACC release fixes bugs present in the v1.3 R7
release.
 
The Enhanced SNACC ASN.1 software can be used to ASN.1 encode and decode
objects.  In past releases, Getronics enhanced the original SNACC ASN.1 
C++ library to implement the Distinguished Encoding Rules (DER), support

large ASN.1 INTEGERs, and improve memory usage.    

v1.3 R8 Enhanced SNACC ASN.1 Library enhancements (compared to v1.3 R7):

 1) Fixed bug in processing of BMP strings on UNIX platforms.  

 2) Removed dependencies on SNACC config.h in distributed includes/libs.


 3) Developed a test driver and successfully tested the Enhanced SNACC
C ASN.1 Library.  We corrected bugs in the C Library DER code.  

 4) Corrected bug in sm_vdasnacc.cpp (line 303) regarding setting the
length value for indefinite length decodings. 

 5) Corrected AsnOcts to use inherited CSM_Buffer Length() member
function instead of AsnOcts maintaining it's own length data member.  

 6) Corrected memory management bug in AsnOid::PutChar in asn-oid.cpp.

 7) Tested with v2.0.1 S/MIME Freeware Library (SFL) 
<http://www.getronicsgov.com/hot/sfl_home.htm> that uses the Enhanced
SNACC ASN.1 software to encode and decode the IETF S/MIME v3 
Cryptographic Message Syntax (RFC 2630) and Enhanced Security 
Services for S/MIME (RFC 2634) security protocol.  

 8) Tested with freeware v2.0.1 Certificate Management Library (CML)
<http://www.getronicsgov.com/hot/cml_home.htm> that uses the Enhanced
SNACC ASN.1 software to encode and decode X.509 certificates, 
attribute certificates and Certificate Revocation Lists as specified
in the 2000 X.509 Recommendation.

 9) Tested with freeware v2.0.1 Access Control Library (ACL)
<http://www.getronicsgov.com/hot/acl_home.htm> that uses the Enhanced
SNACC ASN.1 software to encode and decode security labels and other 
objects (such as Security Policy Information Files) required to
provide rule based automated access control as specified in SDN.801.

The aforementioned bug fixes improved the multi-threaded performance
of the Enhanced SNACC ASN.1 C++ Library.

The Enhanced SNACC ASN.1 software implements the majority of the 
ASN.1 encoding/decoding rules as specified in the 1988 X.209 
Recommendation.  It implements the DER as specified in the 1994 
X.690 Recommendation.  It does not support all of the latest ASN.1
features, but there are strategies that allow it to be used to 
produce ASN.1 hex encodings that are identical to those produced by
ASN.1 libraries that do support the latest ASN.1 features.  Also note
that many of the PKIX specs, such as RFC 2459 and RFC 2630, include 
1988-compliant ASN.1 syntax modules which can be compiled using the
Enhanced SNACC compiler.

The Enhanced SNACC ASN.1 library is totally unencumbered as stated 
in the Enhanced SNACC Software Public License.  All source code for
the Enhanced SNACC software is being provided at no cost and with no
financial limitations regarding its use and distribution.  
Organizations can use the Enhanced SNACC software without paying
any royalties or licensing fees.  

The Internet Mail Consortium (IMC) has established an Enhanced SNACC
web page <http://www.imc.org/imc-snacc/>.  The IMC has established 
an Enhanced SNACC mail list which is used to: distribute information 
regarding Enhanced SNACC releases; discuss related issues; and 
provide a means for integrators to provide feedback, comments,
bug reports, etc.  Subscription information for the imc-snacc
mail list is at the IMC web site listed above.

We welcome all feedback regarding the Enhanced SNACC software.
If bugs are reported, then we will investigate each reported
bug and, if required, will produce a patch or an updated
release of the software to repair the bug. 

This release announcement was sent to several mail lists,
but please send all messages regarding the Enhanced SNACC 
software to the imc-snacc mail list ONLY.  Please do not send 
messages regarding the Enhanced SNACC software to any of the 
IETF mail lists.  We will respond to all messages sent to the
imc-snacc mail list.

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1PH3UN02835 for ietf-smime-bks; Mon, 25 Feb 2002 09:03:30 -0800 (PST)
Received: from tron.admin.cto.netsol.com (h240.s231.netsol.com [216.168.231.240]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1PH3T302830 for <[e-mail]>; Mon, 25 Feb 2002 09:03:29 -0800 (PST)
Received: (from raldi@localhost) by tron.admin.cto.netsol.com (8.11.6/8.11.6) id g1PH3Pi03843 for [e-mail]; Mon, 25 Feb 2002 12:03:25 -0500
Date: Mon, 25 Feb 2002 12:03:25 -0500
From: Mike Schiraldi <[e-mail]>
To: [e-mail]
Subject: Email wildcards?
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="HB4mHL4PVvkpZAgW"
Content-Disposition: inline
User-Agent: Mutt/1.5.0i
X-Last-Reboot: February 15, 2002 (9 days ago)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--HB4mHL4PVvkpZAgW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Recently i've been working on S/MIME support for the mutt email client, and
several users have been asking me about problems with email addresses that
don't perfectly match those in their certificates.

For example, a user with the address [e-mail] may want to use
[e-mail] when posting here, so that they can keep track of
where spam harvesters are gathering their address from -- many mail delivery
agents strip off "+" and anything after it before matching a username.

Searching through the list archives and elsewhere on the web, i've found
much discussion circa 1998 about whether or not S/MIME should support
wildcards in email certificates, but no resolution. What is the current
status on this? Is there a workaround?

Thanks


--=20
Mike Schiraldi
VeriSign Applied Research

--HB4mHL4PVvkpZAgW
Content-Type: application/x-pkcs7-signature
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIIKIAYJKoZIhvcNAQcCoIIKETCCCg0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
B6wwggR2MIID36ADAgECAhAyACTCO7tQsBTRNUR0/tTjMA0GCSqGSIb3DQEBBAUAMIHMMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5
IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp
dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAxMDMyMjAwMDAw
MFoXDTAyMDMyMjIzNTk1OVowggEaMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE
CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y
ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV
UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO
ZXRzY2FwZSBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pa2UgU2NoaXJhbGRpMSgwJgYJKoZI
hvcNAQkBFhlyYWxkaUByZXNlYXJjaC5uZXRzb2wuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDu28IxMPojtN900dqX3LO3rfhirsJstpbSOzKVwPH9GwIgycFIn3YFkmOpeB40
cBkqNC1HzreGuFFAo9f3Y9xPjbvnEWlNo6oBu/wGL53gUtsUcNcj7tOngfjTr/4V3rohPuWU
4qRAZxjd5qaFUSP3bLh/U/7MoRwRB2Sz82HCqwIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCB
rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC
AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp
OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6
Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAYOkgLNF2
HYrK+ucdU0TN2PIAtbB3vV0cLhHJfE6zzyL9u5PlAKnxqwVYozd5S/u4Lg1WvDFE3vG3mVIE
Fobol2RmSNIo6kOgED48B6oWgU/21lysVZ6DRPnGTSX7FsIH12L0mHj7jSDkzTqtkbzY6is/
YBkKDmeAuXnmljJ7H7wwggMuMIICl6ADAgECAhEA0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG
9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNV
BAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN
OTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp
c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgx
SDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBl
cnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQW
u1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0Rc
qkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqn
sX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4w
PAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0
b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQIFAAOB
gQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ43BuYDAeGW4UVag+5SYWklfEXfWe0fy0s
3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg
5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJp
U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9
d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M
VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj
cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAyACTCO7tQsBTRNUR0/tTjMAkGBSsOAwIa
BQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDIwMjI1
MTcwMzI1WjAjBgkqhkiG9w0BCQQxFgQUeImma0F4UnS0mkOTZJgC+Aq4W60wUgYJKoZIhvcN
AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF
Kw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYCiVZ26yHg1Stzu1COIy4Tx
UIopFW/3RhP9VjIreqty8QFwT+sWZNcmWMexJEMdNDRkb9hWaHJ2BuFEcCu8R+386OjY/TaB
m+zVLK4sHJbQ5ggK1BMzylTcc4yIdmqfz/JjK8kmrQLFfgQdRCU7hO8zlMy5UGy9G7VVHbKm
n4JYGA==

--HB4mHL4PVvkpZAgW--


Received: by above.proper.com (8.11.6/8.11.3) id g1G88bX14328 for ietf-smime-bks; Sat, 16 Feb 2002 00:08:37 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1G88Z314317 for <[e-mail]>; Sat, 16 Feb 2002 00:08:35 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz ([e-mail] [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id VAA25201 for <[e-mail]>; Sat, 16 Feb 2002 21:08:28 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id VAA131570 for [e-mail]; Sat, 16 Feb 2002 21:08:27 +1300 (NZDT) (sender [e-mail])
Date: Sat, 16 Feb 2002 21:08:27 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Jim Schaad" <[e-mail]> writes:

>It is true that the wrapping algorithm in RFC 3211 exists and could be used
>for the HMAC wrapping process.  However the pure Triple-DES wrap algorithm was
>required to implement CMS, and it is still a required algorithm for
>impliementing Diffie-Hellman key management in the cmsalg. 

... which virtually nothing implements.  Hardly a strong argument for using it.

>Given that it is a required algorithm, it seems to be a good base to expand
>on.

But it still has the problem that every single little variation requires a
completely new RFC to handle it, whereas the RFC 3211 wrap covers any algorithm
type and key combination.  You implement it once, and it works for everything.

(In fact the 3211 wrap is parameterised, something I added at your insistence,
 so there's no reason it can't be adapted to do whatever you need).

>The AES key wrap algorithm is currently on track to become the standard key
>wrap algorithm for use with AES.  Again, given that it is expected to be the
>standard algorithm, it seems to be a good base to expand on.

It's yet another special-case variation which people have to implement.

>I personally have some security reservations about the key wrap algorithm
>given in RFC 3211. Triple-DES key wrap received significant peer review.
>[etc]

See my private reply.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1ELZkx26104 for ietf-smime-bks; Thu, 14 Feb 2002 13:35:46 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id g1ELZU326078 for <[e-mail]>; Thu, 14 Feb 2002 13:35:30 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 14 Feb 2002 21:34:55 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA26778 for <[e-mail]>; Thu, 14 Feb 2002 16:35:23 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g1ELZMl02130 for <[e-mail]>; Thu, 14 Feb 2002 16:35:22 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <19KG7QHW>; Thu, 14 Feb 2002 15:54:21 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.38]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 19KG7QHV; Thu, 14 Feb 2002 15:54:17 -0500
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 14 Feb 2002 16:32:49 -0500
Subject: draft-ietf-smime-rfc2632bis-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Blake:

I have some comments on rfc2632bis-00.  I did not expect to have so many, 
but here we go...

Section 1, 1st paragraph. Son-of-2459, which should be reference [KEYM], 
does not include algorithm specifics any more.  They were moved to a 
separate document.  You should also reference it: 
draft-ietf-pkix-ipki-pkalgs-05.txt.

Section 1, 2nd paragraph. You should reference [CMSALG] as well as [CMS].

Section 1.1, Attribute Certificate (AC) definition.  Please reference 
draft-ietf-pkix-ac509prof-09.txt.  This document is in the RFC Editor 
queue, and it will get a number soon.  It depends on Son-of-2459, which is 
also in the RFC Editor queue.

Section 2.1, 1st paragraph.  I would like to begin ithe: "Receiving agents 
MUST support PKIX v1 and PKIX v2 CRLs."

Section 2.1, last paragraph.  I agree with the statements, but I think the 
whole paragraph belongs in a section on certificates.  Perhaps is belongs 
in section 2.3.

Section 2.2, 1st paragraph, last sentence.  This references section 
3.1.  There is not a section 3.1.  Should it reference section 3 or 
something else?

Section 2.2, last paragraph.  Please change it to: "Receiving agents SHOULD 
support X.509 version 2 attribute certificates [PKIXAC]."

Section 2.2.1, only paragraph.  rfc2630bis supports three types of 
certificates: PKIX, PKCS #6 Extended Certificates, version 1 Attribute 
Certificates, and version 2 Attribute Certificates.  The version 1 
Attribute Certificates are obsolete, and they were not widely 
implemented.  The paragraph needs to say that PKCS #6 Extended Certificates 
and version 1 Attribute Certificates MUST NOT be used.

Section 2.3, 4th paragraph.  Please change "Also note that in the case of 
DSA certificates the parameters may..." to "Also, when certificates 
containing DSA public keys, the parameters may..."

Section 2.3, 4th paragraph.  Please delete "but are not currently 
recommended."  In my opinion, the use of subjectKeyIdentifier and 
authorityKeyIdentifer is recommended.  However, support of chain building 
based on distinguished names is the required technique.

Section 2.3, last paragraph.  Please add "version 2" before "attribute 
certificates."

Section 2.3, last paragraph.  Please add a reference to 
draft-ietf-smime-seclabel-04.txt.  I suggest replacing the last sentence 
with:  "All other issues regarding the generation and use of X.509 version 
2 attribute certificates are outside of the scope of this specification; 
however, [SECLABEL] offers guidance on one use." This document is in the 
RFC Editor queue, so including this reference will not delay progression of 
this document.

Section 3, 2nd paragraph.  Please add a reference for the PKCS#9 
emailAddress attribute.

Section 4.1, 1st paragraph.  Please change "certificate-revocation list" to 
"certificate revocation list" in three places.

Section 4.1, 2nd paragraph.  Please change "certificate chain" to 
"certification path."

Section 4.1, 2nd paragraph.  Please change "draft" to "specification."

Section 4.1, 2nd paragraph.  Please change "... with particular certificate 
hierarchies" to "... with particular certification paths."

Section 4.2, whole.  Please change "certificate chain" to "certification 
path" in many places, including the section title.  In two places, toward 
the end of the 2nd paragraph, also replace "chain" with "certification path."

Section 4.3, 1st paragraph.  Please change "certificate-revocation list" to 
"certificate revocation list."

Section 4.3, 2nd paragraph.  Please replace the paragraph with the 
following:  "A receiving agent MUST be capable of verifying the signatures 
on certificates and CRLs made with sha-1WithRSAEncryption signature 
algorithms, using key sizes from 512 bits to 2048 bits, as described in 
[CMSALG].  A receiving agent SHOULD be capable of verifying the signatures on
certificates and CRLs made with md2WithRSAEncryption and 
md5WithRSAEncryption signature algorithms, using key sizes from 512 bits to 
2048 bits, as described in [CMSALG]."

Section 4.4, 2nd paragraph.  Please replace the paragraph with the 
following:  "Sending and receiving agents MUST correctly handle the basic 
constraints, key usage, authority key identifier, subject key identifier, 
and subject alternative names certificate extensions when they appear in 
end-entity certificates. Some mechanism SHOULD exist to gracefully handle 
other certificate extensions when they appear in end-entity or CA certificates.

Section 4.4.1, 1st paragraph.  Please change "chain of certificates" to 
"certification path."

Section 4.4.2, 2nd paragraph.  Please change "end user certs" to 
"certificates."  The extension does not distinguish between the signing of 
subordinate CA certificates or end-entity certificates.

Section 4.4.2, last paragraph.  Son-of-2459 says: "When this extension 
appears, it SHOULD be marked critical."  Why do we change this to MUST?

Section 5, last paragraph.  Please delete "[TBD] -- PKCS #1 v1.5 
warnings?"  I do not believe that this is an issue for this document.  RSA 
PKCS#1 v1.5 and RSA OAEP use the same public key, so the million message 
attack issue is properly handled in rfc2633bis.

References.  Please update [KEYM] to reference 
draft-ietf-pkix-new-part1-12.txt.  This document is now in the RFC Editor 
queue, so it will get a number soon.

References.  Please update [CMS] to reference rfc2630bis.  The IESG 
discussed this document last week, and only editorial issues were 
raised.  I hope it will transition to the RFC Editor queue very soon.

References.  Please add draft-ietf-pkix-ac509prof-09.txt, with a tag of 
[PKIXAC].  This document is now in the RFC Editor queue, so it will get a 
number soon.

References.  Please add draft-ietf-smime-seclabel-04.txt., with a tag of 
[SECLABEL].  This document is now in the RFC Editor queue, so it will get a 
number soon.

Enjoy the Olympics,
   Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CLJju15865 for ietf-smime-bks; Tue, 12 Feb 2002 13:19:45 -0800 (PST)
Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CLJi315861 for <[e-mail]>; Tue, 12 Feb 2002 13:19:44 -0800 (PST)
Received: from revelation ([12.230.157.165]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020212211942.YUXF2951.rwcrmhc53.attbi.com@revelation>; Tue, 12 Feb 2002 21:19:42 +0000
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Peter Gutmann'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
Date: Tue, 12 Feb 2002 13:18:20 -0800
Message-ID: <001f01c1b40a$cbb2cd50$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

Sorry about taking so long to reply, but between the Olympics and
getting a house built I have running short on time.

It is true that the wrapping algorithm in RFC 3211 exists and could be
used for the HMAC wrapping process.  However the pure Triple-DES wrap
algorithm was required to implement CMS, and it is still a required
algorithm for impliementing Diffie-Hellman key management in the cmsalg.
Given that it is a required algorithm, it seems to be a good base to
expand on.

The AES key wrap algorithm is currently on track to become the standard
key wrap algorithm for use with AES.  Again, given that it is expected
to be the standard algorithm, it seems to be a good base to expand on.

I personally have some security reservations about the key wrap
algorithm given in RFC 3211. Triple-DES key wrap received significant
peer review.   You may recall that Burt Kaliski found a flaw with the
algorithm that was originally proposed.  The Triple-DES key wrap was the
result of about six months of discussion with many people in the crypto
community.  I have seen numerous comments since it was published that
people don't like it for aestetic reasons, but nobody has attacked it on
security reasons.  The AES key wrap algorithm was put out by NIST and
they have had a good track record of publishing secure algorithms.

I would like to hear of more security review on the the algorithm in RFC
3211 before I made any strong ties to it.  I would actually be more
inclined to use the AES key wrap algorithm as a base for a general
algorithm that that in RFC 3211.


Jim


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Peter Gutmann
> Sent: Thursday, February 07, 2002 8:08 PM
> To: [e-mail]
> Subject: 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.
> 



Received: by above.proper.com (8.11.6/8.11.3) id g1CL0P015487 for ietf-smime-bks; Tue, 12 Feb 2002 13:00:25 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id g1CL0N315483 for <[e-mail]>; Tue, 12 Feb 2002 13:00:23 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 12 Feb 2002 20:59:49 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA29823; Tue, 12 Feb 2002 16:00:25 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g1CL0NA06252; Tue, 12 Feb 2002 16:00:23 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <1T31N82K>; Tue, 12 Feb 2002 15:58:06 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.115]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1T31N822; Tue, 12 Feb 2002 15:58:02 -0500
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 12 Feb 2002 16:00:12 -0500
Subject: Re: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
In-Reply-To: <A7896A2B763AD511B27C00AA00DD9371B093E0@niagara>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Francois:

The document describes how to use the NIST AES Key Wrap algorithm to 
encrypt an HMAC key.  The NIST algorithm requires an input that is a 
multiple of 64-bits.  The document describes the mechanism to pad the HMAC 
key prior to encryption and remove the pad after decryption.

Russ

At 02:55 PM 2/12/2002 -0500, [e-mail] wrote:
>Hi Russ,
>
>Sorry I am not registered on the S/MIME mailing list, but feel free to
>distribute your answer.
>
>If I am not mistaken, it is my understanding that the AES Key Wrap Algorithm
>from NIST can be used to wrap any key data and not just another AES key.
>This is also consistent with section 2 of
>draft-ietf-smime-aes-keywrap-00.txt.  This implies that you would certainly
>not need this new proposed Internet Draft for wrapping an HMAC key with an
>AES key.
>
>Regards,
>
>Francois
>---------------------------------
>Francois Rousseau
>IT Standards, Senior Advisor - CSE
>Conseiller Superieur, Normes TI - CST
>[e-mail]
>[phone]
>Edward Drake Building
>1500 Bronson, Ottawa, Ontario, K1G 3Z4


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CKktr15217 for ietf-smime-bks; Tue, 12 Feb 2002 12:46:55 -0800 (PST)
Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CKks315213 for <[e-mail]>; Tue, 12 Feb 2002 12:46:54 -0800 (PST)
Received: from revelation ([12.230.157.165]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020212204651.XXNR2951.rwcrmhc53.attbi.com@revelation>; Tue, 12 Feb 2002 20:46:51 +0000
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: WG Last Call: draft-ietf-smime-aes-keywrap-00.txt
Date: Tue, 12 Feb 2002 12:45:29 -0800
Message-ID: <001e01c1b406$35113c50$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

> 
> Russ,
> 
> I'm just wondering why these two -00 drafts, which don't seem to 
> have much to do with the smime wg (e.g. they don't reference any 
> other wg document), are being processed this way. Did I sleep for
> a bit at the last meeting and miss the explanation?

An additional note on the aes-keywrap draft.  This is a republish of a
document which is currently on the NIST web site, but not in a final
form.  They don't expect it to be final for a while and the AES draft
needs to have the key wrap document to proceed.

> 
> My only possibly useful comment (not being able to review 48 
> pages including binary samples in the time alloted) is that 
> it'd be nice to allocate URIs for these wrapping algorithms 
> as well as OIDs. Or did you expect the W3C XML Encryption 
> group should do that? (Hope I don't cause some sort of process 
> hell by suggesting that one rfc contain both the OIDs and 
> URIs:-).

While I don't have a problem with this, I too can see the advantages,
the W3C is where the URIs are being standardized.  If they want to give
use the URIs, I would consider including these as part of the last call
comments.

> 
> Regards,
> Stephen.
> 

Jim



Received: by above.proper.com (8.11.6/8.11.3) id g1CC3km26058 for ietf-smime-bks; Tue, 12 Feb 2002 04:03:46 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CC3i326051 for <[e-mail]>; Tue, 12 Feb 2002 04:03:44 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08724; Tue, 12 Feb 2002 07:03:34 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt
Date: Tue, 12 Feb 2002 07:03:33 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: S/MIME Version 3.1 Certificate Handling
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-rfc2632bis-00.txt
	Pages		: 
	Date		: 11-Feb-02
	
S/MIME (Secure/Multipurpose Internet Mail Extensions), described in
[SMIME-MSG], provides a method to send and receive secure MIME
messages. Before using a public key to provide security services, the
S/MIME agent MUST certify that the public key is valid. S/MIME agents
MUST use PKIX certificates to validate public keys as described in the
Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL
Profile [KEYM]. S/MIME agents MUST meet the certificate processing
requirements documented in this document in addition to those stated
in [KEYM].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2632bis-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-rfc2632bis-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-rfc2632bis-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-rfc2632bis-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-rfc2632bis-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1CC3fR26049 for ietf-smime-bks; Tue, 12 Feb 2002 04:03:41 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1CC3d326044 for <[e-mail]>; Tue, 12 Feb 2002 04:03:39 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08752; Tue, 12 Feb 2002 07:03:38 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-rfc2633bis-00.txt
Date: Tue, 12 Feb 2002 07:03:38 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: S/MIME Version 3.1 Message Specification
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-rfc2633bis-00.txt
	Pages		: 
	Date		: 11-Feb-02
	
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
consistent way to send and receive secure MIME data. Based on the
popular Internet MIME standard, S/MIME provides the following
cryptographic security services for electronic messaging applications:
authentication, message integrity and non-repudiation of origin (using
digital signatures) and privacy and data security (using encryption).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2633bis-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-rfc2633bis-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-rfc2633bis-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-rfc2633bis-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-rfc2633bis-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1BI1iO03387 for ietf-smime-bks; Mon, 11 Feb 2002 10:01:44 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id g1BI1g303383 for <[e-mail]>; Mon, 11 Feb 2002 10:01:42 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Feb 2002 18:01:07 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA18537 for <[e-mail]>; Mon, 11 Feb 2002 13:01:43 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g1BI1g923879 for <[e-mail]>; Mon, 11 Feb 2002 13:01:42 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <1T31NKC9>; Mon, 11 Feb 2002 12:59:25 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.48]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1T31NKC6; Mon, 11 Feb 2002 12:59:21 -0500
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 11 Feb 2002 13:01:20 -0500
Subject: Re: WG Last Call: draft-ietf-smime-aes-keywrap-00.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve:

They were discussed in the presentation made by Jim Schaad on supporting 
AES in CMS.

The AES key wrap is needed when Diffie-Hellman key agreement (see RFC 2631) 
is used to generate a pairwise key-encryption key, then the key-encryption 
key is used to wrap the content-encryption key.

Russ


At 03:23 PM 2/11/2002 +0000, Stephen Farrell wrote:

>Russ,
>
>I'm just wondering why these two -00 drafts, which don't seem to
>have much to do with the smime wg (e.g. they don't reference any
>other wg document), are being processed this way. Did I sleep for
>a bit at the last meeting and miss the explanation?
>
>My only possibly useful comment (not being able to review 48
>pages including binary samples in the time alloted) is that
>it'd be nice to allocate URIs for these wrapping algorithms
>as well as OIDs. Or did you expect the W3C XML Encryption
>group should do that? (Hope I don't cause some sort of process
>hell by suggesting that one rfc contain both the OIDs and
>URIs:-).
>
>Regards,
>Stephen.
>
>"Housley, Russ" wrote:
> >
> > 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 [e-mail]
> > 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
>
>--
>____________________________________________________________
>Stephen Farrell
>Baltimore Technologies,   tel: (direct line) [phone]
>39 Parkgate Street,                     fax: [phone]
>Dublin 8.                mailto:[e-mail]
>Ireland                             http://www.baltimore.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1BFPia25075 for ietf-smime-bks; Mon, 11 Feb 2002 07:25:44 -0800 (PST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1BFPf325067 for <[e-mail]>; Mon, 11 Feb 2002 07:25:42 -0800 (PST)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g1BFPcU08279 for <[e-mail]>; Mon, 11 Feb 2002 15:25:38 GMT
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Mon, 11 Feb 2002 15:20:56 +0000
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA09948; Mon, 11 Feb 2002 15:25:35 GMT
Message-ID: <[e-mail]>
Date: Mon, 11 Feb 2002 15:23:24 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: draft-ietf-smime-aes-keywrap-00.txt
References: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

I'm just wondering why these two -00 drafts, which don't seem to 
have much to do with the smime wg (e.g. they don't reference any 
other wg document), are being processed this way. Did I sleep for
a bit at the last meeting and miss the explanation?

My only possibly useful comment (not being able to review 48 
pages including binary samples in the time alloted) is that 
it'd be nice to allocate URIs for these wrapping algorithms 
as well as OIDs. Or did you expect the W3C XML Encryption 
group should do that? (Hope I don't cause some sort of process 
hell by suggesting that one rfc contain both the OIDs and 
URIs:-).

Regards,
Stephen.

"Housley, Russ" wrote:
> 
> 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 [e-mail]
> 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

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: by above.proper.com (8.11.6/8.11.3) id g18IBrS14917 for ietf-smime-bks; Fri, 8 Feb 2002 10:11:53 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18IBn314904 for <[e-mail]>; Fri, 8 Feb 2002 10:11:50 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id HAA09900; Sat, 9 Feb 2002 07:11:35 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id HAA141066; Sat, 9 Feb 2002 07:11:35 +1300 (NZDT) (sender [e-mail])
Date: Sat, 9 Feb 2002 07:11:35 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Housley, Russ" <[e-mail]> writes:

>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.

I pointed out when the meeting minutes were posted to the list that this was
unnecessary because it's already provided for in PWRI.  I also pointed out that
I'd been wrapping HMAC keys using 3DES for several years using the PWRI wrap
mechanism.  PWRI defines a universal wrap mechanism which will wrap any key in
any other key, which eliminates the need for creating further special-case
RFCs.  A single implementation of PWRI will wrap anything in anything else, so
you don't have to keep rewriting your code every time a new key wrap RFC
appears.

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g18Hf5r14133 for ietf-smime-bks; Fri, 8 Feb 2002 09:41:05 -0800 (PST)
Received: from romeo.rtfm.com ([198.144.203.242]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18Hf4314127 for <[e-mail]>; Fri, 8 Feb 2002 09:41:04 -0800 (PST)
Received: (ekr@localhost) by romeo.rtfm.com (8.11.3/8.6.4) id g18HfOw04480; Fri, 8 Feb 2002 09:41:24 -0800 (PST)
To: [e-mail] (Peter Gutmann)
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
References: <[e-mail]>
Reply-to: EKR <[e-mail]>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Eric Rescorla <[e-mail]>
Date: 08 Feb 2002 09:41:24 -0800
In-Reply-To: [e-mail]'s message of "Fri, 8 Feb 2002 17:07:35 +1300 (NZDT)"
Message-ID: <[e-mail]>
Lines: 23
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] (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                                   [e-mail]]
                http://www.rtfm.com/


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18HK3Z13581 for ietf-smime-bks; Fri, 8 Feb 2002 09:20:03 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id g18HK2313577 for <[e-mail]>; Fri, 8 Feb 2002 09:20:02 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 8 Feb 2002 17:19:28 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA01239 for <[e-mail]>; Fri, 8 Feb 2002 12:20:03 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g18HK2i06820 for <[e-mail]>; Fri, 8 Feb 2002 12:20:02 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <DTB67CGX>; Fri, 8 Feb 2002 12:20:01 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.116]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DTB67CGR; Fri, 8 Feb 2002 12:19:54 -0500
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 08 Feb 2002 12:06:27 -0500
Subject: Re: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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
>kind?  This draft seems entirely superfluous, since a standards-track RFC
>containing an algorithm which does what's in the draft already exists.
>
>Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18GkLe12818 for ietf-smime-bks; Fri, 8 Feb 2002 08:46:21 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g18GkI312814 for <[e-mail]>; Fri, 8 Feb 2002 08:46:19 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id FAA08581; Sat, 9 Feb 2002 05:46:09 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id FAA139870; Sat, 9 Feb 2002 05:46:09 +1300 (NZDT) (sender [e-mail])
Date: Sat, 9 Feb 2002 05:46:09 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  WG Last Call: draft-ietf-smime-hmac-key-wrap-00.txt
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Housley, Russ" <[e-mail]> writes:

>Please review hmac-key-wrap, and post any comments to the [e-mail]
>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.


Received: by above.proper.com (8.11.6/8.11.3) id g18FZWl11013 for ietf-smime-bks; Fri, 8 Feb 2002 07:35:32 -0800 (PST)
Received: from gonzo.aus.rsa.com (mail.rsasecurity.com.au [203.46.112.10]) by above.proper.com (8.11.6/8.11.3) with SMTP id g18FZU311009 for <[e-mail]>; Fri, 8 Feb 2002 07:35:30 -0800 (PST)
Received: from checkpoint.local.aus.rsa.com by gonzo.aus.rsa.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 8 Feb 2002 15:35:38 UT
Received: from exaus01.local.aus.rsa.com (exaus01.local.aus.rsa.com [10.177.1.15]) by grover.local.aus.rsa.com (8.10.2/8.10.2) with ESMTP id g18Fdvq25691 for <[e-mail]>; Sat, 9 Feb 2002 01:39:57 +1000 (EST)
Received: by exaus01.local.aus.rsa.com with Internet Mail Service (5.5.2653.19) id <13VSCQB7>; Sat, 9 Feb 2002 01:34:53 +1000
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.45]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DTB67BA4; Fri, 8 Feb 2002 10:35:21 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 08 Feb 2002 10:31:00 -0500
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: WG Last Call: draft-ietf-smime-hmac-key-wrap-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 
[e-mail] 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 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g18FPxe10711 for ietf-smime-bks; Fri, 8 Feb 2002 07:25:59 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id g18FPv310706 for <[e-mail]>; Fri, 8 Feb 2002 07:25:57 -0800 (PST)
Received: from sdtihq24.securid.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 8 Feb 2002 15:25:22 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA22657 for <[e-mail]>; Fri, 8 Feb 2002 10:25:58 -0500 (EST)
Received: from exno02.dynas.se (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g18FPub26818 for <[e-mail]>; Fri, 8 Feb 2002 10:25:56 -0500 (EST)
Received: by exno02.dynas.se with Internet Mail Service (5.5.2653.19) id <V47AHJ9L>; Fri, 8 Feb 2002 16:25:41 +0100
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.45]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DTB67A8Z; Fri, 8 Feb 2002 10:25:49 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 08 Feb 2002 10:23:41 -0500
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: WG Last Call: draft-ietf-smime-aes-keywrap-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 [e-mail] 
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


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1847gt14835 for ietf-smime-bks; Thu, 7 Feb 2002 20:07:42 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1847d314831 for <[e-mail]>; Thu, 7 Feb 2002 20:07:39 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id RAA28736 for <[e-mail]>; Fri, 8 Feb 2002 17:07:36 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id RAA125988 for [e-mail]; Fri, 8 Feb 2002 17:07:35 +1300 (NZDT) (sender [e-mail])
Date: Fri, 8 Feb 2002 17:07:35 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>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.


Received: by above.proper.com (8.11.6/8.11.3) id g17INoc27368 for ietf-smime-bks; Thu, 7 Feb 2002 10:23:50 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17INl327363 for <[e-mail]>; Thu, 7 Feb 2002 10:23:47 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04740; Thu, 7 Feb 2002 13:23:47 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
Date: Thu, 07 Feb 2002 13:23:47 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	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
	Pages		: 8
	Date		: 06-Feb-02
	
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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-hmac-key-wrap-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-hmac-key-wrap-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-hmac-key-wrap-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-hmac-key-wrap-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-hmac-key-wrap-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g17INgL27360 for ietf-smime-bks; Thu, 7 Feb 2002 10:23:42 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17INd327355 for <[e-mail]>; Thu, 7 Feb 2002 10:23:39 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04724; Thu, 7 Feb 2002 13:23:39 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-aes-alg-04.txt
Date: Thu, 07 Feb 2002 13:23:38 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Use of the AES Encryption Algorithm and RSA-OAEP Key 
                          Transport in CMS
	Author(s)	: J. Schaad, R. Housley
	Filename	: draft-ietf-smime-aes-alg-04.txt
	Pages		: 16
	Date		: 06-Feb-02
	
This document specifies the conventions for using the Advanced 
Encryption Standard (AES) algorithm [AES] for encryption and the 
RSAES-OAEP key transport method [PKCS#1v2.0] for key management with 
the Cryptographic Message Syntax (CMS) [CMS].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-aes-alg-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-aes-alg-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-aes-alg-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-aes-alg-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-aes-alg-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id g17INZR27349 for ietf-smime-bks; Thu, 7 Feb 2002 10:23:35 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g17INX327345 for <[e-mail]>; Thu, 7 Feb 2002 10:23:34 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04707; Thu, 7 Feb 2002 13:23:33 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-aes-keywrap-00.txt
Date: Thu, 07 Feb 2002 13:23:33 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: AES Key Wrap Algorithm
	Author(s)	: J. Schaad, R. Housley
	Filename	: draft-ietf-smime-aes-keywrap-00.txt
	Pages		: 36
	Date		: 06-Feb-02
	
The purpose of this document is to make the AES Key Wrap algorithm 
conveniently available to the Internet community.  The United States 
of America has adopted AES as the new encryption standard.  The AES 
Key Wrap algorithm will probably be adopted by the USA for 
encryption of AES keys.  The authors took most of the text in this 
document from the draft AES Key Wrap posted by NIST.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-aes-keywrap-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-aes-keywrap-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-aes-keywrap-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-aes-keywrap-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-aes-keywrap-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15NVAx16865 for ietf-smime-bks; Tue, 5 Feb 2002 15:31:10 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15NV8316860 for <[e-mail]>; Tue, 5 Feb 2002 15:31:08 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23674; Tue, 5 Feb 2002 18:31:05 -0500 (EST)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>
Cc: [e-mail]
From: The IESG <[e-mail]>
Subject: Document Action: Use of ECC Algorithms in CMS to Informational
Date: Tue, 05 Feb 2002 18:31:05 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15NHbb16009 for ietf-smime-bks; Tue, 5 Feb 2002 15:17:37 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15NHa316005 for <[e-mail]>; Tue, 5 Feb 2002 15:17:36 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23108; Tue, 5 Feb 2002 18:17:34 -0500 (EST)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>
Cc: [e-mail]
From: The IESG <[e-mail]>
Subject: Document Action: Use of ECC Algorithms in CMS to Proposed Standard
Date: Tue, 05 Feb 2002 18:17:33 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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.




Received: by above.proper.com (8.11.6/8.11.3) id g15M1MJ11233 for ietf-smime-bks; Tue, 5 Feb 2002 14:01:22 -0800 (PST)
Received: from gonzo.aus.rsa.com (mail.rsasecurity.com.au [203.46.112.10]) by above.proper.com (8.11.6/8.11.3) with SMTP id g15M1J311229 for <[e-mail]>; Tue, 5 Feb 2002 14:01:19 -0800 (PST)
Received: from checkpoint.local.aus.rsa.com by gonzo.aus.rsa.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 5 Feb 2002 22:01:28 UT
Received: from exaus01.local.aus.rsa.com (exaus01.local.aus.rsa.com [10.177.1.15]) by grover.local.aus.rsa.com (8.10.2/8.10.2) with ESMTP id g15M5Uq11661 for <[e-mail]>; Wed, 6 Feb 2002 08:05:30 +1000 (EST)
Received: by exaus01.local.aus.rsa.com with Internet Mail Service (5.5.2653.19) id <1BJH1RRS>; Wed, 6 Feb 2002 07:58:24 +1000
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.65]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DTB65YPD; Tue, 5 Feb 2002 17:00:49 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 05 Feb 2002 14:55:13 -0500
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: 53rd IETF Agenda Topics
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g15FRmJ24746 for ietf-smime-bks; Tue, 5 Feb 2002 07:27:48 -0800 (PST)
Received: from tube.clearswift.com (tube.clearswift.com [195.153.60.158]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g15FRk324740 for <[e-mail]>; Tue, 5 Feb 2002 07:27:46 -0800 (PST)
Received: from orange.net-tel.co.uk (orange.net-tel.co.uk [193.122.171.1]) by tube.clearswift.com (4.6.0.87) with ESMTP id ; Tue, 05 Feb 2002 15:25:00 GMT
Received: from "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/" by orange.net-tel.co.uk (Route400-RFCGate); Tue,  5 Feb 2002 15:29:03 +0000
X400-Received: by mta "net-tel" in "/PRMD=net-tel/ADMD=gold 400/C=gb/";  Relayed; Tue,  5 Feb 2002 15:29:03 +0000
X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed;  Tue,  5 Feb 2002 15:29:03 +0000
X400-MTS-Identifier:  ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";ORANGE:0057-020205152903-0294]
X400-Content-Type: P2-1988 (22)
X400-Originator: [e-mail]
Original-Encoded-Information-Types: IA5-Text
X400-Recipients: non-disclosure:;
Date: Tue,  5 Feb 2002 15:29:03 +0000
X400-Content-Identifier: Re(2): MIXER Imp
Message-Id: <"BARNOUIC:0634-020205152654-0002*/G=Jim/S=Craigie/O=Net-Tel Computer Systems Ltd/PRMD=Net-Tel/ADMD=Gold 400/C=GB/"@MHS>
From: Jim Craigie <[e-mail]>
To: "Bonatti, Chris" <[e-mail]>
Cc: IETF SMIME WG <[e-mail]>
References: <[e-mail]>
Subject: Re(2): MIXER Impact on CMS-X400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris,

It seems we agree about almost everything except discussing compatability with STANAG 4406 PCT. I'm surprised by your response on this, since I had assumed that such compatability was an unstated goal of your drafts. If compatability is accidental, it is fortuitous! But even so, I don't really see why you don't want to acknowledge it. Whether or not IETF is mightier than NATO is irrelevant. NATO published three years ago, and there are now implementations of PCT in the market. Therefore, you should be discussing compatability with existing product implementations.

Detailed comments embedded below.

Jim

> 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 
> <[e-mail]> 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 default behavior that we 
> desire (i.e., leave the content alone) is not made an option in MIXER.  
> This probably wouldn't be a problem in the X.400-to-SMTP direction, but 
> for SMTP-to-X.400 it would probably result in a HARPOON encapsulation 
> being performed.  This would be unfortunate, because it would yield 
> multiple behaviors for receiving UAs in the X.400 world to consider.

In the X.400-to-SMTP direction a MIXER gateway could quite legitimately reject (i.e. non-deliver) any content-type other than IPMS.

> 
> > 
> > X400wrap fails to mention that when the objects it defines 
> > are transported over SMTP transport there will of 
> > necessity for conformance to RFC 2822 be a vestigial 
> > Header. This will comprise at a minimum the mandatory 
> > Header fields specified in RFC 2822: "From:" and "Date:". 
> > If it is intended that these fields (which duplicate 
> > semantics already contained within the X.400 content 
> > within the wrapped object, but are not derived from them) 
> > are to be ignored on reception then this must be stated 
> > explicitly. If this is the case, then the values in these 
> > fields on origination can be arbitrary. Given this 
> > additional specification, gatewaying of the x400wrap 
> > content is straightforward, but does need to be specified.
> 
>   I somehow thought this had been dealt with (it was certainly 
> discussed), but I see that it is absent in the document.  I agree that 
> it needs to be considered.
> 
> > 
> > Neither your drafts (quite reasonably) nor any other RFC 
> > that I can find specifies how an X.400 content (without 
> > CMS protection) can be conveyed by SMTP transport. For 
> > completeness, could this be included in x400wrap? I propose:
> > 
> > Content-Type: application/x400-content; content-type = 
> > 1*DIGIT *( "." 1*DIGIT)
> > where the content-type parmeter value is either a single 
> > integer (for a built-in content-type) or an OID in dotted 
> > notation (for an extended content-type).
> > 
> > Either your drafts or a separate addendum to MIXER can 
> > then specify simple gatewaying rules at the message 
> > transport level for any X.400 content-type, defaulting to 
> > the above for a content-type for which no other mapping is defined.
> 
>   This seems okay to me.  I can see that if a UA is going to sometimes 
> send CMS-protected X.400 content, it is reasonable to guess that it's 
> sometimes going to send unprotected X.400 content.  However, I can see 
> how it might be controversial.  At present, we're only considering 
> CMS-encapsulated X.400 content that might ride over SMTP.  A MIXER 
> gateway would probably ignore that combination on the way out of X.400. 
>  If we add this we're recognizing that *SOME* X.400 messages should be 
> MIXER converted and some not.  How is the gateway to know?  Granted 
> that most gateways are local, so maybe this isn't a serious problem.  I 
> guess we need to elaborate all the permutations of this to see how it 
> shakes out.

I think the mapping rules for the more general X.400 to SMTP gateway need to be along the following lines.

For X.400 to SMTP, apply one of the following according to the X.400 content-type:
- for content-type IPMS (2 or 22), apply MIXER in full.
- for any content-type for which a mapping of the content is defined, apply that mapping [I'm not aware of mappings having been defined for any other content-type, but we shouldn't preclude someone producing a mapping for EDIM, or Military-messaging, or Voice-messaging, or some other content-type].
- for content-type contentInfo, take the X.400 content and apply a MIME transfer encoding (e.g. Base 64) and inserted it into an application/pkcs7-mime MIME entity, setting the smime-type from the EITs (exactly how requires specification), create the vestigial RFC822 Header (section 5.3.2 of RFC2156), and map the X.400 envelope as specified in various parts of RFC2156 (I too thought that it would be easy to specify which part until I looked at the inter-twined tangle of envelope and content in RFC2156). Where the content within the content-info is ultimately an RFC822 message, there will need to be a flag somewhere in the CMS to indicate that the outer Header is to be ignored - otherwise the receiving agent cannot tell whether the entire message is protected, or whether a protected message has been forwarded without further protection.
- for any other content-type, take the X.400 content and apply a MIME transfer encoding (e.g. Base 64) and inserted it into an application/x400-content MIME entity, setting the content-type parameter from the value in the X.400 envelope, and create the vestigial RFC822 Header and SMTP Envelope as for content-type contentInfo. [The alternative to this option is that the gateway rejects the message with a non-delivery report for unsupported content-type, and it would seem bizarre to allow the content-type if protected by CMS but not otherwise.]

For SMTP to X.400:
If the message contains a Header with a single MIME entity:
- if the MIME entity is application/x400-content then strip the MIME transfer encoding and place the result into the X.400 content, setting the content-type from the content-type parameter, and map the Header and SMTP Envelope into the X.400 envelope (as specified in various parts of RFC2156), and discard any remaining Header fields.
- if the MIME entity is application/pkcs7-mime *and* either the smime-type is signed-x400 or enveloped-x400, or for other smime-types the "complete message protected" flag (to be defined) is present, then strip the MIME transfer encoding and place the result into the X.400 content, setting the content-type to contentInfo and the EITs <to be specified>, and map the Header and SMTP Envelope into the X.400 envelope (as specified in various parts of RFC2156)), and discard any remaining Header fields.
- otherwise, apply the full MIXER mapping, but map any application/pkcs7-mime or application/x400-content MIME parts into ForwardedContent body-parts.

> 
> > 
> > 
> > Having reviewed your drafts again, I have several 
> > additional comments.
> > 
> > X400wrap also omits mention of two other documents that it 
> > affects: RFC2632 and STANAG 4406.
> 
>   For RFC 2632, I agree.  See below.
> 
>   As regards, STANAG 4406 - I think that's just a private spec as far 
> as IETF is concerned.  Also see below.
> 
> 
> > 
> > X400wrap omits mention of changes to requirements on 
> > Certificates. It should state that for this content the 
> > following wording replaces the second and third paragraphs 
> > in section 3 of RFC2632:
> > 
> >    Receiving agents MUST recognize X.400 addresses in the 
> > subjectAltName field.
> > 
> >    Sending agents SHOULD make the address in the 
> > Originator or Authorising User
> >    heading field in a wrapped mail message match an X.400 
> > address in the signer's
> >    certificate. Receiving agents MUST check that the 
> > address in the Originator
> >    or Authorising User heading field of a mail message 
> > matches an X.400 address
> >    in the signer's certificate, if X.400 addresses are 
> > present in the
> >    certificate. A receiving agent SHOULD provide some 
> > explicit alternate
> >    processing of the message if this comparison fails, 
> > which may be to
> >    display a message that shows the recipient the addresses in the
> >    certificate or other certificate details.
> > 
> 
>   I think I need to spend some time pondering the implications of this, 
> but I think I might agree.  At the outset, I was thinking that most 
> scenarios would employ an SMTP equivalent to an X.400 address.  
> However, I guess this isn't always the case.  I am a little concerned 
> that we might need to tweak this a little because we'd like the 
> CMS/MIME-over-X.400 configuration to be able to interoperate with 
> S/MIME clients that do not otherwise conform to X400WRAP.

I am proposing the above only when the inner content is an X.400 content type, not when it is RFC822. I thought that adding this to X400WRAP and not to X400TRANSPORT achieved that aim.

> 
> 
> > The combination of X400wrap and X400transport should 
> > address compatability with the PCT format defined in 
> > STANAG 4406 version 3. In particular, PCT defines both a 
> > wrapped and a "clear-signed" encoding of its signature. 
> > The latter is particularly useful as it allows signatures 
> > to be introduced whilst preserving interworking through 
> > backwards compatability with systems that do not 
> > incorporate support for PCT. PCT has a major asset in that 
> > it is an algorithmic mapping between the two encodings: 
> > thus a signature generated for one encoding can be mapped 
> > in transit into the other encoding preserving the 
> > signature of the originator.
> 
>   I strongly disagree with this statement.  PCT is essentially a 
> private adaptation of S/MIME.  It's not standardized in IETF, and I 
> don't think it merits consideration here.  If something needs to be 
> done with PCT, then I think they should handle it in STANAG 4406.  It's 
> really out of scope of IETF.
> 
> > 
> > 
> > Other comments on X400transport:
> > 
> > 1. Section 2.2 first sentence:
> > Replace "a CMS object" by "an entire S/MIME message".
> > Rationale: CMS protection can be applied to objects which 
> > are not S/MIME messages. X.400 message content certainly 
> > would not be the preferred (or even an appropriate) 
> > approach to transporting e.g. a CMS protected Excel 
> > spreadsheet file in an X.400 environment.
> 
>   We tried to avoid calling these objects S/MIME messages, because in 
> this context they might well contain X.400 content (which clearly DOES 
> NOT comply with RFC 2633, hence it's not "S/MIME").  Maybe we can say, 
> "a CMS object containing a complete message".  Does this work?

Yes, I'm happy with that.

> 
>   I would think, btw, that something like an Excel spreadsheet would 
> appear as an attachment within the message.  However, I take the point 
> that we're only talking about messages here; not non-message objects.
> 
> 
> > 
> > 2. Section 2.2
> > I cannot see the purpose of introducing the X.400 
> > content-type for a CMS object covered by an outer MIME 
> > wrapper. It seems to me to introduce an option which adds 
> > no value, since the MIME wrapper can be added or 
> > subtracted as needed (e.g. when gatewaying to SMTP 
> > transport) without affecting the CMS object. Options which 
> > add no value should be avoided!
> 
>   This was not an attempt to add an option, but merely to recognize 
> reality that this variation would occur.  One of the reasons we split 
> this spec was to allow different configurations, such as:
> 
> 	- CMS(MIME)-over-X.400
> 	- CMS(P2)-over-X.400
> 	- CMS(P2)-over-SMTP
> 
>   By separating X400transport, we've expressly allowed the possibility 
> that this MIGHT be used with an off-the-shelf S/MIME agent that 
> provides the content with an wrapper already applied.  In the case 
> where MIME-based S/MIME is just tunneling through an X.400 transport, 
> this makes the most sense.  Rather than stipulate that this must be 
> removed (and where?), we simply indicated an appropriate existing 
> identifier.

The drafts do not clearly specify conformance requirements. If you intend to require reception of an X.400 content protected by CMS over X.400 transport both where the CMS object is covered by an outer MIME wrapper and also where the CMS object is not covered by an outer MIME wrapper, then all receiving systems have to have a layer between the X.400 transport and the X.400 or S/MIME agent to add (or subtract) the MIME wrapper [assuming your S/MIME agent to be inflexible and require (or not) the MIME wrapper}. It seems more straightforward to me to apply this layer if required on the sending side (to remove the MIME wrapper if necessary - though most CMS implementations can be configured not to generate it) so that only one option is sent - the more efficiently encoded one - and all receiving systems add the MIME wrapper if required (though again frequently it won't be required). The need to add a MIME wrapper layer or not then becomes governed by the implementation capabilit!
ies, and can be limited to cases where it is needed rather than having to be part of every implementation.

> 
> 
> > 
> > 3. Section 2.3:
> > Comment 1 applies here too. In addition, while in theory 
> > you could define X.400 content types to make the 
> > assertions in the third and fourth sentences true, they 
> > are untrue in practice. It would be better to be positive 
> > and state that for transporting an entire S/MIME message 
> > an X.400 content is more appropriate than an X.400 
> > body-part (except when forwarding). [I agree with your 
> > proposal to use X.400 content - currently a sound proposal 
> > is spoilt by dubious rationale!]
> 
>   Okay.  I'm always in favor of deleting extraneous rationale.
> 
> > 
> > 4. Section 2.5:
> > The defined mechanism does not seem to supply enough 
> > information on the envelope about a wrapped X.400 content. 
> > I don't see any way to identify the actual X.400 
> > content-type that is inside, nor do I see how to 
> > distinguish signed-x400 from triple-wrapped-x400.
> 
>   I think you misunderstand.  These values need not be exclusive to 
> other EIT definitions.  So you could have the EIT id-eit-envelopedx400, 
> and also EITs from X.420.  Perhaps this could be made clearer in the 
> text.

Well currently x400transport says "Sending agents SHOULD include the appropriate S/MIME EIT OID value." - to me, "the value" is singular. Allowing multiple EIT values, one for each protection type (signed or enveloped) present, and one containing the OID representation of the inner X.400 content-type, certainly provides a solution. I don't immediately see how to map reversably between these multiple EITs and the application/pkcs7-mime "smime-type" parameter, however.

> 
>   As for distinguishing between signed and triple-wrapped, I think it's 
> only necessary to include both the id-eit-envelopedx400 and the 
> id-eit-signedx400 EITs.  The receiving agent would be able to see that 
> it handled both.  Since arbitrary nesting seems to be shaping up as a 
> basic requirement for reception, indicating triple-wrapping per se 
> isn't really necessary.  There was some push-back to suggest that we 
> didn't need signed-x400 and enveloped-x400, and that signed-data and 
> enveloped-data was sufficient.  Personally, I am happier to have the 
> additional types because it provides more information in the event that 
> it is the only EIT.

I agree that there is no need to distinguish triple-wrap from more arbitrary nesting of both signed and encrypted.

> 
> > 
> > Jim
> > 
> > 
> 
> 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g14JBFQ08762 for ietf-smime-bks; Mon, 4 Feb 2002 11:11:15 -0800 (PST)
Received: from Obsidian (pcp794540pcs.nrockv01.md.comcast.net [68.49.88.60]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g14JBD308756 for <[e-mail]>; Mon, 4 Feb 2002 11:11:13 -0800 (PST)
Received: from [127.0.0.1] by Obsidian (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Mon, 4 Feb 2002 14:11:12 -0500
From: "Bonatti, Chris" <[e-mail]>
To: "Jim Craigie" <[e-mail]>
Cc: "IETF SMIME WG" <[e-mail]>
Subject: RE: MIXER Impact on CMS-X400
Date: Mon, 4 Feb 2002 14:11:10 -0500
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-reply-to: <"BARNOUIC:0744-020130140903-0005*/G=Jim/S=Craigie/O=Net-Tel Computer Systems Ltd/PRMD=Net-Tel/ADMD=Gold 400/C=GB/"@MHS>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g14JBE308758
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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 <[e-mail]> 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 default behavior that we desire (i.e., leave the content alone) is not made an option in MIXER.  This probably wouldn't be a problem in the X.400-to-SMTP direction, but for SMTP-to-X.400 it would probably result in a HARPOON encapsulation being performed.  This would be unfortunate, because it would yield multiple behaviors for receiving UAs in the X.400 world to consider.

> 
> X400wrap fails to mention that when the objects it defines 
> are transported over SMTP transport there will of 
> necessity for conformance to RFC 2822 be a vestigial 
> Header. This will comprise at a minimum the mandatory 
> Header fields specified in RFC 2822: "From:" and "Date:". 
> If it is intended that these fields (which duplicate 
> semantics already contained within the X.400 content 
> within the wrapped object, but are not derived from them) 
> are to be ignored on reception then this must be stated 
> explicitly. If this is the case, then the values in these 
> fields on origination can be arbitrary. Given this 
> additional specification, gatewaying of the x400wrap 
> content is straightforward, but does need to be specified.

  I somehow thought this had been dealt with (it was certainly discussed), but I see that it is absent in the document.  I agree that it needs to be considered.

> 
> Neither your drafts (quite reasonably) nor any other RFC 
> that I can find specifies how an X.400 content (without 
> CMS protection) can be conveyed by SMTP transport. For 
> completeness, could this be included in x400wrap? I propose:
> 
> Content-Type: application/x400-content; content-type = 
> 1*DIGIT *( "." 1*DIGIT)
> where the content-type parmeter value is either a single 
> integer (for a built-in content-type) or an OID in dotted 
> notation (for an extended content-type).
> 
> Either your drafts or a separate addendum to MIXER can 
> then specify simple gatewaying rules at the message 
> transport level for any X.400 content-type, defaulting to 
> the above for a content-type for which no other mapping is defined.

  This seems okay to me.  I can see that if a UA is going to sometimes send CMS-protected X.400 content, it is reasonable to guess that it's sometimes going to send unprotected X.400 content.  However, I can see how it might be controversial.  At present, we're only considering CMS-encapsulated X.400 content that might ride over SMTP.  A MIXER gateway would probably ignore that combination on the way out of X.400.  If we add this we're recognizing that *SOME* X.400 messages should be MIXER converted and some not.  How is the gateway to know?  Granted that most gateways are local, so maybe this isn't a serious problem.  I guess we need to elaborate all the permutations of this to see how it shakes out.

> 
> 
> Having reviewed your drafts again, I have several 
> additional comments.
> 
> X400wrap also omits mention of two other documents that it 
> affects: RFC2632 and STANAG 4406.

  For RFC 2632, I agree.  See below.

  As regards, STANAG 4406 - I think that's just a private spec as far as IETF is concerned.  Also see below.


> 
> X400wrap omits mention of changes to requirements on 
> Certificates. It should state that for this content the 
> following wording replaces the second and third paragraphs 
> in section 3 of RFC2632:
> 
>    Receiving agents MUST recognize X.400 addresses in the 
> subjectAltName field.
> 
>    Sending agents SHOULD make the address in the 
> Originator or Authorising User
>    heading field in a wrapped mail message match an X.400 
> address in the signer's
>    certificate. Receiving agents MUST check that the 
> address in the Originator
>    or Authorising User heading field of a mail message 
> matches an X.400 address
>    in the signer's certificate, if X.400 addresses are 
> present in the
>    certificate. A receiving agent SHOULD provide some 
> explicit alternate
>    processing of the message if this comparison fails, 
> which may be to
>    display a message that shows the recipient the addresses in the
>    certificate or other certificate details.
> 

  I think I need to spend some time pondering the implications of this, but I think I might agree.  At the outset, I was thinking that most scenarios would employ an SMTP equivalent to an X.400 address.  However, I guess this isn't always the case.  I am a little concerned that we might need to tweak this a little because we'd like the CMS/MIME-over-X.400 configuration to be able to interoperate with S/MIME clients that do not otherwise conform to X400WRAP.


> The combination of X400wrap and X400transport should 
> address compatability with the PCT format defined in 
> STANAG 4406 version 3. In particular, PCT defines both a 
> wrapped and a "clear-signed" encoding of its signature. 
> The latter is particularly useful as it allows signatures 
> to be introduced whilst preserving interworking through 
> backwards compatability with systems that do not 
> incorporate support for PCT. PCT has a major asset in that 
> it is an algorithmic mapping between the two encodings: 
> thus a signature generated for one encoding can be mapped 
> in transit into the other encoding preserving the 
> signature of the originator.

  I strongly disagree with this statement.  PCT is essentially a private adaptation of S/MIME.  It's not standardized in IETF, and I don't think it merits consideration here.  If something needs to be done with PCT, then I think they should handle it in STANAG 4406.  It's really out of scope of IETF.

> 
> 
> Other comments on X400transport:
> 
> 1. Section 2.2 first sentence:
> Replace "a CMS object" by "an entire S/MIME message".
> Rationale: CMS protection can be applied to objects which 
> are not S/MIME messages. X.400 message content certainly 
> would not be the preferred (or even an appropriate) 
> approach to transporting e.g. a CMS protected Excel 
> spreadsheet file in an X.400 environment.

  We tried to avoid calling these objects S/MIME messages, because in this context they might well contain X.400 content (which clearly DOES NOT comply with RFC 2633, hence it's not "S/MIME").  Maybe we can say, "a CMS object containing a complete message".  Does this work?

  I would think, btw, that something like an Excel spreadsheet would appear as an attachment within the message.  However, I take the point that we're only talking about messages here; not non-message objects.


> 
> 2. Section 2.2
> I cannot see the purpose of introducing the X.400 
> content-type for a CMS object covered by an outer MIME 
> wrapper. It seems to me to introduce an option which adds 
> no value, since the MIME wrapper can be added or 
> subtracted as needed (e.g. when gatewaying to SMTP 
> transport) without affecting the CMS object. Options which 
> add no value should be avoided!

  This was not an attempt to add an option, but merely to recognize reality that this variation would occur.  One of the reasons we split this spec was to allow different configurations, such as:

	- CMS(MIME)-over-X.400
	- CMS(P2)-over-X.400
	- CMS(P2)-over-SMTP

  By separating X400transport, we've expressly allowed the possibility that this MIGHT be used with an off-the-shelf S/MIME agent that provides the content with an wrapper already applied.  In the case where MIME-based S/MIME is just tunneling through an X.400 transport, this makes the most sense.  Rather than stipulate that this must be removed (and where?), we simply indicated an appropriate existing identifier.


> 
> 3. Section 2.3:
> Comment 1 applies here too. In addition, while in theory 
> you could define X.400 content types to make the 
> assertions in the third and fourth sentences true, they 
> are untrue in practice. It would be better to be positive 
> and state that for transporting an entire S/MIME message 
> an X.400 content is more appropriate than an X.400 
> body-part (except when forwarding). [I agree with your 
> proposal to use X.400 content - currently a sound proposal 
> is spoilt by dubious rationale!]

  Okay.  I'm always in favor of deleting extraneous rationale.

> 
> 4. Section 2.5:
> The defined mechanism does not seem to supply enough 
> information on the envelope about a wrapped X.400 content. 
> I don't see any way to identify the actual X.400 
> content-type that is inside, nor do I see how to 
> distinguish signed-x400 from triple-wrapped-x400.

  I think you misunderstand.  These values need not be exclusive to other EIT definitions.  So you could have the EIT id-eit-envelopedx400, and also EITs from X.420.  Perhaps this could be made clearer in the text.

  As for distinguishing between signed and triple-wrapped, I think it's only necessary to include both the id-eit-envelopedx400 and the id-eit-signedx400 EITs.  The receiving agent would be able to see that it handled both.  Since arbitrary nesting seems to be shaping up as a basic requirement for reception, indicating triple-wrapping per se isn't really necessary.  There was some push-back to suggest that we didn't need signed-x400 and enveloped-x400, and that signed-data and enveloped-data was sufficient.  Personally, I am happier to have the additional types because it provides more information in the event that it is the only EIT.

> 
> Jim
> 
>