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

["Jim Schaad" <[e-mail]>]

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