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.
I can see the logic in this. Let CMS just define the objects (not just for
S/MIME), and MSG define which must be supported for S/MIME.
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.
That could be true, but doing so would certainly hurt interchangability of
data with S/MIME. If the WG wants to go with this change, I would still
like to see a sentence or two in the CMS draft saying that S/MIME requires
a ContentInfo and other specs that want to not use ContentInfo should think
twice.
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.
Boy, you hit half a dozen things there. There is no such thing as an "IETF
conformance requirement". You can claim conformance to a particular RFC,
but that has nothing to do with the IETF. Because CMS doesn't reference RFC
2119, there is no definition of MUST/SHALL or SHOULD or MAY, and I think
that's fine. The "shalls" mean "need to do this for consistency" or "need
to do this for security".
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:
I can buy this, again with the same caveat from above, that we say what
S/MIME is doing to help other implementors make their data more easily
interchange with S/MIME.
--Paul Hoffman, Director
--Internet Mail Consortium