John,
The CMS spec does not limit the value of signedData encapContentInfo
eContentType or envelopedData encryptedContentInfo contentType to be
id-data. The S/MIME message spec does make that limitation because it
specifies how to use CMS with MIME. In fact, there have already been
discussions of using CMS to protect X.400 messages. In that case, the
signedData encapContentInfo eContentType or envelopedData
encryptedContentInfo contentType could be the P2, P22 or P772 OID (or
other). A separate document needs to be written specifying how CMS and ESS
will be used with X.400. IMHO, this is out of scope for the S/MIME WG since
the charter states "MIME encapsulation".
I respectfully disagree with your proposal for
ProtectedInformationTypeAttribute. I believe that the signedData
encapContentInfo eContentType and envelopedData encryptedContentInfo
contentType OBJECT IDENTIFIER fields provides sufficient information to
identify the content. There is no need to specify a complicated ASN.1
syntax to define the various flavors of message. Organizations can define
OIDs to provide the desired level of granularity.
In summary, I beleive that contentHints should be left as is.
================================
John Pawling, jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
www.jgvandyke.com
================================