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


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 expectto 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 JohnPawling. This is one place where backward comparability with PKCS#7 hasnot been preserved, and we are trying to warn implementors about thepotential dangers.

You make a good point about DER. I have made a few changes to the text tohighlight 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 oncethe -04 draft is published. I would expect it to close next week.


Russ