John:
Thank you for your careful review. I agree with all of the points made in
you proposed replacement to section 5.2.1. I did want to replace "MAY"
with "can" in two places, and I made a few other editorial changes. Please
confirm that the following text is acceptable.
Russ
- - - - - - - - - -
5.2.1 [*** NEW ***] Compatibility with PKCS #7
This section contains a word of warning to implementers that wish to
support both the CMS and PKCS #7 [PKCS#7] SignedData content types.
Both the CMS and PKCS #7 identify the type of the encapsulated
content with an object identifier, but the ASN.1 type of the content
itself was variable in PKCS #7 SignedData content type.
PKCS #7 defines content as:
content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL
The CMS defines eContent as:
eContent [0] EXPLICIT OCTET STRING OPTIONAL
The CMS definition is much easier to use in most applications, and it
is compatible with both S/MIME v2 and S/MIME v3. S/MIME signed
messages exchanged between applications using the CMS and PKCS #7 are
compatible because the RFC 2311 S/MIME v2 [OLDMSG] and RFC 2633
S/MIME v3 [MSG] signed message formats are identical. S/MIME v2
encapsulates the MIME content in a Data type (that is, an OCTET
STRING) carried in the SignedData contentInfo content ANY field, and
S/MIME v3 carries the MIME content in the SignedData encapContentInfo
eContent OCTET STRING. Therefore, in both S/MIME v2 and S/MIME v3,
the MIME content is placed in an OCTET STRING and the message digest
is computed over the identical portions of the content. That is, the
message digest is computed over the octets comprising the value of
the OCTET STRING, neither the tag nor length octets are included.
There are incompatibilities between the CMS and PKCS #7 signedData
types when the encapsulated content is not formatted using the Data
type. For example, when an RFC 2634 [ESS] signed receipt is
encapsulated in the CMS signedData type, then the Receipt SEQUENCE is
encoded in the signedData encapContentInfo eContent OCTET STRING and
the message digest is computed using the entire Receipt SEQUENCE
encoding (including tag, length and value octets). However, if an
RFC 2634 signed receipt is encapsulated in the PKCS #7 signedData
type, then the Receipt SEQUENCE is encoded in the SignedData
contentInfo content ANY field (a SEQUENCE, not an OCTET STRING).
Therefore, the message digest is computed using only the value octets
of the Receipt SEQUENCE encoding.
The following strategy can be used to achieve backward compatibility
with PKCS #7 when processing SignedData content types. If the
implementation is unable to ASN.1 decode the signedData type using
the CMS signedData encapContentInfo eContent OCTET STRING syntax,
then the implementation MAY attempt to decode the signedData type
using the PKCS #7 SignedData contentInfo content ANY syntax and
compute the message digest accordingly.
The following strategy can be used to achieve backward compatibility
with PKCS #7 when creating a SignedData content type in which the
encapsulated content is not formatted using the Data type.
Implementations MAY examine the value of the eContentType, and then
adjust the expected encoding of eContent based on the object
identifier value. For example, to support Microsoft AuthentiCode,
the following information MAY be included:
eContentType Object Identifier is set to { 1 3 6 1 4 1 311 2 1 4 }
eContent contains AuthetiCode signing information