Re: [smime] PKCS#7 v1.5 vs. CMS / ContentInfo vs. EncapsulatedContentInfo based on version
Russ Housley <housley@vigilsec.com> Fri, 03 November 2017 18:30 UTC
Return-Path: <housley@vigilsec.com>
X-Original-To: smime@ietfa.amsl.com
Delivered-To: smime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5AC13FF37 for <smime@ietfa.amsl.com>; Fri, 3 Nov 2017 11:30:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aowLSLKRwRUn for <smime@ietfa.amsl.com>; Fri, 3 Nov 2017 11:30:41 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A6713FF36 for <smime@ietf.org>; Fri, 3 Nov 2017 11:30:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DD9123005D0 for <smime@ietf.org>; Fri, 3 Nov 2017 14:30:40 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id lnAUxcMNUxaD for <smime@ietf.org>; Fri, 3 Nov 2017 14:30:39 -0400 (EDT)
Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 649F1300250; Fri, 3 Nov 2017 14:30:38 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <20171103170128.4300D404B@ld9781.wdf.sap.corp>
Date: Fri, 03 Nov 2017 14:30:36 -0400
Cc: IETF SMIME <smime@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B09D3F90-A6AC-4BC7-96EC-10A8C34BCE8F@vigilsec.com>
References: <20171103160451.AD0DB404B@ld9781.wdf.sap.corp> <EC7CC580-B1A8-4BC2-BF87-B0ACFBB5C8CD@vigilsec.com> <20171103170128.4300D404B@ld9781.wdf.sap.corp>
To: Martin Rex <mrex@sap.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/smime/epVugwo3UQ8SSGttUcLMWXlHBnA>
Subject: Re: [smime] PKCS#7 v1.5 vs. CMS / ContentInfo vs. EncapsulatedContentInfo based on version
X-BeenThere: smime@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SMIME Working Group <smime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/smime>, <mailto:smime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/smime/>
List-Post: <mailto:smime@ietf.org>
List-Help: <mailto:smime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/smime>, <mailto:smime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2017 18:30:43 -0000
As Jim already said, that is not the point of the version number. The point is to avoid decode errors. Russ > On Nov 3, 2017, at 1:01 PM, Martin Rex <mrex@sap.com> wrote: > > Russ, > > It seems I wasn't sufficiently clear. > > This is about a third-party specification refering to CMS/rfc5652. > > That organization specifically refers to SignedData structure and > members as defined in section 5.1 of RFC 5652, it quotes that structure > definition, and describes contents for the structure elements. > > For the version element, since they _not_ doing any of the fancy > stuff, they came up with "version=1" from the pseudo-code. > > > https://tools.ietf.org/html/rfc5652#section-5.1 > > 5.1. SignedData Type > > The following object identifier identifies the signed-data content > type: > > id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2) > us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } > > The signed-data content type shall have ASN.1 type SignedData: > > SignedData ::= SEQUENCE { > version CMSVersion, > digestAlgorithms DigestAlgorithmIdentifiers, > encapContentInfo EncapsulatedContentInfo, > certificates [0] IMPLICIT CertificateSet OPTIONAL, > crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, > signerInfos SignerInfos } > > DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier > > SignerInfos ::= SET OF SignerInfo > > > However, the use of version=1 would IMHO imply the use of the original > PKCS#7 v1.5 structure instead: > > https://tools.ietf.org/html/rfc2315#section-9.1 > > and more specifically, the use of the original PKCS#7 v1.5 ContentInfo rather > than the CMS version 3 EncapsulatedContentInfo. > > > The organization is currently assuming that CMS (rfc5652) would suggest > combining "version=1" with CMS 3+ SignedData with EncapsulatedContentInfo. > > To me, this looks "underspecified". I.e. rfc5652 section 5.1 fails to > describe what exactly version=1 means for the ContentInfo vs. > EncapsulatedContentInfo encoding of SignedData. > > -Martin > > > Russ Housley <housley@vigilsec.com> wrote: >> The version is structure in this manner so that an implementation >> that checks the version number and then does a decode will never >> get a decode error on a properly constructed message. >> >> If the only changes are (migrate from PKCS#1 v1.5 to RSA-PSS) and >> (migrate from PKCS#1 v1.5 to PRS-OAEP), then the change should be >> very straightforward. >> >> If you are not using any version 1 attribute certificates, identifying >> the signer with the subject public key identifier, or using a content >> type other than id-data, then the version for Signed-Data should not change. >> >> I am assuming that you are not mixing RSA-OAEP with other key management >> algorithms. If you are not using unprotect attributes or identifying >> the signer with the subject public key identifier, then the version >> number for Enveloped-Data should not change. > > > >> >>> On Nov 3, 2017, at 12:04 PM, Martin Rex <mrex@sap.com> wrote: >>> >>> There is a somewhat confusing ruleset around the "SignedData" PDU >>> version field in the CMS specification, and insufficient guidance >>> about the ramifications for the Encoder/Decoder for ContentInfo >>> when version 1 vs. 3 is chosen. >>> >>> The organization responsible for certain legally mandated data exchanges >>> in Germany is rev'ving their requirements, intoducing RSA-PSS signatures >>> on certificates plus RSA-OAEP encryption for AppData. >>> >>> Previously, they've been using PKCS#7 v1.5 PDUs with RSA PKCS#1 v1.5 >>> transforms. >>> >>> The confusion I'm seeing is about the choice of the SignedData "version" >>> field, and the resulting consequences for the (ASN.1) PDU encoder/decoder >>> for the ContentInfo vs. EncapsulatedContentInfo in SignedData. >>> >>> >>> For the encoder/decoder, the reasonable interpretation would be, >>> that whenever version=1, then the PKCS#7 ContentInfo encoding will be >>> used, and only for version>=3, the CMS EncapsulatedContentInfo encoding >>> will be encoded or decoded. >>> >>> >>> However the current reading of the CMS standard by that organization is >>> that they want to specify version=1 in combination with EncapsulatedContentInfo >>> encoding -- something that looks extremely weird to me, and would require >>> significant contortions in the ASN.1 encoder and decoder. >>> >>> For the encoder, it will require a laying violation from within the encoder, >>> looking at later elements and semantics of higher level PDUs. >>> >>> For the decoder, it essentially will require heuristics (trial-and-error) >>> decoding if the PDU version will no longer matter, and the data determining >>> which encoding is appropriate, has not been decoded yet at this point >>> requiring a retroactive verification of whether the heuristically determined >>> encoding was actually a _valid_ encoding. >>> >>> >>> Any comments from folks more experienced with CMS ? >>> >>> -Martin >>> >>> _______________________________________________ >>> smime mailing list >>> smime@ietf.org >>> https://www.ietf.org/mailman/listinfo/smime >>
- [smime] PKCS#7 v1.5 vs. CMS / ContentInfo vs. Enc… Martin Rex
- Re: [smime] PKCS#7 v1.5 vs. CMS / ContentInfo vs.… Russ Housley
- Re: [smime] PKCS#7 v1.5 vs. CMS / ContentInfo vs.… Martin Rex
- Re: [smime] PKCS#7 v1.5 vs. CMS / ContentInfo vs.… Jim Schaad
- Re: [smime] PKCS#7 v1.5 vs. CMS / ContentInfo vs.… Russ Housley
- Re: [smime] PKCS#7 v1.5 vs. CMS / ContentInfo vs.… Martin Rex
- Re: [smime] PKCS#7 v1.5 vs. CMS / ContentInfo vs.… Jim Schaad