RE: RSA Signature OIDs

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

Russ,

I think this is a good idea.  I also do not know how much this will
really cause errors to occur in existing software.  In the beginning of
testing this was one of the most common mistakes that people made and I
think that most software handles these values in that location.  (I know
that the Microsoft code does because I was constantly making this
mistake and my own code was not telling me that I was in error.)

Jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Housley, Russ
> Sent: Friday, August 31, 2001 11:06 AM
> To: [e-mail]
> Subject: Re: RSA Signature OIDs
> 
> 
> 
> John Pawling and I started two threads on the same topic at 
> almost the same 
> time.  Please discuss this issue on the other thread 
> (Subject: cmsalg-02 
> RSA OID Proposal).
> 
> Russ
> 
> 
> At 12:43 PM 8/31/2001 -0400, Housley, Russ wrote:
> 
> >In a recent message from John Pawling, he made the following 
> observation:
> >
> >>3) Sec 3.2 specifies that the md5WithRSAEncryption or 
> sha1WithRSAEncryption
> >>OID should be used in the signerInfo signatureAlgorithm 
> field instead of the
> >>id-rsaEncryption OID.  I agree with this strategy, but 
> please note that this
> >>is a change from what is specified in RFC 2630.  RFC2630 
> specifies the use
> >>of id-rsaEncryption in the signerInfo signatureAlgorithm 
> field.  Is this
> >>change going to cause backwards compatibility problems with 
> legacy CMS
> >>implementations?
> >
> >I believe that the text in RFC 2630 was some what 
> incomplete.  Notice that 
> >the corresponding section in cmsalg-02 and cmsalg-03 is 
> significantly longer.
> >
> >The approach documented in cmsalg-03 is aligned with the way that 
> >certificates are handles in PKIX.  That is, public keys are 
> identified 
> >with the rsaEncryption OID, and signature values are identified with 
> >either the sha1WithRSAEncryption OID or the md5WithRSAEncryption OID.
> >
> >Is cmsalg-03 documenting the best approach?  WG Last Call on 
> this document 
> >is scheduled to end today.  Since this issue has been raised 
> on the last 
> >day, I will not close WG Last Call until this thread reaches 
> consensus.
> >
> >Russ
> 




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f815xq208259 for ietf-smime-bks; Fri, 31 Aug 2001 22:59:52 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f815xoD08255 for <[e-mail]>; Fri, 31 Aug 2001 22:59:50 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id RAA13661; Sat, 1 Sep 2001 17:59:49 +1200 (NZST) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id RAA25829; Sat, 1 Sep 2001 17:59:49 +1200 (NZST) (sender [e-mail])
Date: Sat, 1 Sep 2001 17:59:49 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: cmsalg-02 RSA OID Proposal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Pawling, John" <[e-mail]> writes:

>RFC2459 specifies the use of the rsaEncryption OID to indicate that an RSA
>public key is present in the subjectPublicKey field of a certificate. RFC2459
>specifies the use of the md5WithRSAEncryption or sha1WithRSAEncryption OID (as
>appropriate) in the certificate signatureAlgorithm field when the RSA (PKCS #1
>v1.5) algorithm is used to sign the certificate.
>
>RFC2630 specifies the use of the rsaEncryption OID in the signedData
>signerInfo signatureAlgorithm field when the RSA (PKCS #1 v1.5) algorithm is
>used as part of the signature generation process.

RFC2459 requires a unified OID because there's only one place to specify both,
the signatureAlgorithm field.  RFC2630 splits this so there's on OID for the
hash algorithm and another for the signature algorithm.  Both usages are
consistent, it doesn't seem a good idea to force RFC2630 into an inconsistent
usage just to make it look like RFC2459.

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f815sXW08218 for ietf-smime-bks; Fri, 31 Aug 2001 22:54:33 -0700 (PDT)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f815sVD08214 for <[e-mail]>; Fri, 31 Aug 2001 22:54:31 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id RAA13549; Sat, 1 Sep 2001 17:54:30 +1200 (NZST) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id RAA25756; Sat, 1 Sep 2001 17:54:29 +1200 (NZST) (sender [e-mail])
Date: Sat, 1 Sep 2001 17:54:29 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  cmsalg-02 RSA OID Proposal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Pawling, John" <[e-mail]> writes:

>RFC2630 CMS, section 12.2.2, specifies the use of the rsaEncryption object
>identifier (OID) in the signedData signerInfo signatureAlgorithm field when
>the RSA (PKCS #1 v1.5) algorithm is used as part of the signature generation
>process.  cmsalg-02, Section 3.2, specifies the use of the
>md5WithRSAEncryption and sha1WithRSAEncryption OID (as appropriate) in the
>signedData signerInfo signatureAlgorithm field (instead of the id-
>rsaEncryption OID). 

Isn't this kind of asking for trouble?  In addition since SignerInfo already
specifies the hash algorithm being used as DigestAlgorithmIdentifiers, why is
there a need to specify it again in the SignatureAlgorithmIdentifier?

>Is this change going to cause backwards compatibility problems with legacy CMS
>implementations?

cryptlib has a many-to-one mapping of OIDs, so this shouldn't be a problem, as
long as there's an RSA in there somewhere it'll identify it as RSA.

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7VNa1Z02198 for ietf-smime-bks; Fri, 31 Aug 2001 16:36:01 -0700 (PDT)
Received: from femail32.sdc1.sfba.home.com (femail32.sdc1.sfba.home.com [24.254.60.22]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7VNa0D02193 for <[e-mail]>; Fri, 31 Aug 2001 16:36:00 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail32.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010831233557.KVAA10302.femail32.sdc1.sfba.home.com@revelation>; Fri, 31 Aug 2001 16:35:57 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, <[e-mail]>
Subject: RE: RSA Signature OIDs
Date: Fri, 31 Aug 2001 16:36:12 -0700
Message-ID: <000f01c13275$b87d8200$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2526.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

I think this is a good idea.  I also do not know how much this will
really cause errors to occur in existing software.  In the beginning of
testing this was one of the most common mistakes that people made and I
think that most software handles these values in that location.  (I know
that the Microsoft code does because I was constantly making this
mistake and my own code was not telling me that I was in error.)

Jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Housley, Russ
> Sent: Friday, August 31, 2001 11:06 AM
> To: [e-mail]
> Subject: Re: RSA Signature OIDs
> 
> 
> 
> John Pawling and I started two threads on the same topic at 
> almost the same 
> time.  Please discuss this issue on the other thread 
> (Subject: cmsalg-02 
> RSA OID Proposal).
> 
> Russ
> 
> 
> At 12:43 PM 8/31/2001 -0400, Housley, Russ wrote:
> 
> >In a recent message from John Pawling, he made the following 
> observation:
> >
> >>3) Sec 3.2 specifies that the md5WithRSAEncryption or 
> sha1WithRSAEncryption
> >>OID should be used in the signerInfo signatureAlgorithm 
> field instead of the
> >>id-rsaEncryption OID.  I agree with this strategy, but 
> please note that this
> >>is a change from what is specified in RFC 2630.  RFC2630 
> specifies the use
> >>of id-rsaEncryption in the signerInfo signatureAlgorithm 
> field.  Is this
> >>change going to cause backwards compatibility problems with 
> legacy CMS
> >>implementations?
> >
> >I believe that the text in RFC 2630 was some what 
> incomplete.  Notice that 
> >the corresponding section in cmsalg-02 and cmsalg-03 is 
> significantly longer.
> >
> >The approach documented in cmsalg-03 is aligned with the way that 
> >certificates are handles in PKIX.  That is, public keys are 
> identified 
> >with the rsaEncryption OID, and signature values are identified with 
> >either the sha1WithRSAEncryption OID or the md5WithRSAEncryption OID.
> >
> >Is cmsalg-03 documenting the best approach?  WG Last Call on 
> this document 
> >is scheduled to end today.  Since this issue has been raised 
> on the last 
> >day, I will not close WG Last Call until this thread reaches 
> consensus.
> >
> >Russ
> 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7VIE1A24446 for ietf-smime-bks; Fri, 31 Aug 2001 11:14:01 -0700 (PDT)
Received: from nebula.x509.com (nebula.x509.com [199.175.150.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7VIDxD24442 for <[e-mail]>; Fri, 31 Aug 2001 11:14:00 -0700 (PDT)
Received: from crack.x509.com (mail.x509.com [199.175.150.1]) by nebula.x509.com (8.11.6/XCERT) with ESMTP id f7VICY601280 for <[e-mail]>; Fri, 31 Aug 2001 11:12:34 -0700 (PDT)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.11.6/XCERT) with ESMTP id f7VICYr16005 for <[e-mail]>; Fri, 31 Aug 2001 11:12:34 -0700 (PDT)
Received: by exvan01.x509.com with Internet Mail Service (5.5.2653.19) id <QDLC7SWR>; Fri, 31 Aug 2001 11:13:49 -0700
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.24]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCT4N7; Fri, 31 Aug 2001 14:05:48 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 31 Aug 2001 14:05:37 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Re: RSA Signature OIDs
In-Reply-To: <[e-mail]. com>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John Pawling and I started two threads on the same topic at almost the same 
time.  Please discuss this issue on the other thread (Subject: cmsalg-02 
RSA OID Proposal).

Russ


At 12:43 PM 8/31/2001 -0400, Housley, Russ wrote:

>In a recent message from John Pawling, he made the following observation:
>
>>3) Sec 3.2 specifies that the md5WithRSAEncryption or sha1WithRSAEncryption
>>OID should be used in the signerInfo signatureAlgorithm field instead of the
>>id-rsaEncryption OID.  I agree with this strategy, but please note that this
>>is a change from what is specified in RFC 2630.  RFC2630 specifies the use
>>of id-rsaEncryption in the signerInfo signatureAlgorithm field.  Is this
>>change going to cause backwards compatibility problems with legacy CMS
>>implementations?
>
>I believe that the text in RFC 2630 was some what incomplete.  Notice that 
>the corresponding section in cmsalg-02 and cmsalg-03 is significantly longer.
>
>The approach documented in cmsalg-03 is aligned with the way that 
>certificates are handles in PKIX.  That is, public keys are identified 
>with the rsaEncryption OID, and signature values are identified with 
>either the sha1WithRSAEncryption OID or the md5WithRSAEncryption OID.
>
>Is cmsalg-03 documenting the best approach?  WG Last Call on this document 
>is scheduled to end today.  Since this issue has been raised on the last 
>day, I will not close WG Last Call until this thread reaches consensus.
>
>Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7VI0LW24145 for ietf-smime-bks; Fri, 31 Aug 2001 11:00:21 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f7VI0JD24139 for <[e-mail]>; Fri, 31 Aug 2001 11:00:19 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 31 Aug 2001 17:57:52 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA25276 for <[e-mail]>; Fri, 31 Aug 2001 13:59:30 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <QTWCT4M4>; Fri, 31 Aug 2001 14:00:20 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.24]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCT4MT; Fri, 31 Aug 2001 14:00:12 -0400
From: "Housley, Russ" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Cc: "SMIME WG (E-mail)" <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 31 Aug 2001 14:00:09 -0400
Subject: RE: cmsalg-02 Comments
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John:

> >6) sec 4.1.2, originator field, please add: "[PROFILE] specifies the
> >AlgorithmIdentifier parameters syntax and values that are populated in the
> >originator's certificate."
>
>Is this correct?  I think that it has been moved to the PKIX Algs document.
>
>[JSP: You are correct.  Please change my comment to use the PKIX Algs
>reference.]

Okay.  Done.

Russ


Received: by above.proper.com (8.11.6/8.11.3) id f7VHoA723868 for ietf-smime-bks; Fri, 31 Aug 2001 10:50:10 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f7VHo8D23864 for <[e-mail]>; Fri, 31 Aug 2001 10:50:08 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 31 Aug 2001 17:47:41 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA24851 for <[e-mail]>; Fri, 31 Aug 2001 13:49:19 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <QTWCT4K2>; Fri, 31 Aug 2001 13:50:09 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.24]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCT4KG; Fri, 31 Aug 2001 13:50:01 -0400
From: "Housley, Russ" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Cc: "SMIME WG (E-mail)" <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 31 Aug 2001 13:14:11 -0400
Subject: RE: cmsalg-02 Comments
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John:

> >3) Sec 3.2 specifies that the md5WithRSAEncryption or sha1WithRSAEncryption
> >OID should be used in the signerInfo signatureAlgorithm field instead of
>the
> >id-rsaEncryption OID.  I agree with this strategy, but please note that
>this
> >is a change from what is specified in RFC 2630.  RFC2630 specifies the use
> >of id-rsaEncryption in the signerInfo signatureAlgorithm field.  Is this
> >change going to cause backwards compatibility problems with legacy CMS
> >implementations?
>
>I want to highlight this point.  As you say, it might be controversial.  I
>will start a thread to discuss this point.
>
>[JSP: I already started a separate thread.]

Me too....

Russ


Received: by above.proper.com (8.11.6/8.11.3) id f7VHdnj23677 for ietf-smime-bks; Fri, 31 Aug 2001 10:39:49 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7VHdmD23673 for <[e-mail]>; Fri, 31 Aug 2001 10:39:48 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <R052VFK1>; Fri, 31 Aug 2001 13:39:58 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: [e-mail]
Subject: RE: RSA Signature OIDs
Date: Fri, 31 Aug 2001 13:39:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

I agree that the cmsalg proposed change would increase the consistency of
the use of the md5WithRSAEncryption, sha1WithRSAEncryption, and
rsaEncryption OIDs in PKIX X.509 certificates and CMS signedData content
types.  However, I don't believe that the increase in consistency would be
worth breaking backwards compatibility with legacy CMS implementations.
Before we make a decision, I believe that we need further input from the
various implementers so that we know the extent to which this change would
break backwards compatibility with legacy CMS implementations.

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


Received: by above.proper.com (8.11.6/8.11.3) id f7VH7ep22771 for ietf-smime-bks; Fri, 31 Aug 2001 10:07:40 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7VH7eD22767 for <[e-mail]>; Fri, 31 Aug 2001 10:07:40 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <R052VFCR>; Fri, 31 Aug 2001 13:07:49 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>
Cc: "SMIME WG (E-mail)" <[e-mail]>
Subject: RE: cmsalg-02 Comments
Date: Fri, 31 Aug 2001 13:07:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

Thank you for your responses to my comments.  I have included some comments
to your responses in-line.  I snipped the stuff that we already agree on.


-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Friday, August 31, 2001 12:54 PM
To: Pawling, John
Cc: SMIME WG (E-mail)
Subject: Re: cmsalg-02 Comments


John:

<snip> 

>3) Sec 3.2 specifies that the md5WithRSAEncryption or sha1WithRSAEncryption
>OID should be used in the signerInfo signatureAlgorithm field instead of
the
>id-rsaEncryption OID.  I agree with this strategy, but please note that
this
>is a change from what is specified in RFC 2630.  RFC2630 specifies the use
>of id-rsaEncryption in the signerInfo signatureAlgorithm field.  Is this
>change going to cause backwards compatibility problems with legacy CMS
>implementations?

I want to highlight this point.  As you say, it might be controversial.  I 
will start a thread to discuss this point.

[JSP: I already started a separate thread.]

<snip>


>5) sec 4.1.2, originator field, please replace:
>
>OLD: "In both cases, the recipient's certificate contains the sender's
>static public key,"
>
>NEW: "In both cases, the originator's certificate contains the originator's
>static public key,"

Good catch.  In PKCS #7, RFC 2630, and rfc2630bis-03, the term "sender" is 
used in much of that narrative description.  Therefore, I prefer:

       originator MUST be either the issuerAndSerialNumber or
       subjectKeyIdentifier alternative.  In both cases, the originator's
       certificate contains the sender's static public key, and the
       certificate subject public key information field MUST contain the
       dh-public-number object identifier:

          dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
              us(840) ansi-x942(10046) number-type(2) 1 }

[JSP: Agree]


>6) sec 4.1.2, originator field, please add: "[PROFILE] specifies the
>AlgorithmIdentifier parameters syntax and values that are populated in the
>originator's certificate."

Is this correct?  I think that it has been moved to the PKIX Algs document.

[JSP: You are correct.  Please change my comment to use the PKIX Algs
reference.]


<snip>

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7VGsgK22535 for ietf-smime-bks; Fri, 31 Aug 2001 09:54:42 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f7VGseD22528 for <[e-mail]>; Fri, 31 Aug 2001 09:54:40 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 31 Aug 2001 16:52:13 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA22358 for <[e-mail]>; Fri, 31 Aug 2001 12:53:51 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <QTWCTT7K>; Fri, 31 Aug 2001 12:54:41 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.24]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCTT7J; Fri, 31 Aug 2001 12:54:37 -0400
From: "Housley, Russ" <[e-mail]>
To: "Pawling, John" <[e-mail]>
Cc: "SMIME WG (E-mail)" <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 31 Aug 2001 12:54:26 -0400
Subject: Re: cmsalg-02 Comments
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

John:

I just sent cmsalg-03 to the repository.  The results of this discussion 
will appear in cmsalg-04.

>1) Sec 2, 3rd para: Please replace:
>
>OLD: "Digest values are located in the DigestedData digest field the Message
>Digest authenticated attribute."
>
>NEW:  "Digest values are located in the DigestedData digest field and the
>Message Digest attribute."

Good catch.  Done.

>2) Sec 2.1, last para:  In a message exchange between Jim and Russ, Russ
>agreed to change the last paragraph in Sec 2.1 to the following:
>
>     The AlgorithmIdentifier parameters field is OPTIONAL.  If present,
>     the parameters field MUST contain a NULL.  Implementations MUST
>     accept SHA-1 AlgorithmIdentifiers with absent parameters.
>     Implementations SHOULD accept SHA-1 AlgorithmIdentifiers with absent
>     parameters.  Implementations SHOULD generate SHA-1
>     AlgorithmIdentifiers with absent parameters.
>
>I believe that the following paragraph would be better:
>
>     The AlgorithmIdentifier parameters field is OPTIONAL.  If present,
>     the parameters field MUST contain a NULL.  Implementations MUST
>     accept SHA-1 AlgorithmIdentifiers with absent parameters.
>     Implementations MUST accept SHA-1 AlgorithmIdentifiers with NULL
>     parameters.  Implementations SHOULD generate SHA-1
>     AlgorithmIdentifiers with absent parameters.

Fine.  Done.

>3) Sec 3.2 specifies that the md5WithRSAEncryption or sha1WithRSAEncryption
>OID should be used in the signerInfo signatureAlgorithm field instead of the
>id-rsaEncryption OID.  I agree with this strategy, but please note that this
>is a change from what is specified in RFC 2630.  RFC2630 specifies the use
>of id-rsaEncryption in the signerInfo signatureAlgorithm field.  Is this
>change going to cause backwards compatibility problems with legacy CMS
>implementations?

I want to highlight this point.  As you say, it might be controversial.  I 
will start a thread to discuss this point.

>4) Sec 4.1.1, please replace:
>
>OLD: "CMS implementations MUST support ukm being absent, and CMS
>implementations SHOULD support be present."
>
>NEW: "CMS implementations MUST support ukm being absent, and CMS
>implementations SHOULD support ukm being present."

Good catch.  Done.

>5) sec 4.1.2, originator field, please replace:
>
>OLD: "In both cases, the recipient's certificate contains the sender's
>static public key,"
>
>NEW: "In both cases, the originator's certificate contains the originator's
>static public key,"

Good catch.  In PKCS #7, RFC 2630, and rfc2630bis-03, the term "sender" is 
used in much of that narrative description.  Therefore, I prefer:

       originator MUST be either the issuerAndSerialNumber or
       subjectKeyIdentifier alternative.  In both cases, the originator's
       certificate contains the sender's static public key, and the
       certificate subject public key information field MUST contain the
       dh-public-number object identifier:

          dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
              us(840) ansi-x942(10046) number-type(2) 1 }

>6) sec 4.1.2, originator field, please add: "[PROFILE] specifies the
>AlgorithmIdentifier parameters syntax and values that are populated in the
>originator's certificate."

Is this correct?  I think that it has been moved to the PKIX Algs document.

>7) sec 4.3, 1rst sent: Please replace:
>
>OLD: "This section specifies the conventions employed by CMS implementations
>support symmetric key-encryption key management using Triple-DES or RC2
>key-encryption keys."
>
>NEW: "This section specifies the conventions employed by CMS implementations
>that support symmetric key-encryption key management using Triple-DES or RC2
>key-encryption keys."

Agree.  Done.

Russ


Received: by above.proper.com (8.11.6/8.11.3) id f7VGmBh22412 for ietf-smime-bks; Fri, 31 Aug 2001 09:48:11 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7VGmBD22408 for <[e-mail]>; Fri, 31 Aug 2001 09:48:11 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <R052V10D>; Fri, 31 Aug 2001 12:48:20 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "SMIME WG (E-mail)" <[e-mail]>
Subject: RE: cmsalg-02 RSA OID Proposal
Date: Fri, 31 Aug 2001 12:48:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Eric,

I believe that the change is being proposed so that the
md5WithRSAEncryption, sha1WithRSAEncryption, and rsaEncryption OIDs will be
used consistently in PKIX X.509 certificates and CMS signedData content
types.  

RFC2459 specifies the use of the rsaEncryption OID to indicate that an RSA
public key is present in the subjectPublicKey field of a certificate.
RFC2459 specifies the use of the md5WithRSAEncryption or
sha1WithRSAEncryption OID (as appropriate) in the certificate
signatureAlgorithm field when the RSA (PKCS #1 v1.5) algorithm is used to
sign the certificate.

RFC2630 specifies the use of the rsaEncryption OID in the signedData
signerInfo signatureAlgorithm field when the RSA (PKCS #1 v1.5) algorithm is
used as part of the signature generation process. 

Therefore, the RFC2630 use of the id-rsaEncryption OID is inconsistent with
RFC2459.  This caused confusion with some implementers, because they assumed
that the md5WithRSAEncryption or sha1WithRSAEncryption OID (as appropriate)
would be used in the signedData signerInfo signatureAlgorithm field as they
are used in the certificate signatureAlgorithm field.

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


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7VGhxV22299 for ietf-smime-bks; Fri, 31 Aug 2001 09:43:59 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f7VGhvD22295 for <[e-mail]>; Fri, 31 Aug 2001 09:43:57 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 31 Aug 2001 16:41:30 UT
Received: from exeu00.securid.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA21713 for <[e-mail]>; Fri, 31 Aug 2001 12:43:08 -0400 (EDT)
Received: by exeu00.securid.com with Internet Mail Service (5.5.2653.19) id <R0YWAAC9>; Fri, 31 Aug 2001 17:43:52 +0100
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.24]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCTTYW; Fri, 31 Aug 2001 12:43:55 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Fri, 31 Aug 2001 12:43:46 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: RSA Signature OIDs
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In a recent message from John Pawling, he made the following observation:

>3) Sec 3.2 specifies that the md5WithRSAEncryption or sha1WithRSAEncryption
>OID should be used in the signerInfo signatureAlgorithm field instead of the
>id-rsaEncryption OID.  I agree with this strategy, but please note that this
>is a change from what is specified in RFC 2630.  RFC2630 specifies the use
>of id-rsaEncryption in the signerInfo signatureAlgorithm field.  Is this
>change going to cause backwards compatibility problems with legacy CMS
>implementations?

I believe that the text in RFC 2630 was some what incomplete.  Notice that 
the corresponding section in cmsalg-02 and cmsalg-03 is significantly longer.

The approach documented in cmsalg-03 is aligned with the way that 
certificates are handles in PKIX.  That is, public keys are identified with 
the rsaEncryption OID, and signature values are identified with either the 
sha1WithRSAEncryption OID or the md5WithRSAEncryption OID.

Is cmsalg-03 documenting the best approach?  WG Last Call on this document 
is scheduled to end today.  Since this issue has been raised on the last 
day, I will not close WG Last Call until this thread reaches consensus.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7VGBVB21725 for ietf-smime-bks; Fri, 31 Aug 2001 09:11:31 -0700 (PDT)
Received: from romeo.rtfm.com ([198.144.203.242]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7VGBTD21717 for <[e-mail]>; Fri, 31 Aug 2001 09:11:30 -0700 (PDT)
Received: (ekr@localhost) by romeo.rtfm.com (8.9.3/8.6.4) id JAA54973; Fri, 31 Aug 2001 09:18:13 -0700 (PDT)
To: "Pawling, John" <[e-mail]>
Cc: "SMIME WG (E-mail)" <[e-mail]>
Subject: Re: cmsalg-02 RSA OID Proposal
References: <[e-mail]>
Reply-to: EKR <[e-mail]>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Eric Rescorla <[e-mail]>
Date: 31 Aug 2001 09:18:13 -0700
In-Reply-To: "Pawling, John"'s message of "Fri, 31 Aug 2001 11:44:17 -0400"
Message-ID: <[e-mail]>
Lines: 19
X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Pawling, John" <[e-mail]> writes:
> RFC2630 CMS, section 12.2.2, specifies the use of the rsaEncryption object
> identifier (OID) in the signedData signerInfo signatureAlgorithm field when
> the RSA (PKCS #1 v1.5) algorithm is used as part of the signature generation
> process.  cmsalg-02, Section 3.2, specifies the use of the
> md5WithRSAEncryption and sha1WithRSAEncryption OID (as appropriate) in the
> signedData signerInfo signatureAlgorithm field (instead of the
> id-rsaEncryption OID).  The cmsalg-02 proposed use of these OIDs is
> consistent with their use in the RFC2459 PKIX Certificate/CRL Profile.  The
> RFC2630 use of the id-rsaEncryption OID is inconsistent with RFC2459.  
> 
> Is this change going to cause backwards compatibility problems with legacy
> CMS implementations?
I strongly suspect it will. More to the point, what's the virtue of
this change? 

-Ekr




Received: by above.proper.com (8.11.6/8.11.3) id f7VFiAb18831 for ietf-smime-bks; Fri, 31 Aug 2001 08:44:10 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7VFiAD18825 for <[e-mail]>; Fri, 31 Aug 2001 08:44:10 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <R052V1RA>; Fri, 31 Aug 2001 11:44:19 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "SMIME WG (E-mail)" <[e-mail]>
Subject: cmsalg-02 RSA OID Proposal
Date: Fri, 31 Aug 2001 11:44:17 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

RFC2630 CMS, section 12.2.2, specifies the use of the rsaEncryption object
identifier (OID) in the signedData signerInfo signatureAlgorithm field when
the RSA (PKCS #1 v1.5) algorithm is used as part of the signature generation
process.  cmsalg-02, Section 3.2, specifies the use of the
md5WithRSAEncryption and sha1WithRSAEncryption OID (as appropriate) in the
signedData signerInfo signatureAlgorithm field (instead of the
id-rsaEncryption OID).  The cmsalg-02 proposed use of these OIDs is
consistent with their use in the RFC2459 PKIX Certificate/CRL Profile.  The
RFC2630 use of the id-rsaEncryption OID is inconsistent with RFC2459.  

Is this change going to cause backwards compatibility problems with legacy
CMS implementations?

The current release of the S/MIME Freeware Library (SFL) (available from
<http://www.getronicsgov.com/hot/sfl_lib.htm>) can successfully verify a
signedData content type that includes a signerInfo signatureAlgorithm field
that includes the md5WithRSAEncryption, sha1WithRSAEncryption or
rsaEncryption OID (as appropriate).  Therefore, the proposed cmsalg-02 use
of the md5WithRSAEncryption and sha1WithRSAEncryption OID (as appropriate)
would not cause backwards compatibility problems for those applications that
use the SFL along with a crypto library that supports the algorithms
indicated by the OIDs. 

Feedback from others is welcome!  This is an important issue.  

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


Received: by above.proper.com (8.11.6/8.11.3) id f7UN3K918891 for ietf-smime-bks; Thu, 30 Aug 2001 16:03:20 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7UN3JD18887 for <[e-mail]>; Thu, 30 Aug 2001 16:03:19 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <R9HF40SV>; Thu, 30 Aug 2001 19:03:29 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "SMIME WG (E-mail)" <[e-mail]>
Subject: cmsalg-02 Comments
Date: Thu, 30 Aug 2001 19:03:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

I have the following comments to cmsalg-02.  The only comment that may be
controversial is #3.


1) Sec 2, 3rd para: Please replace:

OLD: "Digest values are located in the DigestedData digest field the Message
Digest authenticated attribute."

NEW:  "Digest values are located in the DigestedData digest field and the
Message Digest attribute."

  
2) Sec 2.1, last para:  In a message exchange between Jim and Russ, Russ
agreed to change the last paragraph in Sec 2.1 to the following:

    The AlgorithmIdentifier parameters field is OPTIONAL.  If present,
    the parameters field MUST contain a NULL.  Implementations MUST
    accept SHA-1 AlgorithmIdentifiers with absent parameters.
    Implementations SHOULD accept SHA-1 AlgorithmIdentifiers with absent
    parameters.  Implementations SHOULD generate SHA-1
    AlgorithmIdentifiers with absent parameters.

I believe that the following paragraph would be better:

    The AlgorithmIdentifier parameters field is OPTIONAL.  If present,
    the parameters field MUST contain a NULL.  Implementations MUST
    accept SHA-1 AlgorithmIdentifiers with absent parameters.
    Implementations MUST accept SHA-1 AlgorithmIdentifiers with NULL
    parameters.  Implementations SHOULD generate SHA-1
    AlgorithmIdentifiers with absent parameters.


3) Sec 3.2 specifies that the md5WithRSAEncryption or sha1WithRSAEncryption
OID should be used in the signerInfo signatureAlgorithm field instead of the
id-rsaEncryption OID.  I agree with this strategy, but please note that this
is a change from what is specified in RFC 2630.  RFC2630 specifies the use
of id-rsaEncryption in the signerInfo signatureAlgorithm field.  Is this
change going to cause backwards compatibility problems with legacy CMS
implementations?


4) Sec 4.1.1, please replace:

OLD: "CMS implementations MUST support ukm being absent, and CMS
implementations SHOULD support be present."

NEW: "CMS implementations MUST support ukm being absent, and CMS
implementations SHOULD support ukm being present."


5) sec 4.1.2, originator field, please replace:

OLD: "In both cases, the recipient's certificate contains the sender's
static public key,"

NEW: "In both cases, the originator's certificate contains the originator's
static public key,"


6) sec 4.1.2, originator field, please add: "[PROFILE] specifies the
AlgorithmIdentifier parameters syntax and values that are populated in the
originator's certificate."


7) sec 4.3, 1rst sent: Please replace:

OLD: "This section specifies the conventions employed by CMS implementations
support symmetric key-encryption key management using Triple-DES or RC2
key-encryption keys."

NEW: "This section specifies the conventions employed by CMS implementations
that support symmetric key-encryption key management using Triple-DES or RC2
key-encryption keys."

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




Received: by above.proper.com (8.11.6/8.11.3) id f7UHE4R13150 for ietf-smime-bks; Thu, 30 Aug 2001 10:14:04 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f7UHE2D13144 for <[e-mail]>; Thu, 30 Aug 2001 10:14:02 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 30 Aug 2001 17:11:36 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA03847; Thu, 30 Aug 2001 13:13:07 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <QTWCTHCA>; Thu, 30 Aug 2001 13:13:55 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.70]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCTHB9; Thu, 30 Aug 2001 13:13:52 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 30 Aug 2001 13:13:49 -0400
Subject: draft-ietf-smime-password-05.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeff & Marcus:

As you probably recall, the S/MIME Working Group sent a previous version of 
the password-based key management document forward.  It was returned to the 
Working Group to resolve issues that were raised during IETF Last 
Call.  This version of the document includes resolutions for all of those 
issues.  S/MIME Working Group believes that this document is ready for IESG 
review and subsequent publication as an Standards Track RFC.

	Title		: Password-based Encryption for CMS
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-smime-password-05.txt
	Date		: 28-Aug-01
	
Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7UG2wr11865 for ietf-smime-bks; Thu, 30 Aug 2001 09:02:58 -0700 (PDT)
Received: from swordfish.nexor.co.uk (swordfish.nexor.co.uk [193.63.53.54]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7UG2oD11852 for <[e-mail]>; Thu, 30 Aug 2001 09:02:50 -0700 (PDT)
Received: by swordfish.nexor.co.uk with Internet Mail Service (5.5.2653.19) id <PBCFR50C>; Thu, 30 Aug 2001 17:01:52 +0100
Message-ID: <[e-mail]>
From: Graeme Lunt <[e-mail]>
To: "'Hegde, Vijaykumar'" <[e-mail]>, [e-mail]
Subject: RE: S/MIME support in X.400
Date: Thu, 30 Aug 2001 17:01:48 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Vijay,
    
> I have a couple of queries regarding
"draft-ietf-smime-x400transport-03.txt".

> 1.What is the ASN.1 syntax used for representing a S/MIME content ? For
IPM, 
> the ASN.1 syntax is defined in X.420. For EDI, the syntax is X.435. Are
there 
> any similar representations defined for S/MIME content ?

You will find the ASN.1 syntax in RFC 2630 (CMS) and RFC 2634 (ESS)

> 2. We use XAPI defined by X/OPEN to build the messages. Are there any 
> OID's/integer value defined to represent S/MIME content. i.e. the value
for 
> MH_T_CONTENT_TYPE. Also, are you aware of any plans on behalf of X/OPEN to

> support S/MIME, these drafts ?

Here are the definitions are you might see them in the X/APIs. 
They are aligned with the latest draft.

/* Content Identifiers */
#define OMP_O_MM_CTO_CMS
"\x2A\x86\x48\x86\xF7\x0D\x01\x09\x10\x01\x06"
#define OMP_O_MM_CTO_MIMECMS          "\x2A\x86\x48\x86\xF7\x0D\x01\x07\x01"

You want to use the first for S/MIME wrapped X.400 content.

I don't know of X/OPEN doing anything to specifically support CMS. 
The above definitions, with a binary content, is sufficient (at least for
me).

Graeme




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7UCkMO29956 for ietf-smime-bks; Thu, 30 Aug 2001 05:46:22 -0700 (PDT)
Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7UCkLD29952 for <[e-mail]>; Thu, 30 Aug 2001 05:46:21 -0700 (PDT)
Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id 05804122A; Thu, 30 Aug 2001 07:46:16 -0500 (CDT)
Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id EB98F124D for <[e-mail]>; Thu, 30 Aug 2001 07:46:16 -0500 (CDT)
Received: by mailrelay01.cce.cpqcorp.net (Postfix, from userid 12345) id B4261AEE; Thu, 30 Aug 2001 07:46:16 -0500 (CDT)
Received: from diexch01.xko.dec.com (diexch01.xko.dec.com [16.138.244.57]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 78443B70 for <[e-mail]>; Thu, 30 Aug 2001 07:46:11 -0500 (CDT)
Received: by diexch01.xko.dec.com with Internet Mail Service (5.5.2650.21) id <R6NJXV47>; Thu, 30 Aug 2001 18:10:22 +0530
Message-ID: <[e-mail]>
From: "Hegde, Vijaykumar" <[e-mail]>
To: [e-mail]
Subject: S/MIME support in X.400
Date: Thu, 30 Aug 2001 18:10:21 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13150.EED08FF8"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

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

Hello everybody,
                I am Vijay Hegde from Digital Globalsoft Limited ( formerly
known as Digital India). Currently our team is exploring the possibility of
S/MIME support in X.400. We are closely following the S/MIME discussion and
drafts at IETF.  
                
                I have a couple of queries regarding
"draft-ietf-smime-x400transport-03.txt".
 
1.What is the ASN.1 syntax used for representing a S/MIME content ? For IPM,
the ASN.1 syntax is defined in X.420. For EDI, the syntax is X.435. Are
there any similar representations defined for S/MIME content ?
 
2. We use XAPI defined by X/OPEN to build the messages. Are there any
OID's/integer value defined to represent S/MIME content. i.e. the value for
MH_T_CONTENT_TYPE. Also, are you aware of any plans on behalf of X/OPEN to
support S/MIME, these drafts ?
 
 
Thanks in advance,
Vijay Hegde

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV>
<DIV><FONT color=#0000ff face="Courier New" size=2><SPAN 
class=941471011-30082001>Hello everybody,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Courier New" size=2><SPAN 
class=941471011-30082001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I 
am Vijay Hegde from Digital Globalsoft Limited ( formerly known as 
Digital&nbsp;India). Currently&nbsp;our team&nbsp;is exploring the possibility 
of S/MIME support in X.400. We are closely following the S/MIME discussion and 
drafts at IETF.&nbsp;</SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face="Courier New" size=2><SPAN 
class=941471011-30082001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Courier New" size=2><SPAN 
class=941471011-30082001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
I have a couple of queries regarding 
"draft-ietf-smime-x400transport-03.txt".</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Courier New" size=2><SPAN 
class=941471011-30082001></SPAN></FONT>&nbsp;</DIV>
<DIV><SPAN class=941471011-30082001></SPAN><FONT color=#0000ff 
face="Courier New" size=2><SPAN class=872523608-30082001>1.What is the ASN.1 
syntax used for representing a S/MIME content ? For IPM, the ASN.1 sy<SPAN 
class=941471011-30082001>n</SPAN>tax is defined in X.420. For EDI, the syntax is 
X.435. Are there any similar representations defined for S/MIME content 
?</SPAN></FONT></DIV>
<DIV><SPAN class=872523608-30082001></SPAN><FONT color=#0000ff 
face="Courier New" size=2>&nbsp;</FONT></DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face="Courier New"><SPAN 
class=872523608-30082001>2. We use XAPI defined by X<SPAN 
class=941471011-30082001>/</SPAN>OPEN to build the messages. Are there any 
OID's/integer value defined to represent S/MIME content. i.e. the value for 
MH_T_CONTENT_TYPE<SPAN class=941471011-30082001>. Also, are you aware of any 
plans on behalf of X/OPEN to support S/MIME, these drafts 
?</SPAN></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face="Courier New"><SPAN 
class=872523608-30082001><SPAN 
class=941471011-30082001></SPAN></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face="Courier New"><SPAN 
class=872523608-30082001><SPAN class=941471011-30082001>Thanks in 
advance,</SPAN></SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT size=2><FONT color=#0000ff><FONT face="Courier New"><SPAN 
class=872523608-30082001><SPAN class=941471011-30082001>Vijay 
Hegde</SPAN></SPAN></FONT></FONT></FONT></DIV></DIV></BODY></HTML>

------_=_NextPart_001_01C13150.EED08FF8--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7UCaYu29367 for ietf-smime-bks; Thu, 30 Aug 2001 05:36:34 -0700 (PDT)
Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7UCaWD29363 for <[e-mail]>; Thu, 30 Aug 2001 05:36:32 -0700 (PDT)
Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by anchor-post-30.mail.demon.net with esmtp (Exim 2.12 #1) id 15cR3d-000ElS-0U for [e-mail]; Thu, 30 Aug 2001 13:36:31 +0100
Message-ID: <[e-mail]>
Date: Thu, 30 Aug 2001 13:36:07 +0100
From: Dr S N Henson <[e-mail]>
Organization: S N Henson
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Use of attribute certificates in SignedData
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> Chris,
>  
>  
> To my knowledge, no interoperability testing has been performed of signedData or envelopedData content types including
> ACs.  There are no ACs included in the Examples of S/MIME Messages Internet-Draft.  Also, there are no ACs included in the
> test messages documented in Jim Schaad's interoperability matrix for RFCs 2630 through 2634 (available from
> <http://www.imc.org/ietf-smime/interop-matrix.html>).  
>  

Well I've never seen any public examples of attribute certificates in
any context. I've been sent a few in private email (on the understanding
that they weren't redistributed) but so far they've all been broken and
would typically cause an ASN1 parser to choke.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [e-mail] 
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [e-mail] PGP key: via homepage.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7TIv9G09563 for ietf-smime-bks; Wed, 29 Aug 2001 11:57:09 -0700 (PDT)
Received: from hawaii.deming.com (hawaii.deming.com [208.236.41.139]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7TIv8D09559 for <[e-mail]>; Wed, 29 Aug 2001 11:57:08 -0700 (PDT)
Received: from 208.236.41.137 by hawaii.deming.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Wed, 29 Aug 2001 11:56:49 -0700
X-Server-Uuid: F4BC6258-86A5-40F3-9714-0CF63E081F09
Received: by cane.deming.com with Internet Mail Service (5.5.2650.21) id <R3CXVD14>; Wed, 29 Aug 2001 11:56:49 -0700
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'Christopher S. Francis'" <[e-mail]>, [e-mail], "Pawling, John" <[e-mail]>
Subject: RE: Use of attribute certificates in SignedData
Date: Wed, 29 Aug 2001 11:56:43 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 1793E57B5338-01-01
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C130BC.5B449AD0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

------_=_NextPart_001_01C130BC.5B449AD0
Content-Type: text/plain;
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit

I found a comment in my code:
 
        // REVIEW: This will puke on Attribute Certificates and PKCS #6
certs!

Blake
-----Original Message-----
From: Christopher S. Francis [mailto:[e-mail]]
Sent: Tuesday, August 28, 2001 2:29 PM
To: [e-mail]; Pawling, John
Subject: RE: Use of attribute certificates in SignedData


John,
 
Understood.  So I'm interpreting RFC-2630 correctly then.  When I said I was
considering putting the AC in the 'certificates' field, I really meant that
I wanted to include it as an attrCert choice in the 'certificates' field. 
 
So if that's the "correct" place to put the AC according to 2630, what
experience have people had with real-world applications that process
SignedData?  Will applications/toolkits that understand how to verify the
signature on SignedData, but do not process ACs typically just ignore the AC
if it's included or do they choke because: 1) they can't successfully decode
the AC or 2) they can't successfully validate the AC?
 
Ideally, I'd like to make the AC available for applications that are capable
of using it and have applications that are not AC-enabled just ignore it and
verify the signature on the SignedData using the PKC.  In the description of
the 'certificates' field, RFC-2630 says the following regarding the
certificates in the set: "There may be more certificates than necessary, and
there may be certificates sufficient to contain chains from two or more
independent top-level certification authorities."  This seems to *imply*
that compliant, but AC challenged applications will just ignore the AC as
long as they can validate the signature using the PKC.  I'm just looking for
a bit of a reality check.  Is that the way it works in the real world?
 
Thanks for the heads up regarding the fact that CMS specifies the 1997 X.509
syntax.  I'll go do some reading on what the differences are.  Depending on
the answers to the questions above, it may not matter though.  We're writing
our own X.509 2000 compliant application to process the ACs.  At this point,
it's probably acceptable to say that other third-party AC-enabled
applications must support X.509 2000 to process our SignedData blob.  As I
mentioned above, as long as commonly available 3rd party validation software
doesn't choke, it's ok if it ignores the AC.
 
Chris
 
-----Original Message-----
From: Pawling, John [mailto:[e-mail]]
Sent: Tuesday, August 28, 2001 3:43 PM
To: 'Christopher S. Francis'; [e-mail]
Subject: RE: Use of attribute certificates in SignedData
 
Chris, 
RFC2630 specifies that an AttributeCertificate can be included in the
signedData certificates attrCert field.  Please note that RFC2630 specifies
the 1997 X.509 Attribute Certificate syntax (that is incompatible with the
2000 X.509 Attribute Certificate syntax).  Also, please note that RFC2630
states the following requirement regarding the value to be placed in the
signedData version field: "If attribute certificates are present, then the
value of version shall be 3."  
=========================================== 
John Pawling, [e-mail] 
Getronics Government Solutions, LLC 
=========================================== 

------_=_NextPart_001_01C130BC.5B449AD0
Content-Type: text/html;
 charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: Use of attribute certificates in SignedData</TITLE>

<META content=3DWord.Document name=3DProgId>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR>
<META content=3D"Microsoft Word 9" name=3DOriginator><LINK=20
href=3D"cid:filelist.xml@01C12FE6.E13B2DA0" rel=3DFile-List><!--[if gte =
mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<STYLE>@font-face {
	font-family: Comic Sans MS;
}
@font-face {
	font-family: Tahoma;
}
P.MsoNormal {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
LI.MsoNormal {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
DIV.MsoNormal {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
H1 {
	FONT-FAMILY: Arial; FONT-SIZE: 16pt; FONT-WEIGHT: bold; MARGIN: 12pt =
0in 3pt; mso-pagination: widow-orphan; mso-style-next: Normal; =
mso-outline-level: 1; mso-font-kerning: 16.0pt
}
P.MsoBodyText {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 11pt; LINE-HEIGHT: 120%; =
MARGIN: 13.2pt 0in 0pt 1in; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-font-kerning: 11.0pt; =
mso-bidi-font-size: 10.0pt
}
LI.MsoBodyText {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 11pt; LINE-HEIGHT: 120%; =
MARGIN: 13.2pt 0in 0pt 1in; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-font-kerning: 11.0pt; =
mso-bidi-font-size: 10.0pt
}
DIV.MsoBodyText {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 11pt; LINE-HEIGHT: 120%; =
MARGIN: 13.2pt 0in 0pt 1in; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-font-kerning: 11.0pt; =
mso-bidi-font-size: 10.0pt
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
}
P.MsoAutoSig {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"
}
LI.MsoAutoSig {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"
}
DIV.MsoAutoSig {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"
}
P {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 12pt; MARGIN-LEFT: 0in; =
MARGIN-RIGHT: 0in; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-margin-top-alt: auto; =
mso-margin-bottom-alt: auto
}
SPAN.EmailStyle16 {
	COLOR: navy; mso-style-type: personal-reply; mso-ansi-font-size: =
12.0pt; mso-ascii-font-family: "Comic Sans MS"; mso-hansi-font-family: =
"Comic Sans MS"; mso-bidi-font-family: Arial
}
P.Heading1NoTOC {
	FONT-FAMILY: Arial; FONT-SIZE: 14pt; FONT-WEIGHT: bold; MARGIN: 12pt =
0in 3pt; TEXT-ALIGN: center; mso-style-parent: "Heading 1"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"; mso-outline-level: 1; mso-font-kerning: 14.0pt; =
mso-bidi-font-size: 10.0pt; mso-bidi-font-family: "Times New Roman"; =
mso-style-name: "Heading 1 No TOC"; mso-bidi-font-weight: normal
}
LI.Heading1NoTOC {
	FONT-FAMILY: Arial; FONT-SIZE: 14pt; FONT-WEIGHT: bold; MARGIN: 12pt =
0in 3pt; TEXT-ALIGN: center; mso-style-parent: "Heading 1"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"; mso-outline-level: 1; mso-font-kerning: 14.0pt; =
mso-bidi-font-size: 10.0pt; mso-bidi-font-family: "Times New Roman"; =
mso-style-name: "Heading 1 No TOC"; mso-bidi-font-weight: normal
}
DIV.Heading1NoTOC {
	FONT-FAMILY: Arial; FONT-SIZE: 14pt; FONT-WEIGHT: bold; MARGIN: 12pt =
0in 3pt; TEXT-ALIGN: center; mso-style-parent: "Heading 1"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"; mso-outline-level: 1; mso-font-kerning: 14.0pt; =
mso-bidi-font-size: 10.0pt; mso-bidi-font-family: "Times New Roman"; =
mso-style-name: "Heading 1 No TOC"; mso-bidi-font-weight: normal
}
P.TableText {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 10pt; LINE-HEIGHT: 110%; =
MARGIN: 3pt 0in; mso-pagination: widow-orphan lines-together; =
mso-fareast-font-family: "Times New Roman"; mso-font-kerning: 10.0pt; =
mso-style-name: "Table Text"
}
LI.TableText {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 10pt; LINE-HEIGHT: 110%; =
MARGIN: 3pt 0in; mso-pagination: widow-orphan lines-together; =
mso-fareast-font-family: "Times New Roman"; mso-font-kerning: 10.0pt; =
mso-style-name: "Table Text"
}
DIV.TableText {
	FONT-FAMILY: "Times New Roman"; FONT-SIZE: 10pt; LINE-HEIGHT: 110%; =
MARGIN: 3pt 0in; mso-pagination: widow-orphan lines-together; =
mso-fareast-font-family: "Times New Roman"; mso-font-kerning: 10.0pt; =
mso-style-name: "Table Text"
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US link=3Dblue style=3D"tab-interval: .5in" =
vLink=3Dpurple>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D043245318-29082001>I=20
found a comment in my code:</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D043245318-29082001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D043245318-29082001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
// REVIEW:=20
This will puke on Attribute Certificates and PKCS #6=20
certs!<BR></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D043245318-29082001>Blake</DIV></SPAN></FONT>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Christopher S. =
Francis=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Tuesday, =
August 28,=20
  2001 2:29 PM<BR><B>To:</B> [e-mail]; Pawling,=20
  John<BR><B>Subject:</B> RE: Use of attribute certificates in=20
  SignedData<BR><BR></DIV></FONT>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle16><FONT color=3Dnavy=20
  face=3D"Comic Sans MS" size=3D3><SPAN=20
  style=3D"FONT-FAMILY: 'Comic Sans MS'; FONT-SIZE: =
12pt">John,<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle16><FONT color=3Dnavy=20
  face=3D"Comic Sans MS" size=3D3><SPAN=20
  style=3D"FONT-FAMILY: 'Comic Sans MS'; FONT-SIZE: 12pt"><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></SPAN></FONT></SPAN></P>=

  <P class=3DMsoNormal><SPAN class=3DEmailStyle16><FONT color=3Dnavy=20
  face=3D"Comic Sans MS" size=3D3><SPAN=20
  style=3D"FONT-FAMILY: 'Comic Sans MS'; FONT-SIZE: =
12pt">Understood.<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>So I&#8217;m interpreting =
RFC-2630 correctly=20
  then.<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>When I said I =
was=20
  considering putting the AC in the &#8216;certificates&#8217; field, I =
really meant that I=20
  wanted to include it as an attrCert choice in the =
&#8216;certificates&#8217; field.=20
  <o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle16><FONT color=3Dnavy=20
  face=3D"Comic Sans MS" size=3D3><SPAN=20
  style=3D"FONT-FAMILY: 'Comic Sans MS'; FONT-SIZE: 12pt"><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></SPAN></FONT></SPAN></P>=

  <P class=3DMsoNormal><SPAN class=3DEmailStyle16><FONT color=3Dnavy=20
  face=3D"Comic Sans MS" size=3D3><SPAN=20
  style=3D"FONT-FAMILY: 'Comic Sans MS'; FONT-SIZE: 12pt">So if =
that&#8217;s the=20
  &#8220;correct&#8221; place to put the AC according to 2630, what =
experience have people=20
  had with real-world applications that process SignedData?<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>Will applications/toolkits =
that=20
  understand how to verify the signature on SignedData, but do not =
process ACs=20
  typically just ignore the AC if it&#8217;s included or do they choke =
because: 1)=20
  they can&#8217;t successfully decode the AC or 2) they can&#8217;t =
successfully validate=20
  the AC?<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle16><FONT color=3Dnavy=20
  face=3D"Comic Sans MS" size=3D3><SPAN=20
  style=3D"FONT-FAMILY: 'Comic Sans MS'; FONT-SIZE: 12pt"><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></SPAN></FONT></SPAN></P>=

  <P class=3DMsoNormal><SPAN class=3DEmailStyle16><FONT color=3Dnavy=20
  face=3D"Comic Sans MS" size=3D3><SPAN=20
  style=3D"FONT-FAMILY: 'Comic Sans MS'; FONT-SIZE: 12pt">Ideally, =
I&#8217;d like to=20
  make the AC available for applications that are capable of using it =
and have=20
  applications that are not AC-enabled just ignore it and verify the =
signature=20
  on the SignedData using the PKC.<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
  </SPAN>In the description of the &#8216;certificates&#8217; field, =
RFC-2630 says the=20
  following regarding the certificates in the set: &#8220;There may be =
more=20
  certificates than necessary, and there may be certificates sufficient =
to=20
  contain chains from two or more independent top-level certification=20
  authorities.&#8221;<SPAN style=3D"mso-spacerun: yes">&nbsp; =
</SPAN>This seems to=20
  *<B><SPAN style=3D"FONT-WEIGHT: bold">imply</SPAN></B>* that =
compliant, but AC=20
  challenged applications will just ignore the AC as long as they can =
validate=20
  the signature using the PKC.<SPAN style=3D"mso-spacerun: yes">&nbsp; =
</SPAN>I&#8217;m=20
  just looking for a bit of a reality check.<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>Is that the way it works in =
the real=20
  world?<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle16><FONT color=3Dnavy=20
  face=3D"Comic Sans MS" size=3D3><SPAN=20
  style=3D"FONT-FAMILY: 'Comic Sans MS'; FONT-SIZE: 12pt"><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></SPAN></FONT></SPAN></P>=

  <P class=3DMsoNormal><SPAN class=3DEmailStyle16><FONT color=3Dnavy=20
  face=3D"Comic Sans MS" size=3D3><SPAN=20
  style=3D"FONT-FAMILY: 'Comic Sans MS'; FONT-SIZE: 12pt">Thanks for =
the heads up=20
  regarding the fact that CMS specifies the 1997 X.509 syntax.<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>I&#8217;ll go do some =
reading on what the=20
  differences are.<SPAN style=3D"mso-spacerun: yes">&nbsp; =
</SPAN>Depending on the=20
  answers to the questions above, it may not matter though.<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>We&#8217;re writing our own =
X.509 2000=20
  compliant application to process the ACs.<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>At this point, it&#8217;s =
probably=20
  acceptable to say that other third-party AC-enabled applications must =
support=20
  X.509 2000 to process our SignedData blob.<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>As I mentioned above, as =
long as=20
  commonly available 3<SUP>rd</SUP> party validation software =
doesn&#8217;t choke,=20
  it&#8217;s ok if it ignores the =
AC.<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle16><FONT color=3Dnavy=20
  face=3D"Comic Sans MS" size=3D3><SPAN=20
  style=3D"FONT-FAMILY: 'Comic Sans MS'; FONT-SIZE: 12pt"><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></SPAN></FONT></SPAN></P>=

  <P class=3DMsoNormal><SPAN class=3DEmailStyle16><FONT color=3Dnavy=20
  face=3D"Comic Sans MS" size=3D3><SPAN=20
  style=3D"FONT-FAMILY: 'Comic Sans MS'; FONT-SIZE: =
12pt">Chris<o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=3DMsoNormal><SPAN class=3DEmailStyle16><FONT color=3Dnavy=20
  face=3D"Comic Sans MS" size=3D3><SPAN=20
  style=3D"FONT-FAMILY: 'Comic Sans MS'; FONT-SIZE: 12pt"><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></SPAN></FONT></SPAN></P>=

  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><FONT color=3Dblack =
face=3DTahoma=20
  size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-FAMILY: Tahoma; FONT-SIZE: =
10pt">-----Original=20
  Message-----<BR><B><SPAN style=3D"FONT-WEIGHT: bold">From:</SPAN></B> =
Pawling,=20
  John [mailto:[e-mail]]<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Tuesday, August 28, 2001 =
3:43=20
  PM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> =
'Christopher S.=20
  Francis'; [e-mail]<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE: Use of attribute=20
  certificates in SignedData</SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 0.5in"><FONT face=3D"Times =
New Roman"=20
  size=3D3><SPAN style=3D"FONT-SIZE: 12pt"><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 0.5in"><FONT color=3Dblack face=3D"Times New =
Roman"=20
  size=3D2><SPAN style=3D"COLOR: black; FONT-SIZE: =
10pt">Chris,</SPAN></FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> </SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 0.5in"><FONT color=3Dblack face=3D"Times New =
Roman"=20
  size=3D2><SPAN style=3D"COLOR: black; FONT-SIZE: 10pt">RFC2630 =
specifies that an=20
  AttributeCertificate can be included in the signedData certificates =
attrCert=20
  field.&nbsp; Please note that RFC2630 specifies the 1997 X.509 =
Attribute=20
  Certificate syntax (that is incompatible with the 2000 X.509 =
Attribute=20
  Certificate syntax).&nbsp; Also, please note that RFC2630 states the =
following=20
  requirement regarding the value to be placed in the signedData =
version field:=20
  "If attribute certificates are present, then the value of version =
shall be=20
  3."&nbsp; </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 0.5in"><FONT color=3Dblack face=3D"Times New =
Roman"=20
  size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: =
10pt">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">John Pawling,=20
  [e-mail] </SPAN></FONT><FONT color=3Dblack><SPAN =

  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: 10pt">Getronics Government =
Solutions, LLC=20
  </SPAN></FONT><FONT color=3Dblack><SPAN=20
  style=3D"COLOR: black"><BR></SPAN></FONT><FONT color=3Dblack =
size=3D2><SPAN=20
  style=3D"COLOR: black; FONT-SIZE: =
10pt">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</SPAN></=
FONT><FONT=20
  color=3Dblack><SPAN style=3D"COLOR: black"> </SPAN></FONT><FONT =
color=3Dblack><SPAN=20
  style=3D"COLOR: black; mso-color-alt: =
windowtext"><o:p></o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTM=
L>

------_=_NextPart_001_01C130BC.5B449AD0--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7TFSBp01879 for ietf-smime-bks; Wed, 29 Aug 2001 08:28:11 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7TFSAD01875 for <[e-mail]>; Wed, 29 Aug 2001 08:28:10 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <Q36A76KB>; Wed, 29 Aug 2001 11:28:19 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "'Christopher S. Francis'" <[e-mail]>, [e-mail]
Subject: RE: Use of attribute certificates in SignedData
Date: Wed, 29 Aug 2001 11:28:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1309F.36D77DF0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

------_=_NextPart_001_01C1309F.36D77DF0
Content-Type: text/plain;
	charset="iso-8859-1"

Chris,
 
I can't answer all of your questions, but here is some information that may
help.
 
The S/MIME Freeware Library (SFL) (available from <
http://www.getronicsgov.com/hot/sfl_lib.htm
<http://www.getronicsgov.com/hot/sfl_lib.htm> >) implements RFC 2630
including the 1997 X.509 Attribute Certificate (AC) syntax.  The SFL
supports the ASN.1 encoding and decoding of 1997 ACs in signedData and
envelopedData content types.  The SFL does not attempt to verify ACs.  While
using the SFL to construct a signedData or envelopedData content type, the
application can provide the SFL with an ASN.1-encoded 1997 AC to be included
in the signedData or envelopedData.  While using the SFL to process a
signedData or envelopedData content type, if a 1997 AC is present, then the
SFL provides the ASN.1-encoded 1997 AC to the application for further
verification and processing.  If a 2000 AC is included in a signedData or
envelopedData content type provided to the SFL for processing, then the SFL
will return an ASN.1 decode error because the 2000 X.509 AC syntax is not a
part of RFC2630.  
 
The 2000 X.509 AC syntax is a part of the "son-of-rfc2630" Internet-Draft
<draft-ietf-smime-rfc2630bis-02.txt>.  Once rfc2630bis is stable and
approved, then Getronics will enhance the SFL to implement the rfc2630bis
specification including supporting the ASN.1 encoding and decoding of 2000
X.509 ACs.  At this time, I would recommend against including 2000 ACs in
signedData and envelopedData content types for the following reasons: 2000
X.509 AC syntax is not a part of RFC2630; and rfc2630bis specification is
not yet stable and has not been widely implemented.
 
To my knowledge, no interoperability testing has been performed of
signedData or envelopedData content types including ACs.  There are no ACs
included in the Examples of S/MIME Messages Internet-Draft.  Also, there are
no ACs included in the test messages documented in Jim Schaad's
interoperability matrix for RFCs 2630 through 2634 (available from
<http://www.imc.org/ietf-smime/interop-matrix.html>
<http://www.imc.org/ietf-smime/interop-matrix.html>).  
 
The current release of the Access Control Library (ACL) (available from <
http://www.getronicsgov.com/hot/acl_home.htm
<http://www.getronicsgov.com/hot/acl_home.htm> >) can be used to verify 1997
X.509 ACs.  We are in the process of enhancing the ACL to support the
verification of both 1997 and 2000 X.509 ACs.
=========================================== 
John Pawling, [e-mail] 
Getronics Government Solutions, LLC 
=========================================== 

------_=_NextPart_001_01C1309F.36D77DF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: Use of attribute certificates in SignedData</TITLE>

<META content=3DWord.Document name=3DProgId>
<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR>
<META content=3D"Microsoft Word 9" name=3DOriginator><LINK=20
href=3D"cid:filelist.xml@01C12FE6.E13B2DA0" rel=3DFile-List><!--[if gte =
mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<STYLE>@font-face {
	font-family: Comic Sans MS;
}
@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; =
mso-header-margin: .5in; mso-footer-margin: .5in; mso-paper-source: 0; =
}
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
H1 {
	FONT-WEIGHT: bold; FONT-SIZE: 16pt; MARGIN: 12pt 0in 3pt; FONT-FAMILY: =
Arial; mso-pagination: widow-orphan; mso-style-next: Normal; =
mso-outline-level: 1; mso-font-kerning: 16.0pt
}
P.MsoBodyText {
	FONT-SIZE: 11pt; MARGIN: 13.2pt 0in 0pt 1in; LINE-HEIGHT: 120%; =
FONT-FAMILY: "Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-font-kerning: 11.0pt; =
mso-bidi-font-size: 10.0pt
}
LI.MsoBodyText {
	FONT-SIZE: 11pt; MARGIN: 13.2pt 0in 0pt 1in; LINE-HEIGHT: 120%; =
FONT-FAMILY: "Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-font-kerning: 11.0pt; =
mso-bidi-font-size: 10.0pt
}
DIV.MsoBodyText {
	FONT-SIZE: 11pt; MARGIN: 13.2pt 0in 0pt 1in; LINE-HEIGHT: 120%; =
FONT-FAMILY: "Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-font-kerning: 11.0pt; =
mso-bidi-font-size: 10.0pt
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
}
P.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"
}
LI.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"
}
DIV.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-margin-top-alt: auto; =
mso-margin-bottom-alt: auto
}
SPAN.EmailStyle16 {
	COLOR: navy; mso-style-type: personal-reply; mso-ansi-font-size: =
12.0pt; mso-ascii-font-family: "Comic Sans MS"; mso-hansi-font-family: =
"Comic Sans MS"; mso-bidi-font-family: Arial
}
P.Heading1NoTOC {
	FONT-WEIGHT: bold; FONT-SIZE: 14pt; MARGIN: 12pt 0in 3pt; FONT-FAMILY: =
Arial; TEXT-ALIGN: center; mso-style-parent: "Heading 1"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"; mso-outline-level: 1; mso-font-kerning: 14.0pt; =
mso-bidi-font-size: 10.0pt; mso-bidi-font-family: "Times New Roman"; =
mso-style-name: "Heading 1 No TOC"; mso-bidi-font-weight: normal
}
LI.Heading1NoTOC {
	FONT-WEIGHT: bold; FONT-SIZE: 14pt; MARGIN: 12pt 0in 3pt; FONT-FAMILY: =
Arial; TEXT-ALIGN: center; mso-style-parent: "Heading 1"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"; mso-outline-level: 1; mso-font-kerning: 14.0pt; =
mso-bidi-font-size: 10.0pt; mso-bidi-font-family: "Times New Roman"; =
mso-style-name: "Heading 1 No TOC"; mso-bidi-font-weight: normal
}
DIV.Heading1NoTOC {
	FONT-WEIGHT: bold; FONT-SIZE: 14pt; MARGIN: 12pt 0in 3pt; FONT-FAMILY: =
Arial; TEXT-ALIGN: center; mso-style-parent: "Heading 1"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New =
Roman"; mso-outline-level: 1; mso-font-kerning: 14.0pt; =
mso-bidi-font-size: 10.0pt; mso-bidi-font-family: "Times New Roman"; =
mso-style-name: "Heading 1 No TOC"; mso-bidi-font-weight: normal
}
P.TableText {
	FONT-SIZE: 10pt; MARGIN: 3pt 0in; LINE-HEIGHT: 110%; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan lines-together; =
mso-fareast-font-family: "Times New Roman"; mso-font-kerning: 10.0pt; =
mso-style-name: "Table Text"
}
LI.TableText {
	FONT-SIZE: 10pt; MARGIN: 3pt 0in; LINE-HEIGHT: 110%; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan lines-together; =
mso-fareast-font-family: "Times New Roman"; mso-font-kerning: 10.0pt; =
mso-style-name: "Table Text"
}
DIV.TableText {
	FONT-SIZE: 10pt; MARGIN: 3pt 0in; LINE-HEIGHT: 110%; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan lines-together; =
mso-fareast-font-family: "Times New Roman"; mso-font-kerning: 10.0pt; =
mso-style-name: "Table Text"
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US style=3D"tab-interval: .5in" vLink=3Dpurple =
link=3Dblue>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D740222714-29082001>Chris,</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D740222714-29082001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D740222714-29082001>I can't=20
answer all of your questions, but here is some information that may=20
help.</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D740222714-29082001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D740222714-29082001>The S/MIME=20
Freeware Library (SFL) (available from&nbsp;&lt;<FONT size=3D2><A=20
href=3D"http://www.getronicsgov.com/hot/sfl_lib.htm">http://www.getronic=
sgov.com/hot/sfl_lib.htm</A>&gt;)=20
</FONT>implements RFC 2630&nbsp;including the 1997 X.509 Attribute =
Certificate=20
(AC) syntax.&nbsp;&nbsp;The SFL&nbsp;supports the ASN.1 encoding and =
decoding of=20
1997&nbsp;ACs in&nbsp;signedData and envelopedData content types.&nbsp; =
The SFL=20
does not attempt to verify&nbsp;ACs.&nbsp; While&nbsp;using the SFL to =
construct=20
a signedData or envelopedData content type, the&nbsp;application can =
provide the=20
SFL with an ASN.1-encoded 1997 AC to be included =
in&nbsp;the&nbsp;signedData or=20
envelopedData.&nbsp;&nbsp;While&nbsp;using the SFL to process&nbsp;a =
signedData=20
or envelopedData content type, if a 1997 AC is present, then the SFL =
provides=20
the ASN.1-encoded 1997 AC to the&nbsp;application for further =
verification and=20
processing.&nbsp; <SPAN class=3D740222714-29082001>If a 2000&nbsp;AC is =
included=20
in&nbsp;a signedData or envelopedData content type provided to the SFL =
for=20
processing, then the SFL will return an ASN.1 decode error because =
t<SPAN=20
class=3D740222714-29082001>he 2000 X.509 AC syntax is not a part of=20
RFC2630</SPAN>.&nbsp; </SPAN></SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D740222714-29082001></SPAN></FONT><FONT face=3D"Courier New" =
size=3D2><SPAN=20
class=3D740222714-29082001></SPAN></FONT><FONT face=3D"Courier New" =
size=3D2><SPAN=20
class=3D740222714-29082001></SPAN></FONT><FONT face=3D"Courier New" =
size=3D2><SPAN=20
class=3D740222714-29082001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D740222714-29082001>The 2000=20
X.509 AC syntax&nbsp;is a part of the =
"son-of-rfc2630"&nbsp;Internet-Draft <FONT=20
size=3D2>&lt;draft-ietf-smime-rfc2630bis-02.txt&gt;.&nbsp;=20
Once&nbsp;rfc2630bis&nbsp;is&nbsp;stable and approved, =
then&nbsp;Getronics=20
will&nbsp;enhance the SFL to implement&nbsp;the rfc2630bis =
specification=20
including supporting the ASN.1 encoding and decoding of 2000 X.509 ACs. =
&nbsp;At=20
this time, </FONT></SPAN></FONT><FONT face=3D"Courier New" =
size=3D2><SPAN=20
class=3D740222714-29082001>I would recommend against including 2000 ACs =
in=20
signedData and envelopedData content types for the following =
reasons:&nbsp;<SPAN=20
class=3D740222714-29082001>2000 X.509 AC syntax is not a part of =
RFC2630;=20
and&nbsp;</SPAN>rfc2630bis specification is not yet stable and has not =
been=20
widely implemented.</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D740222714-29082001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D740222714-29082001>To my=20
knowledge, no interoperability testing has been performed of signedData =

or&nbsp;envelopedData content types including ACs.&nbsp;&nbsp;There are =
no ACs=20
included in the <FONT size=3D2>Examples of S/MIME Messages =
Internet-Draft.&nbsp;=20
Also, there are no ACs included in the test messages&nbsp;documented in =
<FONT=20
size=3D2>Jim Schaad's&nbsp;interoperability matrix for RFCs 2630 =
through 2634=20
(available from <A=20
href=3D"http://www.imc.org/ietf-smime/interop-matrix.html">&lt;http://ww=
w.imc.org/ietf-smime/interop-matrix.html</A>&gt;)</FONT></FONT></SPAN></=
FONT><FONT=20
face=3D"Courier New" size=3D2><SPAN class=3D740222714-29082001><FONT =
size=3D2><FONT=20
size=3D2>.&nbsp; </FONT></FONT></SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D740222714-29082001></SPAN></FONT><FONT face=3D"Courier New" =
size=3D2><SPAN=20
class=3D740222714-29082001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D740222714-29082001>The current=20
release of the Access Control Library (ACL) <FONT face=3D"Courier =
New">(<SPAN=20
class=3D740222714-29082001>available from &lt;</SPAN></FONT><A=20
href=3D"http://www.getronicsgov.com/hot/acl_home.htm">http://www.getroni=
csgov.com/hot/acl_home.htm</A>&gt;)=20
</SPAN></FONT><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D740222714-29082001>can=20
be used to verify&nbsp;1997 X.509&nbsp;ACs.&nbsp; We are in the process =
of=20
enhancing the ACL to support the verification of both 1997 and 2000 =
X.509=20
ACs.</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D740222714-29082001>
<P><FONT face=3D"Courier New"=20
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT=
> <BR><FONT=20
face=3D"Courier New" size=3D2>John Pawling, =
[e-mail]</FONT>=20
<BR><FONT face=3D"Courier New" size=3D2>Getronics Government Solutions, =
LLC</FONT>=20
<BR><FONT face=3D"Courier New"=20
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT=
>=20
</P></SPAN></FONT></DIV><![if !supportEmptyParas]><![endif]><![if =
!supportEmptyParas]><![endif]><![if !supportEmptyParas]><![endif]><![if =
!supportEmptyParas]><![endif]><![if !supportEmptyParas]><![endif]><![if =
!supportEmptyParas]><![endif]><![if =
!supportEmptyParas]><![endif]></BODY></HTML>

------_=_NextPart_001_01C1309F.36D77DF0--


Received: by above.proper.com (8.11.6/8.11.3) id f7TEj9100985 for ietf-smime-bks; Wed, 29 Aug 2001 07:45:09 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f7TEj3D00981 for <[e-mail]>; Wed, 29 Aug 2001 07:45:07 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 29 Aug 2001 14:42:37 UT
Received: from exrsa01.rsa.com (exrsa01.rsa.com [10.81.217.7]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA22854 for <[e-mail]>; Wed, 29 Aug 2001 10:44:13 -0400 (EDT)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <QPHT5MHB>; Wed, 29 Aug 2001 07:48:56 -0700
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.121]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCS46X; Wed, 29 Aug 2001 10:44:53 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 29 Aug 2001 10:44:48 -0400
Subject: WG Last Call: draft-ietf-smime-x400wrap-04.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The X.400 Wrap document is ready for WG Last Call.  This document describes 
a protocol for adding cryptographic signature and encryption services to 
X.400 content.  Please post all comments to the S/MIME WG mail list by 14 
September 2001.

	Title		: Securing X.400 Content with S/MIME
	Author(s)	: P. Hoffman, C. Bonatti, A. Eggen
	Filename	: draft-ietf-smime-x400wrap-04.txt
	Date		: 27-Aug-01
	
Russ 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7TBLmw21920 for ietf-smime-bks; Wed, 29 Aug 2001 04:21:48 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7TBLlD21916 for <[e-mail]>; Wed, 29 Aug 2001 04:21:47 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20065; Wed, 29 Aug 2001 07:20:28 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-password-05.txt
Date: Wed, 29 Aug 2001 07:20:27 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Password-based Encryption for S/MIME
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-smime-password-05.txt
	Pages		: 
	Date		: 28-Aug-01
	
This document describes a password-based content encryption mechanism
for CMS.  This is implemented as a new RecipientInfo type and is an
extension to the RecipientInfo types currently defined in RFC 2630
[RFC2630].

The format of the messages are described in ASN.1 [ASN1].

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

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-password-05.txt".

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-password-05.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7SLT8708394 for ietf-smime-bks; Tue, 28 Aug 2001 14:29:08 -0700 (PDT)
Received: from emerald.lightlink.com (emerald.lightlink.com [205.232.34.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7SLT6D08390 for <[e-mail]>; Tue, 28 Aug 2001 14:29:06 -0700 (PDT)
Received: from [209.216.70.29] (perm70-29.ij.net [209.216.70.29] (may be forged)) by emerald.lightlink.com (8.8.8/8.8.8) with SMTP id RAA28280; Tue, 28 Aug 2001 17:28:53 -0400
From: "Christopher S. Francis" <[e-mail]>
To: <[e-mail]>, "Pawling, John" <[e-mail]>
Received: from no.name.available by [209.216.70.29] via smtpd (for smtp.lightlink.com [205.232.34.14]) with SMTP; 28 Aug 2001 21:29:51 UT
Subject: RE: Use of attribute certificates in SignedData
Date: Tue, 28 Aug 2001 17:28:52 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_007A_01C12FE6.E8559170"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_007A_01C12FE6.E8559170
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

John,
=20
Understood.  So I=92m interpreting RFC-2630 correctly then.  When I said =
I was considering putting the AC in the =91certificates=92 field, I =
really meant that I wanted to include it as an attrCert choice in the =
=91certificates=92 field.=20
=20
So if that=92s the =93correct=94 place to put the AC according to 2630, =
what experience have people had with real-world applications that =
process SignedData?  Will applications/toolkits that understand how to =
verify the signature on SignedData, but do not process ACs typically =
just ignore the AC if it=92s included or do they choke because: 1) they =
can=92t successfully decode the AC or 2) they can=92t successfully =
validate the AC?
=20
Ideally, I=92d like to make the AC available for applications that are =
capable of using it and have applications that are not AC-enabled just =
ignore it and verify the signature on the SignedData using the PKC.  In =
the description of the =91certificates=92 field, RFC-2630 says the =
following regarding the certificates in the set: =93There may be more =
certificates than necessary, and there may be certificates sufficient to =
contain chains from two or more independent top-level certification =
authorities.=94  This seems to *imply* that compliant, but AC challenged =
applications will just ignore the AC as long as they can validate the =
signature using the PKC.  I=92m just looking for a bit of a reality =
check.  Is that the way it works in the real world?
=20
Thanks for the heads up regarding the fact that CMS specifies the 1997 =
X.509 syntax.  I=92ll go do some reading on what the differences are.  =
Depending on the answers to the questions above, it may not matter =
though.  We=92re writing our own X.509 2000 compliant application to =
process the ACs.  At this point, it=92s probably acceptable to say that =
other third-party AC-enabled applications must support X.509 2000 to =
process our SignedData blob.  As I mentioned above, as long as commonly =
available 3rd party validation software doesn=92t choke, it=92s ok if it =
ignores the AC.
=20
Chris
=20
-----Original Message-----
From: Pawling, John [mailto:[e-mail]]
Sent: Tuesday, August 28, 2001 3:43 PM
To: 'Christopher S. Francis'; [e-mail]
Subject: RE: Use of attribute certificates in SignedData
=20
Chris,=20
RFC2630 specifies that an AttributeCertificate can be included in the =
signedData certificates attrCert field.  Please note that RFC2630 =
specifies the 1997 X.509 Attribute Certificate syntax (that is =
incompatible with the 2000 X.509 Attribute Certificate syntax).  Also, =
please note that RFC2630 states the following requirement regarding the =
value to be placed in the signedData version field: "If attribute =
certificates are present, then the value of version shall be 3." =20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
John Pawling, [e-mail]=20
Getronics Government Solutions, LLC=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20

------=_NextPart_000_007A_01C12FE6.E8559170
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C12FE6.E13B2DA0">
<title>RE: Use of attribute certificates in SignedData</title>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:"Comic Sans MS";
	panose-1:3 15 7 2 3 3 2 2 2 4;
	mso-font-charset:0;
	mso-generic-font-family:script;
	mso-font-pitch:variable;
	mso-font-signature:647 0 0 0 159 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
h1
	{mso-style-next:Normal;
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:1;
	font-size:16.0pt;
	font-family:Arial;
	mso-font-kerning:16.0pt;
	font-weight:bold;}
p.MsoBodyText, li.MsoBodyText, div.MsoBodyText
	{margin-top:13.2pt;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:1.0in;
	margin-bottom:.0001pt;
	line-height:120%;
	mso-pagination:widow-orphan;
	font-size:11.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-font-kerning:11.0pt;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p
	{margin-right:0in;
	mso-margin-top-alt:auto;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle16
	{mso-style-type:personal-reply;
	mso-ansi-font-size:12.0pt;
	mso-ascii-font-family:"Comic Sans MS";
	mso-hansi-font-family:"Comic Sans MS";
	mso-bidi-font-family:Arial;
	color:navy;}
p.Heading1NoTOC, li.Heading1NoTOC, div.Heading1NoTOC
	{mso-style-name:"Heading 1 No TOC";
	mso-style-parent:"Heading 1";
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	text-align:center;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:1;
	font-size:14.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	mso-font-kerning:14.0pt;
	font-weight:bold;
	mso-bidi-font-weight:normal;}
p.TableText, li.TableText, div.TableText
	{mso-style-name:"Table Text";
	margin-top:3.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	line-height:110%;
	mso-pagination:widow-orphan lines-together;
	font-size:10.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-font-kerning:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans =
MS"'>John,<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>Understood.<span
style=3D"mso-spacerun: yes">&nbsp; </span>So I&#8217;m interpreting =
RFC-2630 correctly
then.<span style=3D"mso-spacerun: yes">&nbsp; </span>When I said I was
considering putting the AC in the &#8216;certificates&#8217; field, I =
really meant that I
wanted to include it as an attrCert choice in the =
&#8216;certificates&#8217; field. <o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>So
if that&#8217;s the &#8220;correct&#8221; place to put the AC according =
to 2630, what experience
have people had with real-world applications that process =
SignedData?<span
style=3D"mso-spacerun: yes">&nbsp; </span>Will applications/toolkits =
that
understand how to verify the signature on SignedData, but do not process =
ACs typically
just ignore the AC if it&#8217;s included or do they choke because: 1) =
they can&#8217;t
successfully decode the AC or 2) they can&#8217;t successfully validate =
the AC?<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>Ideally,
I&#8217;d like to make the AC available for applications that are =
capable of using it
and have applications that are not AC-enabled just ignore it and verify =
the
signature on the SignedData using the PKC.<span style=3D"mso-spacerun:
yes">&nbsp; </span>In the description of the &#8216;certificates&#8217; =
field, RFC-2630
says the following regarding the certificates in the set: &#8220;There =
may be more
certificates than necessary, and there may be certificates sufficient to
contain chains from two or more independent top-level certification =
authorities.&#8221;<span
style=3D"mso-spacerun: yes">&nbsp; </span>This seems to *<b><span
style=3D'font-weight:bold'>imply</span></b>* that compliant, but AC =
challenged
applications will just ignore the AC as long as they can validate the =
signature
using the PKC.<span style=3D"mso-spacerun: yes">&nbsp; </span>I&#8217;m =
just looking
for a bit of a reality check.<span style=3D"mso-spacerun: yes">&nbsp; =
</span>Is
that the way it works in the real =
world?<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>Thanks
for the heads up regarding the fact that CMS specifies the 1997 X.509
syntax.<span style=3D"mso-spacerun: yes">&nbsp; </span>I&#8217;ll go do =
some reading on
what the differences are.<span style=3D"mso-spacerun: yes">&nbsp;
</span>Depending on the answers to the questions above, it may not =
matter
though.<span style=3D"mso-spacerun: yes">&nbsp; </span>We&#8217;re =
writing our own
X.509 2000 compliant application to process the ACs.<span =
style=3D"mso-spacerun:
yes">&nbsp; </span>At this point, it&#8217;s probably acceptable to say =
that other third-party
AC-enabled applications must support X.509 2000 to process our =
SignedData blob.<span
style=3D"mso-spacerun: yes">&nbsp; </span>As I mentioned above, as long =
as
commonly available 3<sup>rd</sup> party validation software =
doesn&#8217;t choke, it&#8217;s
ok if it ignores the AC.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans =
MS"'>Chris<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle16><font size=3D3 =
color=3Dnavy
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblack
face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;color:black'>-----Original
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Pawling, John
[mailto:[e-mail]]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, August 28, =
2001
3:43 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Christopher S. =
Francis';
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Use of =
attribute
certificates in SignedData</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack face=3D"Times =
New Roman"><span
style=3D'font-size:10.0pt;color:black'>Chris,</span></font><font =
color=3Dblack><span
style=3D'color:black'> </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack face=3D"Times =
New Roman"><span
style=3D'font-size:10.0pt;color:black'>RFC2630 specifies that an
AttributeCertificate can be included in the signedData certificates =
attrCert
field.&nbsp; Please note that RFC2630 specifies the 1997 X.509 Attribute
Certificate syntax (that is incompatible with the 2000 X.509 Attribute
Certificate syntax).&nbsp; Also, please note that RFC2630 states the =
following
requirement regarding the value to be placed in the signedData version =
field:
&quot;If attribute certificates are present, then the value of version =
shall be
3.&quot;&nbsp; </span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p style=3D'margin-left:.5in'><font size=3D2 color=3Dblack face=3D"Times =
New Roman"><span
style=3D'font-size:10.0pt;color:black'>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
</span></font><font color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>John Pawling, [e-mail] =
</span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>Getronics Government Solutions, LLC </span></font><font
color=3Dblack><span style=3D'color:black'><br>
</span></font><font size=3D2 color=3Dblack><span =
style=3D'font-size:10.0pt;
color:black'>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</sp=
an></font><font
color=3Dblack><span style=3D'color:black'> </span></font><font =
color=3Dblack><span
style=3D'color:black;mso-color-alt:windowtext'><o:p></o:p></span></font><=
/p>

</div>

</body>

</html>

------=_NextPart_000_007A_01C12FE6.E8559170--



Received: by above.proper.com (8.11.6/8.11.3) id f7SJgos06630 for ietf-smime-bks; Tue, 28 Aug 2001 12:42:50 -0700 (PDT)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7SJgnD06626 for <[e-mail]>; Tue, 28 Aug 2001 12:42:49 -0700 (PDT)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <Q36A7VW3>; Tue, 28 Aug 2001 15:42:58 -0400
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "'Christopher S. Francis'" <[e-mail]>, [e-mail]
Subject: RE: Use of attribute certificates in SignedData
Date: Tue, 28 Aug 2001 15:42:55 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12FF9.A1C7E9C0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

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

Chris,

RFC2630 specifies that an AttributeCertificate can be included in the
signedData certificates attrCert field.  Please note that RFC2630 specifies
the 1997 X.509 Attribute Certificate syntax (that is incompatible with the
2000 X.509 Attribute Certificate syntax).  Also, please note that RFC2630
states the following requirement regarding the value to be placed in the
signedData version field: "If attribute certificates are present, then the
value of version shall be 3."  

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

------_=_NextPart_001_01C12FF9.A1C7E9C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Use of attribute certificates in SignedData</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Chris,</FONT>
</P>

<P><FONT SIZE=3D2>RFC2630 specifies that an AttributeCertificate can be =
included in the signedData certificates attrCert field.&nbsp; Please =
note that RFC2630 specifies the 1997 X.509 Attribute Certificate syntax =
(that is incompatible with the 2000 X.509 Attribute Certificate =
syntax).&nbsp; Also, please note that RFC2630 states the following =
requirement regarding the value to be placed in the signedData version =
field: &quot;If attribute certificates are present, then the value of =
version shall be 3.&quot;&nbsp; </FONT></P>

<P><FONT =
SIZE=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
</FONT>
<BR><FONT SIZE=3D2>John Pawling, [e-mail] </FONT>
<BR><FONT SIZE=3D2>Getronics Government Solutions, LLC </FONT>
<BR><FONT =
SIZE=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT=
>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C12FF9.A1C7E9C0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7SHk8104223 for ietf-smime-bks; Tue, 28 Aug 2001 10:46:08 -0700 (PDT)
Received: from emerald.lightlink.com (emerald.lightlink.com [205.232.34.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7SHk7D04219 for <[e-mail]>; Tue, 28 Aug 2001 10:46:07 -0700 (PDT)
Received: from [209.216.70.29] (perm70-29.ij.net [209.216.70.29] (may be forged)) by emerald.lightlink.com (8.8.8/8.8.8) with SMTP id NAA11320 for <[e-mail]>; Tue, 28 Aug 2001 13:46:08 -0400
From: "Christopher S. Francis" <[e-mail]>
To: <[e-mail]>
Received: from no.name.available by [209.216.70.29] via smtpd (for smtp.lightlink.com [205.232.34.14]) with SMTP; 28 Aug 2001 17:47:07 UT
Subject: Use of attribute certificates in SignedData
Date: Tue, 28 Aug 2001 13:46:08 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0062_01C12FC7.CA45E460"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0062_01C12FC7.CA45E460
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I have a question for the group concerning attribute certificates.=20
=20
Is there an accepted location to put an attribute certificate associated =
with the signer in the SignedData data structure?  I have a SignedData =
object and I=92m considering putting an attribute certificate associated =
with the signer in the =91certificates=92 field of SignedData in =
addition to the PKC of the signer. =20
=20
Is that a =93philosophically correct=94 location?  I have some concern =
about standard decoders being able to successfully decode the SignedData =
structure if includes an attribute certificate.  Other options include =
burying the certificate in the encapsulated content or including it as a =
Signed or UnSigned attribute.
=20
I=92d appreciate any advice and or lessons learned that you can offer.  =
Thanks in advance. =20
=20
Chris Francis

------=_NextPart_000_0062_01C12FC7.CA45E460
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C12FC7.C1429C50">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
	{font-family:"Comic Sans MS";
	panose-1:3 15 7 2 3 3 2 2 2 4;
	mso-font-charset:0;
	mso-generic-font-family:script;
	mso-font-pitch:variable;
	mso-font-signature:647 0 0 0 159 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
h1
	{mso-style-next:Normal;
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:1;
	font-size:16.0pt;
	font-family:Arial;
	mso-font-kerning:16.0pt;}
p.MsoBodyText, li.MsoBodyText, div.MsoBodyText
	{margin-top:13.2pt;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:1.0in;
	margin-bottom:.0001pt;
	line-height:120%;
	mso-pagination:widow-orphan;
	font-size:11.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-font-kerning:11.0pt;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle15
	{mso-style-type:personal-compose;
	mso-ansi-font-size:12.0pt;
	mso-ascii-font-family:"Comic Sans MS";
	mso-hansi-font-family:"Comic Sans MS";
	mso-bidi-font-family:Arial;
	color:black;}
p.Heading1NoTOC, li.Heading1NoTOC, div.Heading1NoTOC
	{mso-style-name:"Heading 1 No TOC";
	mso-style-parent:"Heading 1";
	margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	text-align:center;
	mso-pagination:widow-orphan;
	page-break-after:avoid;
	mso-outline-level:1;
	font-size:14.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-fareast-font-family:"Times New Roman";
	mso-bidi-font-family:"Times New Roman";
	mso-font-kerning:14.0pt;
	font-weight:bold;
	mso-bidi-font-weight:normal;}
p.TableText, li.TableText, div.TableText
	{mso-style-name:"Table Text";
	margin-top:3.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:0in;
	line-height:110%;
	mso-pagination:widow-orphan lines-together;
	font-size:10.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-font-kerning:10.0pt;}
span.EmailStyle21
	{mso-style-type:personal;
	mso-ansi-font-size:12.0pt;
	mso-ascii-font-family:"Comic Sans MS";
	mso-hansi-font-family:"Comic Sans MS";
	mso-bidi-font-family:Arial;
	color:black;}
span.EmailStyle22
	{mso-style-type:personal;
	mso-ansi-font-size:12.0pt;
	mso-ascii-font-family:"Comic Sans MS";
	mso-hansi-font-family:"Comic Sans MS";
	mso-bidi-font-family:Arial;
	color:black;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle21><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>I
have a question for the group concerning attribute certificates. =
<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle21><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans =
MS"'>&nbsp;<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle22><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>Is
there an accepted location to put an attribute certificate associated =
with the
signer in the SignedData data structure?<span style=3D"mso-spacerun: =
yes">&nbsp;
</span>I have a SignedData object and I&#8217;m considering putting an =
attribute
certificate associated with the signer in the &#8216;certificates&#8217; =
field of
SignedData in addition to the PKC of the signer.<span =
style=3D"mso-spacerun:
yes">&nbsp; </span><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle22><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans =
MS"'>&nbsp;<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle22><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>Is
that a &#8220;philosophically correct&#8221; location?<span =
style=3D"mso-spacerun:
yes">&nbsp; </span>I have some concern about standard decoders being =
able to
successfully decode the SignedData structure if includes an attribute
certificate.<span style=3D"mso-spacerun: yes">&nbsp; </span>Other =
options include
burying the certificate in the encapsulated content or including it as a =
Signed
or UnSigned attribute.<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle22><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans =
MS"'>&nbsp;<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle22><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>I&#8217;d
appreciate any advice and or lessons learned that you can offer.<span
style=3D"mso-spacerun: yes">&nbsp; </span>Thanks in advance.<span
style=3D"mso-spacerun: yes">&nbsp; </span></span></font></span><span
class=3DEmailStyle21><font color=3Dblack face=3D"Comic Sans MS"><span
style=3D'font-family:"Comic Sans =
MS"'><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle21><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans =
MS"'>&nbsp;<o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle21><font size=3D3 =
color=3Dblack
face=3D"Comic Sans MS"><span =
style=3D'font-size:12.0pt;font-family:"Comic Sans MS"'>Chris
Francis</span></font></span><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0062_01C12FC7.CA45E460--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7SBPb613775 for ietf-smime-bks; Tue, 28 Aug 2001 04:25:37 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7SBPYD13771 for <[e-mail]>; Tue, 28 Aug 2001 04:25:35 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03717; Tue, 28 Aug 2001 07:24:14 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-x400wrap-04.txt
Date: Tue, 28 Aug 2001 07:24:14 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Securing X.400 Content with S/MIME
	Author(s)	: P. Hoffman, C. Bonatti, A. Eggen
	Filename	: draft-ietf-smime-x400wrap-04.txt
	Pages		: 
	Date		: 27-Aug-01
	
This document describes a protocol for adding cryptographic signature
and encryption services to X.400 content.

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

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-x400wrap-04.txt".

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7S9uXS07999 for ietf-smime-bks; Tue, 28 Aug 2001 02:56:33 -0700 (PDT)
Received: from swordfish.nexor.co.uk (swordfish.nexor.co.uk [193.63.53.54]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7S9uUD07995 for <[e-mail]>; Tue, 28 Aug 2001 02:56:30 -0700 (PDT)
Received: by swordfish.nexor.co.uk with Internet Mail Service (5.5.2653.19) id <PBCFR5VM>; Tue, 28 Aug 2001 10:55:30 +0100
Message-ID: <[e-mail]>
From: Graeme Lunt <[e-mail]>
To: "'jimsch'" <[e-mail]>, "'ietf-smime'" <[e-mail]>
Subject: RE: EITs in the x400-transport draft
Date: Tue, 28 Aug 2001 10:55:26 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim.

> > Could you perhaps summarize these conversations for me?
> > I did not attend the last IETF meeting, and my colleague who did
> > attend the S/MIME meeting does not have detailed notes.
> 
> [JLS]  This topic started on the list before London, basically I was
> have started to argue that the S/MIME type should generally tell you
> what the inner most content type is rather than trying to tell you what 
> this security layer is.  (I.e. map to the inner-content type attribute
> not to the contentInfo OID.)  I raised this question because I did not
> know what the S/MIME type of a signed-receipt should be if a layer of
> encryption is added to the message.  I started this line of reasoning
> based on the EITs of the X.400 world.

Thanks for the summary.

> > > I would like to propose that we remove enveloped-x400
> > > content and signed-x400 content EITs and replace it with 
> > > x400-content EITs and S/MIME types.  
> > 
> > Does this have any bearing on my comments I sent to the list about 
> > the EITS, and in particular being able to identify the inner X.400 
> > content type (e.g. P22 over P772)?
> 
> [JLS]  No, I don't remember seeing this comemnt, however it 
> would have a potential bearing on this.  The question would be should 
> all x.400 content be seen as one and the same or as different things.  
> Different things would argue for different EITs and different SMIME-Types.

> I have absolutely no preference on this issue.

Here is a repost of what I sent to the list - I did not get any feedback.

----

In terms of the EITs, it would be much more useful if the EITs for 
"wrapped X400" messages could indicate the actual X.400 content type that 
is wrapped.  Indicating to a UA that it will find X.400 rather than MIME 
is useful but if the UA then finds EDI (or even unidentified content) 
inside when expecting P22, then it hasn't really gained much.

It would be more useful if the EITs available were something like (in
smime-type notation):
signed-x400-p0
signed-x400-p2
signed-x400-p22
signed-x400-oid.<oid> (for external content types).

For X.400 EITs OIDs, you could use a OID concatenation method (as used
for ForwardedContent bodyparts) on id-eit-signedX400/id-eit-envelopedX400
for
external content types. 

The main requirement I see is for a distinction between p22 and external
content types.

This provides me with more information about the internal X.400 content that
I am likely to find, and allows user agents to choose the appropriate form
for displaying the encapsulated content type.

This provides the same information as the contentHints.contentType ESS 
extension, but is available to the MTS. The MTS could then act on this EIT 
e.g. in a military environment, CMS wrapped P772 messages could be 
identified over CMS wrapped P22 messages.

----

It is a slightly different point, but ultimately trying to get useful 
information from the inner-most content type. In the X.400 world, I 
would just like to have an EIT for
* signed
* enveloped
* receipt
* P22
* P772 
* ... (other content types)

- that is one EIT for the inner-most content type plus one or more EITs
for the services applied.

However mapping to an S/MIME type then becomes more tricky - hence the 
slightly inelegant stuff I mentioned in my previous message.



Graeme







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7PHAKN08626 for ietf-smime-bks; Sat, 25 Aug 2001 10:10:20 -0700 (PDT)
Received: from [165.227.249.20] (ip20.proper.com [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7PHAGD08620 for <[e-mail]>; Sat, 25 Aug 2001 10:10:16 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510032eb7ad8c582411@[165.227.249.20]>
Date: Sat, 25 Aug 2001 10:09:51 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: 8 August 2001 S/MIME WG Minutes
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[[Forwarded for Rich Nicholas, the proficient minutes-taker.]]

This message includes the official minutes of the IETF S/MIME Working
Group (WG) meeting held on 8 August 2001 in London, England.  Briefing
slides will be available from <ftp://ftp.ietf.org/ietf/smime/>.  The
briefing presenters have reviewed these minutes.  Reported by Rich
Nicholas.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Introductions - Russ Housley

Russ welcomed the attendees and presented the working group's agenda as
follows.

Introductions                       Russ Housley
Working Group Status                Russ Housley
Interoperability Matrix             Jim Schaad
CMS and ESS Examples                Paul Hoffman
Updates to CMS                      Russ Housley
Updates to CERT & MSG               Blake Ramsdell
Symmetric Key Distribution          Sean Turner
X.400 and CMS                       Chris Bonatti
Reuse of Content Encryption Keys    Steve Farrell
AES and RSA-OAEP                    Jim Schaad
Elliptic Curve Crypto               Simon Blake-Wilson
S/MIME Gateway Protocol             Blake Ramsdell
NIST S/MIME Activities              Mike Chernick
XML Electronic Signature Syntax     Denis Pinkas
CSP and Time Stamps                 Denis Pinkas
S/MIME Freeware Library             Rich Nicholas
Wrap up                             Russ Housley

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

S/MIME Working Group Status - Russ Housley

Russ listed the RFCs generated by the S/MIME WG:
RFC 2630 Cryptographic Message Syntax (CMS), R. Housley, June 1999
RFC 2631 Diffie-Hellman Key Agreement Method, E. Rescorla, June 1999
RFC 2632 S/MIME Version 3 Certificate Handling, B. Ramsdell, June 1999
RFC 2633 S/MIME Version 3 Message Specification, B. Ramsdell, June 1999
RFC 2634 Enhanced Security Services for S/MIME, P. Hoffman, June 1999
RFC 2785 Methods for Avoiding the "Small-Subgroup" Attacks on the
             Diffie-Hellman Key Agreement Method for S/MIME,
             R. Zuccherato, March 2000.  [Informational]
RFC 2876 Use of the KEA and SKIPJACK Algorithms in CMS, J. Pawling,
             July 2000.  [Informational]
RFC 2984 Use of the CAST-128 Encryption Algorithm in CMS, C. Adams,
	      October 2000.
RFC 3058 Use of the IDEA Encryption Algorithm in CMS, S. Teiwes,
             P. Hartmann, and D. Kuenzi, February 2001.  [Informational]

In addition to the RFCs, the following three documents are in the RFC
Editor's queue:
esformats   Electronic Signature Formats for long term electronic
  		signatures.  D. Pinkas, J. Ross, and N. Pope.
espolicies  Electronic Signature Policies.  J. Ross and N. Pope.
seclabel    Implementing Company Classification Policy
  		with the S/MIME Security Label.  W. Nicolls.

The seclabel document is on hold in the editor's queue pending the PKIX
Attribute Certificate Profile, so the seclabel document can cite it as
a reference.  The PKIX Attribute Certificate Profile was recently sent
to the RFC editor.

Russ outlined the requirements for advancing the standards track RFCs
from Proposed Standards to Draft Standards:
1) Meet requirements documented in RFC 2026
2) Stable, mature, and useful specification
3) At least two independent and interoperable implementations from
different code bases
4) Draft Standards cannot reference Proposed Standard RFCs or
Experimental RFCs, so the aforementioned RFCs are blocked until the PKIX
Certificate and CRL Profile "Son-of-RFC 2459" Internet-Draft
<draft-ietf-pkix-new-part1-08.txt> progresses to Draft Standard.
Son-of-RFC 2459 is presently with the Security Area Director, awaiting
IETF Last Call.

Regarding requirement #3, Jim Schaad has developed an interoperability
matrix for CMS, Diffie-Hellman, MSG, CERT, and ESS documents.  The
interoperability matrix is posted on the IMC web site at the following
URL:  <http://www.imc.org/ietf-smime/interop-matrix.html>.  Paul Hoffman
offered to coordinate interoperability testing and compile CMS and ESS
Examples document.

Blake Ramsdell noted that the Examples of S/MIME Messages Internet-Draft
is a very large document and asked if there is a precedent for such a
large document.  Paul Hoffman answered that there are larger RFCs, but
there is no document that he has ever found like the examples document.
Blake restated his question as are we approaching it the right way, is
there a protocol that has been profiled as extensively as this?  Paul
answered that no, not that he's aware of.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Interoperability Matrix - Jim Schaad

Jim briefed on the status of the interoperability matrix.  The matrix
was updated to reflect the new CMS and CMS Algorithms Internet-Drafts.
CMS now has 96 MUST statements and 79 optional requirements or
"features."  Of those requirements, implementations have demonstrated
interoperability of 56% of the MUST statements and 48% of the features.
In the CMS Algorithms draft, there are now 46 MUST statements and 15
optional features.  Of those, interoperability has been successfully
demonstrated with 93% of the MUST statements and 93% of the optional
features.
For the other unchanged specifications:
RFC 2631, Diffie-Hellman, only 1 of the 13 requirements has passed
interoperability testing.
RFC 2632, CERT, 16 of the 21 requirements have passed.
RFC 2633, MSG, 17 of the 61 requirements have passed.
RFC 2634, ESS, 27 of the 81 requirements have passed.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

CMS and ESS Examples - Paul Hoffman

Paul briefly discussed status of the "Examples of S/MIME Messages"
Internet-Draft <draft-ietf-smime-examples-06.txt>, 25 February 2001.
Paul stated that an updated draft was not posted prior to the Internet
Draft cut-off due to time constraints.  An updated version of the
document is forthcoming that includes changes that have been discussed
on the ietf-smime-examples mail list.  Only John Pawling and Jim Schaad
have provided active input on the examples.  Paul knows there are many
more S/MIME implementations out there and requests the other S/MIME
implementers provide feedback as to whether their software can
process the examples, both positive or negative.  The feedback can
either be public on the ietf-smime-examples mail list or privately to
Paul.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Updates to CMS - Russ Housley

Russ presented the status of CMS.  CMS is being split into two
documents, with the algorithms being moved into a separate document.
The proposed revision to CMS, <draft-ietf-smime-rfc2630bis-01.txt>, has
been discussed on the mail list.  A new draft will be forthcoming once
the two remaining issues have been resolved.  The CMS Algorithms draft,
<draft-ietf-smime-cmsalg-01.txt>, has been discussed on the mail list as
well.  A new draft will be released when the RFC2630bis open issues are
addressed.  Russ hopes that these issues will be resolved during this
meeting.

The two remaining open issues are:
1.  Should CMS specify any mandatory to implement algorithms?
2.  Are version numbers handled correctly?

Regarding issue #1, a protocol cannot say:
"Implementations of the CMS MUST support the mandatory to implement
algorithms specified in [CMSALG], or its successor."  There are two
possible alternative remedies:  either preserve the MUST and SHOULD
statements for algorithms in CMS, or remove the algorithm-specific
requirements from CMS.  Russ presented the pros and cons of both
alternatives.  Requiring mandatory to implement algorithms ensures that
protocols that employ CMS can inherit the algorithms from CMS without
further specification.  Removal of mandatory to implement algorithms
makes the CMS protocol stable, but places the burden of algorithm
specification on protocols that employ CMS.  Russ noted that this second
alternative is similar to the PKIX Certificate and CRL Profile and that
RFC 2633 already includes necessary statements for S/MIME.  Russ noted
that this issue has been discussed on the mail list, but only a few
people have expressed an opinion.

Paul Hoffman stated this is mostly a political issue, not a technical
one, so he hasn't expressed an opinion.  Another working group member
noted that protocol implementers and users typically have different
agendas and users of CMS implementations might feel more strongly about
the need to require specific algorithms to promote interoperability.

Russ polled the working group members as to which alternative they
preferred.  The majority preferred the second alternative to require no
mandatory algorithms in CMS.

Russ then presented the following example to illustrate issue #2:
Current EnvelopedData version processing:
      IF ((originatorInfo is present) AND
           (any version 2 attribute certificates are present)) OR
           (any RecipientInfo structures include pwri) OR
           (any RecipientInfo structures include ori)
      THEN version is 3
      ELSE
           IF (originatorInfo is present) OR
                (unprotectedAttrs is present) OR
                (any RecipientInfo structures are a version other than 0)
           THEN version is 2
           ELSE version is 0

Currently, the version number in a complex structure like EnvelopedData
is set to ensure that all subordinate components can be decoded in a
single pass.  The outer version number indicates to the application if
it can decode all of the inner subcomponents.  The alternative is to let
the version number in each subordinate component handle changes within
that component.  Based on discussions on the list, many implementations
are not prepared for decode errors after the higher-level version check.

Jim Schaad noted that based on discussions on the list, Peter Gutmann's
implementation is the only one to check the EnvelopedData version prior
to decoding.  Most other implementations attempt to decode the entire
structure and only check the version number if a decode error occurs.
Other working group members noted that whether an implementation
encounters an error decoding the EnvelopedData or checks the version
number prior to decoding, the result is the same.  The version number at
least gives information as to the cause of the decode error which is
useful for debugging.

Russ polled the working group members as to which alternative they
preferred.  Only a few members expressed a preference, so Russ left the
issue open.

Blake Ramsdell noted that there are quite a lot of optional features in
CMS.  He asked whether those optional features could be moved from the
base CMS document into a third CMS protocol document.  The consensus was
that it was not worth doing that at this time, but could be done at the
next level (when the documents go from proposed standards to draft
standards).

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Updates to CERT & MSG - Blake Ramsdell

Blake briefed the status of the updates to RFCs 2633 and 2632.  Blake
noted that new versions of both RFCs are forthcoming and outlined the
changes.
Changes to RFC 2633 (MSG):
      RFC 2633                    2633bis
      MUST DSA                    Receiver MUST DSA and RSA
      SHOULD RSA                  Sender MUST DSA or RSA

      MUST DH                     SHOULD DH
      SHOULD RSA                  MUST RSA

      Individual alg specs        CMS Alg

Changes to RFC 2632 (CERT):
      RFC 2632                    2632bis
      MUST DSA                    MUST DSA
      SHOULD SHA1 w/RSA           MUST SHA1 w/RSA
      SHOULD MD2/MD5 w/RSA        MAY MD2/MD5 w/RSA

Jim Schaad asked if the requirement for MD2 could be eliminated.  Paul
Hoffman suggested that the MD5 requirement should be changed to SHOULD
rather than MAY, but that MD2 could be left as a MAY, or dumped.

A question was asked whether the MUST DSA statement in 2632bis required
applications to implement DSA or rather, only if the application
implements DSA, that it be implemented in accordance with CMS Alg.  The
member was particularly concerned about constrained mobile devices not
being able to implement DSA.  The answer from Blake, and seconded by
Russ, was that at a previous working group meeting it was decided that
compliant applications must be capable of verifying signatures signed
using both algorithms.

Jim asked if 2632bis should reference the PKIX algorithms Internet-Draft
or CMS Alg?  Blake answered that it will be changed to refer to the PKIX
algorithms document.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Symmetric Key Distribution - Sean Turner

Sean briefed the status of the S/MIME Symmetric Key Distribution
Internet-Draft, <draft-ietf-smime-symkeydist-05.txt>.  Working group
Last Call was issued on 1 May 2001.  No comments were received on the
list, some comments were sent directly to Sean.  Almost all of the
comments received were editorial.  Based on the comments, the following
changes were made:
- Moved section "Using the Group Key" (section 8) to section 1.3
- Clarified language for the conformance table in section 3.1
- Restricted Attribute Certificates to be version 2
- Made SKDAlgRequest syntax NULL
- Added information pointing out that there are multiple ways to wrap
   SignedData or EnvelopedData (to MIME wrap or not)
- Modified wording in section 4
- Copied wording from CMS Algs about symmetric key generation
- Expanded wording in Security Considerations

One of the suggestions was to change the name.  Sean suggested "CMS
Symmetric Key Management and Distribution."  No one objected to the
name change.

Sean asked whether the document needed to recycle through working group
Last Call.  Russ answered no; it is ready to go forward to the Area
Directors.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

X.400 and CMS - Chris Bonatti

Chris presented the status of the CMS X.400 Internet-Drafts.  New
versions of both "Securing X.400 Content with S/MIME",
<draft-ietf-smime-x400wrap-03.txt>, and "Transporting S/MIME Objects in
X.400," <draft-ietf-smime-x400transport-03.txt> were distributed on
19 July 2001.

The x400wrap document specifies how to protect X.400 content with CMS
objects.  It is roughly analogous to RFC 2633 (MSG).  The changes
incorporated into the -03 version include:
- Altered the requirements for CMS options (2.2 and 2.3) to align with
   the mandatory algorithms agreed for the Draft Standard work.
- Deleted from section 2.3 the statement that:  The size of the private
   key is determined during key generation.  This statement is algorithm
   specific and not pertinent to the topic at hand.  The same comment may
   be raised against 2633bis.
- Clause 2.4.2 was updated to clarify the requirement in terms of
   MAY/SHOULD/MUST.  The same comment may be raised against 2633bis.
- Text of 3.2 through 3.4 to remove intervening layers ContentInfo
   wrappers.
- Revised text of 3.2.1, 3.3.1, and 3.4.1 to reflect correct values of
   smime-type parameters as per the discussion on the mailing list.

A single editorial bug is known to exist in the -03 version:  The second
paragraph 3.2.1 needs to be updated to specify the smime-type parameter
be set to "signed-x400" instead of "signed-data."  This typo is minor
has been discussed on the list.

The x400transport document specifies how to package CMS objects for
transport by X.400 Message Transfer Agents (MTAs).  It is separate from
the X.400 wrapping draft to encourage use of RFC 822/MIME content in
X.400 communities.  The changes incorporated into the -03 version
include:
- Clarified and corrected text of 2.3 describing how to forward CMS
   objects in X.420 IPMS messages.
- Assigned OID values for EITs in section 2.5.
- New text was added in section 2.6 to address use of X.400 EoS that may
   have impact on use of CMS security.
   -- MTS Conversion Services:  Does not apply to CMS content, but could
      result in destruction of the message or breaking the signature
      function.  Conversion Prohibition EoS SHOULD be selected.
   -- Message Redirection Services:  The enveloped-data type requires an
      instance of RecipientInfo for each intended recipient or alternate
      recipient.  Some types of redirection are not subject to originator
      control.  If ORAR is used, an appropriate RecipientInfo element
      SHOULD be generated.
   -- DL Expansion:  The enveloped-data type requires processing by a
      secure mail list expander as described in ESS.  When transporting
      CMS objects within an X.400 environment, the DL Expansion
      Prohibited service SHOULD be selected.

Chris believes both documents are ready for working group Last Call.
Russ agreed to initiate working group Last Call once the typo is fixed
in the X400wrap document.

Jim Schaad commented that a couple of small issues remain in both
documents.  Paul Hoffman believes these new issues need to be resolved,
incorporated into new versions of the documents, and then sent to the
mail list.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

AES and RSA-OAEP in CMS - Jim Schaad

Jim presented a briefing on the updates to the "Use of the AES
Encryption Algorithm and RSA-OAEP Key Transport in CMS" Internet-Draft,
<draft-ietf-smime-aes-alg-02.txt>.  The new draft includes the
following changes:
- Removed the AuthenticatedData section.  Since RSA is a key transport
   mechanism, there was no way to authenticate who sent the key.
- Added an AES overview.
- Added place holder examples for the key wrap algorithm -- awaiting
   Object Identifiers from NIST.
- Added AES EncryptedData section.

Jim listed the following work items as things left to be done:
- Get key wrap algorithm OID assigned by NIST
- Once done, complete AES key wrap examples
- Add ASN.1 appendix to define a couple of ASN.1 items that RFC 2437
   omits.
- Resolve password recipient info key wrap issues

Other algorithms that may be added to the document at a later date
include the RSA Probabilistic Signature Scheme (PSS) algorithm and the
SHA-2 hash algorithm.  The specification of the PSS algorithm has not
progressed, and its OID and definitions are still unspecified.  The
SHA-2 algorithm details for use with DSA have not been released by NIST
at this time.  Use of SHA-2 with RSA is awaiting specification of the
PSS algorithm.

Blake asked when would the working group know anything about SHA-2?
Jim answered that the issue was brought up with RSA at the last working
group and nothing has been done since.  Russ commented that PSS is still
being coordinated with the various communities that will use it.  Russ
was asked if PSS will be specified in a PKCS document and he answered
that yes it would.

A comment was made that the SHA-2 draft has been out for a long time.
Jim clarified that the question was when will the DSA key sizes and OIDs
for DSA with SHA-2 be known.  Mike Chernick noted that NIST completed
the specification of SHA-256, but he didn't know when the DSA
specification would be updated.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Elliptic Curve Cryptography - Simon Blake-Wilson

Simon presented a brief synopsis of the state of the "Use of ECC
Algorithms in CMS" Internet-Draft, <draft-ietf-smime-ecc-06.txt>,
7 May 2001.  The document has completed both working group Last Call
and IETF Last Call.

Russ took an action to follow up with the Area Directors on this
document and the others (rcek and domsec) that are awaiting the ADs
attention.

Simon noted that three independent implementers have conducted
interoperability testing.  Simon is currently working on an examples
draft.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

S/MIME Gateway Protocol - Blake Ramsdell

Blake briefed the working group on the "S/MIME Gateway Protocol",
Internet-Draft, <draft-ramsdell-enc-smime-gateway-00.txt>,
12 July 2001.  The protocol specifies how to use S/MIME to perform
server-to-server (gateway) encryption between cooperating domains.  The
Massachusetts Health Data Consortium led the development of the
protocol and its prototyping in order to comply with the United States
Health Information Protection Act (HIPA).  Six S/MIME server vendors,
Tumbleweed, Baltimore Technologies, DICA, Vanguard, Tenfour, and VIASEC
participated in the effort.  Deloitte & Touche conducted an independent
interoperability test and evaluation of the vendor products.

Blake asked the working group what should be done with the
specification.  Currently it is an independent Internet-Draft under his
name.  Should it be a working group work item?  Should it be considered
a profile of DOMSEC?

Russ asked the working group members, who read the document?  Only a
couple of members had read it.  Paul Hoffman commented that this
document is an important document since it increases the use of S/MIME,
but without having to burden users with the details and complexity.
Paul recommends that all working group members read the document and
encourage similar use of S/MIME wherever possible.

A comment was made that if this document is to be made a working group
work item that it should be aligned with DOMSEC.  Also, if encryption is
the only service provided by this solution, isn't this solution
vulnerable to a man-in-the-middle attack?  Blake responded by noting
that the key management for this solution is handled outside the
document.

The same individual asked Paul why SMTP over TLS was not considered.
Paul answered that SMTP/TLS is ok, but it's point-to-point, so if
multiple SMTP hops are involved, each hop would require a separate TLS
session.  In general, Paul felt that S/MIME implementations are more
widely available then implementations of SMTP over TLS.

A comment was made that the man-in-the-middle attack mentioned earlier
isn't an issue since the To addressee's domain is used to find the
correct certificate for the intended recipient.

Russ asked if Bill Ottaway had looked at DOMSEC in comparison with
Blake's document.  Bill had not.  Russ requested Bill post a comparison
to the list and the working group can go from there.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

NIST S/MIME Activities - Mike Chernick

Mike briefed the working group on the current S/MIME activities at the
U.S. National Institute of Standards and Technology (NIST).  Mike
described the mission of his group as "to accelerate deployment of
secure interoperable S/MIME products."  They are currently working on
three major projects:  an in-house laboratory, the S/MIME v3 client
profile, and an internet-based S/MIME test facility.

The first purpose of the S/MIME v3 profile is to identify the subset of
S/MIME v3 specifications that helps to assure interoperability,
promotes secure communications at reasonable cost, and serves as a
basis for test development.  The second purpose of the profile is to
serve as guidance for COTS product procurement and development.  The
profile is relatively short (17 pages) and is currently out for public
comment until mid-September 2001.  The profile is available at the
following URL:
http://csrc.ncsl.nist.gov/pki/smime/draft_SMIMEProfile.pdf

The profile specifies the mandatory parts of RFCs 2630, 2632, and 2633,
except Diffie-Hellman key agreement not required.  The mandatory CMS
algorithms are required, plus the profile requires support for both RSA
(V1.5, RFC 2313) and DSA (FIPS 186-2) digital signatures.  Key sizes of
at least 1024 bits for RSA and DSA are required.  Use of Diffie-Hellman
keys and derivation of KEKs as defined in RFC 2631 is encouraged but
NOT required.

The profile requires selected features from RFC 2634, Enhanced Security
Services, including Signed Receipts processing:  request (non-third
party) signed receipt, generate signed receipt upon request, and match
signed receipt to original message.  The profile also requires that the
mlExpansionHistory attribute MUST be processed.

The profile has the following message generation requirements:
- Send "clear" signed messages that include generation of SignerInfo,
   SMIMECapabilities Attribute, and sending of user certs and CRLs
- Send encrypted message
- Send signed and encrypted messages
- Send to multiple recipients
The profile requires clients to support receiving and processing both
"clear" and "opaque" signed messages and receiving and decrypting
messages sent to multiple recipients.

The profile requires implementations to construct certification paths
between accepted trust points and the sender's or intended recipient's
certificates.  Tests will include paths with multiple CA certificates.
Testing will require use of LDAP and the processing of the standard
directory attributes (RFC 2587).  The profile requires that client
perform path validation in accordance with RFC 2459, Section 6.

Mike was asked if the profile will be changed to require son-of-RFC2459,
rather than RFC 2459.  Mike answered yes.  In general, the profile will
be updated to require the latest version of the various specifications,
as practical.

The automated S/MIME test facility is currently being developed by NIST
using the Getronics S/MIME Freeware Library (SFL) as reference
implementation.  The test facility will test scenarios to cover S/MIME
v3 profile requirements and options, but NOT out-of-scope S/MIME
features.  The test facility will ensure conformance of vendor
implementations to S/MIME v3 client profile.  Information and
instructions will be available over the web; SMTP will be used for
testing.  The automated test facility will support both originator and
recipient roles, but will require "human scoring" and self-scoring for
some tests.  The automated test facility will help identify ambiguities
and errors in IETF specifications, the NIST profile, and the SFL
reference code.

Some notes about the automated S/MIME test facility are:
- Objective testing wherever possible
- Anonymous testing possible
- Results only to remote tester
- All required communications through e-mail
- Not publishing remote tester's certificates and CRLs
- Using test policy OIDs

Mike also presented the test facility architecture and walked through
several sample scenarios.

More information about the NIST S/MIME group can be found on their web
site: http://csrc.nist.gov/pki/smime

Mike was asked if people outside the United States will be able to use
the automated test facility, and answered yes.
Blake Ramsdell asked if successful tests would be published.  Mike
answered that test results may possibly be published.
Blake asked if the purpose of this testing is to test and certify S/MIME
products for the U.S. government, in addition to FIPS 140?  Mike
answered that the purpose of this testing is to encourage interoperable
implementations, and is much more informal than FIPS 140.
Blake asked for clarification if there will be a requirement for U.S.
government agencies to only use products that pass the NIST S/MIME
testing.  Mike answered certainly not at this point -- that is not their
intention.

Simon asked how the algorithm recommendations in the S/MIME v3 profile
relate to FIPS 186?  Mike answered that the algorithms are aligned with
FIPS 186.  Tim Polk seconded that answer and noted that the profile
allows optional algorithms such as AES, to position the profile for the
future.

Russ asked if a U.S. federal agency could require, in a procurement
document, S/MIME implementations that pass this testing.  Tim clarified
that an agency could require S/MIME implementations that match the
profile.  Tim suggested that one way a vendor could demonstrate profile
compliance would be to pass the conformance tests.  Tim stated that NIST
will not perform any product testing nor certify any results.

As a follow-up, Simon asked if there will be a FIPS 186-3, that permits
PKCS v1.5?  Tim answered yes.  Simon also asked if we can make
assumptions about what the FIPS on key management is going to say?  Tim
answered no, key management is much earlier in its evolution, and is
subject to change.

A comment was made that this testing seems to be geared to vendors
performing vendor testing.  Publishing results would be useful to users.

Paul commented that publishing results while useful, can be dangerous
due to misleading information being provided.  He recommends general
comments be published rather than specific product results.  Mike agreed
that NIST won't publish specific results, only statistical summaries.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Reuse of Content Encryption Keys - Steve Farrell

Steve briefed the status of the "Reuse of CMS Content Encryption Keys"
Internet-Draft, <draft-ietf-smime-rcek-04.txt>, 28 May 2001.  Steve
noted that there is no status to report -- the working group has
finished with it.  IETF Last Call was completed on 23 June 2001 and the
document is with the Area Directors.

Russ took an action to check with the ADs to determine the status of the
document.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

ETSI ESI Working Group - Denis Pinkas

Denis briefed the working group on several draft European
Telecommunications Standards Institute (ETSI) Electronic Signature &
Infrastructure (ESI) working group documents that are out for public
review and comment.  Comments are requested by September 2001.  The
documents are freely available from: http://www.etsi.org/sec/el-sign.htm

The three draft documents are:
- XML Advanced Electronic Signatures (XAdES)
- Policy Requirements for CAs
- Policy Requirements for Time-Stamping Authorities

The first document, XML Advanced Electronic Signatures, provides, for
XML data, the same functionality as the Electronic Signature format
specification, which uses CMS (i.e. ASN.1), but instead of using CMS
uses the XMLDigSig specification with additions.  In the same way CMS
uses signed attributes and unsigned attributes, XAdES uses
SignedSignatureProperties and UnsignedSignatureProperties.  In addition,
it also uses SignedDataObjectProperties since multiple portions of an
XML document can be globally signed by one signer.  It can be seen as an
"xmlElSign", i.e. an equivalent to CMS in the XML world for signatures
(encryption features are not supported).  The work has been done with
close coordination with W3C.

The second document, Policy Requirements for CAs, is based on TS 101 456
and defines policy requirements for CAs issuing Qualified Certificates
and specifies policy requirements for CAs supporting public key
certificates used to support:
- electronic signatures,
- digital signatures,
- encryption,
- key exchange and
- key agreement mechanisms.
Comments to this document are particularly sought on the following
points:
- A number of requirements have been selected for defining different
   quality levels, where each level should represent a consistent set of
   requirements related to threats and risks involved with the
   environment of the service.  This has critical effects of the
   sensitivity of the service with regard to cost or/and security.
- Are these levels appropriate from a market point of view or would
   other level(s) be more useful?
- Comments based on different business scenarios would help in order to
   address wide segments of practical applications.

The last document, Policy Requirements for Time-Stamping Authorities, is
primarily targeted to support a Time-Stamping Service adequate for
Qualified Signatures, but can also be used in other contexts.  Comments
to this document are particularly sought on the following points:
- One baseline policy has been introduced, however the TSA has the
   possibility to define its own policy by adding enhancements to the
   baseline policy.  How can this be done?
- Naming convention for identifying the TSA.
- Verification of a time-stamp beyond the end of the validity period of
   the certificate of the TSA.

On the last issue, typically two things must be done:
- New TST MUST be applied before the end of the validity period of the
   certificate, so that it can remain valid.
- The CRL (or an OCSP response) from the CA that has issued the TSA
   certificate MUST also be captured, to prove that the time-stamp was
   still valid when the additional TST was applied.

Question:  What if the key is compromised?
Denis:  Certificate will be revoked on CRL, so time stamp applied by
revoked cert will be invalid.

To avoid re-applying a time stamp every time a TSA certificate is due to
expire (for example, five years), this could be avoided if:
- Key generation and public key certification is done correctly,
- The private key is zeroized at the end of the validity period of the
   certificate, and
- No backup of the private key is ever done.
Then:
   The private key is very unlikely to be compromised, even beyond the
   end of the validity period of the certificate of the TSA.

A TST would remain verifiable beyond the end of the validity period of
the certificate of the TSA, if it can be known/proven that:
- the TSA private key has not been compromised at any time during the
   validity period of the certificate, and beyond,
- the hash algorithms used in the TST exhibits no collisions,
- the key size of the signature algorithm under which TST has been
   signed is still beyond the reach of cryptographic attacks (as well as
   the signature algorithm itself).

However, there is no guidance on how these conditions can be met in
practice.  PKIX-1 says:  The certificate validity period is the time
interval during which the CA warrants that it will maintain information
about the status of the certificate.  An extension to the PKIX / X.509
model, might be appropriate, e.g., by mandating the CA to handle the
revocation status of TSA certificates beyond the end of their validity
period.

More specifics on these issues can be found by reading the documents,
which are available at: http://www.etsi.org/sec/el-sign.htm

Question:  Regarding the time stamping authority.  What if cryptography
advances and the algorithms are no longer secure?
Denis:  A second time stamp should have been applied before the
vulnerabilities with the first time stamp algorithms are found or
exploited.

Stefan Santesson:  Why would revocation information need to be
maintained after certificate expiration?
Denis:  Once compromised, time stamps with any dates can be generated
and can no longer be trusted.  Therefore, revocation information must be
published even after expiration.

Comment:  The date when TSA's key was compromised is important.  If a
client verifies a time stamp before the key is compromised, time stamp
could still be considered valid since it was known to be valid prior to
revocation of the TSA's certificate.
Denis:  The client's verification process cannot be trusted by a third
party.  It's better to just apply more than one time stamp, as that is
more secure than relying on a single time stamp.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

CMS Version Issue Revisited - Russ Housley

Russ decided to revisit the CMS version issue again.  Russ asked the
question differently:

1. Who objects to the current approach?
2. Who objects to changing the approach to where the subordinate
components handle the version number and the implementations are
required to gracefully handle decode errors?

A comment was made that a third question, "Who doesn't care?" should
also be asked.

Russ asked the three questions with almost no response to the first two
questions.  The working group members that responded answered only to
the third question, that they don't care.

Russ noted that the working group did not give him much guidance on
this issue.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

S/MIME Freeware Library (SFL) - Rich Nicholas

Rich presented a brief overview of the SFL, a freeware implementation of
RFCs 2630 and 2634 developed by Getronics Government Solutions.  Rich
described the various Getronics freeware security libraries and a high
level architecture depicting their relationship.  The libraries are:
- S/MIME Freeware Library
   -- Implements S/MIME v3 CMS/ESS security protocol.
   -- Provides ESS features: security labels, signed receipts, secure mail
      list info, signing certificate.
- Certificate Management Library
   -- Validates PKIX X.509 v3 certification paths & CRLs.
   -- Provides local cert/CRL storage functions.
   -- Provides remote directory retrieval via LDAP.
- Access Control Library
   -- Provides Rule Based Access Control using security labels and
      authorizations conveyed in either X.509 Attribute or public key
      certificates.
- Enhanced SNACC ASN.1 library provides DER.

For all of the Getronics freeware libraries, unencumbered source code is
freely available to all.  Getronics freeware can be used as part of
applications without paying any royalties or licensing fees.  There is a
public license associated with each Getronics freeware library.

The Getronics freeware libraries are available at:
SFL: <http://www.getronicsgov.com/hot/sfl_home.htm>
CML: <http://www.getronicsgov.com/hot/cml_home.htm>
ACL: <http://www.getronicsgov.com/hot/acl_home.htm>
SNACC: <http://www.getronicsgov.com/hot/snacc_home.htm>

The SFL is freeware implementation of RFC 2630 (CMS) and RFC 2634 (ESS).
When used with the Crypto++ library, the SFL implements RFC 2631
Ephemeral-Static (E-S) Diffie-Hellman (D-H) Key Agreement Method.  The
SFL supports RFC 2632 (Certificate Handling) and RFC 2633 (Message
Specification).  The goal of the SFL is to provide a reference
implementation of RFCs 2630 & 2634 to encourage acceptance as Internet
Standards.
The SFL:
- Can be used to protect any type of data (not just MIME)
- Maximizes crypto algorithm independence
- Successfully used by many commercial vendors

Getronics has used the SFL to perform a significant amount of S/MIME v3
interoperability testing.  Getronics tested the majority of features in
RFCs 2630, 2631 and 2634 as well as some of the features in RFCs 2632
and 2633.  Getronics used the SFL to successfully process and produce
the majority of features documented in "Examples of S/MIME
Messages".  SFL-generated data was included in the Examples document
such as: signed receipts, countersignatures, security labels, equivalent
security labels, mail list information, and signing certificate
attributes.  S/MIME v3 interoperability testing between the SFL and
Microsoft successfully tested most CMS/ESS features.

Rich presented the current status of the various Getronics freeware
libraries:
- SFL v1.10 (relesaed April 2001):
   -- Tested on RedHat Linux, Windows NT/98/00, Solaris 2.7.
   -- Fixed bugs in v1.9 SFL and accompanying CTILs.
   -- Added support for SHA-256 use with RSA (use with DSA TBD).
- CML v1.9.2 (released July 2001)
   -- Fixed bugs in v1.9 CML.
- Enhanced SNACC v1.3 R6 (released April 2001) fixed bugs.
- Access Control Library v1.6 (released May 2001)
   -- Supports multiple Clearance attributes in an X.509 attribute
      certificate or public key certificate.

Major new releases planned for September 2001.

The Internet Mail Consortium (IMC) has established SFL, CML and Enhanced
SNACC mail lists.  Rich pointed out that SFL/CML/Enhanced SNACC messages
should be sent to the IMC lists and should not be sent to the IETF mail
lists.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Wrap Up - Russ Housley

Russ asked if there were any other issues to discuss.  No additional
issues were raised.

Meeting adjourned.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7NEaYo21164 for ietf-smime-bks; Thu, 23 Aug 2001 07:36:34 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id f7NEaWD21160 for <[e-mail]>; Thu, 23 Aug 2001 07:36:32 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 23 Aug 2001 14:34:14 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA29967 for <[e-mail]>; Thu, 23 Aug 2001 10:35:51 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <QTWCQ4B9>; Thu, 23 Aug 2001 10:36:28 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.45]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCQ4BX; Thu, 23 Aug 2001 10:36:25 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 23 Aug 2001 10:11:04 -0400
Subject: RE: WG Last Call: rfc2630bis and cmsalg
In-Reply-To: <000001c12b99$0c11ac40$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim:

> > >11.  ASN Module:
> > >cmsalg.asn(124) : error 1019: Type symbol AlgorithmIdentifier never
> > >resolved.
> >
> >I added:
> >
> >    IMPORTS
> >       -- Directory Authentication Framework (X.509-2000)
> >             AlgorithmIdentifier
> >                FROM AuthenticationFramework { joint-iso-itu-t ds(5)
> >                     module(1) authenticationFramework(7) 4 }
> >
> >[JLS]  Don't forget the semi-colon following the OID since there are no
> >other  IMPORTS in the document.
> >[JLS]  I would request that the PKIX module be used rather than the
> >X.509 since that is more widely available.
>
>I caught the semicolon.
>
>RFC 2630 imports from the ISO/ITU-T modules.  Why change now?
>
>[JLS]  Yes, I found out that it does import from the ISO modules when I
>went back and look.  I had changed the versions on my system to import
>from the PKIX modules since they were easier to get a hold of (no free
>versions of the other modules at that point) and thus originally thought
>that you had changed from the PKIX to the ISO modules.
>
>I would prefer using the PKIX modules where possible since 1) they are
>more publicly available and 2) this is an IETF effort thus using the
>IETF versions make sense.  This does not add any new dependencies since
>there are already son-of-2459 and ACC profile dependencies in the
>document.

I have no problem making this change.  However, before I do so, I would 
like to hear from other implementors.  Does anyone object to this 
direction?  If I do not hear any objections in the next day or so, I will 
change the imports from the ISO/ITU-T modules to the PKIX modules wherever 
possible.

Off the top of my head, the version 1 attribute certificate syntax is the 
only thing that I can think of that is not included in any PKIX modules.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f7N61DP09672 for ietf-smime-bks; Wed, 22 Aug 2001 23:01:13 -0700 (PDT)
Received: from femail36.sdc1.sfba.home.com (femail36.sdc1.sfba.home.com [24.254.60.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f7N61CD09663 for <[e-mail]>; Wed, 22 Aug 2001 23:01:12 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail36.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010823060111.ZWU934.femail36.sdc1.sfba.home.com@revelation>; Wed, 22 Aug 2001 23:01:11 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: WG Last Call: cmsalg
Date: Wed, 22 Aug 2001 23:01:27 -0700
Message-ID: <000001c12b99$0c11ac40$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2505.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Housley, Russ
Sent: Wednesday, August 22, 2001 12:18 PM
To: [e-mail]
Cc: [e-mail]
Subject: RE: WG Last Call: cmsalg



Jim:

> >2.  Section 2.1:  There is a conflict between MUST in the next to
last
> >and SHOULD in the last paragraph for handling the presence of NULL
> >algorithm parameters.
>
>I have read it three times, and I do not see the problem.  The working
>group decided that the transmission of omitted parameters and NULL
>parameters are both legal.  Therefore, implementations SHOULD be able
to
>process both.  However, if parameters are present, they must contain
>NULL.
>
>Please post a proposed working change if you still think that there is
a
>problem.
>
>[JLS]
>1.  MUST handle with a parameters of NULL
>2.  SHOULD accept absent parameters (as well as NULL)
>3.  SHOULD generate with absent parameters.
>
>The MUST accept and the SHOULD generate are of opposite choices.

How about:

    The AlgorithmIdentifier parameters field is OPTIONAL.  If present,
    the parameters field MUST contain a NULL.  Implementations MUST
    accept SHA-1 AlgorithmIdentifiers with absent parameters.
    Implementations SHOULD accept SHA-1 AlgorithmIdentifiers with absent
    parameters.  Implementations SHOULD generate SHA-1
    AlgorithmIdentifiers with absent parameters.

[JLS] This addresses my issue.

> >3.  Section 3.2: The paragraph "CMS implentations that support ..."
> >should be removed.  This is a protocol statement on CMS not CMSALGs.
>
>I do not agree.  If an implementation chooses to implement RSA (PKCS#1
>v1.5) signatures, they MUST also implement SHA-1.  Such implementations
>SHOULD also support MD5.  There is nothing in this document that forces
an
>implementation to support RSA (PKCS#1 v1.5) signatures.
>
>[JLS]  I don't have a problem with the statement above, it is when you
>say CMS implementations... That I have a problem as that appears to be
a
>CMS requirement not an algorithm requirement.  Please see response
>message to Paul on this issue.

In the message to Paul, you said:
[JLS] I would agree with a statement that says.  "Implementations of RSA
(PKCS #1 v1.5) signature algorithm MUST implement the SHA-1 message
digest algorithm."

The whole point of CMSALG is to describe the use of algorithms in the
CMS, 
so of course we are talking about CMS implementations.  How about:

    CMS implementations that include the RSA (PKCS #1 v1.5) signature
    algorithm MUST also implement the SHA-1 message digest algorithm.
    Such implementations SHOULD also support MD5 message digest
    algorithm.

[JLS]  This wording is not what I would prefer, but I can live with it.

> >11.  ASN Module:
> >cmsalg.asn(124) : error 1019: Type symbol AlgorithmIdentifier never
> >resolved.
>
>I added:
>
>    IMPORTS
>       -- Directory Authentication Framework (X.509-2000)
>             AlgorithmIdentifier
>                FROM AuthenticationFramework { joint-iso-itu-t ds(5)
>                     module(1) authenticationFramework(7) 4 }
>
>[JLS]  Don't forget the semi-colon following the OID since there are no
>other  IMPORTS in the document.
>[JLS]  I would request that the PKIX module be used rather than the
>X.509 since that is more widely available.

I caught the semicolon.

RFC 2630 imports from the ISO/ITU-T modules.  Why change now?

[JLS]  Yes, I found out that it does import from the ISO modules when I
went back and look.  I had changed the versions on my system to import
from the PKIX modules since they were easier to get a hold of (no free
versions of the other modules at that point) and thus originally thought
that you had changed from the PKIX to the ISO modules.  

I would prefer using the PKIX modules where possible since 1) they are
more publicly available and 2) this is an IETF effort thus using the
IETF versions make sense.  This does not add any new dependencies since
there are already son-of-2459 and ACC profile dependencies in the
document. 

Jim




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7MJmD224760 for ietf-smime-bks; Wed, 22 Aug 2001 12:48:13 -0700 (PDT)
Received: from femail45.sdc1.sfba.home.com (femail45.sdc1.sfba.home.com [24.254.60.39]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7MJmCN24756 for <[e-mail]>; Wed, 22 Aug 2001 12:48:12 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail45.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010822194810.YBTZ3584.femail45.sdc1.sfba.home.com@revelation>; Wed, 22 Aug 2001 12:48:10 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Graeme Lunt'" <[e-mail]>, "'ietf-smime'" <[e-mail]>
Subject: RE: EITs in the x400-transport draft
Date: Wed, 22 Aug 2001 12:48:31 -0700
Message-ID: <003501c12b43$6c11beb0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2505.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Graeme,

Comments in-line

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Graeme Lunt
Sent: Wednesday, August 22, 2001 9:36 AM
To: 'jimsch'; ietf-smime
Subject: RE: EITs in the x400-transport draft



Jim,
 
> Based on the conversations that were held in London about propigating
> smime-types up.  

Could you perhaps summarize these conversations for me?
I did not attend the last IETF meeting, and my colleague who did
attend the S/MIME meeting does not have detailed notes.

[JLS]  This topic started on the list before London, basically I was
have started to argue that the S/MIME type should generally tell you
what the inner most content type is rather than trying to tell you what
this security layer is.  (I.e. map to the inner-content type attribute
not to the contentInfo OID.)  I raised this question because I did not
know what the S/MIME type of a signed-receipt should be if a layer of
encryption is added to the message.  I started this line of reasoning
based on the EITs of the X.400 world.

> I would like to propose that we remove enveloped-x400
> content and signed-x400 content EITs and replace it with x400-content
> EITs and S/MIME types.  

Does this have any bearing on my comments I sent to the list about 
the EITS, and in particular being able to identify the inner X.400 
content type (e.g. P22 over P772)?

[JLS]  No, I don't remember seeing this comemnt, however it would have a
potential bearing on this.  The question would be should all x.400
content be seen as one and the same or as different things.  Different
things would argue for different EITs and different SMIME-Types.  I have
absolutely no preference on this issue.

> This is a difference from the SMIME-types from
> the message draft, but in retrospect I believe that knowing 
> the content is of more importance that trying to one of the
potentially
> manysecurity services.  This also eases the code in moving
SMIME-types 
> from layer to layer.

Do I take it then that is to be a new draft in the (near) future?

[JLS]  I am sure that a new draft will be published before the last call
is completed, but as I am not an author on the draft I cannot really say
what will happen.

Thanks,

Graeme



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7MJRxA24370 for ietf-smime-bks; Wed, 22 Aug 2001 12:27:59 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7MJRqN24361 for <[e-mail]>; Wed, 22 Aug 2001 12:27:53 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 22 Aug 2001 19:25:36 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA02711 for <[e-mail]>; Wed, 22 Aug 2001 15:27:15 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <QTWCQK9M>; Wed, 22 Aug 2001 15:27:50 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.91]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCQK89; Wed, 22 Aug 2001 15:27:38 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 22 Aug 2001 15:17:50 -0400
Subject: RE: WG Last Call: cmsalg
In-Reply-To: <000001c12ab4$34b15000$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim:

> >2.  Section 2.1:  There is a conflict between MUST in the next to last
> >and SHOULD in the last paragraph for handling the presence of NULL
> >algorithm parameters.
>
>I have read it three times, and I do not see the problem.  The working
>group decided that the transmission of omitted parameters and NULL
>parameters are both legal.  Therefore, implementations SHOULD be able to
>process both.  However, if parameters are present, they must contain
>NULL.
>
>Please post a proposed working change if you still think that there is a
>problem.
>
>[JLS]
>1.  MUST handle with a parameters of NULL
>2.  SHOULD accept absent parameters (as well as NULL)
>3.  SHOULD generate with absent parameters.
>
>The MUST accept and the SHOULD generate are of opposite choices.

How about:

    The AlgorithmIdentifier parameters field is OPTIONAL.  If present,
    the parameters field MUST contain a NULL.  Implementations MUST
    accept SHA-1 AlgorithmIdentifiers with absent parameters.
    Implementations SHOULD accept SHA-1 AlgorithmIdentifiers with absent
    parameters.  Implementations SHOULD generate SHA-1
    AlgorithmIdentifiers with absent parameters.

> >3.  Section 3.2: The paragraph "CMS implentations that support ..."
> >should be removed.  This is a protocol statement on CMS not CMSALGs.
>
>I do not agree.  If an implementation chooses to implement RSA (PKCS#1
>v1.5) signatures, they MUST also implement SHA-1.  Such implementations
>SHOULD also support MD5.  There is nothing in this document that forces an
>implementation to support RSA (PKCS#1 v1.5) signatures.
>
>[JLS]  I don't have a problem with the statement above, it is when you
>say CMS implementations... That I have a problem as that appears to be a
>CMS requirement not an algorithm requirement.  Please see response
>message to Paul on this issue.

In the message to Paul, you said:
[JLS] I would agree with a statement that says.  "Implementations of RSA
(PKCS #1 v1.5) signature algorithm MUST implement the SHA-1 message
digest algorithm."

The whole point of CMSALG is to describe the use of algorithms in the CMS, 
so of course we are talking about CMS implementations.  How about:

    CMS implementations that include the RSA (PKCS #1 v1.5) signature
    algorithm MUST also implement the SHA-1 message digest algorithm.
    Such implementations SHOULD also support MD5 message digest
    algorithm.

> >11.  ASN Module:
> >cmsalg.asn(124) : error 1019: Type symbol AlgorithmIdentifier never
> >resolved.
>
>I added:
>
>    IMPORTS
>       -- Directory Authentication Framework (X.509-2000)
>             AlgorithmIdentifier
>                FROM AuthenticationFramework { joint-iso-itu-t ds(5)
>                     module(1) authenticationFramework(7) 4 }
>
>[JLS]  Don't forget the semi-colon following the OID since there are no
>other  IMPORTS in the document.
>[JLS]  I would request that the PKIX module be used rather than the
>X.509 since that is more widely available.

I caught the semicolon.

RFC 2630 imports from the ISO/ITU-T modules.  Why change now?

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7MIvWC23667 for ietf-smime-bks; Wed, 22 Aug 2001 11:57:32 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7MIvUN23661 for <[e-mail]>; Wed, 22 Aug 2001 11:57:30 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 22 Aug 2001 18:55:14 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA29672 for <[e-mail]>; Wed, 22 Aug 2001 14:56:54 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <QTWCQKJW>; Wed, 22 Aug 2001 14:57:31 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.91]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCQKJT; Wed, 22 Aug 2001 14:57:28 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 22 Aug 2001 11:46:01 -0400
Subject: draft-ietf-smime-symkeydist-06.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeff & Marcus:

The S/MIME working group is finished with draft-ietf-smime-symkeydist-06.txt.
We believe that the document is ready for publication as a standards track
RFC.

	Title		: S/MIME Symmetric Key Management and Distribution
	Author(s)	: S. Turner
	Filename	: draft-ietf-smime-symkeydist-06.txt
	Pages		: 75
	Date		: 20-Aug-01
	
This document describes a mechanism to manage (i.e., setup,
distribute, and rekey) keys used with symmetric cryptographic
algorithms. Also defined herein is a mechanism to organize users
into groups to support distribution of encrypted content using
symmetric cryptographic algorithms. The mechanisms use the
Cryptographic Message Syntax (CMS) protocol and Certificate
Management Message over CMS (CMC) protocol to manage the
symmetric keys. Any member of the group can then later use this
distributed shared key to decrypt other CMS encrypted objects with
the symmetric key. This mechanism has been developed to support
S/MIME Mail List Agents (MLAs).

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7MGbhW20728 for ietf-smime-bks; Wed, 22 Aug 2001 09:37:43 -0700 (PDT)
Received: from swordfish.nexor.co.uk (swordfish.nexor.co.uk [193.63.53.54]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7MGbdN20723 for <[e-mail]>; Wed, 22 Aug 2001 09:37:39 -0700 (PDT)
Received: by swordfish.nexor.co.uk with Internet Mail Service (5.5.2653.19) id <PBCFR5H3>; Wed, 22 Aug 2001 17:36:06 +0100
Message-ID: <[e-mail]>
From: Graeme Lunt <[e-mail]>
To: "'jimsch'" <[e-mail]>, ietf-smime <[e-mail]>
Subject: RE: EITs in the x400-transport draft
Date: Wed, 22 Aug 2001 17:35:56 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim,
 
> Based on the conversations that were held in London about propigating
> smime-types up.  

Could you perhaps summarize these conversations for me?
I did not attend the last IETF meeting, and my colleague who did
attend the S/MIME meeting does not have detailed notes.

> I would like to propose that we remove enveloped-x400
> content and signed-x400 content EITs and replace it with x400-content
> EITs and S/MIME types.  

Does this have any bearing on my comments I sent to the list about 
the EITS, and in particular being able to identify the inner X.400 
content type (e.g. P22 over P772)?

> This is a difference from the SMIME-types from
> the message draft, but in retrospect I believe that knowing 
> the content is of more importance that trying to one of the potentially
> manysecurity services.  This also eases the code in moving  SMIME-types 
> from layer to layer.

Do I take it then that is to be a new draft in the (near) future?

Thanks,

Graeme


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7M3DWv23479 for ietf-smime-bks; Tue, 21 Aug 2001 20:13:32 -0700 (PDT)
Received: from femail43.sdc1.sfba.home.com (femail43.sdc1.sfba.home.com [24.254.60.37]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7M3DUN23475 for <[e-mail]>; Tue, 21 Aug 2001 20:13:30 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail43.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010822031328.ZTTS29541.femail43.sdc1.sfba.home.com@revelation>; Tue, 21 Aug 2001 20:13:28 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: WG Last Call: cmsalg
Date: Tue, 21 Aug 2001 19:43:19 -0700
Message-ID: <000001c12ab4$34b15000$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2505.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ:

From: [e-mail]
[mailto:[e-mail]] On Behalf Of Housley, Russ
Sent: Tuesday, August 21, 2001 6:06 AM
To: [e-mail]

Jim:

>1.  Introduction:  CMSALG cannot have a protocol requirement on CMS.
>Please lowercase MAY statements in the first paragraph of the
>introduction.

Here is what RFC 2119 says about MAY:

    MAY   This word, or the adjective "OPTIONAL", mean that an item is
       truly optional.  One vendor may choose to include the item
because a
       particular marketplace requires it or because the vendor feels
that
       it enhances the product while another vendor may omit the same
item.
       An implementation which does not include a particular option MUST
be
       prepared to interoperate with another implementation which does
       include the option, though perhaps with reduced functionality. In
the
       same vein an implementation which does include a particular
option
       MUST be prepared to interoperate with another implementation
which
       does not include the option (except, of course, for the feature
the
       option provides.)

I believe that this is a statement about the things specified in the
CMSALG 
document.  CMS implementations can choose to implement them, or not.  I 
think that MAY is the correct word and case.

>2.  Section 2.1:  There is a conflict between MUST in the next to last
>and SHOULD in the last paragraph for handling the presence of NULL
>algorithm parameters.

I have read it three times, and I do not see the problem.  The working 
group decided that the transmission of omitted parameters and NULL 
parameters are both legal.  Therefore, implementations SHOULD be able to

process both.  However, if parameters are present, they must contain
NULL.

Please post a proposed working change if you still think that there is a

problem.

[JLS]
1.  MUST handle with a parameters of NULL
2.  SHOULD accept absent parameters (as well as NULL)
3.  SHOULD generate with absent parameters.

The MUST accept and the SHOULD generate are of opposite choices.

>3.  Section 3.2: The paragraph "CMS implentations that support ..."
>should be removed.  This is a protocol statement on CMS not CMSALGs.

I do not agree.  If an implementation chooses to implement RSA (PKCS#1 
v1.5) signatures, they MUST also implement SHA-1.  Such implementations 
SHOULD also support MD5.  There is nothing in this document that forces
an 
implementation to support RSA (PKCS#1 v1.5) signatures.

[JLS]  I don't have a problem with the statement above, it is when you
say CMS implementations... That I have a problem as that appears to be a
CMS requirement not an algorithm requirement.  Please see response
message to Paul on this issue.

>4.  Section 4.1:  I think that the following sentence should be removed
>from the text.  I have two problems with this statement.  First, it is
>imposing a MUST on a CMS implementation rather than on algorithms.
>Second, a protocol that requires only RSA and 3DES does not need to
>require 3DES-WRAP as well.
>
>"Any symmetric encryption algorithm that a CMS implementation includes
>as a content-encryption algorithm MUST also be included as a
>key-encryption algorithm."
>
>That said, I do think that a variation of the criteria should be
stated.
>"When a key agreement algorithm is used, a key-encrytion algorithm is
>also required.  In this case a key-encryption algorithm MUST be
provided
>for each content-encryption algorithm."

I agree.  I propose the following alternative for the subject paragraph:

    When a key agreement algorithm is used, a key-encryption algorithm
is
    also needed.  Therefore, when key agreement is supported, a key-
    encryption algorithm MUST be provided for each content-encryption
    algorithm.  The key wrap algorithms for Triple-DES and RC2 are
    described in section 7.

[JLS]  This is acceptable to me.


>9.  Section 4.4:  Some of the PBKDF2 restrictions from the password
>draft have been lost:
>A) Only the salt CHOICE requires support
>B)

I looked through the password-04 draft, and I think that I have covered
all 
of the MUST statements.  Therefore you must be talking about the ASN.1.
It 
says:

    PBKDF2-params ::= SEQUENCE {
      salt OCTET STRING,
      iterationCount INTEGER (1..MAX),
      keyLength INTEGER (1..MAX) OPTIONAL,
      prf AlgorithmIdentifier
             DEFAULT { algorithm id-hmacWithSHA1, parameters NULL } }

However, I pulled the syntax from PKCS #5, and they do not match.  The
one 
is password-04 is a legal subset.  The one in CMSALG is:

    PBKDF2-params ::= SEQUENCE {
      salt CHOICE {
        specified OCTET STRING,
        otherSource AlgorithmIdentifier },
      iterationCount INTEGER (1..MAX),
      keyLength INTEGER (1..MAX) OPTIONAL,
      prf AlgorithmIdentifier DEFAULT hMAC-SHA1 }

I added two things.  First, I added the setting of the default algorithm

parameter to NULL.  Second, I added the following sentence about salt:

    Within the PBKDF2-params, the salt MUST use the
    specified OCTET STRING.

[JLS]  The salt issue addresses my concerns.  I don't care about the
question of the NULL parameter, but do agree that is in the password
draft.

>10. Section 6.1:  Last paragraph should have MUST not must.

Due to the inclusion of the NULL parameter in response to your comment 
number 9, I rewrote almost the whole section.  It now says:

6.1  HMAC with SHA-1

    The HMAC with SHA-1 algorithm is described in RFC 2104 [HMAC].  The
    algorithm identifier for HMAC with SHA-1 is:

       hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3)
           dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }

    There are two possible encodings for the HMAC with SHA-1
    AlgorithmIdentifier parameters field.  The two alternatives arise
    from the fact that when the 1988 syntax for AlgorithmIdentifier was
    translated into the 1997 syntax the OPTIONAL associated with the
    AlgorithmIdentifier parameters got lost.  Later the OPTIONAL was
    recovered via a defect report, but by then many people thought that
    algorithm parameters were mandatory.  Because of this history some
    implementations encode parameters as a NULL element and others omit
    them entirely.  CMS implementations that support HMAC with SHA-1
MUST
    handle both an AlgorithmIdentifier parameters field which contains a
    NULL and an AlgorithmIdentifier with an absent parameters.

[JLS]  This addresses my problem. (And would be good SHA-1 text as
well.)

>11.  ASN Module:
>cmsalg.asn(124) : error 1019: Type symbol AlgorithmIdentifier never
>resolved.

I added:

   IMPORTS
      -- Directory Authentication Framework (X.509-2000)
            AlgorithmIdentifier
               FROM AuthenticationFramework { joint-iso-itu-t ds(5)
                    module(1) authenticationFramework(7) 4 }

[JLS]  Don't forget the semi-colon following the OID since there are no
other  IMPORTS in the document. 
[JLS]  I would request that the PKIX module be used rather than the
X.509 since that is more widely available.

jim



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LKG2k13880 for ietf-smime-bks; Tue, 21 Aug 2001 13:16:02 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7LKG0N13871 for <[e-mail]>; Tue, 21 Aug 2001 13:16:00 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 21 Aug 2001 20:13:45 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA28682 for <[e-mail]>; Tue, 21 Aug 2001 16:15:21 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <QTWCP7JZ>; Tue, 21 Aug 2001 16:15:57 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.99]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCP7JS; Tue, 21 Aug 2001 16:15:54 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 21 Aug 2001 15:40:53 -0400
Subject: RE: WG Last Call: RFC2630-bis
In-Reply-To: <000101c12a07$796a1ea0$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim:

>1.  Section 5.4:  In the fragment
>    "The IMPLICIT [0] tag in the signedAttributes is not used for the DER"
>    change to signedAttrs

Good catch.  Done.

>2.  Section 9.1:  The description of items from originatorInfo to
>authAttrs should be outdented one level.

Agreed.  Done.

>3.  Section 10.1.6:  Insert a blank line before the ASN.

Done.

>4. Security considerations:  Contains a reference to section 12.6

Ooops.  That paragraph belongs (and is in) CMSALG.  I deleted it from 
RFC2630bis.

>5.  I think that the OID defined for ContentInfo in the x400 documents
>should be copied into the second on ContentInfo.

This OID has always just been in the ASN.1.  I will gladly replicate it in 
section 3.

> From -00 comments
>
>35) Section 11: Update RFC 2459 text reference to "Son of 2459".

Done.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LGUMJ07462 for ietf-smime-bks; Tue, 21 Aug 2001 09:30:22 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7LGUKN07458 for <[e-mail]>; Tue, 21 Aug 2001 09:30:21 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 21 Aug 2001 16:28:05 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA19305 for <[e-mail]>; Tue, 21 Aug 2001 12:29:39 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <QTWCPXGF>; Tue, 21 Aug 2001 12:30:15 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.43]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCPXGA; Tue, 21 Aug 2001 12:30:04 -0400
From: "Housley, Russ" <[e-mail]>
To: "Sean P. Turner" <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 21 Aug 2001 12:29:54 -0400
Subject: Re: WG Last Call: rfc2630bis and cmsalg
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sean:

The point being made was that CMSALG does not include any of the other 
algorithms specifications, just how to use them in the CMS context.  And, 
the key wrap algorithm will be useful in other contexts.

Russ


Sean P. Turner wrote:

>I can see if you're going to break out one set of "algorithm" information you
>should break out the other.  I just want to know where the "map" is that is
>going to tell me which parts of the 5 drafts I need to make sure get
>implemented ;)
>
>spt
>
>"Housley, Russ" wrote:
>
> > I have received a request to move the key wrap algorithms to a document of
> > their own.  Do others think that this is a good idea or a bad idea?
> >
> > Russ


Received: by above.proper.com (8.11.3/8.11.3) id f7LGL4s07166 for ietf-smime-bks; Tue, 21 Aug 2001 09:21:04 -0700 (PDT)
Received: from nebula.x509.com (nebula.x509.com [199.175.150.19]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LGL2N07161 for <[e-mail]>; Tue, 21 Aug 2001 09:21:02 -0700 (PDT)
Received: from crack.x509.com (mail.x509.com [199.175.150.1]) by nebula.x509.com (8.11.3/XCERT) with ESMTP id f7LGKvj00212 for <[e-mail]>; Tue, 21 Aug 2001 09:20:57 -0700 (PDT)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.11.3/XCERT) with ESMTP id f7LGKuo08139 for <[e-mail]>; Tue, 21 Aug 2001 09:20:56 -0700 (PDT)
Received: by exvan01.x509.com with Internet Mail Service (5.5.2653.19) id <QDLC69JK>; Tue, 21 Aug 2001 09:22:06 -0700
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.43]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCPXBY; Tue, 21 Aug 2001 12:20:53 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 21 Aug 2001 12:20:37 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Re: WG Last Call: draft-ietf-smime-symkeydist-04.txt
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear S/MIME WG:

I believe that the publication of this draft resolves all of the issues 
that we raise in WG Last Call.  To that end, I plan to send it forward to 
the Security Area Directors unless someone posts a relevant objection today.


>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 Symmetric Key Management and Distribution
>         Author(s)       : S. Turner
>         Filename        : draft-ietf-smime-symkeydist-06.txt
>         Pages           : 75
>         Date            : 20-Aug-01
>
>This document describes a mechanism to manage (i.e., setup,
>distribute, and rekey) keys used with symmetric cryptographic
>algorithms. Also defined herein is a mechanism to organize users
>into groups to support distribution of encrypted content using
>symmetric cryptographic algorithms. The mechanisms use the
>Cryptographic Message Syntax (CMS) protocol [2] and Certificate
>Management Message over CMS (CMC) protocol [3] to manage the
>symmetric keys. Any member of the group can then later use this
>distributed shared key to decrypt other CMS encrypted objects with
>the symmetric key. This mechanism has been developed to support
>S/MIME Mail List Agents (MLAs).

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LGG4Q07049 for ietf-smime-bks; Tue, 21 Aug 2001 09:16:04 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7LGG2N07044 for <[e-mail]>; Tue, 21 Aug 2001 09:16:02 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 21 Aug 2001 16:13:46 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA18080 for <[e-mail]>; Tue, 21 Aug 2001 12:15:22 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <QTWCPW0H>; Tue, 21 Aug 2001 12:15:57 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.43]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCPW0B; Tue, 21 Aug 2001 12:15:51 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 21 Aug 2001 12:15:46 -0400
Subject: RE: WG Last Call: cmsalg
In-Reply-To: <000201c12a07$7a8af7f0$[e-mail]>
References: <p05100310b7a6e613e5b7@[165.227.249.20]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim:

>[JLS] 3.  Section 3.2: The paragraph "CMS implentations that support ..." 
>should
>be removed.  This is a protocol statement on CMS not CMSALGs.
>
>[Paul] Disagree. This paragraph shows a linkage between RSA and SHA-1, which
>is perfectly reasonable.
>
>[JLS] I would agree with a statement that says.  "Implementations of RSA
>(PKCS #1 v1.5) signature algorithm MUST implement the SHA-1 message
>digest algorithm."

[Russ] I am confused here.  The current text is:

    CMS implementations that support the RSA (PKCS #1 v1.5) signature
    algorithm MUST also support the SHA-1 message digest algorithm.  Such
    implementations SHOULD also support MD5 message digest algorithm.

Are you really only asking that we change "support" to "implement"?

>[JLS] 8.  Section 4.4, Para 2:  This contains a MUST on CMS.  It needs to be
>removed.
>
>[Paul] Disagree for same reason above.
>
>[JLS] Again what is the test case (this is a MUST).  Do you mean that I
>cannot have a CMS implemention that supports password based key
>management but does not support PBKDF2?  There are no other manditory
>algorithm implementations in this document.  This one should not be
>manditory.

[Russ] Here I agree with Jim.  At the London meeting, we agreed that all of 
the algorithms listed in CMSALG would be MAY implement, and that other 
documents would make MUST statements.  For example, the updated MSG 
document will reference CMSALG and make MUST statements.

I think that the updated MSG document should say that implementations that 
support password-based key management, then they MUST implement PBKDF2.

Russ


Received: by above.proper.com (8.11.3/8.11.3) id f7LEjNO28294 for ietf-smime-bks; Tue, 21 Aug 2001 07:45:23 -0700 (PDT)
Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LEjLN28283; Tue, 21 Aug 2001 07:45:21 -0700 (PDT)
Received: from revelation (ip23.du1.ptl.nwlink.com [209.20.137.23]) by smtp.nwlink.com (8.9.3/8.9.1) with ESMTP id HAA23637; Tue, 21 Aug 2001 07:43:41 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Paul Hoffman / IMC'" <[e-mail]>, "'Housley, Russ'" <[e-mail]>, <[e-mail]>
Subject: RE: WG Last Call: cmsalg
Date: Mon, 20 Aug 2001 23:06:29 -0700
Message-ID: <000201c12a07$7a8af7f0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <p05100310b7a6e613e5b7@[165.227.249.20]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2505.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul,

Here are my thoughts in return.

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Paul Hoffman / IMC
Sent: Monday, August 20, 2001 9:16 AM
To: [e-mail]; 'Housley, Russ'; [e-mail]
Subject: RE: WG Last Call: cmsalg



A few notes on Jim's comments.

At 10:39 PM -0700 8/19/01, Jim Schaad wrote:
>1.  Introduction:  CMSALG cannot have a protocol requirement on CMS.
Please
>lowercase MAY statements in the first paragraph of the introduction.

Disagree. The "MAY" vs "may" here indicates references into this 
document, not external documents. By using "MAY", this is made 
clearer.

[JLS]  Given what the statements actually say, I don't think that a
protocol based MAY is very appropriate.  You MAY do this. You MAY do
other things also.  I would not have the first idea of how to write a
test case for this as a protocol statement.  While I understand that
MAYs do not have to be tested, if you were to test this statement how
would you go about doing so.

>3.  Section 3.2: The paragraph "CMS implentations that support ..."
should
>be removed.  This is a protocol statement on CMS not CMSALGs.

Disagree. This paragraph shows a linkage between RSA and SHA-1, which 
is perfectly reasonable.

[JLS] I would agree with a statement that says.  "Implementations of RSA
(PKCS #1 v1.5) signature algorithm MUST implement the SHA-1 message
digest algorithm."

>8.  Section 4.4, Para 2:  This contains a MUST on CMS.  It needs to be
>removed.

Disagree for same reason above.

[JLS] Again what is the test case (this is a MUST).  Do you mean that I
cannot have a CMS implemention that supports password based key
management but does not support PBKDF2?  There are no other manditory
algorithm implementations in this document.  This one should not be
manditory.

--Paul Hoffman, Director
--Internet Mail Consortium

--- regards - jim




Received: by above.proper.com (8.11.3/8.11.3) id f7LEjLH28278 for ietf-smime-bks; Tue, 21 Aug 2001 07:45:21 -0700 (PDT)
Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LEjKN28266 for <[e-mail]>; Tue, 21 Aug 2001 07:45:20 -0700 (PDT)
Received: from revelation (ip23.du1.ptl.nwlink.com [209.20.137.23]) by smtp.nwlink.com (8.9.3/8.9.1) with ESMTP id HAA23623; Tue, 21 Aug 2001 07:43:38 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "Russ Housley" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: WG Last Call: RFC2630-bis
Date: Mon, 20 Aug 2001 23:06:29 -0700
Message-ID: <000101c12a07$796a1ea0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2505.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ, 

Things are better -- here are my text comments.

1.  Section 5.4:  In the fragment
   "The IMPLICIT [0] tag in the signedAttributes is not used for the
DER"
   change to signedAttrs

2.  Section 9.1:  The description of items from originatorInfo to
authAttrs should be outdented one level.

3.  Section 10.1.6:  Insert a blank line before the ASN.

4. Security considerations:  Contains a reference to section 12.6

5.  I think that the OID defined for ContentInfo in the x400 documents
should be copied into the second on ContentInfo.

>From -00 comments

35) Section 11: Update RFC 2459 text reference to "Son of 2459".

Jim



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LEFxG27306 for ietf-smime-bks; Tue, 21 Aug 2001 07:15:59 -0700 (PDT)
Received: from tweety (pool-151-200-26-46.res.east.verizon.net [151.200.26.46]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LEFvN27302 for <[e-mail]>; Tue, 21 Aug 2001 07:15:57 -0700 (PDT)
Received: from [192.168.0.11] by tweety (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Tue, 21 Aug 2001 10:10:36 -0400
Message-ID: <[e-mail]>
Date: Tue, 21 Aug 2001 10:10:34 -0400
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: rfc2630bis and cmsalg
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I can see if you're going to break out one set of "algorithm" information you
should break out the other.  I just want to know where the "map" is that is
going to tell me which parts of the 5 drafts I need to make sure get
implemented ;)

spt

"Housley, Russ" wrote:

> I have received a request to move the key wrap algorithms to a document of
> their own.  Do others think that this is a good idea or a bad idea?
>
> Russ




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LDesC26322 for ietf-smime-bks; Tue, 21 Aug 2001 06:40:54 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7LDeqN26317 for <[e-mail]>; Tue, 21 Aug 2001 06:40:52 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 21 Aug 2001 13:38:36 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA01713 for <[e-mail]>; Tue, 21 Aug 2001 09:40:13 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <QTWCPTXZ>; Tue, 21 Aug 2001 09:40:49 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.83]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCPTXP; Tue, 21 Aug 2001 09:40:37 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 21 Aug 2001 09:05:48 -0400
Subject: RE: WG Last Call: cmsalg
In-Reply-To: <!~![e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim:

>1.  Introduction:  CMSALG cannot have a protocol requirement on CMS.
>Please lowercase MAY statements in the first paragraph of the
>introduction.

Here is what RFC 2119 says about MAY:

    MAY   This word, or the adjective "OPTIONAL", mean that an item is
       truly optional.  One vendor may choose to include the item because a
       particular marketplace requires it or because the vendor feels that
       it enhances the product while another vendor may omit the same item.
       An implementation which does not include a particular option MUST be
       prepared to interoperate with another implementation which does
       include the option, though perhaps with reduced functionality. In the
       same vein an implementation which does include a particular option
       MUST be prepared to interoperate with another implementation which
       does not include the option (except, of course, for the feature the
       option provides.)

I believe that this is a statement about the things specified in the CMSALG 
document.  CMS implementations can choose to implement them, or not.  I 
think that MAY is the correct word and case.

>2.  Section 2.1:  There is a conflict between MUST in the next to last
>and SHOULD in the last paragraph for handling the presence of NULL
>algorithm parameters.

I have read it three times, and I do not see the problem.  The working 
group decided that the transmission of omitted parameters and NULL 
parameters are both legal.  Therefore, implementations SHOULD be able to 
process both.  However, if parameters are present, they must contain NULL.

Please post a proposed working change if you still think that there is a 
problem.

>3.  Section 3.2: The paragraph "CMS implentations that support ..."
>should be removed.  This is a protocol statement on CMS not CMSALGs.

I do not agree.  If an implementation chooses to implement RSA (PKCS#1 
v1.5) signatures, they MUST also implement SHA-1.  Such implementations 
SHOULD also support MD5.  There is nothing in this document that forces an 
implementation to support RSA (PKCS#1 v1.5) signatures.

>4.  Section 4.1:  I think that the following sentence should be removed
>from the text.  I have two problems with this statement.  First, it is
>imposing a MUST on a CMS implementation rather than on algorithms.
>Second, a protocol that requires only RSA and 3DES does not need to
>require 3DES-WRAP as well.
>
>"Any symmetric encryption algorithm that a CMS implementation includes
>as a content-encryption algorithm MUST also be included as a
>key-encryption algorithm."
>
>That said, I do think that a variation of the criteria should be stated.
>"When a key agreement algorithm is used, a key-encrytion algorithm is
>also required.  In this case a key-encryption algorithm MUST be provided
>for each content-encryption algorithm."

I agree.  I propose the following alternative for the subject paragraph:

    When a key agreement algorithm is used, a key-encryption algorithm is
    also needed.  Therefore, when key agreement is supported, a key-
    encryption algorithm MUST be provided for each content-encryption
    algorithm.  The key wrap algorithms for Triple-DES and RC2 are
    described in section 7.

>5.  Section 4.1: "A CMS implemenation MAY support mixed..." This
>paragraph should be moved into the description of each key-wrap
>algorithm.  Thus "3DES-Wrap implementations MAY support wrapping of
>non-3DES keys."


Okay.  Done.

>6.  Section 4.1.1:  "ukm MAY be present or absent."  I think this makes
>no sense from a protocol sense.  I believe that one implemenation could
>require presence and another could require absense thus leading to
>non-interopability.  I had thought the requirements on this was going to
>be "ukm may be either present or absent.  Implemenations MUST support
>ukm being absent and SHOULD support be present."

Okay.  Done.

>7.  Section 4.1.1: description of keyEnryptionAlgorithm.
>"KeyWrapAlgorihtm" is misspelt.

Good catch.  Fixed.

>8.  Section 4.4, Para 2:  This contains a MUST on CMS.  It needs to be
>removed.

You are correct.  I deleted the sentence with MUST in it.

>9.  Section 4.4:  Some of the PBKDF2 restrictions from the password
>draft have been lost:
>A) Only the salt CHOICE requires support
>B)

I looked through the password-04 draft, and I think that I have covered all 
of the MUST statements.  Therefore you must be talking about the ASN.1.  It 
says:

    PBKDF2-params ::= SEQUENCE {
      salt OCTET STRING,
      iterationCount INTEGER (1..MAX),
      keyLength INTEGER (1..MAX) OPTIONAL,
      prf AlgorithmIdentifier
             DEFAULT { algorithm id-hmacWithSHA1, parameters NULL } }

However, I pulled the syntax from PKCS #5, and they do not match.  The one 
is password-04 is a legal subset.  The one in CMSALG is:

    PBKDF2-params ::= SEQUENCE {
      salt CHOICE {
        specified OCTET STRING,
        otherSource AlgorithmIdentifier },
      iterationCount INTEGER (1..MAX),
      keyLength INTEGER (1..MAX) OPTIONAL,
      prf AlgorithmIdentifier DEFAULT hMAC-SHA1 }

I added two things.  First, I added the setting of the default algorithm 
parameter to NULL.  Second, I added the following sentence about salt:

    Within the PBKDF2-params, the salt MUST use the
    specified OCTET STRING.

>10. Section 6.1:  Last paragraph should have MUST not must.

Due to the inclusion of the NULL parameter in response to your comment 
number 9, I rewrote almost the whole section.  It now says:

6.1  HMAC with SHA-1

    The HMAC with SHA-1 algorithm is described in RFC 2104 [HMAC].  The
    algorithm identifier for HMAC with SHA-1 is:

       hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
           dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }

    There are two possible encodings for the HMAC with SHA-1
    AlgorithmIdentifier parameters field.  The two alternatives arise
    from the fact that when the 1988 syntax for AlgorithmIdentifier was
    translated into the 1997 syntax the OPTIONAL associated with the
    AlgorithmIdentifier parameters got lost.  Later the OPTIONAL was
    recovered via a defect report, but by then many people thought that
    algorithm parameters were mandatory.  Because of this history some
    implementations encode parameters as a NULL element and others omit
    them entirely.  CMS implementations that support HMAC with SHA-1 MUST
    handle both an AlgorithmIdentifier parameters field which contains a
    NULL and an AlgorithmIdentifier with an absent parameters.

>11.  ASN Module:
>cmsalg.asn(124) : error 1019: Type symbol AlgorithmIdentifier never
>resolved.

I added:

   IMPORTS
      -- Directory Authentication Framework (X.509-2000)
            AlgorithmIdentifier
               FROM AuthenticationFramework { joint-iso-itu-t ds(5)
                    module(1) authenticationFramework(7) 4 }

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7LBSEu19263 for ietf-smime-bks; Tue, 21 Aug 2001 04:28:14 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7LBSCN19258 for <[e-mail]>; Tue, 21 Aug 2001 04:28:13 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05120; Tue, 21 Aug 2001 07:26:56 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-symkeydist-06.txt
Date: Tue, 21 Aug 2001 07:26:55 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: S/MIME Symmetric Key Management and Distribution
	Author(s)	: S. Turner
	Filename	: draft-ietf-smime-symkeydist-06.txt
	Pages		: 75
	Date		: 20-Aug-01
	
This document describes a mechanism to manage (i.e., setup,
distribute, and rekey) keys used with symmetric cryptographic
algorithms. Also defined herein is a mechanism to organize users
into groups to support distribution of encrypted content using
symmetric cryptographic algorithms. The mechanisms use the
Cryptographic Message Syntax (CMS) protocol [2] and Certificate
Management Message over CMS (CMC) protocol [3] to manage the
symmetric keys. Any member of the group can then later use this
distributed shared key to decrypt other CMS encrypted objects with
the symmetric key. This mechanism has been developed to support
S/MIME Mail List Agents (MLAs).

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

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-symkeydist-06.txt".

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-symkeydist-06.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7KJ0k728093 for ietf-smime-bks; Mon, 20 Aug 2001 12:00:46 -0700 (PDT)
Received: from [165.227.249.20] (spare38.proper.com [64.168.243.38]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7KJ0eN28088; Mon, 20 Aug 2001 12:00:40 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100310b7a6e613e5b7@[165.227.249.20]>
In-Reply-To: <!~![e-mail]>
References: <!~![e-mail]>
Date: Mon, 20 Aug 2001 09:16:10 -0700
To: <[e-mail]>, "'Housley, Russ'" <[e-mail]>, <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: WG Last Call: cmsalg
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

A few notes on Jim's comments.

At 10:39 PM -0700 8/19/01, Jim Schaad wrote:
>1.  Introduction:  CMSALG cannot have a protocol requirement on CMS.  Please
>lowercase MAY statements in the first paragraph of the introduction.

Disagree. The "MAY" vs "may" here indicates references into this 
document, not external documents. By using "MAY", this is made 
clearer.

>3.  Section 3.2: The paragraph "CMS implentations that support ..." should
>be removed.  This is a protocol statement on CMS not CMSALGs.

Disagree. This paragraph shows a linkage between RSA and SHA-1, which 
is perfectly reasonable.

>8.  Section 4.4, Para 2:  This contains a MUST on CMS.  It needs to be
>removed.

Disagree for same reason above.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7KIpZL27913 for ietf-smime-bks; Mon, 20 Aug 2001 11:51:35 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7KIpWN27908 for <[e-mail]>; Mon, 20 Aug 2001 11:51:33 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 20 Aug 2001 18:49:18 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA07138 for <[e-mail]>; Mon, 20 Aug 2001 14:50:59 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <QTWCPJ2G>; Mon, 20 Aug 2001 14:51:34 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.8]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCPJHV; Mon, 20 Aug 2001 14:50:38 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Mon, 20 Aug 2001 14:50:35 -0400
Subject: Re: WG Last Call: rfc2630bis and cmsalg
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have received a request to move the key wrap algorithms to a document of 
their own.  Do others think that this is a good idea or a bad idea?

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7K5dJ707060 for ietf-smime-bks; Sun, 19 Aug 2001 22:39:19 -0700 (PDT)
Received: from smtp.nwlink.com (smtp.nwlink.com [209.20.130.57]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7K5dHN07056 for <[e-mail]>; Sun, 19 Aug 2001 22:39:17 -0700 (PDT)
Received: from revelation (ip21.du1.ptl.nwlink.com [209.20.137.21]) by smtp.nwlink.com (8.9.3/8.9.1) with ESMTP id WAA27494; Sun, 19 Aug 2001 22:37:38 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, <[e-mail]>
Subject: RE: WG Last Call: cmsalg
Date: Sun, 19 Aug 2001 22:39:17 -0700
Message-ID: <!~![e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_001A_01C128FF.CCF93460"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2505.0000
X-MS-TNEF-Correlator: 00000000C61F957EEEE3D311963C000086335A64E4592200
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_001A_01C128FF.CCF93460
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

1.  Introduction:  CMSALG cannot have a protocol requirement on CMS.  =
Please
lowercase MAY statements in the first paragraph of the introduction.

2.  Section 2.1:  There is a conflict between MUST in the next to last =
and
SHOULD in the last paragraph for handling the presence of NULL algorithm
parameters.

3.  Section 3.2: The paragraph "CMS implentations that support ..." =
should
be removed.  This is a protocol statement on CMS not CMSALGs.

4.  Section 4.1:  I think that the following sentence should be removed =
from
the text.  I have two problems with this statement.  First, it is =
imposing a
MUST on a CMS implementation rather than on algorithms.  Second, a =
protocol
that requires only RSA and 3DES does not need to require 3DES-WRAP as =
well.

"Any symmetric encryption algorithm that a CMS implementation includes =
as a
content-encryption algorithm MUST also be included as a key-encryption
algorithm."

That said, I do think that a variation of the criteria should be stated.
"When a key agreement algorithm is used, a key-encrytion algorithm is =
also
required.  In this case a key-encryption algorithm MUST be provided for =
each
content-encryption algorithm."

5.  Section 4.1: "A CMS implemenation MAY support mixed..." This =
paragraph
should be moved into the description of each key-wrap algorithm.  Thus
"3DES-Wrap implementations MAY support wrapping of non-3DES keys."

6.  Section 4.1.1:  "ukm MAY be present or absent."  I think this makes =
no
sense from a protocol sense.  I believe that one implemenation could =
require
presence and another could require absense thus leading to
non-interopability.  I had thought the requirements on this was going to =
be
"ukm may be either present or absent.  Implemenations MUST support ukm =
being
absent and SHOULD support be present."

7.  Section 4.1.1: description of keyEnryptionAlgorithm. =
"KeyWrapAlgorihtm"
is misspelt.

8.  Section 4.4, Para 2:  This contains a MUST on CMS.  It needs to be
removed.

9.  Section 4.4:  Some of the PBKDF2 restrictions from the password =
draft
have been lost:
A) Only the salt CHOICE requires support
B)

10. Section 6.1:  Last paragraph should have MUST not must.

11.  ASN Module:
cmsalg.asn(124) : error 1019: Type symbol AlgorithmIdentifier never
resolved.

-----Original Message-----
From: [e-mail] =
[mailto:[e-mail]]
On Behalf Of Housley, Russ
Sent: Thursday, August 16, 2001 10:15 AM
To: [e-mail]
Subject: WG Last Call: rfc2630bis and cmsalg



The update to CMS is ready for WG Last Call.  Please post all comments =
on=20
both documents to the S/MIME WG mail list by 31 August 2001.

	Title		: Cryptographic Message Syntax
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-rfc2630bis-02.txt
	Pages		: 52
	Date		: 13-Aug-01


	Title		: Cryptographic Message Syntax (CMS) Algorithms
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cmsalg-02.txt
	Pages		: 26
	Date		: 14-Aug-01
=09
Russ=20

------=_NextPart_000_001A_01C128FF.CCF93460
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="winmail.dat"

eJ8+IhoFAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGAAcAAQAAAAAAAAEGgAMADgAAANEHCAAT
ABYAJwAAAAAAMAEBA5AGACQMAAAtAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAAD
AC4AAAAAAAIBMQABAAAAGAAAAAAAAADGH5V+7uPTEZY8AACGM1pk5FgiAAMANgAAAAAAHgBwAAEA
AAAVAAAAV0cgTGFzdCBDYWxsOiBjbXNhbGcAAAAAAgFxAAEAAAAWAAAAAcEpNTLkGWjArhGrRe68
ITbRHa5xMAAAAgEdDAEAAAAXAAAAU01UUDpKSU1TQ0hATldMSU5LLkNPTQAACwABDgAAAABAAAYO
ALKfaTopwQECAQoOAQAAABgAAAAAAAAAxh+Vfu7j0xGWPAAAhjNaZMKAAAADABQOAAAAAAsAHw4B
AAAAHgAoDgEAAAAtAAAAMDAwMDAwMDEBamltc2NoQG53bGluay5jb20Bamltc2NoQG53bGluay5j
b20AAAAAHgApDgEAAAAtAAAAMDAwMDAwMDEBamltc2NoQG53bGluay5jb20Bamltc2NoQG53bGlu
ay5jb20AAAAAAgEJEAEAAABPBwAASwcAAPQNAABMWkZ1hMAFiQMACgByY3BnMTI14jIDQ3RleAVB
AQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwECAGNo4QrAc2V0MgYABsMRJfYzBEYTtzAS
LBEzCO8J97Y7GB8OMDURIgxgYwBQMwsJAWQzNhZQC6YgMbAuICBJAjADYGQa0FR0aQIgOh0QQwXg
QZBMRyBjAHBubwVAgRPgdmUgYSBwA2AUdG8XkSAYIHF1aXcYIAeAAjAgAiAeEh0BUKhsZWEUECAX
sHcEkIMekCGRTUFZIHMBkI8OsCByBCALgCB0aB8wXmYgQCKgH2AKwGEJwGF0cGggsGYjcwuAHVgu
dwqiCoQKgDIdAQZgHaMg9SbAMR3xVCOQGCAjQAQgYx9QBaBuZmwN4AVAYo8UICHgCfAF0FVTVCNG
fm4Owh+gIbAhgAVAAHBkwQYASE9VTEQjRirjPyQoAhAFwBPgK0Ao0G5nbyNzH3AHkAnwYx8wJMFO
pSugTB9AbGcFsGkjgL5tJBMHgA6wFAAl+zMm2d0xcDId8CfhJBkiHiEjQP5tC1AggSLAHcEEICOA
IsCRIpB1cHAXwSAuNWDqIiKQaAhgbCtQKSAf8fsEYB8gZB0BJ+AoQShDH3e/IqcgtSpQHtEeJDCc
NCbZ2zqwJ6JJI3ELgGs0hCOD/wbwIcEt0i6BDrAuojW/I7D/A2Ejcw6yHQIe9ClAKsAfcf8CYCBg
BCAD8COAO+IEICKn9R0BRiPSLCNABUA3EjPA/m8AkC3hH1ApoyDBH1Azd/8gcjQjH/AiwCfxNIID
oESi7y92MJAm4wIgZEMgH1k0k+cgBQQgAiBseQfwHkArI8gzREUF8GRvB5Eewh8qYD8BKrEgBUqz
LVdSbEFQH0BBUWU9ACX7InRBbkogcwbAMEEFEGPyIC6RcnkFMCdCL2g0k/dE3ydCC4BjCkABAChR
KFV5PbF0LU9/L8IpowdAcx8qwDYhUmUrUFLza2V5/1O/L7I1gCYKJ+A0sgtwSDHvO9BLEDvqH1B2
CsAHMCczfyTFBQEwYQcwPgkiozayIv5XI5BEslbBH0AJwiBzL2j9KEF1FBBIM1bHT90oQlVy/yAF
NrIdMEG0IhNWr1R9NiH9H3F2WZA/AgWxIXAT0FM/+1ePJjc1Os5OgFErRcQiY/E09W1peDahNXI2
8yQo/z4YPtQlMVoCHzBSsQUDW1X7ZvNkEnckcWhpJ8Jf8DNQv0ykcbJFPAQgbEpxonAt0vMkwR7A
bi1Kw2QRMJBYW8Y2OswnkyJ1a1TxInH/ZfMuciChBcABoD2CNYE7yf8oQQDAZBBLQj1yIZE/Mzd6
73yiQAMpICjQZUByNKICIP8lEWt7BaA14kwmLlcrMgBw/x7QRlKAjHqTIZEjgHLRIWG+ZC3TKsB2
MiUxBJBvCrB2YgMQL7B5QAVL0TXBZ95oPIQgCUnSQbR3TUEvgL+EpTYheSMAwEogNiFlL7H/EoF5
7x0Ca3p0kSmyNOZ5Mn8pIEPzeqMrKjTmebhYTDend/9wHmQRRW5n9UFyCLwiS2Qgc2KUpIcQbTWQ
u3vSBAFwTYA/8CYKODrL+jRDIFAkMSdwJ7NjcgIh7wtxKFJEViD0SUuENHFVk9s2ViYKOZgcHfFT
A3Auw8EjglBCS0RGFEAuYf9PIjQ0PzcKsAQQQLALIEsAfyRAAYAe9CkgKXEXsCKgOuEmBEEpIE9K
AiOCWXDHlxASICuASUNFSVg05ckmBEIpJgoxMB0AJwb7d+AnokwsbD4VHwMpox7CFm1f8JcsMRzy
QVNObwXQHXEhYKM1Y0FAL2Eu6SGAbigOIDSjsB3wBJDnA2AFwKdgMTkyYWSQPfH3BsMQwC92SQEA
AjAGkBJyvypgHyAFwC5hBvCcvi2ywvpPBRBnC4AHQAXQB5BZcOxnZbLDJgRGA2Ed8CHQjSpgcoVA
FCBmLXNtAC0HgEAAwAMQLgdwYy7bBbAt8Fu2Mh+gOrUvtjqiXaPBIEJlE+BsJNCqTyTQSAhgcyFg
eUMg+lJf8HMmBAZgAjAyYghw7HNkijBDIEGG8KrRHOAeNkMgAdCuwK6hOjE1/RDATVjFt2AjQLf4
toW7Fdh1YmonER3wVx5wqIMqQwdAbB3wchPAMjb8MzCF0ChRK0GtNCYKWGz/HzA08LwgDrAqojNz
BCAYIP+EgEogLULAqiEoQ8FfAgMgfwWgTvGIFSYEBuBBkUsQYwZ1IvRvtVMvTUlNf6UAwKG2MiGw
BAApAUogM/+9ULx1vSIl+wyCJ9AvsCFg183TzdMd8ENn8m8kY09Bd7OlFFE0AXjNebxwhsFy7Chz
ppDO1FIdALpFzXm/QtAz4TAxzsWh87fZLcGI/C0wJsAM0KYVzdOZELPwb7sAzokOQc2IRCLBznox
/DMtvHHWkBrzwx3N787/+dANICgeIaOwlKe7BdFf/9Jv03/Uj9WUrTTWn9evJ3D2Ntjv2fk02rzc
8yYTutIFyOV97DAAHgBCEAEAAABAAAAAPDUuMC4xLjQuMi4yMDAxMDgxNjEzMTE0Ni4wMjZjZjQy
MEBleG5hMDcuc2VjdXJpdHlkeW5hbWljcy5jb20+AAMAkhADAAAAAgEUOgEAAAAQAAAAcfd2WhzX
o06PKlvHYQZ0pAMA3j+fTgAAAwAJWQEAAAADAEBlAAAAAAMAAIAIIAYAAAAAAMAAAAAAAABGAAAA
ABCFAAAAAAAAAwADgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAAOOQAQAeAASACCAGAAAAAADAAAAA
AAAARgAAAABUhQAAAQAAAAUAAAAxMC4wAAAAAAsABYAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAA
AAAAAwAGgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALAAeACCAGAAAAAADAAAAAAAAARgAA
AAADhQAAAAAAAAsACIAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAKgAggBgAAAAAAwAAA
AAAAAEYAAAAAGIUAAAAAAAALABaACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAIB+A8BAAAA
EAAAAMYflX7u49MRljwAAIYzWmQCAfoPAQAAABAAAADGH5V+7uPTEZY8AACGM1pkAgH7DwEAAABJ
AAAAAAAAADihuxAF5RAaobsIACsqVsIAAG1zcHN0LmRsbAAAAAAATklUQfm/uAEAqgA32W4AAABD
OlxtYWlsXGN1cnJlbnQucHN0AAAAAAMA/g8FAAAAAwANNP03AgACARQ0AQAAABAAAABOSVRB+b+4
AQCqADfZbgAAAgF/AAEAAAAxAAAAMDAwMDAwMDBDNjFGOTU3RUVFRTNEMzExOTYzQzAwMDA4NjMz
NUE2NEU0NTkyMjAwAAAAAAMABhB1Gi1dAwAHEDUJAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABl
AAAAMUlOVFJPRFVDVElPTjpDTVNBTEdDQU5OT1RIQVZFQVBST1RPQ09MUkVRVUlSRU1FTlRPTkNN
U1BMRUFTRUxPV0VSQ0FTRU1BWVNUQVRFTUVOVFNJTlRIRUZJUlNUUEFSQUdSQQAAAAAqig==

------=_NextPart_000_001A_01C128FF.CCF93460--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7HKQHw05872 for ietf-smime-bks; Fri, 17 Aug 2001 13:26:17 -0700 (PDT)
Received: from sentry.gw.tislabs.com ([e-mail] [192.94.214.100]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7HKQFN05864 for <[e-mail]>; Fri, 17 Aug 2001 13:26:15 -0700 (PDT)
Received: by sentry.gw.tislabs.com; id QAA00829; Fri, 17 Aug 2001 16:30:42 -0400 (EDT)
Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma000812; Fri, 17 Aug 01 16:30:14 -0400
Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id QAA09023 for [e-mail]; Fri, 17 Aug 2001 16:25:49 -0400 (EDT)
Date: Fri, 17 Aug 2001 16:25:49 -0400 (EDT)
From: "David M. Balenson" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: CFP: Submission deadline for NDSS'02 extended to Aug 29th
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Due to the unusually large number of requests for an extension,
the submissions deadline for NDSS'02 has been extended to 
Wednesday August 29, 9:00am EST (U.S. east coast time).
 
Paul Van Oorschot  and Virgil Gligor
Co-Chairs, NDSS'02


                             C A L L   F O R   P A P E R S

Internet Society's 2002 Network and Distributed System Security Symposium  (NDSS'02)

Catamaran Resort - San Diego, California
February 6-8, 2002

IMPORTANT DATES
Paper and panel submissions due August 22, 2001
Author notification October 17, 2001
Final version of papers and panels due November 20, 2001

GOAL: The symposium fosters information exchange among research scientists and practitioners of network and distributed system security services. The target audience includes those interested in practical aspects of network and distributed system security, with a focus on actual system design and implementation (rather than theory). A major goal is to encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. The proceedings are published by the Internet Society.

GENERAL CHAIR: 
Clifford Neuman, USC Information Sciences Institute

PROGRAM CO-CHAIRS:
Paul Van Oorschot, Entrust Technologies
Virgil Gligor, University of Maryland

TUTORIAL CHAIR:
Eric Harder, National Security Agency

LOCAL ARRANGEMENTS CHAIR:
Thomas Hutton, San Diego Supercomputer Center

PUBLICATIONS CHAIR:
Mahesh Tripunitara, Purdue University

PUBLICITY CHAIR:
David Balenson, NAI Labs, Network Associates

LOGISTICS CHAIR:
Terry Weigler, Internet Society

PROGRAM COMMITTEE:
Steve Bellovin, AT&T Labs Research
Dan Boneh, Stanford University
Bill Cheswick, Lumeta Corporation
Li Gong, Sun Microsystems
Peter Gutmann, Univ. of Auckland, N.Z.
Charlie Kaufman, Iris Associates
Steve Kent, BBN Technologies
Markus Kuhn, Univ. of Cambridge, U.K.
Douglas Maughan, DARPA
Kevin McCurley, IBM Almaden Research
Gary McGraw, Cigital
Fabian Monrose, Bell Labs
Sandra Murphy, Network Associates
Radha Poovendran, Univ. of Washington 
Michael Roe, Microsoft Research, U.K. 
Christoph Schuba, Sun Microsystems
Clay Shields, Purdue University
Jonathan Trostle, Cisco Systems
Dan Wallach, Rice University

OUTSTANDING PAPER AWARD: There will be an Outstanding Paper award. The award will be presented at the symposium to the authors of an outstanding paper, as selected by the Program Committee.

SUBMISSIONS: Both technical papers and panel proposals are solicited. Technical papers must include a main body of at most 12 pages, with any additional details in clearly marked appendices for a combined total of at most 20 pages. Technical papers will appear in the proceedings. Panel proposals should be one page and must describe the topic, identify the panel chair, explain the panel format, and list three to four potential panelists. A description of each panel will appear in the proceedings, and may, at the discretion of the panel chair, include written position statements from the panelists.

Submissions are solicited in, but not limited to, the following areas:
* Integrating security in Internet protocols: routing, naming, TCP/IP, multicast, network management, and the Web.
* Intrusion avoidance, detection, and response: systems, experiences and architectures.
* Attack-resistant protocols and services.
* Network perimeter controls: firewalls, packet filters, application gateways.
* Virtual private networks.
* Public key infrastructure, key management, certification, and revocation.
* Secure electronic commerce: e.g., payment, barter, EDI, notarization, timestamping, endorsement, and licensing.
* Supporting security mechanisms and APIs; audit trails; accountability.
* Implementation, deployment and management of network security policies.
* Intellectual property protection: protocols, schemas, implementations, metering, watermarking, digital rights management.
* Fundamental services on network and distributed systems: authentication, data integrity, confidentiality, authorization, non-repudiation, and availability.
* Integrating security services with system and application security facilities and protocols: e.g., message handling, file transport/access, directories, time synchronization, data base management, boot services, mobile computing.
* Security for emerging technologies: sensor networks, specialized testbeds, wireless/mobile (and ad hoc) networks, personal communication systems, and large heterogeneous distributed systems.
* Special problems and case studies: e.g., interplay and tradeoffs between security and efficiency, usability, reliability and cost.
* Security for collaborative applications and services: teleconferencing and video-conferencing, groupwork, etc.

Each submission must contain a separate Submission Overview specifying the submission type (paper or panel), the title or topic, author names with organizational affiliations, and must specify a contact author along with corresponding phone number, FAX number, postal address and email address.

Submissions must be received by August 22, 2001, and must be made electronically in either printable PostScript or PDF. Each submission will be acknowledged by e-mail; if acknowledgment is not received within seven days, contact a program co-chair (see above). Authors and panelists will be notified of acceptance by October 17, 2001, and given instructions for preparing the camera-ready copy. The camera-ready copy must be received by November 20, 2001. 

FURTHER INFORMATION: Official dates, the final call for papers, the advance program, and registration information will be available shortly at http://www.isoc.org/ndss2002. For official submission information, visit http://www.isoc.org/ndss2002/cfp.

Internet Society 

11150 Sunset Hills Road, Suite 100
Reston, VA  20191  USA
Tel:  [phone]
Fax:  [phone]
www.isoc.org

4, rue des Falaises
CH-1205 Geneva
Switzerland
Tel:  [phone]
Fax:  [phone]
www.isoc.org


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7H9OvX08788 for ietf-smime-bks; Fri, 17 Aug 2001 02:24:57 -0700 (PDT)
Received: from swordfish.nexor.co.uk (swordfish.nexor.co.uk [193.63.53.54]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7H9OrN08783 for <[e-mail]>; Fri, 17 Aug 2001 02:24:53 -0700 (PDT)
Received: by swordfish.nexor.co.uk with Internet Mail Service (5.5.2653.19) id <PBCFRZVS>; Fri, 17 Aug 2001 10:23:46 +0100
Message-ID: <[e-mail]>
From: Graeme Lunt <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>
Cc: "'Eggen, Anders'" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "Julian.Onions" <[e-mail]>, Tim Freestone <[e-mail]>
Subject: RE: Comments on draft-ietf-smime-x400wrap-03.txt/draft-ietf-smime -x40 0transport-03.txt
Date: Fri, 17 Aug 2001 10:23:41 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

> Before this approach was adopted, we asked several 
> implementors if their toolkits would handle this sort of nesting.  

> Not a single implementor expressed concern at that time.  

> Do you have new information for us?

No - my point was generic rather than specific - and seeking to
understand the background to the change. It appears to be to
save redundant encoding/bytes. 

I have not reviewed all the toolkits so can't comment on their
support. (FYI: the toolkit we are using is the SFL which does 
allow us to pass in signed-data and enveloped-data, and does
not require a Content-Info wrapper.)

As a user of the toolkit, rather than I provider, I need to be
able to handle the nesting, rather than expecting the toolkit
to do it for me.

For example, after validating the outer signature and retrieving the
ESS label, I want to check that the user is cleared for that label 
before going on to decrypt the next level.


Graeme


Received: by above.proper.com (8.11.3/8.11.3) id f7GJDJf29135 for ietf-smime-bks; Thu, 16 Aug 2001 12:13:19 -0700 (PDT)
Received: from [203.46.112.10] (mail.rsasecurity.com.au [203.46.112.10]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7GJDFN29130 for <[e-mail]>; Thu, 16 Aug 2001 12:13:16 -0700 (PDT)
Received: from [192.168.18.3] by [203.46.112.10] via smtpd (for [208.184.76.43]) with SMTP; 1 Apr 2001 16:12:46 UT
Received: from exaus01.local.aus.rsa.com (exaus01.local.aus.rsa.com [10.177.1.15]) by grover.local.aus.rsa.com (8.10.2/8.10.2) with ESMTP id f7GJH3q25155 for <[e-mail]>; Fri, 17 Aug 2001 05:17:07 +1000 (EST)
Received: by exaus01.local.aus.rsa.com with Internet Mail Service (5.5.2653.19) id <QX7R47P2>; Fri, 17 Aug 2001 05:09:20 +1000
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.101]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWC3J8X; Thu, 16 Aug 2001 15:12:47 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 16 Aug 2001 13:14:56 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: WG Last Call: rfc2630bis and cmsalg
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The update to CMS is ready for WG Last Call.  Please post all comments on 
both documents to the S/MIME WG mail list by 31 August 2001.

	Title		: Cryptographic Message Syntax
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-rfc2630bis-02.txt
	Pages		: 52
	Date		: 13-Aug-01


	Title		: Cryptographic Message Syntax (CMS) Algorithms
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cmsalg-02.txt
	Pages		: 26
	Date		: 14-Aug-01
	
Russ 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7GDggb12631 for ietf-smime-bks; Thu, 16 Aug 2001 06:42:42 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7GDgeN12625 for <[e-mail]>; Thu, 16 Aug 2001 06:42:40 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 16 Aug 2001 13:40:30 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA05389; Thu, 16 Aug 2001 09:42:02 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <QTWC3D00>; Thu, 16 Aug 2001 09:42:31 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.100]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWC3D05; Thu, 16 Aug 2001 09:42:27 -0400
From: "Housley, Russ" <[e-mail]>
To: Graeme Lunt <[e-mail]>
Cc: "'Eggen, Anders'" <[e-mail]>, "'[e-mail] '" <[e-mail]>, "Julian.Onions" <[e-mail]>, Tim Freestone <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 16 Aug 2001 09:32:03 -0400
Subject: RE: Comments on draft-ietf-smime-x400wrap-03.txt/draft-ietf-smime -x40 0transport-03.txt
In-Reply-To: <[e-mail]. uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Graeme:

Before this approach was adopted, we asked several implementors if their 
toolkits would handle this sort of nesting.  Not a single implementor 
expressed concern at that time.  Do you have new information for us?

Russ

At 05:16 PM 8/15/2001 +0100, Graeme Lunt wrote:

>Anders,
>
> > I have given an explanation below for why we removed some of the
> > ContentInfo wrappers in the steps for tripple wrapping of an X.400
> > content.
>
>Thanks for the feedback.
>
> > Since we don't have the MIME wrappings, we don't need the ContentInfo
> > wrappings either. The ContentType OIDs in SignedData and EnvelopedData
> > will identify the encapsulatet content (or content type).  ContentInfo
> > needs only to be used around the outer most SignedData because this is
> > required by PKCS #7 and CMS.
> > The ContentInfo wrappings will only introduce an unnecessary level of
> > indirection, and you will have to modify your ESS code for SMTP anyway
> > because the MIME wrappers are gone.  Thus, a triple wrapped message will
> > have the following form:
> >          X.400 Envelope  ->  id-ct-contentInfo
> >          ContentInfo     ->  id-signedData
> >          SignedData      ->  id-envelopedData
> >          EnvelopedData   ->  id-signedData
> >          SignedData      ->  <OID for content type>
> > If you want to produce a "signed-only" version of a triple wrapped
> > message, all you need to do is to wrap the inner most SignedData in a
> > ContentInfo and forward it which should be a pretty easy operation.
>
>I agree entirely that the ContentInfo wrappings are not needed as you can
>carry all the information required in the structure you outline.
>
>I just think that ContentInfo are more generic and what I might expect
>toolkits to actually process as their basic unit e.g. a Verify() function
>is likely to take a ContentInfo - as I can use it for the outer signature
>(passing the raw content) or the inner signature (passing the content
>returned
>from Decrypt()).
>
>The Verify() function may, of course, just take a signed-data, but it is
>more
>straight-forward to seek to the Signed-Data in the Content-Info ASN.1
>stream,
>rather than wrap up the Signed-Data ASN.1 into a Content-Info ASN.1
>(especially
>for large messages).
>
>Anyway, the current draft is workable - I'm just trying to understand the
>change.
>
>Thanks,
>
>Graeme


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7GCq6n11183 for ietf-smime-bks; Thu, 16 Aug 2001 05:52:06 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7GCq4N11178 for <[e-mail]>; Thu, 16 Aug 2001 05:52:04 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 16 Aug 2001 12:49:54 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA00853 for <[e-mail]>; Thu, 16 Aug 2001 08:51:35 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <QTWC3DF8>; Thu, 16 Aug 2001 08:52:04 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.100]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWC3DFX; Thu, 16 Aug 2001 08:51:58 -0400
From: "Housley, Russ" <[e-mail]>
To: "Bonatti, Chris" <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 15 Aug 2001 10:58:15 -0400
Subject: RE: Comments on draft-ietf-smime-x400wrap-03
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris:

Fine.  I think that Blake will need to expand his discussion to pick up all 
of the details that are no longer in RFC2630bis and CMSALG.

Russ

At 09:20 PM 8/14/2001 -0400, Bonatti, Chris wrote:
>Russ,
>
>I think that referencing son-of-MSG would be best, since the protection is 
>really targeted at the same kind of functional use... e-mail.  It's just a 
>different e-mail.
>
>I'll take a look at Blake's draft and see whether I can propose some text.
>
>Chris
>
>
>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]]On Behalf Of Housley, Russ
>Sent: Tuesday, August 14, 2001 15:48
>To: [e-mail]
>Subject: RE: Comments on draft-ietf-smime-x400wrap-03
>
>
>
>Correct.  At the face-to-face meeting in London last week, there was strong
>consensus that the CMS not specify any mandatory to implement
>algorithms.  I just sent of the revised I-Ds to implement this
>decision.  As a result, all protocols that employ the CMS MUST specify
>their mandatory to implement algorithms.  However, in this case, x400wrap
>may want to reference the son-of-rfc 2632 and son-of-rfc 2633 documents to
>ensure comparability.
>
>Russ
>
>At 10:29 AM 8/8/2001 +0100, Jim Schaad wrote:
> > > 1.  Is it intentional that there is no section on content encryption
> > > algorithms for MUSTs?
> >
> >Yes.  From the beginning, the model for this draft was RFC 2633.  We
> >dealt with this only in the "options" for CMS, and what it says has
> >crept in through various comments.
> >
> >I would be content to say nothing about algorithms in WRAP, and leave
> >the topic to CMS (Son-of-CMS).  However, I don't think the division is
> >easy to make cleanly.
> >
> >[JLS]  With the most recent change of omitting algorithms from CMS, this
> >section is now required both here and in the message draft.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7GCq4811177 for ietf-smime-bks; Thu, 16 Aug 2001 05:52:04 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7GCq2N11172 for <[e-mail]>; Thu, 16 Aug 2001 05:52:02 -0700 (PDT)
Received: from sdtihq24.securid.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 16 Aug 2001 12:49:52 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA00842 for <[e-mail]>; Thu, 16 Aug 2001 08:51:33 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <QTWC3DF6>; Thu, 16 Aug 2001 08:52:01 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.100]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWC3DFY; Thu, 16 Aug 2001 08:51:58 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Wed, 15 Aug 2001 11:20:47 -0400
Subject: RE: Comments on draft-ietf-smime-x400wrap-03
In-Reply-To: <000001c12560$acfd63e0$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim:

You are correct that this approach might delay the x400wrap document.  The 
alternative is to replicate the same information in both documents.

Russ

At 01:02 AM 8/15/2001 -0700, Jim Schaad wrote:
>I am not sure that I agree with this.  I would like to see these drafts
>progress and that cannot happen if you are going to reference son-of-MSG
>until it finishes.
>
>jim
>
>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]] On Behalf Of Bonatti, Chris
>Sent: Tuesday, August 14, 2001 6:20 PM
>To: Housley, Russ; [e-mail]
>Subject: RE: Comments on draft-ietf-smime-x400wrap-03
>
>
>
>Russ,
>
>I think that referencing son-of-MSG would be best, since the protection
>is really targeted at the same kind of functional use... e-mail.  It's
>just a different e-mail.
>
>I'll take a look at Blake's draft and see whether I can propose some
>text.
>
>Chris
>
>
>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]]On Behalf Of Housley, Russ
>Sent: Tuesday, August 14, 2001 15:48
>To: [e-mail]
>Subject: RE: Comments on draft-ietf-smime-x400wrap-03
>
>
>
>Correct.  At the face-to-face meeting in London last week, there was
>strong
>consensus that the CMS not specify any mandatory to implement
>algorithms.  I just sent of the revised I-Ds to implement this
>decision.  As a result, all protocols that employ the CMS MUST specify
>their mandatory to implement algorithms.  However, in this case,
>x400wrap
>may want to reference the son-of-rfc 2632 and son-of-rfc 2633 documents
>to
>ensure comparability.
>
>Russ
>
>At 10:29 AM 8/8/2001 +0100, Jim Schaad wrote:
> > > 1.  Is it intentional that there is no section on content encryption
> > > algorithms for MUSTs?
> >
> >Yes.  From the beginning, the model for this draft was RFC 2633.  We
> >dealt with this only in the "options" for CMS, and what it says has
> >crept in through various comments.
> >
> >I would be content to say nothing about algorithms in WRAP, and leave
> >the topic to CMS (Son-of-CMS).  However, I don't think the division is
> >easy to make cleanly.
> >
> >[JLS]  With the most recent change of omitting algorithms from CMS,
>this
> >section is now required both here and in the message draft.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7G76BE13771 for ietf-smime-bks; Thu, 16 Aug 2001 00:06:11 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7G769N13762 for <[e-mail]>; Thu, 16 Aug 2001 00:06:09 -0700 (PDT)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA05676; Thu, 16 Aug 2001 09:07:49 +0200
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id JAA14824; Thu, 16 Aug 2001 09:05:33 +0200
Message-ID: <[e-mail]>
Date: Thu, 16 Aug 2001 09:05:40 +0200
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Bernd Kunze <[e-mail]>
CC: "'SMIME list (E-Mail on IMC)'" <[e-mail]>
Subject: Re: draft-ietf-smime-esformats Commitment Indication Type Attribute
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Bernd,

> In this draft we have the Commitment Indication Type Attribute indicating a
> type of commitment to the message. We have a generic type proofOfApproval.
> But in some cases I would not approve the message and tell it to the other
> party. But there is no generic type to indicate that.

> Is there a way to add this as a new generic commitment type?

If someone does not approve, then he should not sign ! So expressing
disapproval, does not require the definition of a new commitment type.  

Generally speaking, should there be the need to define an additional
commitment type, just use an OID of your choice.

A requirements study would be needed to define additional generic commitment
types. Until we have some return from experience this seems difficult at
this time, ... unless you would already have a document where such a study
has been done. When this happens, a companion document could refrence or
define additional commitment types.

Denis

> Bernd


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7FKgYg11518 for ietf-smime-bks; Wed, 15 Aug 2001 13:42:34 -0700 (PDT)
Received: from post.ffi.no (post.ffi.no [193.156.99.133]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FKgXN11513 for <[e-mail]>; Wed, 15 Aug 2001 13:42:33 -0700 (PDT)
Received: by post.ffi.no with Internet Mail Service (5.5.2653.19) id <QAX2W8HX>; Wed, 15 Aug 2001 22:42:22 +0200
Message-ID: <[e-mail]>
From: "Eggen, Anders" <[e-mail]>
To: "'Jim Schaad '" <[e-mail]>, "''Bonatti, Chris' '" <[e-mail]>, "''Housley, Russ' '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: Comments on draft-ietf-smime-x400wrap-03
Date: Wed, 15 Aug 2001 22:42:18 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C125CA.C6A973A0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

------_=_NextPart_001_01C125CA.C6A973A0
Content-Type: text/plain;
	charset="ISO-8859-1"

Jim and Chris

I'm OK with "aligning with" instead of "referencing".  

Anders

-----Original Message-----
From: Jim Schaad
To: 'Bonatti, Chris'; 'Housley, Russ'; [e-mail]
Sent: 15.08.01 21:05
Subject: RE: Comments on draft-ietf-smime-x400wrap-03


Alignment rather than reference makes more sense to me.  Then the two
communities can upgrade at different rates on algorithms etc according
to desires of the different groups.  (X.400 might be more security aware
than the general community.)

jim

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Bonatti, Chris
Sent: Wednesday, August 15, 2001 8:54 AM
To: [e-mail]; 'Housley, Russ'; [e-mail]
Subject: RE: Comments on draft-ietf-smime-x400wrap-03



Jim,

This is a good point that I hadn't considered.  I can go with "aligning
with" instead of "referencing".  Okay?

Chris


-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Wednesday, August 15, 2001 04:03
To: 'Bonatti, Chris'; 'Housley, Russ'; [e-mail]
Subject: RE: Comments on draft-ietf-smime-x400wrap-03


I am not sure that I agree with this.  I would like to see these drafts
progress and that cannot happen if you are going to reference son-of-MSG
until it finishes.

jim

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Bonatti, Chris
Sent: Tuesday, August 14, 2001 6:20 PM
To: Housley, Russ; [e-mail]
Subject: RE: Comments on draft-ietf-smime-x400wrap-03



Russ,

I think that referencing son-of-MSG would be best, since the protection
is really targeted at the same kind of functional use... e-mail.  It's
just a different e-mail.

I'll take a look at Blake's draft and see whether I can propose some
text.

Chris


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Housley, Russ
Sent: Tuesday, August 14, 2001 15:48
To: [e-mail]
Subject: RE: Comments on draft-ietf-smime-x400wrap-03



Correct.  At the face-to-face meeting in London last week, there was
strong 
consensus that the CMS not specify any mandatory to implement 
algorithms.  I just sent of the revised I-Ds to implement this 
decision.  As a result, all protocols that employ the CMS MUST specify 
their mandatory to implement algorithms.  However, in this case,
x400wrap 
may want to reference the son-of-rfc 2632 and son-of-rfc 2633 documents
to 
ensure comparability.

Russ

At 10:29 AM 8/8/2001 +0100, Jim Schaad wrote:
> > 1.  Is it intentional that there is no section on content encryption
> > algorithms for MUSTs?
>
>Yes.  From the beginning, the model for this draft was RFC 2633.  We
>dealt with this only in the "options" for CMS, and what it says has
>crept in through various comments.
>
>I would be content to say nothing about algorithms in WRAP, and leave
>the topic to CMS (Son-of-CMS).  However, I don't think the division is
>easy to make cleanly.
>
>[JLS]  With the most recent change of omitting algorithms from CMS,
this
>section is now required both here and in the message draft.

------_=_NextPart_001_01C125CA.C6A973A0
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Comments on draft-ietf-smime-x400wrap-03</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Jim and Chris</FONT>
</P>

<P><FONT SIZE=3D2>I'm OK with &quot;aligning with&quot; instead of =
&quot;referencing&quot;.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>Anders</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Jim Schaad</FONT>
<BR><FONT SIZE=3D2>To: 'Bonatti, Chris'; 'Housley, Russ'; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>Sent: 15.08.01 21:05</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Comments on =
draft-ietf-smime-x400wrap-03</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Alignment rather than reference makes more sense to =
me.&nbsp; Then the two</FONT>
<BR><FONT SIZE=3D2>communities can upgrade at different rates on =
algorithms etc according</FONT>
<BR><FONT SIZE=3D2>to desires of the different groups.&nbsp; (X.400 =
might be more security aware</FONT>
<BR><FONT SIZE=3D2>than the general community.)</FONT>
</P>

<P><FONT SIZE=3D2>jim</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [e-mail]</FONT>
<BR><FONT SIZE=3D2>[<A =
HREF=3D"mailto:[e-mail]">mailto:owner-ietf-smime@ma=
il.imc.org</A>] On Behalf Of Bonatti, Chris</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, August 15, 2001 8:54 AM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]; 'Housley, Russ'; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Comments on =
draft-ietf-smime-x400wrap-03</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Jim,</FONT>
</P>

<P><FONT SIZE=3D2>This is a good point that I hadn't considered.&nbsp; =
I can go with &quot;aligning</FONT>
<BR><FONT SIZE=3D2>with&quot; instead of &quot;referencing&quot;.&nbsp; =
Okay?</FONT>
</P>

<P><FONT SIZE=3D2>Chris</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Jim Schaad [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, August 15, 2001 04:03</FONT>
<BR><FONT SIZE=3D2>To: 'Bonatti, Chris'; 'Housley, Russ'; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Comments on =
draft-ietf-smime-x400wrap-03</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I am not sure that I agree with this.&nbsp; I would =
like to see these drafts</FONT>
<BR><FONT SIZE=3D2>progress and that cannot happen if you are going to =
reference son-of-MSG</FONT>
<BR><FONT SIZE=3D2>until it finishes.</FONT>
</P>

<P><FONT SIZE=3D2>jim</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [e-mail]</FONT>
<BR><FONT SIZE=3D2>[<A =
HREF=3D"mailto:[e-mail]">mailto:owner-ietf-smime@ma=
il.imc.org</A>] On Behalf Of Bonatti, Chris</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, August 14, 2001 6:20 PM</FONT>
<BR><FONT SIZE=3D2>To: Housley, Russ; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Comments on =
draft-ietf-smime-x400wrap-03</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Russ,</FONT>
</P>

<P><FONT SIZE=3D2>I think that referencing son-of-MSG would be best, =
since the protection</FONT>
<BR><FONT SIZE=3D2>is really targeted at the same kind of functional =
use... e-mail.&nbsp; It's</FONT>
<BR><FONT SIZE=3D2>just a different e-mail.</FONT>
</P>

<P><FONT SIZE=3D2>I'll take a look at Blake's draft and see whether I =
can propose some</FONT>
<BR><FONT SIZE=3D2>text.</FONT>
</P>

<P><FONT SIZE=3D2>Chris</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [e-mail]</FONT>
<BR><FONT SIZE=3D2>[<A =
HREF=3D"mailto:[e-mail]">mailto:owner-ietf-smime@ma=
il.imc.org</A>]On Behalf Of Housley, Russ</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, August 14, 2001 15:48</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Comments on =
draft-ietf-smime-x400wrap-03</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Correct.&nbsp; At the face-to-face meeting in London =
last week, there was</FONT>
<BR><FONT SIZE=3D2>strong </FONT>
<BR><FONT SIZE=3D2>consensus that the CMS not specify any mandatory to =
implement </FONT>
<BR><FONT SIZE=3D2>algorithms.&nbsp; I just sent of the revised I-Ds to =
implement this </FONT>
<BR><FONT SIZE=3D2>decision.&nbsp; As a result, all protocols that =
employ the CMS MUST specify </FONT>
<BR><FONT SIZE=3D2>their mandatory to implement algorithms.&nbsp; =
However, in this case,</FONT>
<BR><FONT SIZE=3D2>x400wrap </FONT>
<BR><FONT SIZE=3D2>may want to reference the son-of-rfc 2632 and =
son-of-rfc 2633 documents</FONT>
<BR><FONT SIZE=3D2>to </FONT>
<BR><FONT SIZE=3D2>ensure comparability.</FONT>
</P>

<P><FONT SIZE=3D2>Russ</FONT>
</P>

<P><FONT SIZE=3D2>At 10:29 AM 8/8/2001 +0100, Jim Schaad wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 1.&nbsp; Is it intentional that there is =
no section on content encryption</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; algorithms for MUSTs?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Yes.&nbsp; From the beginning, the model for =
this draft was RFC 2633.&nbsp; We</FONT>
<BR><FONT SIZE=3D2>&gt;dealt with this only in the &quot;options&quot; =
for CMS, and what it says has</FONT>
<BR><FONT SIZE=3D2>&gt;crept in through various comments.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;I would be content to say nothing about =
algorithms in WRAP, and leave</FONT>
<BR><FONT SIZE=3D2>&gt;the topic to CMS (Son-of-CMS).&nbsp; However, I =
don't think the division is</FONT>
<BR><FONT SIZE=3D2>&gt;easy to make cleanly.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;[JLS]&nbsp; With the most recent change of =
omitting algorithms from CMS,</FONT>
<BR><FONT SIZE=3D2>this</FONT>
<BR><FONT SIZE=3D2>&gt;section is now required both here and in the =
message draft.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C125CA.C6A973A0--


Received: by above.proper.com (8.11.3/8.11.3) id f7FJBah08049 for ietf-smime-bks; Wed, 15 Aug 2001 12:11:36 -0700 (PDT)
Received: from femail40.sdc1.sfba.home.com (femail40.sdc1.sfba.home.com [24.254.60.34]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FJBWN08033 for <[e-mail]>; Wed, 15 Aug 2001 12:11:32 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail40.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010815191129.NGTA25522.femail40.sdc1.sfba.home.com@revelation>; Wed, 15 Aug 2001 12:11:29 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>, "'Bonatti, Chris'" <[e-mail]>
Subject: EITs in the x400-transport draft
Date: Wed, 15 Aug 2001 12:11:43 -0700
Message-ID: <000c01c125be$1f25a7e0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2505.0000
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Based on the conversations that were held in London about propigating
smime-types up.  I would like to propose that we remove enveloped-x400
content and signed-x400 content EITs and replace it with x400-content
EITs and S/MIME types.  This is a difference from the SMIME-types from
the message draft, but in retrospect I believe that knowing the content
is of more importance that trying to one of the potentially many
security services.  This also eases the code in moving SMIME-types from
layer to layer.

Jim



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7FJ4tD07749 for ietf-smime-bks; Wed, 15 Aug 2001 12:04:55 -0700 (PDT)
Received: from femail41.sdc1.sfba.home.com (femail41.sdc1.sfba.home.com [24.254.60.35]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FJ4sN07745 for <[e-mail]>; Wed, 15 Aug 2001 12:04:54 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail41.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010815190448.NTGG2348.femail41.sdc1.sfba.home.com@revelation>; Wed, 15 Aug 2001 12:04:48 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Bonatti, Chris'" <[e-mail]>, "'Housley, Russ'" <[e-mail]>, <[e-mail]>
Subject: RE: Comments on draft-ietf-smime-x400wrap-03
Date: Wed, 15 Aug 2001 12:05:02 -0700
Message-ID: <000b01c125bd$30410a20$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2505.0000
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alignment rather than reference makes more sense to me.  Then the two
communities can upgrade at different rates on algorithms etc according
to desires of the different groups.  (X.400 might be more security aware
than the general community.)

jim

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Bonatti, Chris
Sent: Wednesday, August 15, 2001 8:54 AM
To: [e-mail]; 'Housley, Russ'; [e-mail]
Subject: RE: Comments on draft-ietf-smime-x400wrap-03



Jim,

This is a good point that I hadn't considered.  I can go with "aligning
with" instead of "referencing".  Okay?

Chris


-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Wednesday, August 15, 2001 04:03
To: 'Bonatti, Chris'; 'Housley, Russ'; [e-mail]
Subject: RE: Comments on draft-ietf-smime-x400wrap-03


I am not sure that I agree with this.  I would like to see these drafts
progress and that cannot happen if you are going to reference son-of-MSG
until it finishes.

jim

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Bonatti, Chris
Sent: Tuesday, August 14, 2001 6:20 PM
To: Housley, Russ; [e-mail]
Subject: RE: Comments on draft-ietf-smime-x400wrap-03



Russ,

I think that referencing son-of-MSG would be best, since the protection
is really targeted at the same kind of functional use... e-mail.  It's
just a different e-mail.

I'll take a look at Blake's draft and see whether I can propose some
text.

Chris


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Housley, Russ
Sent: Tuesday, August 14, 2001 15:48
To: [e-mail]
Subject: RE: Comments on draft-ietf-smime-x400wrap-03



Correct.  At the face-to-face meeting in London last week, there was
strong 
consensus that the CMS not specify any mandatory to implement 
algorithms.  I just sent of the revised I-Ds to implement this 
decision.  As a result, all protocols that employ the CMS MUST specify 
their mandatory to implement algorithms.  However, in this case,
x400wrap 
may want to reference the son-of-rfc 2632 and son-of-rfc 2633 documents
to 
ensure comparability.

Russ

At 10:29 AM 8/8/2001 +0100, Jim Schaad wrote:
> > 1.  Is it intentional that there is no section on content encryption
> > algorithms for MUSTs?
>
>Yes.  From the beginning, the model for this draft was RFC 2633.  We
>dealt with this only in the "options" for CMS, and what it says has
>crept in through various comments.
>
>I would be content to say nothing about algorithms in WRAP, and leave
>the topic to CMS (Son-of-CMS).  However, I don't think the division is
>easy to make cleanly.
>
>[JLS]  With the most recent change of omitting algorithms from CMS,
this
>section is now required both here and in the message draft.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7FHSCE03130 for ietf-smime-bks; Wed, 15 Aug 2001 10:28:12 -0700 (PDT)
Received: from hamburg01.hamburg.intershop.de ([62.132.124.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FHSBN03125 for <[e-mail]>; Wed, 15 Aug 2001 10:28:11 -0700 (PDT)
Received: by HAMBURG01 with Internet Mail Service (5.5.2650.21) id <QQVV3Q21>; Wed, 15 Aug 2001 19:25:59 +0200
Message-ID: <[e-mail]>
From: Bernd Kunze <[e-mail]>
To: "'SMIME list (E-Mail on IMC)'" <[e-mail]>
Subject: draft-ietf-smime-esformats Commitment Indication Type Attribute
Date: Wed, 15 Aug 2001 19:27:58 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In this draft we have the Commitment Indication Type Attribute indicating a
type of commitment to the message. We have a generic type proofOfApproval.
But in some cases I would not approve the message and tell it to the other
party. But there is no generic type to indicate that. 
Is there a way to add this as a new generic commitment type?

Bernd


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7FGHG800100 for ietf-smime-bks; Wed, 15 Aug 2001 09:17:16 -0700 (PDT)
Received: from swordfish.nexor.co.uk (swordfish.nexor.co.uk [193.63.53.54]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FGHDN29996 for <[e-mail]>; Wed, 15 Aug 2001 09:17:14 -0700 (PDT)
Received: by swordfish.nexor.co.uk with Internet Mail Service (5.5.2653.19) id <PBCFRZ3G>; Wed, 15 Aug 2001 17:16:32 +0100
Message-ID: <[e-mail]>
From: Graeme Lunt <[e-mail]>
To: "'Eggen, Anders'" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Cc: "Julian.Onions" <[e-mail]>, Tim Freestone <[e-mail]>
Subject: RE: Comments on draft-ietf-smime-x400wrap-03.txt/draft-ietf-smime -x40 0transport-03.txt
Date: Wed, 15 Aug 2001 17:16:26 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

> I have given an explanation below for why we removed some of the  
> ContentInfo wrappers in the steps for tripple wrapping of an X.400 
> content. 

Thanks for the feedback.

> Since we don't have the MIME wrappings, we don't need the ContentInfo 
> wrappings either. The ContentType OIDs in SignedData and EnvelopedData 
> will identify the encapsulatet content (or content type).  ContentInfo 
> needs only to be used around the outer most SignedData because this is 
> required by PKCS #7 and CMS.   
> The ContentInfo wrappings will only introduce an unnecessary level of 
> indirection, and you will have to modify your ESS code for SMTP anyway 
> because the MIME wrappers are gone.  Thus, a triple wrapped message will 
> have the following form: 
>          X.400 Envelope  ->  id-ct-contentInfo 
>          ContentInfo     ->  id-signedData 
>          SignedData      ->  id-envelopedData 
>          EnvelopedData   ->  id-signedData 
>          SignedData      ->  <OID for content type> 
> If you want to produce a "signed-only" version of a triple wrapped 
> message, all you need to do is to wrap the inner most SignedData in a 
> ContentInfo and forward it which should be a pretty easy operation.

I agree entirely that the ContentInfo wrappings are not needed as you can
carry all the information required in the structure you outline.

I just think that ContentInfo are more generic and what I might expect
toolkits to actually process as their basic unit e.g. a Verify() function
is likely to take a ContentInfo - as I can use it for the outer signature 
(passing the raw content) or the inner signature (passing the content
returned 
from Decrypt()).

The Verify() function may, of course, just take a signed-data, but it is
more
straight-forward to seek to the Signed-Data in the Content-Info ASN.1
stream, 
rather than wrap up the Signed-Data ASN.1 into a Content-Info ASN.1
(especially
for large messages).

Anyway, the current draft is workable - I'm just trying to understand the
change.

Thanks,

Graeme



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7FFsFQ28036 for ietf-smime-bks; Wed, 15 Aug 2001 08:54:15 -0700 (PDT)
Received: from smtp-a.capu.net (IDENT:[e-mail] [64.50.133.50]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FFsEN28030 for <[e-mail]>; Wed, 15 Aug 2001 08:54:14 -0700 (PDT)
Received: from bonattigateway (dial-216-63.capu.net [64.50.216.63]) by smtp-a.capu.net (8.9.3/8.9.3) with SMTP id LAA15634; Wed, 15 Aug 2001 11:53:59 -0400
From: "Bonatti, Chris" <[e-mail]>
To: <[e-mail]>, "'Housley, Russ'" <[e-mail]>, <[e-mail]>
Subject: RE: Comments on draft-ietf-smime-x400wrap-03
Date: Wed, 15 Aug 2001 11:53:59 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <000001c12560$acfd63e0$[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f7FFsEN28032
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim,

This is a good point that I hadn't considered.  I can go with "aligning with" instead of "referencing".  Okay?

Chris


-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Wednesday, August 15, 2001 04:03
To: 'Bonatti, Chris'; 'Housley, Russ'; [e-mail]
Subject: RE: Comments on draft-ietf-smime-x400wrap-03


I am not sure that I agree with this.  I would like to see these drafts
progress and that cannot happen if you are going to reference son-of-MSG
until it finishes.

jim

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Bonatti, Chris
Sent: Tuesday, August 14, 2001 6:20 PM
To: Housley, Russ; [e-mail]
Subject: RE: Comments on draft-ietf-smime-x400wrap-03



Russ,

I think that referencing son-of-MSG would be best, since the protection
is really targeted at the same kind of functional use... e-mail.  It's
just a different e-mail.

I'll take a look at Blake's draft and see whether I can propose some
text.

Chris


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Housley, Russ
Sent: Tuesday, August 14, 2001 15:48
To: [e-mail]
Subject: RE: Comments on draft-ietf-smime-x400wrap-03



Correct.  At the face-to-face meeting in London last week, there was
strong 
consensus that the CMS not specify any mandatory to implement 
algorithms.  I just sent of the revised I-Ds to implement this 
decision.  As a result, all protocols that employ the CMS MUST specify 
their mandatory to implement algorithms.  However, in this case,
x400wrap 
may want to reference the son-of-rfc 2632 and son-of-rfc 2633 documents
to 
ensure comparability.

Russ

At 10:29 AM 8/8/2001 +0100, Jim Schaad wrote:
> > 1.  Is it intentional that there is no section on content encryption
> > algorithms for MUSTs?
>
>Yes.  From the beginning, the model for this draft was RFC 2633.  We
>dealt with this only in the "options" for CMS, and what it says has
>crept in through various comments.
>
>I would be content to say nothing about algorithms in WRAP, and leave
>the topic to CMS (Son-of-CMS).  However, I don't think the division is
>easy to make cleanly.
>
>[JLS]  With the most recent change of omitting algorithms from CMS,
this
>section is now required both here and in the message draft.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7FDTPJ20019 for ietf-smime-bks; Wed, 15 Aug 2001 06:29:25 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FDTNN20014 for <[e-mail]>; Wed, 15 Aug 2001 06:29:23 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA07299; Wed, 15 Aug 2001 15:29:13 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 15 Aug 2001 15:29:13 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA25101; Wed, 15 Aug 2001 15:29:12 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA06108; Wed, 15 Aug 2001 15:29:11 +0200 (MET DST)
Date: Wed, 15 Aug 2001 15:29:11 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: rfc2534 and multiple signing certificate attributes
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> Peter:
> 
> You are referring to ESS, RFC 2634, right?
ooops, yes.
 
> 
> In some cases, signatures are serial.  In this case, a countersignature 
> that contains the current Signing Certificate Attribute is sufficient.

In this case, too, the first signer or the document policy might want to
indicate: 'my signature is only valid if there is a countersignature from
"the boss"'. 

> 
> In other cases, signatures are parallel.  I think that your comments apply 
> to this situation.  Here, multiple signer info structures are present, each 
> with it's own Signing Certificate Attribute.  You are looking for a way to 
> bind two or more signer info structures together.  Am I understanding your 
> concern correctly?

Yes, binding together and making the signature validation fail if not all 
necessary signatures are present. 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7FB1vJ13271 for ietf-smime-bks; Wed, 15 Aug 2001 04:01:57 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7FB1uN13266 for <[e-mail]>; Wed, 15 Aug 2001 04:01:56 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12393; Wed, 15 Aug 2001 07:00:43 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-cmsalg-02.txt
Date: Wed, 15 Aug 2001 07:00:43 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Cryptographic Message Syntax (CMS) Algorithms
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cmsalg-02.txt
	Pages		: 26
	Date		: 14-Aug-01
	
This document describes cryptographic algorithms for use with the
Cryptographic Message Syntax (CMS) [CMS].  CMS is used to digitally
sign, digest, authenticate, or encrypt arbitrary messages.

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

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-cmsalg-02.txt".

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cmsalg-02.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7F82eb29670 for ietf-smime-bks; Wed, 15 Aug 2001 01:02:40 -0700 (PDT)
Received: from femail32.sdc1.sfba.home.com (femail32.sdc1.sfba.home.com [24.254.60.22]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7F82cN29665 for <[e-mail]>; Wed, 15 Aug 2001 01:02:38 -0700 (PDT)
Received: from revelation ([65.4.166.11]) by femail32.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010815080233.XCJX20799.femail32.sdc1.sfba.home.com@revelation>; Wed, 15 Aug 2001 01:02:33 -0700
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Bonatti, Chris'" <[e-mail]>, "'Housley, Russ'" <[e-mail]>, <[e-mail]>
Subject: RE: Comments on draft-ietf-smime-x400wrap-03
Date: Wed, 15 Aug 2001 01:02:48 -0700
Message-ID: <000001c12560$acfd63e0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2505.0000
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am not sure that I agree with this.  I would like to see these drafts
progress and that cannot happen if you are going to reference son-of-MSG
until it finishes.

jim

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Bonatti, Chris
Sent: Tuesday, August 14, 2001 6:20 PM
To: Housley, Russ; [e-mail]
Subject: RE: Comments on draft-ietf-smime-x400wrap-03



Russ,

I think that referencing son-of-MSG would be best, since the protection
is really targeted at the same kind of functional use... e-mail.  It's
just a different e-mail.

I'll take a look at Blake's draft and see whether I can propose some
text.

Chris


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Housley, Russ
Sent: Tuesday, August 14, 2001 15:48
To: [e-mail]
Subject: RE: Comments on draft-ietf-smime-x400wrap-03



Correct.  At the face-to-face meeting in London last week, there was
strong 
consensus that the CMS not specify any mandatory to implement 
algorithms.  I just sent of the revised I-Ds to implement this 
decision.  As a result, all protocols that employ the CMS MUST specify 
their mandatory to implement algorithms.  However, in this case,
x400wrap 
may want to reference the son-of-rfc 2632 and son-of-rfc 2633 documents
to 
ensure comparability.

Russ

At 10:29 AM 8/8/2001 +0100, Jim Schaad wrote:
> > 1.  Is it intentional that there is no section on content encryption
> > algorithms for MUSTs?
>
>Yes.  From the beginning, the model for this draft was RFC 2633.  We
>dealt with this only in the "options" for CMS, and what it says has
>crept in through various comments.
>
>I would be content to say nothing about algorithms in WRAP, and leave
>the topic to CMS (Son-of-CMS).  However, I don't think the division is
>easy to make cleanly.
>
>[JLS]  With the most recent change of omitting algorithms from CMS,
this
>section is now required both here and in the message draft.



Received: by above.proper.com (8.11.3/8.11.3) id f7F1KQU03699 for ietf-smime-bks; Tue, 14 Aug 2001 18:20:26 -0700 (PDT)
Received: from smtp-a.capu.net (IDENT:[e-mail] [64.50.133.50]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7F1KPN03695 for <[e-mail]>; Tue, 14 Aug 2001 18:20:25 -0700 (PDT)
Received: from bonattigateway (dial-216-125.capu.net [64.50.216.125]) by smtp-a.capu.net (8.9.3/8.9.3) with SMTP id VAA12056; Tue, 14 Aug 2001 21:20:26 -0400
From: "Bonatti, Chris" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, <[e-mail]>
Subject: RE: Comments on draft-ietf-smime-x400wrap-03
Date: Tue, 14 Aug 2001 21:20:27 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f7F1KQN03696
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

I think that referencing son-of-MSG would be best, since the protection is really targeted at the same kind of functional use... e-mail.  It's just a different e-mail.

I'll take a look at Blake's draft and see whether I can propose some text.

Chris


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Housley, Russ
Sent: Tuesday, August 14, 2001 15:48
To: [e-mail]
Subject: RE: Comments on draft-ietf-smime-x400wrap-03



Correct.  At the face-to-face meeting in London last week, there was strong 
consensus that the CMS not specify any mandatory to implement 
algorithms.  I just sent of the revised I-Ds to implement this 
decision.  As a result, all protocols that employ the CMS MUST specify 
their mandatory to implement algorithms.  However, in this case, x400wrap 
may want to reference the son-of-rfc 2632 and son-of-rfc 2633 documents to 
ensure comparability.

Russ

At 10:29 AM 8/8/2001 +0100, Jim Schaad wrote:
> > 1.  Is it intentional that there is no section on content encryption
> > algorithms for MUSTs?
>
>Yes.  From the beginning, the model for this draft was RFC 2633.  We
>dealt with this only in the "options" for CMS, and what it says has
>crept in through various comments.
>
>I would be content to say nothing about algorithms in WRAP, and leave
>the topic to CMS (Son-of-CMS).  However, I don't think the division is
>easy to make cleanly.
>
>[JLS]  With the most recent change of omitting algorithms from CMS, this
>section is now required both here and in the message draft.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7ENtJv01349 for ietf-smime-bks; Tue, 14 Aug 2001 16:55:19 -0700 (PDT)
Received: from [203.46.112.10] (mail.rsasecurity.com.au [203.46.112.10]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7ENtGN01345 for <[e-mail]>; Tue, 14 Aug 2001 16:55:17 -0700 (PDT)
Received: from [192.168.18.3] by [203.46.112.10] via smtpd (for [208.184.76.43]) with SMTP; 30 Mar 2001 20:54:42 UT
Received: from exaus01.local.aus.rsa.com (exaus01.local.aus.rsa.com [10.177.1.15]) by grover.local.aus.rsa.com (8.10.2/8.10.2) with ESMTP id f7ENx9q16746 for <[e-mail]>; Wed, 15 Aug 2001 09:59:09 +1000 (EST)
Received: by exaus01.local.aus.rsa.com with Internet Mail Service (5.5.2653.19) id <QX7R45LJ>; Wed, 15 Aug 2001 09:51:25 +1000
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.83]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCNQZM; Tue, 14 Aug 2001 19:54:43 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 14 Aug 2001 15:47:32 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: RE: Comments on draft-ietf-smime-x400wrap-03
In-Reply-To: <002401c11fec$9c192100$[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Correct.  At the face-to-face meeting in London last week, there was strong 
consensus that the CMS not specify any mandatory to implement 
algorithms.  I just sent of the revised I-Ds to implement this 
decision.  As a result, all protocols that employ the CMS MUST specify 
their mandatory to implement algorithms.  However, in this case, x400wrap 
may want to reference the son-of-rfc 2632 and son-of-rfc 2633 documents to 
ensure comparability.

Russ

At 10:29 AM 8/8/2001 +0100, Jim Schaad wrote:
> > 1.  Is it intentional that there is no section on content encryption
> > algorithms for MUSTs?
>
>Yes.  From the beginning, the model for this draft was RFC 2633.  We
>dealt with this only in the "options" for CMS, and what it says has
>crept in through various comments.
>
>I would be content to say nothing about algorithms in WRAP, and leave
>the topic to CMS (Son-of-CMS).  However, I don't think the division is
>easy to make cleanly.
>
>[JLS]  With the most recent change of omitting algorithms from CMS, this
>section is now required both here and in the message draft.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7ENsnN01334 for ietf-smime-bks; Tue, 14 Aug 2001 16:54:49 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7ENslN01329 for <[e-mail]>; Tue, 14 Aug 2001 16:54:47 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 14 Aug 2001 23:52:41 UT
Received: from exrsa01.rsa.com (exrsa01.rsa.com [10.81.217.7]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id TAA08573 for <[e-mail]>; Tue, 14 Aug 2001 19:54:22 -0400 (EDT)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <QPHTZS49>; Tue, 14 Aug 2001 16:53:22 -0700
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.83]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCNQZN; Tue, 14 Aug 2001 19:54:44 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 14 Aug 2001 16:18:26 -0400
Subject: Re: Mandatory to Implement Algorithms in CMS
In-Reply-To: <[e-mail]. com>
References: <003801c0eece$aaec7230$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear S/MIME WG:

At the face-to-face meeting in London last week, there was strong consensus 
that the CMS not specify any mandatory to implement algorithms.  I just 
sent the rfc2630bis and cmsalg I-Ds that implement this decision.

This means that all protocols that employ the CMS MUST specify their own 
mandatory to implement algorithms.

Russ


>Dear S/MIME WG:
>
>A few weeks ago, Jim Schaad submitted a simple comment on
>draft-ietf-smime-rfc2630bis-00.  Jim wrote:
>
>>2.  I have a sever problem with the following text "However, implementations
>>of the CMS MUST support the mandatory to implement algorithms specified in
>>[CMSALG], or its successor."  It is my believe that this statement should be
>>removed for the following reasons:
>>
>>a)  This violates the letter and spirit of the IETF process rules for
>>pushing documents to standards.  In my opinion if this becomes a standard
>>then CMSALG must also be a standard.  Also if CMSALG is reset to draft, so
>>must this draft.  The words "MUST support" is extremely normative.
>>
>>b)  If I create a toolkit or other system and publish that I am STD [CMS]
>>conformant.  It does not make sense that by updating the set of required
>>algorithms I loose conformance to that standard.  I was compliant, I loose
>>compliance through no action of mine.  This argues that a new standard
>>number should be applied.
>>
>>c)  The reasoning behind not having a MUST for certificates is even more
>>strongly appliciable here.  While certificates and heirarchies can move
>>between different applications (thus making the arugment that application
>>spaces should mandate algorithms a somewhat odd argument), that is not the
>>case with CMS objects.  If S/MIME and CMS/SET were to specificy that
>>different content encryption algorithms be required, there is no
>>interactions between the spaces.  An S/MIME message would never be consumed
>>(successfully) by a CMS/SET application nor would one expect it to be used.
>>
>> From this standpoint I think that not requiring a MUST on algorithms from
>>CMS makes sense.
>
>I have discussed this issue with both of the Security Area Directors.  Only
>one thing is clear: we cannot have a MUST statement that references
>"[CMSALG], or its successor."
>
>If we were to achieve Full Standard status with the specification that we
>are working on, then changing the mandatory to implement algorithm would
>reset the status of the updated protocol to Proposed Standard.  I expect
>such a change at some point, probably to change the mandatory cipher from
>Triple-DES CBC to AES CBC.
>
>There are other protocols besides S/MIME that are using CMS.  If CMS has
>mandatory to implement algorithms, then many of the interoperability issues
>are handled by a simple reference.  On the other hand, if CMS does not
>include any mandatory to implement algorithms, then each reference must
>specify them.
>
>As many of you know, I am arguing for a common set of cryptographic
>algorithms throughout the IETF Security Area.  Having each CMS referee
>specify their own set of algorithms does not support this objective.
>
>What do others think?
>
>Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7ENslB01328 for ietf-smime-bks; Tue, 14 Aug 2001 16:54:47 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7ENsfN01314 for <[e-mail]>; Tue, 14 Aug 2001 16:54:41 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 14 Aug 2001 23:52:35 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id TAA08555 for <[e-mail]>; Tue, 14 Aug 2001 19:54:16 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <QTWCNQZJ>; Tue, 14 Aug 2001 19:54:43 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.83]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCNQZB; Tue, 14 Aug 2001 19:54:38 -0400
From: "Housley, Russ" <[e-mail]>
To: Peter Sylvester <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 14 Aug 2001 13:52:56 -0400
Subject: Re: rfc2534 and multiple signing certificate attributes
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

You are referring to ESS, RFC 2634, right?

In some cases, signatures are serial.  In this case, a countersignature 
that contains the current Signing Certificate Attribute is sufficient.

In other cases, signatures are parallel.  I think that your comments apply 
to this situation.  Here, multiple signer info structures are present, each 
with it's own Signing Certificate Attribute.  You are looking for a way to 
bind two or more signer info structures together.  Am I understanding your 
concern correctly?

Russ

At 05:49 PM 8/10/2001 +0200, Peter Sylvester wrote:


>rfc2534 defines the usage of a Signing Certificate Attribut where
>actually only exactly one public key certificate + a list
>of attribute certs can be indicated.
>
>It happens sometimes that some signature policies require that
>several signatures MUST be present before a document becomes
>valid. Contrary to the real world it is rather simple to remove
>one of multiple signatures on a CMS document, and this may
>put the remaining signers into an undesirable situation.
>
>It seems useful to extend have a mecanism for the signer indicating
>that his signature is only valid if it is also signed by one
>or more other signers.
>
>Would it be useful to allow for multiple occurences of the attribute
>to indicate that the overall signature is valid if there are multiple
>signatures for all of the indicated attributes.
>In addition, multiple attribute values could be used to indicate that
>at least one of the indicated certs should match.
>
>Unfortunately there is no "global" attribute set. Thus, the attributes will
>occur in all signerinfos.
>
>I would like to propose this as a modification to whatever will be
>son of rfc2524.
>
>Any comments are welcome.
>
>Peter Sylvester


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7ENsbi01311 for ietf-smime-bks; Tue, 14 Aug 2001 16:54:37 -0700 (PDT)
Received: from tholian.securitydynamics.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.3/8.11.3) with SMTP id f7ENsZN01307 for <[e-mail]>; Tue, 14 Aug 2001 16:54:35 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 14 Aug 2001 23:52:29 UT
Received: from exna00.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id TAA08544 for <[e-mail]>; Tue, 14 Aug 2001 19:54:10 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <QTWCNQY0>; Tue, 14 Aug 2001 19:54:37 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.83]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QTWCNQY6; Tue, 14 Aug 2001 19:54:35 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 14 Aug 2001 10:49:34 -0400
Subject: Re: S/MIME X.400 Transport
In-Reply-To: <[e-mail]. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nandi proposed an alternative layout as follows:
>             __________________________________
>         |   P1 Envelope                         |
>         |   containing S/MIME oid               |
>         |                                       |
>         |-----------------------------------------------------------    |
>         |    General Content Type               |
>         |                                       |
>         |    with CMS object being the binary   |
>         |    data.                              |
>         |                                       |
>         |__________________________________|

I am confused by this diagram.  My understanding of the content type in the 
P1 envelope tells what ASN.1 syntax is to be used to decode the 
content.  Therefore, the CMS content needs to have its own content-type 
OID.  How can the S/MIME OID in the P1 envelope of the diagram compatible 
with the general content type in the content.

Russ


Received: by above.proper.com (8.11.3/8.11.3) id f7EB2qx04313 for ietf-smime-bks; Tue, 14 Aug 2001 04:02:52 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7EB2pN04309 for <[e-mail]>; Tue, 14 Aug 2001 04:02:51 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26192; Tue, 14 Aug 2001 07:01:40 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-rfc2630bis-02.txt
Date: Tue, 14 Aug 2001 07:01:40 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Cryptographic Message Syntax
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-rfc2630bis-02.txt
	Pages		: 52
	Date		: 13-Aug-01
	
This document describes the Cryptographic Message Syntax (CMS).  This
syntax is used to digitally sign, digest, authenticate, or encrypt
arbitrary messages.

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

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-rfc2630bis-02.txt".

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-rfc2630bis-02.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7E9Yev29450 for ietf-smime-bks; Tue, 14 Aug 2001 02:34:40 -0700 (PDT)
Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7E9YcN29441 for <[e-mail]>; Tue, 14 Aug 2001 02:34:39 -0700 (PDT)
Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id 0BEEF4DD3; Tue, 14 Aug 2001 05:34:34 -0400 (EDT)
Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id C68E662F5 for <[e-mail]>; Tue, 14 Aug 2001 05:34:33 -0400 (EDT)
Received: by mailrelay01.cce.cpqcorp.net (Postfix, from userid 12345) id 46EAF633; Tue, 14 Aug 2001 04:34:33 -0500 (CDT)
Received: from diexch01.xko.dec.com (diexch01.xko.dec.com [16.138.244.57]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id C06727F6 for <[e-mail]>; Tue, 14 Aug 2001 04:34:30 -0500 (CDT)
Received: by diexch01.xko.dec.com with Internet Mail Service (5.5.2650.21) id <Q71TY7KQ>; Tue, 14 Aug 2001 14:59:26 +0530
Message-ID: <[e-mail]>
From: "Prasad, Nandi" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: S/MIME X.400 Transport
Date: Tue, 14 Aug 2001 14:59:25 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f7E9YdN29445
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello everybody

		I need some clarifications regarding the transport of S/MIME
in X.400 as
per the draft  "draft-ietf-smime-x400transport-03.txt". The draft says that
one should have 
a separate content to represent the CMS object. The "content-type" field of
P1 envelope 
should contain the CMS defined value:

id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) 
                                                       pkcs7(7) 1 }

if the CMS object is covered by outer MIME wrapper and should contain value:

id-ct-contentInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2)  us(840)
rsadsi(113549) 
                                                          pkcs(1) pkcs-9(9)
smime(16) content-types(1) 6 }

if the CMS object is not covered by an outer MIME wrapper.

	The draft also says that, In case the S/MIME message is forwarded,
the CMS object
should be a bodypart of the "Forwarded IPM".


	X.400 recommendations define different content types with
Interpersonal Message (IPM)
and EDI to quote as some examples. Our X400 MTA/Gateway implementation uses
APIs  as
specified by Xopen Group http://www.opengroup.org/  i.e. XAPIs to build an
IPM.

	The XAPI document also defines and describes a content type called
the "General Content" 
type with binary data being its content. Since CMS object is a binary, can
we use this content type
to convey CMS objects? and can I assume that the receiving User Agent (UA)
will be 
responsible to interpret the message as secure one?


The layout of the message will be as follows:

            __________________________________
	|   P1 Envelope				|
	|   containing S/MIME oid		|
	|					|
	|-----------------------------------------------------------	|
	|    General Content Type		|
	|   					|
	|    with CMS object being the binary	|
	|    data.				|
	|					|
	|__________________________________|

Following is the dump of the message as seen in X.400:
----------------------------------------------------------------------------
---------------------------------
	XAPI dump of a General content message with CMS object
			being the content
----------------------------------------------------------------------------
---------------------------------

OM_CLASS [OM_S_OBJECT_IDENTIFIER_STRING]: MH_C_DELIV_MESSAGE
MH_T_CONTENT [OM_S_OBJECT]: (Object)
      OM_CLASS [OM_S_OBJECT_IDENTIFIER_STRING]: MH_C_GENERAL_CONTENT
<< The above OID indicates that it is a general content>>

      MH_T_BINARY_CONTENT [OM_S_OCTET_STRING]: Long string.
<< Binary CMS object follows here >>
30 80  6  9 2a 86 48 86 f7  d  1  7  2 a0 80 30 80  2  1  1 0...*.H.÷....
.0....
31  b 30  9  6  5 2b  e  3  2 1a  5  0 30 80  6  9 2a 86 48
1.0...+......0...*.H
86 f7  d  1  7  1 a0 80 24 80  4  c 43 6f 6e 74 65 6e 74 2d .÷....
.$...Content-
<< More data follows here ...but removed >>.
33 b2 bd ed 85 19 af 77 9d 5c 62 9d 1b b1 ab 19 bb 36 26 5c
3²½í..¯w.\b..±«.»6&\
6f  d 37 a6 99 90 82 6c  0  0  0  0  0  0  0  0  0  0  0  0
o.7¦...l............
Total Length 3394
<< Envelope starts from here >>
MH_T_ENVELOPES [OM_S_OBJECT]: (Object)
      OM_CLASS [OM_S_OBJECT_IDENTIFIER_STRING]: MH_C_DELIVERY_ENVELOPE
      MH_T_ACTUAL_RECIPIENT_NAME [OM_S_OBJECT]: (Object)
            OM_CLASS [OM_S_OBJECT_IDENTIFIER_STRING]: MH_C_OR_NAME
            MH_T_ADMD_NAME [OM_S_PRINTABLE_STRING]: vsnl
            MH_T_COMMON_NAME [OM_S_PRINTABLE_STRING]: test
            MH_T_COUNTRY_NAME [OM_S_PRINTABLE_STRING]: in
            MH_T_ORGANIZATION_NAME [OM_S_PRINTABLE_STRING]: idc
            MH_T_PRMD_NAME [OM_S_PRINTABLE_STRING]: digital
      MH_T_BUREAU_FAX_DELIVERY [OM_S_BOOLEAN]: OM_FALSE
      MH_T_CONTENT_TYPE [OM_S_OBJECT_IDENTIFIER_STRING]: 
ObjID: 2a 86 48 86 f7 0d 01 09 10 0106
<< The above OID is the OID for S/MIME (unwrapped) >>

      MH_T_CONVERSION_LOSS_PROHIBITED [OM_S_BOOLEAN]: OM_FALSE
      MH_T_CONVERSION_PROHIBITED [OM_S_BOOLEAN]: OM_FALSE
      MH_T_DELIVERY_TIME [OM_S_UTC_TIME_STRING]: 010809152452Z
      MH_T_FORWARDING_ADDR_REQUESTED [OM_S_BOOLEAN]: OM_FALSE
      MH_T_FORWARDING_PROHIBITED [OM_S_BOOLEAN]: OM_FALSE
      MH_T_MTS_IDENTIFIER [OM_S_OBJECT]: (Object)
            OM_CLASS [OM_S_OBJECT_IDENTIFIER_STRING]: MH_C_MTS_IDENTIFIER
            MH_T_ADMD_NAME [OM_S_PRINTABLE_STRING]: vsnl
            MH_T_COUNTRY_NAME [OM_S_PRINTABLE_STRING]: in
            MH_T_LOCAL_IDENTIFIER [OM_S_IA5_STRING]:
9B265BAE11D58CDA00001590
            MH_T_PRMD_IDENTIFIER [OM_S_PRINTABLE_STRING]: digital
      MH_T_ORIGINATOR_NAME [OM_S_OBJECT]: (Object)
            OM_CLASS [OM_S_OBJECT_IDENTIFIER_STRING]: MH_C_OR_NAME
            MH_T_ADMD_NAME [OM_S_PRINTABLE_STRING]: vsnl
            MH_T_COMMON_NAME [OM_S_PRINTABLE_STRING]: nandi
            MH_T_COUNTRY_NAME [OM_S_PRINTABLE_STRING]: in
            MH_T_ORGANIZATION_NAME [OM_S_PRINTABLE_STRING]: idc
            MH_T_PRMD_NAME [OM_S_PRINTABLE_STRING]: digital
      MH_T_POSTAL_REPORT [OM_S_ENUMERATION]: MH_PR_UNDELIVBLE_MAIL_VIA_PDS
      MH_T_PREFERRED_DELIVERY_MODES [OM_S_ENUMERATION]: MH_DM_ANY
      MH_T_PRIORITY [OM_S_ENUMERATION]: MH_PTY_NORMAL
      MH_T_PROOF_OF_DELIV_REQUESTED [OM_S_BOOLEAN]: OM_FALSE
      MH_T_REGISTRATION [OM_S_ENUMERATION]: 0
      MH_T_RENDITION_ATTRIBUTES [OM_S_OBJECT_IDENTIFIER_STRING]:
MH_RA_BASIC_RENDITION
      MH_T_SUBMISSION_TIME [OM_S_UTC_TIME_STRING]: 010809152421Z
----------------------------------------------------------------------------
---------------------------------

	Could anybody comment on the usage of General content in the
transfer
of CMS object from MIME to X.400.

Regards
Nandi





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f7DLYLm08403 for ietf-smime-bks; Mon, 13 Aug 2001 14:34:21 -0700 (PDT)
Received: from post.ffi.no (post.ffi.no [193.156.99.133]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7DLYJN08399 for <[e-mail]>; Mon, 13 Aug 2001 14:34:20 -0700 (PDT)
Received: by post.ffi.no with Internet Mail Service (5.5.2653.19) id <QAX2WWDW>; Mon, 13 Aug 2001 23:34:18 +0200
Message-ID: <[e-mail]>
From: "Eggen, Anders" <[e-mail]>
To: "'Graeme Lunt '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Cc: "''[e-mail]' '" <[e-mail]>, "'Tim Freestone '" <[e-mail]>
Subject: RE: Comments on draft-ietf-smime-x400wrap-03.txt/draft-ietf-smime -x40 0transport-03.txt
Date: Mon, 13 Aug 2001 23:34:17 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1243F.B48ACF20"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

------_=_NextPart_001_01C1243F.B48ACF20
Content-Type: text/plain;
	charset="ISO-8859-1"

Graeme,

I have given an explanation below for why we removed some of the
ContentInfo wrappers in the steps for tripple wrapping of an X.400 content. 

>-----Original Message-----
>From: Graeme Lunt
>To: [e-mail]
>Cc: '[e-mail]'; Tim Freestone
>Sent: 08.08.01 10:03
>Subject: Comments on draft-ietf-smime-x400wrap-03.txt/draft-ietf-smime->x40
0transport-03.txt
>
>
>Paul,
>
>A couple of comments on the two drafts:
>
>x400wrap-03:
>
>I note that section 3.4.1 "Creating a Triple Wrapped Message With 
>An X.400" has been changed so that a ContentInfo
>wrapping is no longer applied to the inner signed-data and 
>enveloped-data (end of step 3, end of step 4).
>
>I can see that it saves me some bytes/redundancy in the encoding, 
>but maybe you could give me some background to this change?
>
>I have a preference for keeping the contentInfo wrapping as:
>
>a) it to some extent aligns with S/MIME ESS, where at each similar
>stage a MIME construct is added (with a smime-type), and a generic
>object (id-data) is passed to the next level of wrapping. In the
>previous version the ContentInfo was the "generic" form that was
>subject to the next protection operation.
>
>
>
>b) it is simple to produce a "signed-only" version of a triple wrapped
>message e.g. for forwarding, as removing outer two wrappers should give 
>me the appropriate form I require for a forwarded content bodypart.
> 
>c) it just appears to me to be a more generic, simpler solution.
>ContentInfo encodings are what I am mostly likely to deal with e.g. in
>files
>
>(although having a slightly larger encoding).
>
>
>
>Comments?
>
>Graeme
>

In the ESS tripple wrapping decription, all of the nested "contents" are
MIME wrapped and the ContentInfo wrappings are needed to identify the
content (or content type) under the MIME wrappings. The MIME wrappings are
neccesary in SMTP systems for backwards compatibility with S/MIME version 2.
In section 1.4 we explain why we don't need bacwards compatibility with
S/MIME v.2. and for that reason we did not see the need to have the MIME
wrappings (for a tripple wrapped message they add over 300% overhead). 

Since we don't have the MIME wrappings, we don't need the ContentInfo
wrappings either. The ContentType OIDs in SignedData and EnvelopedData will
identify the encapsulatet content (or content type).  ContentInfo needs only
to be used around the outer most SignedData because this is required by PKCS
#7 and CMS.   

The ContentInfo wrappings will only introduce an unnecessary level of
indirection, and you will have to modify your ESS code for SMTP anyway
because the MIME wrappers are gone.  Thus, a triple wrapped message will
have the following form: 

         X.400 Envelope  ->  id-ct-contentInfo 
         ContentInfo     ->  id-signedData 
         SignedData      ->  id-envelopedData 
         EnvelopedData   ->  id-signedData 
         SignedData      ->  <OID for content type> 

If you want to produce a "signed-only" version of a triple wrapped
message, all you need to do is to wrap the inner most SignedData in a
ContentInfo and forward it which should be a pretty easy operation.

Best Regards

Anders

------_=_NextPart_001_01C1243F.B48ACF20
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Comments on =
draft-ietf-smime-x400wrap-03.txt/draft-ietf-smime-x40 =
0transport-03.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Graeme,</FONT>
</P>

<P><FONT SIZE=3D2>I have given an explanation below for why we removed =
some of the&nbsp; ContentInfo wrappers in the steps for tripple =
wrapping of an X.400 content. </FONT></P>

<P><FONT SIZE=3D2>&gt;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;From: Graeme Lunt</FONT>
<BR><FONT SIZE=3D2>&gt;To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt;Cc: '[e-mail]'; Tim =
Freestone</FONT>
<BR><FONT SIZE=3D2>&gt;Sent: 08.08.01 10:03</FONT>
<BR><FONT SIZE=3D2>&gt;Subject: Comments on =
draft-ietf-smime-x400wrap-03.txt/draft-ietf-smime-&gt;x40 =
0transport-03.txt</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Paul,</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;A couple of comments on the two drafts:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;x400wrap-03:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;I note that section 3.4.1 &quot;Creating a =
Triple Wrapped Message With </FONT>
<BR><FONT SIZE=3D2>&gt;An X.400&quot; has been changed so that a =
ContentInfo</FONT>
<BR><FONT SIZE=3D2>&gt;wrapping is no longer applied to the inner =
signed-data and </FONT>
<BR><FONT SIZE=3D2>&gt;enveloped-data (end of step 3, end of step =
4).</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;I can see that it saves me some bytes/redundancy =
in the encoding, </FONT>
<BR><FONT SIZE=3D2>&gt;but maybe you could give me some background to =
this change?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;I have a preference for keeping the contentInfo =
wrapping as:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;a) it to some extent aligns with S/MIME ESS, =
where at each similar</FONT>
<BR><FONT SIZE=3D2>&gt;stage a MIME construct is added (with a =
smime-type), and a generic</FONT>
<BR><FONT SIZE=3D2>&gt;object (id-data) is passed to the next level of =
wrapping. In the</FONT>
<BR><FONT SIZE=3D2>&gt;previous version the ContentInfo was the =
&quot;generic&quot; form that was</FONT>
<BR><FONT SIZE=3D2>&gt;subject to the next protection operation.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;b) it is simple to produce a =
&quot;signed-only&quot; version of a triple wrapped</FONT>
<BR><FONT SIZE=3D2>&gt;message e.g. for forwarding, as removing outer =
two wrappers should give </FONT>
<BR><FONT SIZE=3D2>&gt;me the appropriate form I require for a =
forwarded content bodypart.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;c) it just appears to me to be a more generic, =
simpler solution.</FONT>
<BR><FONT SIZE=3D2>&gt;ContentInfo encodings are what I am mostly =
likely to deal with e.g. in</FONT>
<BR><FONT SIZE=3D2>&gt;files</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;(although having a slightly larger =
encoding).</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Comments?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Graeme</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

<P><FONT SIZE=3D2>In the ESS tripple wrapping decription, all of the =
nested &quot;contents&quot; are MIME wrapped and the ContentInfo =
wrappings are needed to identify the</FONT></P>

<P><FONT SIZE=3D2>content (or content type) under the MIME wrappings. =
The MIME wrappings are neccesary in SMTP systems for backwards =
compatibility with S/MIME version 2. In section 1.4 we explain why we =
don't need bacwards compatibility with S/MIME v.2. and for that reason =
we did not see the need to have the MIME wrappings (for a tripple =
wrapped message they add over 300% overhead). </FONT></P>

<P><FONT SIZE=3D2>Since we don't have the MIME wrappings, we don't need =
the ContentInfo wrappings either. The ContentType OIDs in SignedData =
and EnvelopedData will identify the encapsulatet content (or content =
type).&nbsp; ContentInfo needs only to be used around the outer most =
SignedData because this is required by PKCS #7 and CMS.&nbsp;&nbsp; =
</FONT></P>

<P><FONT SIZE=3D2>The ContentInfo wrappings will only introduce an =
unnecessary level of indirection, and you will have to modify your ESS =
code for SMTP anyway because the MIME wrappers are gone.&nbsp; Thus, a =
triple wrapped message will have the following form: </FONT></P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
X.400 Envelope&nbsp; -&gt;&nbsp; id-ct-contentInfo </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
ContentInfo&nbsp;&nbsp;&nbsp;&nbsp; -&gt;&nbsp; id-signedData </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SignedData&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&gt;&nbsp; id-envelopedData =
</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
EnvelopedData&nbsp;&nbsp; -&gt;&nbsp; id-signedData </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SignedData&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&gt;&nbsp; &lt;OID for =
content type&gt; </FONT>
</P>

<P><FONT SIZE=3D2>If you want to produce a &quot;signed-only&quot; =
version of a triple wrapped</FONT>
<BR><FONT SIZE=3D2>message, all you need to do is to wrap the inner =
most SignedData in a ContentInfo and forward it which should be a =
pretty easy operation.</FONT></P>

<P><FONT SIZE=3D2>Best Regards</FONT>
</P>

<P><FONT SIZE=3D2>Anders</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1243F.B48ACF20--


Received: by above.proper.com (8.11.3/8.11.3) id f7AFnj711617 for ietf-smime-bks; Fri, 10 Aug 2001 08:49:45 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f7AFngN11601 for <[e-mail]>; Fri, 10 Aug 2001 08:49:43 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA17947 for <[e-mail]>; Fri, 10 Aug 2001 17:49:43 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 10 Aug 2001 17:49:43 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA10731 for <[e-mail]>; Fri, 10 Aug 2001 17:49:41 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA03961 for [e-mail]; Fri, 10 Aug 2001 17:49:41 +0200 (MET DST)
Date: Fri, 10 Aug 2001 17:49:41 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: rfc2534 and multiple signing certificate attributes
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

rfc2534 defines the usage of a Signing Certificate Attribut where
actually only exactly one public key certificate + a list
of attribute certs can be indicated. 

It happens sometimes that some signature policies require that
several signatures MUST be present before a document becomes
valid. Contrary to the real world it is rather simple to remove
one of multiple signatures on a CMS document, and this may
put the remaining signers into an undesirable situation. 

It seems useful to extend have a mecanism for the signer indicating
that his signature is only valid if it is also signed by one
or more other signers. 

Would it be useful to allow for multiple occurences of the attribute
to indicate that the overall signature is valid if there are multiple
signatures for all of the indicated attributes. 
In addition, multiple attribute values could be used to indicate that
at least one of the indicated certs should match. 

Unfortunately there is no "global" attribute set. Thus, the attributes will
occur in all signerinfos. 

I would like to propose this as a modification to whatever will be 
son of rfc2524. 

Any comments are welcome.

Peter Sylvester  


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f79J2fx00105 for ietf-smime-bks; Thu, 9 Aug 2001 12:02:41 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79IsuN29812; Thu, 9 Aug 2001 11:54:56 -0700 (PDT)
Received: (from nobody@localhost) by email.nist.gov (8.9.3/8.9.3) id OAA18429; Thu, 9 Aug 2001 14:55:09 -0400 (EDT)
From: C Michael Chernick <[e-mail]>
To: [e-mail], [e-mail]
Subject: Draft NIST S/MIME Profile available (Comment Period Extended)
Message-ID: <[e-mail]>
Date: Thu, 09 Aug 2001 14:55:09 -0400 (EDT)
Cc: [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.5
X-Originating-IP: 217.33.146.249
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

FYI,

At yesterday's SMIME session at the London IETF, it was suggested that
NIST extend the deadline for comments on the Draft NIST S/MIME V3 Client
Profile.  Also, it was suggested that this notice be sent to the PKIX list
as well as the SMIME list. Thus, I am resending the announcement sent out
by Tim Polk on Monday, 2 July 2001 to the SMIME list.  The deadline for 
comments has been extended until 17 September 2001.

Thanks,
   Mike Chernick


---------Original Message Sent by Tim Polk to SMIME List on 2 July---------
FYI,

I have attached below the announcement for a recently released NIST draft 
document concerning S/MIME V3.  The document is intended to define an 
appropriate subset of the S/MIME standards for broad application in the U.S. 
Federal Government.  NIST will be supporting this document through the 
development of an automated conformance testing tool.  We hope the deployment 
of this tool will ease the development of conformant S/MIME V3 clients!

We are very interested in comments from both developers and the user 
community.  Please take the time to review the draft profile and NIST's plans 
for the automated testing facility.  We would appreciate comments on the 
profile by 17 August 2001 (now extended to 17 September).  Please send  
comments to Mike Chernick (NIST's S/MIME project leader) at <[e-mail]>.

BTW, Mike will be presenting an overview of this project in the S/MIME WG 
during the London IETF meeting.  Both Mike and I will be there all week, and 
will be available to discuss this project.

Thanks!

Tim Polk


----------------------

The U.S. National Institute of Standards and Technology (NIST) has recently 
released a draft S/MIME V3 Client Profile. This profile was produced as 
guidance in the development and procurement of commercial-off-the-shelf (COTS) 
S/MIME-compliant products. This profile document identifies requirements for a 
secure and interoperable S/MIME V3 client implementation. The profile cites 
requirements for sending and receiving both signed and encrypted messages, as 
well as requirements for signed receipt processing.

Although the S/MIME specifications were designed to promote interoperable 
secure electronic mail, implementations may support different optional services
and the specifications may unintentionally allow multiple interpretations. As a
result, different implementations of S/MIME may not be fully interoperable or 
provide the desired level of security. Conformance to this proposed profile 
will help to assure that S/MIME implementations will be able to interoperate 
and provide reasonable security assurance to users.

The Draft Profile is available (in PDF format) for public comment at: 
http://csrc.ncsl.nist.gov/pki/smime/draft_SMIMEProfile.pdf

Comments are requested by (**was 17 August 2001**) *****NOW EXTENDED TO 
17 September 2001***** and should be sent to [e-mail].

NIST is developing tests and testing tools to determine the level of 
conformance of an S/MIME V3 client implementation with this profile. It is 
planned that within the next several months, NIST will have a remote testing 
facility on-line which will allow S/MIME V3 messages to be sent to the NIST 
test site for processing to determine if the remotely generated messages 
conform to the profile. In addition, messages may be sent to the test site to 
cause the NIST site to emit S/MIME V3 messages so that a remote system may 
receive S/MIME V3 messages, and verify that remote system can process the 
messages correctly.

Further information on the NIST S/MIME Program may be obtained at
http://csrc.ncsl.nist.gov/pki/smime/welcome.htm or by
contacting Michael Chernick  at <[e-mail]>.

--------------------------------------------------------------------------------
C. Michael Chernick
[phone]   [e-mail]
Computer Security Division 
National Institute of Standards and Technology (NIST)
--------------------------------------------------------------------------------

 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f79Amdb05339 for ietf-smime-bks; Thu, 9 Aug 2001 03:48:39 -0700 (PDT)
Received: from btclick.com (mta01.btfusion.com [62.172.195.11]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f79AmQN05331; Thu, 9 Aug 2001 03:48:37 -0700 (PDT)
Received: from JOHNVARSYSTEM ([213.123.188.215]) by btclick.com (Netscape Messaging Server 4.05) with SMTP id GHSRBP05.F0I; Thu, 9 Aug 2001 11:47:49 +0100 
From: "John Ross" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, "XMLSigWG" <[e-mail]>
Subject: Comments requested on ETSI Draft TR "XML format for signature policies"
Date: Thu, 9 Aug 2001 11:49:28 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Request for comments on draft ETSI TR on XML based Signature Policies:

This draft ETSI technical report defines Signature Policies using XML which
are based on the ASN.1 Signature Policies defined in ETSI TS 101 733 and RFC
3125.

This draft TR is offered as a starting point for discussion on XML based
Signature Policies. All comments received will help to determine the future
direction this work item will take in ETSI. This draft technical report is
being made publicly available for review and comment by any company,
individual or organisation with interest in this area.  A copy can be
obtained through the ETSI El Sign web site (see below).

Comments are requested by 14th September.


Background

The development of this technical report

"XML format for signature policies"

is one of the tasks the ETSI Electronic Signature and Infrastructure Working
Group is progressing within the European Electronic Signature
Standardisation
Initiative (EESSI). The ETSI El Sign Web-site (see below) provides further
information about the ETSI activities and the EESSI program.

REQUESTED ACTION

Please send your comments and suggestions not later than 14 September to the
ETSI El Sign e-mail list [e-mail], with copy to the editor on
[e-mail] .   Please put "ETSI-XML-SigPol" at the front of the
Subject
field of all submissions to the e-mail list on this topic.

To register with the EL-SIGN list and download the draft document
(STF178Task3DraftTR.pdf) see:

http://www.etsi.org/sec/el-sign.htm


The purpose of the open e-mail list is to stimulate discussion of the
published comments and contributions. Therefore, early submissions are
welcome. We expect that discussions will go on through the open e-mail list
under and after the comments period.


With regards

Juan  Carlos Cruellas (Universitat Politecnica de Catalunya)
Editor - XML format for signature policies

[e-mail]

and

György Endersz, Telia Research AB
Chair ETSI ESI Working Group
[e-mail]




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f789TWs28462 for ietf-smime-bks; Wed, 8 Aug 2001 02:29:32 -0700 (PDT)
Received: from relay3.bt.net (relay3.bt.net [194.72.6.50]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f789TUN28456; Wed, 8 Aug 2001 02:29:30 -0700 (PDT)
Received: from [217.33.136.55] (helo=revelation) by relay3.bt.net with esmtp (Exim 3.22 #1) id 15UPeV-0003WE-00; Wed, 08 Aug 2001 10:29:23 +0100
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Bonatti, Chris'" <[e-mail]>
Cc: "'Ietf-Smime'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Comments on draft-ietf-smime-x400wrap-03
Date: Wed, 8 Aug 2001 10:29:23 +0100
Message-ID: <002401c11fec$9c192100$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2505.0000
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Bonatti, Chris
Sent: Tuesday, August 07, 2001 12:33 AM
To: [e-mail]
Cc: Ietf-Smime; [e-mail]; [e-mail]
Subject: RE: Comments on draft-ietf-smime-x400wrap-03



On Monday, August 06, 2001 08:13 Jim Schaad [mailto:[e-mail]]
wrote:
>
> 1.  Is it intentional that there is no section on content encryption 
> algorithms for MUSTs?

Yes.  From the beginning, the model for this draft was RFC 2633.  We
dealt with this only in the "options" for CMS, and what it says has
crept in through various comments.

I would be content to say nothing about algorithms in WRAP, and leave
the topic to CMS (Son-of-CMS).  However, I don't think the division is
easy to make cleanly.

[JLS]  With the most recent change of omitting algorithms from CMS, this
section is now required both here and in the message draft.


>
> 2.  I don't understand the reasoning behind the following statement 
> from section 3.2.  Why should this be an important statement?  I don't

> like the fact that the encoding is suppose to be based on where one 
> thinks the message MIGHT be sent.  I don't see any problem with SHOULD
binary
> MAY mime wrap.   Additionally if a MIME wrapper is added to the
outside
> of the SignedData object, then it does not matter if the inner is 
> encoded as binary as the mime wrapper can base64 the entire object. [ 
> This is also inconsistant with behavior for encrypted data where it is

> always the x.400 content that is embedded. ]
>
> "Note that if SMTP [SMTP] used to transport the resulting signed-only 
> message then the optional MIME encoding SHOULD be used. If binary 
> transports such as X.400 are used then the optional MIME encoding 
> SHOULD NOT be used."
>
> The preceeding text is also present in section 3.3, however it appears

> to be in conflict with the third paragraph where it states that MIME 
> SHOULD NOT be used.

The notion here is multifold: (a) we don't think that an outer MIME
wrapper should be used in the X.400 scenario; (b) we recognize that
there are places where X.400 systems will meeting SMTP/MIME systems
where the outer MIME wrapper might be necessary; (c) we assumed that
since this was outside the security wrappers whatever servers or gateway
logic bridged the gap between the two systems would be smart enough to
apply or remove the outer MIME wrapper as appropriate.  The text you are
seeing is an attempt to cast these thoughts into the language of RFC
2633.  Perhaps there is a better way to present this issue.

Perhaps a better way is to state that the MIME wrapper MAY be applied,
and simply state the conditions (as above).  Thoughts?

[JLS] OK your description here makes much more sense.  I was looking at
this and reading it as a question of whether or not there was mime
wrapping at each layer of wrapping not at the top level.  I don't
however believe that the outer wrapping is at all interesting as the
adding and stripping of this on the gateway is trivial.


>
> 3.  Section 3.2.1:  The following
> 	Content-Type: application/pkcs7-mime; smime-type=signed-data
Should 
> be
> 	Content-Type: application/pkcs7-mime; smime-type=signed-x400

Agree.  Anders noted this earlier.


>
> 4.  Section 3.4.1:  Step 4 uses the phrase "in a single block".  This 
> bothers me as it implies that the entire body needs to be supplied at 
> once.  We octet wrap the content so this is not necessary.  Please 
> remove or clarify what is meant by "in a single block".

I don't see how it implies anything inappropriate.  The step 4
encryption has to process the entire step 3 output to proceed.  I read
"in a single block" to mean that the result of step 3 including the
content.  Since the detached signature form does not apply to
triple-wrapped messages, this seems to me to be the only way to do this.
How do you think this could be 
clarified?

[JLS] Just remove the "as a single block".  "Encrypt the result of step
3." is sufficent.

>
> 5.

If there was a comment 5, I didn't receive it.

no comment.

>

Best regards,
Chris




Received: by above.proper.com (8.11.3/8.11.3) id f78858q19258 for ietf-smime-bks; Wed, 8 Aug 2001 01:05:08 -0700 (PDT)
Received: from swordfish.nexor.co.uk (swordfish.nexor.co.uk [193.63.53.54]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f78855N19254 for <[e-mail]>; Wed, 8 Aug 2001 01:05:05 -0700 (PDT)
Received: by swordfish.nexor.co.uk with Internet Mail Service (5.5.2653.19) id <PBCFRY56>; Wed, 8 Aug 2001 09:03:59 +0100
Message-ID: <[e-mail]>
From: Graeme Lunt <[e-mail]>
To: [e-mail]
Cc: "'[e-mail]'" <[e-mail]>, Tim Freestone <[e-mail]>
Subject: Comments on draft-ietf-smime-x400wrap-03.txt/draft-ietf-smime-x40 0transport-03.txt
Date: Wed, 8 Aug 2001 09:03:52 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul,

A couple of comments on the two drafts:

x400wrap-03:

I note that section 3.4.1 "Creating a Triple Wrapped Message With 
An X.400" has been changed so that a ContentInfo
wrapping is no longer applied to the inner signed-data and 
enveloped-data (end of step 3, end of step 4).

I can see that it saves me some bytes/redundancy in the encoding, 
but maybe you could give me some background to this change?

I have a preference for keeping the contentInfo wrapping as:

a) it to some extent aligns with S/MIME ESS, where at each similar
stage a MIME construct is added (with a smime-type), and a generic
object (id-data) is passed to the next level of wrapping. In the
previous version the ContentInfo was the "generic" form that was
subject to the next protection operation.

b) it is simple to produce a "signed-only" version of a triple wrapped
message e.g. for forwarding, as removing outer two wrappers should give 
me the appropriate form I require for a forwarded content bodypart.
 
c) it just appears to me to be a more generic, simpler solution.
ContentInfo encodings are what I am mostly likely to deal with e.g. in files

(although having a slightly larger encoding).

x400transport-03

In section 2.5 "Encoded Information Type Indication" it states that
"Additional values of smime-type are defined in ... [X400WRAP]."
However, x400-wrap-03 seems to defer to [TRANSPORT] for the definition
of its additional types (e.g. see last para of x400wrap-03 3.2.1).
x400wrap-03 would seem to be the right place.

In terms of the EITs, it would be much more useful if the EITs for 
"wrapped X400" messages could indicate the actual X.400 content type that 
is wrapped.  Indicating to a UA that it will find X.400 rather than MIME 
is useful but if the UA then finds EDI (or even unidentified content) 
inside when expecting P22, then it hasn't really gained much.

It would be more useful if the EITs available were something like (in
smime-type notation):
signed-x400-p0
signed-x400-p2
signed-x400-p22
signed-x400-oid.<oid> (for external content types).

For X.400 EITs OIDs, you could use a OID concatenation method (as used
for ForwardedContent bodyparts) on id-eit-signedX400/id-eit-envelopedX400
for
external content types. 

The main requirement I see is for a distinction between p22 and external
content types.

This provides me with more information about the internal X.400 content that
I am likely to find, and allows user agents to choose the appropriate form
for displaying the encapsulated content type.

This provides the same information as the contentHints.contentType ESS 
extension, but is available to the MTS. The MTS could then act on this EIT 
e.g. in a military environment, CMS wrapped P772 messages could be 
identified over CMS wrapped P22 messages.

Comments?


Graeme



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f77DlpZ02887 for ietf-smime-bks; Tue, 7 Aug 2001 06:47:51 -0700 (PDT)
Received: from post.ffi.no (post.ffi.no [193.156.99.133]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f77DlkN02881; Tue, 7 Aug 2001 06:47:47 -0700 (PDT)
Received: by post.ffi.no with Internet Mail Service (5.5.2653.19) id <QAX2WB1N>; Tue, 7 Aug 2001 15:47:45 +0200
Message-ID: <[e-mail]>
From: "Eggen, Anders" <[e-mail]>
To: "'Bonatti, Chris'" <[e-mail]>, [e-mail]
Cc: Ietf-Smime <[e-mail]>, [e-mail], "Eggen, Anders" <[e-mail]>
Subject: SV: Comments on draft-ietf-smime-x400wrap-03
Date: Tue, 7 Aug 2001 15:47:41 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11F47.87579E90"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

------_=_NextPart_001_01C11F47.87579E90
Content-Type: text/plain;
	charset="ISO-8859-1"

	Jim, Chris,


	>>
	>> 1.  Is it intentional that there is no section on content
encryption
	>> algorithms for MUSTs?

	>Yes.  From the beginning, the model for this draft was RFC 2633.
We dealt
	>with this only in the "options" for CMS, and what it says has crept
in
	>through various comments.
	>
	>I would be content to say nothing about algorithms in WRAP, and
leave the
	>topic to CMS (Son-of-CMS).  However, I don't think the division is
easy to
	>make cleanly.


	>>
	>> 2.  I don't understand the reasoning behind the following
statement from
	>> section 3.2.  Why should this be an important statement?  I don't
like
	>> the fact that the encoding is suppose to be based on where one
thinks
	>> the message MIGHT be sent.  I don't see any problem with SHOULD
binary
	>> MAY mime wrap.   Additionally if a MIME wrapper is added to the
outside
	>> of the SignedData object, then it does not matter if the inner is
	>> encoded as binary as the mime wrapper can base64 the entire
object. [
	>> This is also inconsistant with behavior for encrypted data where
it is
	>> always the x.400 content that is embedded. ]
	>>
	>> "Note that if SMTP [SMTP] used to transport the resulting
signed-only
	>> message then the optional MIME encoding SHOULD be used. If binary
	>> transports such as X.400 are used then the optional MIME encoding
SHOULD
	>> NOT be used."
	>>
	>> The preceeding text is also present in section 3.3, however it
appears
	>> to be in conflict with the third paragraph where it states that
MIME
	>> SHOULD NOT be used.

	The third and fifth paragraph are not in conflict with each other.
Paragraph 3 states that the X.400 content SHOULD NOT be MIME encoded before
it is encapsulated in EnvelopedData, wheras the fifth paragraph states that
the outer ContentInfo SHOULD be MIME encoded if SMTP transport is used.   

	>The notion here is multifold: (a) we don't think that an outer MIME
wrapper
	>should be used in the X.400 scenario; (b) we recognize that there
are places
	>where X.400 systems will meeting SMTP/MIME systems where the outer
MIME
	>wrapper might be necessary; (c) we assumed that since this was
outside the
	>security wrappers whatever servers or gateway logic bridged the gap
between
	>the two systems would be smart enough to apply or remove the outer
MIME
	>wrapper as appropriate.  The text you are seeing is an attempt to
cast these
	>thoughts into the language of RFC 2633.  Perhaps there is a better
way to
	>present this issue.
	>
	>Perhaps a better way is to state that the MIME wrapper MAY be
applied, and
	>simply state the conditions (as above).  Thoughts?

	In an X.400 environment where this RFC is most likely to be used,
you don't need the extra outer MIME wrapper. In fact it only adds additional
overhead (ca. 40 %) to the wrapped object. This was the rational for stating
that the optional MIME encoding should not be used in X.400 environments.
Apart from this I don't have any problems with Chris' new proposal. 

	>>
	>> 3.  Section 3.2.1:  The following
	>> 	Content-Type: application/pkcs7-mime; smime-type=signed-data
	>> Should be
	>> 	Content-Type: application/pkcs7-mime; smime-type=signed-x400

	>Agree.  Anders noted this earlier.


	>>
	>> 4.  Section 3.4.1:  Step 4 uses the phrase "in a single block".
This
	>> bothers me as it implies that the entire body needs to be
supplied at
	>> once.  We octet wrap the content so this is not necessary.
Please
	>> remove or clarify what is meant by "in a single block".

	>I don't see how it implies anything inappropriate.  The step 4
encryption
	>has to process the entire step 3 output to proceed.  I read "in a
single
	>block" to mean that the result of step 3 including the content.
Since the
	>detached signature form does not apply to triple-wrapped messages,
this
	>seems to me to be the only way to do this.  How do you think this
could be
	>clarified?

	I don't see the problem either.

	>>
	>> 5.

	>If there was a comment 5, I didn't receive it.

	>>

	>Best regards,
	>Chris

	Best regards
	Anders


------_=_NextPart_001_01C11F47.87579E90
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>SV: Comments on draft-ietf-smime-x400wrap-03</TITLE>
</HEAD>
<BODY>
<UL>
<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Jim</FONT><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">,</FONT> <FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">Chris,</FONT>
</P>
<BR>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; 1.&nbsp; Is it =
intentional that there is no section on content encryption</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; algorithms for =
MUSTs?</FONT>
</P>

<P><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">Yes.&nbsp; From the =
beginning, the model for this draft was RFC 2633.&nbsp; We dealt</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">with this only in the =
&quot;options&quot; for CMS, and what it says has crept in</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">through various =
comments.</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">I would be content to say =
nothing about algorithms in WRAP, and leave the</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">topic to CMS =
(Son-of-CMS).&nbsp; However, I don't think the division is easy =
to</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">make cleanly.</FONT>
</P>
<BR>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; 2.&nbsp; I don't =
understand the reasoning behind the following statement from</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; section 3.2.&nbsp; Why =
should this be an important statement?&nbsp; I don't like</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; the fact that the =
encoding is suppose to be based on where one thinks</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; the message MIGHT be =
sent.&nbsp; I don't see any problem with SHOULD binary</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; MAY mime =
wrap.&nbsp;&nbsp; Additionally if a MIME wrapper is added to the =
outside</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; of the SignedData =
object, then it does not matter if the inner is</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; encoded as binary as the =
mime wrapper can base64 the entire object. [</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; This is also =
inconsistant with behavior for encrypted data where it is</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; always the x.400 content =
that is embedded. ]</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; &quot;Note that if SMTP =
[SMTP] used to transport the resulting signed-only</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; message then the =
optional MIME encoding SHOULD be used. If binary</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; transports such as X.400 =
are used then the optional MIME encoding SHOULD</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; NOT be =
used.&quot;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; The preceeding text is =
also present in section 3.3, however it appears</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; to be in conflict with =
the third paragraph where it states that MIME</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; SHOULD NOT be =
used.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">The third and fifth =
paragraph are not in conflict with each other. Paragraph 3 states that =
the X.400 content SHOULD NOT be MIME encoded before it is encapsulated =
in EnvelopedData, wheras the fifth paragraph states that the outer =
ContentInfo SHOULD be MIME encoded if SMTP transport is =
used.&nbsp;&nbsp; </FONT></P>

<P><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">The notion here is multifold: =
(a) we don't think that an outer MIME wrapper</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">should be used in the X.400 =
scenario; (b) we recognize that there are places</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">where X.400 systems will =
meeting SMTP/MIME systems where the outer MIME</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">wrapper might be necessary; =
(c) we assumed that since this was outside the</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">security wrappers whatever =
servers or gateway logic bridged the gap between</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">the two systems would be =
smart enough to apply or remove the outer MIME</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">wrapper as appropriate.&nbsp; =
The text you are seeing is an attempt to cast these</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">thoughts into the language of =
RFC 2633.&nbsp; Perhaps there is a better way to</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">present this issue.</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">Perhaps a better way is to =
state that the MIME wrapper MAY be applied, and</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">simply state the conditions =
(as above).&nbsp; Thoughts?</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">In an X.400 =
environment where this RFC is most likely to be used, you don't need =
the extra outer MIME wrapper. In fact it only adds additional overhead =
(ca. 40 %) to the wrapped object. This was the rational for stating =
that the optional MIME encoding should not be used in X.400 =
environments. Apart from this I don't have any problems with Chris' new =
proposal. </FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; 3.&nbsp; Section =
3.2.1:&nbsp; The following</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; &nbsp;&nbsp;&nbsp;&nbsp; =
Content-Type: application/pkcs7-mime; smime-type=3Dsigned-data</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; Should be</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; &nbsp;&nbsp;&nbsp;&nbsp; =
Content-Type: application/pkcs7-mime; smime-type=3Dsigned-x400</FONT>
</P>

<P><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">Agree.&nbsp; Anders noted =
this earlier.</FONT>
</P>
<BR>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; 4.&nbsp; Section =
3.4.1:&nbsp; Step 4 uses the phrase &quot;in a single =
block&quot;.&nbsp; This</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; bothers me as it implies =
that the entire body needs to be supplied at</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; once.&nbsp; We octet =
wrap the content so this is not necessary.&nbsp; Please</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; remove or clarify what =
is meant by &quot;in a single block&quot;.</FONT>
</P>

<P><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">I don't see how it implies =
anything inappropriate.&nbsp; The step 4 encryption</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">has to process the entire =
step 3 output to proceed.&nbsp; I read &quot;in a single</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">block&quot; to mean that the =
result of step 3 including the content.&nbsp; Since the</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">detached signature form does =
not apply to triple-wrapped messages, this</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">seems to me to be the only =
way to do this.&nbsp; How do you think this could be</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">clarified?</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I don't see the =
problem either.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&gt; 5.</FONT>
</P>

<P><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">If there was a comment 5, I =
didn't receive it.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
</P>

<P><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">Best regards,</FONT>
<BR><FONT COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">&gt;</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Arial">Chris</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Best regards</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Anders</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C11F47.87579E90--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f76NXF120263 for ietf-smime-bks; Mon, 6 Aug 2001 16:33:15 -0700 (PDT)
Received: from relay2.bt.net (relay2.bt.net [194.72.6.62]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76NXEN20256; Mon, 6 Aug 2001 16:33:14 -0700 (PDT)
Received: from [217.33.147.100] (helo=BONATTIOMNI) by relay2.bt.net with smtp (Exim 3.15 #1) id 15TtrU-0000wb-00; Tue, 07 Aug 2001 00:32:40 +0100
From: "Bonatti, Chris" <[e-mail]>
To: <[e-mail]>
Cc: "Ietf-Smime" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Comments on draft-ietf-smime-x400wrap-03
Date: Mon, 6 Aug 2001 19:32:39 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <000d01c11e71$15a57ff0$[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Monday, August 06, 2001 08:13 Jim Schaad [mailto:[e-mail]]
wrote:
>
> 1.  Is it intentional that there is no section on content encryption
> algorithms for MUSTs?

Yes.  From the beginning, the model for this draft was RFC 2633.  We dealt
with this only in the "options" for CMS, and what it says has crept in
through various comments.

I would be content to say nothing about algorithms in WRAP, and leave the
topic to CMS (Son-of-CMS).  However, I don't think the division is easy to
make cleanly.


>
> 2.  I don't understand the reasoning behind the following statement from
> section 3.2.  Why should this be an important statement?  I don't like
> the fact that the encoding is suppose to be based on where one thinks
> the message MIGHT be sent.  I don't see any problem with SHOULD binary
> MAY mime wrap.   Additionally if a MIME wrapper is added to the outside
> of the SignedData object, then it does not matter if the inner is
> encoded as binary as the mime wrapper can base64 the entire object. [
> This is also inconsistant with behavior for encrypted data where it is
> always the x.400 content that is embedded. ]
>
> "Note that if SMTP [SMTP] used to transport the resulting signed-only
> message then the optional MIME encoding SHOULD be used. If binary
> transports such as X.400 are used then the optional MIME encoding SHOULD
> NOT be used."
>
> The preceeding text is also present in section 3.3, however it appears
> to be in conflict with the third paragraph where it states that MIME
> SHOULD NOT be used.

The notion here is multifold: (a) we don't think that an outer MIME wrapper
should be used in the X.400 scenario; (b) we recognize that there are places
where X.400 systems will meeting SMTP/MIME systems where the outer MIME
wrapper might be necessary; (c) we assumed that since this was outside the
security wrappers whatever servers or gateway logic bridged the gap between
the two systems would be smart enough to apply or remove the outer MIME
wrapper as appropriate.  The text you are seeing is an attempt to cast these
thoughts into the language of RFC 2633.  Perhaps there is a better way to
present this issue.

Perhaps a better way is to state that the MIME wrapper MAY be applied, and
simply state the conditions (as above).  Thoughts?


>
> 3.  Section 3.2.1:  The following
> 	Content-Type: application/pkcs7-mime; smime-type=signed-data
> Should be
> 	Content-Type: application/pkcs7-mime; smime-type=signed-x400

Agree.  Anders noted this earlier.


>
> 4.  Section 3.4.1:  Step 4 uses the phrase "in a single block".  This
> bothers me as it implies that the entire body needs to be supplied at
> once.  We octet wrap the content so this is not necessary.  Please
> remove or clarify what is meant by "in a single block".

I don't see how it implies anything inappropriate.  The step 4 encryption
has to process the entire step 3 output to proceed.  I read "in a single
block" to mean that the result of step 3 including the content.  Since the
detached signature form does not apply to triple-wrapped messages, this
seems to me to be the only way to do this.  How do you think this could be
clarified?

>
> 5.

If there was a comment 5, I didn't receive it.

>

Best regards,
Chris




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f76CCvJ00489 for ietf-smime-bks; Mon, 6 Aug 2001 05:12:57 -0700 (PDT)
Received: from relay3.bt.net (relay3.bt.net [194.72.6.50]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76CCtN00485 for <[e-mail]>; Mon, 6 Aug 2001 05:12:55 -0700 (PDT)
Received: from [217.33.136.55] (helo=revelation) by relay3.bt.net with esmtp (Exim 3.22 #1) id 15TjFa-0006c1-00; Mon, 06 Aug 2001 13:12:50 +0100
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, "Ietf-Smime" <[e-mail]>
Subject: Comments on draft-ietf-smime-compression-05
Date: Mon, 6 Aug 2001 13:12:50 +0100
Message-ID: <000e01c11e71$1caa8700$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2505.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

Just a couple of minor nits.  

1.  Section 1, para 1:  Change the SHOULD in the last sentence, this is
not a protocol statement so it should be lower case.

2.  Section 2:  For clarity (and to avoid missing the reference) I
suggest that the last paragraph should read:
"This algorithm has no parameters.  The parameters field SHOULD be
encoded as omitted, but MAY be encoded as NULL (see the implemenation
node in section 2.1)."

3.  ASN Module:  Imports should read:

IMPORTS
  CMSVersion, EncapsulatedContentInfo FROM CryptographicMessageSyntax
    { iso(1) member-body(2) us(840) rsadsi(113549)
      pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) }
  AlgorithmIdentifier FROM AuthenticationFramework
    { joint-iso-itu-t ds(5) module(1) authenticationFramework(7) 3 }; 

4.  ASN Module:
compression.asn(33) : error 1019: Type symbol
CompressionAlgorithmIdentifier never resolved.

Jim



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f76CCr500484 for ietf-smime-bks; Mon, 6 Aug 2001 05:12:53 -0700 (PDT)
Received: from relay3.bt.net (relay3.bt.net [194.72.6.50]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f76CCoN00477; Mon, 6 Aug 2001 05:12:51 -0700 (PDT)
Received: from [217.33.136.55] (helo=revelation) by relay3.bt.net with esmtp (Exim 3.22 #1) id 15TjFO-0006b4-00; Mon, 06 Aug 2001 13:12:38 +0100
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: "Ietf-Smime" <[e-mail]>
Subject: Comments on draft-ietf-smime-x400wrap-03
Date: Mon, 6 Aug 2001 13:12:38 +0100
Message-ID: <000d01c11e71$15a57ff0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2505.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

1.  Is it intentional that there is no section on content encryption
algorithms for MUSTs?

2.  I don't understand the reasoning behind the following statement from
section 3.2.  Why should this be an important statement?  I don't like
the fact that the encoding is suppose to be based on where one thinks
the message MIGHT be sent.  I don't see any problem with SHOULD binary
MAY mime wrap.   Additionally if a MIME wrapper is added to the outside
of the SignedData object, then it does not matter if the inner is
encoded as binary as the mime wrapper can base64 the entire object. [
This is also inconsistant with behavior for encrypted data where it is
always the x.400 content that is embedded. ]

"Note that if SMTP [SMTP] used to transport the resulting signed-only
message then the optional MIME encoding SHOULD be used. If binary
transports such as X.400 are used then the optional MIME encoding SHOULD
NOT be used."

The preceeding text is also present in section 3.3, however it appears
to be in conflict with the third paragraph where it states that MIME
SHOULD NOT be used.

3.  Section 3.2.1:  The following
	Content-Type: application/pkcs7-mime; smime-type=signed-data
Should be
	Content-Type: application/pkcs7-mime; smime-type=signed-x400

4.  Section 3.4.1:  Step 4 uses the phrase "in a single block".  This
bothers me as it implies that the entire body needs to be supplied at
once.  We octet wrap the content so this is not necessary.  Please
remove or clarify what is meant by "in a single block".

5.  



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f738swF05102 for ietf-smime-bks; Fri, 3 Aug 2001 01:54:58 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f738sus05095 for <[e-mail]>; Fri, 3 Aug 2001 01:54:56 -0700 (PDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHFDT00.1PL for <[e-mail]>; Fri, 3 Aug 2001 03:56:17 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5SU700.6G2; Fri, 27 Jul 2001 21:15:43 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id QAA26385; Tue, 24 Jul 2001 16:05:16 -0400 (EDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA21621 for [e-mail]; Tue, 24 Jul 2001 15:45:00 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12970 for <[e-mail]>; Tue, 24 Jul 2001 06:33:41 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06688; Tue, 24 Jul 2001 06:33:40 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-x400wrap-03.txt
Date: Tue, 24 Jul 2001 06:33:40 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Securing X.400 Content with S/MIME
	Author(s)	: P. Hoffman, C. Bonatti
	Filename	: draft-ietf-smime-x400wrap-03.txt
	Pages		: 
	Date		: 23-Jul-01
	
This document describes a protocol for adding cryptographic signature
and encryption services to X.400 content.

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

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-x400wrap-03.txt".

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-x400wrap-03.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f738svi05097 for ietf-smime-bks; Fri, 3 Aug 2001 01:54:57 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f738sts05089 for <[e-mail]>; Fri, 3 Aug 2001 01:54:56 -0700 (PDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHFDP00.BRV for <[e-mail]>; Fri, 3 Aug 2001 03:56:13 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5SQX00.1H0; Fri, 27 Jul 2001 21:13:45 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id QAA26873; Tue, 24 Jul 2001 16:19:29 -0400 (EDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA21760 for [e-mail]; Tue, 24 Jul 2001 15:55:00 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12977 for <[e-mail]>; Tue, 24 Jul 2001 06:33:46 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06700; Tue, 24 Jul 2001 06:33:45 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-x400transport-03.txt
Date: Tue, 24 Jul 2001 06:33:44 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Transporting S/MIME Objects in X.400
	Author(s)	: P. Hoffman, C. Bonatti
	Filename	: draft-ietf-smime-x400transport-03.txt
	Pages		: 
	Date		: 23-Jul-01
	
This document describes protocol options for conveying CMS-protected
objects associated with S/MIME version 3 over an X.400 message transfer
system.

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

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-x400transport-03.txt".

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-x400transport-03.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f732BCr04528 for ietf-smime-bks; Thu, 2 Aug 2001 19:11:12 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f732BBs04519 for <[e-mail]>; Thu, 2 Aug 2001 19:11:11 -0700 (PDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGZ3900.4ES for <[e-mail]>; Thu, 2 Aug 2001 22:04:21 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5SU700.6G2; Fri, 27 Jul 2001 21:15:43 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id QAA26385; Tue, 24 Jul 2001 16:05:16 -0400 (EDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA21621 for [e-mail]; Tue, 24 Jul 2001 15:45:00 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12970 for <[e-mail]>; Tue, 24 Jul 2001 06:33:41 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06688; Tue, 24 Jul 2001 06:33:40 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-x400wrap-03.txt
Date: Tue, 24 Jul 2001 06:33:40 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Securing X.400 Content with S/MIME
	Author(s)	: P. Hoffman, C. Bonatti
	Filename	: draft-ietf-smime-x400wrap-03.txt
	Pages		: 
	Date		: 23-Jul-01
	
This document describes a protocol for adding cryptographic signature
and encryption services to X.400 content.

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

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-x400wrap-03.txt".

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-x400wrap-03.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f732BCP04526 for ietf-smime-bks; Thu, 2 Aug 2001 19:11:12 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f732BAs04515 for <[e-mail]>; Thu, 2 Aug 2001 19:11:10 -0700 (PDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGZ2Y00.ODI for <[e-mail]>; Thu, 2 Aug 2001 22:04:10 -0400 
Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5SQX00.1H0; Fri, 27 Jul 2001 21:13:45 -0400 
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id QAA26873; Tue, 24 Jul 2001 16:19:29 -0400 (EDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA21760 for [e-mail]; Tue, 24 Jul 2001 15:55:00 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12977 for <[e-mail]>; Tue, 24 Jul 2001 06:33:46 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06700; Tue, 24 Jul 2001 06:33:45 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-x400transport-03.txt
Date: Tue, 24 Jul 2001 06:33:44 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Transporting S/MIME Objects in X.400
	Author(s)	: P. Hoffman, C. Bonatti
	Filename	: draft-ietf-smime-x400transport-03.txt
	Pages		: 
	Date		: 23-Jul-01
	
This document describes protocol options for conveying CMS-protected
objects associated with S/MIME version 3 over an X.400 message transfer
system.

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

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-x400transport-03.txt".

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-x400transport-03.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f71Cx3P26994 for ietf-smime-bks; Wed, 1 Aug 2001 05:59:03 -0700 (PDT)
Received: from iaik.tu-graz.ac.at (excalibur.iaik.tu-graz.ac.at [129.27.152.30]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f71Cx1s26990 for <[e-mail]>; Wed, 1 Aug 2001 05:59:02 -0700 (PDT)
Received: from edison [129.27.152.230] by iaik.tu-graz.ac.at (SMTPD32-6.06) id AD5135012A; Wed, 01 Aug 2001 15:00:01 +0200
Received: from 127.0.0.1 [127.0.0.1] by edison (IAIK S/MIME Mapper 2.01pre2 26/January/2001); Wed, 01 Aug 2001 15:02:07 +0100
From: "Dieter Bratko" <[e-mail]>
To: <[e-mail]>
Subject: AW: Comments to draft-ietf-smime-rfc2630bis-01
Date: Wed, 1 Aug 2001 15:02:06 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=sha1; boundary="--IAIK.SMIME.MAPPER.9E5D4856--"; protocol="application/x-pkcs7-signature"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multipart MIME message, it may require a MIME capable user agent.
----IAIK.SMIME.MAPPER.9E5D4856--
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

just to add one entry to the list: for our Java based CMS, S/MIMEv3 =
implementation we do not check the version number when parsing an =
EnvelopedData. However, we currently do not accept another RecipientInfo =
than KeyTransRecipientInfo, KeyAgreeRecipientInfo or KEKRecipientInfo as =
required by RFC 2630, i.e. we do not support PasswordRecipientInfo, and =
OtherRecipientInfo handling so far; we will wait to adopt our libraries =
until draft-ietf-smime-rfc2630 has reached its final version.

Regards,
Dieter Bratko, IAIK

-----Urspr=FCngliche Nachricht-----
Von: [e-mail]
[mailto:[e-mail]]Im Auftrag von Peter Gutmann
Gesendet: Freitag, 27. Juli 2001 18:39
An: [e-mail]
Betreff: Re: Comments to draft-ietf-smime-rfc2630bis-01



Here's a summary of the situation, hope I got all these right:

Baltimore (old, SMT): Rejects message if version !=3D 0
Baltimote (new, KeyTools): Won't process the message unless it =
understands the
  version (does this mean it requires version =3D 0...2?)
cryptlib (older versions): Rejects message if unknown version =
encountered (value >2)
cryptlib (newer versions): Ignores version
Microsoft: Ignores version
OpenSSL: Ignores version
RSA: Rejects message if version !=3D 0
SFL: Ignores version (except for use in reporting errors)
Tumbleweed: Rejects message if version !=3D 0

So it looks like there's about a 50/50 split between implementations =
which
require the version to be 0 (or in some cases 0...2) and ones which =
ignore it
entirely.

Peter.




----IAIK.SMIME.MAPPER.9E5D4856--
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA
oIIgmTCCBM0wggO1oAMCAQICFBcTfeE+LbuTGJMi19UPnd2CkFKbMA0GCSqGSIb3
DQEBBQUAMIHEMQswCQYDVQQGEwJBVDEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZ
IE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIElu
Zm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMSEwHwYDVQQL
ExhJQUlLIEV1cm9QS0kgSU5UUkFORVQgQ0ExITAfBgNVBAMTGElBSUsgRXVyb1BL
SSBUVS1HUkFaIFNJRzAeFw0wMDEyMjAxNTU4MzBaFw0wMTEyMjAxNTU4MzBaMIGW
MQswCQYDVQQGEwJBVDEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hO
T0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9u
IFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRYwFAYDVQQDEw1EaWV0ZXIg
QnJhdGtvMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXOzhALiz61TA+BqQ7
GedFI2iHnRvOWvl7EMeg8GiOACPbwXSGqLQJVq6kYcJLCBytkaObJxfvOxzDl9WQ
EbEiodgBQ9TyRWt+PCjMikrWvBYONkt9/xaxPxlgG2kvRbqHQ4K91yh3Jk4ONZqC
PXnrVv1A1R6S90HNnIiO991BiQIDAQABo4IBZTCCAWEwDAYDVR0TAQH/BAIwADAO
BgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAUeLVVoTO9gyV/6vPnjLejn5Vzqnsw
VAYDVR0gBE0wSzBJBgwrBgEEAZUSAQICAQEwOTA3BggrBgEFBQcCARYraHR0cDov
L2V1cm9wa2kuaWFpay5hdC9jYS9pbnRyYW5ldC9jcHMvMS4xLzBMBgNVHR8ERTBD
MEGgP6A9hjtodHRwOi8vZXVyb3BraS5pYWlrLmF0L2NhL2ludHJhbmV0L2NybC9p
YWlrX2V1cm9wa2lfc2lnLmNybDARBglghkgBhvhCAQEEBAMCACAwKAYJYIZIAYb4
QgENBBsWGVVzZXItQ2VydGlmaWNhdGUgSU5UUkFORVQwIAYDVR0RBBkwF4EVRGll
dGVyLkJyYXRrb0BpYWlrLmF0MB0GA1UdDgQWBBQXE33hPi27kxiTItfVD5z59Ufo
8jANBgkqhkiG9w0BAQUFAAOCAQEAOs03CEWMz0z4SVCNE1SQsFgmOTWHFNpClvCs
WtqP8Sqc1NbbbwK1a3TQSuM+qszebiBm8elZU2e5dTT7CbMA9M67Ja3YIj3ua4SU
pzQhaKEc9fgtr0kBBw9xMvW/T80ht44oNc8EnmNl8WUDns26X19vdCAFbKYOyzKe
IoXUQfZ+mt75XE53R6IdQVaRsyoFu89GLytqp3SSVCDylqpC9Gjvm00ok6ly2ZAn
Gv++ZytkcVNlVoUBjy6/Hs8CaNyZqnnEbfABdfL6djln3KkLW8eHafbbwpeFeWac
VIzXNgQFxuR5qEs87gHzgE4QFB1BZLrxk1RVaEuEVBec7T8OazCCBTwwggQkoAMC
AQICFHi1VaEzvYMlf+rz54y3pIMcl/owMA0GCSqGSIb3DQEBBQUAMIHLMQswCQYD
VQQGEwJBVDENMAsGA1UEBxMER3JhejEZMBcGA1UECRMQSW5mZmVsZGdhc3NlIDE2
YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNV
BAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3Npbmcg
YW5kIENvbW11bmljYXRpb25zMSEwHwYDVQQDExhJQUlLIEV1cm9QS0kgSW50cmFu
ZXQgQ0EwHhcNMDAxMjE5MTEyMTQ3WhcNMDIxMjMwMjI1OTMwWjCBxDELMAkGA1UE
BhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9MT0dZMUcw
RQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQcm9jZXNz
aW5nIGFuZCBDb21tdW5pY2F0aW9uczEhMB8GA1UECxMYSUFJSyBFdXJvUEtJIElO
VFJBTkVUIENBMSEwHwYDVQQDExhJQUlLIEV1cm9QS0kgVFUtR1JBWiBTSUcwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDxWjtQORZimthvkSAAJlIL97tg
PeJ8+151iGCyd44WFAyjHsP9oQrZHxazVAB+o8clYdPpp/ECognU41o40iafdgkN
IfsjyFMm3VvcWNx+F4vKYTHoLQascxRJUULgub+B4k4pb9A4URQnxkrMriQlISoF
XeEY1l2Mv4DlXHF3qOEMiLW5B1vmZZaEpNvH/me8fuvJYLi9FWA+Ojk/UybbrGyb
keJY3RAq+FImnWkaB9BAoAhdROR+GXU8YvqZTzqUndKog1KccBKaFTBKwSz9RxOV
PFORs1VLGItlnGRCn25uOiDTDfrU2D4D9cyFEVU+Qd55RzD6PfgP8BbeUyTxAgMB
AAGjggEbMIIBFzASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBxjAf
BgNVHSMEGDAWgBSEWAP+T9cNWn701+2abEq0uxAz0jBUBgNVHSAETTBLMEkGDCsG
AQQBlRIBAgIBATA5MDcGCCsGAQUFBwIBFitodHRwOi8vZXVyb3BraS5pYWlrLmF0
L2NhL2ludHJhbmV0L2Nwcy8xLjEvMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9l
dXJvcGtpLmlhaWsuYXQvY2EvaW50cmFuZXQvY3JsL2lhaWtfZXVyb3BraS5jcmww
EQYJYIZIAYb4QgEBBAQDAgACMB0GA1UdDgQWBBR4tVWhM72DJX/q8+eMt6OflXOq
ezANBgkqhkiG9w0BAQUFAAOCAQEAscTGRuY2BJizRRfug1JU1qhaLVOjZvYPOikX
leQuPBPXFSoT9jwbzDkyN76QMnondlgf0F1Gr+w4LqljFKAdjqFGSXJxAzGjMFbj
Tjyv7mit0Ppk7wKohXM/c8ThDCEBnnAYcTgg504BtJhBmN0ThyL6tAXYfRFqHsgn
1rj58bS+6lAa6n9iepn/yznhnFWr24imSVvef8nbI2GwphBAhNXh+Jq+BWR1pr5u
UJ9ilzL44elcZ+Omh4lsILiUf6YR1xR9+d3G4VQMMOmpfgf0GJVKNKcelVlK4PW/
0VgvDxoyQQFVE2hiLd5r/jUzT4zlLy+5hk3FnxSUgnl14w/u3DCCBLMwggOboAMC
AQICFQCEWAP+T9cNWn701+2abEuYPjyavTANBgkqhkiG9w0BAQUFADBSMQswCQYD
VQQGEwJBVDEQMA4GA1UEChMHRXVyb1BLSTExMC8GA1UEAxMoRXVyb1BLSSBBdXN0
cmlhbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wMDEyMTgxNjUyMzFaFw0w
MjEyMzAyMjU5MzBaMIHLMQswCQYDVQQGEwJBVDENMAsGA1UEBxMER3JhejEZMBcG
A1UECRMQSW5mZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZ
IE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIElu
Zm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMSEwHwYDVQQD
ExhJQUlLIEV1cm9QS0kgSW50cmFuZXQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQDPwrEj1RtzPWRZUGptWv2/KsgPQ0FyMHHYemhn/+QjUv51aD9f
mcqqUU/CgroJE6sLtN6cZoQ91gnxIS/Gw95PNhUX6jZfN4PF5K/GXz3ZUx/bcvcm
4tjFGG12jxWT4IN9d3oT5SMMjh1Aw0BE35yySnlqBcfWHR7gtBpsdAovw1Txy8Bt
8vmBrhe27dY0d3bJitULO1CG19G0Q374rnJ/CY9ZEHsz0498Ej5+eFnefSEilJ7k
QNDNU2zCx7xuu0jdu0yrb5Y1+RBdgJHCoMldUbOA2HkNOz9YLyiYWPWRxT9fcPgX
v9jSYu+t+DB0MMPz53ZcYILVsopsjhKduVO5AgMBAAGjggEEMIIBADAPBgNVHRMB
Af8EBTADAQH/MA4GA1UdDwEB/wQEAwIBxjAfBgNVHSMEGDAWgBQAemdURVCCrBm2
toURUbtpOdgt1DBWBgNVHSAETzBNMEsGDCsGAQQBlRIBAgEBATA7MDkGCCsGAQUF
BwIBFi1odHRwOi8vZXVyb3BraS5pYWlrLmF0L2NhL2V1cm9wa2ktYXQvY3BzLzEu
MS8wRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL2V1cm9wa2kuaWFpay5hdC9jYS9l
dXJvcGtpLWF0L2NybC9hdXN0cmlhLmNybDAdBgNVHQ4EFgQUhFgD/k/XDVp+9Nft
mmxKtLsQM9IwDQYJKoZIhvcNAQEFBQADggEBAC8BA5jJSByaJAeDxiEW4O8mJJdS
suO/KyoEJVjcAyyMx9lJdHNtgwabhFHR2cUZz++vKkJFpmA+A7jgjRO5IwQxiMTo
rdze8X7rxmBlZvizFJfxUwalTAUbJ9iaLjJza42qTwjRRPSEji4b9hcg+6PpK4pO
dZ++SrIrE1qIvRqx3fFqEo8LHkkR8ZHKB/tT4GKQck/tUfeuotfQI/Xlprqctmgz
mjRC0giMEurV2Ogf6kxz9BzmibwGBtCqG0GLN5XKCr6fNBAD3W+Xt0FoujZfZlJq
K3bt6re712rdZnztVlOaCc6gSB9WY7ZrNFhAm9+a2HzlTc7ZS+ePjC8yLW4wggRQ
MIIDOKADAgECAgEJMA0GCSqGSIb3DQEBBAUAMEExEDAOBgNVBAoTB0V1cm9QS0kx
LTArBgNVBAMTJEV1cm9QS0kgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe
Fw0wMDExMjMxNDI0NDVaFw0wMjEyMzExMjAwMDBaMFIxCzAJBgNVBAYTAkFUMRAw
DgYDVQQKEwdFdXJvUEtJMTEwLwYDVQQDEyhFdXJvUEtJIEF1c3RyaWFuIENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAoE5gWK44kT3O3Yenp0GT6+gkypmIAlhqYAcmokavl3WaQ4BhBlAv4ORtBF/h
VObG1ugPCep7cTNyoXZ+sNIbmlLzBxzrRpT4nYQIEu3IXR108c6APycH+9vbYIUQ
rsCKx8Qs/csU5rdOxc15pHsZLJiiCYATB0GWyrcbVcoNgAj6crv7Lx37SlENgMAs
sOoG4E3/2wrCQ2n/QiqBEosscpnEqQs6ABvdQiLKSpfVQJA77l9ujQ1C/ugtlYwA
r5GrtSOhOTYvKB4tuVleqlHFzJoA6XaWQRpD4Oy4ymF0+5IAe9q+lOQ6U57rWIZ0
MMr8xAmf7VZtmk0KJYCkAl3DPwIDAQABo4IBQDCCATwwTAYJYIZIAYb4QgENBD8W
PUlzc3VlZCB1bmRlciBwb2xpY3k6CiBodHRwOi8vd3d3LmV1cm9wa2kub3JnL2Nh
L3Jvb3QvY3BzLzEuMS8wOwYDVR0fBDQwMjAwoC6gLIYqaHR0cDovL3d3dy5ldXJv
cGtpLm9yZy9jYS9yb290L2NybC9jcmwuZGVyMA8GA1UdEwEB/wQFMAMBAf8wTgYD
VR0gBEcwRTBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cu
ZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzAOBgNVHQ8BAf8EBAMCAf4wHQYD
VR0OBBYEFAB6Z1RFUIKsGba2hRFRu2k52C3UMB8GA1UdIwQYMBaAFIzci7GlSpDn
TohzGDyd1V5+5LLNMA0GCSqGSIb3DQEBBAUAA4IBAQD0VfvB2KWA/FyENfhXDK7/
YQwRxdAJj/3VzpdvUPb9mHW9O1kry3ZeM9IfcYqbFPdP9ZvW/g2mWQI9k4vMKDte
PnzQuy+ZUuvxuKlJ7taWAAHkiXTBbJoscHetWVlIINuPYCQF33DTd5otjcOxsE+U
9xjqP5tCLMzQEmnmTaUdZYWZFIjfKzoLC2JEaeVjDUQrYYwL6OUYP6aWoML1gqUP
2PFzRKQK/EMSjRQzTU9ZZLVvc+FS797ki6f8zRxPGqheV4EyjFXRbY03/4fjcZ5p
wictxM97tFYmmlkmWmkEvI+7ToPZ/WtPyqXciKJ9ZT/OJWWWzfXgiz5ECXNBlO0D
MIIDYDCCAkigAwIBAgIBADANBgkqhkiG9w0BAQQFADBBMRAwDgYDVQQKEwdFdXJv
UEtJMS0wKwYDVQQDEyRFdXJvUEtJIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3Jp
dHkwHhcNOTkxMjI5MTczMDM5WhcNMTAxMjMxMTIwMDAwWjBBMRAwDgYDVQQKEwdF
dXJvUEtJMS0wKwYDVQQDEyRFdXJvUEtJIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRo
b3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD/L/zLh4UggkIi
JA2Jmuwd6/TLOoToZz3Dr0FoCgehip+ZNrX1ehBw0esCK6Z18SfDOeyDB+ia3qWa
ltedQVttLUQnVPdXmzubIVapWFoHm1u3oLhBgSp1mHBmAsKmGvHV/IYF4t709tUQ
lpeZgjIzpbjzN799Xoa2X2yJqGGBADzHKiJn5p80LsMnx3VR/UyIXZJEq611UlAD
fJH1qhwUzNa0F80j0tk7/paLhnWrZDsfZNGkAugQLBDUi+nBKUu4FicpfYL7HGX4
fRmtg+oLuQ1vHlYe2YVs+UGI47e7jd4Yf1vbjinQ0OUrx2nx8z+xo47lgXwMbEJ7
VwrECjS3AgMBAAGjYzBhMB8GA1UdIwQYMBaAFIzci7GlSpDnTohzGDyd1V5+5LLN
MB0GA1UdDgQWBBSM3IuxpUqQ506Icxg8ndVefuSyzTAOBgNVHQ8BAf8EBAMCAcYw
DwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOCAQEAW2j/nnW9QhtCe1iQ
dV9KFy9rnOpKH43tHFjuUBlgpgvNv01/rXMXLn/W81nuLTmZwdhYcjldUZZR6WUG
LtArOLQaUkTQMHjc/EkU/s0v8MuWNg5vhC3ZsFFNVtfR8iWa2a+gA4uBH17cXd6P
uzqD0HMFA75P32kes3xblFWZ5qSYGQvy4aWoT/FDsbeJG/Upp8FbZ2Z0pSqfi9cA
WGqzRYlT0dgu8Z2RFwwd/vPvVpQldB1ScRkfpL6PCLvmmfMRHq8Zg0JMcqmIXYYg
0PcPdJ+ECikSYd/7G50/uIfJDDZEOIkmpXVn3cQmcMDRauhvwsoR6B2lCX/cEI0P
EnMBaDCCBNIwggO6oAMCAQICFQDeZVHH4iFilNfPlzX08Z0b0Ji9ADANBgkqhkiG
9w0BAQUFADCBxjELMAkGA1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lU
WSBPRiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJ
bmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEhMB8GA1UE
CxMYSUFJSyBFdXJvUEtJIElOVFJBTkVUIENBMSMwIQYDVQQDExpJQUlLIEV1cm9Q
S0kgVFUtR1JBWiBDUllQVDAeFw0wMDEyMjAxNTU2NThaFw0wMTEyMjAxNTU2NTha
MIGWMQswCQYDVQQGEwJBVDEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRF
Q0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0
aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMRYwFAYDVQQDEw1EaWV0
ZXIgQnJhdGtvMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDPLL4N1Teh5nHJ
PRQEwmIeohSAc9Zv5apagKu7l9s4TB6RUmHIgXSGvCkBOchxsHQYq39yNnBJoPN5
B9T0XyKXAx1PxSyIrqm70XIFKqreQOImyUdRMnM7WsqD0ZPEJscIiUCtcgEC+fOV
cgEUPhtXTyL9XHoE5A9Xr5TnSl5k4wIDAQABo4IBZzCCAWMwDAYDVR0TAQH/BAIw
ADAOBgNVHQ8BAf8EBAMCBDAwHwYDVR0jBBgwFoAUmikZ1heewVHfzGeDobfkvw+4
Qx0wVAYDVR0gBE0wSzBJBgwrBgEEAZUSAQICAQEwOTA3BggrBgEFBQcCARYraHR0
cDovL2V1cm9wa2kuaWFpay5hdC9jYS9pbnRyYW5ldC9jcHMvMS4xLzBOBgNVHR8E
RzBFMEOgQaA/hj1odHRwOi8vZXVyb3BraS5pYWlrLmF0L2NhL2ludHJhbmV0L2Ny
bC9pYWlrX2V1cm9wa2lfY3J5cHQuY3JsMBEGCWCGSAGG+EIBAQQEAwIAIDAoBglg
hkgBhvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5FVDAgBgNVHREEGTAX
gRVEaWV0ZXIuQnJhdGtvQGlhaWsuYXQwHQYDVR0OBBYEFN5lUcfiIWKU18+XNfTx
nDhDUbmNMA0GCSqGSIb3DQEBBQUAA4IBAQBI6mZE7r7uyVu3/3KKzLtDz+8hpBmW
BEOiMIHIZDTR5OM7DDEkJAf+NK5o4aZxKQhXA31U6mXCJCnJt6J1gWAMqCwRo+ud
GNav/HJq6u5MmqKDkRwcYr5HLqTsFVqG4hJk74qpmPpUCI7BbXuCBlI8C4pH9c4H
IWuVjXRbX3F6tW4vZsY0uuIhMHd7g84tlgWQfTz2qkfpCr2yUQx4/2c3C4Xg4eh3
CMB1X1wPZouz8FKgWgSnf3DvS8smf38JzKV9TdAaSIuJI9MC0j/ItoJrBxEZnZMQ
Y+SO/JHeWzqEYHiFSIaXQ86EBe3vHnEKRlFQSLUchaLoplNdtGYd6JsXMIIFPzCC
BCegAwIBAgIVAJopGdYXnsFR38xng6G35aKW5xLxMA0GCSqGSIb3DQEBBQUAMIHL
MQswCQYDVQQGEwJBVDENMAsGA1UEBxMER3JhejEZMBcGA1UECRMQSW5mZmVsZGdh
c3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kx
RzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nl
c3NpbmcgYW5kIENvbW11bmljYXRpb25zMSEwHwYDVQQDExhJQUlLIEV1cm9QS0kg
SW50cmFuZXQgQ0EwHhcNMDAxMjE5MTEzMzExWhcNMDIxMjMwMjI1OTMwWjCBxjEL
MAkGA1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNITk9M
T0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlvbiBQ
cm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEhMB8GA1UECxMYSUFJSyBFdXJv
UEtJIElOVFJBTkVUIENBMSMwIQYDVQQDExpJQUlLIEV1cm9QS0kgVFUtR1JBWiBD
UllQVDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANYiS3bhpzaIPVFl
bQHOyiURwzuToLk9vwQfFWiNayMmyxwEHfZdL0faHb9eaNU4u0I+g2IRqqbxauoW
TLb0h2iS2Qt1Xpu9biA3faTXua89Q0I+ao7vyJ1qpcKb/+hxdEzBQekwK/U037kp
QwnXwENyGW0j9mPVu1gDtxnLgDHTWTpnbMdQmSgBzv/7H3mjwKb/UP0nHFnmjq0d
2IBiDJSMIDpDcvQOY1CAs84xZTll9wA0NZ8xMAfvVzehElooi6bfIIrNOHJfbhfu
JJT9IjWYDa4mc56sTB64s2Ga7mQnMf7Tv0HYnKxyv3bV/NzPooQSMSgS2cXxVJS+
EVbFvZsCAwEAAaOCARswggEXMBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/
BAQDAgHGMB8GA1UdIwQYMBaAFIRYA/5P1w1afvTX7ZpsSrS7EDPSMFQGA1UdIARN
MEswSQYMKwYBBAGVEgECAgEBMDkwNwYIKwYBBQUHAgEWK2h0dHA6Ly9ldXJvcGtp
LmlhaWsuYXQvY2EvaW50cmFuZXQvY3BzLzEuMS8wSAYDVR0fBEEwPzA9oDugOYY3
aHR0cDovL2V1cm9wa2kuaWFpay5hdC9jYS9pbnRyYW5ldC9jcmwvaWFpa19ldXJv
cGtpLmNybDARBglghkgBhvhCAQEEBAMCAAIwHQYDVR0OBBYEFJopGdYXnsFR38xn
g6G35L8PuEMdMA0GCSqGSIb3DQEBBQUAA4IBAQBAnH0+OJpDTzklH3perXGuODlh
hklnM6bf2OKb9BeUeFzaL044eXXuQqqX2YdRQdsMz4J4HPyg3ueQ9crRben2OtBs
aKPq/cxI/O2d+TBtmXtqyRN57KuYjesL+NHqZZMv8AILGftu1NzxT/0gkgW/U5Az
4j2jUvrwLPGxt11NKAafqGPNk7pOeQxb4jxpZB7646O22F7/USuGX1gZIe/wSSos
5Z8mugpz2aYqzaJg1wRtPxUWDsrn79wKqqmnry8Uuxgm2aXKru9TrRc0UxJoDmaD
NzjCsHw5sw73yugFEmwx8pICKtJe6CIqRFHKg90L6vGyJpUprLZd3sYNK7mkMYID
LTCCAykCAQEwgd0wgcQxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZF
UlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxp
ZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxITAf
BgNVBAsTGElBSUsgRXVyb1BLSSBJTlRSQU5FVCBDQTEhMB8GA1UEAxMYSUFJSyBF
dXJvUEtJIFRVLUdSQVogU0lHAhQXE33hPi27kxiTItfVD53dgpBSmzAJBgUrDgMC
GgUAoIIBpTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wMTA4MDExMzAyMDdaMCMGCSqGSIb3DQEJBDEWBBQEBCbGljrpsdNXPhx5Xbkc
CojexjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA
gDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCBzCB8QYJKwYB
BAGCNxAEMYHjMIHgMIHGMQswCQYDVQQGEwJBVDEmMCQGA1UEChMdR1JBWiBVTklW
RVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBs
aWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMSEw
HwYDVQQLExhJQUlLIEV1cm9QS0kgSU5UUkFORVQgQ0ExIzAhBgNVBAMTGklBSUsg
RXVyb1BLSSBUVS1HUkFaIENSWVBUAhUA3mVRx+IhYpTXz5c19PGdG9CYvQAwDQYJ
KoZIhvcNAQEBBQAEgYCp+u15njME+b8VRZeeX9IX0y22BrGUF7tjmfH6DGjHfzKF
HfLfM0E7LSc+R58KTFePzmeyJx39J0tzjK2wrrYmyziZr5ogrORTqgwET06VymAD
f+tHX/NJjCl9QweKhNUCTNiMAhzeXQr3uYtT4E9do8W9hoM0julmpf3Qjo8LFwAA
AAAAAA==
----IAIK.SMIME.MAPPER.9E5D4856----