Subject: RE: S/MIME version number

From: "Pawling, John" <[email-masked]>
Date: Mon, 9 Apr 2001 10:51:57 -0400

Blake (and friends),

I don't object to calling the new set of RFCs "S/MIME Version 3.1".  During
the last S/MIME working group meeting, I was trying to make the point that
the RFC 2630 CMSVersion values do not need to be changed based solely on the
algorithms used to protect the CMS objects (because the algorithmIdentifiers
identify the algorithms used).  

However, there is another factor to discuss related to this issue.  The
Attribute Certificate (AC) ASN.1 syntaxes defined in the 1997 and 2000 X.509
Recommendations are incompatible.  I believe that it is planned for the
"son-of-RFC 2630" to import the AC syntax from the 2000 X.509 Recommendation
rather than from the 1997 X.509 Recommendation as with RFC 2630.  This will
result in a change to the AC syntax included in the CertificateChoices
syntax used in the CMS SignedData and EnvelopedData syntaxes.  The use of
the CMSVersion values should be changed in "son-of-RFC 2630" to identify the
new CMS SignedData and EnvelopedData syntaxes as follows:

1) RFC 2630, Section 5.1  SignedData Type: Change "shall be 3" to "shall be
4" in the following text:

 "version is the syntax version number.  If no attribute
  certificates are present in the certificates field, the
  encapsulated content type is id-data, and all of the elements of
  SignerInfos are version 1, then the value of version shall be 1.
  Alternatively, if attribute certificates are present, the
  encapsulated content type is other than id-data, or any of the
  elements of SignerInfos are version 3, then the value of version
  shall be 3."

2) RFC 2630, Section 6.1  EnvelopedData Type: Change all occurrences of
"shall be 2" to "shall be 3" in the following text:

 "version is the syntax version number.  If originatorInfo is
  present, then version shall be 2.  If any of the RecipientInfo
  structures included have a version other than 0, then the version
  shall be 2.  If unprotectedAttrs is present, then version shall be
  2.  If originatorInfo is absent, all of the RecipientInfo
  structures are version 0, and unprotectedAttrs is absent, then
  version shall be 0.

The other option is that the "son-of-RFC 2630" CMSVersion number usage could
remain the same as defined in RFC 2630 if the working group assumes that
1997 ACs have not been operationally used in SignedData and EnvelopedData
objects.  I do not know if that is a safe assumption.      

===========================================
John Pawling, [email-masked]
Getronics Government Solutions, LLC
===========================================

---

From: Russ Housley <[email-masked]>
Date: Thu, 12 Apr 2001 13:45:13 -0400

John:

I understand that X.509-2000 includes updated syntax for the attribute 
Certificate (AC).  However, this structure already includes a version 
number.  The earlier syntax has v1, and the later syntax has v2.  Since 
this stricture is "self versioning," why do we need to update the version 
number in the parent structure?

Would people prefer to import structures from the PKIX documents (as 
opposed to the ITU-T and ANSI X9 documents)?  At the time RFC 2630 was 
done, PKIX did not have a profile of ACs.  Note that the PKIX AC profile 
requires the use of v2 AC syntax.

Russ

At 10:51 AM 4/9/2001 -0400, Pawling, John wrote:
>syntax used in the CMS SignedData and EnvelopedData syntaxes.