Russ,
The AC syntax is an integral part of the SignedData and EnvelopedData
syntaxes, so the SignedData and EnvelopedData version numbers should be
changed to indicate the new syntaxes. Many generic ASN.1 toolkits (such as
SNACC) decode the entire syntax in one pass (except for data included within
ANY or OCTET STRING components which require a second pass). There is not a
straight forward means of changing the generic ASN.1 toolkit to check
version numbers "mid-stream" while decoding the syntax. Because the AC
syntax is not included in an ANY or OCTET STRING component, it is not
practical to check the AC version number before decoding the AC using a
generic ASN.1 toolkit.
My proposal would allow implementers to perform a simple pre-check of the
signedData or EnvelopedData hex data before calling the generic ASN.1
toolkit to decode the hex data. There is a fixed number of bytes preceding
the version number in the ASN.1 encoded SignedData and EnvelopedData hex
data, so the processing software could simply check the fixed byte position
to determine the version number. For signedData, if the version number is
3, then the processing software would call the ASN.1 library using the
signedData syntax including the old AC syntax. If the version number is 4,
then the processing software would call the ASN.1 library using the
signedData syntax including the new AC syntax. Similar pre-processing could
be performed for EnvelopedData objects.
Of course another option is to simply use trial and error. We could try
decoding the SignedData or EnvelopedData using the syntax including the new
AC syntax. If we get a decode error, then we could try using the syntax
containing the old AC syntax. I would prefer that we define a clean
strategy (i.e. new SignedData and EnvelopedData version numbers), rather
than needing to resort to trial and error.
I people prefer that the S/MIME documents import ASN.1 structures from the
PKIX documents because they are freely available. Care needs to be taken
that the PKIX documents define equivalent ASN.1 syntaxes as the ITU-T
documents and ANSI X9 documents, assuming that interoperability is required.
As expressed in previous messages sent to the S/MIME and PKIX lists, the
current PKIX AC profile document defines an AC syntax that is not equivalent
to the v2 AC syntax defined in the 2000 X.509 Recommendation.
===========================================
John Pawling, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Getronics Government Solutions, LLC
===========================================
-----Original Message-----
From: Russ Housley [mailto:rhousley(_at_)rsasecurity(_dot_)com]
Sent: Thursday, April 12, 2001 1:45 PM
To: Pawling, John
Cc: 'ietf-smime(_at_)imc(_dot_)org'
Subject: RE: S/MIME version number
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:
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.