Re: Comments on draft-ietf-smime-rfc2630bis-03

["Housley, Russ" <[e-mail]>]

Jim:

>1.  The comment I had for section 3 was for
>
>id-ct-contentInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2)
>      us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
>      content-types(1) 6}
>
>Not for id-contentType.  (This has come to you privately but not on the
>list.)

I have already fixed it in the yet-to-be-published rfc2630bis-04.  I expect 
to release -04 later this week (hopefully this afternoon).

>2.  Section 5.2.1.  I don't follow the reasoning behind putting this
>section in the document.  If the issue is to allow for the processing of
>PKCS#7 item, then I think that information is lacking (specifically the
>fact that "content" MUST be DER encoded).  At present it only allows for
>parsing of the content, in some cases.  (Note that my guess is that the
>current MSFT code would fail if the OID corresponded to an OCTET STRING
>as it would not be able to guess which way to go.)  A better way of
>doing the guessing is really to say that you look to see if you have an
>OCTET STRING and assume you will have a CMS rather than a PKCS#7 object.
>The problem with your current method is there is nothing to stop
>somebody from creating a CMS signed data object using the same embedded
>content (but OCTET wrapped).

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.

    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


>3.  I think it is time to remove the [** NEW **] and [** OLD **]
>comments so we can see a true draft for last call.

Okay.  I will do that before I publish -04.

The WG Last Call is already in progress.  I will expend the deadline once 
the -04 draft is published.  I would expect it to close next week.

Russ