Subject: rfc2630bis-03 Comment

From: "Pawling, John" <[email-masked]>
Date: Wed, 5 Sep 2001 15:10:04 -0400

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, [email-masked]
Getronics Government Solutions, LLC
===========================================

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 06 Sep 2001 11:02:17 -0400

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:

    The CMS defines eContent as:

    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