The following comments relate to the use of CMS in non-S/MIME
environments:
* 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.
* 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.
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.
* 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.