RE: Input to content-encryption process in CMS

"Jim Schaad" <jimsch@nwlink.com> Wed, 21 May 2003 21:44 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09902 for <smime-archive@lists.ietf.org>; Wed, 21 May 2003 17:44:23 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4LLEYAF056080 for <ietf-smime-bks@above.proper.com>; Wed, 21 May 2003 14:14:34 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h4LLEYPN056079 for ietf-smime-bks; Wed, 21 May 2003 14:14:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h4LLEWAF056073 for <ietf-smime@imc.org>; Wed, 21 May 2003 14:14:32 -0700 (PDT) (envelope-from jimsch@nwlink.com)
Received: from ROMANS (ip146.126-173-207.eli-du.nwlink.com [207.173.126.146]) by smtp4.pacifier.net (Postfix) with ESMTP id E8C936A65B; Wed, 21 May 2003 13:54:19 -0700 (PDT)
Reply-To: jimsch@exmsft.com
From: Jim Schaad <jimsch@nwlink.com>
To: luciano.medina@safelayer.com, ietf-smime@imc.org
Subject: RE: Input to content-encryption process in CMS
Date: Wed, 21 May 2003 14:14:32 -0700
Message-ID: <002901c31fdd$fb30f8f0$927eadcf@soaringhawk.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <OF05CB5048.BA32C3EC-ONC1256D2D.00557D54@safelayer.com>
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

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