From Juraj.Hajek@ardaco.com Fri Nov 3 03:10:00 2017 Return-Path: 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 D387A13FD4B for ; Fri, 3 Nov 2017 03:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, 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 0pSwkOKstbsG for ; Fri, 3 Nov 2017 03:09:58 -0700 (PDT) Received: from xsi.ardaco.com (xsi.ardaco.com [90.176.8.103]) by ietfa.amsl.com (Postfix) with ESMTP id EBCD613FD3E for ; Fri, 3 Nov 2017 03:09:57 -0700 (PDT) Received: from XSI.ardaco.local (10.0.0.66) by XSI.ardaco.local (10.0.0.66) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Fri, 3 Nov 2017 11:09:54 +0100 Received: from XSI.ardaco.local ([::1]) by XSI.ardaco.local ([::1]) with mapi id 15.00.1293.004; Fri, 3 Nov 2017 11:09:54 +0100 From: "Hajek, Juraj" To: "smime@ietf.org" Thread-Topic: RFC3125: Question - CertInfoReq fullPath Thread-Index: AdNT4+iFLs2Ns6S0Qz2BTL/bzmrqigAp+NgQ Date: Fri, 3 Nov 2017 10:09:54 +0000 Message-ID: References: <73d57ce76d7a43b38666557558a5d9a7@XSI.ardaco.local> In-Reply-To: <73d57ce76d7a43b38666557558a5d9a7@XSI.ardaco.local> Accept-Language: sk-SK, en-US Content-Language: sk-SK X-MS-Has-Attach: X-MS-TNEF-Correlator: x-oldmsgid: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.0.0.182] x-gfi-smtp-submission: 1 x-gfi-smtp-hellodomain: XSI.ardaco.local x-gfi-smtp-remoteip: 10.0.0.66 Content-Type: multipart/alternative; boundary="_000_e80f72fa03ee41efb9c8a3bcf396be44XSIardacolocal_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 03 Nov 2017 08:31:28 -0700 Subject: Re: [smime] RFC3125: Question - CertInfoReq fullPath X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 10:13:51 -0000 --_000_e80f72fa03ee41efb9c8a3bcf396be44XSIardacolocal_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hello, we are not sure about the interpretation of the following sentence in RFC31= 25 (https://datatracker.ietf.org/doc/rfc3125/?include_text=3D1). CertRefReq and CertInfoReq, p.9 "References for full cert path up to a trust point required" Does it mean that the trust point should be included or excluded in the pa= th? Thank you very much. Best regards, Juraj H=E1jek Project Manager Ardaco, a.s. --_000_e80f72fa03ee41efb9c8a3bcf396be44XSIardacolocal_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hello,

we are not sure about the inter= pretation of the following sentence in RFC3125 (https:= //datatracker.ietf.org/doc/rfc3125/?include_text=3D1).

CertRefReq and CertInfoReq, p.9

“References for full c= ert path up to a trust point required”

Does it mean that the trust point should be in= cluded or excluded in the path?

Thank you very much.

Best regards= ,

<= /o:p>

Juraj H=E1je= k

Project Mana= ger

<= /o:p>

Ardaco, a.s.=

--_000_e80f72fa03ee41efb9c8a3bcf396be44XSIardacolocal_-- From nobody Fri Nov 3 09:04:58 2017 Return-Path: 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 2539B13FECA for ; Fri, 3 Nov 2017 09:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 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] 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 WSBi7ZhrKZOm for ; Fri, 3 Nov 2017 09:04:53 -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 8C76713FEB5 for ; Fri, 3 Nov 2017 09:04:53 -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 3yT6Gq5wF5z1Hht for ; Fri, 3 Nov 2017 17:04:51 +0100 (CET) X-purgate-ID: 152705::1509725091-000040CA-D290D0B2/0/0 X-purgate-size: 1829 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 3yT6Gq5KQ7zGpYk for ; Fri, 3 Nov 2017 17:04:51 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id AD0DB404B; Fri, 3 Nov 2017 17:04:51 +0100 (CET) To: smime@ietf.org Date: Fri, 3 Nov 2017 17:04:51 +0100 (CET) Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20171103160451.AD0DB404B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 16:04:57 -0000 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 From nobody Fri Nov 3 09:26:57 2017 Return-Path: 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 E20AC13FEE6 for ; Fri, 3 Nov 2017 09:26:51 -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 Q3YvULpUDYZM for ; Fri, 3 Nov 2017 09:26:48 -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 15DA213FEE0 for ; Fri, 3 Nov 2017 09:26:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 629913005D6 for ; Fri, 3 Nov 2017 12:26:47 -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 4L-CEJTLHSI1 for ; Fri, 3 Nov 2017 12:26:45 -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 6FF8D300541; Fri, 3 Nov 2017 12:26:45 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 $3273$) From: Russ Housley In-Reply-To: <20171103160451.AD0DB404B@ld9781.wdf.sap.corp> Date: Fri, 3 Nov 2017 12:26:45 -0400 Cc: IETF SMIME Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171103160451.AD0DB404B@ld9781.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.3273) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 16:26:52 -0000 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. Russ > On Nov 3, 2017, at 12:04 PM, Martin Rex wrote: >=20 > 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. >=20 > 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. >=20 > Previously, they've been using PKCS#7 v1.5 PDUs with RSA PKCS#1 v1.5 > transforms. >=20 > 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. >=20 >=20 > For the encoder/decoder, the reasonable interpretation would be, > that whenever version=3D1, then the PKCS#7 ContentInfo encoding will = be > used, and only for version>=3D3, the CMS EncapsulatedContentInfo = encoding > will be encoded or decoded. >=20 >=20 > However the current reading of the CMS standard by that organization = is > that they want to specify version=3D1 in combination with = EncapsulatedContentInfo > encoding -- something that looks extremely weird to me, and would = require > significant contortions in the ASN.1 encoder and decoder. >=20 > For the encoder, it will require a laying violation from within the = encoder, > looking at later elements and semantics of higher level PDUs. >=20 > 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. >=20 >=20 > Any comments from folks more experienced with CMS ? >=20 > -Martin >=20 > _______________________________________________ > smime mailing list > smime@ietf.org > https://www.ietf.org/mailman/listinfo/smime From nobody Fri Nov 3 10:01:35 2017 Return-Path: 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 ; 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 ; 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 ; 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: References: <20171103160451.AD0DB404B@ld9781.wdf.sap.corp> To: Russ Housley Date: Fri, 3 Nov 2017 18:01:28 +0100 (CET) CC: mrex@sap.com, IETF SMIME 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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 > From nobody Fri Nov 3 11:08:29 2017 Return-Path: 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 D6AAF13FF26 for ; Fri, 3 Nov 2017 11:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com 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 famJqVajNiQa for ; Fri, 3 Nov 2017 11:08:26 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6714213FF24 for ; Fri, 3 Nov 2017 11:08:26 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01D35494.0E97AAB0" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1509732503; h=from:subject:to:date:message-id; bh=SQRMhMjXCjojmKCMK2aLLuT9WL7rNMfolo4fU1qG9oY=; b=VqFFwNtIA+kkn+oz8gGoogyIqzTzAJYxPemiVYXCCn4tCg+lXWyg6BB5BgKre1cmdcMk8h5dnzy Qgwb1BS8PwX0sQsZSlZF3YIXFd+E5S/Qvl38fy2+IyhncC8pTix5iarb6im2NB1qVpYIQ0T4k0dtm 5crrfJpAZFSew6c2WY6T493o0Zvf67I+f0ovRaEYg33Wm9GbNwd8nG37trloL1GgPnWCaUpBBiMzX 7KpMhxR306Ka3gEW+uu6B8HIlAickHTzRv2q6oOMZPSepJAXerrRuH4k4vIJd0G2/pa2j7mg5fMLW HGqchfwsVnEfXo3uUyAnDCTUp2jYjfXTrgjw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 3 Nov 2017 11:08:22 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 3 Nov 2017 11:07:19 -0700 From: Jim Schaad To: "'Hajek, Juraj'" , References: <73d57ce76d7a43b38666557558a5d9a7@XSI.ardaco.local> In-Reply-To: Date: Fri, 3 Nov 2017 11:08:17 -0700 Message-ID: <000c01d354ce$baf32750$30d975f0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQDlC+65FtxNHzNwXhyqg5MngOp/SAKSb5TjpMrx3XA= X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [smime] RFC3125: Question - CertInfoReq fullPath X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 18:08:28 -0000 ------=_NextPart_000_000D_01D35494.0E97AAB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Normally one would presume that the trust point is shared and thus can = be excluded from the path. I do not believe that a problem would exist if = a reference to the trust point existed, as long as that did not constitute = a trust decision. =20 Jim =20 =20 From: smime [mailto:smime-bounces@ietf.org] On Behalf Of Hajek, Juraj Sent: Friday, November 3, 2017 3:10 AM To: smime@ietf.org Subject: Re: [smime] RFC3125: Question - CertInfoReq fullPath =20 Hello, =20 we are not sure about the interpretation of the following sentence in RFC3125 (https://datatracker.ietf.org/doc/rfc3125/?include_text=3D1). =20 CertRefReq and CertInfoReq, p.9 =93References for full cert path up to a trust point required=94 =20 Does it mean that the trust point should be included or excluded in the path? =20 Thank you very much. =20 Best regards, =20 Juraj H=E1jek Project Manager =20 Ardaco, a.s. =20 ------=_NextPart_000_000D_01D35494.0E97AAB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Normally one would presume that the trust point is = shared and thus can be excluded from the path.=A0 I do not believe that = a problem would exist if a reference to the trust point existed, as long = as that did not constitute a trust decision.

Jim

From: smime = [mailto:smime-bounces@ietf.org] On Behalf Of Hajek, = Juraj
Sent: Friday, November 3, 2017 3:10 AM
To: = smime@ietf.org
Subject: Re: [smime] RFC3125: Question - = CertInfoReq fullPath

Hello,

we are not = sure about the interpretation of the following sentence in RFC3125 = (https= ://datatracker.ietf.org/doc/rfc3125/?include_text=3D1).

CertRefReq and CertInfoReq, p.9

“References for full cert path up to a trust = point required”

Does it mean that the trust point should be included or = excluded in the path?

Thank you very much.

Best = regards,

Juraj H=E1jek

Project = Manager

Ardaco, a.s.

------=_NextPart_000_000D_01D35494.0E97AAB0-- From nobody Fri Nov 3 11:25:33 2017 Return-Path: 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 DACC413FF19 for ; Fri, 3 Nov 2017 11:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com 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 oknLBR3LgdiK for ; Fri, 3 Nov 2017 11:25:29 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 539EF13FD49 for ; Fri, 3 Nov 2017 11:25:28 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1509733526; h=from:subject:to:date:message-id; bh=rTh8cGf5OZ/GqInR0Nz4j0tj3kvqqiSz2lct+PwoMXw=; b=BS/CksscIaLKBrJ6lf4QO7BzFm6nconzuoVWMRJlQfkPl9OpJHLoliFjFWlLNwZH+uugysxStbL zVymdZaDdlWlo/34VsQ7w/xRT/gMmaoqwLSEJYvf2ykrgsLCsGocBTNeyxGpA8Sjbv345MTY4Fq7d jc+K3VbH3TILPVcDWa28mHuds6KyVV+ECbUp6Puosi4aOT5fRNDZcMEV9OWyLVj2rYWRTNBOHCIhw 3riGsLoWYhSdrQNOhB0ZqGe7cH9ESwXskQ2RYL7x+HD8jvkJo81A6gjTuER+i/7FM9X5PzV9gJk5q SF8sz76T3wslWj9B9VAdSuVSGluRoTNNhkyQ== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 3 Nov 2017 11:25:26 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 3 Nov 2017 11:24:22 -0700 From: Jim Schaad To: , References: <20171103160451.AD0DB404B@ld9781.wdf.sap.corp> In-Reply-To: <20171103160451.AD0DB404B@ld9781.wdf.sap.corp> Date: Fri, 3 Nov 2017 11:25:20 -0700 Message-ID: <001101d354d1$1cfdced0$56f96c70$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKF3Wi9cvbMmmnh/4p3vrg5y3Oj2aGd5PeQ X-Originating-IP: [192.168.1.162] Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 18:25:31 -0000 There was never any intent that a version number of one would indicate that this was PKCS#7 rather than CMS. To begin with, this is only a problem if you are looking at wrapping contents other than id-data, for id-data there is no difference. In both cases there is an OCTET wrapper. For things which are not id-data, there is going to be a difference between the two encodings in that for one an octet wrapper is there and for the other case it is not. I would say that you need to look at the content type and the type of the field and then make a decision about what you are doing. I will note that there is a security problem with the PKCS#7 encoding where the content and length bytes are not correctly protected. This is one of the reasons that CMS added the OCTET wrapper in all cases rather than just in the case of id-data. Jim > -----Original Message----- > From: smime [mailto:smime-bounces@ietf.org] On Behalf Of Martin Rex > Sent: Friday, November 3, 2017 9:05 AM > To: smime@ietf.org > Subject: [smime] PKCS#7 v1.5 vs. CMS / ContentInfo vs. > EncapsulatedContentInfo based on version > > 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 From nobody Fri Nov 3 11:30:44 2017 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; 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 In-Reply-To: <20171103170128.4300D404B@ld9781.wdf.sap.corp> Date: Fri, 3 Nov 2017 14:30:36 -0400 Cc: IETF SMIME Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171103160451.AD0DB404B@ld9781.wdf.sap.corp> <20171103170128.4300D404B@ld9781.wdf.sap.corp> To: Martin Rex X-Mailer: Apple Mail (2.3273) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: >=20 > Russ, >=20 > It seems I wasn't sufficiently clear. >=20 > This is about a third-party specification refering to CMS/rfc5652. >=20 > 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. >=20 > For the version element, since they _not_ doing any of the fancy > stuff, they came up with "version=3D1" from the pseudo-code. >=20 >=20 > https://tools.ietf.org/html/rfc5652#section-5.1 >=20 > 5.1. SignedData Type >=20 > The following object identifier identifies the signed-data content > type: >=20 > id-signedData OBJECT IDENTIFIER ::=3D { iso(1) member-body(2) > us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 } >=20 > The signed-data content type shall have ASN.1 type SignedData: >=20 > SignedData ::=3D SEQUENCE { > version CMSVersion, > digestAlgorithms DigestAlgorithmIdentifiers, > encapContentInfo EncapsulatedContentInfo, > certificates [0] IMPLICIT CertificateSet OPTIONAL, > crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, > signerInfos SignerInfos } >=20 > DigestAlgorithmIdentifiers ::=3D SET OF DigestAlgorithmIdentifier >=20 > SignerInfos ::=3D SET OF SignerInfo >=20 >=20 > However, the use of version=3D1 would IMHO imply the use of the = original > PKCS#7 v1.5 structure instead: >=20 > https://tools.ietf.org/html/rfc2315#section-9.1 >=20 > and more specifically, the use of the original PKCS#7 v1.5 ContentInfo = rather > than the CMS version 3 EncapsulatedContentInfo. >=20 >=20 > The organization is currently assuming that CMS (rfc5652) would = suggest > combining "version=3D1" with CMS 3+ SignedData with = EncapsulatedContentInfo. >=20 > To me, this looks "underspecified". I.e. rfc5652 section 5.1 fails to > describe what exactly version=3D1 means for the ContentInfo vs. > EncapsulatedContentInfo encoding of SignedData. >=20 > -Martin >=20 >=20 > Russ Housley 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >=20 >=20 >=20 >>=20 >>> On Nov 3, 2017, at 12:04 PM, Martin Rex wrote: >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Previously, they've been using PKCS#7 v1.5 PDUs with RSA PKCS#1 v1.5 >>> transforms. >>>=20 >>> 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. >>>=20 >>>=20 >>> For the encoder/decoder, the reasonable interpretation would be, >>> that whenever version=3D1, then the PKCS#7 ContentInfo encoding will = be >>> used, and only for version>=3D3, the CMS EncapsulatedContentInfo = encoding >>> will be encoded or decoded. >>>=20 >>>=20 >>> However the current reading of the CMS standard by that organization = is >>> that they want to specify version=3D1 in combination with = EncapsulatedContentInfo >>> encoding -- something that looks extremely weird to me, and would = require >>> significant contortions in the ASN.1 encoder and decoder. >>>=20 >>> For the encoder, it will require a laying violation from within the = encoder, >>> looking at later elements and semantics of higher level PDUs. >>>=20 >>> 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. >>>=20 >>>=20 >>> Any comments from folks more experienced with CMS ? >>>=20 >>> -Martin >>>=20 >>> _______________________________________________ >>> smime mailing list >>> smime@ietf.org >>> https://www.ietf.org/mailman/listinfo/smime >>=20 From nobody Fri Nov 3 14:43:32 2017 Return-Path: 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 9D37513FFE4 for ; Fri, 3 Nov 2017 14:43:31 -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 85vD5yZHW50U for ; Fri, 3 Nov 2017 14:43:29 -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 5C5A213FFE2 for ; Fri, 3 Nov 2017 14:43:29 -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 3yTFnW3NM9z1JWM; Fri, 3 Nov 2017 22:43:27 +0100 (CET) X-purgate-ID: 152705::1509745407-000040CA-1C2519EC/0/0 X-purgate-size: 3643 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 3yTFnW1f8lzGnyb; Fri, 3 Nov 2017 22:43:27 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 2D092404B; Fri, 3 Nov 2017 22:43:27 +0100 (CET) In-Reply-To: <001101d354d1$1cfdced0$56f96c70$@augustcellars.com> References: <20171103160451.AD0DB404B@ld9781.wdf.sap.corp> <001101d354d1$1cfdced0$56f96c70$@augustcellars.com> To: Jim Schaad Date: Fri, 3 Nov 2017 22:43:27 +0100 (CET) CC: mrex@sap.com, 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: <20171103214327.2D092404B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 21:43:32 -0000 Hi Jim, Thanks for the reply, but this leaves me even more confused now. Admittedly my personal implementors experience is tiny. I once patched support for processing rfc3161 TimeStamps into an existing PKCS#7 v1.5 implementation, and I needed a few tweaks for the ASN.1 encoder & decoder -- but rfc3161 uses id-ct-TSTInfo content type and version 3 rather than id-data and version 1, so I needed tweaks for processing of EncapsulatedContentInfo. Jim Schaad wrote: > > To begin with, this is only a problem if you are looking at wrapping > contents other than id-data, for id-data there is no difference. In both > cases there is an OCTET wrapper. This statement looks like a self-contradiction. Either there is _no_ difference between PKCS#7 v1.5 SignedData for id-data, then there is no wrapper. Or there is a difference, and EncapsulatedContentInfo is used. > > For things which are not id-data, there is going to be a difference between > the two encodings in that for one an octet wrapper is there and for the > other case it is not. I would say that you need to look at the content type > and the type of the field and then make a decision about what you are doing. Do you mean that while the PDU encoding for SignedData with id-data ContentInfo is the same for PKCS#7 v1.5 and CMS, the actual signature (or more precisely the hash over that id-data) is computed _differently_ for PKCS#7 v1.5 and CMS (covering the 0x04 plus ASN.1 length field for CMS, and omitting this for PKCS#7 v1.5) ? I wouldn't like a heuristic on decoding because it results in needlessly complex code and seems to have an ambituity for certain id-data that conicidentally matches the beginning of an ASN.1 DER OctetString. But requiring a heuristic on SignedData would be magnitudes worse, because of significantly higher CPU cycles impact for computing and verifying two different hashes. > I will note that there is a security problem with the PKCS#7 encoding where > the content and length bytes are not correctly protected. This is one of > the reasons that CMS added the OCTET wrapper in all cases rather than just > in the case of id-data. But "in all cases rather than just in the case of id-data" is a contradiction to the above (with respect to the encoding). Or is this comment _not_ about the encoding, but rather about the data which gets signed (hashed) ? > > There was never any intent that a version number of one would indicate that > this was PKCS#7 rather than CMS. That sounds wrong to me. At least my copy of PKCS#7 v1.5 (rfc2315) is _explicit_ that this version indicates PDU/protocol, and version==1 therefore implies PKCS#7 (rfc2315) syntax/encoding **AND** processing rules (semantics). https://tools.ietf.org/html/rfc2315#section-9.1 The fields of type SignedData have the following meanings: o version is the syntax version number. It shall be 1 for this version of the document. The PKCS#7 v1.5 PDU was *ALWAYS* supposed to be self-describing, and later revisions of it to identify different syntax as well as different processing rules by using a different version in the PDU. For the particular (governmentally mandated) data exchange scenario in Germany, they're currently using PKCS#7 v1.5 with RSA PKCS#1 v1.5, and they want to transition to using RSA-PSS (signatures on certs and PKCS#7/CMS SignedData) and RSA-OAEP (EvelopedData), with EndEntity certs that carry rsaEncryption keys (so that the keys can be used for both, signature and encryption). -Martin From nobody Fri Nov 3 22:13:24 2017 Return-Path: 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 B8A7813FB42 for ; Fri, 3 Nov 2017 22:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com 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 dotYwQUoz5YC for ; Fri, 3 Nov 2017 22:13:20 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD77913FB37 for ; Fri, 3 Nov 2017 22:13:20 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1509772397; h=from:subject:to:date:message-id; bh=dov93CLIldTAnt99RnNzEUBBb0tNttxwhrUNXEcTSR8=; b=fvpQXpU4afl1xtPXv5HYD/Ahl++vKtAfgVvbXcX6InNtzgA2W+3p/Z9Tabm3VmN4iUFsPw+VdLZ 57ZGYJ736IXeWUXiHXdAJh1z2+fsNJVXQ/OLfpMPPz9xyA63Yar2xc8Q+9ZeUA3wxO3mELACNROSA PmjISVTgD57wQ9HFBHHSqwaGU7TqZDKj9omOF2KWR6PlT0hP9sOitEWf7xlSQ4DXFlyJ0THoMYpZX MnmP+beEtsocrrOUl/WOHFUGzxmkHtWZvmjTnk9LpQX2UXqZeQPWMC7euVAUOoVz8jX9dLOxaEOUd eSnzqzd3EN9kxJy2+m1M4uK33UVWo0AfTOuw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 3 Nov 2017 22:13:16 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 3 Nov 2017 22:12:14 -0700 From: Jim Schaad To: CC: References: <20171103160451.AD0DB404B@ld9781.wdf.sap.corp> <001101d354d1$1cfdced0$56f96c70$@augustcellars.com> <20171103214327.2D092404B@ld9781.wdf.sap.corp> In-Reply-To: <20171103214327.2D092404B@ld9781.wdf.sap.corp> Date: Fri, 3 Nov 2017 22:13:11 -0700 Message-ID: <002a01d3552b$9e1ea700$da5bf500$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKF3Wi9cvbMmmnh/4p3vrg5y3Oj2QJVgjNfAdAjTyqhfW3NoA== X-Originating-IP: [73.180.8.170] Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 05:13:23 -0000 > -----Original Message----- > From: Martin Rex [mailto:mrex@sap.com] > Sent: Friday, November 3, 2017 2:43 PM > To: Jim Schaad > Cc: mrex@sap.com; smime@ietf.org > Subject: Re: [smime] PKCS#7 v1.5 vs. CMS / ContentInfo vs. > EncapsulatedContentInfo based on version > > Hi Jim, > > Thanks for the reply, but this leaves me even more confused now. > > Admittedly my personal implementors experience is tiny. I once patched > support for processing rfc3161 TimeStamps into an existing PKCS#7 v1.5 > implementation, and I needed a few tweaks for the ASN.1 encoder & decoder > -- but rfc3161 uses id-ct-TSTInfo content type and version 3 rather than id-data > and version 1, so I needed tweaks for processing of EncapsulatedContentInfo. > > > Jim Schaad wrote: > > > > To begin with, this is only a problem if you are looking at wrapping > > contents other than id-data, for id-data there is no difference. In > > both cases there is an OCTET wrapper. > > This statement looks like a self-contradiction. Either there is _no_ difference > between PKCS#7 v1.5 SignedData for id-data, then there is no wrapper. Or > there is a difference, and EncapsulatedContentInfo is used. There is zero difference in the bytes outputted by the encoder. For PKCS#7 v1.5 - id-data is defined to be an OCTET STRING - thus the emitted content is an OCTET wrapped data string For CMS - id-data is defined to not have an ASN.1 type - instead the data is directly wrapped by the OCTET wrapper that present in all SignedData objects > > > > > For things which are not id-data, there is going to be a difference > > between the two encodings in that for one an octet wrapper is there > > and for the other case it is not. I would say that you need to look > > at the content type and the type of the field and then make a decision about > what you are doing. > > Do you mean that while the PDU encoding for SignedData with id-data > ContentInfo is the same for PKCS#7 v1.5 and CMS, the actual signature (or > more precisely the hash over that id-data) is computed _differently_ for > PKCS#7 v1.5 and CMS (covering the 0x04 plus ASN.1 length field for CMS, and > omitting this for PKCS#7 v1.5) ? For PKCS #7 v1.5 - the outer ASN.1 length and tag are not included in the signature computation. This means that the exact same set of bytes are going to be hashed for an id-data object. For a non-id-data object, the bytes that would be hashed ARE different. For PKCS #7 v1.5 the tag and length are not included in the signature computation. For CMS the OCTET wrapper is not included, but all of the contents are included. This means that for CMS the tag and length of the data are included in the hash computation. Does this answer your questions? > > I wouldn't like a heuristic on decoding because it results in needlessly complex > code and seems to have an ambituity for certain id-data that conicidentally > matches the beginning of an ASN.1 DER OctetString. > > But requiring a heuristic on SignedData would be magnitudes worse, because > of significantly higher CPU cycles impact for computing and verifying two > different hashes. > > > > I will note that there is a security problem with the PKCS#7 encoding > > where the content and length bytes are not correctly protected. This > > is one of the reasons that CMS added the OCTET wrapper in all cases > > rather than just in the case of id-data. > > But "in all cases rather than just in the case of id-data" is a contradiction to the > above (with respect to the encoding). Or is this comment _not_ about the > encoding, but rather about the data which gets signed (hashed) ? > > > > > > There was never any intent that a version number of one would indicate > > that this was PKCS#7 rather than CMS. > > That sounds wrong to me. At least my copy of PKCS#7 v1.5 > (rfc2315) is _explicit_ that this version indicates PDU/protocol, and > version==1 therefore implies PKCS#7 (rfc2315) syntax/encoding > **AND** processing rules (semantics). > > https://tools.ietf.org/html/rfc2315#section-9.1 > > The fields of type SignedData have the following meanings: > > o version is the syntax version number. It shall be > 1 for this version of the document. > > > The PKCS#7 v1.5 PDU was *ALWAYS* supposed to be self-describing, and later > revisions of it to identify different syntax as well as different processing rules by > using a different version in the PDU. > > > For the particular (governmentally mandated) data exchange scenario in > Germany, they're currently using PKCS#7 v1.5 with RSA PKCS#1 v1.5, and they > want to transition to using RSA-PSS (signatures on certs and PKCS#7/CMS > SignedData) and RSA-OAEP (EvelopedData), with EndEntity certs that carry > rsaEncryption keys (so that the keys can be used for both, signature and > encryption). > > > -Martin From nobody Mon Nov 13 07:16:38 2017 Return-Path: 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 13A91129AD2 for ; Mon, 13 Nov 2017 07:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 H0wX2GSdf7Ix for ; Mon, 13 Nov 2017 07:16:31 -0800 (PST) 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 1337D129AF9 for ; Mon, 13 Nov 2017 07:16:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 79C0F3005A4 for ; Mon, 13 Nov 2017 10:16:08 -0500 (EST) 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 Sj5IYut6oeJH for ; Mon, 13 Nov 2017 10:16:06 -0500 (EST) Received: from [10.5.245.234] (wsip-98-172-24-238.dc.dc.cox.net [98.172.24.238]) by mail.smeinc.net (Postfix) with ESMTPSA id 07E34300435 for ; Mon, 13 Nov 2017 10:16:05 -0500 (EST) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_459A6D90-F745-423A-B117-4BC23D20FC39" Mime-Version: 1.0 (Mac OS X Mail 10.3 $3273$) Message-Id: References: <151058607297.580.10143889052435378840.idtracker@ietfa.amsl.com> To: IETF SMIME Date: Mon, 13 Nov 2017 10:16:08 -0500 X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [smime] Fwd: New Version Notification for draft-housley-cms-mix-with-psk-00.txt X-BeenThere: smime@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SMIME Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 15:16:37 -0000 --Apple-Mail=_459A6D90-F745-423A-B117-4BC23D20FC39 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii People on this list may find this new I-D interesting, Russ > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-housley-cms-mix-with-psk-00.txt > Date: November 13, 2017 at 10:14:32 AM EST > To: "Russell Housley" >, "Russ Housley" > >=20 >=20 > A new version of I-D, draft-housley-cms-mix-with-psk-00.txt > has been successfully submitted by Russell Housley and posted to the > IETF repository. >=20 > Name: draft-housley-cms-mix-with-psk > Revision: 00 > Title: Using Pre-Shared Key (PSK) in the Cryptographic = Message Syntax (CMS) > Document date: 2017-11-13 > Group: Individual Submission > Pages: 11 > URL: = https://www.ietf.org/internet-drafts/draft-housley-cms-mix-with-psk-00.txt= = > Status: = https://datatracker.ietf.org/doc/draft-housley-cms-mix-with-psk/ = > Htmlized: = https://tools.ietf.org/html/draft-housley-cms-mix-with-psk-00 = > Htmlized: = https://datatracker.ietf.org/doc/html/draft-housley-cms-mix-with-psk-00 = >=20 >=20 > Abstract: > The invention of a large-scale quantum computer would pose a serious > challenge for the cryptographic algorithms that are widely deployed > today. The Cryptographic Message Syntax (CMS) supports key = transport > and key agreement algorithms that could be broken by the invention = of > such a quantum computer. By storing communications that are > protected with the CMS today, someone could decrypt them in the > future when a large-scale quantum computer becomes available. Once > quantum-secure key management algorithms are available, the CMS will > be extended to support them, if current syntax the does not > accommodated them. In the near-term, this document describes a > mechanism to protect today's communication from the future invention > of a large-scale quantum computer by mixing the output of key > transport and key agreement algorithms with a pre-shared key. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org = . >=20 > The IETF Secretariat >=20 --Apple-Mail=_459A6D90-F745-423A-B117-4BC23D20FC39 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

People on this list may find this new I-D interesting,

Russ

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-housley-cms-mix-with-psk-00.txt
Date: = November 13, 2017 at 10:14:32 = AM EST
To: = "Russell Housley" <housley@vigilsec.com>, "Russ Housley" <housley@vigilsec.com>

A new version = of I-D, draft-housley-cms-mix-with-psk-00.txt
has been = successfully submitted by Russell Housley and posted to the
IETF repository.

Name: = draft-housley-cms-mix-with-psk
Revision: 00
Title:= = Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax = (CMS)
Document date: 2017-11-13
Group:= = Individual Submission
Pages: 11
URL: =            https://www.ietf.org/internet-drafts/draft-housley-cms-mix-with= -psk-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-housley-cms-mix-with-psk= /
Htmlized:       https://tools.ietf.org/html/draft-housley-cms-mix-with-psk-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-housley-cms-mix-wit= h-psk-00

Abstract:
  The invention of a large-scale quantum computer = would pose a serious
  challenge for the = cryptographic algorithms that are widely deployed
=   today. The Cryptographic Message Syntax (CMS) supports = key transport
  and key agreement algorithms = that could be broken by the invention of
  such = a quantum computer. By storing communications that are
  protected with the CMS today, someone could = decrypt them in the
  future when a large-scale = quantum computer becomes available. Once
=   quantum-secure key management algorithms are available, the = CMS will
  be extended to support them, if = current syntax the does not
  accommodated = them. In the near-term, this document describes a
=   mechanism to protect today's communication from the future = invention
  of a large-scale quantum computer = by mixing the output of key
  transport and key = agreement algorithms with a pre-shared key.

Please note that = it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

= --Apple-Mail=_459A6D90-F745-423A-B117-4BC23D20FC39--