From nobody Mon Sep 9 07:59:55 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BCE12086C; Mon, 9 Sep 2019 07:59:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.101.0 Auto-Submitted: auto-generated Precedence: bulk Cc: rdd@cert.org, draft-ietf-lamps-cms-shakes@ietf.org, Russ Housley , lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org, The IESG , rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156804117912.28121.2770867974006440059.idtracker@ietfa.amsl.com> Date: Mon, 09 Sep 2019 07:59:39 -0700 Archived-At: Subject: [lamps] Protocol Action: 'Use of the SHAKE One-way Hash Functions in the Cryptographic Message Syntax (CMS)' to Proposed Standard (draft-ietf-lamps-cms-shakes-17.txt) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2019 14:59:42 -0000 The IESG has approved the following document: - 'Use of the SHAKE One-way Hash Functions in the Cryptographic Message Syntax (CMS)' (draft-ietf-lamps-cms-shakes-17.txt) as Proposed Standard This document is the product of the Limited Additional Mechanisms for PKIX and SMIME Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ Technical Summary This document updates the "Cryptographic Message Syntax Algorithms" (RFC3370) and describes the conventions for using the SHAKE family of hash functions in the Cryptographic Message Syntax as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms. The conventions for the associated signer public keys in CMS are also described. Working Group Summary There is consensus for this document in the LAMPS WG. Document Quality S/MIME has wide support, and it depends on the CMS. A few people have expressed interest in using SHAKE in their implementations. Personnel Russ Housley is the document shepherd. Roman Danyliw is the responsible area director. From nobody Wed Sep 11 12:06:34 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA8812006E for ; Wed, 11 Sep 2019 12:06:32 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 lwNVByPZbuha for ; Wed, 11 Sep 2019 12:06:31 -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 1A70612001B for ; Wed, 11 Sep 2019 12:06:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6C855300AF1 for ; Wed, 11 Sep 2019 15:06:29 -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 3kaoXzniRc20 for ; Wed, 11 Sep 2019 15:06:28 -0400 (EDT) Received: from [5.5.33.11] (unknown [204.194.23.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 1F908300AEF for ; Wed, 11 Sep 2019 15:06:28 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <6FA94952-63C4-42A3-A85F-AAB0A8145F68@vigilsec.com> Date: Wed, 11 Sep 2019 15:06:28 -0400 To: LAMPS WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [lamps] draft-ietf-lamps-cms-shakes X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 19:06:33 -0000 I was just working on an implementation, and I discovered an omission in = the ASN.1 for draft-ietf-lamps-cms-shakes. The ASN.1 module for draft-ietf-lamps-pkix-shake includes: -- RSASSA-PSS with SHAKE128 sa-rsassapssWithSHAKE128 SIGNATURE-ALGORITHM ::=3D { IDENTIFIER id-RSASSA-PSS-SHAKE128 PARAMS ARE absent -- The hashAlgorithm is mda-shake128 -- The maskGenAlgorithm is id-shake128 -- Mask Gen Algorithm is SHAKE128 with output length -- (8*ceil((n-1)/8) - 264) bits, where n is the RSA -- modulus in bits. -- The saltLength is 32. The trailerField is 1 HASHES { mda-shake128 } PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE128 } SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE128 } } id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::=3D { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) TBD1 } -- RSASSA-PSS with SHAKE256 sa-rsassapssWithSHAKE256 SIGNATURE-ALGORITHM ::=3D { IDENTIFIER id-RSASSA-PSS-SHAKE256 PARAMS ARE absent -- The hashAlgorithm is mda-shake256 -- The maskGenAlgorithm is id-shake256 -- Mask Gen Algorithm is SHAKE256 with output length -- (8*ceil((n-1)/8) - 520)-bits, where n is the -- RSA modulus in bits. -- The saltLength is 64. The trailerField is 1. HASHES { mda-shake256 } PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE256 } SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE256 } } id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::=3D { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) TBD2 } -- ECDSA with SHAKE128 sa-ecdsaWithSHAKE128 SIGNATURE-ALGORITHM ::=3D { IDENTIFIER id-ecdsa-with-shake128 VALUE ECDSA-Sig-Value PARAMS ARE absent HASHES { mda-shake128 } PUBLIC-KEYS { pk-ec } SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake128 } } id-ecdsa-with-shake128 OBJECT IDENTIFIER ::=3D { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) TBD3 } -- ECDSA with SHAKE256 sa-ecdsaWithSHAKE256 SIGNATURE-ALGORITHM ::=3D { IDENTIFIER id-ecdsa-with-shake256 VALUE ECDSA-Sig-Value PARAMS ARE absent HASHES { mda-shake256 } PUBLIC-KEYS { pk-ec } SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake256 } } id-ecdsa-with-shake256 OBJECT IDENTIFIER ::=3D { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) TBD4 } I think that the draft-ietf-lamps-cms-shakes ASN.1 module should repeat = this information in exactly the same format or it should IMPORT these = definitions. Russ= From nobody Wed Sep 11 12:17:34 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7538E120865 for ; Wed, 11 Sep 2019 12:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 880jua8898Kg for ; Wed, 11 Sep 2019 12:17:30 -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 B551C120800 for ; Wed, 11 Sep 2019 12:17:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3BAFC300AED for ; Wed, 11 Sep 2019 15:17:29 -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 3fsQerTnOVE3 for ; Wed, 11 Sep 2019 15:17:28 -0400 (EDT) Received: from [5.5.33.11] (unknown [204.194.23.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 22DA1300AEC for ; Wed, 11 Sep 2019 15:17:28 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 11 Sep 2019 15:17:28 -0400 References: <3DB1B550-26FA-4F93-8CFA-434C1F8811D1@vigilsec.com> To: LAMPS WG In-Reply-To: <3DB1B550-26FA-4F93-8CFA-434C1F8811D1@vigilsec.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Proposed charter update regarding clarifications X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 19:17:32 -0000 I am concerned that we have heard from very few people on this topic, = with roughly equal numbers speaking for, against, and indifferent. If = you have not spoken, please do so. Russ > On Jul 27, 2019, at 7:40 AM, Russ Housley = wrote: >=20 > At the meeting in Montreal, we suggested a charter update to allow = clarifications. I suggest: >=20 > OLD: >=20 > In addition, the LAMPS WG may investigate other updates to documents > produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not adopt > any of these potential work items without rechartering. >=20 > NEW: >=20 > In addition, the LAMPS WG may investigate other updates to documents > produced by the PKIX and S/MIME WG. The LAMPS WG may produce > clarifications where needed, but the LAMPS WG shall not adopt > anything beyond clarifications without rechartering. >=20 > Thoughts? >=20 > Russ From nobody Wed Sep 11 12:43:08 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87C31201E4 for ; Wed, 11 Sep 2019 12:43:07 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 VCHBb8Bgudsl for ; Wed, 11 Sep 2019 12:43:06 -0700 (PDT) Received: from mail2.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 A6D3F12081B for ; Wed, 11 Sep 2019 12:43:05 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 11 Sep 2019 12:42:58 -0700 From: Jim Schaad To: 'Russ Housley' , 'LAMPS WG' References: <3DB1B550-26FA-4F93-8CFA-434C1F8811D1@vigilsec.com> In-Reply-To: Date: Wed, 11 Sep 2019 12:42:57 -0700 Message-ID: <007201d568d9$1ded2390$59c76ab0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQJvVAnk/CB0xTANRsCye1KxYOkgewIP228rpeKLIVA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] Proposed charter update regarding clarifications X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 19:43:08 -0000 Given that we have found several clarification locations, I think this is good text. Jim -----Original Message----- From: Spasm On Behalf Of Russ Housley Sent: Wednesday, September 11, 2019 12:17 PM To: LAMPS WG Subject: Re: [lamps] Proposed charter update regarding clarifications I am concerned that we have heard from very few people on this topic, with roughly equal numbers speaking for, against, and indifferent. If you have not spoken, please do so. Russ > On Jul 27, 2019, at 7:40 AM, Russ Housley wrote: > > At the meeting in Montreal, we suggested a charter update to allow clarifications. I suggest: > > OLD: > > In addition, the LAMPS WG may investigate other updates to documents > produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not adopt > any of these potential work items without rechartering. > > NEW: > > In addition, the LAMPS WG may investigate other updates to documents > produced by the PKIX and S/MIME WG. The LAMPS WG may produce > clarifications where needed, but the LAMPS WG shall not adopt anything > beyond clarifications without rechartering. > > Thoughts? > > Russ _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Wed Sep 11 15:18:39 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB02D1200A1; Wed, 11 Sep 2019 15:18:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-lamps-cms-hash-sig@ietf.org, Tim Hollebeek , lamps-chairs@ietf.org, tim.hollebeek@digicert.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.101.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <156824031769.13397.11560883765399298866.idtracker@ietfa.amsl.com> Date: Wed, 11 Sep 2019 15:18:37 -0700 Archived-At: Subject: [lamps] Barry Leiba's No Objection on draft-ietf-lamps-cms-hash-sig-09: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 22:18:38 -0000 Barry Leiba has entered the following ballot position for draft-ietf-lamps-cms-hash-sig-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-hash-sig/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks, Russ, as always, for a clear and well-written document. Some editorial nits: — Section 1.3 — Each of these advances pose a threat to widely deployed digital signature algorithms. “poses”, to match the singular “each”. 
 Recent advances in cryptoanalysis [BH2013] “cryptanalysis”, no “o”. The HSS/LMS signature algorithm does not depend on the difficulty of discrete logarithm or factoring, as a result these algorithms are Comma splice. Make it a semicolon. — Section 2.2 — The second parameter is the number of bytes output by the hash function, m, which is the amount of data associated with each node in the tree. It’s a small thing, but I think the “m” is misplaced where it is, and suggest “…the number of bytes, m, output by the hash function….” — Section 3 — Each format includes a counter and type codes that indirectly providing all of the information that is needed “provide” — Section 5 — When signed attributes are absent, the HSS/LMS signature is computed over the content. When signed attributes are present, a hash is computed over the content using the same hash function that is used in the HSS/LMS tree, and then a message-digest attribute is constructed to contain the resulting hash value, and then the result of DER encoding the set of signed attributes (which MUST include a content-type attribute and a message-digest attribute, and then the HSS/LMS signature is computed over the DER-encoded output. You’re missing a “)” there, which makes it a bit odd. I think it should be “(which MUST include a content-type attribute and a message-digest attribute), and then….” digestAlgorithm MUST contain the one-way hash function used to in the HSS/LMS tree. Remove “to”. — Section 6 — While the consequences of an inadequate pseudo-random number generator (PRNGs) to generate these values is much less severe than the generation of private keys “than in the generation” — Appendix — Just a note that I did not review the ASN.1 module. From nobody Wed Sep 11 21:21:57 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F9E120025 for ; Wed, 11 Sep 2019 21:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Srdbs2+e; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=dMdE8rMX 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 yocwkqHLZdmN for ; Wed, 11 Sep 2019 21:21:54 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 207FD120019 for ; Wed, 11 Sep 2019 21:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4039; q=dns/txt; s=iport; t=1568262114; x=1569471714; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=wnarrWlWxHV7RyiNkppH3t21pOr1l5UmVYBcpURvLCQ=; b=Srdbs2+e8uYHdPke6+96Sk6K26B4pf1bmztmfzAnLJ1yMNp0AoruFWlK kUauPWnq7rOH09j93vq15DAdHK2De/vOzbkWj3p32ULkl3e5c3Nchj8Uu rFg9MdKSNvNBsuD4bwkC0zJvG8ZLLf8Fb/9cV3IcAGoMydel1FAx16AsM 0=; IronPort-PHdr: =?us-ascii?q?9a23=3ArPKRLBXsY3NugtYseSdHRO8AnhrV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtankiH81HTFZj9lmwMFNeH4D1YFiB6nA=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAAAFx3ld/5hdJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVQMBAQEBCwGBRFADbVYgBAsqh2gDimdNgg+XcIEugSQDVAk?= =?us-ascii?q?BAQEMAQEYCwoCAQGEPwKCVSM2Bw4CAwkBAQQBAQECAQYEbYUuDIVKAQEBAQM?= =?us-ascii?q?BARAoBgEBLAwLBAIBCBEEAQEeARAnCx0IAgQBEggagwGBagMdAQIMn2oCgTi?= =?us-ascii?q?IYYIlgn0BAQWFBRiCFgMGgTQBi3cYgUA/gRFGgkw+gmEBAQIBgWCDO4ImrEs?= =?us-ascii?q?KgiGHAY4RmQqNf4gEkGoCBAIEBQIOAQEFgVkBMIFYcBU7gmyCQoNyhRSFP3M?= =?us-ascii?q?BgSiOfwEB?= X-IronPort-AV: E=Sophos;i="5.64,495,1559520000"; d="scan'208";a="329896755" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Sep 2019 04:21:53 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x8C4Lrk5024825 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Sep 2019 04:21:53 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 11 Sep 2019 23:21:52 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 11 Sep 2019 23:21:47 -0500 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 11 Sep 2019 23:21:47 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bvQACOGAfJdyZyqX4/9eROIJihogu1m0+dLM+9Ma4hrbMn7cgTb+thMYcCE3P2H/zsK2a6GHXmgcGM1k2/++xDq2dNNMAjz0ILdIpnI0bHKllqbw102xjy6veiZJS/LIl4SzkvDhzqqxtZ1IJ8RaJXHDaAeWEFJcIiF2prbMHYC1Zu0lyY8/ERtASbjSFA1xKs1DCPA1B42QKrVtN2gi+EbfyoCeIYpDe5Vw929SSFwa+Q/6UbZA2lS/CNeH8BDGcuAbeKb0x/ImVd53KqAxqrK46cYhuSZ4GritvjalFv6/zduL8+v0Lr88DD130tD3RPxjedissuLmrWxWw6CSpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6BIcC48T7C6A70MPy+6bQI/6whEWZYLypTT10jGw0Ak=; b=CTZNxZ8H3CBz03jVMoUAkTLcrIlgoOIoHH5ypZrNOdAyMPuH7X6mLHn0SxghU8rnXP2oH27AL4/IO4qGyzYnaj6rLLGRio6QPGWD0pfMspB8e11emA8gZ+pJE4LWdMTEO+BCk1gO0x9CnwLQofaJRhus7wB87li2ZKL2MRMt9LtudEgfbVoha3A0mAfMesoVW9zhpvozOZsjsU+3EwGI+YiJrK31oPoi4Sr+TEJXLaHlOZEZcaIGSl5HjoT9pOETMoPsVeQXOphPyzjeF1LFXVmLXlEUCe+qXnHJxYk4/oJKbG1x+lfOGHBqrdxRFH8au5oCgkHhYvXYvj8XjKH6ig== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6BIcC48T7C6A70MPy+6bQI/6whEWZYLypTT10jGw0Ak=; b=dMdE8rMXcH6hwxonvy/osP7PlopQVur/NOv3bQr6WMaISX9a/lLF8wgyrRtu3/VRIlqoyfxW7r+CtrINwNzozoGPUpuPrxDBfITqgrqBp9Emje57z6fltBrPnbOvdUrPeBecMKK/PW5MjpSF0Pw0fdkytCPFNT/IPo1GXGgoD3Q= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2756.namprd11.prod.outlook.com (52.135.246.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.19; Thu, 12 Sep 2019 04:21:46 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::20df:b3df:537d:fd20]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::20df:b3df:537d:fd20%7]) with mapi id 15.20.2263.016; Thu, 12 Sep 2019 04:21:46 +0000 From: "Panos Kampanakis (pkampana)" To: Russ Housley , LAMPS WG Thread-Topic: [lamps] draft-ietf-lamps-cms-shakes Thread-Index: AQHVaNQPFcxLGZJUgkqHUOMyu7XEmacnawkA Date: Thu, 12 Sep 2019 04:21:45 +0000 Message-ID: References: <6FA94952-63C4-42A3-A85F-AAB0A8145F68@vigilsec.com> In-Reply-To: <6FA94952-63C4-42A3-A85F-AAB0A8145F68@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1004::49] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 67a0b8aa-53dd-479e-c08b-08d73738b93e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN7PR11MB2756; x-ms-traffictypediagnostic: BN7PR11MB2756: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 01583E185C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(376002)(366004)(396003)(39860400002)(189003)(199004)(13464003)(51444003)(99286004)(229853002)(7736002)(25786009)(476003)(33656002)(7696005)(19627235002)(6436002)(256004)(14444005)(86362001)(55016002)(9686003)(486006)(6306002)(76176011)(6116002)(46003)(81166006)(76116006)(8676002)(966005)(478600001)(66476007)(66556008)(64756008)(74316002)(66446008)(6246003)(446003)(186003)(11346002)(316002)(66946007)(110136005)(102836004)(81156014)(8936002)(71200400001)(6506007)(53546011)(66574012)(53936002)(52536014)(14454004)(305945005)(5660300002)(71190400001)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2756; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 90/3pZgB/yYipT5wiSWyV5R564B5tY6hWpunvfJpYxxToJCo7Itr61hOCOtNOt9RPySqWZbkJEFSg/Ks8P+GdtZo5QAb1dWYrXqa0JkZTEAE3WHJ5EYBkYbrkIZ1bl8IFhpEunX3yc6OGTQCf6o0zlykIqbgBgjfzUVF4dveYv5R543jH0S1KeAMNpj65qMK8zRM0EM2C1IqBsKxYlQWrt0jXbUb3ley7HFqHPa8XR2oilgq1j/j9SAnmrXTpNwmzvvAonVglW+M9cT0d4raeUrt4hOGKzLwEb777G7SzJhZEuJO3PnsGZ75DuzTuAyC6q77/z3DLRvAMfR7M88h+yClDgPtWmfWmDjh9C0sQ8w2s331iRqSx368YQg6SgUZMNH/v3qVLLJkfFM9P2XIWJa3JtA/jufqQZPhpByPs08= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 67a0b8aa-53dd-479e-c08b-08d73738b93e X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Sep 2019 04:21:45.9919 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6Ebqy1GScECuvU7l9R435wHSLwtDVJtjpzEFYS3s8evQ63aoJOS3OLV8VaoCKX5+GVA1RqEC32LKPlQ377oSKg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2756 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.21, xch-rcd-011.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [lamps] draft-ietf-lamps-cms-shakes X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 04:21:56 -0000 Hi Russ,=20 Hmm, do we need it?=20 CMS imports AlgorithmIdentifier from PKIX which we updated in the PKIX SHAK= Es draft. And then CMS uses these algorithm identifiers in the SignedData S= ignerInfo signatureAlgorithm field.=20 https://tools.ietf.org/html/rfc5753#appendix-A.2 does import sa-ecdsawithXX= X as you are suggesting, but I am not sure it needed to. I mean we could im= port the new sa-ecdsawithshake and sa-rsassapssWithSHAKE and put them Signa= tureAlgs to make it easier, but it would be commented out like https://tool= s.ietf.org/html/rfc5753#appendix-A.2 does because it already exists in the = PKIX SHAKEs ASN.1 Rgs, Panos -----Original Message----- From: Spasm On Behalf Of Russ Housley Sent: Wednesday, September 11, 2019 3:06 PM To: LAMPS WG Subject: [lamps] draft-ietf-lamps-cms-shakes I was just working on an implementation, and I discovered an omission in th= e ASN.1 for draft-ietf-lamps-cms-shakes. The ASN.1 module for draft-ietf-lamps-pkix-shake includes: -- RSASSA-PSS with SHAKE128 sa-rsassapssWithSHAKE128 SIGNATURE-ALGORITHM ::=3D { IDENTIFIER id-RSASSA-PSS-SHAKE128 PARAMS ARE absent -- The hashAlgorithm is mda-shake128 -- The maskGenAlgorithm is id-shake128 -- Mask Gen Algorithm is SHAKE128 with output length -- (8*ceil((n-1)/8) - 264) bits, where n is the RSA -- modulus in bits. -- The saltLength is 32. The trailerField is 1 HASHES { mda-shake128 } PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE128 } SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE128 } } id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::=3D { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) TBD1 } -- RSASSA-PSS with SHAKE256 sa-rsassapssWithSHAKE256 SIGNATURE-ALGORITHM ::=3D { IDENTIFIER id-RSASSA-PSS-SHAKE256 PARAMS ARE absent -- The hashAlgorithm is mda-shake256 -- The maskGenAlgorithm is id-shake256 -- Mask Gen Algorithm is SHAKE256 with output length -- (8*ceil((n-1)/8) - 520)-bits, where n is the -- RSA modulus in bits. -- The saltLength is 64. The trailerField is 1. HASHES { mda-shake256 } PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE256 } SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE256 } } id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::=3D { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) TBD2 } -- ECDSA with SHAKE128 sa-ecdsaWithSHAKE128 SIGNATURE-ALGORITHM ::=3D { IDENTIFIER id-ecdsa-with-shake128 VALUE ECDSA-Sig-Value PARAMS ARE absent HASHES { mda-shake128 } PUBLIC-KEYS { pk-ec } SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake128 } } id-ecdsa-with-shake128 OBJECT IDENTIFIER ::=3D { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) TBD3 } -- ECDSA with SHAKE256 sa-ecdsaWithSHAKE256 SIGNATURE-ALGORITHM ::=3D { IDENTIFIER id-ecdsa-with-shake256 VALUE ECDSA-Sig-Value PARAMS ARE absent HASHES { mda-shake256 } PUBLIC-KEYS { pk-ec } SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake256 } } id-ecdsa-with-shake256 OBJECT IDENTIFIER ::=3D { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) TBD4 } I think that the draft-ietf-lamps-cms-shakes ASN.1 module should repeat thi= s information in exactly the same format or it should IMPORT these definiti= ons. Russ _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Wed Sep 11 21:54:39 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32C012081F for ; Wed, 11 Sep 2019 21:54:37 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 xiYl3ChIfzSh for ; Wed, 11 Sep 2019 21:54:35 -0700 (PDT) Received: from mail2.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 4857E12080E for ; Wed, 11 Sep 2019 21:54:35 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 11 Sep 2019 21:54:29 -0700 From: Jim Schaad To: "'Panos Kampanakis (pkampana)'" , 'Russ Housley' , 'LAMPS WG' References: <6FA94952-63C4-42A3-A85F-AAB0A8145F68@vigilsec.com> In-Reply-To: Date: Wed, 11 Sep 2019 21:54:27 -0700 Message-ID: <00bb01d56926$296d4b80$7c47e280$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQJ9oOfTTjAaQCybpEakgIm7VCChzwKGFaBNpcLZPCA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [lamps] draft-ietf-lamps-cms-shakes X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 04:54:38 -0000 Redefining is something that is not good. You only want to have a single definition if at all possible. Importing something that is not referenced is a bit odd, but does not hurt anything. Pointing to where something is defined would be sufficient as far as I am concerned -- sa-rsassapssWithSHAKE - this is defined in RFCXXXX Jim -----Original Message----- From: Spasm On Behalf Of Panos Kampanakis (pkampana) Sent: Wednesday, September 11, 2019 9:22 PM To: Russ Housley ; LAMPS WG Subject: Re: [lamps] draft-ietf-lamps-cms-shakes Hi Russ, Hmm, do we need it? CMS imports AlgorithmIdentifier from PKIX which we updated in the PKIX SHAKEs draft. And then CMS uses these algorithm identifiers in the SignedData SignerInfo signatureAlgorithm field. https://tools.ietf.org/html/rfc5753#appendix-A.2 does import sa-ecdsawithXXX as you are suggesting, but I am not sure it needed to. I mean we could import the new sa-ecdsawithshake and sa-rsassapssWithSHAKE and put them SignatureAlgs to make it easier, but it would be commented out like https://tools.ietf.org/html/rfc5753#appendix-A.2 does because it already exists in the PKIX SHAKEs ASN.1 Rgs, Panos -----Original Message----- From: Spasm On Behalf Of Russ Housley Sent: Wednesday, September 11, 2019 3:06 PM To: LAMPS WG Subject: [lamps] draft-ietf-lamps-cms-shakes I was just working on an implementation, and I discovered an omission in the ASN.1 for draft-ietf-lamps-cms-shakes. The ASN.1 module for draft-ietf-lamps-pkix-shake includes: -- RSASSA-PSS with SHAKE128 sa-rsassapssWithSHAKE128 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-RSASSA-PSS-SHAKE128 PARAMS ARE absent -- The hashAlgorithm is mda-shake128 -- The maskGenAlgorithm is id-shake128 -- Mask Gen Algorithm is SHAKE128 with output length -- (8*ceil((n-1)/8) - 264) bits, where n is the RSA -- modulus in bits. -- The saltLength is 32. The trailerField is 1 HASHES { mda-shake128 } PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE128 } SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE128 } } id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) TBD1 } -- RSASSA-PSS with SHAKE256 sa-rsassapssWithSHAKE256 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-RSASSA-PSS-SHAKE256 PARAMS ARE absent -- The hashAlgorithm is mda-shake256 -- The maskGenAlgorithm is id-shake256 -- Mask Gen Algorithm is SHAKE256 with output length -- (8*ceil((n-1)/8) - 520)-bits, where n is the -- RSA modulus in bits. -- The saltLength is 64. The trailerField is 1. HASHES { mda-shake256 } PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE256 } SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE256 } } id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) TBD2 } -- ECDSA with SHAKE128 sa-ecdsaWithSHAKE128 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-ecdsa-with-shake128 VALUE ECDSA-Sig-Value PARAMS ARE absent HASHES { mda-shake128 } PUBLIC-KEYS { pk-ec } SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake128 } } id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) TBD3 } -- ECDSA with SHAKE256 sa-ecdsaWithSHAKE256 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-ecdsa-with-shake256 VALUE ECDSA-Sig-Value PARAMS ARE absent HASHES { mda-shake256 } PUBLIC-KEYS { pk-ec } SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake256 } } id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) algorithms(6) TBD4 } I think that the draft-ietf-lamps-cms-shakes ASN.1 module should repeat this information in exactly the same format or it should IMPORT these definitions. Russ _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Sep 12 04:24:53 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3541200F4 for ; Thu, 12 Sep 2019 04:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 vwc_z_lCPDFY for ; Thu, 12 Sep 2019 04:24:49 -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 D26421200CD for ; Thu, 12 Sep 2019 04:24:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 385D1300B0D for ; Thu, 12 Sep 2019 07:24: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 UmStyB6xKUKG for ; Thu, 12 Sep 2019 07:24:45 -0400 (EDT) Received: from [5.5.33.13] (unknown [204.194.23.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 061433004AF; Thu, 12 Sep 2019 07:24:44 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <00bb01d56926$296d4b80$7c47e280$@augustcellars.com> Date: Thu, 12 Sep 2019 07:24:45 -0400 Cc: LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: <0C2B305A-27DC-45A8-97B9-C51F61BCB2EB@vigilsec.com> References: <6FA94952-63C4-42A3-A85F-AAB0A8145F68@vigilsec.com> <00bb01d56926$296d4b80$7c47e280$@augustcellars.com> To: Jim Schaad , Panos Kampanakis X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] draft-ietf-lamps-cms-shakes X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 11:24:51 -0000 Since pkix-shake is going through the process sirse, it would be easy to = add an IMPORT for the four sa-* values. Russ > On Sep 12, 2019, at 12:54 AM, Jim Schaad = wrote: >=20 > Redefining is something that is not good. You only want to have a = single > definition if at all possible. >=20 > Importing something that is not referenced is a bit odd, but does not = hurt > anything. Pointing to where something is defined would be sufficient = as far > as I am concerned >=20 > -- sa-rsassapssWithSHAKE - this is defined in RFCXXXX >=20 > Jim >=20 >=20 > -----Original Message----- > From: Spasm On Behalf Of Panos Kampanakis > (pkampana) > Sent: Wednesday, September 11, 2019 9:22 PM > To: Russ Housley ; LAMPS WG > Subject: Re: [lamps] draft-ietf-lamps-cms-shakes >=20 > Hi Russ,=20 >=20 > Hmm, do we need it?=20 >=20 > CMS imports AlgorithmIdentifier from PKIX which we updated in the PKIX > SHAKEs draft. And then CMS uses these algorithm identifiers in the > SignedData SignerInfo signatureAlgorithm field.=20 >=20 > https://tools.ietf.org/html/rfc5753#appendix-A.2 does import = sa-ecdsawithXXX > as you are suggesting, but I am not sure it needed to. I mean we could > import the new sa-ecdsawithshake and sa-rsassapssWithSHAKE and put = them > SignatureAlgs to make it easier, but it would be commented out like > https://tools.ietf.org/html/rfc5753#appendix-A.2 does because it = already > exists in the PKIX SHAKEs ASN.1 >=20 > Rgs, > Panos >=20 >=20 > -----Original Message----- > From: Spasm On Behalf Of Russ Housley > Sent: Wednesday, September 11, 2019 3:06 PM > To: LAMPS WG > Subject: [lamps] draft-ietf-lamps-cms-shakes >=20 > I was just working on an implementation, and I discovered an omission = in the > ASN.1 for draft-ietf-lamps-cms-shakes. >=20 > The ASN.1 module for draft-ietf-lamps-pkix-shake includes: >=20 > -- RSASSA-PSS with SHAKE128 > sa-rsassapssWithSHAKE128 SIGNATURE-ALGORITHM ::=3D { > IDENTIFIER id-RSASSA-PSS-SHAKE128 > PARAMS ARE absent > -- The hashAlgorithm is mda-shake128 > -- The maskGenAlgorithm is id-shake128 > -- Mask Gen Algorithm is SHAKE128 with output length > -- (8*ceil((n-1)/8) - 264) bits, where n is the RSA > -- modulus in bits. > -- The saltLength is 32. The trailerField is 1 > HASHES { mda-shake128 } > PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE128 } > SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE128 } > } > id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::=3D { iso(1) > identified-organization(3) dod(6) internet(1) > security(5) mechanisms(5) pkix(7) algorithms(6) > TBD1 } >=20 > -- RSASSA-PSS with SHAKE256 > sa-rsassapssWithSHAKE256 SIGNATURE-ALGORITHM ::=3D { > IDENTIFIER id-RSASSA-PSS-SHAKE256 > PARAMS ARE absent > -- The hashAlgorithm is mda-shake256 > -- The maskGenAlgorithm is id-shake256 > -- Mask Gen Algorithm is SHAKE256 with output length > -- (8*ceil((n-1)/8) - 520)-bits, where n is the > -- RSA modulus in bits. > -- The saltLength is 64. The trailerField is 1. > HASHES { mda-shake256 } > PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE256 } > SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE256 } > } > id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::=3D { iso(1) > identified-organization(3) dod(6) internet(1) > security(5) mechanisms(5) pkix(7) algorithms(6) > TBD2 } >=20 > -- ECDSA with SHAKE128 > sa-ecdsaWithSHAKE128 SIGNATURE-ALGORITHM ::=3D { > IDENTIFIER id-ecdsa-with-shake128 > VALUE ECDSA-Sig-Value > PARAMS ARE absent > HASHES { mda-shake128 } > PUBLIC-KEYS { pk-ec } > SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake128 } > } > id-ecdsa-with-shake128 OBJECT IDENTIFIER ::=3D { iso(1) > identified-organization(3) dod(6) internet(1) > security(5) mechanisms(5) pkix(7) algorithms(6) > TBD3 } >=20 > -- ECDSA with SHAKE256 > sa-ecdsaWithSHAKE256 SIGNATURE-ALGORITHM ::=3D { > IDENTIFIER id-ecdsa-with-shake256 > VALUE ECDSA-Sig-Value > PARAMS ARE absent > HASHES { mda-shake256 } > PUBLIC-KEYS { pk-ec } > SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake256 } > } > id-ecdsa-with-shake256 OBJECT IDENTIFIER ::=3D { iso(1) > identified-organization(3) dod(6) internet(1) > security(5) mechanisms(5) pkix(7) algorithms(6) > TBD4 } >=20 > I think that the draft-ietf-lamps-cms-shakes ASN.1 module should = repeat this > information in exactly the same format or it should IMPORT these > definitions. >=20 > Russ > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Sep 12 05:51:19 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830EF120857 for ; Thu, 12 Sep 2019 05:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.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 TbglwZxf-_Jk for ; Thu, 12 Sep 2019 05:51:10 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60061.outbound.protection.outlook.com [40.107.6.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62D58120115 for ; Thu, 12 Sep 2019 05:51:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U5aWqJMaMHuEll5SVCULT9pXGwcuN9Gqv4+0w68mBaicZ7kCUIOIdPIS6JESYhmYDAComUuciqfemRHNO8YdTAzHpQ2hSLdaCUqPQKwAV8tmsij7/vjvxMjjFo6QytzquVnnTL8/lcjqxACzkSjJXZUFfV7YaXqJutZesexV/PMIXuoZDhxX80kYW4TscP/UeOxmivMzhIeBAZ2nR9YZ5u+bOEmWY+JPkZxOJC/ZGaCP3oaTP/bv6kGBwvP+0ovaTKYSrow9IJ60iuMaYFwkuBcGSMJ1gRr6K14vs3e0hB7KORzISBaBXld12kDDXQhseCxmtmyTZCyv5/074HnpWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ArArWtEUbzLISp9k+KSNfN56XmTog6sq5JG5VX/qws4=; b=OnV44ZOCEjnwIlmEJvMnyfRg6vnD/jZ63iuw4Rfdj7YKG4KQibUFNNhc90h0+rqyj8Fdkuku0+MDmzyDI2Yd2oSpxIO+LuaUai8eCPr5WvLZkPSjqhEKIJQyMPPoLKTJY3peWRvTQE+4RKB6xjLDsxqoEjwx9kEAopGcl+RYiUHxrfvtwxKIZvuUFbhemhiUdWWiSEaULYlVGWTFr61JbJ+am+wEFZbQEwZ96XWVQegNvMqEU8Kvx/TqXeKmso8R4AMAQLnT8n7iNee2AQ5Q8S1si7noxgOerXxhgYbovoFhVuGngpy6ualdNzSu5BRcOLCgNEw4BIsAmJo6jMRf9A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector2-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ArArWtEUbzLISp9k+KSNfN56XmTog6sq5JG5VX/qws4=; b=R8zkl9wC9Qm+2P4+fy9U7DnhhjrlIH75ByJExYUNBH/JeCFyhdMuM9oCzmYwkHDyYxo+OyKqKWAtmB+nlsqXAJqhvil/N80UgojaLhu16wiZBNF8OTtglqY0/XgF6hUOEfbYw7RxrpTC+hjKYVOj8/pCoWpHe7XdSmoj1e09pGI= Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM (20.177.110.224) by AM0PR10MB2066.EURPRD10.PROD.OUTLOOK.COM (52.134.84.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.17; Thu, 12 Sep 2019 12:51:08 +0000 Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::449a:3304:b112:df40]) by AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::449a:3304:b112:df40%6]) with mapi id 15.20.2241.018; Thu, 12 Sep 2019 12:51:08 +0000 From: "Brockhaus, Hendrik" To: Russ Housley , LAMPS WG Thread-Topic: [lamps] Proposed charter update regarding clarifications Thread-Index: AQHVRHAU976CKRQUrkqVEcAqKmzoNacnIjkAgAEl3vA= Date: Thu, 12 Sep 2019 12:51:08 +0000 Message-ID: References: <3DB1B550-26FA-4F93-8CFA-434C1F8811D1@vigilsec.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified authentication-results: spf=none (sender IP is ) smtp.mailfrom=hendrik.brockhaus@siemens.com; x-originating-ip: [195.145.170.173] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4d650518-71cb-4450-0c90-08d7377fe19d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM0PR10MB2066; x-ms-traffictypediagnostic: AM0PR10MB2066: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 01583E185C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(346002)(396003)(136003)(366004)(189003)(199004)(66556008)(64756008)(66946007)(66476007)(66446008)(52536014)(66066001)(15650500001)(186003)(71190400001)(53936002)(7696005)(76176011)(102836004)(478600001)(9686003)(26005)(3846002)(6116002)(110136005)(71200400001)(14454004)(305945005)(76116006)(7736002)(316002)(2906002)(74316002)(966005)(5660300002)(6436002)(256004)(14444005)(86362001)(33656002)(66574012)(446003)(11346002)(476003)(486006)(45080400002)(25786009)(6506007)(53546011)(8936002)(6306002)(55016002)(99286004)(8676002)(81156014)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR10MB2066; H:AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: siemens.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: w2TAkT+Vqnc0d0i9bISZSchuvJrQqn+zF8mny6nPJZPz2wjNf0Y/m6p11S1x+3azcSfa9kFwI2WQJzt0M3NbEn+3MI+X3QqecZXxryBz6fdFnJbOvKC1LvCT+ISJW+KpnwrEeextykT5EWsY/VZzOiwCuNhoJUYoRElunLPpivaeo6kT+acKSNn1V/BSQ2dqLXanTFSflKy83wyk9FvFJjf/cQyKudAnNdw8GERhBbFjXN1g+hM6UIm0UzqSYIlTgh7T4oJkgIOTWLAHYece1mVQLq5k0ieE9AfZC9PA2YjvC86MCgDS9Pgt1fuSoRz4B55ZAy7ckm2T4hWbT5V4uuxDuYNJG1u+HhaVw4kQSsI2gMTjjW/lTXZApbOX77jJ1CvH2A19lyKOfOaqM7cP8gAIzS2nzJj4dKVUS+384ig= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4d650518-71cb-4450-0c90-08d7377fe19d X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Sep 2019 12:51:08.0475 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: JSFf3zq/llXvZTTuwmLp9UObXVctm0rDQgnWURVUufBW52Jf3KO0e2YmdHaVewIMnr2cmDIOo/1lOSzY0RuYnVRoYqeqLkFPd6q8Oa60MbU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2066 Archived-At: Subject: Re: [lamps] Proposed charter update regarding clarifications X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 12:51:18 -0000 Probably my previous statement was not quite clear. I support the new text. Hendrik > -----Urspr=FCngliche Nachricht----- > Von: Spasm Im Auftrag von Russ Housley > Gesendet: Mittwoch, 11. September 2019 21:17 > An: LAMPS WG > Betreff: Re: [lamps] Proposed charter update regarding clarifications >=20 > I am concerned that we have heard from very few people on this topic, wit= h > roughly equal numbers speaking for, against, and indifferent. If you hav= e not > spoken, please do so. >=20 > Russ >=20 > > On Jul 27, 2019, at 7:40 AM, Russ Housley wrote: > > > > At the meeting in Montreal, we suggested a charter update to allow > clarifications. I suggest: > > > > OLD: > > > > In addition, the LAMPS WG may investigate other updates to documents > > produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not > adopt > > any of these potential work items without rechartering. > > > > NEW: > > > > In addition, the LAMPS WG may investigate other updates to documents > > produced by the PKIX and S/MIME WG. The LAMPS WG may produce > > clarifications where needed, but the LAMPS WG shall not adopt anything > > beyond clarifications without rechartering. > > > > Thoughts? > > > > Russ >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww > .ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=3D02%7C01%7Chendrik. > brockhaus%40siemens.com%7Cf4ba70d23a6a4687d83f08d736ecb6a2%7C38a > e3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637038262608870643& > sdata=3Drfsq7Gs3PwlxZL6488CvGaZ%2B2cp9baujJ6cMQiJtaIg%3D&reserv > ed=3D0 From nobody Thu Sep 12 06:35:05 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A83812007C for ; Thu, 12 Sep 2019 06:35:03 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=letsencrypt.org 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 hKlRBUBzz8p3 for ; Thu, 12 Sep 2019 06:35:01 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6D7E120041 for ; Thu, 12 Sep 2019 06:35:00 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id q18so77693wmq.3 for ; Thu, 12 Sep 2019 06:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=F/qGXD+4LAwPHX3e8S08qMlbwAPFRynJ8WylVSejMd0=; b=AZ08YGI12kF5QYPKUAMo2nP5DoUFdY/2zMZ8TluuS6po9p5dYO/5OE3UckNw/JfEyQ o/iDL5oYyIYKUCc2Chewmy+QCtgP2lJ+h5TnfaWX4xkzckLTToQXjYSaY1aRvTY0sAuY wi25UxLtfEN7Ox/Km7t8qnwb9vv+O759m9Fvg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=F/qGXD+4LAwPHX3e8S08qMlbwAPFRynJ8WylVSejMd0=; b=KYWPHJwMVMPpLWShT0GPyF1ZfF8yT7frLbHq3V4ks+G6G16isy5jBTBbnwLz2X5q9w oZJsjn3r5yfjT7QK2j+6ZU/FFeoJjZ48ISCwJWJzWHFhlOF9xpi9otjlHeIztgjDblVW mN5KhYnJpl3B2SfxzqahS1n+lzzSB/uZ1HB2AHNl9M27vNtP/zgndh24del+a5PRHeEu zTcQn0Wbq10eSFrBy9qimuVjDQ9r/HgavT9sUXXjhrTmSzDqmO146ftN+QFYRs98Ncdc IkEHAb45dlJhifDRhe0IF/6rlB10BUmG3Uf5yqeyjcctPh6XAF/3TDBkRerWG8uere0N 5Q/g== X-Gm-Message-State: APjAAAWazQjKh773tL3g+opBHqrlZmp3qMdVJq+gaodCWP0O/yly4Gsv kVYWItjyWccEbrGcQBENTqtMOaKXL5gwp3CzU5gvTYrs X-Google-Smtp-Source: APXvYqwmI6/oLp01zQvpgFQs38YuGys0LQrUdLXDXhwJGxyWQhwmxpI4TZ9iPXpNF88IXBJ+I/kPSDKYnT5M3CJ1Iw8= X-Received: by 2002:a1c:2d85:: with SMTP id t127mr10893wmt.81.1568295299311; Thu, 12 Sep 2019 06:34:59 -0700 (PDT) MIME-Version: 1.0 References: <3DB1B550-26FA-4F93-8CFA-434C1F8811D1@vigilsec.com> In-Reply-To: Reply-To: cpu@letsencrypt.org From: Daniel McCarney Date: Thu, 12 Sep 2019 09:34:48 -0400 Message-ID: To: Russ Housley Cc: LAMPS WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lamps] Proposed charter update regarding clarifications X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 13:35:03 -0000 I'm in favour of the new text. On Wed, Sep 11, 2019 at 3:17 PM Russ Housley wrote: > > I am concerned that we have heard from very few people on this topic, with roughly equal numbers speaking for, against, and indifferent. If you have not spoken, please do so. > > Russ > > > On Jul 27, 2019, at 7:40 AM, Russ Housley wrote: > > > > At the meeting in Montreal, we suggested a charter update to allow clarifications. I suggest: > > > > OLD: > > > > In addition, the LAMPS WG may investigate other updates to documents > > produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not adopt > > any of these potential work items without rechartering. > > > > NEW: > > > > In addition, the LAMPS WG may investigate other updates to documents > > produced by the PKIX and S/MIME WG. The LAMPS WG may produce > > clarifications where needed, but the LAMPS WG shall not adopt > > anything beyond clarifications without rechartering. > > > > Thoughts? > > > > Russ > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Sep 12 07:40:06 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C608120106 for ; Thu, 12 Sep 2019 07:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=QMj6NGsM; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=YHGFXV1G 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 v_uIeOn88W1N for ; Thu, 12 Sep 2019 07:40:02 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C91531200FB for ; Thu, 12 Sep 2019 07:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5775; q=dns/txt; s=iport; t=1568299201; x=1569508801; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Vzk1ei0LkafUkisbc5izpQ8SZgByAO61kbEus+jHwsk=; b=QMj6NGsMEGRcTChvuudB8HPMwLU8WaYv87N9CtuCCBVEAqYM7y9VCFzo dPSXSpniWIpRcAJKW5i/yT4KdicNtu94r+tScn39yEQaoYTLJPLp6fFe/ mDLrePvvYavjUhg9QapFFv+yrBVI79UPvma1sOJr1Q0BewRuMLp5Fi3+T 8=; IronPort-PHdr: =?us-ascii?q?9a23=3ArbpjtBawwbHQF37mH7hpx1r/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavybCU/BM1EXXdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAABHWHpd/5tdJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVgIBAQEBCwGBRFADbVYgBAsqCodeA4ppglyXcIJSA1QJAQE?= =?us-ascii?q?BDAEBGAsKAgEBhD8Cgl0jNwYOAgMJAQEEAQEBAgEGBG2FLgyFSgEBAQECAQE?= =?us-ascii?q?BECgGAQEsCwEEBwQCAQgRBAEBAR4QJwsdCAIEDgUIGoMBgWoDDg8BAgyfNQK?= =?us-ascii?q?BOIhhgiWCfQEBBYUKGIIWAwaBNAGLdxiBQD+BEUaCTD6CYQEBAgGBYIM7gia?= =?us-ascii?q?sSwqCIYcBjhGZCpYDkGoCBAIEBQIOAQEFgWgigVhwFTuCbIJCg3KFFIU/cwG?= =?us-ascii?q?BKI1cAYEiAQE?= X-IronPort-AV: E=Sophos;i="5.64,497,1559520000"; d="scan'208";a="409503796" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Sep 2019 14:40:00 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x8CEe0k4003215 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Sep 2019 14:40:00 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 12 Sep 2019 09:40:00 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 12 Sep 2019 09:39:59 -0500 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 12 Sep 2019 09:39:59 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SH7kANXcMol+3CJL43zI4aGAyBaz6SiFOZOuhNiLbiPLsZylpti3qlOFcX1kYES6MfaPd3Fx5nRy/hlWKa21ZO/Uk0osyPT0DtgbpefEcrqZ4C/8t9pcYY15jz67LbIFR4SonMo+CQRarx+snvVUDFx48GN5WSX23CS4UIGE36ZQCzMR6Dl2rpAiU7mgsJX8yqOG9Ne5OtflkVFqExpfU5xkHTVfrDXjChg0CpLJhHDLN7pAbPO2r/7rI2CtNN/rS/ormQPAmBzrPiF97puDhhRsFWRPRmAHpja976XxOqemw6gbKLZs8VVrv1Ny9j/QP9r1jTYLLNzL+JalWRcPKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=It0Oigoy0FtVzQRTAiDoQFnYv210kV7g6BVcACyEBzA=; b=HrPgn0wA7QNX7zIXTl4YC/z7DJxt4m/WKPozcuvp1QLIO4HKCecv5SarOfNpgb2BYTvsAv/nfD30H/6o2+U8Log8O+VpPwd10+XfjHQqVH+PjllFFDldLBRMocapNJO2FNdNPptVAQiA2KzPSvoL6K5My88Pz9pk1nYUEkfNASD+2heIkyIHe/KFJ00nFo5H8BkEpE2feeliJ3zIDrQGTtbFmspEgjNTBarMV12kgJuAjJrXNKZPrqnIVmjbZ6VOGVa74d9z1qrn5ahWicZB46uUP2udHERGyfizJYD1AnIlH7NuosEx5GsMckRHZzHHoghlF/4OcLxgtC0BFYmWFA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=It0Oigoy0FtVzQRTAiDoQFnYv210kV7g6BVcACyEBzA=; b=YHGFXV1GfTnnAYUUNCAcOP0IYAqWI58mbryS5sVIPb2f29eLzdguO8sPpzOF9p0yq0P1CV/NzuiPC8QEAaH9mkkbPtIh3g+UoejqUBFWkTlsIwlWtcqcnj9V8hkEVxsNolbXe7YHG0f1GYDLoniwannTqtyPVkXK8wqOCeZz3VI= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2530.namprd11.prod.outlook.com (52.135.254.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.17; Thu, 12 Sep 2019 14:39:58 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::20df:b3df:537d:fd20]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::20df:b3df:537d:fd20%7]) with mapi id 15.20.2263.016; Thu, 12 Sep 2019 14:39:58 +0000 From: "Panos Kampanakis (pkampana)" To: Russ Housley CC: LAMPS WG Thread-Topic: [lamps] draft-ietf-lamps-cms-shakes Thread-Index: AQHVaNQPFcxLGZJUgkqHUOMyu7XEmacnawkAgAAPnYCAAG0NgIAANg8Q Date: Thu, 12 Sep 2019 14:39:58 +0000 Message-ID: References: <6FA94952-63C4-42A3-A85F-AAB0A8145F68@vigilsec.com> <00bb01d56926$296d4b80$7c47e280$@augustcellars.com> <0C2B305A-27DC-45A8-97B9-C51F61BCB2EB@vigilsec.com> In-Reply-To: <0C2B305A-27DC-45A8-97B9-C51F61BCB2EB@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [173.38.117.80] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 22ec4210-0d88-4742-ed75-08d7378f1611 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN7PR11MB2530; x-ms-traffictypediagnostic: BN7PR11MB2530: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 01583E185C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(366004)(376002)(39860400002)(396003)(189003)(13464003)(199004)(51444003)(99286004)(26005)(486006)(74316002)(76176011)(186003)(305945005)(966005)(316002)(446003)(11346002)(6506007)(53546011)(102836004)(7696005)(7736002)(14454004)(66476007)(66556008)(64756008)(66446008)(66946007)(6916009)(52536014)(8936002)(81156014)(33656002)(66066001)(81166006)(8676002)(2906002)(19627235002)(9686003)(6436002)(53936002)(6246003)(25786009)(478600001)(229853002)(76116006)(6116002)(3846002)(71200400001)(71190400001)(86362001)(66574012)(14444005)(6306002)(256004)(4326008)(55016002)(476003)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2530; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: cKMAgizeOygSCTPB/4qVarh0m+MwsvAv53AvkLhVUWMnKTCCuDwgGdx3XGcCSzCuSdr2PEy40PMA41mZG9iLMYPekDrppbN42VHuFMPztVN9c1qkNuxhlCnPfop8u6Vw0TNbDVuanse0rPTs/TEcgJXvakW806cl2C7oZWNWscwBE1x2+JnTqKXE9wxH5aGtbMGACILpedhhmpNEzUsQI81tXD5Y28zKz/CesNyJxuv8a2GMxFEQiMxsGHiQGh5sma8cS0sz1Dgg2uUSAWTim0q8WoLeIflXBwhVav4RZHZvA44CMCLVMhFUvHzm6QZNe7+0rnL5tgo1C0dg6jypukdoHsrNFBjr7kV/45llNemiV6SPG8eKUWK0m22WKnxdhmN7+tmD4mMXJr/Z+uGt8Ci+dugC4aS/ID2dfWRa+q8= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 22ec4210-0d88-4742-ed75-08d7378f1611 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Sep 2019 14:39:58.4370 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: KvO9lRih1Ja0H0qs0KbvJgOL8ew0iqE6LRvQPAgbu/NZkr8ybF9S9vojsHwxvDwbik5xsttsxDoiN8O8TsBUGg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2530 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.25, xch-rcd-015.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [lamps] draft-ietf-lamps-cms-shakes X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 14:40:05 -0000 ACK, thanks.=20 I will spin up a new iteration early next week.=20 -----Original Message----- From: Russ Housley =20 Sent: Thursday, September 12, 2019 7:25 AM To: Jim Schaad ; Panos Kampanakis (pkampana) Cc: LAMPS WG Subject: Re: [lamps] draft-ietf-lamps-cms-shakes Since pkix-shake is going through the process sirse, it would be easy to ad= d an IMPORT for the four sa-* values. Russ > On Sep 12, 2019, at 12:54 AM, Jim Schaad wrote: >=20 > Redefining is something that is not good. You only want to have a=20 > single definition if at all possible. >=20 > Importing something that is not referenced is a bit odd, but does not=20 > hurt anything. Pointing to where something is defined would be=20 > sufficient as far as I am concerned >=20 > -- sa-rsassapssWithSHAKE - this is defined in RFCXXXX >=20 > Jim >=20 >=20 > -----Original Message----- > From: Spasm On Behalf Of Panos Kampanakis > (pkampana) > Sent: Wednesday, September 11, 2019 9:22 PM > To: Russ Housley ; LAMPS WG > Subject: Re: [lamps] draft-ietf-lamps-cms-shakes >=20 > Hi Russ, >=20 > Hmm, do we need it?=20 >=20 > CMS imports AlgorithmIdentifier from PKIX which we updated in the PKIX=20 > SHAKEs draft. And then CMS uses these algorithm identifiers in the=20 > SignedData SignerInfo signatureAlgorithm field. >=20 > https://tools.ietf.org/html/rfc5753#appendix-A.2 does import=20 > sa-ecdsawithXXX as you are suggesting, but I am not sure it needed to.=20 > I mean we could import the new sa-ecdsawithshake and=20 > sa-rsassapssWithSHAKE and put them SignatureAlgs to make it easier,=20 > but it would be commented out like > https://tools.ietf.org/html/rfc5753#appendix-A.2 does because it=20 > already exists in the PKIX SHAKEs ASN.1 >=20 > Rgs, > Panos >=20 >=20 > -----Original Message----- > From: Spasm On Behalf Of Russ Housley > Sent: Wednesday, September 11, 2019 3:06 PM > To: LAMPS WG > Subject: [lamps] draft-ietf-lamps-cms-shakes >=20 > I was just working on an implementation, and I discovered an omission=20 > in the > ASN.1 for draft-ietf-lamps-cms-shakes. >=20 > The ASN.1 module for draft-ietf-lamps-pkix-shake includes: >=20 > -- RSASSA-PSS with SHAKE128 > sa-rsassapssWithSHAKE128 SIGNATURE-ALGORITHM ::=3D { > IDENTIFIER id-RSASSA-PSS-SHAKE128 > PARAMS ARE absent > -- The hashAlgorithm is mda-shake128 > -- The maskGenAlgorithm is id-shake128 > -- Mask Gen Algorithm is SHAKE128 with output length > -- (8*ceil((n-1)/8) - 264) bits, where n is the RSA > -- modulus in bits. > -- The saltLength is 32. The trailerField is 1 > HASHES { mda-shake128 } > PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE128 } > SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE128 } > } > id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::=3D { iso(1) > identified-organization(3) dod(6) internet(1) > security(5) mechanisms(5) pkix(7) algorithms(6) > TBD1 } >=20 > -- RSASSA-PSS with SHAKE256 > sa-rsassapssWithSHAKE256 SIGNATURE-ALGORITHM ::=3D { > IDENTIFIER id-RSASSA-PSS-SHAKE256 > PARAMS ARE absent > -- The hashAlgorithm is mda-shake256 > -- The maskGenAlgorithm is id-shake256 > -- Mask Gen Algorithm is SHAKE256 with output length > -- (8*ceil((n-1)/8) - 520)-bits, where n is the > -- RSA modulus in bits. > -- The saltLength is 64. The trailerField is 1. > HASHES { mda-shake256 } > PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE256 } > SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE256 } > } > id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::=3D { iso(1) > identified-organization(3) dod(6) internet(1) > security(5) mechanisms(5) pkix(7) algorithms(6) > TBD2 } >=20 > -- ECDSA with SHAKE128 > sa-ecdsaWithSHAKE128 SIGNATURE-ALGORITHM ::=3D { > IDENTIFIER id-ecdsa-with-shake128 > VALUE ECDSA-Sig-Value > PARAMS ARE absent > HASHES { mda-shake128 } > PUBLIC-KEYS { pk-ec } > SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake128 } > } > id-ecdsa-with-shake128 OBJECT IDENTIFIER ::=3D { iso(1) > identified-organization(3) dod(6) internet(1) > security(5) mechanisms(5) pkix(7) algorithms(6) > TBD3 } >=20 > -- ECDSA with SHAKE256 > sa-ecdsaWithSHAKE256 SIGNATURE-ALGORITHM ::=3D { > IDENTIFIER id-ecdsa-with-shake256 > VALUE ECDSA-Sig-Value > PARAMS ARE absent > HASHES { mda-shake256 } > PUBLIC-KEYS { pk-ec } > SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake256 } > } > id-ecdsa-with-shake256 OBJECT IDENTIFIER ::=3D { iso(1) > identified-organization(3) dod(6) internet(1) > security(5) mechanisms(5) pkix(7) algorithms(6) > TBD4 } >=20 > I think that the draft-ietf-lamps-cms-shakes ASN.1 module should=20 > repeat this information in exactly the same format or it should IMPORT=20 > these definitions. >=20 > Russ > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Sep 12 09:41:53 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D514F12013A for ; Thu, 12 Sep 2019 09:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.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 p5UWlffIZttm for ; Thu, 12 Sep 2019 09:41:47 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50050.outbound.protection.outlook.com [40.107.5.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0EE12018B for ; Thu, 12 Sep 2019 09:41:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LKZ66ZCSL7bfydtIV+PHI7jp9m7u8OdEtE4uyDy8fXb64FoUnfYw/idN5YtzDJcsUfyD+/LLJDf647yWIrwk7dWzD61qAnL4QQa+FRHZah2QqCDsbzRa+F4RQaVYk4NT6JypSO4MHmzP0nwjGk8pOkh7CK/qbGTTVQhk0HU+D6bvpJ74xOuyBrSu1BzV2eFWDkwdahKBJEZSeaC5UUUwTcBDIrGVJEXO63LXm/BVULq5EkdwWDUnZor4v/JZ1o6hDDUGhMVSw80ICwk3FQe32ju0IV8Z87cNjuMSu+LHOykVlcfAQviDTU8Zv9mTzvIm4EBVfhwYN9W4ZCJYL+Dofg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vEUwTb8w2T7nZcH0M1nNdcXics//h05gBOYPByI2v/4=; b=lLN1Sjq4Mj9eCdkVTUDtKunjhBBd4Cy3bidlx3/rDB3br4P7xhTPHuxPtRHN1bAufwdcAdW4eUY3whwmg6iHkjs/F2RULxOpI01RUIsqagrldzoKtYU3/YxnVdNgYacMHNWlE+CbV01eXXblzTv/OmVGRSg8NIhYlfYGaNkOqpXIz0vu2Q3USFcKmKg9tgxEFbERUpTDFOgw9RnUVeFEy4J997tpOpIj/ZVsE5lvwb9tStkIAzSbDKSJkMLs2FM+ayAz84VKkugbTLY9ADzK8GWmrZXmrpaAnykIbfTFOn7NWsu7neQEHQtZbXCWbI6Ufpz4L/4BowzIX7zFfiElxQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector2-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vEUwTb8w2T7nZcH0M1nNdcXics//h05gBOYPByI2v/4=; b=cladQaxAWGl2HRtE+4dy8bt3jR8HoQNKP1xfJfmFgzcgHN3t7Fu/hqtVaVcEVQH3NJ3L2jk8iAULYYHeRT3HLdVxC5Q6wTU9jDFMHA9+3fhZMHoUWM8wluHkzp7syzu5Tjh9JCcvr8qyTz2dG7QRabxspOJEuo/rIOorNFr91Sg= Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM (20.177.110.224) by AM0PR10MB3028.EURPRD10.PROD.OUTLOOK.COM (10.255.29.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2241.14; Thu, 12 Sep 2019 16:41:43 +0000 Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::449a:3304:b112:df40]) by AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::449a:3304:b112:df40%6]) with mapi id 15.20.2241.018; Thu, 12 Sep 2019 16:41:43 +0000 From: "Brockhaus, Hendrik" To: Michael Richardson CC: LAMPS WG Thread-Topic: [lamps] [Mathmesh] pkix-keyinfo content type Thread-Index: AdVpiOhoiMIaQgPGTI+qS8PjruRemg== Date: Thu, 12 Sep 2019 16:41:42 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified authentication-results: spf=none (sender IP is ) smtp.mailfrom=hendrik.brockhaus@siemens.com; x-originating-ip: [195.145.170.171] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dfb4bd65-53d1-481e-dd20-08d737a017d4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM0PR10MB3028; x-ms-traffictypediagnostic: AM0PR10MB3028: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01583E185C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(376002)(396003)(366004)(39860400002)(199004)(189003)(5660300002)(305945005)(66476007)(186003)(66556008)(64756008)(316002)(6116002)(81156014)(81166006)(53936002)(486006)(6506007)(66946007)(102836004)(66446008)(3846002)(7736002)(76116006)(14444005)(26005)(74316002)(229853002)(256004)(52536014)(33656002)(25786009)(2906002)(478600001)(71190400001)(14454004)(71200400001)(4326008)(55016002)(6246003)(476003)(66066001)(8676002)(7696005)(8936002)(99286004)(9686003)(6436002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR10MB3028; H:AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: siemens.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: eBl24e1JE28UTgEAj03ygUZK66NU4/vcTGS4ueLz6hGbmzQLTOdwpJUN8ulxcHZi2XnoghC3PXpvQ+KKzBFjH4MOIKQAKboLcAPlXXv8RGisoQbONx8kfJiY4unc/6gUbeZ61uz1P1znXVofJ6XklAimiIrnrm2NNgRE6nvZ5nieZYNx3+E0V69TYE0t7TyhyYl7i2WlWZaBKUCQOtXO8ro2X8xp9Oxxe1sinrjBOeVLjT7n7vvnpN/qtjXCTPwvV+vzdFzkaKtBhZChlh2mS+Yul3Ju51YriMosxqMYCBHIsv1+vMZJiqdpe2d8vb1oW3NDNCZgJDAXfTVdfuNrkWCWc+5tUEgkjiUOx0VcXZ1ocaSzNF8RtKZWAPS5VnZ+JtVpjlkStMKW2PBNIvBwrE/Vua+5BG4SgZhZ3ZRJt/k= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: dfb4bd65-53d1-481e-dd20-08d737a017d4 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Sep 2019 16:41:42.8826 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: WA12zpYIx4iLLrglM013SMs+VV/rwdMxefsoJIIeTIzYc19aXgH8SFKf2IVNVIpnha8IzdMY3WdgaqG2M9GhTaAyQRfnGaK0h/UhChinua4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB3028 Archived-At: Subject: Re: [lamps] [Mathmesh] pkix-keyinfo content type X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 16:41:51 -0000 Michael I just read through your email. I like your statement on the subjectKeyId in end entity certificates as it = is quite handy to identify the public key to use in the protocol context. > As SubjectKeyIdentifier can be calculated by any suitable way and used=20 > if it is present, it's only for the case that it is not present that is a= problem. > Typically only CA:TRUE certificates are supposed to have it present. =20 > I'd like it to be present for all certificates. I was quite sad to see that the subjectKeyId is not recommended in DevID ce= rtificate profiles in IEEE 802.1AR. Finally the subjectKeyId is not only be helpful to identify the issuing CA = key/certificate but also the e.g. signing key/certificate for a JSON, XML, = CMS object. Also within CMP messages the subectKeyId can be used in the message header = (senderKeyId) to clearly identify the key/certificate to use to validate th= e CMP protection. This makes the code to pick the right key/certificate muc= h easier. I typically recommend to use this extension also for end entiy certificates= in my company. Hendrik From nobody Fri Sep 13 12:10:56 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED6B1200FA; Fri, 13 Sep 2019 12:10:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-lamps-cms-hash-sig@ietf.org, Tim Hollebeek , lamps-chairs@ietf.org, tim.hollebeek@digicert.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.101.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156840184931.31866.4936814444231419124.idtracker@ietfa.amsl.com> Date: Fri, 13 Sep 2019 12:10:49 -0700 Archived-At: Subject: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-cms-hash-sig-09: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2019 19:10:49 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-lamps-cms-hash-sig-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-hash-sig/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Two fairly minor points that should be easy to resolve, but seem to be worth some time: I think we need to be a bit more clear about what exactly the contents of the signature OCTET STRING are. Section 3 has a fairly abstract note about including enough information to be self-describing (within the HSS/LMS variants), and Section 5 does better with "the single HSS signature value resulting from the signing operation as specified in [HASHSIG]", but it doesn't seem too burdensome to say something like "the string returned from Algorithm 3 in [RFC8554]" or even refer back to the description language at the end of Section 2 and avoid any confusion. Section 5 has a "MUST" for using the same hash for the CMS digestAlgorithm and the HSS/LMS tree, but Section 6 only has a "SHOULD" for the message-digest attribute's digest and the signed attributes digest (the latter of which MUST be the HSS/LMS hash per the previous); should these two requirements be at the same level of normativity? I'm not sure why the one would be more important for correct operation than the other. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1 based digital signature, and it is described in [HASHSIG]. The HSS/LMS signature algorithm can only be used for a fixed number of signing operations. [...] nit: with a given key use. A post-quantum cryptosystem [PQC] is a system that is secure against quantum computers that have more than a trivial number of quantum bits (qu-bits). It is open to conjecture when it will be nit(?): I'm much more used to seeing "q-bits" or "qbits" than "qu-bits". Section 2.2 It's a bit unfortunate that we have to mix 0- (signed public keys) and 1-based (tree nodes) indexing, but it seems that this is inherent in RFC 8554 and not really avoidable in this document. Section 3 The signature value identifies the hash function used in the HSS/LMS tree. In [HASHSIG] only the SHA-256 hash function [SHS] is supported, but it also establishes an IANA registry [IANA-LMS] to permit the registration of additional hash functions in the future. (This pattern occurs in several places, but I pick an arbitrary one to comment on) I am not sure that the "In [HASHSIG] only is supported, but it also establishes an IANA registry" is going to present the best interface to readers; the language in Section 2 about "the algorithm specified in [HASHSIG] currently only uses , but it also establishes an IANA registry to permit the registration of additional [...]" seems to give more emphasis on the registry as opposed to the snapshot in [HASHSIG]. On the other hand, someone is probably going to complain that "currently" will not age well... Section 4 It feels a little surprising to make explicit requirements on the keyUsage contents but not say anything about extendedKeyUsage. Having a static whitelist of EKU OIDs is not reasonable, of course, and the PUBLIC-KEY class from RFC 5912 only covers regular keyUsage, but some advice about "encipherment methods are not going to make sense" might still be appropriate. The public key value is an OCTET STRING. Like the signature format, it is designed for easy parsing. The value is the number of levels in the public key, L, followed by the LMS public key. The HSS/LMS public key value can be summarized as: u32str(L) || lms_public_key "Can be summarized as" does not say to me "here is a rigorous protocol specification" (though it does seem to actually be one, given the notation used in this document and 8554). So unlike the signature OCTET STRING contents, this one is not DISCUSS-worthy, since it's in the same section as the thing being described. Section 5 When signed attributes are absent, the HSS/LMS signature is computed over the content. When signed attributes are present, a hash is computed over the content using the same hash function that is used in the HSS/LMS tree, and then a message-digest attribute is constructed to contain the resulting hash value, and then the result of DER encoding the set of signed attributes (which MUST include a content-type attribute and a message-digest attribute, and then the HSS/LMS signature is computed over the DER-encoded output. In nit(?): is this "the message-digest attribute" constructed in the previous step (as opposed to any old message-digest attribute)? Section 6 tracking data can cause a one-time key to be used more than once. As a result, when a private key and the tracking data are stored on non- volatile media or stored in a virtual machine environment, care must be taken to preserve confidentiality and integrity. It might be worth explicitly noting "in the face of failed writes, virtual machine snapshotting or cloning, and other operational concerns". Appendix: ASN.1 Module MTS-HashSig-2013 Once written, the module name can never change? :) From nobody Sun Sep 15 15:35:58 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342281207FD for ; Sun, 15 Sep 2019 15:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 iEOcbDCVeovH for ; Sun, 15 Sep 2019 15:35:53 -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 4E3D51200E7 for ; Sun, 15 Sep 2019 15:35:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 74361300B12 for ; Sun, 15 Sep 2019 18:35:51 -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 MQElqRJrQrUo for ; Sun, 15 Sep 2019 18:35:45 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 6B3C8300A46; Sun, 15 Sep 2019 18:35:45 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_CA04855B-27ED-4DF5-A320-FF558414162A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sun, 15 Sep 2019 18:35:45 -0400 In-Reply-To: <156840184931.31866.4936814444231419124.idtracker@ietfa.amsl.com> Cc: IESG , LAMPS WG , Tim Hollebeek To: Ben Kaduk References: <156840184931.31866.4936814444231419124.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-cms-hash-sig-09: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2019 22:35:56 -0000 --Apple-Mail=_CA04855B-27ED-4DF5-A320-FF558414162A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Sep 13, 2019, at 3:10 PM, Benjamin Kaduk via Datatracker = wrote: >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-lamps-cms-hash-sig-09: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-hash-sig/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Two fairly minor points that should be easy to resolve, but seem to be > worth some time: >=20 > I think we need to be a bit more clear about what exactly the contents > of the signature OCTET STRING are. Section 3 has a fairly abstract = note > about including enough information to be self-describing (within the > HSS/LMS variants), and Section 5 does better with "the single HSS > signature value resulting from the signing operation as specified in > [HASHSIG]", but it doesn't seem too burdensome to say something like > "the string returned from Algorithm 3 in [RFC8554]" or even refer back > to the description language at the end of Section 2 and avoid any > confusion. I suggest: The signature value is a large OCTET STRING as described in Section 2 of this document. The signature format is designed for easy parsing. The HSS, LMS, and LMOTS component of the signature value each format include a counter and a type code that indirectly providing all of the information that is needed to parse the value during signature validation. > Section 5 has a "MUST" for using the same hash for the CMS > digestAlgorithm and the HSS/LMS tree, but Section 6 only has a = "SHOULD" > for the message-digest attribute's digest and the signed attributes > digest (the latter of which MUST be the HSS/LMS hash per the = previous); > should these two requirements be at the same level of normativity? = I'm > not sure why the one would be more important for correct operation = than > the other. The MUST comes from discussion on the mail list. Please see: = https://mailarchive.ietf.org/arch/msg/spasm/ZJnHLMAsi8229TWUiDZUMN0noFM = As you can see from Scott's message, the design in RFC 8554 expects the = same hash to be used in both places. Currently, CMS does not require the same hash algorithm to be used to = compute the message digest of the content and the signed attributes (if = any are present). RFC 6211 points out that it is normal practice for = them to be the same. I would argue that it is time for an update to RFC = 5652 to REQUIRE them to be the same, but that should not fall to this = document. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Section 1 >=20 > based digital signature, and it is described in [HASHSIG]. The > HSS/LMS signature algorithm can only be used for a fixed number of > signing operations. [...] >=20 > nit: with a given key Yes. ... with a given private key. >=20 > use. A post-quantum cryptosystem [PQC] is a system that is secure > against quantum computers that have more than a trivial number of > quantum bits (qu-bits). It is open to conjecture when it will be >=20 > nit(?): I'm much more used to seeing "q-bits" or "qbits" than = "qu-bits". draft-hoffman-c2pq-05 uses "qubits". I'll drop the hypen. > Section 2.2 >=20 > It's a bit unfortunate that we have to mix 0- (signed public keys) and > 1-based (tree nodes) indexing, but it seems that this is inherent in = RFC > 8554 and not really avoidable in this document. Yes. I need to be aligned with [HASHSIG]. =20 > Section 3 >=20 > The signature value identifies the hash function used in the HSS/LMS > tree. In [HASHSIG] only the SHA-256 hash function [SHS] is > supported, but it also establishes an IANA registry [IANA-LMS] to > permit the registration of additional hash functions in the future. >=20 > (This pattern occurs in several places, but I pick an arbitrary one to > comment on) I am not sure that the "In [HASHSIG] only is > supported, but it also establishes an IANA registry" is going to = present > the best interface to readers; the language in Section 2 about "the > algorithm specified in [HASHSIG] currently only uses , but it = also > establishes an IANA registry to permit the registration of additional > [...]" seems to give more emphasis on the registry as opposed to the > snapshot in [HASHSIG]. On the other hand, someone is probably going = to > complain that "currently" will not age well... I suggest: ... The hash-based signature algorithm specified in [HASHSIG] uses only the SHA-256 one-way hash function [SHS], but it establishes an IANA registry [IANA-LMS] to permit the registration of additional one-way hash functions in the future. > Section 4 >=20 > It feels a little surprising to make explicit requirements on the > keyUsage contents but not say anything about extendedKeyUsage. Having = a > static whitelist of EKU OIDs is not reasonable, of course, and the > PUBLIC-KEY class from RFC 5912 only covers regular keyUsage, but some > advice about "encipherment methods are not going to make sense" might > still be appropriate. That is what the "it MUST NOT contain other values" does. RFC 5280 = define the keyUsage bits as: KeyUsage ::=3D BIT STRING { digitalSignature (0), nonRepudiation (1), -- recent editions of X.509 have -- renamed this bit to contentCommitment keyEncipherment (2), dataEncipherment (3), keyAgreement (4), keyCertSign (5), cRLSign (6), encipherOnly (7), decipherOnly (8) } > The public key value is an OCTET STRING. Like the signature format, > it is designed for easy parsing. The value is the number of levels > in the public key, L, followed by the LMS public key. >=20 > The HSS/LMS public key value can be summarized as: >=20 > u32str(L) || lms_public_key >=20 > "Can be summarized as" does not say to me "here is a rigorous protocol > specification" (though it does seem to actually be one, given the > notation used in this document and 8554). So unlike the signature = OCTET > STRING contents, this one is not DISCUSS-worthy, since it's in the = same > section as the thing being described. It would be better to say: The HSS/LMS public key value can be described as: > Section 5 >=20 > When signed attributes are absent, the HSS/LMS signature is computed > over the content. When signed attributes are present, a hash is > computed over the content using the same hash function that is used > in the HSS/LMS tree, and then a message-digest attribute is > constructed to contain the resulting hash value, and then the result > of DER encoding the set of signed attributes (which MUST include a > content-type attribute and a message-digest attribute, and then the > HSS/LMS signature is computed over the DER-encoded output. In >=20 > nit(?): is this "the message-digest attribute" constructed in the > previous step (as opposed to any old message-digest attribute)? I hope this is more clear: When signed attributes are absent, the HSS/LMS signature is computed over the content. When signed attributes are present, a hash is computed over the content using the same hash function that is used in the HSS/LMS tree, and then a message-digest attribute is constructed with the hash of the content, and then the HSS/LMS signature is computed over the DER-encoded set of signed attributes (which MUST include a content-type attribute and a message-digest attribute). In summary: IF (signed attributes are absent) THEN HSS_LMS_Sign(content) ELSE message-digest attribute =3D Hash(content); HSS_LMS_Sign(DER(SignedAttributes)) > Section 6 >=20 > tracking data can cause a one-time key to be used more than once. = As > a result, when a private key and the tracking data are stored on = non- > volatile media or stored in a virtual machine environment, care must > be taken to preserve confidentiality and integrity. >=20 > It might be worth explicitly noting "in the face of failed writes, > virtual machine snapshotting or cloning, and other operational > concerns". I suggest: Implementations MUST protect the private keys. Compromise of the private keys may result in the ability to forge signatures. Along with the private key, the implementation MUST keep track of which leaf nodes in the tree have been used. Loss of integrity of this tracking data can cause a one-time key to be used more than once. As a result, when a private key and the tracking data are stored on non- volatile media or stored in a virtual machine environment, failed writes, virtual machine snapshotting or cloning, and other operational concerns must be considered to ensure confidentiality and integrity. > Appendix: ASN.1 Module >=20 > MTS-HashSig-2013 >=20 > Once written, the module name can never change? :) Once the OID is assigned to a string, it would be bad form to change it. Russ --Apple-Mail=_CA04855B-27ED-4DF5-A320-FF558414162A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Sep 13, 2019, at 3:10 PM, Benjamin Kaduk via Datatracker = <noreply@ietf.org> wrote:

Benjamin Kaduk has entered the following ballot position = for
draft-ietf-lamps-cms-hash-sig-09: Discuss

When responding, please keep the subject line = intact and reply to all
email addresses included in the To = and CC lines. (Feel free to cut this
introductory = paragraph, however.)


Please = refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-hash-sig/=



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

Two fairly minor points that should = be easy to resolve, but seem to be
worth some time:

I think we need to be a bit more clear about = what exactly the contents
of the signature OCTET STRING = are.  Section 3 has a fairly abstract note
about = including enough information to be self-describing (within the
HSS/LMS variants), and Section 5 does better with "the single = HSS
signature value resulting from the signing operation = as specified in
[HASHSIG]", but it doesn't seem too = burdensome to say something like
"the string returned from = Algorithm 3 in [RFC8554]" or even refer back
to the = description language at the end of Section 2 and avoid any
confusion.

I suggest:

   The signature value is a large = OCTET STRING as described in Section 2
   of this = document.  The signature format is designed for easy = parsing.
   The HSS, LMS, and LMOTS component of the = signature value each format
   include a counter and = a type code that indirectly providing all of
   the = information that is needed to parse the value during = signature
   validation.

Section 5 has a "MUST" for using the same hash for the = CMS
digestAlgorithm and the HSS/LMS tree, but Section 6 = only has a "SHOULD"
for the message-digest attribute's = digest and the signed attributes
digest (the latter of = which MUST be the HSS/LMS hash per the previous);
should = these two requirements be at the same level of normativity?  I'm
not sure why the one would be more important for correct = operation than
the other.

The MUST = comes from discussion on the mail list.  Please see:


As you can see from = Scott's message, the design in RFC 8554 expects the same hash to be used = in both places.

Currently, CMS does = not require the same hash algorithm to be used to compute the message = digest of the content and the signed attributes (if any are present). =  RFC 6211 points out that it is normal practice for them to be the = same.  I would argue that it is time for an update to RFC 5652 to = REQUIRE them to be the same, but that should not fall to this = document.

---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

Section 1

  based digital signature, and it is described in = [HASHSIG].  The
  HSS/LMS signature = algorithm can only be used for a fixed number of
=   signing operations.  [...]

nit: with a given key

Yes. =  ... with a given private key.

=   use.  A post-quantum cryptosystem [PQC] is a system = that is secure
  against quantum computers that = have more than a trivial number of
  quantum = bits (qu-bits).  It is open to conjecture when it will be

nit(?): I'm much more used to seeing "q-bits" = or "qbits" than "qu-bits".
draft-hoffman-c2pq-05 uses "qubits".  I'll drop = the hypen.

Section 2.2

It's a bit unfortunate that we have to mix 0- (signed public = keys) and
1-based (tree nodes) indexing, but it seems that = this is inherent in RFC
8554 and not really avoidable in = this document.

Yes. I need to be aligned with = [HASHSIG].
 
Section 3

  The signature value identifies the hash function = used in the HSS/LMS
  tree.  In [HASHSIG] = only the SHA-256 hash function [SHS] is
=   supported, but it also establishes an IANA registry = [IANA-LMS] to
  permit the registration of = additional hash functions in the future.

(This pattern occurs in several places, but I pick an = arbitrary one to
comment on) I am not sure that the "In = [HASHSIG] only <foo> is
supported, but it also = establishes an IANA registry" is going to present
the best = interface to readers; the language in Section 2 about "the
algorithm specified in [HASHSIG] currently only uses = <foo>, but it also
establishes an IANA registry to = permit the registration of additional
[...]" seems to give = more emphasis on the registry as opposed to the
snapshot = in [HASHSIG].  On the other hand, someone is probably going to
complain that "currently" will not age well...

I = suggest:

  ...  The = hash-based signature
   algorithm specified in = [HASHSIG] uses only the SHA-256 one-way hash
  =  function [SHS], but it establishes an IANA registry [IANA-LMS] = to
   permit the registration of additional one-way = hash functions in the
   future.

Section 4

It feels a little = surprising to make explicit requirements on the
keyUsage = contents but not say anything about extendedKeyUsage.  Having a
static whitelist of EKU OIDs is not reasonable, of course, = and the
PUBLIC-KEY class from RFC 5912 only covers regular = keyUsage, but some
advice about "encipherment methods are = not going to make sense" might
still be appropriate.

That is = what the "it MUST NOT contain other values" does.  RFC 5280 define = the keyUsage bits as:

  =     KeyUsage ::=3D BIT STRING {
      =      digitalSignature       =  (0),
          =  nonRepudiation          (1), -- recent = editions of X.509 have
          =                     =   -- renamed this bit to contentCommitment
    =        keyEncipherment         = (2),
           dataEncipherment =        (3),
        =    keyAgreement           =  (4),
          =  keyCertSign             = (5),
           cRLSign   =               (6),
  =          encipherOnly       =      (7),
          =  decipherOnly            (8) = }

  The public key = value is an OCTET STRING.  Like the signature format,
=   it is designed for easy parsing.  The value is the = number of levels
  in the public key, L, = followed by the LMS public key.

=   The HSS/LMS public key value can be summarized as:

     u32str(L) || = lms_public_key

"Can be summarized as" does = not say to me "here is a rigorous protocol
specification" = (though it does seem to actually be one, given the
notation = used in this document and 8554).  So unlike the signature OCTET
STRING contents, this one is not DISCUSS-worthy, since it's = in the same
section as the thing being described.

It would = be better to say:

  =  The HSS/LMS public key value can be described as:

Section 5

=   When signed attributes are absent, the HSS/LMS signature is = computed
  over the content.  When signed = attributes are present, a hash is
  computed = over the content using the same hash function that is used
=   in the HSS/LMS tree, and then a message-digest attribute = is
  constructed to contain the resulting hash = value, and then the result
  of DER encoding = the set of signed attributes (which MUST include a
=   content-type attribute and a message-digest attribute, and = then the
  HSS/LMS signature is computed over = the DER-encoded output.  In

nit(?): is = this "the message-digest attribute" constructed in the
previous step (as opposed to any old message-digest = attribute)?

I hope this is more clear:

   When signed attributes are = absent, the HSS/LMS signature is computed
   over = the content.  When signed attributes are present, a hash = is
   computed over the content using the same hash = function that is used
   in the HSS/LMS tree, and = then a message-digest attribute is
   constructed = with the hash of the content, and then the HSS/LMS
  =  signature is computed over the DER-encoded set of signed = attributes
   (which MUST include a content-type = attribute and a message-digest
   attribute). =  In summary:

    =   IF (signed attributes are absent)
      = THEN HSS_LMS_Sign(content)
      ELSE = message-digest attribute =3D Hash(content);
    =       =  HSS_LMS_Sign(DER(SignedAttributes))

Section 6

  tracking = data can cause a one-time key to be used more than once.  As
  a result, when a private key and the tracking = data are stored on non-
  volatile media or = stored in a virtual machine environment, care must
=   be taken to preserve confidentiality and integrity.

It might be worth explicitly noting "in the = face of failed writes,
virtual machine snapshotting or = cloning, and other operational
concerns".

I = suggest:

  =  Implementations MUST protect the private keys.  Compromise of = the
   private keys may result in the ability to = forge signatures.  Along
   with the private = key, the implementation MUST keep track of which
  =  leaf nodes in the tree have been used.  Loss of integrity of = this
   tracking data can cause a one-time key to be = used more than once.  As
   a result, when a = private key and the tracking data are stored on non-
  =  volatile media or stored in a virtual machine environment, = failed
   writes, virtual machine snapshotting or = cloning, and other
   operational concerns must be = considered to ensure confidentiality and
  =  integrity.

Appendix: ASN.1 Module

  MTS-HashSig-2013

Once written, the module name can never change? :)

Once the = OID is assigned to a string, it would be bad form to change = it.

Russ

= --Apple-Mail=_CA04855B-27ED-4DF5-A320-FF558414162A-- From nobody Sun Sep 15 19:04:45 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9319612080C; Sun, 15 Sep 2019 19:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 wmRFrsnvLEWr; Sun, 15 Sep 2019 19:04:33 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3913A1202DD; Sun, 15 Sep 2019 19:04:32 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x8G24RjP022404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 15 Sep 2019 22:04:29 -0400 Date: Sun, 15 Sep 2019 21:04:26 -0500 From: Benjamin Kaduk To: Russ Housley Cc: IESG , LAMPS WG , Tim Hollebeek Message-ID: <20190916020426.GI22210@kduck.mit.edu> References: <156840184931.31866.4936814444231419124.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-cms-hash-sig-09: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 02:04:37 -0000 On Sun, Sep 15, 2019 at 06:35:45PM -0400, Russ Housley wrote: > > > > On Sep 13, 2019, at 3:10 PM, Benjamin Kaduk via Datatracker wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-lamps-cms-hash-sig-09: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-hash-sig/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Two fairly minor points that should be easy to resolve, but seem to be > > worth some time: > > > > I think we need to be a bit more clear about what exactly the contents > > of the signature OCTET STRING are. Section 3 has a fairly abstract note > > about including enough information to be self-describing (within the > > HSS/LMS variants), and Section 5 does better with "the single HSS > > signature value resulting from the signing operation as specified in > > [HASHSIG]", but it doesn't seem too burdensome to say something like > > "the string returned from Algorithm 3 in [RFC8554]" or even refer back > > to the description language at the end of Section 2 and avoid any > > confusion. > > I suggest: > > The signature value is a large OCTET STRING as described in Section 2 > of this document. The signature format is designed for easy parsing. > The HSS, LMS, and LMOTS component of the signature value each format > include a counter and a type code that indirectly providing all of > the information that is needed to parse the value during signature > validation. This is for the Section 3 text? I think that works for me, thanks. > > Section 5 has a "MUST" for using the same hash for the CMS > > digestAlgorithm and the HSS/LMS tree, but Section 6 only has a "SHOULD" > > for the message-digest attribute's digest and the signed attributes > > digest (the latter of which MUST be the HSS/LMS hash per the previous); > > should these two requirements be at the same level of normativity? I'm > > not sure why the one would be more important for correct operation than > > the other. > > The MUST comes from discussion on the mail list. Please see: > > https://mailarchive.ietf.org/arch/msg/spasm/ZJnHLMAsi8229TWUiDZUMN0noFM > > As you can see from Scott's message, the design in RFC 8554 expects the same hash to be used in both places. Indeed, thanks for the pointer. > Currently, CMS does not require the same hash algorithm to be used to compute the message digest of the content and the signed attributes (if any are present). RFC 6211 points out that it is normal practice for them to be the same. I would argue that it is time for an update to RFC 5652 to REQUIRE them to be the same, but that should not fall to this document. Agreed; this is not the right place to do so. Thanks for the explanation; I'll go clear now. > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Section 1 > > > > based digital signature, and it is described in [HASHSIG]. The > > HSS/LMS signature algorithm can only be used for a fixed number of > > signing operations. [...] > > > > nit: with a given key > > Yes. ... with a given private key. > > > > use. A post-quantum cryptosystem [PQC] is a system that is secure > > against quantum computers that have more than a trivial number of > > quantum bits (qu-bits). It is open to conjecture when it will be > > > > nit(?): I'm much more used to seeing "q-bits" or "qbits" than "qu-bits". > > draft-hoffman-c2pq-05 uses "qubits". I'll drop the hypen. > > > Section 2.2 > > > > It's a bit unfortunate that we have to mix 0- (signed public keys) and > > 1-based (tree nodes) indexing, but it seems that this is inherent in RFC > > 8554 and not really avoidable in this document. > > Yes. I need to be aligned with [HASHSIG]. > > > Section 3 > > > > The signature value identifies the hash function used in the HSS/LMS > > tree. In [HASHSIG] only the SHA-256 hash function [SHS] is > > supported, but it also establishes an IANA registry [IANA-LMS] to > > permit the registration of additional hash functions in the future. > > > > (This pattern occurs in several places, but I pick an arbitrary one to > > comment on) I am not sure that the "In [HASHSIG] only is > > supported, but it also establishes an IANA registry" is going to present > > the best interface to readers; the language in Section 2 about "the > > algorithm specified in [HASHSIG] currently only uses , but it also > > establishes an IANA registry to permit the registration of additional > > [...]" seems to give more emphasis on the registry as opposed to the > > snapshot in [HASHSIG]. On the other hand, someone is probably going to > > complain that "currently" will not age well... > > I suggest: > > ... The hash-based signature > algorithm specified in [HASHSIG] uses only the SHA-256 one-way hash > function [SHS], but it establishes an IANA registry [IANA-LMS] to > permit the registration of additional one-way hash functions in the > future. Sure, that takes care of the potential misread I was worried about. > > Section 4 > > > > It feels a little surprising to make explicit requirements on the > > keyUsage contents but not say anything about extendedKeyUsage. Having a > > static whitelist of EKU OIDs is not reasonable, of course, and the > > PUBLIC-KEY class from RFC 5912 only covers regular keyUsage, but some > > advice about "encipherment methods are not going to make sense" might > > still be appropriate. > > That is what the "it MUST NOT contain other values" does. RFC 5280 define the keyUsage bits as: > > KeyUsage ::= BIT STRING { > digitalSignature (0), > nonRepudiation (1), -- recent editions of X.509 have > -- renamed this bit to contentCommitment > keyEncipherment (2), > dataEncipherment (3), > keyAgreement (4), > keyCertSign (5), > cRLSign (6), > encipherOnly (7), > decipherOnly (8) } That's true, but does not seem relevant to extendedKeyUsage (unless you are saying that restrictions on keyUsage somehow supersede usage of extendedKeyUsage?) -- I understand what we are saying about keyUsage, and wonder if we can say anything useful about extendedKeyUsage in an analogous fashion. > > The public key value is an OCTET STRING. Like the signature format, > > it is designed for easy parsing. The value is the number of levels > > in the public key, L, followed by the LMS public key. > > > > The HSS/LMS public key value can be summarized as: > > > > u32str(L) || lms_public_key > > > > "Can be summarized as" does not say to me "here is a rigorous protocol > > specification" (though it does seem to actually be one, given the > > notation used in this document and 8554). So unlike the signature OCTET > > STRING contents, this one is not DISCUSS-worthy, since it's in the same > > section as the thing being described. > > It would be better to say: > > The HSS/LMS public key value can be described as: Okay. > > Section 5 > > > > When signed attributes are absent, the HSS/LMS signature is computed > > over the content. When signed attributes are present, a hash is > > computed over the content using the same hash function that is used > > in the HSS/LMS tree, and then a message-digest attribute is > > constructed to contain the resulting hash value, and then the result > > of DER encoding the set of signed attributes (which MUST include a > > content-type attribute and a message-digest attribute, and then the > > HSS/LMS signature is computed over the DER-encoded output. In > > > > nit(?): is this "the message-digest attribute" constructed in the > > previous step (as opposed to any old message-digest attribute)? > > I hope this is more clear: > > When signed attributes are absent, the HSS/LMS signature is computed > over the content. When signed attributes are present, a hash is > computed over the content using the same hash function that is used > in the HSS/LMS tree, and then a message-digest attribute is > constructed with the hash of the content, and then the HSS/LMS > signature is computed over the DER-encoded set of signed attributes > (which MUST include a content-type attribute and a message-digest > attribute). In summary: I think my pedantic quibble ("a message-digest attribute" vs. "the message-digest attribute [that we just talked about]") still applies to this text, though the probability of a misreading seems low. > IF (signed attributes are absent) > THEN HSS_LMS_Sign(content) > ELSE message-digest attribute = Hash(content); > HSS_LMS_Sign(DER(SignedAttributes)) > > > Section 6 > > > > tracking data can cause a one-time key to be used more than once. As > > a result, when a private key and the tracking data are stored on non- > > volatile media or stored in a virtual machine environment, care must > > be taken to preserve confidentiality and integrity. > > > > It might be worth explicitly noting "in the face of failed writes, > > virtual machine snapshotting or cloning, and other operational > > concerns". > > I suggest: > > Implementations MUST protect the private keys. Compromise of the > private keys may result in the ability to forge signatures. Along > with the private key, the implementation MUST keep track of which > leaf nodes in the tree have been used. Loss of integrity of this > tracking data can cause a one-time key to be used more than once. As > a result, when a private key and the tracking data are stored on non- > volatile media or stored in a virtual machine environment, failed > writes, virtual machine snapshotting or cloning, and other > operational concerns must be considered to ensure confidentiality and > integrity. Sure, that works. > > Appendix: ASN.1 Module > > > > MTS-HashSig-2013 > > > > Once written, the module name can never change? :) > > Once the OID is assigned to a string, it would be bad form to change it. Is it also bad form to have the module associated with the OID change after the OID is assigned? (I didn't check whether this one actually changed since 2003.) Thanks, Ben From nobody Sun Sep 15 21:16:40 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F32412008D; Sun, 15 Sep 2019 21:16:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-lamps-cms-hash-sig@ietf.org, Tim Hollebeek , lamps-chairs@ietf.org, tim.hollebeek@digicert.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.101.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <156860739125.20757.8743104391323500131.idtracker@ietfa.amsl.com> Date: Sun, 15 Sep 2019 21:16:31 -0700 Archived-At: Subject: [lamps] Benjamin Kaduk's No Objection on draft-ietf-lamps-cms-hash-sig-09: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 04:16:32 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-lamps-cms-hash-sig-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-hash-sig/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the discussion around my Discuss points, and the updates in response to my comments! From nobody Mon Sep 16 09:33:47 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F29F1200B9 for ; Mon, 16 Sep 2019 09:33:45 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 lVmBmS47mixR for ; Mon, 16 Sep 2019 09:33:43 -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 3A62F12004F for ; Mon, 16 Sep 2019 09:33:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BB900300A2F for ; Mon, 16 Sep 2019 12:33:41 -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 o0FCkXxvmfnH for ; Mon, 16 Sep 2019 12:33:34 -0400 (EDT) Received: from [5.5.33.45] (unknown [204.194.23.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 8B7343004AF; Mon, 16 Sep 2019 12:33:34 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <20190916020426.GI22210@kduck.mit.edu> Date: Mon, 16 Sep 2019 12:33:34 -0400 Cc: IESG , LAMPS WG , Tim Hollebeek Content-Transfer-Encoding: quoted-printable Message-Id: References: <156840184931.31866.4936814444231419124.idtracker@ietfa.amsl.com> <20190916020426.GI22210@kduck.mit.edu> To: Ben Kaduk X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-cms-hash-sig-09: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 16:33:46 -0000 Ben: Dropping the resolved parts ... >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> Two fairly minor points that should be easy to resolve, but seem to = be >>> worth some time: >>>=20 >>> I think we need to be a bit more clear about what exactly the = contents >>> of the signature OCTET STRING are. Section 3 has a fairly abstract = note >>> about including enough information to be self-describing (within the >>> HSS/LMS variants), and Section 5 does better with "the single HSS >>> signature value resulting from the signing operation as specified in >>> [HASHSIG]", but it doesn't seem too burdensome to say something like >>> "the string returned from Algorithm 3 in [RFC8554]" or even refer = back >>> to the description language at the end of Section 2 and avoid any >>> confusion. >>=20 >> I suggest: >>=20 >> The signature value is a large OCTET STRING as described in Section = 2 >> of this document. The signature format is designed for easy = parsing. >> The HSS, LMS, and LMOTS component of the signature value each = format >> include a counter and a type code that indirectly providing all of >> the information that is needed to parse the value during signature >> validation. >=20 > This is for the Section 3 text? I think that works for me, thanks. Yes, this text goes in Section 3. [snip] >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 [snip] >>> Section 4 >>>=20 >>> It feels a little surprising to make explicit requirements on the >>> keyUsage contents but not say anything about extendedKeyUsage. = Having a >>> static whitelist of EKU OIDs is not reasonable, of course, and the >>> PUBLIC-KEY class from RFC 5912 only covers regular keyUsage, but = some >>> advice about "encipherment methods are not going to make sense" = might >>> still be appropriate. >>=20 >> That is what the "it MUST NOT contain other values" does. RFC 5280 = define the keyUsage bits as: >>=20 >> KeyUsage ::=3D BIT STRING { >> digitalSignature (0), >> nonRepudiation (1), -- recent editions of X.509 = have >> -- renamed this bit to = contentCommitment >> keyEncipherment (2), >> dataEncipherment (3), >> keyAgreement (4), >> keyCertSign (5), >> cRLSign (6), >> encipherOnly (7), >> decipherOnly (8) } >=20 > That's true, but does not seem relevant to extendedKeyUsage (unless = you are > saying that restrictions on keyUsage somehow supersede usage of > extendedKeyUsage?) -- I understand what we are saying about keyUsage, = and > wonder if we can say anything useful about extendedKeyUsage in an = analogous > fashion. Because extendedKeyUsage is an object identifier, more are defined all = the time, and they usually say something about protocol context. These = are defined in RFC 5280: id-kp-serverAuth OBJECT IDENTIFIER ::=3D { id-kp 1 } -- TLS WWW server authentication -- Key usage bits that may be consistent: digitalSignature, -- keyEncipherment or keyAgreement id-kp-clientAuth OBJECT IDENTIFIER ::=3D { id-kp 2 } -- TLS WWW client authentication -- Key usage bits that may be consistent: digitalSignature -- and/or keyAgreement id-kp-codeSigning OBJECT IDENTIFIER ::=3D { id-kp 3 } -- Signing of downloadable executable code -- Key usage bits that may be consistent: digitalSignature id-kp-emailProtection OBJECT IDENTIFIER ::=3D { id-kp 4 } -- Email protection -- Key usage bits that may be consistent: digitalSignature, -- nonRepudiation, and/or (keyEncipherment or keyAgreement) So, for algorithms (without any protocol context) we only say anything = about keyUsage. You can see this in RFC 3279, Section 2.3.. Russ= From nobody Mon Sep 16 14:14:27 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8FA9120118 for ; Mon, 16 Sep 2019 14:14:24 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 6FF3E2oj6oC8 for ; Mon, 16 Sep 2019 14:14:23 -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 0C4D81200DB for ; Mon, 16 Sep 2019 14:14:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 603DC300ABB for ; Mon, 16 Sep 2019 17:14:21 -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 JhQxVQOxyNUt for ; Mon, 16 Sep 2019 17:14:19 -0400 (EDT) Received: from [5.5.33.49] (unknown [204.194.23.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 46CD5300577; Mon, 16 Sep 2019 17:14:19 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <156824031769.13397.11560883765399298866.idtracker@ietfa.amsl.com> Date: Mon, 16 Sep 2019 17:14:19 -0400 Cc: IESG , Tim Hollebeek , LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: <0D4923CE-0775-411D-8B38-B7C0121ECC5F@vigilsec.com> References: <156824031769.13397.11560883765399298866.idtracker@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Barry Leiba's No Objection on draft-ietf-lamps-cms-hash-sig-09: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 21:14:25 -0000 Barry: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks, Russ, as always, for a clear and well-written document. Thanks for the careful review. > Some editorial nits: >=20 > =E2=80=94 Section 1.3 =E2=80=94 >=20 > Each of these advances pose a > threat to widely deployed digital signature algorithms. >=20 > =E2=80=9Cposes=E2=80=9D, to match the singular =E2=80=9Ceach=E2=80=9D. Fixed. > Recent advances in cryptoanalysis [BH2013] >=20 > =E2=80=9Ccryptanalysis=E2=80=9D, no =E2=80=9Co=E2=80=9D. Indeed. Fixed. > The HSS/LMS signature algorithm does not depend on the difficulty of > discrete logarithm or factoring, as a result these algorithms are >=20 > Comma splice. Make it a semicolon. How about: Since the HSS/LMS signature algorithm does not depend on the difficulty of discrete logarithm or factoring, the HSS/LMS signature algorithm is considered to be post-quantum secure. > =E2=80=94 Section 2.2 =E2=80=94 >=20 > The second parameter is > the number of bytes output by the hash function, m, which is the > amount of data associated with each node in the tree. >=20 > It=E2=80=99s a small thing, but I think the =E2=80=9Cm=E2=80=9D is = misplaced where it is, and suggest > =E2=80=9C=E2=80=A6the number of bytes, m, output by the hash = function=E2=80=A6.=E2=80=9D How about: The second parameter is the number of bytes output by the hash function, m, and it is the amount of data associated with each node in the tree.=20 > =E2=80=94 Section 3 =E2=80=94 >=20 > Each format includes a counter and type > codes that indirectly providing all of the information that is = needed >=20 > =E2=80=9Cprovide=E2=80=9D Fixed. > =E2=80=94 Section 5 =E2=80=94 >=20 > When signed attributes are absent, the HSS/LMS signature is computed > over the content. When signed attributes are present, a hash is > computed over the content using the same hash function that is used > in the HSS/LMS tree, and then a message-digest attribute is > constructed to contain the resulting hash value, and then the result > of DER encoding the set of signed attributes (which MUST include a > content-type attribute and a message-digest attribute, and then the > HSS/LMS signature is computed over the DER-encoded output. >=20 > You=E2=80=99re missing a =E2=80=9C)=E2=80=9D there, which makes it a = bit odd. I think it should be > =E2=80=9C(which MUST include a content-type attribute and a = message-digest attribute), > and then=E2=80=A6.=E2=80=9D This text was changed to address a comment from Ben Kaduk. It now says: When signed attributes are absent, the HSS/LMS signature is computed over the content. When signed attributes are present, a hash is computed over the content using the same hash function that is used in the HSS/LMS tree, and then a message-digest attribute is constructed with the hash of the content, and then the HSS/LMS signature is computed over the DER-encoded set of signed attributes (which MUST include a content-type attribute and a message-digest attribute). In summary: IF (signed attributes are absent) THEN HSS_LMS_Sign(content) ELSE message-digest attribute =3D Hash(content); HSS_LMS_Sign(DER(SignedAttributes)) > digestAlgorithm MUST contain the one-way hash function used to = in > the HSS/LMS tree. >=20 > Remove =E2=80=9Cto=E2=80=9D. Fixed. > =E2=80=94 Section 6 =E2=80=94 >=20 > While the consequences of an inadequate pseudo-random > number generator (PRNGs) to generate these values is much less = severe > than the generation of private keys >=20 > =E2=80=9Cthan in the generation=E2=80=9D Sure. Fixed. > =E2=80=94 Appendix =E2=80=94 > Just a note that I did not review the ASN.1 module. Gee, why not? ;-) Russ From nobody Mon Sep 16 14:47:16 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3CB8120124; Mon, 16 Sep 2019 14:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, SPF_HELO_NONE=0.001, 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 3g5iB8y5pygg; Mon, 16 Sep 2019 14:47:01 -0700 (PDT) Received: from mail-io1-f42.google.com (mail-io1-f42.google.com [209.85.166.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7DD1200DB; Mon, 16 Sep 2019 14:47:01 -0700 (PDT) Received: by mail-io1-f42.google.com with SMTP id b19so2693823iob.4; Mon, 16 Sep 2019 14:47:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SUXsRnuB9tkTiFZKtOXBIskJkXpsUpfqiPbDwZWIUWQ=; b=oP5prjd14b8KVr6T+ETOSy7dgXT8gm8xKTX7uolNH9friWoyEaWLvzGKN/ZNcoXaJk dv5jbB75r8ltb87fEsDL8XNwpQ3tOADgeCgIkRiP0rmQTTMmVSNBlhcKR98Kp57zRPJd cl3vmWElPCgMI0RFRfFCineqyqQ2waVqhh7WiTqfKQTYKNlR+BRhTbTbbbltSzF94MCZ KRGaU5ooKYztyZvmCl3fDbleK7+E2w0hA6LdT6rqsnWyN/qR3E5vjHIXH1cGu8/wmaHX +WpyoMVzb4DXyX9w3GoTI3zOPy2cLxqdTAord84iwOzawOhU89t87gVoiN0syT9+U8O0 MkdA== X-Gm-Message-State: APjAAAV/9Av71P3z/rYY0yfvBM8hta2KEHEMkMFrpOcnlKMBXkgfs3aE phInck1jr8S+sY0rjgGVcIBuBZ4Jo+/MO+Fi/R2LRuTx X-Google-Smtp-Source: APXvYqylMel/kV/j31fVD3YkVTXLwBA3NYWayan0GIflXUDvRa6Vy5Bq+fMSXVSdXBaPh6D7VKU2iX1EObyMqe9Vf0A= X-Received: by 2002:a6b:1787:: with SMTP id 129mr563715iox.140.1568670420147; Mon, 16 Sep 2019 14:47:00 -0700 (PDT) MIME-Version: 1.0 References: <156824031769.13397.11560883765399298866.idtracker@ietfa.amsl.com> <0D4923CE-0775-411D-8B38-B7C0121ECC5F@vigilsec.com> In-Reply-To: <0D4923CE-0775-411D-8B38-B7C0121ECC5F@vigilsec.com> From: Barry Leiba Date: Mon, 16 Sep 2019 14:46:48 -0700 Message-ID: To: Russ Housley Cc: IESG , Tim Hollebeek , LAMPS WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [lamps] Barry Leiba's No Objection on draft-ietf-lamps-cms-hash-sig-09: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 21:47:07 -0000 Thanks for the reply, Russ. Just on the one thing that remains open; on the rest, all is good: > > =E2=80=94 Section 2.2 =E2=80=94 > > > > The second parameter is > > the number of bytes output by the hash function, m, which is the > > amount of data associated with each node in the tree. > > > > It=E2=80=99s a small thing, but I think the =E2=80=9Cm=E2=80=9D is misp= laced where it is, and suggest > > =E2=80=9C=E2=80=A6the number of bytes, m, output by the hash function= =E2=80=A6.=E2=80=9D > > How about: > > The second parameter is > the number of bytes output by the hash function, m, and it is the > amount of data associated with each node in the tree. It retains the fault that "m" is not the hash function, and "by the hash function, m," makes it look like it is. I still think you're better off moving "m" to one of these positions: "The second parameter, m, is the number of bytes output by the hash functio= n" "The second parameter is the number of bytes, m, output by the hash functio= n" But I'll grant that I'm being picky about the wording, and that it's not likely to be confusing in practice. So if you think it's best with the "m" where you have it, we're done here, and thanks for considering my suggestions and accepting most of them. Barry From nobody Mon Sep 16 14:50:23 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FB71201CE for ; Mon, 16 Sep 2019 14:50:09 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 JoGg-mJGz4Qu for ; Mon, 16 Sep 2019 14:50:07 -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 45F8512011D for ; Mon, 16 Sep 2019 14:50:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A8D55300B0C for ; Mon, 16 Sep 2019 17:50:05 -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 FEvCcfGMNIJT for ; Mon, 16 Sep 2019 17:50:04 -0400 (EDT) Received: from [5.5.33.49] (unknown [204.194.23.17]) by mail.smeinc.net (Postfix) with ESMTPSA id B6AA6300577; Mon, 16 Sep 2019 17:50:03 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: Date: Mon, 16 Sep 2019 17:50:04 -0400 Cc: IESG , Tim Hollebeek , LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <156824031769.13397.11560883765399298866.idtracker@ietfa.amsl.com> <0D4923CE-0775-411D-8B38-B7C0121ECC5F@vigilsec.com> To: Barry Leiba X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Barry Leiba's No Objection on draft-ietf-lamps-cms-hash-sig-09: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 21:50:12 -0000 > On Sep 16, 2019, at 5:46 PM, Barry Leiba = wrote: >=20 > Thanks for the reply, Russ. Just on the one thing that remains open; > on the rest, all is good: >=20 >>> =E2=80=94 Section 2.2 =E2=80=94 >>>=20 >>> The second parameter is >>> the number of bytes output by the hash function, m, which is the >>> amount of data associated with each node in the tree. >>>=20 >>> It=E2=80=99s a small thing, but I think the =E2=80=9Cm=E2=80=9D is = misplaced where it is, and suggest >>> =E2=80=9C=E2=80=A6the number of bytes, m, output by the hash = function=E2=80=A6.=E2=80=9D >>=20 >> How about: >>=20 >> The second parameter is >> the number of bytes output by the hash function, m, and it is the >> amount of data associated with each node in the tree. >=20 > It retains the fault that "m" is not the hash function, and "by the > hash function, m," makes it look like it is. I still think you're > better off moving "m" to one of these positions: >=20 > "The second parameter, m, is the number of bytes output by the hash = function" > "The second parameter is the number of bytes, m, output by the hash = function" >=20 > But I'll grant that I'm being picky about the wording, and that it's > not likely to be confusing in practice. So if you think it's best > with the "m" where you have it, we're done here, and thanks for > considering my suggestions and accepting most of them. I guess I missed your point on the first reading. How about: The second parameter, m, is the number of bytes output by the hash function, and it is the amount of data associated with each node in the tree. Russ From nobody Mon Sep 16 14:53:06 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA3812011A; Mon, 16 Sep 2019 14:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, SPF_HELO_NONE=0.001, 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 4gOSsVHFTYKx; Mon, 16 Sep 2019 14:52:54 -0700 (PDT) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395AB1200EB; Mon, 16 Sep 2019 14:52:54 -0700 (PDT) Received: by mail-io1-f54.google.com with SMTP id q1so2777317ion.1; Mon, 16 Sep 2019 14:52:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=RDRY9RylSsFmffQeMT87a21f0guEwT5460Cv5Bu20bU=; b=gaBTpbQ2wgefpXdHzPrnfgDq47ga8LiFNwP+1d/sMUm87X1+NZQAkjFBL+G7qLfPag DG9BuLMMEta2xdxvSr1WaLzAwwxTl9oKvnCafpSXK4Z7kaFhEPOMqvxBfuT3LxxUOhni F5zDepbctI0J+HHmTQfsqU7wVALuqZJnYf8kM1Gjc71SuUXprOd4KueASpzu/Qgdm8tA KGjDouXih7Riqq6dvjxNLISrobsWdK56pd7yh4wkQsPNDWIwBX59r6QASXHoj7jrGM/r WE48YzX2wu/8ZU4xhwVxm3CdgFFkp0r/cWtgW6qVwEKu9Fiuznrp728X9WYvMIged7Oh rBDw== X-Gm-Message-State: APjAAAV89DjVImFwPeoenfETyeu+ua3/LEJBvHQpQApIBlmI5b5NUfeF Uhc4mnQw/Xe2dJAilWg0H/0DOAqhOsXDbx9zn0k= X-Google-Smtp-Source: APXvYqwawEfh3B5NVoqxLecYFV4UF3hdeLhxd5Gzx0LbsF1j483MoDiL4mZd+QtWoIWWtOOJZyITMsHahMEjhGxG5fA= X-Received: by 2002:a02:c546:: with SMTP id g6mr226537jaj.59.1568670773326; Mon, 16 Sep 2019 14:52:53 -0700 (PDT) MIME-Version: 1.0 References: <156824031769.13397.11560883765399298866.idtracker@ietfa.amsl.com> <0D4923CE-0775-411D-8B38-B7C0121ECC5F@vigilsec.com> In-Reply-To: From: Barry Leiba Date: Mon, 16 Sep 2019 14:52:42 -0700 Message-ID: To: Russ Housley Cc: IESG , Tim Hollebeek , LAMPS WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [lamps] Barry Leiba's No Objection on draft-ietf-lamps-cms-hash-sig-09: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 21:52:56 -0000 Perfect; thanks. b On Mon, Sep 16, 2019 at 2:50 PM Russ Housley wrote: > > > > > On Sep 16, 2019, at 5:46 PM, Barry Leiba wrot= e: > > > > Thanks for the reply, Russ. Just on the one thing that remains open; > > on the rest, all is good: > > > >>> =E2=80=94 Section 2.2 =E2=80=94 > >>> > >>> The second parameter is > >>> the number of bytes output by the hash function, m, which is the > >>> amount of data associated with each node in the tree. > >>> > >>> It=E2=80=99s a small thing, but I think the =E2=80=9Cm=E2=80=9D is mi= splaced where it is, and suggest > >>> =E2=80=9C=E2=80=A6the number of bytes, m, output by the hash function= =E2=80=A6.=E2=80=9D > >> > >> How about: > >> > >> The second parameter is > >> the number of bytes output by the hash function, m, and it is the > >> amount of data associated with each node in the tree. > > > > It retains the fault that "m" is not the hash function, and "by the > > hash function, m," makes it look like it is. I still think you're > > better off moving "m" to one of these positions: > > > > "The second parameter, m, is the number of bytes output by the hash fun= ction" > > "The second parameter is the number of bytes, m, output by the hash fun= ction" > > > > But I'll grant that I'm being picky about the wording, and that it's > > not likely to be confusing in practice. So if you think it's best > > with the "m" where you have it, we're done here, and thanks for > > considering my suggestions and accepting most of them. > > I guess I missed your point on the first reading. > > How about: > > The second parameter, m, > is the number of bytes output by the hash function, and it is the > amount of data associated with each node in the tree. > > Russ > From nobody Tue Sep 17 10:53:49 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 751B6120A05; Tue, 17 Sep 2019 10:53:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.101.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <156874282638.17545.1124490758819491932@ietfa.amsl.com> Date: Tue, 17 Sep 2019 10:53:46 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-18.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 17:53:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Use of the SHAKE One-way Hash Functions in the Cryptographic Message Syntax (CMS) Authors : Panos Kampanakis Quynh Dang Filename : draft-ietf-lamps-cms-shakes-18.txt Pages : 19 Date : 2019-09-17 Abstract: This document updates the "Cryptographic Message Syntax Algorithms" (RFC3370) and describes the conventions for using the SHAKE family of hash functions in the Cryptographic Message Syntax as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms. The conventions for the associated signer public keys in CMS are also described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-shakes-18 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-shakes-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-shakes-18 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 17 11:00:45 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D059E120127 for ; Tue, 17 Sep 2019 11:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=YZUkd/cj; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=St+804Eq 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 JpqRozFOlL5Z for ; Tue, 17 Sep 2019 11:00:41 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 358B1120112 for ; Tue, 17 Sep 2019 11:00:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2115; q=dns/txt; s=iport; t=1568743241; x=1569952841; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=oezKS+bpoOJfeZcKL8+VcL6eXtl7oBSaVud5/DfARXs=; b=YZUkd/cjOLRFv6fCvyDin4h67oQ+nXedBJ46LM+xeYUwzhYhdaxQ1nZL b2zSigaszFHZlI5wuX2BSKlS7O+NCDKGwXo22PN3CkP+RPcN2ZDADp+Jj 131SVywL/MxGhvY0DyQkBU1ftbXzRbIV8MRMXdQEM8YHQotI5/OxpEXqE E=; IronPort-PHdr: =?us-ascii?q?9a23=3AUx4VURzt/nsRn+7XCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZudCkT+NPfsZgQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAADBHoFd/5hdJa1mHQEBBQEHBQG?= =?us-ascii?q?BUwgBCwGBRCQsA21WIAQLKodoA4RShiVNgg+XcoEugSQDVAkBAQEMAQEYCwo?= =?us-ascii?q?CAQGEPwKCfCM0CQ4CAwkBAQQBAQECAQUEbYUuAQuFSgEBAQQBARAoBgEBLAw?= =?us-ascii?q?LBAIBCBEEAQEfECcLHQgCBBMIGoMBgWoDHQECDKNPAoE4iGGCJYJ9AQEFgTc?= =?us-ascii?q?CDkGDCRiCFwmBNAGLdxiBQD+BEUaCTD6CYQEBAgEBFoEgKYM7giascwqCIoc?= =?us-ascii?q?FjheCNXGGVo8ejgqIDI0fg1kCBAIEBQIOAQEFgVI4gUIOCHAVGiGCbAmCOQs?= =?us-ascii?q?Yg0+FFIU/c4EpjHmCVAEB?= X-IronPort-AV: E=Sophos;i="5.64,517,1559520000"; d="scan'208";a="545164607" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Sep 2019 18:00:40 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x8HI0eGH019747 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 17 Sep 2019 18:00:40 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 17 Sep 2019 13:00:39 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 17 Sep 2019 13:00:39 -0500 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 17 Sep 2019 13:00:39 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RDZkHULFP9N5NU1uwh7bq5QYUJ3d5IC36cwHjIHlLPU2M0tFy+8LyVliIqA4KQtEoAwOieo30T/t8zeXbknN0WRIDKr3U8ozscmV2huOmow+PQRGBqPJ2yza4HF2hnIgAYBydh2GfWafNfgdqzH+LbjJQHj0B9SYxnEGVlICoZKYo+nH0sPM3JNCfEL6npNcdNcThpSspl54GhXReCok/b/rapiSM3TNrJEcw2vs30QKSnuA7TvOTef6JwUrRbf63oJK0MDWc9tbwq40e/aS5zctDb9JR2uqZQ/F159SycJng2hEAdcYMwvpVDqsPEvUjt+a6218JqkPvgpek1zIwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FIyZJPsbAfI8ykEnDT3zs2DOagvYf4BcnN4z5ODHZQc=; b=MKM46xac3MxznxDY3ev+Bytp74zh3J13g4LQiCfwA4eUTa5yjkpZVhNjND+jQG6QjYG3r0OqVl6dhWtrFAPkK4t6nwj7pNsBwy8gvTr5ghfHUIxgtM9s7xLeNITKw2TcsOxvfHQ2/PhDTdTw5qrHw+NxaB6uBfaKwo84HL6orZI3JsrNCifXo4+WB89EPW1DAwuBD8wiMfF9QxmT57wrmWjZsoXwp+gLApkuB70GJZcHJqhvGMZ4dMS9ij0G314LvVge53sEJhHR2r1VKxkbM+8mSGhM5tUmELlnGCnNkSILWBxLZ8Ku1TBTklsbOBw8+qsOxXA4BHukvvrvFUDJMw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FIyZJPsbAfI8ykEnDT3zs2DOagvYf4BcnN4z5ODHZQc=; b=St+804EqdBYVq2PyTEO0T/Qt7nWfc1kYLqP8fQFzPUqd1o3odlIyLETciAEYte4tFNHdJqVSpAd9DzAvgJjuMUFYY9qTWmAGrWqAMEJKfoMjgcGP0xMO8K+AgX41K+eWB12ISAEfVD+gGtnU/aSWzMSY3f9ySEDKZKSzPGg+Mg4= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2594.namprd11.prod.outlook.com (52.135.246.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.21; Tue, 17 Sep 2019 18:00:37 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::20df:b3df:537d:fd20]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::20df:b3df:537d:fd20%7]) with mapi id 15.20.2263.023; Tue, 17 Sep 2019 18:00:37 +0000 From: "Panos Kampanakis (pkampana)" To: "spasm@ietf.org" Thread-Topic: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-18.txt Thread-Index: AQHVbYDhgA0ksIMBekKgsQPUbZzn86cwKEVA Date: Tue, 17 Sep 2019 18:00:37 +0000 Message-ID: References: <156874282638.17545.1124490758819491932@ietfa.amsl.com> In-Reply-To: <156874282638.17545.1124490758819491932@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:2090:1009:aca3:b2e5:c7a:faaa] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5e24781e-6c38-49fe-04e7-08d73b98f204 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600167)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN7PR11MB2594; x-ms-traffictypediagnostic: BN7PR11MB2594: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 01630974C0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(396003)(136003)(366004)(346002)(199004)(189003)(13464003)(8676002)(81156014)(1730700003)(81166006)(8936002)(11346002)(966005)(486006)(76116006)(6506007)(66574012)(46003)(14454004)(66476007)(66556008)(66446008)(2351001)(476003)(53546011)(305945005)(64756008)(25786009)(66946007)(186003)(229853002)(5640700003)(446003)(478600001)(7696005)(99286004)(55016002)(5660300002)(9686003)(6116002)(6306002)(6436002)(6246003)(71200400001)(71190400001)(74316002)(102836004)(7736002)(6916009)(2501003)(52536014)(316002)(86362001)(76176011)(256004)(33656002)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2594; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ZgrstkF8CL2fQPmDWodvzvLrvPilbQyfLAGhmWaPYJtMAS/pv4ulqDKf21QZlFt+qe2GBOp1TjoOMhyUgXmRCpV/h8h3SHquRvJDYi22z3zTCJEc3MVs8dzuqAvlGmkRhiO+0LQxHUrxMJhI7oSYNoArvsRQvSGuFkX3YeukVLXVWwbFgSHdXbnfWw+jKwJaVFCCBooKMXdMhIbdcW9rh1AURMqi8VNw0OfGbpP1rGIHV8UiLBD0Oe/9QRo7YYd/gZ9kk/3bJTekAX/gzOFv+9z8II5d08RLVggYc8Hh1qydo8Xe2yh60jegW+jfDITA6LoBGoma0mA3OhS1nfdKPBBLvZQTrZCvrnuqA5Nx4nk8Xi9b/GjdWeKLBZOE+3rKW3PUSAykoNIkK756pI2DQdF/2rj0bPWsl8ZNqT9bfxE= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5e24781e-6c38-49fe-04e7-08d73b98f204 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2019 18:00:37.6232 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: KSJw567gXkNFheKP+tr9INm6SgL+Mopnj+0MtGgDpeIO1HePLKqluiwRr6Tva2hgtX/dqxlsE8VgeX79dyeu/Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2594 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-18.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 18:00:44 -0000 This draft just updates the IANA assigned OIDs that were previously TBDs an= d fixes a couple of ASN.1 minor issues found by Russ.=20 Thanks Russ.=20 -----Original Message----- From: Spasm On Behalf Of internet-drafts@ietf.org Sent: Tuesday, September 17, 2019 1:54 PM To: i-d-announce@ietf.org Cc: spasm@ietf.org Subject: [lamps] I-D Action: draft-ietf-lamps-cms-shakes-18.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Limited Additional Mechanisms for PKIX and= SMIME WG of the IETF. Title : Use of the SHAKE One-way Hash Functions in the Cr= yptographic Message Syntax (CMS) Authors : Panos Kampanakis Quynh Dang Filename : draft-ietf-lamps-cms-shakes-18.txt Pages : 19 Date : 2019-09-17 Abstract: This document updates the "Cryptographic Message Syntax Algorithms" (RFC3370) and describes the conventions for using the SHAKE family of hash functions in the Cryptographic Message Syntax as one-way hash functions with the RSA Probabilistic signature and ECDSA signature algorithms. The conventions for the associated signer public keys in CMS are also described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-shakes/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-shakes-18 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-shakes-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-shakes-18 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Tue Sep 17 15:07:32 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA1C12011A; Tue, 17 Sep 2019 15:07:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Vigoureux via Datatracker To: "The IESG" Cc: draft-ietf-lamps-cms-hash-sig@ietf.org, Tim Hollebeek , lamps-chairs@ietf.org, tim.hollebeek@digicert.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.101.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Vigoureux Message-ID: <156875805038.17465.814848713453844421.idtracker@ietfa.amsl.com> Date: Tue, 17 Sep 2019 15:07:30 -0700 Archived-At: Subject: [lamps] Martin Vigoureux's No Record on draft-ietf-lamps-cms-hash-sig-09: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 22:07:31 -0000 Martin Vigoureux has entered the following ballot position for draft-ietf-lamps-cms-hash-sig-09: No Record When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-hash-sig/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi thank you for this document. There have been recent advances in cryptanalysis and advances in the development of quantum computers. Each of these advances pose a threat to widely deployed digital signature algorithms. Recent advances in cryptoanalysis [BH2013] and progress in the development of quantum computers [NAS2019] pose a threat to widely deployed digital signature algorithms. looks redundant. -m From nobody Tue Sep 17 15:08:23 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5063812011A; Tue, 17 Sep 2019 15:08:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Vigoureux via Datatracker To: "The IESG" Cc: draft-ietf-lamps-cms-hash-sig@ietf.org, Tim Hollebeek , lamps-chairs@ietf.org, tim.hollebeek@digicert.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.101.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Vigoureux Message-ID: <156875809431.17488.13686721328758793354.idtracker@ietfa.amsl.com> Date: Tue, 17 Sep 2019 15:08:14 -0700 Archived-At: Subject: [lamps] Martin Vigoureux's No Objection on draft-ietf-lamps-cms-hash-sig-09: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 22:08:15 -0000 Martin Vigoureux has entered the following ballot position for draft-ietf-lamps-cms-hash-sig-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-hash-sig/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi thank you for this document. There have been recent advances in cryptanalysis and advances in the development of quantum computers. Each of these advances pose a threat to widely deployed digital signature algorithms. Recent advances in cryptoanalysis [BH2013] and progress in the development of quantum computers [NAS2019] pose a threat to widely deployed digital signature algorithms. looks redundant. -m From nobody Tue Sep 17 19:25:47 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7CE120219 for ; Tue, 17 Sep 2019 19:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 H0JGojeUr5rd for ; Tue, 17 Sep 2019 19:25:34 -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 AC4061201A3 for ; Tue, 17 Sep 2019 19:25:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 27556300AFF for ; Tue, 17 Sep 2019 22:25:33 -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 MBumohqVOK5x for ; Tue, 17 Sep 2019 22:25:31 -0400 (EDT) Received: from [5.5.33.20] (unknown [204.194.23.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 41256300577; Tue, 17 Sep 2019 22:25:31 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <156875805038.17465.814848713453844421.idtracker@ietfa.amsl.com> Date: Tue, 17 Sep 2019 22:25:31 -0400 Cc: IESG , LAMPS WG , Tim Hollebeek Content-Transfer-Encoding: quoted-printable Message-Id: <94E79ECE-4ACE-4E4F-9F2B-8CBEC7DE0167@vigilsec.com> References: <156875805038.17465.814848713453844421.idtracker@ietfa.amsl.com> To: Martin Vigoureux X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Martin Vigoureux's No Record on draft-ietf-lamps-cms-hash-sig-09: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 02:25:37 -0000 Martin: Sure. I'll delete the first one. Russ > On Sep 17, 2019, at 6:07 PM, Martin Vigoureux via Datatracker = wrote: >=20 > Martin Vigoureux has entered the following ballot position for > draft-ietf-lamps-cms-hash-sig-09: No Record >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-hash-sig/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Hi >=20 > thank you for this document. >=20 > There have been recent advances in cryptanalysis and advances in the > development of quantum computers. Each of these advances pose a > threat to widely deployed digital signature algorithms. >=20 > Recent advances in cryptoanalysis [BH2013] and progress in the > development of quantum computers [NAS2019] pose a threat to widely > deployed digital signature algorithms. >=20 > looks redundant. >=20 > -m >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Wed Sep 18 09:29:24 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A6412091D; Wed, 18 Sep 2019 09:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=cooperw.in header.b=jrZ7wWZV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=P0et3j+J 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 k_CDwtAkK03g; Wed, 18 Sep 2019 09:29:07 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 139BB120106; Wed, 18 Sep 2019 09:29:07 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 61E4F21FAE; Wed, 18 Sep 2019 12:29:06 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 18 Sep 2019 12:29:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=X ZT3y2shsMEGaTtiwe8XCyZJIpMMBZ9E4g96K5YdjEU=; b=jrZ7wWZV7eLZyfbpI 9ghqq1ExXNn88YPm1i6e1HBTNaXR3ltp1fUIp67OaNMtTXSY0gsa70+ZBN8MdNsR yg6ZtEfxiyGtQeq0hJ2O/6M3VonsKTaXr6O38Iutk2Xt5lcfPEBFMBgbJIG5iLIo hsB7L9UFw+Zuk30LPkAZvoEcAEQ9sH2kmMn965qan+EanAhBxh5m9Yr+ZoibNPuE /D10eRf0fhghnHWHGWHt7Fgil12BP9rnRRio98rUfPGKcMzqyEbmaMQVJQO4qJ+R LsyivVaONV/LtN0+bGYi/8MtWGbVFkAHFkSFoxA3vbUyMkuoWYFX3z7wdjy7fDVk MHWFg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=XZT3y2shsMEGaTtiwe8XCyZJIpMMBZ9E4g96K5Ydj EU=; b=P0et3j+J8FvL88Vq7PEpq5xsgZ3u2NiTf//y1l0Ier1ixTz1AepJveEvD i7ClARvQmx7FjAFfuW7X2Bwn7YQFp+9Tz/HDQFHRCqivsKcKQZEkVF+hDtG/iiD1 b8PdHt7nd4vWAt0S/DFGrWDsRABzlAF//SlK3EhDS2qId1R8a6oIMfCa8TC7oFfB Jjf1xiqA5JVxxKUDCSJQMeF5SRERTstumqKudPj6/hsellH7bocCHYwJyffO6bT2 1tEQFKIk/pwnG3+qbuFKecw9j8kKA2UxgSZmsZJ5coFgfOS8GM8a6+GkbNNmFgPl ViwFgNrVzvzzc1W/n7A8ilG9MQb9A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudekgddutdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrleefnecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsth gvrhfuihiivgeptd X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.93]) by mail.messagingengine.com (Postfix) with ESMTPA id 37FB480063; Wed, 18 Sep 2019 12:29:05 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <47826955-B512-4806-9971-211F4F4F24D0@vigilsec.com> Date: Wed, 18 Sep 2019 12:29:05 -0400 Cc: LAMPS WG , IETF Gen-ART , IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <156341753682.25805.15107717483258855258@ietfa.amsl.com> <47826955-B512-4806-9971-211F4F4F24D0@vigilsec.com> To: Russ Housley , Dale Worley X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] [Gen-art] Genart last call review of draft-ietf-lamps-cms-hash-sig-08 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 16:29:10 -0000 Dale, thanks for your review. Russ, thanks for your response. I entered = a No Objection ballot. Alissa > On Jul 18, 2019, at 10:19 AM, Russ Housley = wrote: >=20 > Dale: >=20 > Thank you for the careful review. >=20 >> Summary: >>=20 >> This draft is in great shape and ready for publication as a >> proposed standard RFC, with only a few editorial nits. >=20 > Good to hear. >=20 >> Nits/editorial comments:=20 >>=20 >> 2.2. Leighton-Micali Signature (LMS) >>=20 >> The [HASHSIG] specification supports five tree sizes: >>=20 >> LMS_SHA256_M32_H5; >> LMS_SHA256_M32_H10; >> LMS_SHA256_M32_H15; >> LMS_SHA256_M32_H20; and >> LMS_SHA256_M32_H25. >>=20 >> This text seems redundant with the description in the preceding >> paragraph. >=20 > True. The intent was to provide the identifiers for the five tree = sizes. >=20 > Perhaps the two paragraphs should be merged, with the sentence before = the list saying: >=20 > ... As a result, the [HASHSIG] specification supports > five tree sizes; they are identified as: >=20 >> The LMS public key is the string consists of four elements: the >>=20 >> Perhaps "An LMS public key consists of ...". >=20 > Yes, that reads better. >=20 >> u32str(lms_algorithm_type) || u32str(otstype) || I || T[1] >>=20 >> The notation "T[1]" seems to be undefined (although the intended = value >> is described clearly in the preceding paragraph). >=20 > Good catch. How about: >=20 > ... and the m-byte string associated with the root > node of the tree (T[1]). >=20 >> 2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS) >>=20 >> n - The number of bytes associated with the hash function. >> [HASHSIG] supports only SHA-256 [SHS], with n=3D32. >>=20 >> "associated" seems to me to be vague. Perhaps "The length in bytes = of >> the output of the hash function." >=20 > Okay. How about: >=20 > n - The length in bytes of the hash function output. ... >=20 >> ls - The number of left-shift bits used in the checksum function, >> which is defined in Section 4.4 of [HASHSIG]. >>=20 >> "The number of left-shift bits" is not quite right. Perhaps "The >> number of bits of left-shifting used in ..." or "The amount/size of >> the left-shift used in ...". >=20 > These words were taken directly from Section 4.1 of RFC 8554. That = said, I think you are right that it could be more clear. How about: >=20 > ls - The number of bits that are left-shifted in the final step of > the checksum function, which is defined in Section 4.4 > of [HASHSIG]. >=20 >> 5. Signed-data Conventions >>=20 >> This paragraph has to be a number of minor wording issues, which I >> have described interline: >>=20 >> As specified in [CMS], the digital signature is produced from the >> message digest and the signer's private key. The signature is >> computed over different value depending on whether signed attributes >>=20 >> s/value/values/ >=20 > Fixed. >=20 >> are absent or present. When signed attributes are absent, the >> HSS/LMS signature is computed over the content. When signed >>=20 >> It might help the reader to put a paragraph break before "When signed >> attributes are present..." >=20 > Okay. Done. >=20 >> attributes are present, a hash is computed over the content using = the >> same hash function that is used in the HSS/LMS tree, and then a >> message-digest attribute is constructed with the resulting hash >>=20 >> I would replace "with" with "containing" or "whose value is" >=20 > How about: >=20 > ... a message-digest attribute is constructed to contain the > resulting hash value, and ... >=20 >> value, and then DER encode the set of signed attributes, which MUST >>=20 >> For parallelism, this clause should start with a subject and a = passive >> verb. Perhaps "the DER encoding is constructed of ...". >=20 > How about: >=20 > ... and then the result of DER encoding the set of signed > attributes, which ... >=20 >>=20 >> include a content-type attribute and a message-digest attribute, and >>=20 >> It might be clearer if the clause "which MUST ... attribute" was put >> in parentheses. >=20 > Okay. There are a lot of commas in this sentence. >=20 >> then the HSS/LMS signature is computed over the output of the DER- >> encode operation. In summary: >>=20 >> You can probably change "the output of the DER-encode operation" with >> "the DER encoding". >=20 > How about: >=20 > ... then the HSS/LMS signature is computed over the > DER-encoded output. >=20 >> The paragraph contains four clauses joined by three successive "and >> then". You probably want to change that, perhaps breaking it out as = a >> numbered/bulleted list. (What does the Editor recommend?) >=20 > I think the text is accurate. I wil wait for the RFC Editor to = propose a different format if they want to do so. >=20 >> And in this computation: >>=20 >> IF (signed attributes are absent) >> THEN HSS_LMS_Sign(content) >> ELSE message-digest attribute =3D Hash(content); >>=20 >> I think you want to add a hyphen: >> s/message-digest attribute/message-digest-attribute/ >=20 > No. This is the way that the attributes are talked about in RFC 5652. > (See the indented paragraphs on Page 15 of RFC 5652 as an example.) >=20 >>=20 >> HSS_LMS_Sign(DER(SignedAttributes)) >=20 >=20 > Thanks again for the careful review. >=20 > Russ >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Sep 18 10:18:49 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8E6120ABD; Wed, 18 Sep 2019 10:18:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari via Datatracker To: "The IESG" Cc: draft-ietf-lamps-cms-hash-sig@ietf.org, Tim Hollebeek , lamps-chairs@ietf.org, tim.hollebeek@digicert.com, spasm@ietf.org, jclarke@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 6.101.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Warren Kumari Message-ID: <156882712117.4491.239737047176506617.idtracker@ietfa.amsl.com> Date: Wed, 18 Sep 2019 10:18:41 -0700 Archived-At: Subject: [lamps] Warren Kumari's No Objection on draft-ietf-lamps-cms-hash-sig-09: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 17:18:42 -0000 Warren Kumari has entered the following ballot position for draft-ietf-lamps-cms-hash-sig-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-hash-sig/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for writing this, and thanks to Joe for the OpsDir review -- it has some useful comments to address. From nobody Wed Sep 18 10:23:05 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81038120A8D for ; Wed, 18 Sep 2019 10:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 8RQc-mFyWe_4 for ; Wed, 18 Sep 2019 10:22:55 -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 15F57120B3B for ; Wed, 18 Sep 2019 10:22:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 822BA300AEF for ; Wed, 18 Sep 2019 13:22:53 -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 kkltYKtwFe3b for ; Wed, 18 Sep 2019 13:22:51 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 451BC300A81; Wed, 18 Sep 2019 13:22:51 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <156882712117.4491.239737047176506617.idtracker@ietfa.amsl.com> Date: Wed, 18 Sep 2019 13:22:51 -0400 Cc: IESG , Tim Hollebeek , LAMPS WG , Joe Clarke Content-Transfer-Encoding: quoted-printable Message-Id: References: <156882712117.4491.239737047176506617.idtracker@ietfa.amsl.com> To: Warren Kumari X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Warren Kumari's No Objection on draft-ietf-lamps-cms-hash-sig-09: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 17:22:57 -0000 Warren: I believe that -09 addresses the comments from Joe. You will see that = the Acknowledgements include Joe. Russ > On Sep 18, 2019, at 1:18 PM, Warren Kumari via Datatracker = wrote: >=20 > Warren Kumari has entered the following ballot position for > draft-ietf-lamps-cms-hash-sig-09: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-hash-sig/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thank you for writing this, and thanks to Joe for the OpsDir review -- = it has > some useful comments to address. >=20 >=20 From nobody Wed Sep 18 10:33:47 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B86120AFF for ; Wed, 18 Sep 2019 10:33:32 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 FWLWoqQYdE20 for ; Wed, 18 Sep 2019 10:33:29 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BDA3120B2A for ; Wed, 18 Sep 2019 10:33:29 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id y144so278776qkb.7 for ; Wed, 18 Sep 2019 10:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a324NIs9pxXeBg3sVqzYnDwsXL6SkGtrsYnyklVFZdY=; b=tOalTw1Aheza6MQeI8izjo2wSaUip6EG3Wi/7Ew5D4sNtqhlGojpZrK19Qa28CjF2U iMHEfG4Rcy387iKBmU6kQKn15Aw0Heau4KPJOg0bJTa3bQ1IBHAheLXd0LV1WMf07ZLv 60+UWmCa4vEl4YVjxwn7QX16GC2J57OoheXy/HFiaT07/hzHT9cV8T8Eusp5sFDXDsks wU4dfKrJwoB9d8iOb1SFTib9sLP7JM55S0tATS0LEWtuW0lL8y3vBXJNDgXgRDn3YlAE FE/PxB8Jtirb35ZIS8eL8xvYODDQagnj/mVqjFhEkP2NuEsh/65H1qil52gE6KllYrRM kmAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=a324NIs9pxXeBg3sVqzYnDwsXL6SkGtrsYnyklVFZdY=; b=a2EoK83Dk3aqUe9R9Lfer09zFQPwK1xn0zIgE8YrDIr1oSYuC6ILS4yK9gNBnbWpLh bhl8+C4hGAbLhyyVKhvJIUyveE7Jljz/Bx9igbR7xUtJNOJRO5LsJndNXEiYkY5Nqjrz p1HJ3I3E0F2WTZagN1hGSXGkGrM4lFKGF8sukJ5JF/DEej3JIzpJRCeE+NL8LdYfhvEd t7jXMZhEK7IPGu00HrgGi8xX5rmNqJW6yaPxUEHkVMYCGYtKMJ7Gr0k2NPxXo1BJweNa vmmMvPZARXMRGpPDbvA1/LTbiArAZ1lD8QmpzbZX/ule8sr80/sk/Xtcunz9OmirAwNb CQuw== X-Gm-Message-State: APjAAAVOfHBN0OS91F/Oz+XgWM2qzNGpKn+M9bf70SeY862EWIBcTLML VLY0047pSmw2XbxMCPvhBNbvDuaJBtjkkVCYKb6HmbAT X-Google-Smtp-Source: APXvYqxzphhkTJo5CNlevBLyeYPe4EbPjd2a9nkDiNQB4NZ1I8NS999b9vobw1ts9+32b1kSKdrAuo7klpSYC6IxXYo= X-Received: by 2002:a05:620a:753:: with SMTP id i19mr5282228qki.192.1568828008201; Wed, 18 Sep 2019 10:33:28 -0700 (PDT) MIME-Version: 1.0 References: <156882712117.4491.239737047176506617.idtracker@ietfa.amsl.com> In-Reply-To: From: Warren Kumari Date: Wed, 18 Sep 2019 10:32:51 -0700 Message-ID: To: Russ Housley Cc: IESG , Tim Hollebeek , LAMPS WG , Joe Clarke Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [lamps] Warren Kumari's No Objection on draft-ietf-lamps-cms-hash-sig-09: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 17:33:38 -0000 On Wed, Sep 18, 2019 at 10:22 AM Russ Housley wrote: > > Warren: > > I believe that -09 addresses the comments from Joe. You will see that the Acknowledgements include Joe. Oh, great. Well, my work here is done then :-P W > > Russ > > > > On Sep 18, 2019, at 1:18 PM, Warren Kumari via Datatracker wrote: > > > > Warren Kumari has entered the following ballot position for > > draft-ietf-lamps-cms-hash-sig-09: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-hash-sig/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thank you for writing this, and thanks to Joe for the OpsDir review -- it has > > some useful comments to address. > > > > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Sep 18 11:48:57 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB55120BDD for ; Wed, 18 Sep 2019 11:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 VyNZVIevncbh for ; Wed, 18 Sep 2019 11:48:53 -0700 (PDT) Received: from esa1.isaracorp.com (esa1.isaracorp.com [207.107.152.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC6A4120BDB for ; Wed, 18 Sep 2019 11:48:53 -0700 (PDT) IronPort-SDR: kF+ttcmsRN7jzlQ+Yq6AMkFRDVLJuYqQkKkFAHl71b4dZgdnybL4bH1n+DVBLmJMnRNXdzN7z8 3p9p8f84n1n/GcP7Kuf5swqX1i0n9Xvf4hjFHL5ANq6XMR5cUwzK4v0bXg/w6C+10ib5cXvxgw Gv3TUqnJxHkPDWAbCEDiif13TLlLMm2gcUbZsVNxrGErBmr56b+rXJJUERcKFKU3h3+m7diyoy 9zMvlIC3RrkbybBiLnrYY6/ySzlmLAghRfFs8B3/PYdk6NPkzPrWhrPcdMTNoyZe0cWFxFi/cr c/8= Received: from unknown (HELO V0501WEXGPR02.isaracorp.com) ([10.5.9.20]) by ip1.isaracorp.com with ESMTP; 18 Sep 2019 18:48:53 +0000 Received: from V0501WEXGPR01.isaracorp.com (10.5.8.20) by V0501WEXGPR02.isaracorp.com (10.5.9.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1779.2; Wed, 18 Sep 2019 14:49:53 -0400 Received: from V0501WEXGPR01.isaracorp.com ([fe80::d802:5aec:db34:beba]) by V0501WEXGPR01.isaracorp.com ([fe80::d802:5aec:db34:beba%7]) with mapi id 15.01.1779.002; Wed, 18 Sep 2019 14:49:53 -0400 From: Daniel Van Geest To: Russ Housley , LAMPS WG Thread-Topic: [lamps] Proposed charter update regarding clarifications Thread-Index: AQHVRHA9vepqQ/jtQ0yplc6ZP7NY6acnZUcAgAq1RYA= Date: Wed, 18 Sep 2019 18:49:52 +0000 Message-ID: References: <3DB1B550-26FA-4F93-8CFA-434C1F8811D1@vigilsec.com> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.5.52] Content-Type: multipart/alternative; boundary="_000_B36ACC93B68D490893BD7FF1A19D378Fisaracom_" MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] Proposed charter update regarding clarifications X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 18:48:56 -0000 --_000_B36ACC93B68D490893BD7FF1A19D378Fisaracom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gaW4gZmF2b3VyIG9mIHRoZSBuZXcgdGV4dC4NCg0KT24gMjAxOS0wOS0xMSwgMzoxOCBQ TSwgIlNwYXNtIG9uIGJlaGFsZiBvZiBSdXNzIEhvdXNsZXkiIDxzcGFzbS1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzpzcGFzbS1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgaG91c2xleUB2 aWdpbHNlYy5jb208bWFpbHRvOmhvdXNsZXlAdmlnaWxzZWMuY29tPj4gd3JvdGU6DQoNCkkgYW0g Y29uY2VybmVkIHRoYXQgd2UgaGF2ZSBoZWFyZCBmcm9tIHZlcnkgZmV3IHBlb3BsZSBvbiB0aGlz IHRvcGljLCB3aXRoIHJvdWdobHkgZXF1YWwgbnVtYmVycyBzcGVha2luZyBmb3IsIGFnYWluc3Qs IGFuZCBpbmRpZmZlcmVudC4gIElmIHlvdSBoYXZlIG5vdCBzcG9rZW4sIHBsZWFzZSBkbyBzby4N Cg0KUnVzcw0KDQpPbiBKdWwgMjcsIDIwMTksIGF0IDc6NDAgQU0sIFJ1c3MgSG91c2xleSA8aG91 c2xleUB2aWdpbHNlYy5jb208bWFpbHRvOmhvdXNsZXlAdmlnaWxzZWMuY29tPj4gd3JvdGU6DQpB dCB0aGUgbWVldGluZyBpbiBNb250cmVhbCwgd2Ugc3VnZ2VzdGVkIGEgY2hhcnRlciB1cGRhdGUg dG8gYWxsb3cgY2xhcmlmaWNhdGlvbnMuICBJIHN1Z2dlc3Q6DQpPTEQ6DQpJbiBhZGRpdGlvbiwg dGhlIExBTVBTIFdHIG1heSBpbnZlc3RpZ2F0ZSBvdGhlciB1cGRhdGVzIHRvIGRvY3VtZW50cw0K cHJvZHVjZWQgYnkgdGhlIFBLSVggYW5kIFMvTUlNRSBXR3MsIGJ1dCB0aGUgTEFNUFMgV0cgc2hh bGwgbm90IGFkb3B0DQphbnkgb2YgdGhlc2UgcG90ZW50aWFsIHdvcmsgaXRlbXMgd2l0aG91dCBy ZWNoYXJ0ZXJpbmcuDQpORVc6DQpJbiBhZGRpdGlvbiwgdGhlIExBTVBTIFdHIG1heSBpbnZlc3Rp Z2F0ZSBvdGhlciB1cGRhdGVzIHRvIGRvY3VtZW50cw0KcHJvZHVjZWQgYnkgdGhlIFBLSVggYW5k IFMvTUlNRSBXRy4gVGhlIExBTVBTIFdHIG1heSBwcm9kdWNlDQpjbGFyaWZpY2F0aW9ucyB3aGVy ZSBuZWVkZWQsIGJ1dCB0aGUgTEFNUFMgV0cgc2hhbGwgbm90IGFkb3B0DQphbnl0aGluZyBiZXlv bmQgY2xhcmlmaWNhdGlvbnMgd2l0aG91dCByZWNoYXJ0ZXJpbmcuDQpUaG91Z2h0cz8NClJ1c3MN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClNwYXNt IG1haWxpbmcgbGlzdA0KU3Bhc21AaWV0Zi5vcmc8bWFpbHRvOlNwYXNtQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcGFzbQ0KDQo= --_000_B36ACC93B68D490893BD7FF1A19D378Fisaracom_ Content-Type: text/html; charset="utf-8" Content-ID: <6E0BF631F875F947B7E833828359FCE6@isara.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUNBIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5J4oCZbSBpbiBmYXZvdXIgb2YgdGhlIG5ldyB0ZXh0LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi Pk9uIDIwMTktMDktMTEsIDM6MTggUE0sICZxdW90O1NwYXNtIG9uIGJlaGFsZiBvZiBSdXNzIEhv dXNsZXkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcGFzbS1ib3VuY2VzQGlldGYub3JnIj5z cGFzbS1ib3VuY2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzpo b3VzbGV5QHZpZ2lsc2VjLmNvbSI+aG91c2xleUB2aWdpbHNlYy5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij5JIGFtIGNvbmNlcm5lZCB0aGF0IHdlIGhhdmUgaGVhcmQgZnJvbSB2ZXJ5IGZldyBwZW9wbGUg b24gdGhpcyB0b3BpYywgd2l0aCByb3VnaGx5IGVxdWFsIG51bWJlcnMgc3BlYWtpbmcgZm9yLCBh Z2FpbnN0LCBhbmQgaW5kaWZmZXJlbnQuJm5ic3A7Jm5ic3A7SWYgeW91IGhhdmUgbm90IHNwb2tl biwgcGxlYXNlIGRvIHNvLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij5SdXNzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdDttYXJnaW4tbGVmdDoz Ljc1cHQ7bWFyZ2luLXJpZ2h0OjBjbSIgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NL UVVPVEUiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPk9uIEp1bCAyNywgMjAxOSwgYXQgNzo0MCBBTSwgUnVzcyBIb3VzbGV5ICZsdDs8YSBo cmVmPSJtYWlsdG86aG91c2xleUB2aWdpbHNlYy5jb20iPmhvdXNsZXlAdmlnaWxzZWMuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5BdCB0aGUgbWVldGluZyBpbiBNb250 cmVhbCwgd2Ugc3VnZ2VzdGVkIGEgY2hhcnRlciB1cGRhdGUgdG8gYWxsb3cgY2xhcmlmaWNhdGlv bnMuJm5ic3A7Jm5ic3A7SSBzdWdnZXN0OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T0xEOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+SW4gYWRkaXRpb24sIHRoZSBMQU1QUyBXRyBtYXkgaW52ZXN0aWdh dGUgb3RoZXIgdXBkYXRlcyB0byBkb2N1bWVudHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPnByb2R1 Y2VkIGJ5IHRoZSBQS0lYIGFuZCBTL01JTUUgV0dzLCBidXQgdGhlIExBTVBTIFdHIHNoYWxsIG5v dCBhZG9wdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+YW55IG9mIHRoZXNlIHBvdGVudGlhbCB3b3Jr IGl0ZW1zIHdpdGhvdXQgcmVjaGFydGVyaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+TkVXOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SW4gYWRkaXRpb24sIHRoZSBMQU1QUyBXRyBtYXkgaW52ZXN0 aWdhdGUgb3RoZXIgdXBkYXRlcyB0byBkb2N1bWVudHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPnBy b2R1Y2VkIGJ5IHRoZSBQS0lYIGFuZCBTL01JTUUgV0cuIFRoZSBMQU1QUyBXRyBtYXkgcHJvZHVj ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Y2xhcmlmaWNhdGlvbnMgd2hlcmUgbmVlZGVkLCBidXQg dGhlIExBTVBTIFdHIHNoYWxsIG5vdCBhZG9wdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+YW55dGhp bmcgYmV5b25kIGNsYXJpZmljYXRpb25zIHdpdGhvdXQgcmVjaGFydGVyaW5nLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+VGhvdWdodHM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5SdXNzPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5TcGFzbSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxh IGhyZWY9Im1haWx0bzpTcGFzbUBpZXRmLm9yZyI+U3Bhc21AaWV0Zi5vcmc8L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NwYXNtIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwYXNtPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_B36ACC93B68D490893BD7FF1A19D378Fisaracom_-- From nobody Wed Sep 18 11:51:32 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D23120B88 for ; Wed, 18 Sep 2019 11:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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=akamai.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 aQ7JpCPfJEUg for ; Wed, 18 Sep 2019 11:51:28 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3DBD120988 for ; Wed, 18 Sep 2019 11:51:28 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x8IImfjw030320; Wed, 18 Sep 2019 19:51:25 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=k61OvYHfR09ql1GadnPZx1+S9WAzm4IEcd0I3V6Oa8U=; b=Vs+2UHltL+xms4lOYdDz1OwgxNYNilJ/wadbEioA2JenSpHqVbxixLIgITrRRpaxat5o JO1n3i28IeVLvXVRx112PSShPUtC1zcV5hy6h2mR5HiWttS0ZHn6HbREoL21bDPaUb5Z UFf3cfNVylh2E24ymc3vY4nBf/EFyT/Wk8dNmHXX8UQwdz8WWyjSwlujwbg/QzUB7RQt L9cTscVeKKBL2FK+bzoNjbyHvv81BTHgRRYDYFQcWwgKPIoaMC27PpjFCD1Di27HLtLm ugcXSmXvNIbu+80NH6lmYSwl1dB1Tu0ezqkRqlPvq3e5NAIMZkm8wDbxhQInT2Ba310p 6Q== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2v37vxmm1j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Sep 2019 19:51:25 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x8IImYMG032694; Wed, 18 Sep 2019 14:51:24 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint2.akamai.com with ESMTP id 2v37rmvvab-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 18 Sep 2019 14:51:23 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 18 Sep 2019 14:51:23 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Wed, 18 Sep 2019 14:51:23 -0400 From: "Salz, Rich" To: Russ Housley , LAMPS WG Thread-Topic: [lamps] Proposed charter update regarding clarifications Thread-Index: AQHVaNWYHZSuA5tlj0WLxrBDDES3RacyFRgA//+9XQA= Date: Wed, 18 Sep 2019 18:51:22 +0000 Message-ID: <35FF4CD6-D84C-4B76-BFA8-F2015A916636@akamai.com> References: <3DB1B550-26FA-4F93-8CFA-434C1F8811D1@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.23] Content-Type: multipart/alternative; boundary="_000_35FF4CD6D84C4B76BFA8F2015A916636akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-18_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=922 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909180164 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-18_09:2019-09-18,2019-09-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 adultscore=0 spamscore=0 bulkscore=0 mlxlogscore=940 priorityscore=1501 mlxscore=0 malwarescore=0 clxscore=1011 impostorscore=0 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909180164 Archived-At: Subject: Re: [lamps] Proposed charter update regarding clarifications X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 18:51:31 -0000 --_000_35FF4CD6D84C4B76BFA8F2015A916636akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBJIGNvbW1lbnRlZCBiZWZvcmUsIGJ1dCBoYXZlIG5vIGJsb2NraW5nIGlzc3VlcyB3 aXRoIHRoZSBuZXcgdGV4dA0KDQpPbiAyMDE5LTA5LTExLCAzOjE4IFBNLCAiU3Bhc20gb24gYmVo YWxmIG9mIFJ1c3MgSG91c2xleSIgPHNwYXNtLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNwYXNt LWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBob3VzbGV5QHZpZ2lsc2VjLmNvbTxtYWls dG86aG91c2xleUB2aWdpbHNlYy5jb20+PiB3cm90ZToNCg0KSSBhbSBjb25jZXJuZWQgdGhhdCB3 ZSBoYXZlIGhlYXJkIGZyb20gdmVyeSBmZXcgcGVvcGxlIG9uIHRoaXMgdG9waWMsIHdpdGggcm91 Z2hseSBlcXVhbCBudW1iZXJzIHNwZWFraW5nIGZvciwgYWdhaW5zdCwgYW5kIGluZGlmZmVyZW50 LiAgSWYgeW91IGhhdmUgbm90IHNwb2tlbiwgcGxlYXNlIGRvIHNvLg0KDQoNCk9mZi10b3BpYzog c2luY2Ugd2UgY2hhbmdlZCB0aGUgbmFtZSBvZiB0aGUgV0cgdG8gYXZvaWQgZ2l2aW5nIG9mZmVu c2UsIGl0IHN1cmUgd291bGQgYmUgbmljZSBpZiB3ZSBjb3VsZCBjaGFuZ2UgdGhlIG5hbWUgb2Yg dGhlIG1haWxpbmcgbGlzdC4NCg== --_000_35FF4CD6D84C4B76BFA8F2015A916636akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <5DFF6AC8364C1844A08EA49D618672DE@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSB0aGluayBJIGNvbW1lbnRlZCBiZWZvcmUsIGJ1dCBoYXZlIG5vIGJsb2NraW5nIGlzc3VlcyB3 aXRoIHRoZSBuZXcgdGV4dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5PbiAyMDE5LTA5LTExLCAzOjE4IFBNLCAmcXVvdDtTcGFz bSBvbiBiZWhhbGYgb2YgUnVzcyBIb3VzbGV5JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3Bh c20tYm91bmNlc0BpZXRmLm9yZyI+c3Bhc20tYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxm IG9mDQo8YSBocmVmPSJtYWlsdG86aG91c2xleUB2aWdpbHNlYy5jb20iPmhvdXNsZXlAdmlnaWxz ZWMuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5JIGFtIGNvbmNlcm5lZCB0aGF0IHdlIGhhdmUgaGVhcmQgZnJv bSB2ZXJ5IGZldyBwZW9wbGUgb24gdGhpcyB0b3BpYywgd2l0aCByb3VnaGx5IGVxdWFsIG51bWJl cnMgc3BlYWtpbmcgZm9yLCBhZ2FpbnN0LCBhbmQgaW5kaWZmZXJlbnQuJm5ic3A7Jm5ic3A7SWYg eW91IGhhdmUgbm90IHNwb2tlbiwgcGxlYXNlIGRvIHNvLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PZmYtdG9waWM6IHNpbmNlIHdlIGNoYW5nZWQg dGhlIG5hbWUgb2YgdGhlIFdHIHRvIGF2b2lkIGdpdmluZyBvZmZlbnNlLCBpdCBzdXJlIHdvdWxk IGJlIG5pY2UgaWYgd2UgY291bGQgY2hhbmdlIHRoZSBuYW1lIG9mIHRoZSBtYWlsaW5nIGxpc3Qu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_35FF4CD6D84C4B76BFA8F2015A916636akamaicom_-- From nobody Wed Sep 18 13:46:44 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0217D120112; Wed, 18 Sep 2019 13:46:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.101.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <156883960192.4639.13115138596166414130@ietfa.amsl.com> Date: Wed, 18 Sep 2019 13:46:42 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-hash-sig-10.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 20:46:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Use of the HSS/LMS Hash-based Signature Algorithm in the Cryptographic Message Syntax (CMS) Author : Russ Housley Filename : draft-ietf-lamps-cms-hash-sig-10.txt Pages : 14 Date : 2019-09-18 Abstract: This document specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-hash-sig/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-hash-sig-10 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-hash-sig-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-hash-sig-10 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 18 13:49:46 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383AF120112 for ; Wed, 18 Sep 2019 13:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 GbuVw1BMQ8WW for ; Wed, 18 Sep 2019 13:49:43 -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 1CEB0120046 for ; Wed, 18 Sep 2019 13:49:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 962DE300AE0 for ; Wed, 18 Sep 2019 16:49:41 -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 VE_bEdlKAmmo for ; Wed, 18 Sep 2019 16:49:40 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 313A1300250 for ; Wed, 18 Sep 2019 16:49:40 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 18 Sep 2019 16:49:40 -0400 References: <156883960192.4639.13115138596166414130@ietfa.amsl.com> To: LAMPS WG In-Reply-To: <156883960192.4639.13115138596166414130@ietfa.amsl.com> Message-Id: <067E5FB6-1DA7-412C-8E16-9F2C28C45D78@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-hash-sig-10.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 20:49:45 -0000 These changes were made to address comments from the IESG. Each changes = was discussed in a message on this mail list. Russ > On Sep 18, 2019, at 4:46 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Limited Additional Mechanisms for = PKIX and SMIME WG of the IETF. >=20 > Title : Use of the HSS/LMS Hash-based Signature = Algorithm in the Cryptographic Message Syntax (CMS) > Author : Russ Housley > Filename : draft-ietf-lamps-cms-hash-sig-10.txt > Pages : 14 > Date : 2019-09-18 >=20 > Abstract: > This document specifies the conventions for using the Hierarchical > Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based > signature algorithm with the Cryptographic Message Syntax (CMS). In > addition, the algorithm identifier and public key syntax are > provided. The HSS/LMS algorithm is one form of hash-based digital > signature; it is described in RFC 8554. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-hash-sig/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lamps-cms-hash-sig-10 > https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-hash-sig-10 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-hash-sig-10 >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Sep 21 06:35:04 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B18912006D for ; Sat, 21 Sep 2019 06:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.103 X-Spam-Level: X-Spam-Status: No, score=0.103 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 PZVe0JihV4zn for ; Sat, 21 Sep 2019 06:35:01 -0700 (PDT) Received: from smtpscan1.dandomain.dk (smtpscan1.dandomain.dk [194.150.112.161]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CE64120033 for ; Sat, 21 Sep 2019 06:35:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtpscan1.dandomain.dk (Postfix) with ESMTP id DB062D228A for ; Sat, 21 Sep 2019 15:34:58 +0200 (CEST) Received: from smtpscan1.dandomain.dk ([127.0.0.1]) by localhost (smtpscan1.dandomain.dk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMk9IPjCtN-y for ; Sat, 21 Sep 2019 15:34:58 +0200 (CEST) Received: from mail02.dandomain.dk (mail02.dandomain.dk [194.150.112.202]) by smtpscan1.dandomain.dk (Postfix) with ESMTP id 1F8F6D2279 for ; Sat, 21 Sep 2019 15:34:58 +0200 (CEST) Received: from mail-proxy.dandomain.dk ([194.150.112.64]) by mail02.dandomain.dk (DanDomain Mailserver) with ASMTP id 2201909211534541628 for ; Sat, 21 Sep 2019 15:34:54 +0200 From: "Erik Andersen" To: "LAMPS" Date: Sat, 21 Sep 2019 15:34:55 +0200 Message-ID: <000601d57081$5afa8fc0$10efaf40$@x500.eu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01D57092.1E85D0C0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdVwgHnXSUKOFJeEQaeWb5AL9ofT4g== Content-Language: en-gb Archived-At: Subject: [lamps] X.510 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2019 13:35:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0007_01D57092.1E85D0C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Within ITU-T and ISO we have developed a new specification, Rec. ITU-T X.510 | ISO/IEC 9594-11, which now is out for final vote. There is a link to it here . We expect to complete it by March 2020. Any comment any of you might have will be highly appreciated. Best regards, Erik ------=_NextPart_000_0007_01D57092.1E85D0C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Within ITU-T and ISO we have developed a new = specification, Rec. ITU-T X.510 | ISO/IEC 9594-11, which now is out for = final vote. There is a link to it h= ere. We expect to complete it by March 2020.

 

Any comment = any of you might have will be highly appreciated.

 

Best = regards,

 

Erik

------=_NextPart_000_0007_01D57092.1E85D0C0-- From nobody Mon Sep 23 10:05:37 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE1E1200F4; Mon, 23 Sep 2019 10:05:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.102.0 Auto-Submitted: auto-generated Precedence: bulk Cc: rdd@cert.org, lamps-chairs@ietf.org, draft-ietf-lamps-cms-hash-sig@ietf.org, The IESG , spasm@ietf.org, Tim Hollebeek , tim.hollebeek@digicert.com, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156925832396.17153.2389278525114160787.idtracker@ietfa.amsl.com> Date: Mon, 23 Sep 2019 10:05:23 -0700 Archived-At: Subject: [lamps] Protocol Action: 'Use of the HSS/LMS Hash-based Signature Algorithm in the Cryptographic Message Syntax (CMS)' to Proposed Standard (draft-ietf-lamps-cms-hash-sig-10.txt) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 17:05:25 -0000 The IESG has approved the following document: - 'Use of the HSS/LMS Hash-based Signature Algorithm in the Cryptographic Message Syntax (CMS)' (draft-ietf-lamps-cms-hash-sig-10.txt) as Proposed Standard This document is the product of the Limited Additional Mechanisms for PKIX and SMIME Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-hash-sig/ Technical Summary This document specifies the conventions for using the the HSS/LMS hash-based signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in draft-mcgrew-hash-sigs-15, which is about to be published as RFC 8554. Working Group Summary There is consensus for this document in the LAMPS WG. Document Quality This extension allows the HSS/LMS hash-based signature algorithm described in draft-mcgrew-hash-sigs-15 to be used with the CMS. In addition, the algorithm identifiers allow the hash-based signatures to be used in digital certificates. At least one PKI intends to issue certificates using this algorithm. Personnel Tim Hollebeek is the document shepherd. Roman Danyliw is the responsible area director. From nobody Mon Sep 23 11:10:15 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25CE11208DC for ; Mon, 23 Sep 2019 11:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 O68G-gpJt7s9 for ; Mon, 23 Sep 2019 11:10:02 -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 D5AAA1208E8 for ; Mon, 23 Sep 2019 11:10:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 582A6300B12 for ; Mon, 23 Sep 2019 14:10:00 -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 L4MMXnzT48xs for ; Mon, 23 Sep 2019 14:09:59 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 1CF8E300470; Mon, 23 Sep 2019 14:09:58 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_DEBE2ED7-EB8B-415D-B52E-0BFE50C2DF5A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 23 Sep 2019 14:09:59 -0400 In-Reply-To: <000601d57081$5afa8fc0$10efaf40$@x500.eu> Cc: LAMPS To: Erik Andersen References: <000601d57081$5afa8fc0$10efaf40$@x500.eu> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] X.510 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 18:10:13 -0000 --Apple-Mail=_DEBE2ED7-EB8B-415D-B52E-0BFE50C2DF5A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Erik: I think it would be better to reference RFC 5083 instead of RFC 8084. Russ > On Sep 21, 2019, at 9:34 AM, Erik Andersen wrote: >=20 > Within ITU-T and ISO we have developed a new specification, Rec. ITU-T = X.510 | ISO/IEC 9594-11, which now is out for final vote. There is a = link to it here = . We = expect to complete it by March 2020. > =20 > Any comment any of you might have will be highly appreciated. > =20 > Best regards, > =20 > Erik > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm = --Apple-Mail=_DEBE2ED7-EB8B-415D-B52E-0BFE50C2DF5A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Erik:

I = think it would be better to reference RFC 5083 instead of RFC = 8084.

Russ


On Sep = 21, 2019, at 9:34 AM, Erik Andersen <era@x500.eu> wrote:

Within = ITU-T and ISO we have developed a new specification, Rec. ITU-T X.510 | = ISO/IEC 9594-11, which now is out for final vote. There is a link to = it here. We expect to complete it by March 2020.
 
Any = comment any of you might have will be highly appreciated.
 
Best = regards,
 
Erik
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

= --Apple-Mail=_DEBE2ED7-EB8B-415D-B52E-0BFE50C2DF5A-- From nobody Mon Sep 23 20:50:53 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CABEE1200F4 for ; Mon, 23 Sep 2019 20:50:50 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 BZd9se1n1VZQ for ; Mon, 23 Sep 2019 20:50:48 -0700 (PDT) Received: from mx1.entrustdatacard.com (mx1.entrustdatacard.com [204.124.80.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C7E51200F1 for ; Mon, 23 Sep 2019 20:50:48 -0700 (PDT) IronPort-SDR: yrGcEbigravpfuAXNizE2Kz/iyYInsQgyVVXZBd/oaETYGUvUgzUAmWRMZfog5OJu6PwkqhOa8 xPt31WTrzYxg== X-IronPort-AV: E=Sophos;i="5.64,542,1559538000"; d="scan'208";a="57621193" Received: from pmspex03.corporate.datacard.com (HELO owa.entrustdatacard.com) ([192.168.211.50]) by pmspesa03inside.corporate.datacard.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 23 Sep 2019 22:50:47 -0500 Received: from PMSPEX05.corporate.datacard.com (192.168.211.52) by PMSPEX03.corporate.datacard.com (192.168.211.50) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 23 Sep 2019 22:50:47 -0500 Received: from PMSPEX05.corporate.datacard.com ([fe80::8084:293e:7f03:4ab2]) by PMSPEX05.corporate.datacard.com ([fe80::8084:293e:7f03:4ab2%12]) with mapi id 15.00.1497.000; Mon, 23 Sep 2019 22:50:46 -0500 From: Mike Ounsworth To: Erik Andersen , LAMPS Thread-Topic: [EXTERNAL][lamps] X.510 Thread-Index: AdVwgHnXSUKOFJeEQaeWb5AL9ofT4gCCULlw Date: Tue, 24 Sep 2019 03:50:46 +0000 Message-ID: <01fd886909e94b0ab9c353958f46a45e@PMSPEX05.corporate.datacard.com> References: <000601d57081$5afa8fc0$10efaf40$@x500.eu> In-Reply-To: <000601d57081$5afa8fc0$10efaf40$@x500.eu> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.1.43.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] [EXTERNAL] X.510 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 03:50:51 -0000 Hi Erik, I found your slides https://docbox.etsi.org/Workshop/2019/201906_ETSISECURI= TYWEEK/202106_DynamicNatureOfTechno/SESSION03_CHANGINGCRYPTOGRAPHY/ANDERSEN= SLSERVICES_ANDERSEN.pdf, explaining the rationale behind X.510. In it, you = say: * A back level recipient will ignore the alternative algorithm, but validat= e according to the native one * An advanced recipient will validate according to the alternative algorith= m In attending post-quantum conferences, for example the NIST PQC, there is a= strong call for "hybrid" modes where *both* algorithms are validated becau= se we don't fully trust the new stuff yet. So this may not be simply a migr= ation issue, but a more long-term issue of combining algorithms for increas= ed security. Do you have an opinion on whether X.510 in its current form would be approp= riate for hybrid modes, and whether your language should be adjusted to be = "native algorithm and alt algorithm" as opposed to your current "native alg= orithm or alt algorithm" ? - - - Mike Ounsworth | Office: +1 (613) 270-2873 From: Spasm On Behalf Of Erik Andersen Sent: Saturday, September 21, 2019 8:35 AM To: LAMPS Subject: [EXTERNAL][lamps] X.510 WARNING: This email originated outside of Entrust Datacard. DO NOT CLICK links or attachments unless you trust the sender and know the = content is safe. ________________________________________ Within ITU-T and ISO we have developed a new specification, Rec. ITU-T X.51= 0 | ISO/IEC 9594-11, which now is out for final vote. There is a link to it= https://www.dropbox.com/s/qzzuy9hu2vjz9qw/X.510-dis.pdf?dl=3D0. We expect = to complete it by March 2020. Any comment any of you might have will be highly appreciated. Best regards, Erik From nobody Tue Sep 24 01:28:32 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FD8120115 for ; Tue, 24 Sep 2019 01:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 2pY0qw-HK3WJ for ; Tue, 24 Sep 2019 01:28:28 -0700 (PDT) Received: from smtpscan3.dandomain.dk (smtpscan3.dandomain.dk [194.150.112.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24E49120052 for ; Tue, 24 Sep 2019 01:28:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtpscan3.dandomain.dk (Postfix) with ESMTP id 81251D2C3D for ; Tue, 24 Sep 2019 10:28:25 +0200 (CEST) Received: from smtpscan3.dandomain.dk ([127.0.0.1]) by localhost (smtpscan3.dandomain.dk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05R0oMQucfqi for ; Tue, 24 Sep 2019 10:28:24 +0200 (CEST) Received: from mail03.dandomain.dk (mail03.dandomain.dk [194.150.112.203]) by smtpscan3.dandomain.dk (Postfix) with ESMTP id ADC8BD2C8A for ; Tue, 24 Sep 2019 10:28:24 +0200 (CEST) Received: from mail-proxy.dandomain.dk ([194.150.112.64]) by mail03.dandomain.dk (DanDomain Mailserver) with ASMTP id 3201909241028235380; Tue, 24 Sep 2019 10:28:23 +0200 From: "Erik Andersen" To: "'LAMPS'" Cc: "Jean-Paul LEMAIRE" , "Mark Pecen" References: <000601d57081$5afa8fc0$10efaf40$@x500.eu> <01fd886909e94b0ab9c353958f46a45e@PMSPEX05.corporate.datacard.com> In-Reply-To: <01fd886909e94b0ab9c353958f46a45e@PMSPEX05.corporate.datacard.com> Date: Tue, 24 Sep 2019 10:28:23 +0200 Message-ID: <002201d572b2$0815f6e0$1841e4a0$@x500.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQISoDp2LBZNpXW83TH/US3RFiUrOAFnm8W/prTjbiA= Content-Language: en-gb Archived-At: Subject: Re: [lamps] [EXTERNAL] X.510 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 08:28:30 -0000 Hi Mike, A good point. Having multiple algorithms for added security and not just = for migration is not really considered in draft X.510, which could be a = miss. We will see if we can get that aspect into document during its final ballot round where in principle only editorials are allowed. Anyway, we will probably need an edition 2 quite quickly. Best regards, Erik -----Oprindelig meddelelse----- Fra: Spasm [mailto:spasm-bounces@ietf.org] P=E5 vegne af Mike Ounsworth Sendt: 24 September 2019 05:51 Til: Erik Andersen ; LAMPS Emne: Re: [lamps] [EXTERNAL] X.510 Hi Erik, I found your slides https://docbox.etsi.org/Workshop/2019/201906_ETSISECURITYWEEK/202106_Dyna= mic NatureOfTechno/SESSION03_CHANGINGCRYPTOGRAPHY/ANDERSENSLSERVICES_ANDERSEN= .pd f, explaining the rationale behind X.510. In it, you say: * A back level recipient will ignore the alternative algorithm, but = validate according to the native one * An advanced recipient will validate according to the alternative = algorithm In attending post-quantum conferences, for example the NIST PQC, there = is a strong call for "hybrid" modes where *both* algorithms are validated = because we don't fully trust the new stuff yet. So this may not be simply a migration issue, but a more long-term issue of combining algorithms for increased security. Do you have an opinion on whether X.510 in its current form would be appropriate for hybrid modes, and whether your language should be = adjusted to be "native algorithm and alt algorithm" as opposed to your current "native algorithm or alt algorithm" ? - - - Mike Ounsworth | Office: +1 (613) 270-2873 From: Spasm On Behalf Of Erik Andersen Sent: Saturday, September 21, 2019 8:35 AM To: LAMPS Subject: [EXTERNAL][lamps] X.510 WARNING: This email originated outside of Entrust Datacard. DO NOT CLICK links or attachments unless you trust the sender and know = the content is safe. ________________________________________ Within ITU-T and ISO we have developed a new specification, Rec. ITU-T = X.510 | ISO/IEC 9594-11, which now is out for final vote. There is a link to = it https://www.dropbox.com/s/qzzuy9hu2vjz9qw/X.510-dis.pdf?dl=3D0. We = expect to complete it by March 2020. Any comment any of you might have will be highly appreciated. Best regards, Erik _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Tue Sep 24 10:44:14 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D57D1208B5 for ; Tue, 24 Sep 2019 10:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 YpO2vwHP8NLN for ; Tue, 24 Sep 2019 10:44:10 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B846A12084B for ; Tue, 24 Sep 2019 10:44:10 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 35F53B80836; Tue, 24 Sep 2019 10:43:50 -0700 (PDT) To: housley@vigilsec.com, rdd@cert.org, kaduk@mit.edu, housley@vigilsec.com, tim.hollebeek@digicert.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: nay486028@gmail.com, spasm@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190924174350.35F53B80836@rfc-editor.org> Date: Tue, 24 Sep 2019 10:43:50 -0700 (PDT) Archived-At: Subject: [lamps] [Editorial Errata Reported] RFC8649 (5863) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 17:44:12 -0000 The following errata report has been submitted for RFC8649, "Hash Of Root Key Certificate Extension". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5863 -------------------------------------- Type: Editorial Reported by: Shwe Yoke Lay Section: RFC 2119 Original Text ------------- Spelling Corrected Text -------------- Grammer Notes ----- Punctuation Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8649 (draft-ietf-lamps-hash-of-root-key-cert-extn-07) -------------------------------------- Title : Hash Of Root Key Certificate Extension Publication Date : August 2019 Author(s) : R. Housley Category : INFORMATIONAL Source : Limited Additional Mechanisms for PKIX and SMIME Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Sep 24 11:03:19 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5D212090D for ; Tue, 24 Sep 2019 11:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 q_1yGfgwTvDZ for ; Tue, 24 Sep 2019 11:03:15 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82032120908 for ; Tue, 24 Sep 2019 11:03:15 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8OHqhKQ029021; Tue, 24 Sep 2019 19:03:02 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=bQM2kfyckYHBXzLXVYlVHqwidpZ/8pA4+jXL41jYTF8=; b=YxS/yDXKHoPPfCnKAp+vcJzdlE+Kt64TDzUqPTu46YBpSsAmaXvamOEfYT1RukH0515/ VZVnupNnvpt9OJ6KfbtFlTRI8Ro4GbUovurDE7LBtKNY9EK747MrJpopmX2Z6x74PyPN AsE6q+t7ps8Wfcapj7mX6UAnt2q8rYaG97aZdAViFjdxuoQi8SlUM/gimwq4NZ2c0EKb RsEOmCYz2rjSkAtjB/LZhmCq4btiYWuvbDRUA+xVGlWcVA5NTX6OyL1odp3FL716WcbO +C4aNs2sqj/m9cjftoEm2smGcRz9clvTvNW+w8w/9IRLGXIIQaAlyQlwHjw5FCr/DflI lw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2v73q9c5fu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Sep 2019 19:03:02 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x8OI1r76030946; Tue, 24 Sep 2019 14:03:01 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint1.akamai.com with ESMTP id 2v73vpmmfw-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 24 Sep 2019 14:03:01 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Sep 2019 14:03:00 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Tue, 24 Sep 2019 14:03:00 -0400 From: "Salz, Rich" To: RFC Errata System , "housley@vigilsec.com" , "rdd@cert.org" , "kaduk@mit.edu" , "tim.hollebeek@digicert.com" CC: "spasm@ietf.org" , "nay486028@gmail.com" Thread-Topic: [lamps] [Editorial Errata Reported] RFC8649 (5863) Thread-Index: AQHVcv+1u2ohsQmsyEmB6FW97dWi/ac7HpmA Date: Tue, 24 Sep 2019 18:02:59 +0000 Message-ID: <3C3C5B32-8858-4699-BC27-D0BA79AC3CAE@akamai.com> References: <20190924174350.35F53B80836@rfc-editor.org> In-Reply-To: <20190924174350.35F53B80836@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.220] Content-Type: text/plain; charset="utf-8" Content-ID: <4B7510DAA18F7342BCE27B9DC175B508@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-24_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=853 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909240154 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-09-24_07:2019-09-23,2019-09-24 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 priorityscore=1501 impostorscore=0 suspectscore=0 adultscore=0 malwarescore=0 lowpriorityscore=0 clxscore=1011 bulkscore=0 mlxlogscore=849 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909240154 Archived-At: Subject: Re: [lamps] [Editorial Errata Reported] RFC8649 (5863) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 18:03:17 -0000 SSBhbSBub3Qgc3VyZSB3aGF0IHRoaXMgZXJyYXRhIGlzIHRyeWluZyB0byBzYXksIGJ1dCB0aGUg IkdyYW1tZXIiIGlzIHNwZWxsZWQgd3JvbmcuDQpJIGd1ZXNzIHRoaXMgc2hvdWxkIGJlIGNsb3Nl ZD8NCg0KDQo= From nobody Tue Sep 24 11:29:58 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710C1120874 for ; Tue, 24 Sep 2019 11:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com header.b=l322JjtK; dkim=pass (1024-bit key) header.d=digicert.com header.b=pkdRFbup 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 b97GH84Oew8G for ; Tue, 24 Sep 2019 11:29:54 -0700 (PDT) Received: from us-smtp-delivery-173.mimecast.com (us-smtp-delivery-173.mimecast.com [63.128.21.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0CA71200CC for ; Tue, 24 Sep 2019 11:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1569349793; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=BFs2fBcniStFl7mqdFjUZGdHgJj/iWpd0trgKLMG5D8=; b=l322JjtKYkCmjAFcmUKs5H08bSipaRH3mUPcL9VO6FBw/WuzkIMGwqJP2YH4MF5hz7/tED dVRPbj/UwGCJDxYja6w2bEdkONRCm72PttzU5kgJkwC48BeOfpT5eL/ipE0R0FJRrI9s+J 49QsO2rXeFfo5bAAgSEg2MY8GX3j/gM= Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-bn3nam04lp2056.outbound.protection.outlook.com [104.47.46.56]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-324-Mv-0dKixN7u1-7-_MLkKJA-1; Tue, 24 Sep 2019 14:29:50 -0400 X-MC-Unique: Mv-0dKixN7u1-7-_MLkKJA-1 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QcFbHe/5hF+9rRjOpqoLPalvedljSbOy7EWYugv6tFX+/I2BBewg/BFz82Athte6gSV0kVVUoOfGnFAHwMGyCaY+3YmEMFNUFlziozp25EBe1yR2S7qhq7aaBfyM2llKGazcu2j5z/wtCc0ZJ5WgF9q8d5bb/Xbbi25OEeA1bMdx7LwXZYmy5U6WvIWN4nH5TYBVdC8urq7eqiuJ/jnIPB7S4vjGypaidjeQz4UjjCyAWePDLQ1AwiPZQZEyYhevhpSQD1ryWNhLr6uYsYzDsSnlYs83uszSKSG8OTlmJziAfmtofYBS9GiCff0ZxJkqUIl5Pz6bwYFAwtxFQ+vgMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BFs2fBcniStFl7mqdFjUZGdHgJj/iWpd0trgKLMG5D8=; b=Y3yemm9GyzPuusu76OflTiCmENwSKjBN4W23Y+US2omMyyxM4sy0Cp5JnTvxDtwJVChanFlmtiEFze1rGYG0Oi1bhFg8xy0E0nAMCyuTEWKAmI/vJa68qMy/WO/sL2eIwwi0LTstjCcmvHHbBwWjuf21k56fbOMK3vP/UvJ9ycEUPRKE/WmZTamtUStfKGlSHvRGqDP+TeVmvS/JyNLJDfgB4ABXvh6o4wqqUrTNo3XtlXVhNInF3WAYpDq2bOvQQS3IvWm/R+cmtH3zXjx3ZwTiQM6FhrUm+qr9Pi/Jpc5+mkdjdjal1ZSgGNguX6Z4tT6DpA5yowqcqaSYPk1Qow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=digicert.com; dmarc=pass action=none header.from=digicert.com; dkim=pass header.d=digicert.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BFs2fBcniStFl7mqdFjUZGdHgJj/iWpd0trgKLMG5D8=; b=pkdRFbupbJFjX/kwk37f8wOMkngqElwRiFwZUEk+oYg3tqi/jp6VUNoMivtO+iYlnA2hWeMNSPhJ7wbtmyHnQpfUSvxLX0LFLRffiacyyPCsdepFlK+S8w+1TuqDoeV/MVtSGI0h7DYFsc7gcm128LH2YspsJtZaPxziCP4NNOQ= Received: from MWHPR14MB1456.namprd14.prod.outlook.com (10.173.232.10) by MWHSPR00MB73.namprd14.prod.outlook.com (10.172.167.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.18; Tue, 24 Sep 2019 18:29:48 +0000 Received: from MWHPR14MB1456.namprd14.prod.outlook.com ([fe80::f436:fd5a:1938:6a92]) by MWHPR14MB1456.namprd14.prod.outlook.com ([fe80::f436:fd5a:1938:6a92%12]) with mapi id 15.20.2284.023; Tue, 24 Sep 2019 18:29:48 +0000 From: Tim Hollebeek To: "Salz, Rich" , RFC Errata System , "housley@vigilsec.com" , "rdd@cert.org" , "kaduk@mit.edu" CC: "spasm@ietf.org" , "nay486028@gmail.com" Thread-Topic: [lamps] [Editorial Errata Reported] RFC8649 (5863) Thread-Index: AQHVcv+yM3aSfYKAzkWaFHW3SoO3J6c7HpmAgAAHWEA= Date: Tue, 24 Sep 2019 18:29:47 +0000 Message-ID: References: <20190924174350.35F53B80836@rfc-editor.org> <3C3C5B32-8858-4699-BC27-D0BA79AC3CAE@akamai.com> In-Reply-To: <3C3C5B32-8858-4699-BC27-D0BA79AC3CAE@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tim.hollebeek@digicert.com; x-originating-ip: [98.111.253.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cddaf337-b911-4190-f264-08d7411d2e34 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(49563074)(7193020); SRVR:MWHSPR00MB73; x-ms-traffictypediagnostic: MWHSPR00MB73: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0170DAF08C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(366004)(136003)(376002)(396003)(13464003)(199004)(189003)(7696005)(6436002)(6506007)(9686003)(26005)(55016002)(102836004)(2906002)(186003)(2171002)(33656002)(110136005)(54906003)(99286004)(316002)(86362001)(2201001)(8676002)(8936002)(81166006)(66616009)(52536014)(76116006)(76176011)(81156014)(6246003)(53546011)(66446008)(66476007)(66556008)(64756008)(66946007)(478600001)(4326008)(14454004)(476003)(25786009)(74316002)(305945005)(2501003)(7736002)(11346002)(71190400001)(229853002)(446003)(6116002)(3846002)(44832011)(256004)(5660300002)(486006)(4744005)(99936001)(66066001)(71200400001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHSPR00MB73; H:MWHPR14MB1456.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 3BbAHLQ99pG0sXVgEYLys8/oo+u/j5zXlczNvuy2cgb9i8XPyiBUtojVJEcOwWx4BFnO/byGGfezxBKG/70cDzRwPA8hkCmmCbVihkswpllXWVnDYvF73+7BBbXpy5FkFxur9SMCucWH0/fE2O7Z0z3xpcp8qghe4e/dO28qcS4y6Mu0UkLoEwEuw8QHfJ7VtRH03wHeBOMOskabPfT511SvbbzT0dHPlwTJPOViDDxcWX7T2cKblCfZL+RYZQnEoNuvx+2xQOcguDRx5n8/cEZMhg8RK4omO2bU8vgEAaEfmCnJChpoOp72wpebmGwW17TYufZeDfmVsBELBVgJytba8HyhKbEwZG2tAZhL8DVf1805o8xh9uk1ok6QmhFHRahm+ONBf1oGLqw2BMuQRIVkzEcEMKwXbmtAm6xe2yE= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_027B_01D572E4.7A8F4FA0" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: cddaf337-b911-4190-f264-08d7411d2e34 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2019 18:29:47.8594 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jPrS6BGQKmGXRuFtjwOxtHiCMxgVpEPT3uPFINnlxTgCsADZby7wFxJEZY0k5AZO+pWMTH0HALWXuVeknY8SDYNs65/mfIaY2U+xf6kxAtI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHSPR00MB73 Archived-At: Subject: Re: [lamps] [Editorial Errata Reported] RFC8649 (5863) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 18:29:57 -0000 ------=_NextPart_000_027B_01D572E4.7A8F4FA0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I had the same reaction. -Tim > -----Original Message----- > From: Salz, Rich > Sent: Tuesday, September 24, 2019 2:03 PM > To: RFC Errata System ; housley@vigilsec.com; > rdd@cert.org; kaduk@mit.edu; Tim Hollebeek > > Cc: spasm@ietf.org; nay486028@gmail.com > Subject: Re: [lamps] [Editorial Errata Reported] RFC8649 (5863) > > I am not sure what this errata is trying to say, but the "Grammer" is > spelled > wrong. > I guess this should be closed? > ------=_NextPart_000_027B_01D572E4.7A8F4FA0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTkwOTI0MTgyOTMxWjAvBgkqhkiG9w0BCQQxIgQgYyv9b9HSyxxOxCtRRGAUhAMi1Rkg DyUOjooKmrRjWOMwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAFes6HJ/Qig3gE26c2WsjdYcakFwamCjtSLvNhUB9YPLry6YNRkp4nxoci3wQTAG02qRA94e NrTAcVhmUp6E1Yh4T0zIIqVN2QoYTchUauIx/Gt/3VkFFq3qjyjThFb6lGIJ6izTA1tm0FwJCDgs CHwOEYRhq/EfQZaksdhbDdErEeUfIdh6LGSYBOmDkT9h5vMFNYCYin24aCUavZ2vjJtzgpzq/FyR 32v7/zE3JWWMrO7ivrnBSP9cmWDQeeuaX+Gmdm/9GWAJaginFTeNHJEaTIP3xWF+O5xxN9zq3qlV Fx7lfC9MpLARdzPFdgkjkRgTyZxo0AwXsgNqrhmgHUAAAAAAAAA= ------=_NextPart_000_027B_01D572E4.7A8F4FA0-- From nobody Tue Sep 24 11:36:28 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDE91208BF for ; Tue, 24 Sep 2019 11:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 HB0d37UDidTe for ; Tue, 24 Sep 2019 11:36:25 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B84D1208A6 for ; Tue, 24 Sep 2019 11:36:25 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x8OIaB8x017203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Sep 2019 14:36:13 -0400 Date: Tue, 24 Sep 2019 11:36:10 -0700 From: Benjamin Kaduk To: Tim Hollebeek Cc: "Salz, Rich" , RFC Errata System , "housley@vigilsec.com" , "rdd@cert.org" , "spasm@ietf.org" , "nay486028@gmail.com" Message-ID: <20190924183610.GE6424@kduck.mit.edu> References: <20190924174350.35F53B80836@rfc-editor.org> <3C3C5B32-8858-4699-BC27-D0BA79AC3CAE@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [lamps] [Editorial Errata Reported] RFC8649 (5863) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 18:36:27 -0000 The RFC Editor can just delete reports like this. -Ben On Tue, Sep 24, 2019 at 06:29:47PM +0000, Tim Hollebeek wrote: > I had the same reaction. > > -Tim > > > -----Original Message----- > > From: Salz, Rich > > Sent: Tuesday, September 24, 2019 2:03 PM > > To: RFC Errata System ; housley@vigilsec.com; > > rdd@cert.org; kaduk@mit.edu; Tim Hollebeek > > > > Cc: spasm@ietf.org; nay486028@gmail.com > > Subject: Re: [lamps] [Editorial Errata Reported] RFC8649 (5863) > > > > I am not sure what this errata is trying to say, but the "Grammer" is > > spelled > > wrong. > > I guess this should be closed? > > > From nobody Tue Sep 24 11:38:04 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8CD81208BF for ; Tue, 24 Sep 2019 11:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com header.b=LOftz44g; dkim=pass (1024-bit key) header.d=digicert.com header.b=wZOfLis0 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 ZAKMq0jfX4EK for ; Tue, 24 Sep 2019 11:37:59 -0700 (PDT) Received: from us-smtp-delivery-173.mimecast.com (us-smtp-delivery-173.mimecast.com [63.128.21.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4480C1208A6 for ; Tue, 24 Sep 2019 11:37:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1569350278; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=IS2Bqo8XitYWNC73mMXH9OKeiqzxpsMuzXwLHFwQzLg=; b=LOftz44g4SInV7WR5fyHU0HuKnyQCuIt7zoSrTqlmN2UEgpkIDQcM2TIKsNyaQayQk7aaw 6EDjycJXduMfXCYDsaJEnkBUQKRB2/D/lfYXS+Cl+Ub4gsvujKdUDfc3doHlH4gsOu2Heg 0rlUnD6RfpJPC8VWClRqYOFNhqKiXwM= Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-co1nam05lp2056.outbound.protection.outlook.com [104.47.48.56]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-130-7EmZcEfEP_ynFeMSXkj9Ew-1; Tue, 24 Sep 2019 14:37:42 -0400 X-MC-Unique: 7EmZcEfEP_ynFeMSXkj9Ew-1 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fTD+OLHAFbOfsZ5BU/NyevwGZDF1FYS2YrJOgpqvyeododzj+dzmS2nOCRX44/3z+Z4PeyQo+COu8t+6zVXRvt+rhLAijAmVTNc3ThGmSckMzTDXYtp2pYn6rxQQH1pTqsrFL/xWnjKdFL1uWDlCYX7bfiFBaCE7/cwlcAzoIiW23omqttX4FwPmkcwfTx04vfaeVF/JbctMCXTbYIg9shrLsvgTzeZ8mDgzgU0MqeA2uNfFRChQJGS4MqpttQKjN9BZiWolDgg1K6NAjME2geUghSstoa1p4Qdm0EsVQ4N7auq62I6T3p26YW+Pi6XvbdiVwr5ncVAYS9Vmc2V+gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IS2Bqo8XitYWNC73mMXH9OKeiqzxpsMuzXwLHFwQzLg=; b=XY3UMPSEVXfp6LfjgG/8I/NWTZURmmYH8rWEWkROE8zrd7/9ypGV1MoTo0Mqe+IiklmWtgCckpdPE+KKeaoz41hC3ekb8NNP7Mq/bXIGau17LWUBgTUDgfRjxp/yM/zGWHkL4d+uMcpQZRMDKAmzZBV6oCxaUMsvKKFyeloAODVR8khbzSkS0r9dknvVT5//NdR6ex8obxAIyIItpPqfeyPTwih0U6T2OPNQ87//QSgIGW1FMsB1+xJbhdeATYm1eqTIWY5YLzor7lJrPV2qpzrWME37pzlEvQV4CdZuAqdjO7yjy6skg+vLjOddtZmQ3pAPY9lK7xcpvjdtPaPy6A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=digicert.com; dmarc=pass action=none header.from=digicert.com; dkim=pass header.d=digicert.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IS2Bqo8XitYWNC73mMXH9OKeiqzxpsMuzXwLHFwQzLg=; b=wZOfLis0F3BIoFG6dF4NYznNGhoYGURDHKFbW7JwylH/nEIL2H7ZiRq0uh7YuKem4RlYf2a3qhnpPWv3cMTFb0CwEyq0A05t/gdLP/0b4WsgOB+65Q+9AZ5ENAsrvpLk4BofF+INqXHUJrNaKKNZQPO0g+HHOTHlnyLozG9H7Ao= Received: from MWHPR14MB1456.namprd14.prod.outlook.com (10.173.232.10) by MWHPR14MB1247.namprd14.prod.outlook.com (10.173.102.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.20; Tue, 24 Sep 2019 18:37:39 +0000 Received: from MWHPR14MB1456.namprd14.prod.outlook.com ([fe80::f436:fd5a:1938:6a92]) by MWHPR14MB1456.namprd14.prod.outlook.com ([fe80::f436:fd5a:1938:6a92%12]) with mapi id 15.20.2284.023; Tue, 24 Sep 2019 18:37:39 +0000 From: Tim Hollebeek To: Benjamin Kaduk CC: "Salz, Rich" , RFC Errata System , "housley@vigilsec.com" , "rdd@cert.org" , "spasm@ietf.org" , "nay486028@gmail.com" Thread-Topic: [lamps] [Editorial Errata Reported] RFC8649 (5863) Thread-Index: AQHVcv+yM3aSfYKAzkWaFHW3SoO3J6c7HpmAgAAHWECAAAHuAIAAAEvg Date: Tue, 24 Sep 2019 18:37:38 +0000 Message-ID: References: <20190924174350.35F53B80836@rfc-editor.org> <3C3C5B32-8858-4699-BC27-D0BA79AC3CAE@akamai.com> <20190924183610.GE6424@kduck.mit.edu> In-Reply-To: <20190924183610.GE6424@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tim.hollebeek@digicert.com; x-originating-ip: [98.111.253.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 78337864-22ac-4687-ad22-08d7411e46e2 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(49563074)(7193020); SRVR:MWHPR14MB1247; x-ms-traffictypediagnostic: MWHPR14MB1247: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0170DAF08C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(396003)(346002)(376002)(39860400002)(189003)(199004)(13464003)(86362001)(55016002)(71200400001)(44832011)(71190400001)(2171002)(476003)(486006)(5660300002)(9686003)(6246003)(52536014)(7736002)(11346002)(305945005)(74316002)(2906002)(229853002)(446003)(25786009)(14444005)(256004)(54906003)(316002)(6436002)(7696005)(76116006)(76176011)(53546011)(6506007)(66066001)(8676002)(66616009)(14454004)(81166006)(81156014)(99286004)(66556008)(64756008)(3846002)(66476007)(478600001)(186003)(33656002)(8936002)(6916009)(99936001)(66946007)(6116002)(102836004)(26005)(4326008)(66446008); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR14MB1247; H:MWHPR14MB1456.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 82dEEB8oduhc3vuUxfZWr3ZdESqnhD0cbFc5baEmtDFyQa9ydcrOxoEEIyIxtewi8N5ridx3Kwq18MIEjLnFUHTfhqRIghWuFeLbiM+T5I8SbXpIo7Ncdct9KpOUtm7OzJio3llJnYioOgOuUOH8P2hRK9Da4GahI/MyVLkyrKODd9++6FL7oc2PhPLawwmk3QhCR/XNn701sku7/zDFBOrrkQeyvlBEs5aX7YNUMLERSpR7r/4SmQF/8FEIgWrf117nCAX7FCjgSk1zZmXx0QiUxOiml7vo15pGfYhSlLf+YzVRbR9FHwITaYJFwwsVf96tj94DB89VwR8WpgJHy4NLjWmWjZY2rC5DJ63eR7fdo6VfzT+p/21FjR7LNZ2I2PRcZqu6sXMPSH/mV8otfSwMCx+bVWWmvHXWWAx0aMs= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_027F_01D572E5.943CFDC0" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 78337864-22ac-4687-ad22-08d7411e46e2 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2019 18:37:38.8440 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wYkezOc330GxV26euXUIytNnfFxiwjLhdJ0kJ3WuRmpfybBrTEpAU3cOb8fbmpPHSNJPV4VTL6kxI8z/TzY2SVAE820sV2YdBmv5t1yOXiM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR14MB1247 Archived-At: Subject: Re: [lamps] [Editorial Errata Reported] RFC8649 (5863) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 18:38:02 -0000 ------=_NextPart_000_027F_01D572E5.943CFDC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Then that's what I recommend we do here. -Tim > -----Original Message----- > From: Benjamin Kaduk > Sent: Tuesday, September 24, 2019 2:36 PM > To: Tim Hollebeek > Cc: Salz, Rich ; RFC Errata System editor.org>; housley@vigilsec.com; rdd@cert.org; spasm@ietf.org; > nay486028@gmail.com > Subject: Re: [lamps] [Editorial Errata Reported] RFC8649 (5863) > > The RFC Editor can just delete reports like this. > > -Ben > > On Tue, Sep 24, 2019 at 06:29:47PM +0000, Tim Hollebeek wrote: > > I had the same reaction. > > > > -Tim > > > > > -----Original Message----- > > > From: Salz, Rich > > > Sent: Tuesday, September 24, 2019 2:03 PM > > > To: RFC Errata System ; > > > housley@vigilsec.com; rdd@cert.org; kaduk@mit.edu; Tim Hollebeek > > > > > > Cc: spasm@ietf.org; nay486028@gmail.com > > > Subject: Re: [lamps] [Editorial Errata Reported] RFC8649 (5863) > > > > > > I am not sure what this errata is trying to say, but the "Grammer" > > > is spelled wrong. > > > I guess this should be closed? > > > > > > ------=_NextPart_000_027F_01D572E5.943CFDC0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTkwOTI0MTgzNzIzWjAvBgkqhkiG9w0BCQQxIgQg27z4/fas5tnpkGZYv0O7/4j1rHcS Y4gBbWdeThBlQOAwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAH2aghQIgXHlhpTI8gQgPTukQiF87o2WLkw+n8xJ5KkwFRMCZp7PYUj+CeaeBXTssLVC2EUT FTdJwOh6PHi9FGv5CK7RTwqTf01GZbQDgr+z4lqyDNpEv3aN7WXpd9cNppXmiY2/LGxQ4WlA6e2p GhC8JaX99mJXcqgVupvWNkqxsKF2H55CeEC2UTvWGsQ++EBbveAIBSHbtRVI29c4+u0YQJeZOF8N LnqvS9BN84GCEGnp3BT+8yTD/LHApE+/SwS4/ony0ti5wtNXgjAQ0/xAvYUR6HJh/ExXOo5cz5yW tKqd2MNsvFhahO55S2P92xGeHtvyHKWAGYKIYtOZQ1wAAAAAAAA= ------=_NextPart_000_027F_01D572E5.943CFDC0--