Thanks for that clarification, that helps as far as understanding how CMS
and ESS can be used with repect to X.400. But you should at least change
the name of ContentHints to someting more meaningfull.
From: John Pawling <jsp(_at_)jgvandyke(_dot_)com>
To: John Ross <ross(_at_)jgross(_dot_)demon(_dot_)co(_dot_)uk>; Ietf
Date: Friday, March 27, 1998 6:14 AM
Subject: Re: protected content
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
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.