Russ,
1. The comment I had for section 3 was for
id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
content-types(1) 6}
Not for id-contentType. (This has come to you privately but not on the
list.)
2. Section 5.2.1. I don't follow the reasoning behind putting this
section in the document. If the issue is to allow for the processing of
PKCS#7 item, then I think that information is lacking (specifically the
fact that "content" MUST be DER encoded). At present it only allows for
parsing of the content, in some cases. (Note that my guess is that the
current MSFT code would fail if the OID corresponded to an OCTET STRING
as it would not be able to guess which way to go.) A better way of
doing the guessing is really to say that you look to see if you have an
OCTET STRING and assume you will have a CMS rather than a PKCS#7 object.
The problem with your current method is there is nothing to stop
somebody from creating a CMS signed data object using the same embedded
content (but OCTET wrapped).
3. I think it is time to remove the [** NEW **] and [** OLD **]
comments so we can see a true draft for last call.
Jim