ietf-smime
[Top] [All Lists]

Re: WG LAST CALL for ESS, MSG and CERT

1998-06-23 23:12:58
Dave:

* CMS draft -05 section 2 contains the paragraph:

    An implementation that conforms to this specification must implement
    the data, signed-data, and enveloped-data content types.  The other
    content types may be implemented if desired.

Since this is an S/MIME conformance requirement, it should be moved
to the MSG draft section 2.4, and removed from CMS.  For editorial
consistency, the real content type names (Data, SignedData, and
EnvelopedData) should be used instead of nicknames with dashes.

Yes, these are the forms needed to implement S/MIME.  However, I do not think
that a CMS implemntation should be required to implment all of the content
types.

The "nicknames with dashes" come from PKCS#7 version 1.5.  It is not a big
dela
to remove these names, but we should consider the origin before we make this
decision.

* CMS section 3 says:

    The Cryptographic Message Syntax associates a protection content
    type with a protection content.  The syntax shall have ASN.1 type
    ContentInfo:

In cases where no other means of identifying the protection content
type is available (as is the case with S/MIME), ContentInfo is used to
identify the type of outer content.  However, when CMS is used inside a
layered protocol (such as X.411), the enclosing protocol will include a
content type identifier as part of it's own syntax, and the
encapsulated content would be a SignedData, EnvelopedData, ... item,
not a ContentInfo item.

PKCS#7 v1.5 only exports one type ContentInfo.  CMS is doing the same.

It is ambiguous whether CMS contains any IETF conformance requirements.
It doesn't have any capitalized MUSTs, SHOULDs or MAYs, but the word
"shall" might be construed as a conformance requirement.  The paragraph
above should be replaced with the following to remove the ambiguity:

    The Cryptographic Message Syntax defines the ASN.1 type ContentInfo,
    which associates a protection content type with a protection
    content.  ContentInfo may be used as the top-level CMS structure,
    or it may be omitted if the encapsulating environment provides
    a method of identifying the CMS content type.

Does adding this to section 2 help?
The Cryptographic Message Syntax (CMS) is general enough to support many
different content types.  This document defines one protection content,
ContentInfo.  ContentInfo encapsulates one or more protection content type. 
This document defines six content types: data, signed-data, enveloped-data,
digested-data, encrypted-data, and authenticated-data.  Additional content
types can be defined outside this document. 
* CMS section 4 says:>
    The data content type is intended to refer to arbitrary octet
    strings, such as ASCII text files; the interpretation is left to
    the application.  Such strings need not have any internal structure
    (although they could have their own ASN.1 definition or other
    structure).

    The data content type is generally used in conjunction with the
    signed-data, enveloped-data, digested-data, encrypted-data, and
    authenticated-data protection content types.  The data content
    type is encapsulated in one of these protection content types.

S/MIME (MSG section 2.4.1) requires that id-data be used to identify
the inner content.  However, other protocols which reference CMS may
wish to use a more specific type identifier.  CMS should explicitly
allow this possibility:

    The data content type is intended to refer to arbitrary octet
    strings of unspecified type; the interpretation is left to
    the application.  Such strings could be ASCII text files with
    no internal structure, or they could be MIME entities, ASN.1
    types, or other structured objects.

    The data content type is generally used in conjunction with the
    signed-data, enveloped-data, digested-data, encrypted-data, and
    authenticated-data protection content types.  The data content
    type is encapsulated in one of these protection content types.
    Object identifiers other than id-data may be used to identify
    the specific type of encapsulated content, but such usage is
    outside the scope of this specification.

Agree.

Russ