Russ:
Items of agreement have been removed.
Jim:
This text was proposed by Peter Gutmann and improved upon by John
Pawling. This is one place where backward comparability with
PKCS#7 has
not been preserved, and we are trying to warn implementors about the
potential dangers.
You make a good point about DER. I have made a few changes
to the text to
highlight the DER issue. Are these changes sufficient? I propose:
5.2.1 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 is 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 using the CMS and PKCS #7 are compatible because
identical
signed message formats are specified in RFC 2311 for S/MIME v2
[OLDMSG] and RFC 2633 for S/MIME v3 [MSG]. 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 DER encoded [X.509-88] 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.
I have a minor issue with the last sentence. The digest must include
the type and length bytes of the SEQUENCE and I don't believe that this
is correctly stated in the text. Suggest: "Therefore, the message
digest is computed using the entirety 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 DER 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 DER encoded AuthentiCode signing information
Russ
Jim