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. > >
- Input to content-encryption process in CMS luciano.medina
- RE: Input to content-encryption process in CMS Jim Schaad