All,
In my opinion, Russ has done an outstanding job of updating this document.
I recommend that section 5.2.1 be replaced with the following text:
"5.2.1 [*** NEW ***] Compatibility with PKCS #7 SignedData Type
This section contains a word of warning to implementers that wish to support
both the CMS and PKCS #7 [PKCS#7] SignedData types. Both the CMS and PKCS
#7 SignedData types identify the type of the encapsulated content with an
object identifier, but the ASN.1 type of the content itself was variable in
the PKCS #7 SignedData type.
PKCS #7 defined content as:
content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL
CMS defines eContent as:
eContent [0] EXPLICIT OCTET STRING OPTIONAL
The CMS definition is much easier to use in most applications, and is
compatible with both S/MIME v2 and S/MIME v3. There are some deployed
applications that use the PKCS #7 definition. S/MIME signed messages
exchanged between PKCS #7 and CMS applications are compatible because the
RFC 2311 S/MIME v2 and RFC 2633 S/MIME v3 signed message formats are
identical. RFC 2311 specifies that the MIME content MUST be encapsulated in
a Data type (i.e. OCTET STRING) stored in the SignedData contentInfo content
ANY field. RFC 2633 specifies that the MIME content MUST be stored in the
SignedData encapContentInfo eContent OCTET STRING. In both cases, the MIME
content is stored in an OCTET STRING and the message digest is computed over
the identical portions of the content (i.e. only the octets comprising the
value of the OCTET STRING are input to the message digest algorithm, not the
tag or length octets).
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 signed receipt is encapsulated in a 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). If an RFC 2634 signed receipt is encapsulated in a PKCS #7
signedData type, then the Receipt SEQUENCE is encoded in the SignedData
contentInfo content ANY field (i.e. not an OCTET STRING) and the message
digest is computed using only the value octets (not the tag and length
octets) of the Receipt SEQUENCE encoding.
The following strategy MAY be used to achieve PKCS #7 backward compatibility
when processing signedData types. If the CMS implementation is unable to
ASN.1 decode the signedData type using the CMS signedData encapContentInfo
eContent OCTET STRING syntax, then the CMS implementation MAY attempt to
decode the signedData type using the PKCS #7 SignedData contentInfo content
ANY syntax and compute the message digest accordingly (i.e. using only the
value octets of the content, not the tag and length octets).
The following strategy MAY be used to achieve PKCS #7 backward compatibility
when creating a signedData type in which the encapsulated content is not
formatted using the Data type. CMS 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 = { 1 3 6 1 4 1 311 2 1 4 }
eContent Type = SpcIndirectDataContext -- Microsoft code signing"
===========================================
John Pawling, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Getronics Government Solutions, LLC
===========================================