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

From: [email-masked] (Peter Gutmann)
Date: Sat, 16 Feb 2002 21:08:27 +1300 (NZDT)

"Jim Schaad" <[email-masked]> 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.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 26 Feb 2002 16:39:25 -0800

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Peter Gutmann
> Sent: Saturday, February 16, 2002 12:08 AM
> To: [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
> 
> 
> 

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Peter Gutmann'" <[email-masked]>, <[email-masked]>
Cc: "Russ Housley" <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
Date: Tue, 26 Feb 2002 16:39:25 -0800
Importance: Normal
Sender: [email-masked]

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Peter Gutmann
> Sent: Saturday, February 16, 2002 12:08 AM
> To: [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
> 
> 
> 

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Tue, 26 Feb 2002 16:57:57 -0500
Subject: draft-ietf-smime-rfc2633bis-00.txt
Sender: [email-masked]

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 

From: "Housley, Russ" <[email-masked]>
To: Tony Capel <[email-masked]>
Cc: Terry Harding <[email-masked]>, [email-masked]
Date: Tue, 26 Feb 2002 14:03:23 -0500
Subject: RE: Order of signing and compression operations. 
Sender: [email-masked]

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: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Housley, Russ
> > Sent: February 26, 2002 11:21 AM
> > To: Terry Harding
> > Cc: [email-masked]
> > 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
> >
> >

From: "Housley, Russ" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Date: Tue, 26 Feb 2002 13:04:30 -0500
Subject: S/MIME WG Finished: draft-ietf-smime-aes-keywrap-00.txt
Sender: [email-masked]

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

From: "Tony Capel" <[email-masked]>
To: "Housley, Russ" <[email-masked]>, "Terry Harding" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Order of signing and compression operations. 
Date: Tue, 26 Feb 2002 13:57:00 -0500
Importance: Normal
Sender: [email-masked]

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: [email-masked]
> [mailto:[email-masked]]On Behalf Of Housley, Russ
> Sent: February 26, 2002 11:21 AM
> To: Terry Harding
> Cc: [email-masked]
> 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
>
>

From: "Housley, Russ" <[email-masked]>
To: Terry Harding <[email-masked]>
Cc: [email-masked]
Date: Tue, 26 Feb 2002 11:20:45 -0500
Subject: Re: Order of signing and compression operations. 
Sender: [email-masked]

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

From: "Ahmed, Zahid" <[email-masked]>
To: [email-masked]
Subject: RE: Order of signing and compression operations. 
Date: Mon, 25 Feb 2002 17:21:10 -0800
Sender: [email-masked]

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:[email-masked]]
Sent: Monday, February 25, 2002 2:25 PM
To: [email-masked]
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:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Monday, February 25, 2002 2:25 PM</FONT>
<BR><FONT SIZE=2>To: [email-masked]</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--

From: "Terry Harding" <[email-masked]>
To: <[email-masked]>
Subject: Order of signing and compression operations. 
Date: Mon, 25 Feb 2002 15:25:04 -0700
Sender: [email-masked]

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

From: "Pawling, John" <[email-masked]>
To: "SMIME WG (E-mail)" <[email-masked]>
Subject: v2.0.1 S/MIME Freeware Library (SFL) Now Available
Date: Mon, 25 Feb 2002 16:39:30 -0500
Sender: [email-masked]

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, [email-masked]
Getronics Government Solutions, LLC
============================================ 

content-class: urn:content-classes:message
Subject: v1.3 R8 Enhanced SNACC Freeware Now Available
Date: Mon, 25 Feb 2002 15:29:03 -0500
From: "Pawling, John" <[email-masked]>
To: "ietf-pkix@imc. org (E-mail)" <[email-masked]>, "SMIME WG (E-mail)" <[email-masked]>
Sender: [email-masked]

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, [email-masked]
Getronics Government Solutions, LLC
===========================================

Date: Mon, 25 Feb 2002 12:03:25 -0500
From: Mike Schiraldi <[email-masked]>
To: [email-masked]
Subject: Email wildcards?
Sender: [email-masked]

--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 [email-masked] may want to use
[email-masked] 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

--HB4mHL4PVvkpZAgW--

Date: Sat, 16 Feb 2002 21:08:27 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
Sender: [email-masked]

See my private reply.

Peter.

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Thu, 14 Feb 2002 16:32:49 -0500
Subject: draft-ietf-smime-rfc2632bis-00.txt
Sender: [email-masked]

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

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Peter Gutmann'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
Date: Tue, 12 Feb 2002 13:18:20 -0800
Importance: Normal
Sender: [email-masked]

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Peter Gutmann
> Sent: Thursday, February 07, 2002 8:08 PM
> To: [email-masked]
> 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.
> 

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Date: Tue, 12 Feb 2002 16:00:12 -0500
Subject: Re: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
Sender: [email-masked]

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, [email-masked] 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
>[email-masked]
>(613) 991-8364
>Edward Drake Building
>1500 Bronson, Ottawa, Ontario, K1G 3Z4

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: RE: WG Last Call: draft-ietf-smime-aes-keywrap-00.txt
Date: Tue, 12 Feb 2002 12:45:29 -0800
Importance: Normal
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt
Date: Tue, 12 Feb 2002 07:03:33 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-rfc2633bis-00.txt
Date: Tue, 12 Feb 2002 07:03:38 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Mon, 11 Feb 2002 13:01:20 -0500
Subject: Re: WG Last Call: draft-ietf-smime-aes-keywrap-00.txt
Sender: [email-masked]

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 [email-masked]
> > 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) +353 1 881 6716
>39 Parkgate Street,                     fax: +353 1 881 7000
>Dublin 8.                mailto:[email-masked]
>Ireland                             http://www.baltimore.com

Date: Mon, 11 Feb 2002 15:23:24 +0000
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: "Housley, Russ" <[email-masked]>
CC: [email-masked]
Subject: Re: WG Last Call: draft-ietf-smime-aes-keywrap-00.txt
Sender: [email-masked]

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 [email-masked]
> 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) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

Date: Sat, 9 Feb 2002 07:11:35 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
Cc: [email-masked]
Sender: [email-masked]

"Housley, Russ" <[email-masked]> 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.

To: [email-masked] (Peter Gutmann)
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
Reply-to: EKR <[email-masked]>
From: Eric Rescorla <[email-masked]>
Date: 08 Feb 2002 09:41:24 -0800
Lines: 23
Sender: [email-masked]

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

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Fri, 08 Feb 2002 12:06:27 -0500
Subject: Re: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
Sender: [email-masked]

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.

Date: Sat, 9 Feb 2002 05:46:09 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re:  WG Last Call: draft-ietf-smime-hmac-key-wrap-00.txt
Sender: [email-masked]

"Housley, Russ" <[email-masked]> writes:

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

Date: Fri, 08 Feb 2002 10:31:00 -0500
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: WG Last Call: draft-ietf-smime-hmac-key-wrap-00.txt
Sender: [email-masked]

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 
[email-masked] 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 

Date: Fri, 08 Feb 2002 10:23:41 -0500
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: WG Last Call: draft-ietf-smime-aes-keywrap-00.txt
Sender: [email-masked]

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 [email-masked] 
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

Date: Fri, 8 Feb 2002 17:07:35 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
Date: Thu, 07 Feb 2002 13:23:47 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-aes-alg-04.txt
Date: Thu, 07 Feb 2002 13:23:38 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-aes-keywrap-00.txt
Date: Thu, 07 Feb 2002 13:23:33 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: Document Action: Use of ECC Algorithms in CMS to Informational
Date: Tue, 05 Feb 2002 18:31:05 -0500
Sender: [email-masked]

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.

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: Document Action: Use of ECC Algorithms in CMS to Proposed Standard
Date: Tue, 05 Feb 2002 18:17:33 -0500
Sender: [email-masked]

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.

Date: Tue, 05 Feb 2002 14:55:13 -0500
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: 53rd IETF Agenda Topics
Sender: [email-masked]

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 

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: [email-masked]
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
From: Jim Craigie <[email-masked]>
To: "Bonatti, Chris" <[email-masked]>
Cc: IETF SMIME WG <[email-masked]>
Subject: Re(2): MIXER Impact on CMS-X400
Sender: [email-masked]

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 
> <[email-masked]> 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

From: "Bonatti, Chris" <[email-masked]>
To: "Jim Craigie" <[email-masked]>
Cc: "IETF SMIME WG" <[email-masked]>
Subject: RE: MIXER Impact on CMS-X400
Date: Mon, 4 Feb 2002 14:11:10 -0500
Importance: Normal
Sender: [email-masked]

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 <[email-masked]> 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