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, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Getronics Government Solutions, LLC
===========================================