Re: [smime] PKCS#7 v1.5 vs. CMS / ContentInfo vs. EncapsulatedContentInfo based on version

mrex@sap.com (Martin Rex) Fri, 03 November 2017 17:01 UTC

Return-Path: <mrex@sap.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 73ACF13FAED for <smime@ietfa.amsl.com>; Fri, 3 Nov 2017 10:01:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level:
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 vNJoPucwxENm for <smime@ietfa.amsl.com>; Fri, 3 Nov 2017 10:01:30 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 301A113FEDD for <smime@ietf.org>; Fri, 3 Nov 2017 10:01:30 -0700 (PDT)
Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3yT7X84dN7z1JWf; Fri, 3 Nov 2017 18:01:28 +0100 (CET)
X-purgate-ID: 152705::1509728488-0000088F-9F21365B/0/0
X-purgate-size: 5034
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3yT7X82K4wzGpGn; Fri, 3 Nov 2017 18:01:28 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 4300D404B; Fri, 3 Nov 2017 18:01:28 +0100 (CET)
In-Reply-To: <EC7CC580-B1A8-4BC2-BF87-B0ACFBB5C8CD@vigilsec.com>
References: <20171103160451.AD0DB404B@ld9781.wdf.sap.corp> <EC7CC580-B1A8-4BC2-BF87-B0ACFBB5C8CD@vigilsec.com>
To: Russ Housley <housley@vigilsec.com>
Date: Fri, 3 Nov 2017 18:01:28 +0100 (CET)
CC: mrex@sap.com, IETF SMIME <smime@ietf.org>
Reply-To: mrex@sap.com
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20171103170128.4300D404B@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <https://mailarchive.ietf.org/arch/msg/smime/-mVL2pYk8GVbW6rvO0qDMDExUgw>
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 17:01:33 -0000

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
>