ietf-smime
[Top] [All Lists]

RE: Input to content-encryption process in CMS

2003-05-21 14:14:34

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: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org 
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of 
luciano(_dot_)medina(_at_)safelayer(_dot_)com
Sent: Wednesday, May 21, 2003 10:01 AM
To: ietf-smime(_at_)imc(_dot_)org
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:
      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.




<Prev in Thread] Current Thread [Next in Thread>