Russ,
Recommend that CMS Section 4 should be replaced with the following text:
"4 Data Content Type
The data content type is identified by the following object
identifier:
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }
The presence of id-data in signedData SignedContentInfo->sigContentType
indicates that the sigContent OCTET STRING is present and includes
arbitrary data.
The presence of id-data in ContentInfo->contentType
indicates that the content field is present and is defined
as an OCTET STRING including arbitrary data.
In both cases, the presence of id-data indicates that the
OCTET STRING includes arbitrary data, such as ASCII text files;
the interpretation is left to the application. Such data need
not have any internal structure (although it may;
it could even include DER encoded ASN.1 objects)."
- John Pawling
At 09:06 PM 2/1/98 -0500, Russ Housley wrote:
I am working on the text for the next draft already...
I have not figured out what to do with the section on the Data content
type. The OID is still needed...
Russ
At 06:53 PM 1/30/98 -0500, John Pawling wrote:
All,
I believe that CMS should mandate the strategy that was agreed to at San
Francisco as follows:
"Proposal #2: Change the CMS SignedData contentInfo field to be
signedContentInfo defined as follows:
SignedContentInfo ::= SEQUENCE {
sigContentType ContentType,
sigContent [0] EXPLICIT OCTET STRING OPTIONAL}
It is proposed that the CMS Section 5.3 will be changed so that the
digesting rules are consistent for all types of data that is signed (i.e.
the rules for digesting the Data content type will be extended to all types
of data)."
- John Pawling