Subject: Ambiguity for EnvelopedData and PKCS#7

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Wed, 21 Oct 1998 13:24:31 -0700

At Microsoft we appear to have run into a problem with an ambiguity in the
PKCS#7 documents and how we implemented the wrapping of non id-data in an
EnvelopedData structure.

The text from PKCS #7 on the Content-encryption process is:

"The input to the content-encryption process is the "value" of the content
being enveloped. Specifically, the input is the contents octets of a
definite-length BER encoding of the content field of the ContentInfo value
to which the enveloping process is applied. Only the contents octets of the
BER encoding are encrypted, not the identifier octets or length octets;
those other octets are not represented at all.
When the content being enveloped has content type data, then just the value
of the data (e.g., the contents of a file) is encrypted. This has the
advantage that the length of the content being encrypted need not be known
in advance of the encryption process. This method is compatible with
Privacy-Enhanced Mail.
The identifier octets and the length octets are not encrypted. The length
octets may be protected implicitly by the encryption process, depending on
the encryption algorithm. The identifier octets are not protected at all,
although they can be recovered from the content type, assuming that the
content type uniquely determines the identifier octets. Explicit protection
of the identifier and length octets requires that the
signed-and-enveloped-data content type be employed, or that the
digested-data and enveloped-data content types be applied in succession."
The problem here is that one reading of the text appears to imply that, for
non id-data, the identifier and length octets of the item to be encoded
should be striped PRIOR to the encryption and result of the encryption
placed into the EncryptedContent.  Unfortionately, it appears that Microsoft
interperated this way and has shipped product like this.  It is not clear at
this point if this is being used by callers of our APIs, but the normal
method of doing Enveloped(Signed(id-data)) appears to imply that this is
what should be done (i.e. no id-data wrapping between the Enveloped and the
Signed).
In order to prevent (save?) ourselfs from this problem, I propose the
following change to CMS
    version is the syntax version number. If originatorInfo is present, then
version shall be 2. <new> If the contentType is not id-data, then version
shall be 2.<end> If any of the RecipientInfo structures included have a
version other than 0, then the version shall be 2.  If originatorInfo is
absent<new>, the contentType is id-data<end> and all of the RecipientInfo
structures are version 0, then version shall be 0.