Subject: Input to content-encryption process in CMS

From: [email-masked]
Date: Wed, 21 May 2003 19:00:49 +0200

In section 6.3 "Content-encryption Process" of obsolete RFC 2630
"Cryptographic Message Syntax (CMS)", the second paragraph describes the
input to the content-encryption process. It is resumed in the sentence:
    The input to the content-encryption process is the "value" of the
content being enveloped

There was some discussion on this topic between Russ Housley and John
Pawling on the mailing list. The latter wrote:
      29) Section 6.3, para 2:  You want to preserve the following
sentence: "The
      input to the content-encryption process is the "value" of the content
being
      enveloped."  In my opinion, this sentence is not needed and is
confusing.
      For example, when encrypting an ASN.1 encoded content, an implementer
might
      interpret this statement to mean that the tag and length octets of
the ASN.1
      encoded content should not be encrypted.  I still believe that the
first
      paragraph is fine [..] and that the second paragraph should be
deleted.

Finally, the second paragraph of section 6.3 was removed in the new RFC
3369, and no mention to the input of the content-encryption process
remains.

From John's words, I understand that if we want to nest a SignedData into
an EnvelopedData, we shall encrypt the whole BER encoded SignedData
(including tag and length octets). This is incompatible with PKCS#7 (RFC
2315), where it is clearly stated that only the content octets of the BER
encoding are encrypted.
I need to be sure that this is the intended meaning, because there is a
whole section (5.2.1) in RFC 3369 explaining the incompatibility of
SignedData in CMS and PKCS#7, but nothing is said about the incompatibility
of encrypted contents.

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 21 May 2003 14:14:32 -0700

This is correct.  Examine section 5.2.1 in RFC 3369 for the difference
in how content is encrypted between PKCS #7 and CMS.  Note that these
changes never affected S/MIME since there is always a MIME wrapper
between the two layers.

jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Wednesday, May 21, 2003 10:01 AM
> To: [email-masked]
> Subject: Input to content-encryption process in CMS
> 
> 
> 
> In section 6.3 "Content-encryption Process" of obsolete RFC 
> 2630 "Cryptographic Message Syntax (CMS)", the second 
> paragraph describes the input to the content-encryption 
> process. It is resumed in the sentence:
>     The input to the content-encryption process is the 
> "value" of the content being enveloped
> 
> There was some discussion on this topic between Russ Housley 
> and John Pawling on the mailing list. The latter wrote:
>       input to the content-encryption process is the "value" 
> of the content being
>       enveloped."  In my opinion, this sentence is not needed 
> and is confusing.
>       For example, when encrypting an ASN.1 encoded content, 
> an implementer might
>       interpret this statement to mean that the tag and 
> length octets of the ASN.1
>       encoded content should not be encrypted.  I still 
> believe that the first
>       paragraph is fine [..] and that the second paragraph 
> should be deleted.
> 
> Finally, the second paragraph of section 6.3 was removed in 
> the new RFC 3369, and no mention to the input of the 
> content-encryption process remains.
> 
> From John's words, I understand that if we want to nest a 
> SignedData into an EnvelopedData, we shall encrypt the whole 
> BER encoded SignedData (including tag and length octets). 
> This is incompatible with PKCS#7 (RFC 2315), where it is 
> clearly stated that only the content octets of the BER 
> encoding are encrypted. I need to be sure that this is the 
> intended meaning, because there is a whole section (5.2.1) in 
> RFC 3369 explaining the incompatibility of SignedData in CMS 
> and PKCS#7, but nothing is said about the incompatibility of 
> encrypted contents.
> 
>