From nobody Sat Feb 1 07:44:01 2020 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 94283120804 for ; Sat, 1 Feb 2020 07:44:00 -0800 (PST) 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 B2dh14BvV6_t for ; Sat, 1 Feb 2020 07:43:58 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3AE812022C for ; Sat, 1 Feb 2020 07:43:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 18C00300AFB for ; Sat, 1 Feb 2020 10:17:17 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SoNH1jRsMSDs for ; Sat, 1 Feb 2020 10:17:15 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 978AA3009FF for ; Sat, 1 Feb 2020 10:17:15 -0500 (EST) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_421D2B81-31E6-441B-9307-746413C5C137" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 1 Feb 2020 10:43:56 -0500 References: <157850673005.22571.2917503256026347682@ietfa.amsl.com> To: LAMPS WG In-Reply-To: Message-Id: <40D34A3B-1552-4D49-A065-1DBE57A75069@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] LAMPS WG Last Call for draft-ietf-lamps-5480-ku-clarifications-00 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, 01 Feb 2020 15:44:01 -0000 --Apple-Mail=_421D2B81-31E6-441B-9307-746413C5C137 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The shepherd write-up has been posted. See = https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/s= hepherdwriteup/ = I will push the "publication requested" button right after sending this = note. Russ > On Jan 24, 2020, at 1:07 PM, Russ Housley = wrote: >=20 > Thanks for the discussion. I see consensus for publication. I will = begin preparing a document shepherd write-up. >=20 > Russ >=20 >=20 >> On Jan 8, 2020, at 2:51 PM, Russ Housley = wrote: >>=20 >> This is a very short document, and it had some review prior to WG = adoption. So, now that the document has been adopted, I think it is = ready for WG Last Call. >>=20 >> This is the LAMPS WG Last Call for "Clarifications for Elliptic Curve = Cryptogtaphy Subject Public Key Information" = . Please review the = document and send your comments to the list by 24 January 2020. >>=20 >> The datatracker page for the document is = https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications-0= 0/ >>=20 >> Thanks, >> Russ & Tim >=20 --Apple-Mail=_421D2B81-31E6-441B-9307-746413C5C137 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The = shepherd write-up has been posted.  See https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clari= fications/shepherdwriteup/

I will push the "publication requested" button right after = sending this note.

Russ


On Jan = 24, 2020, at 1:07 PM, Russ Housley <housley@vigilsec.com> wrote:

Thanks= for the discussion.  I see consensus for publication.  I will = begin preparing a document shepherd write-up.

Russ


On Jan 8, 2020, at 2:51 PM, Russ Housley <housley@vigilsec.com> wrote:

This is a very short document, and it had some review prior = to WG adoption.  So, now that the document has been adopted, I = think it is ready for WG Last Call.

This is = the LAMPS WG Last Call for "Clarifications for Elliptic Curve = Cryptogtaphy Subject Public Key Information" = <draft-ietf-lamps-5480-ku-clarifications-00>.  Please review = the document and send your comments to the list by 24 January 2020.

The datatracker page for the document is https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clari= fications-00/

Thanks,
Russ = & Tim


= --Apple-Mail=_421D2B81-31E6-441B-9307-746413C5C137-- From nobody Sat Feb 1 07:44:25 2020 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 6FB2812007C; Sat, 1 Feb 2020 07:44:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Cc: spasm@ietf.org, lamps-chairs@ietf.org, iesg-secretary@ietf.org, housley@vigilsec.com, Russ Housley Message-ID: <158057186344.11621.8664198059030653949.idtracker@ietfa.amsl.com> Date: Sat, 01 Feb 2020 07:44:23 -0800 Archived-At: Subject: [lamps] Publication has been requested for draft-ietf-lamps-5480-ku-clarifications-00 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: Sat, 01 Feb 2020 15:44:24 -0000 Russ Housley has requested publication of draft-ietf-lamps-5480-ku-clarifications-00 as Proposed Standard on behalf of the LAMPS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/ From nobody Sat Feb 1 13:46:13 2020 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 659FF1200F9; Sat, 1 Feb 2020 13:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.435 X-Spam-Level: * X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 8ls_XKe39cMS; Sat, 1 Feb 2020 13:46:08 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB98B12004A; Sat, 1 Feb 2020 13:46:08 -0800 (PST) Received: from dooku.sandelman.ca (dc3829c8a.static.telenet.be [195.130.156.138]) by relay.sandelman.ca (Postfix) with ESMTPS id EB53B1F45B; Sat, 1 Feb 2020 21:46:04 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 3BEDA1A38D2; Sat, 1 Feb 2020 22:46:04 +0100 (CET) From: Michael Richardson To: Benjamin Kaduk cc: "spasm\@ietf.org" , EMU WG In-reply-to: <20200118034732.GZ80030@kduck.mit.edu> References: <26119.1579299579@localhost> <20200118034732.GZ80030@kduck.mit.edu> Comments: In-reply-to Benjamin Kaduk message dated "Fri, 17 Jan 2020 19:47:32 -0800." X-Mailer: MH-E 8.6; nmh 1.7.1-RC3; GNU Emacs 25.2.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Sat, 01 Feb 2020 22:46:04 +0100 Message-ID: <22097.1580593564@dooku> Archived-At: Subject: Re: [lamps] Using public CA infrastructure for autonomic bootstrapping over EAP. 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, 01 Feb 2020 21:46:10 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable {did I answer this already?} Benjamin Kaduk wrote: > You mention in a couple places that EAP server certificate should be > identifying an rfc822Name DN, and I think I'm confused about what you > mean. (I suspect I'm seeing "rfc822Name" and jumping to what ACP doe= s, > which is wrong.) Could you walk through an example of what that would > look like to help un-confuse me? There is no connection to the ACP situation. I think that the idea is that the ESSID would be set to an FQDN, and the EAP-TLS server certificate would have the same FQDN in the rfc822Name. Given ACME dns-01 type challenge, that would provide evidence that the entity was authoritative for the name. In a LE ACME certificate that w= as issued via dns-01, I found two policy OIDS: 1.3.6.1.4.1.44947.1.1.1 (unknow= n) and 2.23.140.1.2.1 (domain-validated). I think that domain-validated can mean http-01 or dns-01, but I don't know. I don't know if the above mechanism really works. I don't think that this would matter if the goal was TEAP-BRSKI, because we can pin an EE certificate from any origin. Once the voucher is issued, then the pledge will download a new set of trust anchors, so it doesn't really matter once the device is enrolled.=20=20 It can then use the new trust anchor with (any) other EAP mechanisms to con= nect afterwards. Critically, if the trust anchor is a public anchor, then the client needs to pin the rfc822Name as well as the anchor, otherwise any EE issued by the public trust anchor could be a valid authenticator. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl418ZsACgkQlUzhVv38 QpA0wwf9GOSKSH5jBBoOezrPZ96V80bMASTgqSPV5+IZBgPlOpqFVNZfgJ8FX1Bw DYYzqXnPywRxTXyD9tTvzMnAtK0UzShNurMAV1f6hqmf/ZjJGKiDqDk5uSyBOLFx bYGiP3Y86KXd7jCGzqLUMIyDqJTLPvWr+5BJOfYige6kIB+DijUxgwvsb5MI/OpS ud+7KQLDyr7HFasZaB0bOGJMRoRAkXW+f/mc0opLyjJfptrR5Os0PRpwSnFs2Fn7 ctYENFqFyHqWVH6OLnzHmOspFzIYFpHoDD2yTATSPR8u7nh7AvksECTDdK4557WN KnRP7bvw4MZyQf3Z3C5x90MuYaCDUg== =sS8b -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Feb 7 06:21:17 2020 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 6E9CA1207FB for ; Fri, 7 Feb 2020 06:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.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 143C4d6-tJgQ for ; Fri, 7 Feb 2020 06:21:14 -0800 (PST) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 D82D3120048 for ; Fri, 7 Feb 2020 06:21:13 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 017ELCGD035361 for ; Fri, 7 Feb 2020 09:21:12 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 017ELCGD035361 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1581085272; bh=z2ZR2SSeIYUCOaG9alLioo5bNUBab0Ij6zio7uDoyuc=; h=From:To:CC:Subject:Date:From; b=HmN+pS1KynV3YcGo2TDihomL9VtJq49VrqqfHEvvKKE9dM1fIk0idvEVI3t1JirPD +bThk0I8l1s9JTKv2Gxn9jQ2zCQGGy2wG4Zxv6dznCuCX9Ete0grJS0BrwAEji2iTG qoD7WO+t0pO1NoG+4vLhj/5HK6vyVWSrEF+IRFgg= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 017ELAXu018559 for ; Fri, 7 Feb 2020 09:21:10 -0500 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0468.000; Fri, 7 Feb 2020 09:21:10 -0500 From: Roman Danyliw To: LAMPS WG CC: Roman Danyliw Thread-Topic: AD review of draft-ietf-lamps-5480-ku-clarifications Thread-Index: AdXdwSSxPZy9/yKrS9SOhzAmUY3+oQ== Date: Fri, 7 Feb 2020 14:21:09 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0216F2A290@marchand> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [lamps] AD review of draft-ietf-lamps-5480-ku-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: Fri, 07 Feb 2020 14:21:16 -0000 Hi! I conducted an AD review of draft-ietf-lamps-5480-ku-clarifications and agr= ee that it is ready. I'm advancing it to IETF LC. Thanks, Roman From nobody Fri Feb 7 06:35:50 2020 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 88535120048; Fri, 7 Feb 2020 06:35:46 -0800 (PST) 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.117.0 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: rdd@cert.org, lamps-chairs@ietf.org, Russ Housley , housley@vigilsec.com, spasm@ietf.org, draft-ietf-lamps-5480-ku-clarifications@ietf.org Content-Transfer-Encoding: 7bit Reply-To: last-call@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <158108614655.11602.5356133964505115022.idtracker@ietfa.amsl.com> Date: Fri, 07 Feb 2020 06:35:46 -0800 Archived-At: Subject: [lamps] Last Call: (Clarifications for Elliptic Curve Cryptogtaphy Subject Public Key Information) to Proposed Standard 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, 07 Feb 2020 14:35:46 -0000 The IESG has received a request from the Limited Additional Mechanisms for PKIX and SMIME WG (lamps) to consider the following document: - 'Clarifications for Elliptic Curve Cryptogtaphy Subject Public Key Information' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-02-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document updates RFC 5480 to specify semantics for the keyEncipherment and dataEncipherment key usage bits when used in certificates that support Elliptic Curve Cryptography. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Feb 12 15:12:34 2020 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 3188612001E; Wed, 12 Feb 2020 15:12:30 -0800 (PST) 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 dVo_IbZCvIiA; Wed, 12 Feb 2020 15:12:28 -0800 (PST) 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 E62D7120013; Wed, 12 Feb 2020 15:12:28 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 90CEAF40721; Wed, 12 Feb 2020 15:12:04 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, spasm@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20200212231204.90CEAF40721@rfc-editor.org> Date: Wed, 12 Feb 2020 15:12:04 -0800 (PST) Archived-At: Subject: [lamps] =?utf-8?q?RFC_8708_on_Use_of_the_HSS/LMS_Hash-Based_Sign?= =?utf-8?q?ature_Algorithm_in_the_Cryptographic_Message_Syntax_=28CMS=29?= 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, 12 Feb 2020 23:12:30 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8708 Title: Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS) Author: R. Housley Status: Standards Track Stream: IETF Date: February 2020 Mailbox: housley@vigilsec.com Pages: 14 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-lamps-cms-hash-sig-10.txt URL: https://www.rfc-editor.org/info/rfc8708 DOI: 10.17487/RFC8708 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. This document is a product of the Limited Additional Mechanisms for PKIX and SMIME Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Feb 17 18:29:12 2020 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 30F2F1207FD; Mon, 17 Feb 2020 01:31:44 -0800 (PST) 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.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <158193190415.17941.13117772687132829046@ietfa.amsl.com> Date: Mon, 17 Feb 2020 01:31:44 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cmp-updates-00.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, 17 Feb 2020 09:31:44 -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 : CMP Updates Author : Hendrik Brockhaus Filename : draft-ietf-lamps-cmp-updates-00.txt Pages : 15 Date : 2020-02-16 Abstract: This document contains a set of updates to the base syntax of Certificate Management Protocol (CMP) version 2. This document updates RFC 4210. Specifically, the CMP services updated in this document comprise the enabling of using EnvelopedData instead of EncryptedValue and the definition of extended key usages to identify certificates of CMP endpoints on certification and registration authorities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cmp-updates/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cmp-updates-00 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cmp-updates-00 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 Mon Feb 17 18:29:45 2020 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 98CBB12081E; Mon, 17 Feb 2020 02:09:30 -0800 (PST) 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.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <158193417054.18005.4720758486254855932@ietfa.amsl.com> Date: Mon, 17 Feb 2020 02:09:30 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-lightweight-cmp-profile-00.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, 17 Feb 2020 10:09:31 -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 : Lightweight CMP Profile Authors : Hendrik Brockhaus Steffen Fries David von Oheimb Filename : draft-ietf-lamps-lightweight-cmp-profile-00.txt Pages : 70 Date : 2020-02-14 Abstract: The goal of this document is to facilitate interoperability and automation by profiling the Certificate Management Protocol (CMP) version 2 and the related Certificate Request Message Format (CRMF) version 2 and the HTTP Transfer for the Certificate Management Protocol. It specifies a subset of CMP and CRMF focusing on typical uses cases relevant for managing certificates of devices in many industrial and IoT scenarios. To limit the overhead of certificate management for more constrained devices only the most crucial types of transactions are specified as mandatory. To foster interoperability also in more complex scenarios, other types of transactions are specified as recommended or optional. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-lightweight-cmp-profile/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-lightweight-cmp-profile-00 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile-00 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 Feb 18 19:08:07 2020 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 A18E312089A; Tue, 18 Feb 2020 19:07:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dale Worley via Datatracker To: Cc: draft-ietf-lamps-5480-ku-clarifications.all@ietf.org, last-call@ietf.org, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Dale Worley Message-ID: <158208167058.19287.14585229025387805615@ietfa.amsl.com> Date: Tue, 18 Feb 2020 19:07:50 -0800 Archived-At: Subject: [lamps] Genart last call review of draft-ietf-lamps-5480-ku-clarifications-00 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, 19 Feb 2020 03:07:51 -0000 Reviewer: Dale Worley Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-lamps-5480-ku-clarifications-00 Reviewer: Dale R. Worley Review Date: 2020-02-18 IETF LC End Date: 2020-02-07 IESG Telechat date: [unknown] Summary: This draft is on the right track but has open issues, described in the review. The text is difficult to follow in places. I believe that the WG has a clear understanding of what is intended, but a few small editorial errors have unfortunately rendered the text incorrect and contradictory to RFC 5480. Note that I am unfamiliar with the details of PKI certificates; this review is based largely on what I have learned from RFC 5480 and this I-D. >From the discussion it appears that id-ecDH and id-ecMQV are "key agreement algorithms" and that, as such, they should not be used with keyEncipherment or dataEncipherment. [this draft, section 3] Conversely, id-ecPublicKey is not a "key agreement algorithm". [RFC 5480, section 2.1.2, para. 1, sentence 1] 1. Introduction This document corrects this omission, by updating Section 3 of [RFC5480] to make it clear that neither keyEncipherment nor the dataEncipherment key usage bits are set for key agreement algorithms. This could be clearer by replacing or augmenting "key agreement algorithms" with a description of which of these algorithms are key agreement algorithms, viz., id-ecDH and id-ecMQV. Otherwise, one must first have read RFC 5480 to understand this introduction correctly. 3. Updates to Section 3 If the keyUsage extension is present in a certificate that indicates id-ecPublicKey as algorithm of AlgorithmIdentifier [RFC2986] in SubjectPublicKeyInfo, then following values MUST NOT be present: keyEncipherment; and dataEncipherment. If the keyUsage extension is present in a certificate that indicates id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following values also MUST NOT be present: keyEncipherment; and dataEncipherment. The structure of this section is peculiar, since it presents almost the same text about "id-ecPublicKey" and about "id-ecDH or id-ecMQV". If the intention is to say the same thing about all three, these should be folded together. It is also not clear why the first paragraph refers to AlgorithmIdentifier but the second paragraph uses SubjectPublicKeyInfo to refer to essentially the same thing. But this text appears to contradict the statement in [RFC 5480] that the usage of id-ecPublicKey is "unrestricted" and is not a key agreement algorithm, in which case the first paragraph should say "the following values MAY be present". (In which case, the "also" in the 2nd paragraph should be omitted.) [END] From nobody Thu Feb 20 06:49:36 2020 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 F370312003E for ; Thu, 20 Feb 2020 06:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=sn3rd.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 uGMhuhxnZPu2 for ; Thu, 20 Feb 2020 06:49:27 -0800 (PST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 A7643120047 for ; Thu, 20 Feb 2020 06:49:26 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id i23so3034519qtr.5 for ; Thu, 20 Feb 2020 06:49:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=unwOyO4EBq/Bdfa+oHelhW0BKHkO8L4cEViu2Jrsods=; b=FScu+TGcTCori1Tyog3xMOFQmVc9QgnQWS8L7Ndy5edF1b24g1lnq6QewsWsZnfnI1 29e4YTjIzfBUiygbSdR3SIFUR1vOmHPaDkVVqEwd5H7MfNrH+unrRgYYGJDNXzVDskiQ 8oLZIbQlHjfRBjkwz90jHvIL5OfClJNYyXisM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=unwOyO4EBq/Bdfa+oHelhW0BKHkO8L4cEViu2Jrsods=; b=nZreCULn99hFHYJxn56o+Ewp8eGX+1I6+YkVDEbX4BQ6zJ/JJKFH1YU88sRVZ3CSmX eKZ0We4ePk6QQybA55VTWnzacZHCijSeRUY5CS3LmfJrjrf4pAS9HQU3gpLy510VR3De OuJPNAQuWBkklT6yqW7MDSM/9dASV8vHv2bbQYC7m2OgQAdGwYWkXMxBasmQmqDP41cJ P2fcufjP03NqgYj99ocUbQnjqx4bjE0PyWeI4YPN5y9FTMA4Cz2AZvNMoXCfPXgge8jJ U/TNdxxZ9hsR6Z7fdzQ7s1kzuwJfdgz5l7x6Gj0BCXSIhhLp9WgiRVvAfjVwoKCSOVwA vGPw== X-Gm-Message-State: APjAAAUREXKq9aL7IQc6qessmduSg/c0kiXhD1odZ1LbfS/T3fLrNL1p ksGMH7r8cFzYgZOB2h90M2qAEg== X-Google-Smtp-Source: APXvYqxicgTwSbIo1t4beYlaXDeLs68Ri3yXWmfz7xfP1Q/HnpF4bFo9mxLJhdaLiUwftNztPgxCyg== X-Received: by 2002:ac8:6784:: with SMTP id b4mr25961959qtp.27.1582210164566; Thu, 20 Feb 2020 06:49:24 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id l6sm1855980qti.10.2020.02.20.06.49.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Feb 2020 06:49:23 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: <158208167058.19287.14585229025387805615@ietfa.amsl.com> Date: Thu, 20 Feb 2020 09:49:23 -0500 Cc: gen-art@ietf.org, draft-ietf-lamps-5480-ku-clarifications.all@ietf.org, last-call@ietf.org, spasm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9A18B0AA-084C-4B25-9B8B-0C166E7FA1D4@sn3rd.com> References: <158208167058.19287.14585229025387805615@ietfa.amsl.com> To: Dale Worley X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Genart last call review of draft-ietf-lamps-5480-ku-clarifications-00 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, 20 Feb 2020 14:49:29 -0000 Dale, Hi! And, thanks for your review comments in-line. spt > On Feb 18, 2020, at 22:07, Dale Worley via Datatracker = wrote: >=20 > Reviewer: Dale Worley > Review result: Ready with Issues >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed by > the IESG for the IETF Chair. Please treat these comments just like > any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-lamps-5480-ku-clarifications-00 > Reviewer: Dale R. Worley > Review Date: 2020-02-18 > IETF LC End Date: 2020-02-07 > IESG Telechat date: [unknown] >=20 > Summary: >=20 > This draft is on the right track but has open issues, described > in the review. >=20 > The text is difficult to follow in places. I believe that the WG has > a clear understanding of what is intended, but a few small editorial > errors have unfortunately rendered the text incorrect and > contradictory to RFC 5480. Sometimes when you are too familiar with the context you assume too much = so a fresh set of eye can help! > Note that I am unfamiliar with the details of PKI certificates; this > review is based largely on what I have learned from RFC 5480 and this > I-D. >=20 >> =46rom the discussion it appears that id-ecDH and id-ecMQV are "key > agreement algorithms" and that, as such, they should not be used with > keyEncipherment or dataEncipherment. [this draft, section 3] > Conversely, id-ecPublicKey is not a "key agreement algorithm". [RFC > 5480, section 2.1.2, para. 1, sentence 1] Ah ... this might be where some of misunderstanding comes from because = id-ecPublicKey MAY be a key agreement algorithm that is why it is = =E2=80=9Cunrestricted=E2=80=9D. In other words, when key agreement = certificates can include the following OIDs: id-ecDH (for an EC DH = algorithm), id-ecMQV (for EC MQV), or id-ecPublicKey (for any = algorithm). Here=E2=80=99s the text from 5480 about id-ecPublicKey being = used as key agreement algrithm: If the keyUsage extension is present in an End Entity (EE) certificate that indicates id-ecPublicKey in SubjectPublicKeyInfo, then any combination of the following values MAY be present: digitalSignature; nonRepudiation; and keyAgreement. > 1. Introduction >=20 > This document corrects this omission, by updating Section 3 of > [RFC5480] to make it clear that neither keyEncipherment nor the > dataEncipherment key usage bits are set for key agreement = algorithms. >=20 > This could be clearer by replacing or augmenting "key agreement > algorithms" with a description of which of these algorithms are key > agreement algorithms, viz., id-ecDH and id-ecMQV. Otherwise, one must > first have read RFC 5480 to understand this introduction correctly. See above. I also pondered how much to put in the intro to accommodate those = readers that are not as familiar with RFC 5480. I went the minimal route = since this is supposed to be just adding two sentences to RFC 5480. I = sure hope people that are not intimately familiar with RFC 5480 do = immediately go read RFC 5480 because this draft isn=E2=80=99t all that = much use without doing so :) > 3. Updates to Section 3 >=20 > If the keyUsage extension is present in a certificate that indicates > id-ecPublicKey as algorithm of AlgorithmIdentifier [RFC2986] in > SubjectPublicKeyInfo, then following values MUST NOT be present: >=20 > keyEncipherment; and > dataEncipherment. >=20 > If the keyUsage extension is present in a certificate that indicates > id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following > values also MUST NOT be present: >=20 > keyEncipherment; and > dataEncipherment. >=20 > The structure of this section is peculiar, since it presents almost > the same text about "id-ecPublicKey" and about "id-ecDH or id-ecMQV". > If the intention is to say the same thing about all three, these > should be folded together. There are two reasons I=E2=80=99d like to not merge these two bits of = text: 1. Agreed it is a bit odd, but it does mirror RFC 5480, which talks = about id-ecPublicKey for CA certificates and then EE certificates and = then id-ecDH/id-ecMQV. I guess we could collapse it, but for me then = it=E2=80=99s a style thing and I=E2=80=99d rather mimic the RFC it=E2=80=99= s updating. 2. With separate sentences we leave open the door for ECC encryption = algorithms like ECIES = These algorithm need a lot of metadata (including EC point, KDF = algorithm, hash algorithms, metadata of hash or KDF, etc=E2=80=A6), and = we are not sure, but believe, when specified they will not use = id-ecPublicKey. However, they may use SubjectPublicKeyInfo for their metadata. If we integrate two sentence together, a possible future ECIES draft = will conflict with our draft. > It is also not clear why the first paragraph refers to > AlgorithmIdentifier but the second paragraph uses SubjectPublicKeyInfo > to refer to essentially the same thing. I am pretty sure we did that to provide some context for where the OIDs = go, but you are right the first paragraph could just of easily been: If the keyUsage extension is present in a certificate that indicates id-ecPublicKey in SubjectPublicKeyInfo, I will make that change. > But this text appears to contradict the statement in [RFC 5480] that > the usage of id-ecPublicKey is "unrestricted" and is not a key > agreement algorithm, in which case the first paragraph should say "the > following values MAY be present". (In which case, the "also" in the > 2nd paragraph should be omitted.) See above. Cheers, spt= From nobody Thu Feb 20 07:10:17 2020 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 66E3512003E; Thu, 20 Feb 2020 07:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=gmail.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 sbzidTgQeYqV; Thu, 20 Feb 2020 07:09:56 -0800 (PST) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 A9A7B120024; Thu, 20 Feb 2020 07:09:56 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id k24so5036569ioc.4; Thu, 20 Feb 2020 07:09:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cVR6NzqJPwwyrZBCYpUq/ioNymyqxK/Ph1Q5o79pkCM=; b=qWflKIlWZOFE70FTaLOcNQ/my1gQHmTgSnfaVOc+FmVbzDG1lhWcnzopKUN6qE1/Cv /Ttud/rz9U5n3TgzxhS/4agXbnlhqFeYitnmzMI7BjYgZ9djGgXwV4AMCsnvhREHShpa UDxXCMl4uY4/d8vDGaqYCYna648PowatWNpzg83tMXHUpJJni+Qw6J+RPpUELXF+obhC +wwL3JYTVI/K1zAOw1yQmQs/u+NI4vyuE7hpWBaz8O7Y/heCBJOMFBpSYmITe8hA3E1/ Qi1Z5e37TAWqY5dCfSoKTsRqxWcYSqs5je9uHz9TYXok8GODF+Js/ZEovnDgrB2ZDWpZ l6qQ== 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=cVR6NzqJPwwyrZBCYpUq/ioNymyqxK/Ph1Q5o79pkCM=; b=PNXBPjHl52rSb1pexrgRRii/mdF2K0qkh16BKK+MocArn4yj3kPBFKbsVem1P1VGzt 4VtPUaofjS2uPpKKVHBBJFK220RGtNlDpypKpm/1m4doHedyVi852hV6EkhCvvqFsm+g lNVwmHho1hgGaQ8pxMHy2vWfW9t+WqjLys8gj2Ghs6FQwSleTEhalsNggHlDUHp+6QSh fVXrlr/1kLihxIrgQ+STQttCabbfNOUrTZNDW9POC2wOjILhBm49VAVuOg6EGe9TM8Qv 3d7gVsOjBwaJNNzdMNT6bcLve50HzwmZNS/IJvUB1mt3pd/H7AZCQ+sNFWY4raB8JBZa N3ag== X-Gm-Message-State: APjAAAV0/78RtUW1Vd69OekpgiEi3/cGGC+u34TcPtOWUsQdfZmT70ps tP+goPrRDyCmGq3T/imCIwvv1EbNpLoIhwH1snI= X-Google-Smtp-Source: APXvYqwXGtnQ8EfpvEkZ4TXuf0uKLSfvPj4Kbs024wVoOapqJ8nG4xRe8xyAVayId/tAPTy71mNM5HElAX0YpN7gmqs= X-Received: by 2002:a05:6638:1e6:: with SMTP id t6mr25778798jaq.118.1582211395598; Thu, 20 Feb 2020 07:09:55 -0800 (PST) MIME-Version: 1.0 References: <158208167058.19287.14585229025387805615@ietfa.amsl.com> <9A18B0AA-084C-4B25-9B8B-0C166E7FA1D4@sn3rd.com> In-Reply-To: <9A18B0AA-084C-4B25-9B8B-0C166E7FA1D4@sn3rd.com> From: Tadahiko Ito Date: Thu, 20 Feb 2020 16:09:43 +0100 Message-ID: To: Sean Turner Cc: Dale Worley , gen-art@ietf.org, draft-ietf-lamps-5480-ku-clarifications.all@ietf.org, last-call@ietf.org, LAMPS WG Content-Type: multipart/alternative; boundary="00000000000031bd2c059f034c89" Archived-At: Subject: Re: [lamps] Genart last call review of draft-ietf-lamps-5480-ku-clarifications-00 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, 20 Feb 2020 15:10:02 -0000 --00000000000031bd2c059f034c89 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi let me fix a little. >>These algorithm need a lot of metadata (including EC point, KDF algorithm, hash algorithms, metadata of hash or KDF, etc=E2=80=A6), >>and we are not sure, but believe, when specified they will not use id-ecPublicKey. >>However, they may use SubjectPublicKeyInfo for their metadata. we are not sure, but believe when specified they will not use id-ecPublicKey as a algorithm, but they may use id-ecPublicKey in the metadata field, along with ECIES algorithm identifier in the algorithm field. Regards Tadahiko Ito 2020=E5=B9=B42=E6=9C=8820=E6=97=A5(=E6=9C=A8) 15:49 Sean Turner : > Dale, > > Hi! And, thanks for your review comments in-line. > > spt > > > On Feb 18, 2020, at 22:07, Dale Worley via Datatracker > wrote: > > > > Reviewer: Dale Worley > > Review result: Ready with Issues > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > > Review Team (Gen-ART) reviews all IETF documents being processed by > > the IESG for the IETF Chair. Please treat these comments just like > > any other last call comments. > > > > For more information, please see the FAQ at > > > > . > > > > Document: draft-ietf-lamps-5480-ku-clarifications-00 > > Reviewer: Dale R. Worley > > Review Date: 2020-02-18 > > IETF LC End Date: 2020-02-07 > > IESG Telechat date: [unknown] > > > > Summary: > > > > This draft is on the right track but has open issues, described > > in the review. > > > > The text is difficult to follow in places. I believe that the WG has > > a clear understanding of what is intended, but a few small editorial > > errors have unfortunately rendered the text incorrect and > > contradictory to RFC 5480. > > Sometimes when you are too familiar with the context you assume too much > so a fresh set of eye can help! > > > Note that I am unfamiliar with the details of PKI certificates; this > > review is based largely on what I have learned from RFC 5480 and this > > I-D. > > > >> From the discussion it appears that id-ecDH and id-ecMQV are "key > > agreement algorithms" and that, as such, they should not be used with > > keyEncipherment or dataEncipherment. [this draft, section 3] > > Conversely, id-ecPublicKey is not a "key agreement algorithm". [RFC > > 5480, section 2.1.2, para. 1, sentence 1] > > Ah ... this might be where some of misunderstanding comes from because > id-ecPublicKey MAY be a key agreement algorithm that is why it is > =E2=80=9Cunrestricted=E2=80=9D. In other words, when key agreement certif= icates can include > the following OIDs: id-ecDH (for an EC DH algorithm), id-ecMQV (for EC > MQV), or id-ecPublicKey (for any algorithm). Here=E2=80=99s the text from= 5480 > about id-ecPublicKey being used as key agreement algrithm: > > If the keyUsage extension is present in an End Entity (EE) > certificate that indicates id-ecPublicKey in SubjectPublicKeyInfo, > then any combination of the following values MAY be present: > > digitalSignature; > nonRepudiation; and > keyAgreement. > > > 1. Introduction > > > > This document corrects this omission, by updating Section 3 of > > [RFC5480] to make it clear that neither keyEncipherment nor the > > dataEncipherment key usage bits are set for key agreement algorithms. > > > > This could be clearer by replacing or augmenting "key agreement > > algorithms" with a description of which of these algorithms are key > > agreement algorithms, viz., id-ecDH and id-ecMQV. Otherwise, one must > > first have read RFC 5480 to understand this introduction correctly. > > See above. > > I also pondered how much to put in the intro to accommodate those readers > that are not as familiar with RFC 5480. I went the minimal route since th= is > is supposed to be just adding two sentences to RFC 5480. I sure hope peop= le > that are not intimately familiar with RFC 5480 do immediately go read RFC > 5480 because this draft isn=E2=80=99t all that much use without doing so = :) > > > 3. Updates to Section 3 > > > > If the keyUsage extension is present in a certificate that indicates > > id-ecPublicKey as algorithm of AlgorithmIdentifier [RFC2986] in > > SubjectPublicKeyInfo, then following values MUST NOT be present: > > > > keyEncipherment; and > > dataEncipherment. > > > > If the keyUsage extension is present in a certificate that indicates > > id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following > > values also MUST NOT be present: > > > > keyEncipherment; and > > dataEncipherment. > > > > The structure of this section is peculiar, since it presents almost > > the same text about "id-ecPublicKey" and about "id-ecDH or id-ecMQV". > > If the intention is to say the same thing about all three, these > > should be folded together. > > There are two reasons I=E2=80=99d like to not merge these two bits of tex= t: > > 1. Agreed it is a bit odd, but it does mirror RFC 5480, which talks about > id-ecPublicKey for CA certificates and then EE certificates and then > id-ecDH/id-ecMQV. I guess we could collapse it, but for me then it=E2=80= =99s a > style thing and I=E2=80=99d rather mimic the RFC it=E2=80=99s updating. > > 2. With separate sentences we leave open the door for ECC encryption > algorithms like ECIES > < > https://itectec.com/spec/c-3-elliptic-curve-integrated-encryption-scheme-= ecies/ > > > > These algorithm need a lot of metadata (including EC point, KDF algorithm= , > hash algorithms, metadata of hash or KDF, etc=E2=80=A6), and we are not s= ure, but > believe, when specified they will not use id-ecPublicKey. > However, they may use SubjectPublicKeyInfo for their metadata. > > If we integrate two sentence together, a possible future ECIES draft will > conflict with our draft. > > > It is also not clear why the first paragraph refers to > > AlgorithmIdentifier but the second paragraph uses SubjectPublicKeyInfo > > to refer to essentially the same thing. > > I am pretty sure we did that to provide some context for where the OIDs > go, but you are right the first paragraph could just of easily been: > > If the keyUsage extension is present in a certificate that indicates > id-ecPublicKey in SubjectPublicKeyInfo, > > I will make that change. > > > But this text appears to contradict the statement in [RFC 5480] that > > the usage of id-ecPublicKey is "unrestricted" and is not a key > > agreement algorithm, in which case the first paragraph should say "the > > following values MAY be present". (In which case, the "also" in the > > 2nd paragraph should be omitted.) > > See above. > > Cheers, > > spt --00000000000031bd2c059f034c89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

let me fix a little.

>>These algorithm need a lot = of metadata (including EC point, KDF algorithm, hash algorithms, metadata o= f hash or KDF, etc=E2=80=A6),=C2=A0
>>and we ar= e not sure, but believe, when specified they will not use id-ecPublicKey.
>>However, they may use SubjectPublicKeyIn= fo for their metadata.

we are not sure, but believe when specifi= ed they will not use id-ecPublicKey as a algorithm,=C2=A0

but they may use id-ecPublicKey i= n the metadata field, =C2=A0along with ECIES algorithm identifier in the al= gorithm field.


Regards Tadahiko Ito

2020=E5=B9=B42= =E6=9C=8820=E6=97=A5(=E6=9C=A8) 15:49 Sean Turner <sean@sn3rd.com>:
Dale,

Hi! And, thanks for your review comments in-line.

spt

> On Feb 18, 2020, at 22:07, Dale Worley via Datatracker <noreply@ietf.org> wrote:<= br> >
> Reviewer: Dale Worley
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft.=C2=A0 The General A= rea
> Review Team (Gen-ART) reviews all IETF documents being processed by > the IESG for the IETF Chair.=C2=A0 Please treat these comments just li= ke
> any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq<= /a>>.
>
> Document:=C2=A0 draft-ietf-lamps-5480-ku-clarifications-00
> Reviewer:=C2=A0 Dale R. Worley
> Review Date:=C2=A0 2020-02-18
> IETF LC End Date:=C2=A0 2020-02-07
> IESG Telechat date:=C2=A0 [unknown]
>
> Summary:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This draft is on the right track but has ope= n issues, described
>=C2=A0 =C2=A0 =C2=A0 =C2=A0in the review.
>
> The text is difficult to follow in places.=C2=A0 I believe that the WG= has
> a clear understanding of what is intended, but a few small editorial > errors have unfortunately rendered the text incorrect and
> contradictory to RFC 5480.

Sometimes when you are too familiar with the context you assume too much so= a fresh set of eye can help!

> Note that I am unfamiliar with the details of PKI certificates; this > review is based largely on what I have learned from RFC 5480 and this<= br> > I-D.
>
>> From the discussion it appears that id-ecDH and id-ecMQV are "= ;key
> agreement algorithms" and that, as such, they should not be used = with
> keyEncipherment or dataEncipherment.=C2=A0 [this draft, section 3]
> Conversely, id-ecPublicKey is not a "key agreement algorithm"= ;.=C2=A0 [RFC
> 5480, section 2.1.2, para. 1, sentence 1]

Ah ... this might be where some of misunderstanding comes from because id-e= cPublicKey MAY be a key agreement algorithm that is why it is =E2=80=9Cunre= stricted=E2=80=9D. In other words, when key agreement certificates can incl= ude the following OIDs: id-ecDH (for an EC DH algorithm), id-ecMQV (for EC = MQV), or id-ecPublicKey (for any algorithm). Here=E2=80=99s the text from 5= 480 about id-ecPublicKey being used as key agreement algrithm:

If the keyUsage extension is present in an End Entity (EE)
certificate that indicates id-ecPublicKey in SubjectPublicKeyInfo,
then any combination of the following values MAY be present:

=C2=A0digitalSignature;
=C2=A0nonRepudiation; and
=C2=A0keyAgreement.

> 1.=C2=A0 Introduction
>
>=C2=A0 =C2=A0This document corrects this omission, by updating Section = 3 of
>=C2=A0 =C2=A0[RFC5480] to make it clear that neither keyEncipherment no= r the
>=C2=A0 =C2=A0dataEncipherment key usage bits are set for key agreement = algorithms.
>
> This could be clearer by replacing or augmenting "key agreement > algorithms" with a description of which of these algorithms are k= ey
> agreement algorithms, viz., id-ecDH and id-ecMQV.=C2=A0 Otherwise, one= must
> first have read RFC 5480 to understand this introduction correctly.
See above.

I also pondered how much to put in the intro to accommodate those readers t= hat are not as familiar with RFC 5480. I went the minimal route since this = is supposed to be just adding two sentences to RFC 5480. I sure hope people= that are not intimately familiar with RFC 5480 do immediately go read RFC = 5480 because this draft isn=E2=80=99t all that much use without doing so :)=

> 3.=C2=A0 Updates to Section 3
>
>=C2=A0 =C2=A0If the keyUsage extension is present in a certificate that= indicates
>=C2=A0 =C2=A0id-ecPublicKey as algorithm of AlgorithmIdentifier [RFC298= 6] in
>=C2=A0 =C2=A0SubjectPublicKeyInfo, then following values MUST NOT be pr= esent:
>
>=C2=A0 =C2=A0 =C2=A0keyEncipherment; and
>=C2=A0 =C2=A0 =C2=A0dataEncipherment.
>
>=C2=A0 =C2=A0If the keyUsage extension is present in a certificate that= indicates
>=C2=A0 =C2=A0id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the foll= owing
>=C2=A0 =C2=A0values also MUST NOT be present:
>
>=C2=A0 =C2=A0 =C2=A0keyEncipherment; and
>=C2=A0 =C2=A0 =C2=A0dataEncipherment.
>
> The structure of this section is peculiar, since it presents almost > the same text about "id-ecPublicKey" and about "id-ecDH= or id-ecMQV".
> If the intention is to say the same thing about all three, these
> should be folded together.

There are two reasons I=E2=80=99d like to not merge these two bits of text:=

1. Agreed it is a bit odd, but it does mirror RFC 5480, which talks about i= d-ecPublicKey for CA certificates and then EE certificates and then id-ecDH= /id-ecMQV. I guess we could collapse it, but for me then it=E2=80=99s a sty= le thing and I=E2=80=99d rather mimic the RFC it=E2=80=99s updating.

2. With separate sentences we leave open the door for ECC encryption algori= thms like ECIES
<https://itectec.c= om/spec/c-3-elliptic-curve-integrated-encryption-scheme-ecies/>

These algorithm need a lot of metadata (including EC point, KDF algorithm, = hash algorithms, metadata of hash or KDF, etc=E2=80=A6), and we are not sur= e, but believe, when specified they will not use id-ecPublicKey.
However, they may use SubjectPublicKeyInfo for their metadata.

If we integrate two sentence together, a possible future ECIES draft will c= onflict with our draft.

> It is also not clear why the first paragraph refers to
> AlgorithmIdentifier but the second paragraph uses SubjectPublicKeyInfo=
> to refer to essentially the same thing.

I am pretty sure we did that to provide some context for where the OIDs go,= but you are right the first paragraph could just of easily been:

=C2=A0If the keyUsage extension is present in a certificate that indicates<= br> =C2=A0id-ecPublicKey in SubjectPublicKeyInfo,

I will make that change.

> But this text appears to contradict the statement in [RFC 5480] that > the usage of id-ecPublicKey is "unrestricted" and is not a k= ey
> agreement algorithm, in which case the first paragraph should say &quo= t;the
> following values MAY be present".=C2=A0 (In which case, the "= ;also" in the
> 2nd paragraph should be omitted.)

See above.

Cheers,

spt
--00000000000031bd2c059f034c89-- From nobody Thu Feb 20 18:03:34 2020 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 9657E120219 for ; Thu, 20 Feb 2020 18:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.983 X-Spam-Level: X-Spam-Status: No, score=-0.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net 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 C3_vZj6Fpg-V for ; Thu, 20 Feb 2020 18:03:17 -0800 (PST) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (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 3969F1202DD for ; Thu, 20 Feb 2020 18:03:17 -0800 (PST) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-04v.sys.comcast.net with ESMTP id 4wywj6UcYsAwi4xeujXtpl; Fri, 21 Feb 2020 02:03:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1582250596; bh=cMCykhHMukf4bLzlHWbQwZT503B9mayya5UFVwZS2U8=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=igVBm/WmS0XLIHzx3GTrNRM9A/Ia7M92CfvLWKrirPhB24wuL6DCR9LDrqTIeU7Un TOaPtySepGNP5YbKemQqQ0coHZhL78IOq5xuU/J9BqcrqYxU5iz/0xQlL53TzjwfCm KTqEPqJzwgHrG5EyKQr2U7ggjZi8UkFRu22K8J3MCQ6sWtEokfZp8UbWakVbeuxbCD N0LZCZyOdh1azIX9aiDlBtnoA6XdA2tA9wlQGtXAKRrN++dY7h6lfK5VP1NXPApJLB 5jeyGcO5GLAEiaHo2Gj/zY3zKhLHBOwzRQcgCa5ff0+lttWYjEPEngz0okXakhrWFQ +aHApaWtCxu4Q== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4600:c190:222:fbff:fe91:d396]) by resomta-ch2-16v.sys.comcast.net with ESMTPA id 4xetjznxA7vgv4xetjmc98; Fri, 21 Feb 2020 02:03:16 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 01L23Egi002622; Thu, 20 Feb 2020 21:03:14 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 01L23DcA002619; Thu, 20 Feb 2020 21:03:13 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Sean Turner Cc: gen-art@ietf.org, draft-ietf-lamps-5480-ku-clarifications.all@ietf.org, last-call@ietf.org, spasm@ietf.org In-Reply-To: <9A18B0AA-084C-4B25-9B8B-0C166E7FA1D4@sn3rd.com> (sean@sn3rd.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 20 Feb 2020 21:03:13 -0500 Message-ID: <87zhdcg0im.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [lamps] Genart last call review of draft-ietf-lamps-5480-ku-clarifications-00 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: Fri, 21 Feb 2020 02:03:19 -0000 Sean Turner writes: >>> From the discussion it appears that id-ecDH and id-ecMQV are "key >> agreement algorithms" and that, as such, they should not be used with >> keyEncipherment or dataEncipherment. [this draft, section 3] >> Conversely, id-ecPublicKey is not a "key agreement algorithm". [RFC >> 5480, section 2.1.2, para. 1, sentence 1] > > Ah ... this might be where some of misunderstanding comes from because > id-ecPublicKey MAY be a key agreement algorithm that is why it is > "unrestricted". In other words, when key agreement certificates can I assume that "when" in the above line should be omitted. > include the following OIDs: id-ecDH (for an EC DH algorithm), id-ecMQV > (for EC MQV), or id-ecPublicKey (for any algorithm). Here's the text > from 5480 about id-ecPublicKey being used as key agreement algrithm: > > If the keyUsage extension is present in an End Entity (EE) > certificate that indicates id-ecPublicKey in SubjectPublicKeyInfo, > then any combination of the following values MAY be present: > > digitalSignature; > nonRepudiation; and > keyAgreement. I'm still finding this an uphill climb. If I understand you correctly, "key agreement" is not an attribute of an algorithm per se, but rather an attribute of a certificate. And thus id-ecPublicKey may be specified in a key agreement certificate (that is, one with keyAgreement), but can also be specified in non-key agreement certificates (that is, ones without keyAgrement). But id-ecDH and id-ecMQV may only be used in key agreement certificates, and in that sense they can be considered "key agreement algorithms". Is that correct? Dale From nobody Tue Feb 25 13:04:15 2020 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 0FCBD3A15BF; Tue, 25 Feb 2020 13:04:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-lamps-5480-ku-clarifications@ietf.org, lamps-chairs@ietf.org, spasm@ietf.org, Russ Housley , housley@vigilsec.com X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <158266464705.11162.11554831216624396111.idtracker@ietfa.amsl.com> Date: Tue, 25 Feb 2020 13:04:07 -0800 Archived-At: Subject: [lamps] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-lamps-5480-ku-clarifications-00=3A_=28with_COMMENT=29?= 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, 25 Feb 2020 21:04:07 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-lamps-5480-ku-clarifications-00: 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-5480-ku-clarifications/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Ultra short document :-) Anyway, a minor comment: what is the location of the text updating the section 3 of RFC 5480? Should it go at the end of the existing section 3 (my guess)? Or at the beginning ? or somewhere in the middle ? Should it replace completely or partially the existing section 3? -éric PS: I know that my comment is mostly larger than the update itself ;-) From nobody Tue Feb 25 13:16:28 2020 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 0865C3A15FC for ; Tue, 25 Feb 2020 13:16:21 -0800 (PST) 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, 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 QlkoVpyywj_Q for ; Tue, 25 Feb 2020 13:16:19 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96ABB3A15FA for ; Tue, 25 Feb 2020 13:16:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 67AB4300B84 for ; Tue, 25 Feb 2020 16:08:29 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VLo0ARk5MvF0 for ; Tue, 25 Feb 2020 16:08:27 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 100D6300B7F; Tue, 25 Feb 2020 16:08:26 -0500 (EST) 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: <158266464705.11162.11554831216624396111.idtracker@ietfa.amsl.com> Date: Tue, 25 Feb 2020 16:08:28 -0500 Cc: IESG , draft-ietf-lamps-5480-ku-clarifications@ietf.org, lamps-chairs@ietf.org, spasm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2A47D0FC-A57A-48B7-B642-C3305C3B9270@vigilsec.com> References: <158266464705.11162.11554831216624396111.idtracker@ietfa.amsl.com> To: Eric Vyncke X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-lamps-5480-ku-clarifications-00=3A_=28with_COMMENT=29?= 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, 25 Feb 2020 21:16:21 -0000 Eric: You are correct, the text should be added to the end of Section 3. Russ > On Feb 25, 2020, at 4:04 PM, =C3=89ric Vyncke via Datatracker = wrote: >=20 > =C3=89ric Vyncke has entered the following ballot position for > draft-ietf-lamps-5480-ku-clarifications-00: 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-5480-ku-clarifications/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Ultra short document :-) >=20 > Anyway, a minor comment: what is the location of the text updating the = section > 3 of RFC 5480? Should it go at the end of the existing section 3 (my = guess)? Or > at the beginning ? or somewhere in the middle ? Should it replace = completely or > partially the existing section 3? >=20 > -=C3=A9ric >=20 > PS: I know that my comment is mostly larger than the update itself ;-) >=20 >=20 >=20 From nobody Tue Feb 25 14:56:26 2020 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 59E4F3A0794; Tue, 25 Feb 2020 14:56:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-lamps-5480-ku-clarifications@ietf.org, lamps-chairs@ietf.org, spasm@ietf.org, Russ Housley , housley@vigilsec.com X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <158267138036.11010.7143212937692090838.idtracker@ietfa.amsl.com> Date: Tue, 25 Feb 2020 14:56:20 -0800 Archived-At: Subject: [lamps] Barry Leiba's No Objection on draft-ietf-lamps-5480-ku-clarifications-00: (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, 25 Feb 2020 22:56:21 -0000 Barry Leiba has entered the following ballot position for draft-ietf-lamps-5480-ku-clarifications-00: 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-5480-ku-clarifications/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for a nice, super-short and to-the-point document. I hate to pick on anything here, but: then the following values also MUST NOT be present: Do you mean "MUST NOT also be present"? The "also" seems misplaced where it is, and it made me wonder if I misunderstood. An alternative fix would be to simply remove "also". From nobody Tue Feb 25 17:57:54 2020 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 F19663A08C9; Tue, 25 Feb 2020 17:57:51 -0800 (PST) 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.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <158268227186.11060.4098120784139485495@ietfa.amsl.com> Date: Tue, 25 Feb 2020 17:57:51 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-5480-ku-clarifications-01.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, 26 Feb 2020 01:57:52 -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 : Clarifications for Elliptic Curve Cryptogtaphy Subject Public Key Information Authors : Tadahiko Ito Sean Turner Filename : draft-ietf-lamps-5480-ku-clarifications-01.txt Pages : 3 Date : 2020-02-25 Abstract: This document updates RFC 5480 to specify semantics for the keyEncipherment and dataEncipherment key usage bits when used in certificates that support Elliptic Curve Cryptography. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-5480-ku-clarifications-01 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-5480-ku-clarifications-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-5480-ku-clarifications-01 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 Feb 25 17:59:47 2020 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 2567E3A08D1 for ; Tue, 25 Feb 2020 17:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.585 X-Spam-Level: X-Spam-Status: No, score=-0.585 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_RHS_DOB=1.514] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 n9cCDKaPbmZ5 for ; Tue, 25 Feb 2020 17:59:44 -0800 (PST) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 8E3353A08CF for ; Tue, 25 Feb 2020 17:59:44 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id b7so1195356qkl.7 for ; Tue, 25 Feb 2020 17:59:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=huY2LHjunWeArLFFCdMF3U2EWnaJnsAWPeug5b0cdJY=; b=NqO/kGQmlEDbHLInIB4sgrgLkcCs6raX54a+nFUdGit3JXeycr1Jxd665BMmsOQySi dph4D+bghs+m+YdlksdvO9X2ir955eHhYlDiteTGRNcXLuXmwUyQK+6DQmHzLUITzPDY P/TbtzUP+p1KMaq9hZ6zrk7jjH8bvgEni2v4E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=huY2LHjunWeArLFFCdMF3U2EWnaJnsAWPeug5b0cdJY=; b=D/X9/IeJITFR+jUgrCZRxU0GhqDp+emBbUhlPKYRUuorr7BCc0M4yvT1Mb9DlllHtw W2Hd08ulppd/bmar2p8auh1GUlCPU+ElssKdpVDNv8gifLh2ieoi2b7D9hIddlLRIYnI /Yx14m6Pm69sHz4qEqA76D1grVjw1cmJTiJHNQM2A8BvHoONKTXcaMndBr3qK4NKqFGE nKCllXqfGoEU/OzGaY+/90PpbwoPJ+U0CgfxQn1YEa/Ayh88Q8pWmRBRX/T6sWZAiq1C KQnwhofBRqWiJUZYrzFsB7F7GdjD9ATZ4cdYKgYCXkk5BupeF+BiglT0iImW7FnxjRqV GKsg== X-Gm-Message-State: APjAAAVDQIxE/P5kUoR9r7YVX3DKJBkJh+CRxolqE12NTl/v2jn/R4r6 bZ/Cd+CaB/8zp12KKSTsikPPiI0KsOc= X-Google-Smtp-Source: APXvYqzwUrzHC5Yk9wnQo7IozItpnR6CO/2K5BIvGAKYLJN1grZdqMLC6n9h44Pb6L8YaRCBGyGcAQ== X-Received: by 2002:a37:f502:: with SMTP id l2mr2164798qkk.76.1582682383181; Tue, 25 Feb 2020 17:59:43 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id s13sm274541qke.67.2020.02.25.17.59.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Feb 2020 17:59:42 -0800 (PST) From: Sean Turner 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: Tue, 25 Feb 2020 20:59:41 -0500 References: <158268227186.11060.4098120784139485495@ietfa.amsl.com> To: LAMPS WG In-Reply-To: <158268227186.11060.4098120784139485495@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-5480-ku-clarifications-01.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, 26 Feb 2020 01:59:46 -0000 This version incorporates changes to address the GENART review. spt > On Feb 25, 2020, at 20:57, 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 : Clarifications for Elliptic Curve = Cryptogtaphy Subject Public Key Information > Authors : Tadahiko Ito > Sean Turner > Filename : draft-ietf-lamps-5480-ku-clarifications-01.txt > Pages : 3 > Date : 2020-02-25 >=20 > Abstract: > This document updates RFC 5480 to specify semantics for the > keyEncipherment and dataEncipherment key usage bits when used in > certificates that support Elliptic Curve Cryptography. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lamps-5480-ku-clarifications-01 > = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-5480-ku-clarificati= ons-01 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-5480-ku-clarification= s-01 >=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/ >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Tue Feb 25 18:01:21 2020 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 6782B3A08DC for ; Tue, 25 Feb 2020 18:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.585 X-Spam-Level: X-Spam-Status: No, score=-0.585 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_RHS_DOB=1.514] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 QvHIqB2mZrHY for ; Tue, 25 Feb 2020 18:01:14 -0800 (PST) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 C8B763A08DD for ; Tue, 25 Feb 2020 18:01:14 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id b5so1190420qkh.8 for ; Tue, 25 Feb 2020 18:01:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rD1c6TgmXQHnWBS180TILOytMW1+Prv0Zf7Ya9spKVs=; b=STdH6bb0+o4vXuMD4PdGn1aFIMO2yNRma5OFwbS5yQFhicaqpKzCu/+ZaWynHoKD27 irV5OHt89eDEV+++UZv3qHPv13bdF5sYo2Ur3gKjwjBnyrniwTIdGM2sVoTx05GiA2WW rhn26y4we5LCrqK9e3TQxR5SRjPUCGeyXUd7I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rD1c6TgmXQHnWBS180TILOytMW1+Prv0Zf7Ya9spKVs=; b=gvqQtmBQz/JcivgtEkTcUx3JYnqGnbHdvRA8TIy9PiI17VZ/8OK71XMwGJpjhZ4kKY G9987jC3eu1SnAmf9I3H/nCMM+erPUbKKld9HRKuqShPX0w9X6sHaMh4xEfqsNbXCcPg QOURynB+aP+TVf+CSfry0PsboZSOpk9GEwI+4asIyHL6LqJiZ3OZH2lRpvNpz4tcPzF8 XNSj/2PB7Eoxni+UrB/922U17h0pKs9X9gt+raRPbpDgbotUIF6yGPL6klrdJnbQ6FBF fCGrldRazC8cOIpLk837be7S6TDQRCiJMSi1VeWrdVzHbH33zg8o+ofxXt3ZxXn+hOp2 k05w== X-Gm-Message-State: APjAAAUSHH6my4INWxH6A5lYLF9QJpwM48L7U0YlgLIpt5o+BwRk3GgM iA/0ozDQVvwjv+CTnXlR+O6boA== X-Google-Smtp-Source: APXvYqxh9cmg23ggGnTOwPUha47PXbRzrTvkJ86jCwQYM74Qh5Qn5WpQ/vxriC54eq8m7YXHZwfNVw== X-Received: by 2002:a37:4b4b:: with SMTP id y72mr2203284qka.175.1582682473813; Tue, 25 Feb 2020 18:01:13 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id 145sm309253qkh.10.2020.02.25.18.01.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Feb 2020 18:01:13 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: <87zhdcg0im.fsf@hobgoblin.ariadne.com> Date: Tue, 25 Feb 2020 21:01:12 -0500 Cc: gen-art@ietf.org, draft-ietf-lamps-5480-ku-clarifications.all@ietf.org, last-call@ietf.org, spasm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6888D55C-5A3D-4C8E-AF6C-ED96235A1691@sn3rd.com> References: <87zhdcg0im.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Genart last call review of draft-ietf-lamps-5480-ku-clarifications-00 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, 26 Feb 2020 02:01:17 -0000 > On Feb 20, 2020, at 21:03, Dale R. Worley wrote: >=20 > Sean Turner writes: >>>> =46rom the discussion it appears that id-ecDH and id-ecMQV are "key >>> agreement algorithms" and that, as such, they should not be used = with >>> keyEncipherment or dataEncipherment. [this draft, section 3] >>> Conversely, id-ecPublicKey is not a "key agreement algorithm". [RFC >>> 5480, section 2.1.2, para. 1, sentence 1] >>=20 >> Ah ... this might be where some of misunderstanding comes from = because >> id-ecPublicKey MAY be a key agreement algorithm that is why it is >> "unrestricted". In other words, when key agreement certificates can > I assume that "when" in the above line should be omitted. >> include the following OIDs: id-ecDH (for an EC DH algorithm), = id-ecMQV >> (for EC MQV), or id-ecPublicKey (for any algorithm). Here's the text >> from 5480 about id-ecPublicKey being used as key agreement algrithm: >>=20 >> If the keyUsage extension is present in an End Entity (EE) >> certificate that indicates id-ecPublicKey in SubjectPublicKeyInfo, >> then any combination of the following values MAY be present: >>=20 >> digitalSignature; >> nonRepudiation; and >> keyAgreement. >=20 > I'm still finding this an uphill climb. If I understand you = correctly, > "key agreement" is not an attribute of an algorithm per se, but rather > an attribute of a certificate. And thus id-ecPublicKey may be = specified > in a key agreement certificate (that is, one with keyAgreement), but = can > also be specified in non-key agreement certificates (that is, ones > without keyAgrement). But id-ecDH and id-ecMQV may only be used in = key > agreement certificates, and in that sense they can be considered "key > agreement algorithms". Is that correct? >=20 > Dale Yes. BTW - I spun a new version to make the changes I noted early (at the = request of Roman) spt= From nobody Tue Feb 25 18:10:55 2020 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 38D793A0931 for ; Tue, 25 Feb 2020 18:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.585 X-Spam-Level: X-Spam-Status: No, score=-0.585 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_RHS_DOB=1.514] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 MdN4JVNPAWZP for ; Tue, 25 Feb 2020 18:10:52 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 BBFE03A093C for ; Tue, 25 Feb 2020 18:10:52 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id 145so1247193qkl.2 for ; Tue, 25 Feb 2020 18:10:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=K1joOEj/f+Lz2l1ufErbn2rYkOp2bAWXy2c/05n3sEM=; b=FwSNqSp5+ruXtleYqnXvBMAfoEnz5O2Sbv07B4YruSPigYCnLDPQ5nsr5+3HpFyIJC +YrT9e0OAR1JQ27l8VKD83Ag6lm9z8C6mZrqd4tppB4pp31/XNruhOGZTV9lT04XzmtG 8k22IDMjHnAL+fMbqy0jKOgA52O2eklK7ZoDk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=K1joOEj/f+Lz2l1ufErbn2rYkOp2bAWXy2c/05n3sEM=; b=iXq+QtmYtEo8hRtaklB8C8mzgmzWT//3xFFy7w4AMUtdI+Y17Yh9w+UIgjzUbZmqYk Qg7mZ6xDsGS6jfZ0Rm4tUkeAZTTuhbOEa3TQhFLufcE1CC0Rhn6W/0downR2oHURELt4 SuQkVFcq0q6me4H6A3FdvRNGfQTDzfBSdgyC2yLfqvWFxc9KJKfgGUFe7W7NhRo1JxV5 aHG5gdNDvoGDIksAaQZzNXVXoL6bYNvYs/TcBHLUx6kPKxd4HcVirJR1zcv4njnLu6xc yTEBJI55No9Z5iswrXL4QfUPibkn3BqbdjqX7gjJP4LS7qUx0l6YmI+yDVqN6jOToNiB rLZg== X-Gm-Message-State: APjAAAXyS9TdmBUJgqt/gHOUN9N82PqZzOSnEyhqX+JSkS5QPt5Qt3SL fj6EthmqDTIeiw5K7KDpUxMYgg== X-Google-Smtp-Source: APXvYqzFwwR5bqbVBj4htOEh11bfC6UE0Xy5+8SzI2Gl8chez/9co62In2+wgDi7gxitw8Q++jzv9Q== X-Received: by 2002:a37:9c01:: with SMTP id f1mr2600350qke.194.1582683051897; Tue, 25 Feb 2020 18:10:51 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id 12sm274555qkj.136.2020.02.25.18.10.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Feb 2020 18:10:51 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: <158267138036.11010.7143212937692090838.idtracker@ietfa.amsl.com> Date: Tue, 25 Feb 2020 21:10:49 -0500 Cc: The IESG , draft-ietf-lamps-5480-ku-clarifications@ietf.org, lamps-chairs@ietf.org, spasm@ietf.org, Russ Housley Content-Transfer-Encoding: quoted-printable Message-Id: <756FF88A-DE98-42A9-ADC0-F24E155A8CA6@sn3rd.com> References: <158267138036.11010.7143212937692090838.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-5480-ku-clarifications-00: (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, 26 Feb 2020 02:10:54 -0000 > On Feb 25, 2020, at 17:56, Barry Leiba via Datatracker = wrote: >=20 > Barry Leiba has entered the following ballot position for > draft-ietf-lamps-5480-ku-clarifications-00: 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-5480-ku-clarifications/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for a nice, super-short and to-the-point document. I hate to = pick on > anything here, but: >=20 > then the following > values also MUST NOT be present: >=20 > Do you mean "MUST NOT also be present"? The "also" seems misplaced = where it > is, and it made me wonder if I misunderstood. An alternative fix = would be to > simply remove "also=E2=80=9D. In my mind it was an =E2=80=9Calso=E2=80=9D because the text is = basically saying in addition to the list already in RFC 5480 (text = below) do not also set these two bits. If the keyUsage extension is present in a certificate that indicates id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following values MUST NOT be present: digitalSignature; nonRepudiation; keyTransport; keyCertSign; and cRLSign. With that said, I would be happy to remove it or move it - You tell me = which you=E2=80=99d prefer ;) spt From nobody Tue Feb 25 18:13:07 2020 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 5BB1A3A0951 for ; Tue, 25 Feb 2020 18:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.585 X-Spam-Level: X-Spam-Status: No, score=-0.585 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_RHS_DOB=1.514] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 g-KRTY1ZJPr2 for ; Tue, 25 Feb 2020 18:13:05 -0800 (PST) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 E6D4F3A094D for ; Tue, 25 Feb 2020 18:13:04 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id o28so1209042qkj.9 for ; Tue, 25 Feb 2020 18:13:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6Ujwj0xLSIgThXdvW/cvez04XUwkb7/WvyvW8XIvNBw=; b=fzmzjxauxDcKjbsRlG3AzB00NxihQsFNf+c7MkuPGXbaCu7kmih746QBRpQv0/UpJ9 0IRaCYP/sRZqzfe24u6IusrHzN72ajEAY+Vh2kFR7CjoKlhVO3pYmXaZx19fKKxISN6O vm4SXmRzYn92QclJgaWt8YvUDWaGspRfrW8pg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6Ujwj0xLSIgThXdvW/cvez04XUwkb7/WvyvW8XIvNBw=; b=jVPNcsy9EeSHG835R2n8NJaFy66oZM4ulREBuCzox07KD7oH448gKyeMEHjRtcO1KQ 61F4JSi20GRkHnSJ5UmRwBiIkM0LCtSQyQzk4SN+mHuslxnH9E6vgM1FZPyBp43rTLoH eYQjKrZDBwWwJzXK7trSlxQD38mT+XIpU4nA0uz9g6SX/ePlFHM+xSX7mihz7d2EMQH/ 0zBRj5FwekFyZRWLx5U/eAh5LQYhKMZO4ejC1T6jbWQNKBCKhrmGiqzYuJc+nGm5fSm9 I9cZ/LH+K6kZoYgV5PwTyLFw6E0SHPycUvGlWTMdVpBCovPhVPNqDrbGqFUNWAwQ4j7T gsJw== X-Gm-Message-State: APjAAAXNOmWfNex742LSaCHo+WyrUl7jlCgg/6vCmrijEn1ASO73GWNi PNvRIqg/MIggqk2gqzJTcIES3Q== X-Google-Smtp-Source: APXvYqzVkd2AtVaI3nNkjl+QXfkipwAQ+JZjRAGfgANM4makHVjARUAat9KAB2rIjwmmjb1rbasOtQ== X-Received: by 2002:a37:9284:: with SMTP id u126mr2401950qkd.470.1582683184117; Tue, 25 Feb 2020 18:13:04 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id p50sm320740qtf.5.2020.02.25.18.13.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Feb 2020 18:13:03 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: <2A47D0FC-A57A-48B7-B642-C3305C3B9270@vigilsec.com> Date: Tue, 25 Feb 2020 21:13:02 -0500 Cc: Eric Vyncke , IESG , draft-ietf-lamps-5480-ku-clarifications@ietf.org, lamps-chairs@ietf.org, spasm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <19971B81-9F49-4CB4-BEF1-103CAC920279@sn3rd.com> References: <158266464705.11162.11554831216624396111.idtracker@ietfa.amsl.com> <2A47D0FC-A57A-48B7-B642-C3305C3B9270@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-lamps-5480-ku-clarifications-00=3A_=28with_COMMENT=29?= 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, 26 Feb 2020 02:13:06 -0000 I could add something like the following at the end of s1: The additions are to be made to the end of Section 3. spt PS - As requested by Roman, I spun a new version to address the GENART = comments. > On Feb 25, 2020, at 16:08, Russ Housley wrote: >=20 > Eric: >=20 > You are correct, the text should be added to the end of Section 3. >=20 > Russ >=20 >=20 >> On Feb 25, 2020, at 4:04 PM, =C3=89ric Vyncke via Datatracker = wrote: >>=20 >> =C3=89ric Vyncke has entered the following ballot position for >> draft-ietf-lamps-5480-ku-clarifications-00: 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-5480-ku-clarifications/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Ultra short document :-) >>=20 >> Anyway, a minor comment: what is the location of the text updating = the section >> 3 of RFC 5480? Should it go at the end of the existing section 3 (my = guess)? Or >> at the beginning ? or somewhere in the middle ? Should it replace = completely or >> partially the existing section 3? >>=20 >> -=C3=A9ric >>=20 >> PS: I know that my comment is mostly larger than the update itself = ;-) >>=20 >>=20 >>=20 >=20 From nobody Tue Feb 25 21:52:15 2020 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 60AF93A0DF7; Tue, 25 Feb 2020 21:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.086 X-Spam-Level: X-Spam-Status: No, score=-8.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_RHS_DOB=1.514, 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=dILdgeYS; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Zt8GRS5/ 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 GmJH1GrtV9Cn; Tue, 25 Feb 2020 21:51:27 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92C003A0DF9; Tue, 25 Feb 2020 21:51:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3446; q=dns/txt; s=iport; t=1582696286; x=1583905886; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+pdVyBbc7feihvVqx2Libpu/PqJWA1RBBVfywq7QYbU=; b=dILdgeYSGx2c2eOfbWWDBxJvxktNV04pkEJh2OVlVIt5eGhUTWRsoB8H oh+BH2jJ1ddBJBp1K0kG2pmu51xdLUDfavm/N9sOZffXU0Tkxy3KuqtFn ycw7nxTNkv7QYqL+dHek4HU7PXojLzvz0zQ1j7SQ8q68IBtfsleWuJOYR s=; IronPort-PHdr: =?us-ascii?q?9a23=3AKthopRTAdBoUUR1eSzqglmIondpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBdfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOiEkDcJJV1JN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAAAiB1Ze/4oNJK1lGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYFqAgEBAQELAYFTUAVsWCAECyqEFINGA4pygjo?= =?us-ascii?q?lmBSBQoEQA1QJAQEBDAEBJQgCBAEBhEACF4FoJDcGDgIDDQEBBQEBAQIBBQR?= =?us-ascii?q?thTcMhWMBAQEBAgESEREMAQE3AQsEAgEIEQMBAgECAiYCAgIwFQUDCAIEAQ0?= =?us-ascii?q?FIoMEAYJKAw4gAQ6jGwKBOYhidYEygn8BAQWBQ0GDChiCDAMGgQ4qAYwjGoF?= =?us-ascii?q?BP4ERJwwUgkw+gmQCAQIBgSwBEgEhgxEygiyHVoYagnWfNQqCPIdRimKEMhy?= =?us-ascii?q?CSYgbkEqDTIskgU2HL5JLAgQCBAUCDgEBBYFoI2dYEQhwFWUBgkFQGA2OHTi?= =?us-ascii?q?DO4UUhUF0AoEnkDYBAQ?= X-IronPort-AV: E=Sophos;i="5.70,486,1574121600"; d="scan'208";a="450954487" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Feb 2020 05:51:25 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 01Q5pOBh012117 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Feb 2020 05:51:24 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 25 Feb 2020 23:51:23 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 25 Feb 2020 23:51:23 -0600 Received: from NAM10-MW2-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; Tue, 25 Feb 2020 23:51:22 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nOfjF/i2nbi4b1laib6do+6d9fzWjxibb5j81GhQN5LG2hZ4+6XFKLEePmCJBhYGC8Ugt9t5yqHXl5GmNGgaNhkTOpqZ8yu3E45KBVBCYIi4kZxpzTGLQnegUsCz1kC+7xR2xvFXVJWXpJSZgyMogl0DtDdmTazLMOhaV/vbLFLUsCiLA8IHTU+9FiUJh5zjHzkXWXUz+/kYFdIAO7AtNv9zLzOR+chgkc+O5aoD0Ok60JUMwzXs3CZpNgeO5fiZI2Zp5ml+8zItcd2djT6jBGtohwFQetXHde0CMJ27rY0/dMJYP3GUqPKPUz8mlVRSmgsjOuGo2Og+hJ4lIBnQVw== 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=+pdVyBbc7feihvVqx2Libpu/PqJWA1RBBVfywq7QYbU=; b=SyGTG57kGu2v7EuEebz25Pq0YiE9bN8+JG9O4toz080rbWbkJKzyFl3vTWQmoPwKAaqaQ3fC1ieHvBTxDRr9erUd2tVbXdUgx4UEMZfHEeCTDQx83QZOfc8HmhylDZMi3qC1dzP4Zd7++DTPkl3RIJQY2P+Oruo3xqKP/BrDAHNI3ORpqivIIwh+dsUyXAYz7TKWVX4wPxoFgZqy7FodnwlU48Y0fc2qMiB5V8KdzJuYVh/ZVMXwZtt5MtpK1da8z0+HJ6auZPQTynHNJopIFrQWQqROmRTQgjgQWUFxbUMX53e5uncmNt3tkkn9IpmLwzGFy9vAYjy807ac2LYg3g== 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=+pdVyBbc7feihvVqx2Libpu/PqJWA1RBBVfywq7QYbU=; b=Zt8GRS5/KO6htux9tHBl7wtQWaSAXVtvc1F2HCpb7Jr7P59/vo/8EYQ/EPDBLg5uAhikIqYNgYR+qpHV+NEd4x8AvvL+Td97es7d9cy/dmK9A+Fo7wmzAkJ1F0TYKG3UwPAN2gW2aVA+I52AwkZPIUtxMt/kc6R5hA3CfoitrAs= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (2603:10b6:3:10d::13) by DM5PR11MB1436.namprd11.prod.outlook.com (2603:10b6:4:8::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.22; Wed, 26 Feb 2020 05:51:22 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::680d:e22e:72d5:67ca]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::680d:e22e:72d5:67ca%3]) with mapi id 15.20.2772.012; Wed, 26 Feb 2020 05:51:21 +0000 From: "Eric Vyncke (evyncke)" To: Sean Turner , Russ Housley CC: IESG , "draft-ietf-lamps-5480-ku-clarifications@ietf.org" , "lamps-chairs@ietf.org" , "spasm@ietf.org" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtbGFt?= =?utf-8?Q?ps-5480-ku-clarifications-00:_(with_COMMENT)?= Thread-Index: AQHV7EpKao3gqtG7IkaIMuC+S1AZPagtCbmA Date: Wed, 26 Feb 2020 05:51:21 +0000 Message-ID: <8049C43E-F18C-4298-AF24-4AC040AEBDE0@cisco.com> References: <158266464705.11162.11554831216624396111.idtracker@ietfa.amsl.com> <2A47D0FC-A57A-48B7-B642-C3305C3B9270@vigilsec.com> <19971B81-9F49-4CB4-BEF1-103CAC920279@sn3rd.com> In-Reply-To: <19971B81-9F49-4CB4-BEF1-103CAC920279@sn3rd.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:8c98:5ceb:1ac6:951b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 47a6b766-ac2d-47ba-5175-08d7ba7fe873 x-ms-traffictypediagnostic: DM5PR11MB1436: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0325F6C77B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(366004)(39860400002)(136003)(376002)(189003)(199004)(33656002)(4326008)(81166006)(316002)(8936002)(224303003)(6512007)(54906003)(81156014)(6486002)(110136005)(2906002)(71200400001)(186003)(66446008)(91956017)(36756003)(5660300002)(6506007)(86362001)(2616005)(53546011)(76116006)(66946007)(64756008)(478600001)(966005)(66476007)(66556008); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1436; H:DM5PR11MB1753.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: BCL:0; x-microsoft-antispam-message-info: VSjuq57yQzyAvayu+pdquP89LR+KOAZWq7aS7OQrdcDJMJ653Hb6f8bjXYm2twwUbC0HPgM/UCFEjFwmltxY6H2D0LPlVn/TZszy4GpP/3JOfr3s65ChbqNEjWnv719nkooX1otM12Jd88zgDuSrVki3i5J+/IiRqGVCvmsBVAfX94Qm2kYDZI9GbBh3V+1/SqoxJiMnfGa8XBX7P117oNGRkj6OcoWCZlg0IpPJFE1L9EKgVqSniuX4osWdkv30wt97Zy6NCzBQOFUfz5xdmoFod7J8wYtL+BRu0o0OkA7NaimYZ3vfa8EMya5lqDD7klKLd+GjcDrXRk0AKG0ulsZgBEAcFOCj+PvDYe+9j3VkAkJPkZE6h6RRia+wH9+m0YNANNRhxRGQUNAQRX6AmRaMWBWYEH9iafAA2txDNOcW55o5mcRUpiNsUJdO/u9qygkeZp1VTQ/26ocEvRClOJnSWMRLQ9WLrs3azu/uByHKQZmKHuuCYZRlLOqL1BPUBkEaxp4JqarhaX/TDb+q5g== x-ms-exchange-antispam-messagedata: u5NNWdzd62WFm4LI+4aa+yizQcOAvZyWl1ZEXS3GSWnXBLtQYwXLdaFeGNC4nkH5ZHSk5lPLZ9EAz9E5Ghjyj2HBA1FEns0u+2q1ypSU/YDz4uv53vkmhgY5ESA1kf4aR5eA4e9SUNB432VftsX6RM2nxOCAS2jBsPtiQF71TWknXLCTKDI+wbESoKFfP09kPUczzRjstk7fKfSqFQhNKw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <87A33AB2B6C4964F8EF4C6F027D14D03@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 47a6b766-ac2d-47ba-5175-08d7ba7fe873 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2020 05:51:21.8209 (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: /iKgDfuI03tq1k9aW4MPcpSjxzWmMEicXAMo93i8kv0hohtMYe8m82mW4N5aWDva+gxjQF3bphsZiGgT1AlQ8A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1436 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [lamps] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-lamps-5480-ku-clarifications-00=3A_=28with_COMMENT=29?= 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, 26 Feb 2020 05:51:30 -0000 VGhpcyB3b3VsZCBiZSB0aGUgY2hlcnJ5IG9uIHRoZSBjYWtlIDstKQ0KDQrvu78tLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU2VhbiBUdXJuZXIgPHNlYW5Ac24zcmQuY29tPg0KRGF0 ZTogV2VkbmVzZGF5LCAyNiBGZWJydWFyeSAyMDIwIGF0IDAzOjEzDQpUbzogUnVzcyBIb3VzbGV5 IDxob3VzbGV5QHZpZ2lsc2VjLmNvbT4NCkNjOiBFcmljIFZ5bmNrZSA8ZXZ5bmNrZUBjaXNjby5j b20+LCBJRVNHIDxpZXNnQGlldGYub3JnPiwgImRyYWZ0LWlldGYtbGFtcHMtNTQ4MC1rdS1jbGFy aWZpY2F0aW9uc0BpZXRmLm9yZyIgPGRyYWZ0LWlldGYtbGFtcHMtNTQ4MC1rdS1jbGFyaWZpY2F0 aW9uc0BpZXRmLm9yZz4sICJsYW1wcy1jaGFpcnNAaWV0Zi5vcmciIDxsYW1wcy1jaGFpcnNAaWV0 Zi5vcmc+LCAic3Bhc21AaWV0Zi5vcmciIDxzcGFzbUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiDD iXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1sYW1wcy01NDgwLWt1LWNs YXJpZmljYXRpb25zLTAwOiAod2l0aCBDT01NRU5UKQ0KDQogICAgSSBjb3VsZCBhZGQgc29tZXRo aW5nIGxpa2UgdGhlIGZvbGxvd2luZyBhdCB0aGUgZW5kIG9mIHMxOg0KICAgIA0KICAgICAgVGhl IGFkZGl0aW9ucyBhcmUgdG8gYmUgbWFkZSB0byB0aGUgZW5kIG9mIFNlY3Rpb24gMy4NCiAgICAN CiAgICBzcHQNCiAgICANCiAgICBQUyAtIEFzIHJlcXVlc3RlZCBieSBSb21hbiwgSSBzcHVuIGEg bmV3IHZlcnNpb24gdG8gYWRkcmVzcyB0aGUgR0VOQVJUIGNvbW1lbnRzLg0KICAgIA0KICAgID4g T24gRmViIDI1LCAyMDIwLCBhdCAxNjowOCwgUnVzcyBIb3VzbGV5IDxob3VzbGV5QHZpZ2lsc2Vj LmNvbT4gd3JvdGU6DQogICAgPiANCiAgICA+IEVyaWM6DQogICAgPiANCiAgICA+IFlvdSBhcmUg Y29ycmVjdCwgdGhlIHRleHQgc2hvdWxkIGJlIGFkZGVkIHRvIHRoZSBlbmQgb2YgU2VjdGlvbiAz Lg0KICAgID4gDQogICAgPiBSdXNzDQogICAgPiANCiAgICA+IA0KICAgID4+IE9uIEZlYiAyNSwg MjAyMCwgYXQgNDowNCBQTSwgw4lyaWMgVnluY2tlIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBp ZXRmLm9yZz4gd3JvdGU6DQogICAgPj4gDQogICAgPj4gw4lyaWMgVnluY2tlIGhhcyBlbnRlcmVk IHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KICAgID4+IGRyYWZ0LWlldGYtbGFt cHMtNTQ4MC1rdS1jbGFyaWZpY2F0aW9ucy0wMDogTm8gT2JqZWN0aW9uDQogICAgPj4gDQogICAg Pj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBh bmQgcmVwbHkgdG8gYWxsDQogICAgPj4gZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBU byBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCiAgICA+PiBpbnRyb2R1Y3Rv cnkgcGFyYWdyYXBoLCBob3dldmVyLikNCiAgICA+PiANCiAgICA+PiANCiAgICA+PiBQbGVhc2Ug cmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0 ZXJpYS5odG1sDQogICAgPj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNT IGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCiAgICA+PiANCiAgICA+PiANCiAgICA+PiBUaGUgZG9j dW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhl cmU6DQogICAgPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1s YW1wcy01NDgwLWt1LWNsYXJpZmljYXRpb25zLw0KICAgID4+IA0KICAgID4+IA0KICAgID4+IA0K ICAgID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICA+PiBDT01NRU5UOg0KICAgID4+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCiAgICA+PiANCiAgICA+PiBVbHRyYSBzaG9ydCBkb2N1bWVudCA6LSkNCiAgICA+PiANCiAg ICA+PiBBbnl3YXksIGEgbWlub3IgY29tbWVudDogd2hhdCBpcyB0aGUgbG9jYXRpb24gb2YgdGhl IHRleHQgdXBkYXRpbmcgdGhlIHNlY3Rpb24NCiAgICA+PiAzIG9mIFJGQyA1NDgwPyBTaG91bGQg aXQgZ28gYXQgdGhlIGVuZCBvZiB0aGUgZXhpc3Rpbmcgc2VjdGlvbiAzIChteSBndWVzcyk/IE9y DQogICAgPj4gYXQgdGhlIGJlZ2lubmluZyA/IG9yIHNvbWV3aGVyZSBpbiB0aGUgbWlkZGxlID8g U2hvdWxkIGl0IHJlcGxhY2UgY29tcGxldGVseSBvcg0KICAgID4+IHBhcnRpYWxseSB0aGUgZXhp c3Rpbmcgc2VjdGlvbiAzPw0KICAgID4+IA0KICAgID4+IC3DqXJpYw0KICAgID4+IA0KICAgID4+ IFBTOiBJIGtub3cgdGhhdCBteSBjb21tZW50IGlzIG1vc3RseSBsYXJnZXIgdGhhbiB0aGUgdXBk YXRlIGl0c2VsZiA7LSkNCiAgICA+PiANCiAgICA+PiANCiAgICA+PiANCiAgICA+IA0KICAgIA0K ICAgIA0KDQo= From nobody Wed Feb 26 08:20:06 2020 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 35E793A0ACA for ; Wed, 26 Feb 2020 08:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 zJV4w2CggtSl for ; Wed, 26 Feb 2020 08:19:57 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 3D7773A0ADA for ; Wed, 26 Feb 2020 08:19:30 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id f3so3179419qkh.3 for ; Wed, 26 Feb 2020 08:19:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mHZeeVWbpTwajpHBxI+bo4aoGuS9HlySk6EcqoTJAGU=; b=BIAm5FCBvS3LsqW1Y6dnUbS+IkfTcmcPENAM84OFauFYVf5qaB/1iFpuxK05M4H4NE TPdVvvGPCvTRH2tlN1KutZzuttRALR4jSmYRht9jAA3rKH6ptDUfMSxdZQfLBqTIc18n cxyNy6GnNRboEpPBO97h9XkyGjMb6B24WVl2Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mHZeeVWbpTwajpHBxI+bo4aoGuS9HlySk6EcqoTJAGU=; b=SfCuWZsErx9gXlUe3z6+suVGFtQicsLIMfuvdM9Zfk15xGoOtGXW3YAzubhnYIMuvH BDiSY2j4LpnKkxTzIseClghSKjhxm3GTZgSyq20bFRNq/CEzEaGVRvFSIAKy0HJRUhpY HNQy6lVpqOCOm0j4WVSYmHqQFjV0r8seINqL3h5FyvtqL8y9vTGvLdjrLuDQ37cUG2fD K/1cEMlKM6N8z0d0C3Kuj+UWiZl52F8J8bdSIfEiZc2M515uCG7IL0pf//FikPgzfffh 5cfFvCvmVX/xdjroYzJtBqbThL0KATA6Y1d3RLl2Tc7KmLht8lIqD+GzVYGAznRys7FN d2wA== X-Gm-Message-State: APjAAAWTPG4m0sKEEPmyzjKnVml0u11ZWpgqBy9GgK0qXwTsXMpuN1Vx EpuZTYxSheZ0P9JVI7P7oRGRhRXa9dw= X-Google-Smtp-Source: APXvYqwCXtTR9qbpiM5qyMAjktFB1uQW60U25vha2ge9pJ6OI0ke1BZg3f45YlwToZyK8ixvT5u5KQ== X-Received: by 2002:a37:6843:: with SMTP id d64mr6219165qkc.207.1582733968195; Wed, 26 Feb 2020 08:19:28 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id t2sm1366267qkc.31.2020.02.26.08.19.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Feb 2020 08:19:27 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: <8049C43E-F18C-4298-AF24-4AC040AEBDE0@cisco.com> Date: Wed, 26 Feb 2020 11:19:26 -0500 Cc: Russ Housley , IESG , "draft-ietf-lamps-5480-ku-clarifications@ietf.org" , "lamps-chairs@ietf.org" , "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <15DB9AB7-4FA8-405A-9739-89089A65640D@sn3rd.com> References: <158266464705.11162.11554831216624396111.idtracker@ietfa.amsl.com> <2A47D0FC-A57A-48B7-B642-C3305C3B9270@vigilsec.com> <19971B81-9F49-4CB4-BEF1-103CAC920279@sn3rd.com> <8049C43E-F18C-4298-AF24-4AC040AEBDE0@cisco.com> To: "Eric Vyncke (evyncke)" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-lamps-5480-ku-clarifications-00=3A_=28with_COMMENT=29?= 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, 26 Feb 2020 16:20:04 -0000 PR staged and ready to be merged pending other IESG comments: = https://github.com/lamps-wg/draft-ietf-lamps-5480-ku-clarifications/pull/6= spt > On Feb 26, 2020, at 00:51, Eric Vyncke (evyncke) = wrote: >=20 > This would be the cherry on the cake ;-) >=20 > =EF=BB=BF-----Original Message----- > From: Sean Turner > Date: Wednesday, 26 February 2020 at 03:13 > To: Russ Housley > Cc: Eric Vyncke , IESG , = "draft-ietf-lamps-5480-ku-clarifications@ietf.org" = , = "lamps-chairs@ietf.org" , "spasm@ietf.org" = > Subject: Re: =C3=89ric Vyncke's No Objection on = draft-ietf-lamps-5480-ku-clarifications-00: (with COMMENT) >=20 > I could add something like the following at the end of s1: >=20 > The additions are to be made to the end of Section 3. >=20 > spt >=20 > PS - As requested by Roman, I spun a new version to address the = GENART comments. >=20 >> On Feb 25, 2020, at 16:08, Russ Housley wrote: >>=20 >> Eric: >>=20 >> You are correct, the text should be added to the end of Section 3. >>=20 >> Russ >>=20 >>=20 >>> On Feb 25, 2020, at 4:04 PM, =C3=89ric Vyncke via Datatracker = wrote: >>>=20 >>> =C3=89ric Vyncke has entered the following ballot position for >>> draft-ietf-lamps-5480-ku-clarifications-00: 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-5480-ku-clarifications/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> Ultra short document :-) >>>=20 >>> Anyway, a minor comment: what is the location of the text updating = the section >>> 3 of RFC 5480? Should it go at the end of the existing section 3 (my = guess)? Or >>> at the beginning ? or somewhere in the middle ? Should it replace = completely or >>> partially the existing section 3? >>>=20 >>> -=C3=A9ric >>>=20 >>> PS: I know that my comment is mostly larger than the update itself = ;-) >>>=20 >>>=20 >>>=20 >>=20 >=20 >=20 >=20 From nobody Wed Feb 26 08:37:14 2020 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 5FF0D3A0B33; Wed, 26 Feb 2020 08:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.389 X-Spam-Level: X-Spam-Status: No, score=-0.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_URI_ONLY=0.999, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 GpQrlAGNsCtW; Wed, 26 Feb 2020 08:37:06 -0800 (PST) Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) (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 61C443A0B2B; Wed, 26 Feb 2020 08:37:06 -0800 (PST) Received: by mail-io1-f41.google.com with SMTP id c17so4035844ioc.4; Wed, 26 Feb 2020 08:37:06 -0800 (PST) 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=/e3IhJhDgNOWEdmHeSebiSQP38rRlsIbey5C4W5dCJY=; b=b5E8CunvJQoa4gqYFE1zjKdWM5fsRUvEiphWiaKdGu7iIUWIAn9szuYlu/pGNYCXkI 9LieH8rXIn9rx3tjyWIOW/bUOD8zQZCpBM13wRFTKYNh0S/Babgcb29Sxajc8a0iZj0B qcGbXSlRBD+L+aQ4K7fGd821zQTB0uPfEryTI5yJzIKF5WJ63tmHI+99HizKbczmRlsV zvtNKzk7Jj4gx89wgDzKYs2q0nbGDg/hrfhy48kWqqUZiIA/C8myFV10RePAf5lalZMt oMRGjRvz6G+x98DuT3hvA829Xa9y8YUjYc2eH9cIpUXJkF/Z5HezZGAmX4sVLLg5OcXI 3Djw== X-Gm-Message-State: APjAAAWUWJ0UONH5OcMc4XWKW2XQm8vl6nBb+lO46ef98qoBLCg/Qiv9 2izJYBex5r8sf2Cv5BdmtxKrUPxqoOpNNMobrzU= X-Google-Smtp-Source: APXvYqxgWyQZ2kbLjcbSwHapFlG/sbKE1sJBIVcTcNaNasYpvC8SD0NX+kFdliCL5R8OFbrJ3joGVs0lC8VusPN1EJw= X-Received: by 2002:a5d:9a85:: with SMTP id c5mr5431432iom.266.1582735025203; Wed, 26 Feb 2020 08:37:05 -0800 (PST) MIME-Version: 1.0 References: <158267138036.11010.7143212937692090838.idtracker@ietfa.amsl.com> <756FF88A-DE98-42A9-ADC0-F24E155A8CA6@sn3rd.com> In-Reply-To: <756FF88A-DE98-42A9-ADC0-F24E155A8CA6@sn3rd.com> From: Barry Leiba Date: Wed, 26 Feb 2020 08:36:53 -0800 Message-ID: To: Sean Turner Cc: The IESG , draft-ietf-lamps-5480-ku-clarifications@ietf.org, lamps-chairs@ietf.org, LAMPS WG , Russ Housley 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-5480-ku-clarifications-00: (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, 26 Feb 2020 16:37:12 -0000 On Tue, Feb 25, 2020 at 6:11 PM Sean Turner wrote: > > > > > On Feb 25, 2020, at 17:56, Barry Leiba via Datatracker wrote: > > > > Barry Leiba has entered the following ballot position for > > draft-ietf-lamps-5480-ku-clarifications-00: 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.ht= ml > > 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-5480-ku-clarification= s/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thanks for a nice, super-short and to-the-point document. I hate to pi= ck on > > anything here, but: > > > > then the following > > values also MUST NOT be present: > > > > Do you mean "MUST NOT also be present"? The "also" seems misplaced whe= re it > > is, and it made me wonder if I misunderstood. An alternative fix would= be to > > simply remove "also=E2=80=9D. > > In my mind it was an =E2=80=9Calso=E2=80=9D because the text is basically= saying in addition to the list already in RFC 5480 (text below) do not als= o set these two bits. > > If the keyUsage extension is present in a certificate that indicates > id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following > values MUST NOT be present: > > digitalSignature; > nonRepudiation; > keyTransport; > keyCertSign; and > cRLSign. > > With that said, I would be happy to remove it or move it - You tell me wh= ich you=E2=80=99d prefer ;) > > spt > From nobody Wed Feb 26 08:38:44 2020 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 6B3513A0BA1; Wed, 26 Feb 2020 08:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.115 X-Spam-Level: X-Spam-Status: No, score=0.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_RHS_DOB=1.514] autolearn=no 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 PBPPmIEF6Lyj; Wed, 26 Feb 2020 08:38:18 -0800 (PST) Received: from mail-il1-f177.google.com (mail-il1-f177.google.com [209.85.166.177]) (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 090AE3A0B8C; Wed, 26 Feb 2020 08:38:18 -0800 (PST) Received: by mail-il1-f177.google.com with SMTP id x7so804290ilq.11; Wed, 26 Feb 2020 08:38:17 -0800 (PST) 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=hunTfswkbyAg1aLXO1wj3p4zoGOVuix0mxBnUTNX9Rs=; b=AJk88lReGV46ei8wXFkkWfSiyxLI5NF2Shf+Y0j/ZzUaqjwx8m3kLDZscS/F6sVEHv hUY+C+WzURQjTMV0q6s+W5TgCuX9cZQZ+AyWbZBcR2uEnu6NX5qKX+FpXKHZeIMQPHyo qitkcAmlu1G6WDeXCQ/d/5jcKXugm+AAZXCsHhb4+w/mMSsxPqo6V0ZMvsWQJ67LC2eC E+b210A+jWsVvhzvBzXY0guJ5MpNIFT8dtfWWPYcWylXtqyV4lcbe4m/KAenZ0y3Gybn 17QjvN6TsE+6bA0fuplseOmuudsyHl3Wu6Dkj7Gfw/c5rGPO1R3SZvtMVEwTFaYL1VXc cQMQ== X-Gm-Message-State: APjAAAVPBHB1yIsn1sJg99EyRSFGFrNeG87O0hTNhVWdhIM9A+FRgKYQ mwSlxT+Y6s7UWGjkcBHISaHi27pio5PfSjSdYOs= X-Google-Smtp-Source: APXvYqw48H9tQJ3kfuF9pviLzkqwra+9KvqtThVtEsgbgVv3xa1RNXsXty7P7SVFNLdKyF7niyUqWUeuWG0k/4cUBfw= X-Received: by 2002:a92:2907:: with SMTP id l7mr6108805ilg.140.1582735097090; Wed, 26 Feb 2020 08:38:17 -0800 (PST) MIME-Version: 1.0 References: <158267138036.11010.7143212937692090838.idtracker@ietfa.amsl.com> <756FF88A-DE98-42A9-ADC0-F24E155A8CA6@sn3rd.com> In-Reply-To: <756FF88A-DE98-42A9-ADC0-F24E155A8CA6@sn3rd.com> From: Barry Leiba Date: Wed, 26 Feb 2020 08:38:03 -0800 Message-ID: To: Sean Turner Cc: The IESG , draft-ietf-lamps-5480-ku-clarifications@ietf.org, lamps-chairs@ietf.org, LAMPS WG , Russ Housley 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-5480-ku-clarifications-00: (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, 26 Feb 2020 16:38:25 -0000 (Sorry for the previous content-free message.) My comment is, of course, non-blocking, and I don't care which way you handle it, really. If you think the current phrasing is good, then tally-ho. b On Tue, Feb 25, 2020 at 6:11 PM Sean Turner wrote: > > > > > On Feb 25, 2020, at 17:56, Barry Leiba via Datatracker wrote: > > > > Barry Leiba has entered the following ballot position for > > draft-ietf-lamps-5480-ku-clarifications-00: 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.ht= ml > > 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-5480-ku-clarification= s/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thanks for a nice, super-short and to-the-point document. I hate to pi= ck on > > anything here, but: > > > > then the following > > values also MUST NOT be present: > > > > Do you mean "MUST NOT also be present"? The "also" seems misplaced whe= re it > > is, and it made me wonder if I misunderstood. An alternative fix would= be to > > simply remove "also=E2=80=9D. > > In my mind it was an =E2=80=9Calso=E2=80=9D because the text is basically= saying in addition to the list already in RFC 5480 (text below) do not als= o set these two bits. > > If the keyUsage extension is present in a certificate that indicates > id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following > values MUST NOT be present: > > digitalSignature; > nonRepudiation; > keyTransport; > keyCertSign; and > cRLSign. > > With that said, I would be happy to remove it or move it - You tell me wh= ich you=E2=80=99d prefer ;) > > spt > From nobody Thu Feb 27 02:46:36 2020 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 7FB9F3A0836; Thu, 27 Feb 2020 02:46:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tim Chown via Datatracker To: Cc: draft-ietf-lamps-5480-ku-clarifications.all@ietf.org, spasm@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158280039040.6210.14383434825732268169@ietfa.amsl.com> Reply-To: Tim Chown Date: Thu, 27 Feb 2020 02:46:30 -0800 Archived-At: Subject: [lamps] Opsdir last call review of draft-ietf-lamps-5480-ku-clarifications-01 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: Thu, 27 Feb 2020 10:46:31 -0000 Reviewer: Tim Chown Review result: Not Ready I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. The draft updates RFC 5480 to clarify the usage of the keyEncipherment and dataEncipherment key usage bits in the Subject Public Key Information field for certificates that support elliptic curve cryptography. Specifically, it states that neither of these bits are set for key agreement algorithms. This is a short document with just a few lines of text that update RFC 5480. The rationale for the additional clarification seems clear. The subject matter of the draft is not a strong area of interest of mine. Overall, the document is not Ready, primarily due to some key (no pun intended!) text being missing. Comments: Section 1: It would be good to state whether it is all or some specific key agreement algorithms. Section 3: The way it is written, I would suggest saying “or” for the bits, not “and”. A specific reference to section 2.1 of RFC 5480 would be good to add, where the semantics id-ecDH, id-ecMQV and id-ecPublicKey are given. The first sentence appears to be missing text - a certificate that indicates what? I’m guessing this should be id-ecPublicKey? Tim From nobody Thu Feb 27 09:30:31 2020 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 786963A0D96 for ; Thu, 27 Feb 2020 09:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=sn3rd.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 J1Au2TXCgTXn for ; Thu, 27 Feb 2020 09:30:19 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 073393A0D98 for ; Thu, 27 Feb 2020 09:30:18 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id f140so76799qke.11 for ; Thu, 27 Feb 2020 09:30:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JR6KPZBGAskwD0zP/bgzATrAO1G7JJ7q9ORyqO4kX7Q=; b=B4afwrBu1oYteO4jzHi9D6o2YjOrCT+lNnv5ts++aO/mm3zAE+usCoFrAf42p9bFu5 cmRkezhdlOphYXgVm0LiOg/lwOM8IGYjzfDxKs7zLDBx8SDf2Pf2OEvSj806ipRhhQ+/ QLfSbh0sWH16X087LU8asKYvveUHJyOGw6E+4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JR6KPZBGAskwD0zP/bgzATrAO1G7JJ7q9ORyqO4kX7Q=; b=nFXVK840ABJjDBMInAx/OkrOEoIIibCx+Gt+YBKl5RF7PvKknJG/u8/U+vnyXE8EQb pHQIOQydj/TlScQj4atTyBTThbO2fK0tzAR1V0cbgjqJQnaJk5awexQ6BQWYWxNM/+/x bdNF7k6DxKVfqquODchQ1dajpHVKUCLeG6yo1XFHIbNfXFJNwy3BPx9hHjxC9NtCONFq c0D3CMhJK7JxTmq4j5qqC9qUprpEFh/PawR1gEJuXOEZJT/fkD46d6ZXYnGc1aHX0z7V jKcP7Ps86Ri0/0//ks5Un+XI6p08LlCANobYOtp42Xey2BNHci5lpdtBcUmf1FyeTq+m FqJw== X-Gm-Message-State: APjAAAVoY8dTs9gPjtpbjAHCUpP4DRWjkrV1Tb6Posiy2PQ4HCtWpGeh qZzZkfaGICB00o0JcRQL4goNKA== X-Google-Smtp-Source: APXvYqziRYQjg46sq86SEtwIepF/iZbDLfDOlZZB8s0e4jp0CJTdmt+QY+CI4B+JnlY5NenTBfp8JQ== X-Received: by 2002:a37:a8c3:: with SMTP id r186mr307008qke.37.1582824618067; Thu, 27 Feb 2020 09:30:18 -0800 (PST) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id k16sm3425295qkh.55.2020.02.27.09.30.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Feb 2020 09:30:17 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: <158280039040.6210.14383434825732268169@ietfa.amsl.com> Date: Thu, 27 Feb 2020 12:30:16 -0500 Cc: ops-dir@ietf.org, draft-ietf-lamps-5480-ku-clarifications.all@ietf.org, LAMPS WG , last-call@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <897DD40E-CB32-4DF4-AE98-A6E06262ED6B@sn3rd.com> References: <158280039040.6210.14383434825732268169@ietfa.amsl.com> To: Tim Chown X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Opsdir last call review of draft-ietf-lamps-5480-ku-clarifications-01 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, 27 Feb 2020 17:30:22 -0000 Tim, Thanks for the review. Responses in-line. spt > On Feb 27, 2020, at 05:46, Tim Chown via Datatracker = wrote: >=20 > Reviewer: Tim Chown > Review result: Not Ready >=20 > I have reviewed this document as part of the Operational directorate's = ongoing > effort to review all IETF documents being processed by the IESG. = These > comments were written with the intent of improving the operational = aspects of > the IETF drafts. Comments that are not addressed in last call may be = included > in AD reviews during the IESG review. Document editors and WG chairs = should > treat these comments just like any other last call comments. >=20 > The draft updates RFC 5480 to clarify the usage of the keyEncipherment = and > dataEncipherment key usage bits in the Subject Public Key Information = field for > certificates that support elliptic curve cryptography. Specifically, = it states > that neither of these bits are set for key agreement algorithms. >=20 > This is a short document with just a few lines of text that update RFC = 5480.=20 > The rationale for the additional clarification seems clear. >=20 > The subject matter of the draft is not a strong area of interest of = mine. >=20 > Overall, the document is not Ready, primarily due to some key (no pun > intended!) text being missing. >=20 > Comments: >=20 > Section 1: >=20 > It would be good to state whether it is all or some specific key = agreement > algorithms. It's just the ones defined in RFC 5480 ;) How about: OLD: This document corrects this omission, by updating=20 Section 3 of [RFC5480] to make it clear that neither keyEncipherment nor the dataEncipherment key usage bits are set for key agreement algorithms. NEW: This document corrects this omission, by updating=20 Section 3 of [RFC5480] to make it clear that neither keyEncipherment nor the dataEncipherment key usage bits are set for key agreement algorithms specified therein. Implemented here: = https://github.com/lamps-wg/draft-ietf-lamps-5480-ku-clarifications/pull/7= > Section 3: >=20 > The way it is written, I would suggest saying =E2=80=9Cor=E2=80=9D for = the bits, not =E2=80=9Cand=E2=80=9D. I could see =E2=80=9Cnor=E2=80=9D, but just wanted to use words similar = to those used in RFC 5480 and there it uses =E2=80=9Cand=E2=80=9D for = the MUST NOT clauses. > A specific reference to section 2.1 of RFC 5480 would be good to add, = where the > semantics id-ecDH, id-ecMQV and id-ecPublicKey are given. I will bow to the will of the IESG, but I think this is a bit overkill = since I would expect that anybody reading this also read RFC 5480. > The first sentence appears to be missing text - a certificate that = indicates > what? I=E2=80=99m guessing this should be id-ecPublicKey? drat I was overzealous in my deletions to address an earlier comment - = yep id-ecPublicKey. It=E2=80=99s fixed here: = https://github.com/lamps-wg/draft-ietf-lamps-5480-ku-clarifications/blob/m= aster/draft-ietf-lamps-5480-ku-clarifications.md= From nobody Thu Feb 27 10:18:32 2020 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 E76713A07C9 for ; Thu, 27 Feb 2020 10:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (1024-bit key) header.d=jisc.ac.uk 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 dVpg019CQ2CY for ; Thu, 27 Feb 2020 10:18:14 -0800 (PST) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03AA53A07BC for ; Thu, 27 Feb 2020 10:18:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1582827492; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6HmzYzRYaCfzOk7ILG2lH0058XN3NFy2ggQgr7bUqW0=; b=L/iytHR2OstuGFQfuCtkTDRFqjZEmMbQH2d0DyrSA3M5osSi1VA5r1llaC6IeBzeWoqzDj ZuwCkcZbxYOnjaDZCXA4VDICHy40QC1J8kWwXWyDGrSp8vNjy8S3c8lfXJlHyNmz5836e0 vHLLmpUjC5K0uvbBM1v/hUvUR0k2/yY= Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03lp2054.outbound.protection.outlook.com [104.47.10.54]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-186-0fqdeB_-NgSmHjB5CipZcw-1; Thu, 27 Feb 2020 18:17:01 +0000 X-MC-Unique: 0fqdeB_-NgSmHjB5CipZcw-1 Received: from AM5PR0701MB2849.eurprd07.prod.outlook.com (10.168.153.149) by AM5PR0701MB2481.eurprd07.prod.outlook.com (10.169.153.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.12; Thu, 27 Feb 2020 18:16:59 +0000 Received: from AM5PR0701MB2849.eurprd07.prod.outlook.com ([fe80::1446:7407:4077:14a4]) by AM5PR0701MB2849.eurprd07.prod.outlook.com ([fe80::1446:7407:4077:14a4%9]) with mapi id 15.20.2772.012; Thu, 27 Feb 2020 18:16:58 +0000 From: Tim Chown To: Sean Turner CC: "draft-ietf-lamps-5480-ku-clarifications.all@ietf.org" , LAMPS WG , "ops-dir@ietf.org" , "last-call@ietf.org" Thread-Topic: [Last-Call] Opsdir last call review of draft-ietf-lamps-5480-ku-clarifications-01 Thread-Index: AQHV7ZOYCDvEdlVQEEaChOtdrZpZfKgvWQsA Date: Thu, 27 Feb 2020 18:16:58 +0000 Message-ID: <4A062CB7-3A71-4A71-AC80-AA65DAAABCE0@jisc.ac.uk> References: <158280039040.6210.14383434825732268169@ietfa.amsl.com> <897DD40E-CB32-4DF4-AE98-A6E06262ED6B@sn3rd.com> In-Reply-To: <897DD40E-CB32-4DF4-AE98-A6E06262ED6B@sn3rd.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.60.0.2.5) x-originating-ip: [2001:a88:d510:1101:6806:ebcd:80e:a748] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 895fa641-5988-4e8d-4626-08d7bbb13c2b x-ms-traffictypediagnostic: AM5PR0701MB2481: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03264AEA72 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(376002)(136003)(366004)(39860400002)(199004)(189003)(8676002)(81156014)(8936002)(5660300002)(6506007)(478600001)(36756003)(54906003)(66946007)(186003)(6512007)(966005)(53546011)(6486002)(71200400001)(2906002)(91956017)(33656002)(76116006)(4326008)(81166006)(6916009)(2616005)(86362001)(66556008)(66476007)(64756008)(66446008)(786003)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2481; H:AM5PR0701MB2849.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iasNtF408dnE4gCKHdkLnKb8xQaCJ+TMGhxz7NqQqcmG5M7JBDltanPgUOlqVt3GOrFdEKYHYNSvruIN54DOEwWeKUkRtBSDede2+4oWRfcKX9Sdearft6mzNjoRmLiGktTayoOubr+/NPnrtVtvwPPu/R9ZSBcKVodsdrzTCOE13tbce1BARHUDYOd0Oi23TIKcVX+Fn24tEV6AbqtZnluyg23N9zhd0+Z1a9aWhn8ZhKwNP5h8VlFwRdfzA2+XQzPmQRnaZ0i3Vzjrjim0ns83XRFPiYEtFXYMKgfvC/c8I1zYY8NisGssjYqSsxJItlLNid2RbNJZLCbtzU5u9WhU4x7+/p1dpv3B0GgUKaPJOZ/lMjhzFKqcDZf8JZZFLW65hHQCHGLQ7RC7Jf2tdVj/BVVH7S5HuD10uoatr6t7GJm30rHMdN4N8zUjZIdz1RVxoatEAHtJTokgcjksIGnyTaqA/sIy0MWi2Ugg/bn5vSaBUFcL/WgC9GY0qMRFiHaHI+fJ+ogfwpv+70lCKg== x-ms-exchange-antispam-messagedata: 2roE/c1zBQ+2OmhH0hPWl2InDEI/cAYXZ3gE13qJMtc95W4uJXLUke43KrqjgMOP4AeawZ1P/1WoI16MS2GAzbMyd/d7qEaNJ6enjftkIhBj9auSkj7LFisBTKl9oDtWhTs0ghCwep8GYuye47Jmeh6Fjos75gFW7roDsbULoZzJmoQHGJgc3H8gezIZgxtdMI177+dfBzOdIxpAjXOAYg== x-ms-exchange-transport-forked: True Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 895fa641-5988-4e8d-4626-08d7bbb13c2b X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2020 18:16:58.7609 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: LcY0ioy+H0v9lt1Fp7WPYa6wm+jHmPgQbt71glRg99slWq5BlMZuJWWPjKJf5Y8yfCEayU88pIEwD91lUiRVTw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2481 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: jisc.ac.uk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [lamps] [Last-Call] Opsdir last call review of draft-ietf-lamps-5480-ku-clarifications-01 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, 27 Feb 2020 18:18:23 -0000 SGksDQoNCkluLWxpbmUuLi4NCg0KPiBPbiAyNyBGZWIgMjAyMCwgYXQgMTc6MzAsIFNlYW4gVHVy bmVyIDxzZWFuQHNuM3JkLmNvbT4gd3JvdGU6DQo+IA0KPiBUaW0sDQo+IA0KPiBUaGFua3MgZm9y IHRoZSByZXZpZXcuIFJlc3BvbnNlcyBpbi1saW5lLg0KPiANCj4gc3B0DQo+IA0KPj4gT24gRmVi IDI3LCAyMDIwLCBhdCAwNTo0NiwgVGltIENob3duIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBp ZXRmLm9yZz4gd3JvdGU6DQo+PiANCj4+IFJldmlld2VyOiBUaW0gQ2hvd24NCj4+IFJldmlldyBy ZXN1bHQ6IE5vdCBSZWFkeQ0KPj4gDQo+PiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBh cyBwYXJ0IG9mIHRoZSBPcGVyYXRpb25hbCBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcNCj4+IGVmZm9y dCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVT Ry4gIFRoZXNlDQo+PiBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gd2l0aCB0aGUgaW50ZW50IG9mIGlt cHJvdmluZyB0aGUgb3BlcmF0aW9uYWwgYXNwZWN0cyBvZg0KPj4gdGhlIElFVEYgZHJhZnRzLiBD b21tZW50cyB0aGF0IGFyZSBub3QgYWRkcmVzc2VkIGluIGxhc3QgY2FsbCBtYXkgYmUgaW5jbHVk ZWQNCj4+IGluIEFEIHJldmlld3MgZHVyaW5nIHRoZSBJRVNHIHJldmlldy4gIERvY3VtZW50IGVk aXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQNCj4+IHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3Qg bGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KPj4gDQo+PiBUaGUgZHJhZnQgdXBk YXRlcyBSRkMgNTQ4MCB0byBjbGFyaWZ5IHRoZSB1c2FnZSBvZiB0aGUga2V5RW5jaXBoZXJtZW50 IGFuZA0KPj4gZGF0YUVuY2lwaGVybWVudCBrZXkgdXNhZ2UgYml0cyBpbiB0aGUgU3ViamVjdCBQ dWJsaWMgS2V5IEluZm9ybWF0aW9uIGZpZWxkIGZvcg0KPj4gY2VydGlmaWNhdGVzIHRoYXQgc3Vw cG9ydCBlbGxpcHRpYyBjdXJ2ZSBjcnlwdG9ncmFwaHkuICBTcGVjaWZpY2FsbHksIGl0IHN0YXRl cw0KPj4gdGhhdCBuZWl0aGVyIG9mIHRoZXNlIGJpdHMgYXJlIHNldCBmb3Iga2V5IGFncmVlbWVu dCBhbGdvcml0aG1zLg0KPj4gDQo+PiBUaGlzIGlzIGEgc2hvcnQgZG9jdW1lbnQgd2l0aCBqdXN0 IGEgZmV3IGxpbmVzIG9mIHRleHQgdGhhdCB1cGRhdGUgUkZDIDU0ODAuIA0KPj4gVGhlIHJhdGlv bmFsZSBmb3IgdGhlIGFkZGl0aW9uYWwgY2xhcmlmaWNhdGlvbiBzZWVtcyBjbGVhci4NCj4+IA0K Pj4gVGhlIHN1YmplY3QgbWF0dGVyIG9mIHRoZSBkcmFmdCBpcyBub3QgYSBzdHJvbmcgYXJlYSBv ZiBpbnRlcmVzdCBvZiBtaW5lLg0KPj4gDQo+PiBPdmVyYWxsLCB0aGUgZG9jdW1lbnQgaXMgbm90 IFJlYWR5LCBwcmltYXJpbHkgZHVlIHRvIHNvbWUga2V5IChubyBwdW4NCj4+IGludGVuZGVkISkg dGV4dCBiZWluZyBtaXNzaW5nLg0KPj4gDQo+PiBDb21tZW50czoNCj4+IA0KPj4gU2VjdGlvbiAx Og0KPj4gDQo+PiBJdCB3b3VsZCBiZSBnb29kIHRvIHN0YXRlIHdoZXRoZXIgaXQgaXMgYWxsIG9y IHNvbWUgc3BlY2lmaWMga2V5IGFncmVlbWVudA0KPj4gYWxnb3JpdGhtcy4NCj4gDQo+IEl0J3Mg anVzdCB0aGUgb25lcyBkZWZpbmVkIGluIFJGQyA1NDgwIDspICBIb3cgYWJvdXQ6DQo+IA0KPiBP TEQ6DQo+IA0KPiBUaGlzIGRvY3VtZW50IGNvcnJlY3RzIHRoaXMgb21pc3Npb24sIGJ5IHVwZGF0 aW5nIA0KPiBTZWN0aW9uIDMgb2YgW1JGQzU0ODBdIHRvIG1ha2UgaXQgY2xlYXIgdGhhdCBuZWl0 aGVyDQo+IGtleUVuY2lwaGVybWVudCBub3IgdGhlIGRhdGFFbmNpcGhlcm1lbnQga2V5IHVzYWdl DQo+IGJpdHMgYXJlIHNldCBmb3Iga2V5IGFncmVlbWVudCBhbGdvcml0aG1zLg0KPiANCj4gTkVX Og0KPiANCj4gVGhpcyBkb2N1bWVudCBjb3JyZWN0cyB0aGlzIG9taXNzaW9uLCBieSB1cGRhdGlu ZyANCj4gU2VjdGlvbiAzIG9mIFtSRkM1NDgwXSB0byBtYWtlIGl0IGNsZWFyIHRoYXQgbmVpdGhl cg0KPiBrZXlFbmNpcGhlcm1lbnQgbm9yIHRoZSBkYXRhRW5jaXBoZXJtZW50IGtleSB1c2FnZQ0K PiBiaXRzIGFyZSBzZXQgZm9yIGtleSBhZ3JlZW1lbnQgYWxnb3JpdGhtcyBzcGVjaWZpZWQNCj4g dGhlcmVpbi4NCj4gDQo+IEltcGxlbWVudGVkIGhlcmU6DQo+IGh0dHBzOi8vZ2l0aHViLmNvbS9s YW1wcy13Zy9kcmFmdC1pZXRmLWxhbXBzLTU0ODAta3UtY2xhcmlmaWNhdGlvbnMvcHVsbC83DQoN ClRoYW5rcy4NCg0KPj4gU2VjdGlvbiAzOg0KPj4gDQo+PiBUaGUgd2F5IGl0IGlzIHdyaXR0ZW4s IEkgd291bGQgc3VnZ2VzdCBzYXlpbmcg4oCcb3LigJ0gZm9yIHRoZSBiaXRzLCBub3Qg4oCcYW5k 4oCdLg0KPiANCj4gSSBjb3VsZCBzZWUg4oCcbm9y4oCdLCBidXQganVzdCB3YW50ZWQgdG8gdXNl IHdvcmRzIHNpbWlsYXIgdG8gdGhvc2UgdXNlZCBpbiBSRkMgNTQ4MCBhbmQgdGhlcmUgaXQgdXNl cyDigJxhbmTigJ0gZm9yIHRoZSBNVVNUIE5PVCBjbGF1c2VzLg0KDQpPSywgaWYgaXQga2VlcHMg aXQgY29uc2lzdGVudCB0aGF0J3MgZmluZSwgaXQganVzdCByZWFkcyBhIGxpdHRsZSBzdHJhbmdl bHkgdG8gbWUuDQoNCj4+IEEgc3BlY2lmaWMgcmVmZXJlbmNlIHRvIHNlY3Rpb24gMi4xIG9mIFJG QyA1NDgwIHdvdWxkIGJlIGdvb2QgdG8gYWRkLCB3aGVyZSB0aGUNCj4+IHNlbWFudGljcyBpZC1l Y0RILCBpZC1lY01RViBhbmQgaWQtZWNQdWJsaWNLZXkgYXJlIGdpdmVuLg0KPiANCj4gSSB3aWxs IGJvdyB0byB0aGUgd2lsbCBvZiB0aGUgSUVTRywgYnV0IEkgdGhpbmsgdGhpcyBpcyBhIGJpdCBv dmVya2lsbCBzaW5jZSBJIHdvdWxkIGV4cGVjdCB0aGF0IGFueWJvZHkgcmVhZGluZyB0aGlzIGFs c28gcmVhZCBSRkMgNTQ4MC4NCg0KV2VsbCwgb3BzLWRpciByZXZpZXdlcnMgbWlnaHQgbm90LCBz byBtYXliZSBpdOKAmXMganVzdCBkb3duIHRvIG1lIG5lZWRpbmcgdG8gaHVudCBkb3duIHRoZSBy ZWZlcmVuY2UgdG8gY2hlY2suICBXb3VsZG7igJl0IGh1cnQgdG8gYWRkIGl0PyAgQnV0IGFsc28g ZmluZSBpZiB5b3UgZG9u4oCZdC4NCg0KPj4gVGhlIGZpcnN0IHNlbnRlbmNlIGFwcGVhcnMgdG8g YmUgbWlzc2luZyB0ZXh0IC0gYSBjZXJ0aWZpY2F0ZSB0aGF0IGluZGljYXRlcw0KPj4gd2hhdD8g IEnigJltIGd1ZXNzaW5nIHRoaXMgc2hvdWxkIGJlIGlkLWVjUHVibGljS2V5Pw0KPiANCj4gZHJh dCBJIHdhcyBvdmVyemVhbG91cyBpbiBteSBkZWxldGlvbnMgdG8gYWRkcmVzcyBhbiBlYXJsaWVy IGNvbW1lbnQgLSB5ZXAgaWQtZWNQdWJsaWNLZXkuICBJdOKAmXMgZml4ZWQgaGVyZToNCj4gaHR0 cHM6Ly9naXRodWIuY29tL2xhbXBzLXdnL2RyYWZ0LWlldGYtbGFtcHMtNTQ4MC1rdS1jbGFyaWZp Y2F0aW9ucy9ibG9iL21hc3Rlci9kcmFmdC1pZXRmLWxhbXBzLTU0ODAta3UtY2xhcmlmaWNhdGlv bnMubWQNCg0KT0ssIGNoZWVycyENCg0KVGltDQoNCj4gLS0gDQo+IGxhc3QtY2FsbCBtYWlsaW5n IGxpc3QNCj4gbGFzdC1jYWxsQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbGFzdC1jYWxsDQoNCg== From nobody Fri Feb 28 10:03:25 2020 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 C042C3A1AA5 for ; Fri, 28 Feb 2020 10:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.387 X-Spam-Level: X-Spam-Status: No, score=-1.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 qRxdUlnN1yN8 for ; Fri, 28 Feb 2020 10:03:15 -0800 (PST) Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) (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 8DF313A0D7E for ; Fri, 28 Feb 2020 10:03:14 -0800 (PST) Received: by mail-ed1-f47.google.com with SMTP id p14so4327469edy.13 for ; Fri, 28 Feb 2020 10:03:14 -0800 (PST) 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; bh=TvPhgn5uHyx5bX2lYVTLMs6pjZsPj+aLnMPHTq20aLU=; b=brt7B4Ut1TvMo/XCI2dyFsb9U4xXLsezJ3yNJttHy8iw8SURNdSA8oTkLUdBglPDm6 F++4+X6PG/tppw9oCgY42UXH+RUe1aLndd6OmVoM/HdmJaQI1RTOGi7MHFJdxIcKb/EL 8X97PrPN16jgqh4uFUpQFvFYLviTaPiWM9tya8hOJECl0gXJoQn+CCXTwVPTk+QWXQKU +CcrpKnffvzSsxQprCuZW7Ui1Xo9I2XsBZj7iHkW4bpTMGblvpG5x6Xw5acfj6rDMb8d YrUHKL0ymuMtdxeaSLwHzn+NoDqzS4q53RrjjdqEeUTroC+2y1NRJSLod4WreIezw72W McDA== X-Gm-Message-State: APjAAAWhJpNkzpkyPGinNoEbGYkWwyw+OikUYCV1jQ2m/+5OjLzo+m/8 WIcOeK1bLbWY/QsGN5g90512dYB8 X-Google-Smtp-Source: APXvYqxRoN3nd8Ru+h1zHJpaHGTi6rmi7tK+qwX5zoipDgU76JVRtQkB+DVYXoY8TQRPPwHdmvqzAg== X-Received: by 2002:a17:906:7d6:: with SMTP id m22mr5189853ejc.335.1582912991883; Fri, 28 Feb 2020 10:03:11 -0800 (PST) Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com. [209.85.221.43]) by smtp.gmail.com with ESMTPSA id q3sm455775eju.88.2020.02.28.10.03.11 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Feb 2020 10:03:11 -0800 (PST) Received: by mail-wr1-f43.google.com with SMTP id j16so4016902wrt.3 for ; Fri, 28 Feb 2020 10:03:11 -0800 (PST) X-Received: by 2002:adf:aa0e:: with SMTP id p14mr5987909wrd.399.1582912991030; Fri, 28 Feb 2020 10:03:11 -0800 (PST) MIME-Version: 1.0 References: <20200227225404.CA7ADF40714@rfc-editor.org> In-Reply-To: <20200227225404.CA7ADF40714@rfc-editor.org> From: Ryan Sleevi Date: Fri, 28 Feb 2020 13:03:00 -0500 X-Gmail-Original-Message-ID: Message-ID: To: SPASM Content-Type: multipart/alternative; boundary="0000000000008a76d3059fa6a6f9" Archived-At: Subject: [lamps] Fwd: [Technical Errata Reported] RFC5280 (5997) 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: Fri, 28 Feb 2020 18:03:22 -0000 --0000000000008a76d3059fa6a6f9 Content-Type: text/plain; charset="UTF-8" I've heard word that this may not have gone out to the PKIX list, but I did want to pass this along with LAMPS. As both the current syntax and semantics are ambiguous, judging by implementation behaviour, I'm totally appreciative that the suggested change might be rejected or might be held for a hypothetical document update in the future. However, I did want to bring to broader attention and document the fact that the ambiguity has lead to different levels of guarantees. It was recently pointed out to me that Apple adopted the "URI-like" syntax, as discussed at https://cabforum.org/pipermail/servercert-wg/2020-February/001676.html , while as mentioned in the Errata, Go and OpenSSL seem to have adopted the "PEBKAC" syntax of assuming it's an encoding error. Within the Web PKI, tools like Amazon's certlint treats this as an error, while tools like ZLint inherit Golang's permissiveness. As a consequence, unless the CA applies both checks (which is strongly recommended, due to certlint attempting to compile the ASN.1 modules to offer stricter validation), it's possible that such certificates might continue to proliferate. As discussed within the linked Golang issue, there's unfortunately a number of documentation examples that use the leading period example, and so RFC 5280 CAs that don't participate exclusively in the Web PKI are even more at risk of the varying interpretations. ---------- Forwarded message --------- From: RFC Errata System Date: Thu, Feb 27, 2020 at 5:54 PM Subject: [Technical Errata Reported] RFC5280 (5997) To: , , < stephen.farrell@cs.tcd.ie>, , < housley@vigilsec.com>, , , , < kent@bbn.com>, Cc: , , The following errata report has been submitted for RFC5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5997 -------------------------------------- Type: Technical Reported by: Ryan Sleevi Section: 4.2.1.10 Original Text ------------- DNS name restrictions are expressed as host.example.com. Any DNS name that can be constructed by simply adding zero or more labels to the left-hand side of the name satisfies the name constraint. Corrected Text -------------- The syntax of dNSName MUST be as described in Section 4.2.1.6. Any DNS name that can be constructed by simply adding zero or more labels to the left-hand side of the name satisfies the name constraint. Notes ----- Currently, the syntax for a dNSName nameConstraint is left implicit, and thus has resulted in ambiguities in encoding and processing that have resulted in ineroperability issues. One interpretation is that the dNSName nameConstraint must be a valid "host name" (as discussed in RFC 8499), which is to say must be a Fully-Qualified Domain Name in the preferred name syntax. This interpretation is supported by Section 4.2.1.6, which explicitly states that for the subjectAltName. As 4.2.1.10 does not define an exception to this (as discussed in Appendix B), the interpretation, along with the existing example, would conclude that this field uses preferred name syntax, and that "DNS name" here matches the "host name" interpretation from RFC 8499 A different interpretation is that the dNSName nameConstraint uses the modified syntax similar to the URI nameConstraint. That is, it explicitly permits a leading period to indicate that one or more labels preceding is required in order to satisfy the constraint. This allows subdomains, but does not allow the base domain to match. While the language for the DNS name constraint makes it clear that a host name with no preceding period matches both that host and sub-domains, the existence of a preceding period would constraint it to only subdomains. Aligning with Section 4.2.1.6 would prohibit the latter interpretation, as the preferred name syntax does not permit leading periods. Alternatively, if the latter interpretation is intended, this section would benefit from making that explicit. This has been a source of interoperability issues, with additional information and discussion captured at: - https://github.com/golang/go/issues/16347 - https://rt.openssl.org/Ticket/Display.html?id=3562 While "running code" has aligned in being permissive with a leading period, implementations have gone and seemingly aligned on a third interpretation: The syntax of a dNSName MUST be as described in Section 4.2.1.6, with the exception that it MAY contain a leading period. Any DNS name that can be constructed by simply adding zero or more labels to the left-hand side of the name, ignoring any leading period, satisfies the name constraint. This seems to support implementations expecting the first interpretation in the certificates they receive, and seeing leading period as an encoding mistake, not an explicit desire for the second interpretation. 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. -------------------------------------- RFC5280 (draft-ietf-pkix-rfc3280bis-11) -------------------------------------- Title : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Publication Date : May 2008 Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk Category : PROPOSED STANDARD Source : Public-Key Infrastructure (X.509) Area : Security Stream : IETF Verifying Party : IESG --0000000000008a76d3059fa6a6f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've heard word that this may not have gone out to the= PKIX list, but I did want to pass this along with LAMPS.

As both the current syntax and semantics are ambiguous, judging by implem= entation behaviour, I'm totally appreciative that the suggested change = might be rejected or might be held for a hypothetical document update in th= e future.

However, I did want to bring to broader = attention and document the fact that the ambiguity has lead to different le= vels of guarantees. It was recently pointed out to me that Apple adopted th= e "URI-like" syntax, as discussed at=C2=A0https://cabforu= m.org/pipermail/servercert-wg/2020-February/001676.html=C2=A0, while as= mentioned in the Errata, Go and OpenSSL seem to have adopted the "PEB= KAC" syntax of assuming it's an encoding error.

Within the Web PKI, tools like Amazon's certlint treats this as = an error, while tools like ZLint inherit Golang's permissiveness. As a = consequence, unless the CA applies both checks (which is strongly recommend= ed, due to certlint attempting to compile the ASN.1 modules to offer strict= er validation), it's possible that such certificates might continue to = proliferate. As discussed within the linked Golang issue, there's unfor= tunately a number of documentation examples that use the leading period exa= mple, and so RFC 5280 CAs that don't participate exclusively in the Web= PKI are even more at risk of the varying interpretations.

---------- F= orwarded message ---------
From: RFC Errata System <rfc-editor@rfc-editor.org>
D= ate: Thu, Feb 27, 2020 at 5:54 PM
Subject: [Technical Errata Reported] R= FC5280 (5997)
To: <david.co= oper@nist.gov>, <stefan= s@microsoft.com>, <= stephen.farrell@cs.tcd.ie>, <sharon.boeyen@entrust.com>, <housley@vigilsec.com>, <wpolk@nist.gov>, <rdd@c= ert.org>, <kaduk@mit.edu>= ;, <kent@bbn.com>, <stefan@aaa-sec.com>
Cc: <ryan-pkix@sleevi.com>, <pkix@ietf.org>, <rfc-editor@rfc-editor.org>

The following errata report has been submitted for RFC5280,
"Internet X.509 Public Key Infrastructure Certificate and Certificate = Revocation List (CRL) Profile".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5997

--------------------------------------
Type: Technical
Reported by: Ryan Sleevi <ryan-pkix@sleevi.com>

Section: 4.2.1.10

Original Text
-------------
DNS name restrictions are expressed as host.example.com.=C2=A0 Any DNS name that can be constructed by simply adding zero or more labels to
the left-hand side of the name satisfies the name constraint.=C2=A0

Corrected Text
--------------
The syntax of dNSName MUST be as described in Section 4.2.1.6.=C2=A0 Any DN= S
name that can be constructed by simply adding zero or more labels to
the left-hand side of the name satisfies the name constraint.=C2=A0

Notes
-----
Currently, the syntax for a dNSName nameConstraint is left implicit, and th= us has resulted in ambiguities in encoding and processing that have resulte= d in ineroperability issues.

One interpretation is that the dNSName nameConstraint must be a valid "= ;host name" (as discussed in RFC 8499), which is to say must be a Full= y-Qualified Domain Name in the preferred name syntax. This interpretation i= s supported by Section 4.2.1.6, which explicitly states that for the subjec= tAltName. As 4.2.1.10 does not define an exception to this (as discussed in= Appendix B), the interpretation, along with the existing example, would co= nclude that this field uses preferred name syntax, and that "DNS name&= quot; here matches the "host name" interpretation from RFC 8499
A different interpretation is that the dNSName nameConstraint uses the modi= fied syntax similar to the URI nameConstraint. That is, it explicitly permi= ts a leading period to indicate that one or more labels preceding is requir= ed in order to satisfy the constraint. This allows subdomains, but does not= allow the base domain to match. While the language for the DNS name constr= aint makes it clear that a host name with no preceding period matches both = that host and sub-domains, the existence of a preceding period would constr= aint it to only subdomains.

Aligning with Section 4.2.1.6 would prohibit the latter interpretation, as = the preferred name syntax does not permit leading periods. Alternatively, i= f the latter interpretation is intended, this section would benefit from ma= king that explicit.

This has been a source of interoperability issues, with additional informat= ion and discussion captured at:
- https://github.com/golang/go/issues/16347
- https://rt.openssl.org/Ticket/Display.html?id= =3D3562

While "running code" has aligned in being permissive with a leadi= ng period, implementations have gone and seemingly aligned on a third inter= pretation:

The syntax of a dNSName MUST be as described in Section 4.2.1.6, with the e= xception that it MAY contain a leading period. Any DNS name that can be con= structed by simply adding zero or more labels to the left-hand side of the = name, ignoring any leading period, satisfies the name constraint.

This seems to support implementations expecting the first interpretation in= the certificates they receive, and seeing leading period as an encoding mi= stake, not an explicit desire for the second interpretation.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party=C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC5280 (draft-ietf-pkix-rfc3280bis-11)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Internet X.50= 9 Public Key Infrastructure Certificate and Certificate Revocation List (CR= L) Profile
Publication Date=C2=A0 =C2=A0 : May 2008
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: D. Cooper, S. Santesson= , S. Farrell, S. Boeyen, R. Housley, W. Polk
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Public-Key Infrast= ructure (X.509)
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
--0000000000008a76d3059fa6a6f9-- From nobody Fri Feb 28 10:39:27 2020 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 2CA273A1C02 for ; Fri, 28 Feb 2020 10:39:24 -0800 (PST) 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 bl8mbicCoDaG for ; Fri, 28 Feb 2020 10:39:16 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89DF3A1BED for ; Fri, 28 Feb 2020 10:39:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3D16B300A91 for ; Fri, 28 Feb 2020 13:39:13 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ly0V-9EmST7Q for ; Fri, 28 Feb 2020 13:39:09 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id B5E423005DB; Fri, 28 Feb 2020 13:39:08 -0500 (EST) From: Russ Housley Message-Id: <48F9976F-C087-4695-BA63-8DAA730A4906@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F9835CB2-E008-47FC-BDB7-E03FF4934CB7" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 28 Feb 2020 13:39:10 -0500 In-Reply-To: Cc: SPASM , IETF PKIX To: Ryan Sleevi References: <20200227225404.CA7ADF40714@rfc-editor.org> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Fwd: [Technical Errata Reported] RFC5280 (5997) 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: Fri, 28 Feb 2020 18:39:24 -0000 --Apple-Mail=_F9835CB2-E008-47FC-BDB7-E03FF4934CB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ryan: I see the point you are trying to make, but the exact substitution that = you propose breaks the sentence that follows. OLD DNS name restrictions are expressed as host.example.com. Any DNS name that can be constructed by simply adding zero or more labels to the left-hand side of the name satisfies the name constraint. For example, www.host.example.com would satisfy the constraint but host1.example.com would not. NEW For DNS names, restrictions MUST use the dNSName syntax in Section 4.2.1.6. Any DNS name that can be constructed by simply adding zero or more labels to the left-hand side of the name = satisfies the name constraint. For example, if the constraint contains host.example.com , then = www.host.example.com would satisfy the constraint but host1.example.com would not. > On Feb 28, 2020, at 1:03 PM, Ryan Sleevi wrote: >=20 > I've heard word that this may not have gone out to the PKIX list, but = I did want to pass this along with LAMPS. >=20 > As both the current syntax and semantics are ambiguous, judging by = implementation behaviour, I'm totally appreciative that the suggested = change might be rejected or might be held for a hypothetical document = update in the future. >=20 > However, I did want to bring to broader attention and document the = fact that the ambiguity has lead to different levels of guarantees. It = was recently pointed out to me that Apple adopted the "URI-like" syntax, = as discussed at = https://cabforum.org/pipermail/servercert-wg/2020-February/001676.html = = , while as mentioned in the Errata, Go and OpenSSL seem to have adopted = the "PEBKAC" syntax of assuming it's an encoding error. >=20 > Within the Web PKI, tools like Amazon's certlint treats this as an = error, while tools like ZLint inherit Golang's permissiveness. As a = consequence, unless the CA applies both checks (which is strongly = recommended, due to certlint attempting to compile the ASN.1 modules to = offer stricter validation), it's possible that such certificates might = continue to proliferate. As discussed within the linked Golang issue, = there's unfortunately a number of documentation examples that use the = leading period example, and so RFC 5280 CAs that don't participate = exclusively in the Web PKI are even more at risk of the varying = interpretations. >=20 > ---------- Forwarded message --------- > From: RFC Errata System > > Date: Thu, Feb 27, 2020 at 5:54 PM > Subject: [Technical Errata Reported] RFC5280 (5997) > To: >, = >, = >, = >, = >, >, >, = >, >, > > Cc: >, = >, > >=20 >=20 > The following errata report has been submitted for RFC5280, > "Internet X.509 Public Key Infrastructure Certificate and Certificate = Revocation List (CRL) Profile". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5997 = >=20 > -------------------------------------- > Type: Technical > Reported by: Ryan Sleevi > >=20 > Section: 4.2.1.10 >=20 > Original Text > ------------- > DNS name restrictions are expressed as host.example.com = . Any DNS > name that can be constructed by simply adding zero or more labels to > the left-hand side of the name satisfies the name constraint. =20 >=20 > Corrected Text > -------------- > The syntax of dNSName MUST be as described in Section 4.2.1.6. Any = DNS > name that can be constructed by simply adding zero or more labels to > the left-hand side of the name satisfies the name constraint. =20 >=20 > Notes > ----- > Currently, the syntax for a dNSName nameConstraint is left implicit, = and thus has resulted in ambiguities in encoding and processing that = have resulted in ineroperability issues. >=20 > One interpretation is that the dNSName nameConstraint must be a valid = "host name" (as discussed in RFC 8499), which is to say must be a = Fully-Qualified Domain Name in the preferred name syntax. This = interpretation is supported by Section 4.2.1.6, which explicitly states = that for the subjectAltName. As 4.2.1.10 does not define an exception to = this (as discussed in Appendix B), the interpretation, along with the = existing example, would conclude that this field uses preferred name = syntax, and that "DNS name" here matches the "host name" interpretation = from RFC 8499 >=20 > A different interpretation is that the dNSName nameConstraint uses the = modified syntax similar to the URI nameConstraint. That is, it = explicitly permits a leading period to indicate that one or more labels = preceding is required in order to satisfy the constraint. This allows = subdomains, but does not allow the base domain to match. While the = language for the DNS name constraint makes it clear that a host name = with no preceding period matches both that host and sub-domains, the = existence of a preceding period would constraint it to only subdomains. >=20 > Aligning with Section 4.2.1.6 would prohibit the latter = interpretation, as the preferred name syntax does not permit leading = periods. Alternatively, if the latter interpretation is intended, this = section would benefit from making that explicit. >=20 > This has been a source of interoperability issues, with additional = information and discussion captured at: > - https://github.com/golang/go/issues/16347 = > - https://rt.openssl.org/Ticket/Display.html?id=3D3562 = >=20 > While "running code" has aligned in being permissive with a leading = period, implementations have gone and seemingly aligned on a third = interpretation: >=20 > The syntax of a dNSName MUST be as described in Section 4.2.1.6, with = the exception that it MAY contain a leading period. Any DNS name that = can be constructed by simply adding zero or more labels to the left-hand = side of the name, ignoring any leading period, satisfies the name = constraint. >=20 > This seems to support implementations expecting the first = interpretation in the certificates they receive, and seeing leading = period as an encoding mistake, not an explicit desire for the second = interpretation. >=20 > 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 =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5280 (draft-ietf-pkix-rfc3280bis-11) > -------------------------------------- > Title : Internet X.509 Public Key Infrastructure = Certificate and Certificate Revocation List (CRL) Profile > Publication Date : May 2008 > Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, = R. Housley, W. Polk > Category : PROPOSED STANDARD > Source : Public-Key Infrastructure (X.509) > Area : Security > Stream : IETF > Verifying Party : IESG > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --Apple-Mail=_F9835CB2-E008-47FC-BDB7-E03FF4934CB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Ryan:

I = see the point you are trying to make, but the exact substitution that = you propose breaks the sentence that follows.

OLD

   DNS name = restrictions are expressed as host.example.com.  Any DNS
 =  name that can be constructed by simply adding zero or more labels = to
   the left-hand side of the name = satisfies the name constraint.  For
  =  example, www.host.example.com would satisfy the constraint = but
   host1.example.com would not.

NEW

   For DNS = names, restrictions MUST use the dNSName syntax in
   Section 4.2.1.6.  Any DNS name that can be = constructed by simply
   adding zero or = more labels to the left-hand side of the name satisfies
   the name constraint.  For example, if the = constraint contains
   host.example.com, then = www.host.example.com would satisfy the
   constraint but host1.example.com would = not.

On Feb 28, 2020, at 1:03 PM, Ryan Sleevi = <ryan-ietf@sleevi.com> wrote:

I've heard word that this may not have gone out to the PKIX = list, but I did want to pass this along with LAMPS.

As both the current syntax and = semantics are ambiguous, judging by implementation behaviour, I'm = totally appreciative that the suggested change might be rejected or = might be held for a hypothetical document update in the = future.

However,= I did want to bring to broader attention and document the fact that the = ambiguity has lead to different levels of guarantees. It was recently = pointed out to me that Apple adopted the "URI-like" syntax, as discussed = at https://cabforum.org/pipermail/servercert-wg/2020-February/0016= 76.html , while as mentioned in the Errata, Go and OpenSSL seem = to have adopted the "PEBKAC" syntax of assuming it's an encoding = error.

Within = the Web PKI, tools like Amazon's certlint treats this as an error, while = tools like ZLint inherit Golang's permissiveness. As a consequence, = unless the CA applies both checks (which is strongly recommended, due to = certlint attempting to compile the ASN.1 modules to offer stricter = validation), it's possible that such certificates might continue to = proliferate. As discussed within the linked Golang issue, there's = unfortunately a number of documentation examples that use the leading = period example, and so RFC 5280 CAs that don't participate exclusively = in the Web PKI are even more at risk of the varying = interpretations.

---------- = Forwarded message ---------
From: RFC Errata System <rfc-editor@rfc-editor.org>
Date: = Thu, Feb 27, 2020 at 5:54 PM
Subject: [Technical Errata = Reported] RFC5280 (5997)
To: <david.cooper@nist.gov>, <stefans@microsoft.com>, <stephen.farrell@cs.tcd.ie>, <sharon.boeyen@entrust.com>, <housley@vigilsec.com>, <wpolk@nist.gov>, = <rdd@cert.org>, = <kaduk@mit.edu>, = <kent@bbn.com>, = <stefan@aaa-sec.com>
Cc: <ryan-pkix@sleevi.com>, <pkix@ietf.org>, <rfc-editor@rfc-editor.org>


The following errata report has been submitted = for RFC5280,
"Internet X.509 Public Key Infrastructure Certificate and Certificate = Revocation List (CRL) Profile".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5997

--------------------------------------
Type: Technical
Reported by: Ryan Sleevi <ryan-pkix@sleevi.com>

Section: 4.2.1.10

Original Text
-------------
DNS name restrictions are expressed as host.example.com.  Any DNS
name that can be constructed by simply adding zero or more labels to
the left-hand side of the name satisfies the name constraint. 

Corrected Text
--------------
The syntax of dNSName MUST be as described in Section 4.2.1.6.  Any = DNS
name that can be constructed by simply adding zero or more labels to
the left-hand side of the name satisfies the name constraint. 

Notes
-----
Currently, the syntax for a dNSName nameConstraint is left implicit, and = thus has resulted in ambiguities in encoding and processing that have = resulted in ineroperability issues.

One interpretation is that the dNSName nameConstraint must be a valid = "host name" (as discussed in RFC 8499), which is to say must be a = Fully-Qualified Domain Name in the preferred name syntax. This = interpretation is supported by Section 4.2.1.6, which explicitly states = that for the subjectAltName. As 4.2.1.10 does not define an exception to = this (as discussed in Appendix B), the interpretation, along with the = existing example, would conclude that this field uses preferred name = syntax, and that "DNS name" here matches the "host name" interpretation = from RFC 8499

A different interpretation is that the dNSName nameConstraint uses the = modified syntax similar to the URI nameConstraint. That is, it = explicitly permits a leading period to indicate that one or more labels = preceding is required in order to satisfy the constraint. This allows = subdomains, but does not allow the base domain to match. While the = language for the DNS name constraint makes it clear that a host name = with no preceding period matches both that host and sub-domains, the = existence of a preceding period would constraint it to only = subdomains.

Aligning with Section 4.2.1.6 would prohibit the latter interpretation, = as the preferred name syntax does not permit leading periods. = Alternatively, if the latter interpretation is intended, this section = would benefit from making that explicit.

This has been a source of interoperability issues, with additional = information and discussion captured at:
- https://github.com/golang/go/issues/16347
- https://rt.openssl.org/Ticket/Display.html?id=3D3562

While "running code" has aligned in being permissive with a leading = period, implementations have gone and seemingly aligned on a third = interpretation:

The syntax of a dNSName MUST be as described in Section 4.2.1.6, with = the exception that it MAY contain a leading period. Any DNS name that = can be constructed by simply adding zero or more labels to the left-hand = side of the name, ignoring any leading period, satisfies the name = constraint.

This seems to support implementations expecting the first interpretation = in the certificates they receive, and seeing leading period as an = encoding mistake, not an explicit desire for the second = interpretation.

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.

--------------------------------------
RFC5280 (draft-ietf-pkix-rfc3280bis-11)
--------------------------------------
Title               : Internet = X.509 Public Key Infrastructure Certificate and Certificate Revocation = List (CRL) Profile
Publication Date    : May 2008
Author(s)           : D. Cooper, S. = Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk
Category            : PROPOSED STANDARD
Source              : Public-Key = Infrastructure (X.509)
Area                : = Security
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
Spasm = mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

= --Apple-Mail=_F9835CB2-E008-47FC-BDB7-E03FF4934CB7-- From nobody Fri Feb 28 10:52:44 2020 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 24CBB3A0043; Fri, 28 Feb 2020 10:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 whVB5nkpT78f; Fri, 28 Feb 2020 10:52:21 -0800 (PST) Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) (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 AF46D3A00B0; Fri, 28 Feb 2020 10:52:20 -0800 (PST) Received: by mail-ed1-f53.google.com with SMTP id c26so4515041eds.8; Fri, 28 Feb 2020 10:52:20 -0800 (PST) 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=MSNSRKjoyzTGtYvz6dR00ka9cPyfK0J09Wis2MJ9kWs=; b=CLdp+RPNnOVC1+HwhIdaQ2XBb0Dofhp8CxTN/4L5cfVfaydzP+zmXMu2fdRgOiOK5D 9WbQlqgOSxVGUnA3Pg7suofdBZ4djke3LmEvPnClNRAGzK03wsSvqQX4b8OMYXDeXZMw 6CArSU68YcgFLngtt9CDBr+pNjmZpunluracPJnVKelq2maiduQWYeR2oNeNqOzNZXkC 4ARmOKl+BZ7ZYvCNarqWNIXx6OuSxE4zRrDeuqkSR2aT2dz9m6FPEhhd/2Yby73ZWfKE ynDlzK5g3PdwRwVGQAUMEwJgfp3n92YQqOo6j6sFK0sSfiZWyOnaH2aK4JS33QIFmc6n PhuQ== X-Gm-Message-State: APjAAAXxXyu1F1wwiQnBk7Dc15kdf24ROBi59EGn213CW5MfeHqucTrL kifHVjHakDw3BCFFsCcVY9rSiCsR X-Google-Smtp-Source: APXvYqwQACk205jC2PjdFHqq1VF6wrllY+HeGNlJSmVii5WT1565HQfPkGBjcGCaj7JmObmtPI/K7A== X-Received: by 2002:a17:906:6d03:: with SMTP id m3mr5148247ejr.39.1582915938737; Fri, 28 Feb 2020 10:52:18 -0800 (PST) Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com. [209.85.128.54]) by smtp.gmail.com with ESMTPSA id l9sm115234ejg.42.2020.02.28.10.52.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Feb 2020 10:52:18 -0800 (PST) Received: by mail-wm1-f54.google.com with SMTP id m3so4383648wmi.0; Fri, 28 Feb 2020 10:52:18 -0800 (PST) X-Received: by 2002:a1c:9c4c:: with SMTP id f73mr5831973wme.125.1582915937880; Fri, 28 Feb 2020 10:52:17 -0800 (PST) MIME-Version: 1.0 References: <20200227225404.CA7ADF40714@rfc-editor.org> <48F9976F-C087-4695-BA63-8DAA730A4906@vigilsec.com> In-Reply-To: <48F9976F-C087-4695-BA63-8DAA730A4906@vigilsec.com> From: Ryan Sleevi Date: Fri, 28 Feb 2020 13:52:07 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Russ Housley Cc: SPASM , IETF PKIX Content-Type: multipart/alternative; boundary="0000000000002fcf12059fa75634" Archived-At: Subject: Re: [lamps] Fwd: [Technical Errata Reported] RFC5280 (5997) 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: Fri, 28 Feb 2020 18:52:25 -0000 --0000000000002fcf12059fa75634 Content-Type: text/plain; charset="UTF-8" Thanks. You're absolutely right, that was an oversight on my part. I think the higher-order question is what the syntax is "meant" to be, as the use of an illustrative example alone has lead to confusion. Even if a future revision retroactively 'blesses' ".example.com" as an ambiguity within 5280, the semantics of that are also ambiguous. On Fri, Feb 28, 2020 at 1:39 PM Russ Housley wrote: > Ryan: > > I see the point you are trying to make, but the exact substitution that > you propose breaks the sentence that follows. > > OLD > > DNS name restrictions are expressed as host.example.com. Any DNS > name that can be constructed by simply adding zero or more labels to > the left-hand side of the name satisfies the name constraint. For > example, www.host.example.com would satisfy the constraint but > host1.example.com would not. > > NEW > > For DNS names, restrictions MUST use the dNSName syntax in > Section 4.2.1.6. Any DNS name that can be constructed by simply > adding zero or more labels to the left-hand side of the name satisfies > the name constraint. For example, if the constraint contains > host.example.com, then www.host.example.com would satisfy the > constraint but host1.example.com would not. > > On Feb 28, 2020, at 1:03 PM, Ryan Sleevi wrote: > > I've heard word that this may not have gone out to the PKIX list, but I > did want to pass this along with LAMPS. > > As both the current syntax and semantics are ambiguous, judging by > implementation behaviour, I'm totally appreciative that the suggested > change might be rejected or might be held for a hypothetical document > update in the future. > > However, I did want to bring to broader attention and document the fact > that the ambiguity has lead to different levels of guarantees. It was > recently pointed out to me that Apple adopted the "URI-like" syntax, as > discussed at > https://cabforum.org/pipermail/servercert-wg/2020-February/001676.html , > while as mentioned in the Errata, Go and OpenSSL seem to have adopted the > "PEBKAC" syntax of assuming it's an encoding error. > > Within the Web PKI, tools like Amazon's certlint treats this as an error, > while tools like ZLint inherit Golang's permissiveness. As a consequence, > unless the CA applies both checks (which is strongly recommended, due to > certlint attempting to compile the ASN.1 modules to offer stricter > validation), it's possible that such certificates might continue to > proliferate. As discussed within the linked Golang issue, there's > unfortunately a number of documentation examples that use the leading > period example, and so RFC 5280 CAs that don't participate exclusively in > the Web PKI are even more at risk of the varying interpretations. > > ---------- Forwarded message --------- > From: RFC Errata System > Date: Thu, Feb 27, 2020 at 5:54 PM > Subject: [Technical Errata Reported] RFC5280 (5997) > To: , , < > stephen.farrell@cs.tcd.ie>, , < > housley@vigilsec.com>, , , , > , > Cc: , , > > > The following errata report has been submitted for RFC5280, > "Internet X.509 Public Key Infrastructure Certificate and Certificate > Revocation List (CRL) Profile". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5997 > > -------------------------------------- > Type: Technical > Reported by: Ryan Sleevi > > Section: 4.2.1.10 > > Original Text > ------------- > DNS name restrictions are expressed as host.example.com. Any DNS > name that can be constructed by simply adding zero or more labels to > the left-hand side of the name satisfies the name constraint. > > Corrected Text > -------------- > The syntax of dNSName MUST be as described in Section 4.2.1.6. Any DNS > name that can be constructed by simply adding zero or more labels to > the left-hand side of the name satisfies the name constraint. > > Notes > ----- > Currently, the syntax for a dNSName nameConstraint is left implicit, and > thus has resulted in ambiguities in encoding and processing that have > resulted in ineroperability issues. > > One interpretation is that the dNSName nameConstraint must be a valid > "host name" (as discussed in RFC 8499), which is to say must be a > Fully-Qualified Domain Name in the preferred name syntax. This > interpretation is supported by Section 4.2.1.6, which explicitly states > that for the subjectAltName. As 4.2.1.10 does not define an exception to > this (as discussed in Appendix B), the interpretation, along with the > existing example, would conclude that this field uses preferred name > syntax, and that "DNS name" here matches the "host name" interpretation > from RFC 8499 > > A different interpretation is that the dNSName nameConstraint uses the > modified syntax similar to the URI nameConstraint. That is, it explicitly > permits a leading period to indicate that one or more labels preceding is > required in order to satisfy the constraint. This allows subdomains, but > does not allow the base domain to match. While the language for the DNS > name constraint makes it clear that a host name with no preceding period > matches both that host and sub-domains, the existence of a preceding period > would constraint it to only subdomains. > > Aligning with Section 4.2.1.6 would prohibit the latter interpretation, as > the preferred name syntax does not permit leading periods. Alternatively, > if the latter interpretation is intended, this section would benefit from > making that explicit. > > This has been a source of interoperability issues, with additional > information and discussion captured at: > - https://github.com/golang/go/issues/16347 > - https://rt.openssl.org/Ticket/Display.html?id=3562 > > While "running code" has aligned in being permissive with a leading > period, implementations have gone and seemingly aligned on a third > interpretation: > > The syntax of a dNSName MUST be as described in Section 4.2.1.6, with the > exception that it MAY contain a leading period. Any DNS name that can be > constructed by simply adding zero or more labels to the left-hand side of > the name, ignoring any leading period, satisfies the name constraint. > > This seems to support implementations expecting the first interpretation > in the certificates they receive, and seeing leading period as an encoding > mistake, not an explicit desire for the second interpretation. > > 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. > > -------------------------------------- > RFC5280 (draft-ietf-pkix-rfc3280bis-11) > -------------------------------------- > Title : Internet X.509 Public Key Infrastructure Certificate > and Certificate Revocation List (CRL) Profile > Publication Date : May 2008 > Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. > Housley, W. Polk > Category : PROPOSED STANDARD > Source : Public-Key Infrastructure (X.509) > Area : Security > Stream : IETF > Verifying Party : IESG > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > > --0000000000002fcf12059fa75634 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks. You're absolutely right, that was an over= sight on my part.

I think the higher-order questio= n is what the syntax is "meant" to be, as the use of an illustrat= ive example alone has lead to confusion. Even if a future revision retroact= ively 'blesses' ".example.com" as an ambiguity within 5280, the semantics of that are also ambigu= ous.

On Fri, Feb 28, 2020 at 1:39 PM Russ Housley <housley@vigilsec.com> wrote:
Ryan:

I see the point you are trying to make, but t= he exact substitution that you propose breaks the sentence that follows.

OLD

=C2=A0 =C2=A0DNS n= ame restrictions are expressed as host.example.com.=C2=A0 Any DNS
=C2=A0 =C2=A0nam= e that can be constructed by simply adding zero or more labels to
=C2=A0 =C2=A0the left-hand side of the name satisfies the name constraint.= =C2=A0 For
=C2=A0 =C2=A0example, www.host.example.com would satisfy the constr= aint but
=C2=A0 =C2=A0host1.example.com would not.

NEW

=C2=A0 =C2=A0For DNS names, restrictions MUST = use the dNSName syntax in
=C2=A0 =C2=A0Section 4.2.1.6.=C2=A0 Any= DNS name that can be constructed by simply
=C2=A0 =C2=A0adding z= ero or more labels to the left-hand side of the name satisfies
= =C2=A0 =C2=A0the name constraint.=C2=A0 For example, if the constraint cont= ains
=C2=A0 =C2=A0host.example.com, then www.host.example.com would satisfy the
=C2= =A0 =C2=A0constraint but host1.example.com would not.

On Feb 28, 2020, at 1:03 PM, Ryan Sleevi <ryan-ietf@sleevi.com> wro= te:

I've heard word that this may not ha= ve gone out to the PKIX list, but I did want to pass this along with LAMPS.=

As both the current syntax and semantics are ambiguous,= judging by implementation behaviour, I'm totally appreciative that the= suggested change might be rejected or might be held for a hypothetical doc= ument update in the future.

However, I did want to= bring to broader attention and document the fact that the ambiguity has le= ad to different levels of guarantees. It was recently pointed out to me tha= t Apple adopted the "URI-like" syntax, as discussed at=C2=A0https://cabforum.org/pipermail/servercert-wg/2020-Febr= uary/001676.html=C2=A0, while as mentioned in the Errata, Go and OpenSS= L seem to have adopted the "PEBKAC" syntax of assuming it's a= n encoding error.

Within the Web PKI, tools like A= mazon's certlint treats this as an error, while tools like ZLint inheri= t Golang's permissiveness. As a consequence, unless the CA applies both= checks (which is strongly recommended, due to certlint attempting to compi= le the ASN.1 modules to offer stricter validation), it's possible that = such certificates might continue to proliferate. As discussed within the li= nked Golang issue, there's unfortunately a number of documentation exam= ples that use the leading period example, and so RFC 5280 CAs that don'= t participate exclusively in the Web PKI are even more at risk of the varyi= ng interpretations.

---------- Forwarded message ---------
From: RFC Errata System <rfc-editor@rfc-editor.org>
Date: Thu, Feb 27, 2020= at 5:54 PM
Subject: [Technical Errata Reported] RFC5280 (5997)
To: = <david.cooper= @nist.gov>, <stefans@microsoft.com>, <stephen.farrell@cs.tcd.ie>, <sharon.boeyen@e= ntrust.com>, <housley@vigilsec.com>, <wpolk@nist.gov>, <rdd@cert.org>, <kaduk@mit.edu>, <kent@bbn.com>, <stefan@aaa-sec.com>
Cc: &l= t;ryan-pkix@sleev= i.com>, <pkix= @ietf.org>, <rfc-editor@rfc-editor.org>


The followin= g errata report has been submitted for RFC5280,
"Internet X.509 Public Key Infrastructure Certificate and Certificate = Revocation List (CRL) Profile".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5997

--------------------------------------
Type: Technical
Reported by: Ryan Sleevi <ryan-pkix@sleevi.com>

Section: 4.2.1.10

Original Text
-------------
DNS name restrictions are expressed as host.example.com.=C2=A0 Any DNS name that can be constructed by simply adding zero or more labels to
the left-hand side of the name satisfies the name constraint.=C2=A0

Corrected Text
--------------
The syntax of dNSName MUST be as described in Section 4.2.1.6.=C2=A0 Any DN= S
name that can be constructed by simply adding zero or more labels to
the left-hand side of the name satisfies the name constraint.=C2=A0

Notes
-----
Currently, the syntax for a dNSName nameConstraint is left implicit, and th= us has resulted in ambiguities in encoding and processing that have resulte= d in ineroperability issues.

One interpretation is that the dNSName nameConstraint must be a valid "= ;host name" (as discussed in RFC 8499), which is to say must be a Full= y-Qualified Domain Name in the preferred name syntax. This interpretation i= s supported by Section 4.2.1.6, which explicitly states that for the subjec= tAltName. As 4.2.1.10 does not define an exception to this (as discussed in= Appendix B), the interpretation, along with the existing example, would co= nclude that this field uses preferred name syntax, and that "DNS name&= quot; here matches the "host name" interpretation from RFC 8499
A different interpretation is that the dNSName nameConstraint uses the modi= fied syntax similar to the URI nameConstraint. That is, it explicitly permi= ts a leading period to indicate that one or more labels preceding is requir= ed in order to satisfy the constraint. This allows subdomains, but does not= allow the base domain to match. While the language for the DNS name constr= aint makes it clear that a host name with no preceding period matches both = that host and sub-domains, the existence of a preceding period would constr= aint it to only subdomains.

Aligning with Section 4.2.1.6 would prohibit the latter interpretation, as = the preferred name syntax does not permit leading periods. Alternatively, i= f the latter interpretation is intended, this section would benefit from ma= king that explicit.

This has been a source of interoperability issues, with additional informat= ion and discussion captured at:
- https://github.com/golang/go/issues/16347
- https://rt.openssl.org/Ticket/Display.html?id= =3D3562

While "running code" has aligned in being permissive with a leadi= ng period, implementations have gone and seemingly aligned on a third inter= pretation:

The syntax of a dNSName MUST be as described in Section 4.2.1.6, with the e= xception that it MAY contain a leading period. Any DNS name that can be con= structed by simply adding zero or more labels to the left-hand side of the = name, ignoring any leading period, satisfies the name constraint.

This seems to support implementations expecting the first interpretation in= the certificates they receive, and seeing leading period as an encoding mi= stake, not an explicit desire for the second interpretation.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party=C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC5280 (draft-ietf-pkix-rfc3280bis-11)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Internet X.50= 9 Public Key Infrastructure Certificate and Certificate Revocation List (CR= L) Profile
Publication Date=C2=A0 =C2=A0 : May 2008
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: D. Cooper, S. Santesson= , S. Farrell, S. Boeyen, R. Housley, W. Polk
Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Public-Key Infrast= ructure (X.509)
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
_______________________________________________
Spasm mailing list
Spasm@ietf.org
http= s://www.ietf.org/mailman/listinfo/spasm
--0000000000002fcf12059fa75634-- From nobody Fri Feb 28 11:20:33 2020 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 742B63A0B05; Fri, 28 Feb 2020 11:20:31 -0800 (PST) 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.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <158291763133.22419.11883722130207594053@ietfa.amsl.com> Date: Fri, 28 Feb 2020 11:20:31 -0800 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-5480-ku-clarifications-02.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: Fri, 28 Feb 2020 19:20:32 -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 : Clarifications for Elliptic Curve Cryptogtaphy Subject Public Key Information Authors : Tadahiko Ito Sean Turner Filename : draft-ietf-lamps-5480-ku-clarifications-02.txt Pages : 3 Date : 2020-02-28 Abstract: This document updates RFC 5480 to specify semantics for the keyEncipherment and dataEncipherment key usage bits when used in certificates that support Elliptic Curve Cryptography. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-5480-ku-clarifications-02 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-5480-ku-clarifications-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-5480-ku-clarifications-02 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 Fri Feb 28 11:21:39 2020 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 36F8F3A0964 for ; Fri, 28 Feb 2020 11:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=sn3rd.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 Cvd5GOpVeYxX for ; Fri, 28 Feb 2020 11:21:34 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 8BB103A02C1 for ; Fri, 28 Feb 2020 11:21:34 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id m9so4087659qke.4 for ; Fri, 28 Feb 2020 11:21:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=MznQV6UhDkno/MrjsQPsvKKxorF4Vm2B/xUgfQGMGIc=; b=g0BMx+IQ5+LE1K2DTkagUrxSG3yLIoEZTUdu2IoAFAfrSV83N/o6yH8A2NVaI0y91/ pkbDUmicJZN6oXwpSiaEFqNVUlam+9jKuFDfrIYO2i5AQ2mmmaBZ01ee/XDQSExbKkAV UkIr4J+yoJYUAyhbXvKBsXc7lOnoNroYAHyRE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=MznQV6UhDkno/MrjsQPsvKKxorF4Vm2B/xUgfQGMGIc=; b=fEH9JySSycvEG9oHQgdSMkJZ02akDJxySrKjDqHmKjcmlvzp2+sCbSGbSARL/LP4Sm KronSXs8QqAQ/Enobm9ZkAkm2Mga4mKv2U4v1Gg2Loh+UosVBGZMYxEfz3xYegmFyUeB 09RnmUbvm9AQdv34/0eQSYWmdQD0a/wWQYiavEuJsFhijN7F0Uq+y6JVoTErZ/9qoAXe Fv1QjEk+Ypmg2rAiQNcdgNz1ga4x4gcpbprTk6SqWGR3L7AAYJ0i5DzvaqjDwQncAMIf /QQ6vTSL8trpSdrs0yDN84e119Hcqh+sFLJ/U0c7OXaKtw8/fG8hHQqyTJ9PKjxCJjKg ZDwQ== X-Gm-Message-State: APjAAAU7PEB6WNJyRG0aIudi39zFqwzr/O29QcOuZRMbo3byWsPtMhYf hldGYXsz5BXX/TvQYUe6tgtGun7l9yo= X-Google-Smtp-Source: APXvYqzIIguEHlEonqMQQBbUpQFZ8bepsvpn143Zy8KMVLTbeic8fhL0gcQht5Q+foydR6RoPUaE5A== X-Received: by 2002:a37:7f03:: with SMTP id a3mr5894494qkd.121.1582917693562; Fri, 28 Feb 2020 11:21:33 -0800 (PST) Received: from [5.5.33.216] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id o127sm5669263qke.92.2020.02.28.11.21.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Feb 2020 11:21:33 -0800 (PST) From: Sean Turner 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: Fri, 28 Feb 2020 14:21:32 -0500 References: <158291763133.22419.11883722130207594053@ietfa.amsl.com> To: LAMPS WG In-Reply-To: <158291763133.22419.11883722130207594053@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-5480-ku-clarifications-02.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: Fri, 28 Feb 2020 19:21:37 -0000 This version addresses opsdir and some IESG comments. spt > On Feb 28, 2020, at 14:20, 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 : Clarifications for Elliptic Curve = Cryptogtaphy Subject Public Key Information > Authors : Tadahiko Ito > Sean Turner > Filename : draft-ietf-lamps-5480-ku-clarifications-02.txt > Pages : 3 > Date : 2020-02-28 >=20 > Abstract: > This document updates RFC 5480 to specify semantics for the > keyEncipherment and dataEncipherment key usage bits when used in > certificates that support Elliptic Curve Cryptography. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lamps-5480-ku-clarifications-02 > = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-5480-ku-clarificati= ons-02 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-5480-ku-clarification= s-02 >=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/ >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Fri Feb 28 11:32:31 2020 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 EF3183A19C3 for ; Fri, 28 Feb 2020 11:32:28 -0800 (PST) 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, 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 WKJ2t262IKdq for ; Fri, 28 Feb 2020 11:32:27 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2853A19A9 for ; Fri, 28 Feb 2020 11:32:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0099A300B17 for ; Fri, 28 Feb 2020 14:32:24 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Xoqp8GvhKcG2 for ; Fri, 28 Feb 2020 14:32:23 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 9A5763002A9; Fri, 28 Feb 2020 14:32:23 -0500 (EST) 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: Date: Fri, 28 Feb 2020 14:32:24 -0500 Cc: LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: <2B2C07BF-B658-4C4B-ACDB-9779ACFF0D15@vigilsec.com> References: <158291763133.22419.11883722130207594053@ietfa.amsl.com> To: Sean Turner X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-5480-ku-clarifications-02.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: Fri, 28 Feb 2020 19:32:29 -0000 Sean: Since the new text is being added to the end of section 3 of RFC 5480, = why have two separate paragraphs? Wouldn't this do the job? If the keyUsage extension is present in a certificate that indicates id-ecPublicKey, id-ecDH, or id-ecMQV in SubjectPublicKeyInfo, then the following values MUST NOT be present: keyEncipherment; and dataEncipherment. Russ > On Feb 28, 2020, at 2:21 PM, Sean Turner wrote: >=20 > This version addresses opsdir and some IESG comments. >=20 > spt >=20 >> On Feb 28, 2020, at 14:20, 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 : Clarifications for Elliptic Curve = Cryptogtaphy Subject Public Key Information >> Authors : Tadahiko Ito >> Sean Turner >> Filename : draft-ietf-lamps-5480-ku-clarifications-02.txt >> Pages : 3 >> Date : 2020-02-28 >>=20 >> Abstract: >> This document updates RFC 5480 to specify semantics for the >> keyEncipherment and dataEncipherment key usage bits when used in >> certificates that support Elliptic Curve Cryptography. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/ >>=20 >> There are also htmlized versions available at: >> = https://tools.ietf.org/html/draft-ietf-lamps-5480-ku-clarifications-02 >> = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-5480-ku-clarificati= ons-02 >>=20 >> A diff from the previous version is available at: >> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-5480-ku-clarification= s-02 >>=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/ >>=20 >>=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 Fri Feb 28 12:01:30 2020 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 2AB5F3A1D26 for ; Fri, 28 Feb 2020 12:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=sn3rd.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 ZgaQQde3mJXp for ; Fri, 28 Feb 2020 12:01:22 -0800 (PST) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 8C1DD3A1D69 for ; Fri, 28 Feb 2020 12:01:22 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id r5so2953987qtt.9 for ; Fri, 28 Feb 2020 12:01:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=STqC6pbnziQxUAnpvxkyaT0Wt6qgc/9m7MTStTvac1A=; b=fzv6uIPZ2o/RVSEx9BkxyfjU+0zsKkCnNhPAiTzMBNGi+EMZ6e21p10YaOjBOaziYj i5zQb/mLg+Y9Cc/Js8ncBXeo0PgQOQzt46tLLi+fIvarBwOhUy6yuQBpvAYPmvEbb/AT id7GpcGHTb66hbc9kfkFbpX/YgXcNG87lOCqk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=STqC6pbnziQxUAnpvxkyaT0Wt6qgc/9m7MTStTvac1A=; b=k6mGGrtVCxwljS1BEHyvxCjE+n9CJSo3SPARheXo9EtqfmhYuJISvxEfoDrWMfgVOE 0k3YdtOd1EquiaX/vJh2hUJpt+9PG55FxPObTLD256/xr4frmXTUzBxtgWe8gnfbtnEI d9S7TsQZnI0JEeO1zXCgnn4uCT83be8UcNUbt3XOSoF6erDHdPnSiU4J2uHbelJQURel lU7KmT3Y/8CX1Sr/+OmJZcwFgccu4LFLZDyjhH4Jf98ZnU17QvxQY/54y+N2UfaJGL5u H5o5Bw+X6wrKce7CO+nibu/7RcTN/nR0x64jlHgbf1hpfLpe5N8nE76zhlN0XaUw7tMy R2nQ== X-Gm-Message-State: APjAAAUOiK9dRrNrIR2Z7vE1Pr39A8MTEnx0k0uq03q9u11k+YwVUGQp nLtXXZ5ozyLiPfbHuL6mJenmrg0wEMU= X-Google-Smtp-Source: APXvYqyxitk5t2XDpGEHEEzpZn5vbUyS8dHhPqn5o7GHkBCdNEbbcFmlI1nr4DmqNsHbI313nlWEYw== X-Received: by 2002:ac8:7695:: with SMTP id g21mr5066262qtr.99.1582920081496; Fri, 28 Feb 2020 12:01:21 -0800 (PST) Received: from [5.5.33.228] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id x14sm5560619qkf.99.2020.02.28.12.01.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Feb 2020 12:01:21 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: <2B2C07BF-B658-4C4B-ACDB-9779ACFF0D15@vigilsec.com> Date: Fri, 28 Feb 2020 15:01:20 -0500 Cc: LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <158291763133.22419.11883722130207594053@ietfa.amsl.com> <2B2C07BF-B658-4C4B-ACDB-9779ACFF0D15@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-5480-ku-clarifications-02.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: Fri, 28 Feb 2020 20:01:29 -0000 That was also suggested by Dale Worley in his GENART review but we = suggested not combining them: https://mailarchive.ietf.org/arch/msg/spasm/NbeUttXn3SV5Q68s3tjVS86b1Rc/ spt > On Feb 28, 2020, at 14:32, Russ Housley wrote: >=20 > Sean: >=20 > Since the new text is being added to the end of section 3 of RFC 5480, = why have two separate paragraphs? >=20 > Wouldn't this do the job? >=20 > If the keyUsage extension is present in a certificate that indicates > id-ecPublicKey, id-ecDH, or id-ecMQV in SubjectPublicKeyInfo, then > the following values MUST NOT be present: >=20 > keyEncipherment; and > dataEncipherment. >=20 > Russ >=20 >=20 >> On Feb 28, 2020, at 2:21 PM, Sean Turner wrote: >>=20 >> This version addresses opsdir and some IESG comments. >>=20 >> spt >>=20 >>> On Feb 28, 2020, at 14:20, 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 : Clarifications for Elliptic Curve = Cryptogtaphy Subject Public Key Information >>> Authors : Tadahiko Ito >>> Sean Turner >>> Filename : draft-ietf-lamps-5480-ku-clarifications-02.txt >>> Pages : 3 >>> Date : 2020-02-28 >>>=20 >>> Abstract: >>> This document updates RFC 5480 to specify semantics for the >>> keyEncipherment and dataEncipherment key usage bits when used in >>> certificates that support Elliptic Curve Cryptography. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> = https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/ >>>=20 >>> There are also htmlized versions available at: >>> = https://tools.ietf.org/html/draft-ietf-lamps-5480-ku-clarifications-02 >>> = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-5480-ku-clarificati= ons-02 >>>=20 >>> A diff from the previous version is available at: >>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-5480-ku-clarification= s-02 >>>=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/ >>>=20 >>>=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 >=20 From nobody Fri Feb 28 12:09:59 2020 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 DDF983A1D2C for ; Fri, 28 Feb 2020 12:09:56 -0800 (PST) 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, 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 MWYkPbgjBJCp for ; Fri, 28 Feb 2020 12:09:54 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2D813A1D22 for ; Fri, 28 Feb 2020 12:09:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 00613300B17 for ; Fri, 28 Feb 2020 15:09:51 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id zeKTLr9axB8C for ; Fri, 28 Feb 2020 15:09:50 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id 17F783004C0; Fri, 28 Feb 2020 15:09:50 -0500 (EST) 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: Date: Fri, 28 Feb 2020 15:09:51 -0500 Cc: LAMPS WG Content-Transfer-Encoding: quoted-printable Message-Id: <2C454AFD-6A59-401F-B917-2D50CC334F61@vigilsec.com> References: <158291763133.22419.11883722130207594053@ietfa.amsl.com> <2B2C07BF-B658-4C4B-ACDB-9779ACFF0D15@vigilsec.com> To: Sean Turner X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-5480-ku-clarifications-02.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: Fri, 28 Feb 2020 20:09:57 -0000 Not merging make more sense if the paragraphs were being added in the = two places where there are already lists. i do not see the reason with = the current wording. Russ > On Feb 28, 2020, at 3:01 PM, Sean Turner wrote: >=20 > That was also suggested by Dale Worley in his GENART review but we = suggested not combining them: > = https://mailarchive.ietf.org/arch/msg/spasm/NbeUttXn3SV5Q68s3tjVS86b1Rc/ >=20 > spt >=20 >> On Feb 28, 2020, at 14:32, Russ Housley wrote: >>=20 >> Sean: >>=20 >> Since the new text is being added to the end of section 3 of RFC = 5480, why have two separate paragraphs? >>=20 >> Wouldn't this do the job? >>=20 >> If the keyUsage extension is present in a certificate that indicates >> id-ecPublicKey, id-ecDH, or id-ecMQV in SubjectPublicKeyInfo, then >> the following values MUST NOT be present: >>=20 >> keyEncipherment; and >> dataEncipherment. >>=20 >> Russ >>=20 >>=20 >>> On Feb 28, 2020, at 2:21 PM, Sean Turner wrote: >>>=20 >>> This version addresses opsdir and some IESG comments. >>>=20 >>> spt >>>=20 >>>> On Feb 28, 2020, at 14:20, 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 : Clarifications for Elliptic Curve = Cryptogtaphy Subject Public Key Information >>>> Authors : Tadahiko Ito >>>> Sean Turner >>>> Filename : draft-ietf-lamps-5480-ku-clarifications-02.txt >>>> Pages : 3 >>>> Date : 2020-02-28 >>>>=20 >>>> Abstract: >>>> This document updates RFC 5480 to specify semantics for the >>>> keyEncipherment and dataEncipherment key usage bits when used in >>>> certificates that support Elliptic Curve Cryptography. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> = https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/ >>>>=20 >>>> There are also htmlized versions available at: >>>> = https://tools.ietf.org/html/draft-ietf-lamps-5480-ku-clarifications-02 >>>> = https://datatracker.ietf.org/doc/html/draft-ietf-lamps-5480-ku-clarificati= ons-02 >>>>=20 >>>> A diff from the previous version is available at: >>>> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-5480-ku-clarification= s-02 >>>>=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/ >>>>=20 >>>>=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 >>=20 >=20 From nobody Fri Feb 28 14:36:20 2020 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 631DD3A1F78; Fri, 28 Feb 2020 14:35:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: spasm@ietf.org, rdd@cert.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158292930338.19931.1994508162247319088@ietfa.amsl.com> Date: Fri, 28 Feb 2020 14:35:03 -0800 Archived-At: Subject: [lamps] lamps - Requested session has been scheduled for IETF 107 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, 28 Feb 2020 22:35:11 -0000 Dear Russ Housley, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. lamps Session 1 (2:00 requested) Monday, 23 March 2020, Morning Session I 1000-1200 Room Name: Georgia B size: 150 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/lamps.ics Request Information: --------------------------------------------------------- Working Group Name: Limited Additional Mechanisms for PKIX and SMIME Area Name: Security Area Session Requester: Russ Housley Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 45 Conflicts to Avoid: Chair Conflict: suit stir ipwave Technology Overlap: acme cfrg ace Key Participant Conflict: oauth secdispatch saag sipbrandy tls mls teep People who must be present: Russ Housley Sean Turner Alexey Melnikov Roman Danyliw Bernie Hoeneisen Jim Schaad Tim Hollebeek Hendrik Brockhaus Resources Requested: Special Requests: ---------------------------------------------------------