From nobody Wed Mar 1 02:00:31 2017 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 72B64129955 for ; Wed, 1 Mar 2017 02:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ObgId7DIzB2 for ; Wed, 1 Mar 2017 02:00:28 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1F31298CA for ; Wed, 1 Mar 2017 02:00:28 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5FBA7C0467CE; Wed, 1 Mar 2017 10:00:28 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.156]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v21A0Oxb000445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Mar 2017 05:00:26 -0500 Message-ID: <1488362424.31660.6.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Phillip Hallam-Baker , Russ Housley Date: Wed, 01 Mar 2017 11:00:24 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 01 Mar 2017 10:00:28 +0000 (UTC) Archived-At: Cc: SPASM Subject: Re: [Spasm] Add SHA-3 to PKIX X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 01 Mar 2017 10:00:29 -0000 On Mon, 2017-02-27 at 18:07 -0500, Phillip Hallam-Baker wrote: > > In addition, the LAMPS Working Group may investigate other > > updates to > > > the documents produced by the PKIX and S/MIME Working Groups, but > > the > > > LAMPS Working Group shall not adopt any of these potential work > > items > > > without rechartering. No such re-chartering is envisaged until > > one or > > > more of the above work items have been successfully delivered to > > the RFC > > > editor queue. > > > > Since our first document is in IESG Evaluation and the other two > > are in WG Last Call, I would expect that this criteria will be met > > shortly. > > I agree about not wanting to document stuff that is not going to be > used. > > The point of this is to get a sounding from the parties that would be > doing the deployment in CABForum. To pass a ballot has to have a > majority of the Browsers and 2/3rd of the CAs. > > We can't hold a ballot on adding anything to the approved algorithms > until we have the RFC. But we can have a motion of intent to do so. I second that. Note also that I already have an implementation of SHA3 for PKIX certificates. regards, Nikos From nobody Wed Mar 1 07:32:31 2017 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 22357129570 for ; Wed, 1 Mar 2017 07:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 9R7JDoHkObvK for ; Wed, 1 Mar 2017 07:32:28 -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 C4BAD129580 for ; Wed, 1 Mar 2017 07:32:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0510F30049F for ; Wed, 1 Mar 2017 10:32:28 -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 lqVFlcECClxu for ; Wed, 1 Mar 2017 10:32:27 -0500 (EST) Received: from [192.168.2.107] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 0284D30024F; Wed, 1 Mar 2017 10:32:26 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Russ Housley In-Reply-To: <1488362424.31660.6.camel@redhat.com> Date: Wed, 1 Mar 2017 10:32:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1488362424.31660.6.camel@redhat.com> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.3259) Archived-At: Cc: SPASM Subject: Re: [Spasm] Add SHA-3 to PKIX X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 01 Mar 2017 15:32:30 -0000 > On Mar 1, 2017, at 5:00 AM, Nikos Mavrogiannopoulos = wrote: >=20 > On Mon, 2017-02-27 at 18:07 -0500, Phillip Hallam-Baker wrote: >>> In addition, the LAMPS Working Group may investigate other >>> updates to >>>> the documents produced by the PKIX and S/MIME Working Groups, but >>> the >>>> LAMPS Working Group shall not adopt any of these potential work >>> items >>>> without rechartering. No such re-chartering is envisaged until >>> one or >>>> more of the above work items have been successfully delivered to >>> the RFC >>>> editor queue. >>>=20 >>> Since our first document is in IESG Evaluation and the other two >>> are in WG Last Call, I would expect that this criteria will be met >>> shortly. >>=20 >> I agree about not wanting to document stuff that is not going to be >> used. >>=20 >> The point of this is to get a sounding from the parties that would be >> doing the deployment in CABForum. To pass a ballot has to have a >> majority of the Browsers and 2/3rd of the CAs. >>=20 >> We can't hold a ballot on adding anything to the approved algorithms >> until we have the RFC. But we can have a motion of intent to do so. >=20 > I second that. Note also that I already have an implementation of SHA3 > for PKIX certificates. Did you assign your own OIDs? Russ From nobody Wed Mar 1 07:54:48 2017 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 C58211294C0 for ; Wed, 1 Mar 2017 07:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgBUhoFZQmnu for ; Wed, 1 Mar 2017 07:54:45 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5A081295A2 for ; Wed, 1 Mar 2017 07:54:45 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx16.intmail.prod.int.phx2.redhat.com [10.5.11.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5CE643B74F; Wed, 1 Mar 2017 15:54:46 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com (unknown [10.40.3.156]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AA3F12D655; Wed, 1 Mar 2017 15:54:45 +0000 (UTC) Message-ID: <1488383684.31660.10.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Russ Housley Date: Wed, 01 Mar 2017 16:54:44 +0100 In-Reply-To: References: <1488362424.31660.6.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.74 on 10.5.11.28 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 01 Mar 2017 15:54:46 +0000 (UTC) Archived-At: Cc: SPASM Subject: Re: [Spasm] Add SHA-3 to PKIX X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 01 Mar 2017 15:54:47 -0000 On Wed, 2017-03-01 at 10:32 -0500, Russ Housley wrote: > > > I agree about not wanting to document stuff that is not going to > > > be > > > used. > > > > > > The point of this is to get a sounding from the parties that > > > would be > > > doing the deployment in CABForum. To pass a ballot has to have a > > > majority of the Browsers and 2/3rd of the CAs. > > > > > > We can't hold a ballot on adding anything to the approved > > > algorithms > > > until we have the RFC. But we can have a motion of intent to do > > > so. > > > > I second that. Note also that I already have an implementation of > > SHA3 > > for PKIX certificates. > Did you assign your own OIDs? I have used the NIST OIDs. regards, Nikos From nobody Wed Mar 1 17:52:57 2017 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 9008B129479; Wed, 1 Mar 2017 17:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLU1ch8BUknt; Wed, 1 Mar 2017 17:52:55 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ED031293F5; Wed, 1 Mar 2017 17:52:55 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BF7B0E20F; Wed, 1 Mar 2017 21:15:10 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5596F6381A; Wed, 1 Mar 2017 20:52:51 -0500 (EST) From: Michael Richardson To: SPASM In-Reply-To: <18454.1488305685@obiwan.sandelman.ca> References: <18454.1488305685@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: anima-bootstrap Subject: [Spasm] SHA1 usage in Anima-bootstrap voucher yang X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 02 Mar 2017 01:52:56 -0000 --=-=-= Content-Type: text/plain In the ANIMA ownership voucher YANG model, the absolute latest which you can currently see at: https://github.com/anima-wg/voucher/blob/master/draft-ietf-anima-voucher-01.txt we write at line 574: leaf subject-hash { type binary; description "The certificate's entire subject field MUST match this value. This value is calculated as the SHA-1 hash over the TBSCertificate's subject structure, as specified by RFC 5280 Section 4.1.2.6, encoded using the ASN.1 distinguished encoding rules (DER), as specified in ITU-T X.690. Note: by using the SHA-1 algorithm, the result can be easily compared to OpenSSL's 'subject_hash' output."; } The voucher is a signed artifact (PKCS7? JWT? CWT? TBD) which indicates to a particular device who the devices owner is. ("Are you my mummy?" for Dr.Who Fans) For reasons of key hygiene and longevity, in many cases we do not want to point at the public key of the registrar directly, but rather indicate that it's DN=Foo, as signed by CA=Bar. It seems like there ought be a better way to do this kind of thing than what we specify above, which is annoyingly SHA1 linked. Can SPASM offer any advice? We could list the actual DER itself. Encoded, it might actually not be bigger than a SHA256, for instance. That might have privacy implications though, which we'd need to think through. Some time ago, I proposed replicating the SIDR artifact (RFC3779), and copy and pasted it to make: https://www.ietf.org/archive/id/draft-richardson-anima-idevid-cert-00.txt but, we didn't really want to go exactly that way. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAli3evIACgkQgItw+93Q 3WVvoAf+O9mDTyPtXmu0kdFK+jKTQ7bOBu42B54CLP1h5z4q99nf3mpi5XvAG9s+ dWMLGKUe79bES0kQtsNeAdi9ugraCTimwEidZuwi+eCuYWnF1Gqh+xydOhCCqk3X vMdwxhtlfSOm0v5oCjOe1DyuHaGUTdpilFQTbSl8HUIEa3tT89tQLWlfBwAX4+vD KxJUgS6n/rsTcO5MRn0lZ1YkRSeXFKpARWGPtYL2/qWMGinakdZVjtUKSxzR8cTt XYPrrgDCkSh5lR+sz/a2yqjaubPn5FSesMGoRtRvm7AwDgM24STlFocSYbgh4iZR AXIYkH4JeKSbZz2zuEYidHZ09/Tncw== =ouYz -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 3 03:20:24 2017 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 2EE7E1294AD; Fri, 3 Mar 2017 03:20:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stewart Bryant To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148854001916.10113.3160004873362723901.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 03:20:19 -0800 Archived-At: Cc: spasm@ietf.org, ietf@ietf.org, draft-ietf-lamps-eai-addresses.all@ietf.org Subject: [Spasm] Review of draft-ietf-lamps-eai-addresses-06 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 03 Mar 2017 11:20:19 -0000 Reviewer: Stewart Bryant Review result: Ready 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 wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-lamps-eai-addresses-?? Reviewer: Stewart Bryant Review Date: 2017-03-03 IETF LC End Date: 2017-01-30 IESG Telechat date: 2017-03-16 Summary: Ready for Publication Major issues: None Minor issues: None Nits/editorial comments: None From nobody Fri Mar 3 12:43:19 2017 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 9B6FA1294ED for ; Fri, 3 Mar 2017 12:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=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 goWgbduTBCqq for ; Fri, 3 Mar 2017 12:43:12 -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 8310E129528 for ; Fri, 3 Mar 2017 12:43:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E0D9030024F for ; Fri, 3 Mar 2017 15:43:05 -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 j8zojWJsFIcn for ; Fri, 3 Mar 2017 15:43:04 -0500 (EST) Received: from new-host-5.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 85A8230024A; Fri, 3 Mar 2017 15:43:04 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Russ Housley In-Reply-To: <14573.1488419571@obiwan.sandelman.ca> Date: Fri, 3 Mar 2017 15:43:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8C184CD7-69EB-424B-9D95-1C64A8FD706F@vigilsec.com> References: <18454.1488305685@obiwan.sandelman.ca> <14573.1488419571@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3259) Archived-At: Cc: SPASM , anima-bootstrap Subject: Re: [Spasm] SHA1 usage in Anima-bootstrap voucher yang X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 03 Mar 2017 20:43:14 -0000 > On Mar 1, 2017, at 8:52 PM, Michael Richardson = wrote: >=20 >=20 > In the ANIMA ownership voucher YANG model, the absolute latest which = you can > currently see at: > = https://github.com/anima-wg/voucher/blob/master/draft-ietf-anima-voucher-0= 1.txt >=20 > we write at line 574: >=20 > leaf subject-hash { > type binary; > description "The certificate's entire subject field MUST > match this value. This value is calculated as the SHA-1 > hash over the TBSCertificate's subject structure, as > specified by RFC 5280 Section 4.1.2.6, encoded using > the ASN.1 distinguished encoding rules (DER), as > specified in ITU-T X.690. >=20 > Note: by using the SHA-1 algorithm, the result can be > easily compared to OpenSSL's 'subject_hash' > output."; > } >=20 > The voucher is a signed artifact (PKCS7? JWT? CWT? TBD) which = indicates to a > particular device who the devices owner is. ("Are you my mummy?" for = Dr.Who Fans) >=20 > For reasons of key hygiene and longevity, in many cases we do not want = to > point at the public key of the registrar directly, but rather indicate = that > it's DN=3DFoo, as signed by CA=3DBar. It seems like there ought be a = better way > to do this kind of thing than what we specify above, which is = annoyingly SHA1 > linked. >=20 > Can SPASM offer any advice? >=20 > We could list the actual DER itself. Encoded, it might actually not be = bigger > than a SHA256, for instance. That might have privacy implications = though, > which we'd need to think through. >=20 > Some time ago, I proposed replicating the SIDR artifact (RFC3779), and = copy > and pasted it to make: > = https://www.ietf.org/archive/id/draft-richardson-anima-idevid-cert-00.txt >=20 > but, we didn't really want to go exactly that way. Michael: I=E2=80=99m sure you know that there are three important properties for = hash functions. The are: (1) collision resistance: it is computationally infeasible to find two different inputs that hash to the same output; that is, it is really hard to find a and b such that H(a) =3D H(b). (2) preimage resistance: it is computationally infeasible to find any input that hashes to a given output; that is, given y, it is really hard to find x such that H(x) =3D y. (3) second-preimage resistance: it is computationally infeasible to find a second input which has the same output as a specified input; that is, given x, it is really hard to find y such that H(x) =3D H(y). Google has announced a collision for SHA-1. They found to PDF files that produce the same SHA-1 hash value. In the system you describe, it seems that an attacker would need to find a preimage. For SHA-1, we do not know of a way to do that yet, but the 160-bit have value produced by SHA-1 is probably not big enough to be considered safe in today's computing environment. It seems very odd to be developing a new standards that is using a hash function that was deprecated at the end of 2010 by NIST. My personal recommendation ould be to move from SHA-1 to SHA-256. Russ From nobody Fri Mar 3 13:06:32 2017 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 2C2B51295DC for ; Fri, 3 Mar 2017 13:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 m2gqg6NtRfBG for ; Fri, 3 Mar 2017 13:06:26 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 2624712951B for ; Fri, 3 Mar 2017 13:06:26 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id g129so13234128qkd.1 for ; Fri, 03 Mar 2017 13:06: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=9wMP5ewi2ekReV3h+o0QiWmht9Co9egHBX1z4v01OMw=; b=GK2UTPzEdNlKFbcKPInC55fA/9oouT7SwVxAYYOzzPSPcgMPVbTpyHJVx6Cp6JWA9J CrYSK/nFm5aI5vkJnecdtow5HM0fj6Kbz28/OCt06vpCaPBsNc7oMm86Odp0cv+5024n drGovciEOWEViAc1pEEX83n2aSrZeT/a8BGxs= 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=9wMP5ewi2ekReV3h+o0QiWmht9Co9egHBX1z4v01OMw=; b=lR9zb6QaeFzj/9qPgV47ZBh4PYxfLmdy4itDiGRvzM9qBo1bG4gei1BUnN0D5maCR4 j1bwyHgrKcD+hO4C3V/UTwgVNviAgMir94ETa2Zh3P6jSeo/CbMikNHEp0aEEaqYwLMq 8y6Gmt/D+DoiSeQnKF56eHNqd3s/AtwzeAQP4zf0fZVjz3bxD4XqWFt4xZ1vVwCo/cx/ 3vUJU3VWbYP8uCmPwwFwZ4axAWN8xcO8l4e+nxStEUeMslpYGsYzkmcuXI+mTVMjCQJ1 yOoapfrq7mURenNhSoydQEuCgtDf0gsBUU64BxNmPT0Dalgq0uje91iJE18lcv7p8WOu vWog== X-Gm-Message-State: AMke39liZ3jO2Oy50B7sPJZ8RSOn9Qd6OTkLy7CvV0EUXlvUKIvwqSeNY73kVW3N5RGpqw== X-Received: by 10.237.59.19 with SMTP id p19mr4840173qte.28.1488575184612; Fri, 03 Mar 2017 13:06:24 -0800 (PST) Received: from [172.16.0.92] ([96.231.228.203]) by smtp.gmail.com with ESMTPSA id r189sm8349723qkf.58.2017.03.03.13.06.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Mar 2017 13:06:23 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <8C184CD7-69EB-424B-9D95-1C64A8FD706F@vigilsec.com> Date: Fri, 3 Mar 2017 16:06:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <18454.1488305685@obiwan.sandelman.ca> <14573.1488419571@obiwan.sandelman.ca> <8C184CD7-69EB-424B-9D95-1C64A8FD706F@vigilsec.com> To: Michael Richardson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: SPASM , anima-bootstrap Subject: Re: [Spasm] SHA1 usage in Anima-bootstrap voucher yang X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 03 Mar 2017 21:06:28 -0000 > On Mar 3, 2017, at 15:43, Russ Housley wrote: >=20 >>=20 >> On Mar 1, 2017, at 8:52 PM, Michael Richardson = wrote: >>=20 >>=20 >> In the ANIMA ownership voucher YANG model, the absolute latest which = you can >> currently see at: >> = https://github.com/anima-wg/voucher/blob/master/draft-ietf-anima-voucher-0= 1.txt >>=20 >> we write at line 574: >>=20 >> leaf subject-hash { >> type binary; >> description "The certificate's entire subject field MUST >> match this value. This value is calculated as the SHA-1 >> hash over the TBSCertificate's subject structure, as >> specified by RFC 5280 Section 4.1.2.6, encoded using >> the ASN.1 distinguished encoding rules (DER), as >> specified in ITU-T X.690. >>=20 >> Note: by using the SHA-1 algorithm, the result can be >> easily compared to OpenSSL's 'subject_hash' >> output."; >> } >>=20 >> The voucher is a signed artifact (PKCS7? JWT? CWT? TBD) which = indicates to a >> particular device who the devices owner is. ("Are you my mummy?" for = Dr.Who Fans) >>=20 >> For reasons of key hygiene and longevity, in many cases we do not = want to >> point at the public key of the registrar directly, but rather = indicate that >> it's DN=3DFoo, as signed by CA=3DBar. It seems like there ought be = a better way >> to do this kind of thing than what we specify above, which is = annoyingly SHA1 >> linked. >>=20 >> Can SPASM offer any advice? >>=20 >> We could list the actual DER itself. Encoded, it might actually not = be bigger >> than a SHA256, for instance. That might have privacy implications = though, >> which we'd need to think through. >>=20 >> Some time ago, I proposed replicating the SIDR artifact (RFC3779), = and copy >> and pasted it to make: >> = https://www.ietf.org/archive/id/draft-richardson-anima-idevid-cert-00.txt >>=20 >> but, we didn't really want to go exactly that way. >=20 > Michael: >=20 > I=E2=80=99m sure you know that there are three important properties = for hash > functions. The are: >=20 > (1) collision resistance: it is computationally infeasible to find two > different inputs that hash to the same output; that is, it is = really > hard to find a and b such that H(a) =3D H(b). >=20 > (2) preimage resistance: it is computationally infeasible to find any > input that hashes to a given output; that is, given y, it is really > hard to find x such that H(x) =3D y. >=20 > (3) second-preimage resistance: it is computationally infeasible to = find > a second input which has the same output as a specified input; that > is, given x, it is really hard to find y such that H(x) =3D H(y). >=20 > Google has announced a collision for SHA-1. They found to PDF files > that produce the same SHA-1 hash value. >=20 > In the system you describe, it seems that an attacker would need to > find a preimage. For SHA-1, we do not know of a way to do that yet, > but the 160-bit have value produced by SHA-1 is probably not big = enough > to be considered safe in today's computing environment. >=20 > It seems very odd to be developing a new standards that is using a = hash > function that was deprecated at the end of 2010 by NIST. >=20 > My personal recommendation ould be to move from SHA-1 to SHA-256. >=20 > Russ >=20 And, there=E2=80=99s an RFC for that (TM) :) https://datatracker.ietf.org/doc/rfc7093/ spt= From nobody Fri Mar 3 14:52:01 2017 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 E206B12965B; Fri, 3 Mar 2017 14:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7tWIdKX2Ne7; Fri, 3 Mar 2017 14:51:58 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D0D8129657; Fri, 3 Mar 2017 14:51:58 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 53E732009E; Fri, 3 Mar 2017 18:14:23 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 64ED0636BB; Fri, 3 Mar 2017 17:51:57 -0500 (EST) From: Michael Richardson To: Russ Housley In-Reply-To: <8C184CD7-69EB-424B-9D95-1C64A8FD706F@vigilsec.com> References: <18454.1488305685@obiwan.sandelman.ca> <14573.1488419571@obiwan.sandelman.ca> <8C184CD7-69EB-424B-9D95-1C64A8FD706F@vigilsec.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: SPASM , anima-bootstrap Subject: Re: [Spasm] SHA1 usage in Anima-bootstrap voucher yang X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 03 Mar 2017 22:52:00 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Russ Housley wrote: > I=E2=80=99m sure you know that there are three important properties f= or hash > functions. The are: Yes. > In the system you describe, it seems that an attacker would need to > find a preimage. For SHA-1, we do not know of a way to do that yet, > but the 160-bit have value produced by SHA-1 is probably not big enou= gh > to be considered safe in today's computing environment. > It seems very odd to be developing a new standards that is using a ha= sh > function that was deprecated at the end of 2010 by NIST. > My personal recommendation ould be to move from SHA-1 to SHA-256. Yes, I agree completely. What I'm asking for, is if there is a good, well-established container that we can reference, that essentially gives us the agility to move from SHA1 to SHA256, and to SHA3 if we have to. Alternatively, for the use case involved, which is to refer to a certificate by reference-to-CA + reference-to-DN, if there is some other construct that would better do what we want, and *also* provide us with the agility we wou= ld like. (Some ownership vouchers may sit in filing cabinets for a few decades in a warehouse somewhere) =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAli584wACgkQgItw+93Q 3WVAgQf+OVhFGSafm1IM0IeND2snRTHQ98/khgntKpXO4V6VJ9p0g62R6vlfWJ3O P4pxi8YZz/uEw4DGZK2FfEvBOz6vON1BycEgPPpm/4Mz73qioAlxx8vM/7qO7JUH LuX3ji2qfvArmzw5sNFpBcFVYw1mBhr2EqpMU6Yp5uhiyf9I8ApkJBL1Mlw9SkjD oOM+YUe2UXPEBC1eDq2eM38h1gkgn0/9GV8F9DgOQe6JKluBsEVzM+X2Z1PT8nxJ +DrlE+jYFE0Qra/c6Z3MY2skGmT90yEOjn3iC04h2cuBIlyaWrap+BZQWtMigaE/ 4gyfLsl9oVLewY+TDQQoy9KYBQq6nA== =otnx -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 3 15:58:49 2017 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 19C171299D4; Fri, 3 Mar 2017 15:55:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858532710.15846.12177796377662722027.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:27 -0800 Archived-At: Cc: spasm@ietf.org, stephen.farrell@cs.tcd.ie Subject: [Spasm] lamps - Requested session has been scheduled for IETF 98 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 03 Mar 2017 23:55:29 -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 (1:00:00) Thursday, Afternoon Session III 1740-1840 Room Name: Vevey 1/2 size: 200 --------------------------------------------- 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): 1 Hour Number of Attendees: 50 Conflicts to Avoid: First Priority: ipwave stir openpgp acme ace rtcweb tls sipbrandy sidrops saag perc dane curdle Second Priority: ntp cfrg dprive ecrit oauth quic sacm mile modern radext Third Priority: mtgvenue People who must be present: Russ Housley Stephen Farrell Resources Requested: Experimental room setup (boardroom and classroom) subject to availability Special Requests: Small room with U shape setup would be great if one is available. --------------------------------------------------------- From nobody Mon Mar 6 07:54:36 2017 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 45B91129869 for ; Mon, 6 Mar 2017 07:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 3Mz77T3oywbx for ; Mon, 6 Mar 2017 07:54:30 -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 7ABE412985F for ; Mon, 6 Mar 2017 07:54:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C7D52300449 for ; Mon, 6 Mar 2017 10:54: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 xJ1gDKtp8CTj for ; Mon, 6 Mar 2017 10:54:28 -0500 (EST) Received: from russhousleymbp.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 68343300266; Mon, 6 Mar 2017 10:54:28 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Russ Housley In-Reply-To: <24239.1488581517@obiwan.sandelman.ca> Date: Mon, 6 Mar 2017 10:54:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <19405A7A-EC2C-4DE5-A18B-300EA10D0B03@vigilsec.com> References: <18454.1488305685@obiwan.sandelman.ca> <14573.1488419571@obiwan.sandelman.ca> <8C184CD7-69EB-424B-9D95-1C64A8FD706F@vigilsec.com> <24239.1488581517@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3259) Archived-At: Cc: SPASM , anima-bootstrap Subject: Re: [Spasm] SHA1 usage in Anima-bootstrap voucher yang X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 15:54:32 -0000 Michael: > Russ Housley wrote: >> I=E2=80=99m sure you know that there are three important properties = for hash >> functions. The are: >=20 > Yes. >=20 >> In the system you describe, it seems that an attacker would need to >> find a preimage. For SHA-1, we do not know of a way to do that yet, >> but the 160-bit have value produced by SHA-1 is probably not big = enough >> to be considered safe in today's computing environment. >=20 >> It seems very odd to be developing a new standards that is using a = hash >> function that was deprecated at the end of 2010 by NIST. >=20 >> My personal recommendation ould be to move from SHA-1 to SHA-256. >=20 > Yes, I agree completely. >=20 > What I'm asking for, is if there is a good, well-established container = that > we can reference, that essentially gives us the agility to move from = SHA1 to > SHA256, and to SHA3 if we have to. >=20 > Alternatively, for the use case involved, which is to refer to a = certificate > by reference-to-CA + reference-to-DN, if there is some other construct = that > would better do what we want, and *also* provide us with the agility = we would > like. >=20 > (Some ownership vouchers may sit in filing cabinets for a few decades = in > a warehouse somewhere) As Sean said, RFC 7093 gives ways that the CA can compute the Subject = Key Identifier, and the CA can migrate from SHA-256 if needed in the = future. Russ From nobody Mon Mar 6 07:59:04 2017 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 0B87512985F for ; Mon, 6 Mar 2017 07:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 aUyVFBnVPMtf for ; Mon, 6 Mar 2017 07:59:01 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 CC9B4129522 for ; Mon, 6 Mar 2017 07:59:00 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id y76so29287644qkb.0 for ; Mon, 06 Mar 2017 07:59:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:mime-version:subject:message-id:references:to:date; bh=SXutPQB61CpISKD86HWXu/BFA1skcJhnsL2K6wULTeQ=; b=Oa2u5uJDZ7VM4sjgUG5urxZh4TEr7ptlYAcOmuGrnJQBbjIf6uAmbYGcZyPgJX4tjR 36kAILD0c+48BldNin+SeFffvfJnQ5Fe9s3eByMNrVjQK3a5AsQelY8QnKg31Vn8l5AY Xp1/J0PC8LR1dsSMY0fdbwSxS0H5hw9s0qMws= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=SXutPQB61CpISKD86HWXu/BFA1skcJhnsL2K6wULTeQ=; b=WLRl42RGzUegsmWkT9fzr3B63hFDnLFRwl1MwoRrHCQ3bXTIDfonY3WQOIYp7jSRLI oJ5NAzvNaCvJc2gC6y89BE+eniPvN5DQ4d3qxBCoRNGnyZNym61zkhZ4PZd6Yl0rnyKP hbMwGes76103XqfhYoClUKq/V64nhsWtGLi3CPxjljZjtyIlQhuNwfn+EnP93X/zhCPD DvKu03W7BouZoC+AMeKJOJoTd1uYVTdOEjjfxytFIs2GNtBMBpARk7nUzPxz0pKyA7xZ vh5odB1v5CmURXFZZekji1b0NFTynOixJ6SPEB2LCKAn2Z0tTn2jSIW3r6Wo8DK5Kzkl BPmg== X-Gm-Message-State: AMke39nB8JcNDGNVGwo5j4GKX86dDvdq3pmoe61qwOHk57t0IjI8ylgPQWJyrZ0YtGamfQ== X-Received: by 10.55.91.194 with SMTP id p185mr6184457qkb.27.1488815939656; Mon, 06 Mar 2017 07:58:59 -0800 (PST) Received: from [172.16.0.18] ([96.231.228.203]) by smtp.gmail.com with ESMTPSA id a26sm13677760qtb.28.2017.03.06.07.58.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Mar 2017 07:58:58 -0800 (PST) From: Sean Turner Content-Type: multipart/alternative; boundary="Apple-Mail=_A05D9949-C216-4443-B409-D756080E0E2B" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <8553FDBC-CEDC-467B-8693-48956184AF28@sn3rd.com> References: <148881563181.15097.4475225867357155229.idtracker@ietfa.amsl.com> To: SPASM Date: Mon, 6 Mar 2017 10:58:57 -0500 X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [Spasm] Fwd: New Version Notification for draft-turner-lamps-adding-sha3-to-pkix-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 15:59:03 -0000 --Apple-Mail=_A05D9949-C216-4443-B409-D756080E0E2B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I took a first swing at the SHA-3 draft: > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-turner-lamps-adding-sha3-to-pkix-00.txt > Date: March 6, 2017 at 10:53:51 AM EST > To: "Sean Turner" >=20 >=20 > A new version of I-D, draft-turner-lamps-adding-sha3-to-pkix-00.txt > has been successfully submitted by Sean Turner and posted to the > IETF repository. >=20 > Name: draft-turner-lamps-adding-sha3-to-pkix > Revision: 00 > Title: SHA-3 Related Algorithms and Identifiers for = PKIX > Document date: 2017-03-06 > Group: Individual Submission > Pages: 11 > URL: = https://www.ietf.org/internet-drafts/draft-turner-lamps-adding-sha3-to-pki= x-00.txt > Status: = https://datatracker.ietf.org/doc/draft-turner-lamps-adding-sha3-to-pkix/ > Htmlized: = https://tools.ietf.org/html/draft-turner-lamps-adding-sha3-to-pkix-00 >=20 >=20 > Abstract: > This document describes the conventions for using the SHA-3 family = of > hash functions in the Internet X.509 PKI as one-way hash functions > and with the ECDSA signature algorithm; the conventions for the > associated ECDSA subject public keys are also described. Digital > signatures are used to sign certificates and CRLs (Certificate > Revocation Lists). >=20 The gh repo can be found at: https://github.com/seanturner/draft-turner-lamps-adding-sha3-to-pkix Couple of questions for -01: 1. Do we want to add SHA3-224 and the associated signature algorithms? = I=E2=80=99m sure we could do it for completeness but does anybody really = need these? 2. Do we need to add DSA? Again we could do this for completeness, but = is there anybody who issues DSA certificates now that=E2=80=99s actually = going to switch to SHA-3 in the future? And would they say so on list? 3. Do we really need RSASSA-PKCS1-v1.5? RSA suggested moving towards = RSASSA-PSS over a decade ago and we=E2=80=99re actually considering = specifying it RSASSA-PKCS1-v1.5 with SHA-3? Notes: 1. The HMAC algorithms don=E2=80=99t really fit in this draft. 2. I mentioned but purposely omit the expandable-output functions. 3. There=E2=80=99s OIDs at = http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.html = = but the only ASN.1 module is for the AES-related algorithms so I added = ASN.1 modules (=E2=80=9988 and =E2=80=9912/=E2=80=9915) but I=E2=80=99d = use the OIDs from NIST page. Comments obviously welcome. spt --Apple-Mail=_A05D9949-C216-4443-B409-D756080E0E2B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I took a first swing at the SHA-3 draft:

Begin = forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-turner-lamps-adding-sha3-to-pkix-00.txt
Date: = March 6, 2017 at 10:53:51 AM = EST
To: = "Sean Turner" <sean@sn3rd.com>

A new version of I-D, = draft-turner-lamps-adding-sha3-to-pkix-00.txt
has been = successfully submitted by Sean Turner and posted to the
IETF= repository.

Name: = draft-turner-lamps-adding-sha3-to-pkix
Revision: 00
Title:= = SHA-3 Related Algorithms and Identifiers for PKIX
Document date: 2017-03-06
Group:= = Individual Submission
Pages: 11
URL: =            https://www.ietf.org/internet-drafts/draft-turner-lamps-adding-= sha3-to-pkix-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-turner-lamps-adding-sha3= -to-pkix/
Htmlized: =       https://tools.ietf.org/html/draft-turner-lamps-adding-sha3-to-p= kix-00


Abstract:
  This document describes the conventions for = using the SHA-3 family of
  hash functions in = the Internet X.509 PKI as one-way hash functions
=   and with the ECDSA signature algorithm; the conventions for = the
  associated ECDSA subject public keys are = also described.  Digital
  signatures are = used to sign certificates and CRLs (Certificate
=   Revocation Lists).


The gh repo can be found at:
https://github.com/seanturner/draft-turner-lamps-adding-sha3-to= -pkix

Couple= of questions for -01:

1. Do we want to add SHA3-224 and the = associated signature algorithms?  I=E2=80=99m sure we could do it = for completeness but does anybody really need these?

2. Do we need to add = DSA? Again we could do this for completeness, but is there anybody who = issues DSA certificates now that=E2=80=99s actually going to switch to = SHA-3 in the future?  And would they say so on list?

3. Do we really need = RSASSA-PKCS1-v1.5?  RSA suggested moving towards RSASSA-PSS over a = decade ago and we=E2=80=99re actually considering specifying it = RSASSA-PKCS1-v1.5 with SHA-3?

Notes:

1. The HMAC algorithms don=E2=80=99t = really fit in this draft.
2. I mentioned but = purposely omit the expandable-output functions.
3. There=E2=80=99s OIDs at http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithm= s.html but the only ASN.1 module is for the AES-related = algorithms so I added ASN.1 modules (=E2=80=9988 and =E2=80=9912/=E2=80=99= 15) but I=E2=80=99d use the OIDs from NIST page.

Comments obviously = welcome.

spt

= --Apple-Mail=_A05D9949-C216-4443-B409-D756080E0E2B-- From nobody Mon Mar 6 08:07:14 2017 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 BD5E112953B for ; Mon, 6 Mar 2017 08:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 HJOMOAu64AW5 for ; Mon, 6 Mar 2017 08:07:11 -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 65641128AB0 for ; Mon, 6 Mar 2017 08:07:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C73F830044B for ; Mon, 6 Mar 2017 11:07:10 -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 lCC3K3lMdy1n for ; Mon, 6 Mar 2017 11:07:09 -0500 (EST) Received: from russhousleymbp.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 60B3B30029E; Mon, 6 Mar 2017 11:07:09 -0500 (EST) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_DF5852EE-D6BF-400D-AA94-875BFC5A383F" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 6 Mar 2017 11:07:23 -0500 In-Reply-To: <8553FDBC-CEDC-467B-8693-48956184AF28@sn3rd.com> To: Sean Turner References: <148881563181.15097.4475225867357155229.idtracker@ietfa.amsl.com> <8553FDBC-CEDC-467B-8693-48956184AF28@sn3rd.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: SPASM Subject: Re: [Spasm] Fwd: New Version Notification for draft-turner-lamps-adding-sha3-to-pkix-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 16:07:13 -0000 --Apple-Mail=_DF5852EE-D6BF-400D-AA94-875BFC5A383F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks Sean. We cannot adopt this in the working group until the IESG approves a = charter update. However, I think we can talk about the document in = preparation for the updated charter. > The gh repo can be found at: > https://github.com/seanturner/draft-turner-lamps-adding-sha3-to-pkix = >=20 > Couple of questions for -01: >=20 > 1. Do we want to add SHA3-224 and the associated signature algorithms? = I=E2=80=99m sure we could do it for completeness but does anybody = really need these? I do not mind them being there for completeness, but I have not seen any = use of SHA-224. > 2. Do we need to add DSA? Again we could do this for completeness, but = is there anybody who issues DSA certificates now that=E2=80=99s actually = going to switch to SHA-3 in the future? And would they say so on list? I am aware of some systems that used DSA years ago, but I am not aware = of anything recent. If anyone know of a system that might use DSA with = SHA3, please speak up. > 3. Do we really need RSASSA-PKCS1-v1.5? RSA suggested moving towards = RSASSA-PSS over a decade ago and we=E2=80=99re actually considering = specifying it RSASSA-PKCS1-v1.5 with SHA-3? These are a lot of systems that continue to use RSASSA-PKCS1-v1.5. I = think these identifiers are needed. That said, does anyone know of a system that would likely use RSASSA-PSS = with SHA3? Russ --Apple-Mail=_DF5852EE-D6BF-400D-AA94-875BFC5A383F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks Sean.

We cannot adopt this in the working group until the IESG = approves a charter update.  However, I think we can talk about the = document in preparation for the updated charter.


The gh repo can be found at:
https://github.com/seanturner/draft-turner-lamps-adding-sha3-to= -pkix

Couple= of questions for -01:

1. Do we want to add SHA3-224 and the = associated signature algorithms?  I=E2=80=99m sure we could do it = for completeness but does anybody really need = these?

I do not = mind them being there for completeness, but I have not seen any use of = SHA-224.

2. Do we need to add DSA? Again we could do = this for completeness, but is there anybody who issues DSA certificates = now that=E2=80=99s actually going to switch to SHA-3 in the future? =  And would they say so on = list?

I am aware = of some systems that used DSA years ago, but I am not aware of anything = recent.  If anyone know of a system that might use DSA with SHA3, = please speak up.

3. Do we really need RSASSA-PKCS1-v1.5? =  RSA suggested moving towards RSASSA-PSS over a decade ago and = we=E2=80=99re actually considering specifying it RSASSA-PKCS1-v1.5 with = SHA-3?

These are = a lot of systems that continue to use RSASSA-PKCS1-v1.5.  I = think these identifiers are needed.

That said, does anyone know of a system that would = likely use RSASSA-PSS with SHA3?

Russ

= --Apple-Mail=_DF5852EE-D6BF-400D-AA94-875BFC5A383F-- From nobody Tue Mar 7 00:02:06 2017 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 D00D3129AB1 for ; Tue, 7 Mar 2017 00:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ed1f2m-KGjU for ; Tue, 7 Mar 2017 00:02:02 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 411CF1299FC for ; Tue, 7 Mar 2017 00:02:02 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B5BE376FC; Tue, 7 Mar 2017 08:02:02 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.156]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v27820gr006041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 7 Mar 2017 03:02:02 -0500 Message-ID: <1488873720.3288.7.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Sean Turner , SPASM Date: Tue, 07 Mar 2017 09:02:00 +0100 In-Reply-To: <8553FDBC-CEDC-467B-8693-48956184AF28@sn3rd.com> References: <148881563181.15097.4475225867357155229.idtracker@ietfa.amsl.com> <8553FDBC-CEDC-467B-8693-48956184AF28@sn3rd.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 07 Mar 2017 08:02:02 +0000 (UTC) Archived-At: Subject: Re: [Spasm] Fwd: New Version Notification for draft-turner-lamps-adding-sha3-to-pkix-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 07 Mar 2017 08:02:04 -0000 On Mon, 2017-03-06 at 10:58 -0500, Sean Turner wrote: > > Abstract: > >   This document describes the conventions for using the SHA-3 > > family of > >   hash functions in the Internet X.509 PKI as one-way hash > > functions > >   and with the ECDSA signature algorithm; the conventions for the > >   associated ECDSA subject public keys are also described.  Digital > >   signatures are used to sign certificates and CRLs (Certificate > >   Revocation Lists). > > > > The gh repo can be found at: > https://github.com/seanturner/draft-turner-lamps-adding-sha3-to-pkix > > Couple of questions for -01: > > 1. Do we want to add SHA3-224 and the associated signature > algorithms?  I’m sure we could do it for completeness but does > anybody really need these? Most likely not. > 2. Do we need to add DSA? Again we could do this for completeness, > but is there anybody who issues DSA certificates now that’s actually > going to switch to SHA-3 in the future?  And would they say so on > list? I think DSA is being slowly dropped from any applications and protocols that used to support it and there is little interest even following up and bringing documents up to date with DSA2. > 3. Do we really need RSASSA-PKCS1-v1.5?  RSA suggested moving towards > RSASSA-PSS over a decade ago and we’re actually considering > specifying it RSASSA-PKCS1-v1.5 with SHA-3? Yes please. RSASSA-PSS has close to none deployment/usage at this point, and very few CAs can issue certificates with that OID. That may change when TLS1.3 is out, but that's yet to be seen. regards, Nikos From nobody Wed Mar 8 08:22:36 2017 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 91D21126DFB; Wed, 8 Mar 2017 08:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie 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 7K7OAnCzeD2o; Wed, 8 Mar 2017 08:22:29 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59911293FB; Wed, 8 Mar 2017 08:22:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 359FEBE74; Wed, 8 Mar 2017 16:22:27 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7VJ91IF2gm0; Wed, 8 Mar 2017 16:22:26 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 80A11BE5C; Wed, 8 Mar 2017 16:22:26 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1488990146; bh=lY6U4W5VBenuNRZ4o8uth1UN4sqP7TcC5DK94bv2Vbo=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Jhx9pK7lqgDgPkkiVbIStuwtRRFnndGn8Xjui467XoiO48ItlD7LZOFPfXg4vMgJ3 wQVixcWIc5qY3pHTXfFIwePDzwCZSq33B35YgtKVisXLQEE8gusnvIJ0YAxNgPXIaP zUY7V1PkJ7WWRNdTcEIEAy1T4oQyngNinxsbvE88= To: IETF general list References: <841bb724-7403-4682-3d50-f878f63b0346@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <6d114340-c9a7-e311-e6f9-0614600cafd2@cs.tcd.ie> Date: Wed, 8 Mar 2017 16:22:25 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <841bb724-7403-4682-3d50-f878f63b0346@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="quAp4X6UJvPOAv7q2DWUgEAos2xxHDs4F" Archived-At: Cc: "spasm@ietf.org" Subject: Re: [Spasm] Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2017 16:22:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --quAp4X6UJvPOAv7q2DWUgEAos2xxHDs4F Content-Type: multipart/mixed; boundary="v4rPmfsUwDLw1amHFe2u3QOqS6PrrkQbG"; protected-headers="v1" From: Stephen Farrell To: IETF general list Cc: "spasm@ietf.org" Message-ID: <6d114340-c9a7-e311-e6f9-0614600cafd2@cs.tcd.ie> Subject: Re: Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard References: <841bb724-7403-4682-3d50-f878f63b0346@cs.tcd.ie> In-Reply-To: <841bb724-7403-4682-3d50-f878f63b0346@cs.tcd.ie> --v4rPmfsUwDLw1amHFe2u3QOqS6PrrkQbG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, So I don't think we've yet resolved the issues raised with this. And since the March 16th telechat will be my last one I figure that the best thing to do is to ask that this go back to the working group for resolution. Once that's sorted out, then the WG can kick it over to their new AD. Note that this need not add any major delay - it'd be entirely possible to have it back on a telechat agenda shortly after IETF98, all going well. If nobody yells, I'll do that tomorrow. If someone does yell, please do that now and accompany your yell with the OLD/NEW changes that you claim resolve the issues raised. (To be honest though, I think this would benefit from more WG discussion so I'll not be so easy to convince if someone does yell thusly;-) Cheers, S. On 23/02/17 20:16, Stephen Farrell wrote: >=20 > Folks, >=20 > I've just reviewed the IETF LC for this draft. Thanks all for > the comments and discussion which I think have thrown up some > real issues. >=20 > As of now, it is not clear to me that we have finished the > work with this one, at least the issues to do with name > constraints seem to me to call for some more WG consideration. >=20 > I think Russ (as lamps WG chair) has a similar opinion > that we're not done yet. >=20 > That said, I had put this on the March 16th IESG telechat > for consideration. If we do manage to reach a clear enough > consensus on a published revision to the draft in say the > next week then that schedule should still be fine. So I'd > encourage the authors and others who've commented to try > again and see if, in that timeframe, we can get to where > we're happy that the issues raised have been handled well > enough. >=20 > But, if it looks (as it does to me today) as if this'll take > a bit longer to figure out, then I figure the right thing to > do will be to let the lamps WG figure out how to proceed. > (And that'll mean that my successor as the responsible AD > for the lamps WG will handle further actions with the doc.) >=20 > Bottom line: if this isn't settled in the next week or so, > I'll take it off the March 16th IESG telechat and let the WG > continue the discussion. >=20 > Cheers, > S. >=20 > PS: To add to the name constraints discussion, I did wonder > if anyone really wants to use those. So for example, if we > defined the new name form so that certificate chains with > any name constraints at all and one of those names anywhere > are always treated as invalid, then would that cause any > real breakage? (It certainly would cause theoretical breakage, > but if that's all then I'd be ok with that:-) >=20 >=20 >=20 --v4rPmfsUwDLw1amHFe2u3QOqS6PrrkQbG-- --quAp4X6UJvPOAv7q2DWUgEAos2xxHDs4F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYwC/BAAoJEC88hzaAX42iocYIALp9f0AnHtixvM+KOZO8nn8d 0cwBZZzvEtSfWNzvWyMOk5rzTjAAdfLwSegfc90n563fosY5LXhhgbfuzURpztOs EHNj7myTkUhI08LuwPGqs/FIS4p79JH5h1R3bW7im+KstENOV8aB3XlrZkBCMHyj YP4XvC62TVFxO60QF0LZaokjStiMJbEv603eK0aH0US0sHLdJnyBswKhcJYbzB6J pV8jp3OR9TH0O2lbUmHo3I1W2zGjgAKfgbT/B9bSt0PsuvidZfkNIgiR9giLCKAI ZtFMxPbAnQ8kijKaGPwLWsYDeT15/oS/e+8pI/tWo9dj+ss1ehMftTqDWMDN7b4= =TY2X -----END PGP SIGNATURE----- --quAp4X6UJvPOAv7q2DWUgEAos2xxHDs4F-- From nobody Wed Mar 8 14:58:13 2017 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 C07C81294C9; Wed, 8 Mar 2017 14:58:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148901388875.20183.9133906633071318723@ietfa.amsl.com> Date: Wed, 08 Mar 2017 14:58:08 -0800 Archived-At: Cc: spasm@ietf.org Subject: [Spasm] I-D Action: draft-ietf-lamps-eai-addresses-07.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2017 22:58:09 -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 of the IETF. Title : Internationalized Email Addresses in X.509 certificates Authors : Alexey Melnikov Weihaw Chuang Filename : draft-ietf-lamps-eai-addresses-07.txt Pages : 12 Date : 2017-03-08 Abstract: This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternate Name extension that allows a certificate subject to be associated with an Internationalized Email Address. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-addresses-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 8 15:07:24 2017 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 3EF6D1294E1 for ; Wed, 8 Mar 2017 15:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 1fC1BGBxmfyf for ; Wed, 8 Mar 2017 15:07:17 -0800 (PST) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 95535129607 for ; Wed, 8 Mar 2017 15:07:17 -0800 (PST) Received: by mail-oi0-x229.google.com with SMTP id m124so28217084oig.1 for ; Wed, 08 Mar 2017 15:07:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DAER+LYKF+5PCXc89tAJY0Zz2/J4DKYr9e9vJLVaX24=; b=hHq/m0DPR+DnO543qEX6qv6W/rDOK/ACV1zcdtvz45TxpmEEWEox2ElERmNIznA9uD dURJV6fKD0IvI13985y0MQQjLH635H2ppDQGhc1xMy7t+13Arsj6HBHeRdcNsmHSMlJe LXNTiDZ7ARJplYx5kjbOq6uWXrJd9dW+1TKLZgHGfVhlNQD3CqtB5l3tPuyn/N+jrIKk AFvBOCC+3gnrCUbRA27VF93LeheLR5IEt7Bpa80hSK28JfkMzWrAiYa5hz08CNQN6Dvi JLaU+N4gyxdfQ4oCpqM6En0NYJ+uZ1ijYTgaUNLeN1Aodof4mbXOc/agrlQhRCz+Zwyc QGaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DAER+LYKF+5PCXc89tAJY0Zz2/J4DKYr9e9vJLVaX24=; b=t4RX8aagx5mJWnKVZjj8GyCTnEF3IIo7mPPaA6etA3W9axN8CBtXgw+GKoe6/4pvB7 eQoyX21k6FFLVwDySKRvHONlp2fblP1b9y8P1u44LjuXUUW7ZTDF7sqxgrkmpF+v0H0m dbvtrorD7b6ZYOeeV0ctto654FM/o+8EYT1q8KQk6OTK/xRLRh4FtNASU4XmhXcBtk57 8UqXryYi8f4+eByshi/hEUIrJzqLSbtWPGK6l8I44304jD7V3p1GucbjZ+1ZhSabfgLB DyHAZuE+C3IsPKtFH5tDVDMYtp08VHBc/Ga/1OFpGXjxWm8gkYU6YEpPewIF7Y8rT9LQ +skQ== X-Gm-Message-State: AMke39n+fzkzwxuS6BLtwl080wCmdDcgYdUgssopbj4FFkh148NJD5O3iSI6wLy5dZtu3zzBsXFU33mhwcWuZzT+ X-Received: by 10.202.79.18 with SMTP id d18mr5439041oib.9.1489014436781; Wed, 08 Mar 2017 15:07:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.41.226 with HTTP; Wed, 8 Mar 2017 15:07:15 -0800 (PST) In-Reply-To: <6d114340-c9a7-e311-e6f9-0614600cafd2@cs.tcd.ie> References: <841bb724-7403-4682-3d50-f878f63b0346@cs.tcd.ie> <6d114340-c9a7-e311-e6f9-0614600cafd2@cs.tcd.ie> From: Wei Chuang Date: Wed, 8 Mar 2017 15:07:15 -0800 Message-ID: To: Stephen Farrell Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113d85c4968c7e054a403020" Archived-At: Cc: "spasm@ietf.org" , IETF general list Subject: Re: [Spasm] Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2017 23:07:20 -0000 --001a113d85c4968c7e054a403020 Content-Type: multipart/alternative; boundary=001a113d85c492465c054a40302a --001a113d85c492465c054a40302a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Stephen, Let me provide that yell to see if this draft resolves the last set of concerns. https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-07 The diff is here: https://tools.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-addresses-07.txt -Wei On Wed, Mar 8, 2017 at 8:22 AM, Stephen Farrell wrote: > > Hiya, > > So I don't think we've yet resolved the issues raised > with this. And since the March 16th telechat will be my > last one I figure that the best thing to do is to ask > that this go back to the working group for resolution. > > Once that's sorted out, then the WG can kick it over > to their new AD. Note that this need not add any major > delay - it'd be entirely possible to have it back on a > telechat agenda shortly after IETF98, all going well. > > If nobody yells, I'll do that tomorrow. > > If someone does yell, please do that now and accompany > your yell with the OLD/NEW changes that you claim resolve > the issues raised. (To be honest though, I think this > would benefit from more WG discussion so I'll not be so > easy to convince if someone does yell thusly;-) > > Cheers, > S. > > On 23/02/17 20:16, Stephen Farrell wrote: > > > > Folks, > > > > I've just reviewed the IETF LC for this draft. Thanks all for > > the comments and discussion which I think have thrown up some > > real issues. > > > > As of now, it is not clear to me that we have finished the > > work with this one, at least the issues to do with name > > constraints seem to me to call for some more WG consideration. > > > > I think Russ (as lamps WG chair) has a similar opinion > > that we're not done yet. > > > > That said, I had put this on the March 16th IESG telechat > > for consideration. If we do manage to reach a clear enough > > consensus on a published revision to the draft in say the > > next week then that schedule should still be fine. So I'd > > encourage the authors and others who've commented to try > > again and see if, in that timeframe, we can get to where > > we're happy that the issues raised have been handled well > > enough. > > > > But, if it looks (as it does to me today) as if this'll take > > a bit longer to figure out, then I figure the right thing to > > do will be to let the lamps WG figure out how to proceed. > > (And that'll mean that my successor as the responsible AD > > for the lamps WG will handle further actions with the doc.) > > > > Bottom line: if this isn't settled in the next week or so, > > I'll take it off the March 16th IESG telechat and let the WG > > continue the discussion. > > > > Cheers, > > S. > > > > PS: To add to the name constraints discussion, I did wonder > > if anyone really wants to use those. So for example, if we > > defined the new name form so that certificate chains with > > any name constraints at all and one of those names anywhere > > are always treated as invalid, then would that cause any > > real breakage? (It certainly would cause theoretical breakage, > > but if that's all then I'd be ok with that:-) > > > > > > > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > --001a113d85c492465c054a40302a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi Stephen,

Let me provide that yell to see if this draft resolves the last set of concerns.

-Wei


On Wed, Mar 8, 2017 at 8:22 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hiya,

So I don't think we've yet resolved the issues raised
with this. And since the March 16th telechat will be my
last one I figure that the best thing to do is to ask
that this go back to the working group for resolution.

Once that's sorted out, then the WG can kick it over
to their new AD. Note that this need not add any major
delay - it'd be entirely possible to have it back on a
telechat agenda shortly after IETF98, all going well.

If nobody yells, I'll do that tomorrow.

If someone does yell, please do that now and accompany
your yell with the OLD/NEW changes that you claim resolve
the issues raised. (To be honest though, I think this
would benefit from more WG discussion so I'll not be so
easy to convince if someone does yell thusly;-)

Cheers,
S.

On 23/02/17 20:16, Stephen Farrell wrote:
>
> Folks,
>
> I've just reviewed the IETF LC for this draft. Thanks all for
> the comments and discussion which I think have thrown up some
> real issues.
>
> As of now, it is not clear to me that we have finished the
> work with this one, at least the issues to do with name
> constraints seem to me to call for some more WG consideration.
>
> I think Russ (as lamps WG chair) has a similar opinion
> that we're not done yet.
>
> That said, I had put this on the March 16th IESG telechat
> for consideration. If we do manage to reach a clear enough
> consensus on a published revision to the draft in say the
> next week then that schedule should still be fine. So I'd
> encourage the authors and others who've commented to try
> again and see if, in that timeframe, we can get to where
> we're happy that the issues raised have been handled well
> enough.
>
> But, if it looks (as it does to me today) as if this'll take
> a bit longer to figure out, then I figure the right thing to
> do will be to let the lamps WG figure out how to proceed.
> (And that'll mean that my successor as the responsible AD
> for the lamps WG will handle further actions with the doc.)
>
> Bottom line: if this isn't settled in the next week or so,
> I'll take it off the March 16th IESG telechat and let the WG
> continue the discussion.
>
> Cheers,
> S.
>
> PS: To add to the name constraints discussion, I did wonder
> if anyone really wants to use those. So for example, if we
> defined the new name form so that certificate chains with
> any name constraints at all and one of those names anywhere
> are always treated as invalid, then would that cause any
> real breakage? (It certainly would cause theoretical breakage,
> but if that's all then I'd be ok with that:-)
>
>
>


_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm


--001a113d85c492465c054a40302a-- --001a113d85c4968c7e054a403020 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMZN1N4N3KNCF5ZBTQMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTAyNjE4NDI0NVoXDTE3MDQy NDE4NDI0NVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDiNpZ5E2IqcxktrcD1X5jWksphe1Ur882fsZM99Y4hiVugSVOb zIZIxoh3ckmGpUFyK1un6AU9Rxq9GSSkRskGAaSGrGcy7ncPi7Z1NlOJN25oXFmzituZsZeYIs0S QqT9hlDpLGc95r1CpsuTlaIB8m9Uvi+H6sGecVb2TOuGbRViQIWWf5GWk2AlJYhBFyJv7regqVa8 v3fx6SLkn/hIzBQf7xpVJzG6kAa09ZE0LoPdp5YV+Hv38EqDOWjm+g6Qbh1NADhdGpbmQDp9kdlm 6WZjCMwryQukdCypLKI2BPa08F18LZktaQNlJ2s7VxDJj2ozxomeBpSK6rxSxLAjAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFIMwgx+nNfYP3NyOZfiHYydFyNdQMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAO0J2vGX8ye90RegS3 HS+OE2hGEdDYJlR+S9ZSpla5AC9eejUKUc9JZR3y0ocGeQ3FQyXjM5/azBblqz/ajAbj2Fxuge45 SdRXrItDhAGWtQNl3utu2Uhf4y3re4ZRjApnhEBBX1l0E2BJuHf8MmqMhVU70Ko6Lk3lyPxnBeWo Q3tG2He3CNCkq/SDImq9vf8CNoxKxEkCP+kI+/NaCh5peLygU1h7Dc0ryWAcrxRWn8GUeEOg28MI vpwttw54cNR4YJYJVuiXCNc6PqkT/JxCiMvHS1woXJuET6QZSPtpNtvhNu90sV68Q7b2m6Vp8QTn xbzoEIHhiQWIcfphXjbeMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMZN1N4N3K NCF5ZBTQMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBJveztXIFL4CUkp5/jo67V gUpg5M2E4+zZke5gIiTJxDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAzMDgyMzA3MTdaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEApvT3IGe2usxRXKhvM2pjVsDbzaHxzbzErs+JZrvF b2vTIuXUKd2NsdnN4ohOZKp12vPY2eakNZExPODBy3SVTTxDH/p3PWs1gjps99ys+L3UpTvZiAEw so4t9wciTWU0tQhpBIVNeKccnx2ZAzsT9czshItoSIcsLu8PrXXDwXT/P5SIrV0d4jdPdFovLGSN gs5IFZaD8K+oXQA8Fenlv0wy0wqRMA2E8HRXFm8etzlaHGrm3/iZmpLop1n8iHebdGsBivlUqNLg DHMdvLVXg/l+NVDF01J5zN0gpjeSd5ACwPOpWShMmWACY8fnryPvfxLZWV9JlbnhweB+u8dXCA== --001a113d85c4968c7e054a403020-- From nobody Wed Mar 8 15:28:00 2017 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 2D779127058; Wed, 8 Mar 2017 15:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 F5kzJ1vIatIp; Wed, 8 Mar 2017 15:27:57 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63D56120726; Wed, 8 Mar 2017 15:27:57 -0800 (PST) Received: from [172.31.30.83] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 6D1A37A32D8; Wed, 8 Mar 2017 23:27:56 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) From: Viktor Dukhovni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 8 Mar 2017 18:27:55 -0500 References: <841bb724-7403-4682-3d50-f878f63b0346@cs.tcd.ie> <6d114340-c9a7-e311-e6f9-0614600cafd2@cs.tcd.ie> To: "spasm@ietf.org" , IETF general list In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Spasm] Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2017 23:27:59 -0000 > On Mar 8, 2017, at 6:07 PM, Wei Chuang wrote: > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-addresses-07.txt This diff covers a lot more than just name constraints. One oddity that stands out is in section 5: 3. Ensure local-part is UTF-8. I don't see how one would "ensure" such a thing, since no encoding information is available for the localpart, is I would expect that is always presumptively UTF-8 (if not us-ascii). More importantly I don't believe that the name constraint issues are adequately or correctly addressed in this revision. Instead of prohibiting issuance of EE certs that HAVE SmtpUTF8Name SAN elements via a cert chain that has a certificate with *just* rfc822Name constraints, it attempts to require an unnecessary (and I think not entirely robust) correspondence between the two types constraint, and needlessly bans EE certs whose chains include just rfc822Name constraints even in the absence of SmtpUTF8Name SAN elements. The changes in this revision seem to me to be too extensive, and not yet finished. :-( -- Viktor. From nobody Wed Mar 8 17:17:24 2017 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 081FD12953D for ; Wed, 8 Mar 2017 17:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=google.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 7yxOjgZ0psBH for ; Wed, 8 Mar 2017 17:17:17 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 488AB1294EB for ; Wed, 8 Mar 2017 17:17:17 -0800 (PST) Received: by mail-oi0-x231.google.com with SMTP id m124so29372788oig.1 for ; Wed, 08 Mar 2017 17:17:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/70QjfBnciGbt/D86m2ayX1snyPwiwUjn5jIre1Lvso=; b=MKrva7BZY9zi74bC1nplJizZaFAwVWM3anueaFTj4OF6bo9u3dZUQdj8xCFdd5y9F4 Mdwt1xMcPrNRmGI/94A8U8AVOlHJsWFn17zmHE9Y1a9qh5qkwciIM6pEPQvqUWBFs20u UWRfTbL1ey2p8tIji/58c0HsWwkUCaxw2lE6NDs1ajkdpi8aodlp0TqfqIe2WgmDbjl0 HaQq4WdGeAzs/g6BaXtZpr2Y6wBB3XEufvh+wkFg7j1x8o+wBYBF53cjbNxY6J9nFqwm PAonDeoNnMWtdTlIwAhOEm78bFurCS2f6cFGjEld8fuffY2heFTRRW7T06r95lMDwH4c qDbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/70QjfBnciGbt/D86m2ayX1snyPwiwUjn5jIre1Lvso=; b=uKX4Fjpq9H/DPbL/4n5gFd+4yQ8e+pmIOz+Lwx2U8scSgE1Mav0OXo7iiihNcdzzNv MiS0Z0tJ1nQUvQ1s49saIjKrQ/N/hn5lV79q7PGSmWmTL4SpTbuYOgbz2cLM6OT1ipLS TDpapKe+PPd7fLowybfCCBiYQkwQALUrqQyBRDyRld3Itn7ooyZOVYHEya+TvBoBavHy Frai/BGXHcvdzrwdXp6shQO26bZQmTCYsg5c9m3GibRyxL/6mYiwN+NfrkSpPvbJpUEo gSTeDVjUueTlnhaPaMM2QxURS6pffIgD6JnBFym8ujM1NOQpeO5lqzScuwAKK1B4j7o3 JS/w== X-Gm-Message-State: AMke39kZhphiKOQHF//Csh3a3DK5yEv5TxjbTBnjUBvtckPsSZ8vJbN0yduM4BfzLZWg40lVSQKozmsg4BILkM/h X-Received: by 10.202.90.84 with SMTP id o81mr5034972oib.106.1489022236419; Wed, 08 Mar 2017 17:17:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.41.226 with HTTP; Wed, 8 Mar 2017 17:17:15 -0800 (PST) In-Reply-To: References: <841bb724-7403-4682-3d50-f878f63b0346@cs.tcd.ie> <6d114340-c9a7-e311-e6f9-0614600cafd2@cs.tcd.ie> From: Wei Chuang Date: Wed, 8 Mar 2017 17:17:15 -0800 Message-ID: To: Viktor Dukhovni Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113d52727c05c7054a4201d4" Archived-At: Cc: "spasm@ietf.org" , IETF general list Subject: Re: [Spasm] Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 01:17:20 -0000 --001a113d52727c05c7054a4201d4 Content-Type: multipart/alternative; boundary=001a113d5272774752054a420152 --001a113d5272774752054a420152 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Okay. I think the direction then is to have SmtpUTF8Name respect rfc822Name name constraints and vice versa. -Wei On Wed, Mar 8, 2017 at 3:27 PM, Viktor Dukhovni wrote: > > > On Mar 8, 2017, at 6:07 PM, Wei Chuang wrote: > > > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-lamps- > eai-addresses-07.txt > > This diff covers a lot more than just name constraints. One oddity that > stands out is in section 5: > > 3. Ensure local-part is UTF-8. > > I don't see how one would "ensure" such a thing, since no encoding > information is available for the localpart, is I would expect that > is always presumptively UTF-8 (if not us-ascii). > > More importantly I don't believe that the name constraint issues are > adequately or correctly addressed in this revision. > > Instead of prohibiting issuance of EE certs that HAVE SmtpUTF8Name SAN > elements via a cert chain that has a certificate with *just* rfc822Name > constraints, it attempts to require an unnecessary (and I think not > entirely robust) correspondence between the two types constraint, and > needlessly bans EE certs whose chains include just rfc822Name constraints > even in the absence of SmtpUTF8Name SAN elements. > > The changes in this revision seem to me to be too extensive, and not > yet finished. :-( > > -- > Viktor. > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --001a113d5272774752054a420152 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Okay.  I think the direction then is to have SmtpUTF8Name respect rfc822Name name constraints and vice versa.

-Wei

On Wed, Mar 8, 2017 at 3:27 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:

> On Mar 8, 2017, at 6:07 PM, Wei Chuang <weihaw@google.com> wrote:
>
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-addresses-07.txt

This diff covers a lot more than just name constraints.  One oddity that
stands out is in section 5:

        3.  Ensure local-part is UTF-8.

I don't see how one would "ensure" such a thing, since no encoding
information is available for the localpart, is I would expect that
is always presumptively UTF-8 (if not us-ascii).

More importantly I don't believe that the name constraint issues are
adequately or correctly addressed in this revision.

Instead of prohibiting issuance of EE certs that HAVE SmtpUTF8Name SAN
elements via a cert chain that has a certificate with *just* rfc822Name
constraints, it attempts to require an unnecessary (and I think not
entirely robust) correspondence between the two types constraint, and
needlessly bans EE certs whose chains include just rfc822Name constraints
even in the absence of SmtpUTF8Name SAN elements.

The changes in this revision seem to me to be too extensive, and not
yet finished. :-(

--
        Viktor.

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

--001a113d5272774752054a420152-- --001a113d52727c05c7054a4201d4 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMZN1N4N3KNCF5ZBTQMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTAyNjE4NDI0NVoXDTE3MDQy NDE4NDI0NVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDiNpZ5E2IqcxktrcD1X5jWksphe1Ur882fsZM99Y4hiVugSVOb zIZIxoh3ckmGpUFyK1un6AU9Rxq9GSSkRskGAaSGrGcy7ncPi7Z1NlOJN25oXFmzituZsZeYIs0S QqT9hlDpLGc95r1CpsuTlaIB8m9Uvi+H6sGecVb2TOuGbRViQIWWf5GWk2AlJYhBFyJv7regqVa8 v3fx6SLkn/hIzBQf7xpVJzG6kAa09ZE0LoPdp5YV+Hv38EqDOWjm+g6Qbh1NADhdGpbmQDp9kdlm 6WZjCMwryQukdCypLKI2BPa08F18LZktaQNlJ2s7VxDJj2ozxomeBpSK6rxSxLAjAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFIMwgx+nNfYP3NyOZfiHYydFyNdQMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAO0J2vGX8ye90RegS3 HS+OE2hGEdDYJlR+S9ZSpla5AC9eejUKUc9JZR3y0ocGeQ3FQyXjM5/azBblqz/ajAbj2Fxuge45 SdRXrItDhAGWtQNl3utu2Uhf4y3re4ZRjApnhEBBX1l0E2BJuHf8MmqMhVU70Ko6Lk3lyPxnBeWo Q3tG2He3CNCkq/SDImq9vf8CNoxKxEkCP+kI+/NaCh5peLygU1h7Dc0ryWAcrxRWn8GUeEOg28MI vpwttw54cNR4YJYJVuiXCNc6PqkT/JxCiMvHS1woXJuET6QZSPtpNtvhNu90sV68Q7b2m6Vp8QTn xbzoEIHhiQWIcfphXjbeMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMZN1N4N3K NCF5ZBTQMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAVVK0iDJzPLi0Oh+gTgxSx lbTPkzbQyljj7lj7GOqNXzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAzMDkwMTE3MTZaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAvX6oSkBn06Ui+5iSamyIeXQ1n9h3nTb+rT3F3C4C 0U9nhz8dXwmMmf59mFTU7zZsF8vKSn6Od0biSEANvUYL4qy2BPv6WYpROp1pY05epRugSFShOXNL 6GE2OSMfucPuKhRaoRnbnqRwg+FH2BX3u3/7cj84A8JRLcNZ+Ilxv1AjGwQEd1O+LDPWM5DZAVYY pJucNGl3F8iywHRZ4oT4VBsTYih02xWJv1GcBVtbxD59nOmGcwN0i9skJdHI7ocDvY8jerRot7au kgBm+zXFx+yUyI93mWiAlipEy2D5meqrWqCvsrIPisMmsFoJXs0hZOZK62AbTZMJ9KT/1xXiuw== --001a113d52727c05c7054a4201d4-- From nobody Wed Mar 8 19:19:30 2017 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 A7E77129717; Wed, 8 Mar 2017 19:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 HbCfQ_P6vvTc; Wed, 8 Mar 2017 19:19:23 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC96F1296FD; Wed, 8 Mar 2017 19:19:22 -0800 (PST) Received: from [172.31.30.83] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 8C5F97A32D8; Thu, 9 Mar 2017 03:19:21 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 8 Mar 2017 22:19:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <841bb724-7403-4682-3d50-f878f63b0346@cs.tcd.ie> <6d114340-c9a7-e311-e6f9-0614600cafd2@cs.tcd.ie> To: "spasm@ietf.org" , IETF general list X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Spasm] Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "spasm@ietf.org" , IETF general 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, 09 Mar 2017 03:19:25 -0000 > On Mar 8, 2017, at 8:17 PM, Wei Chuang wrote: >=20 > Okay. I think the direction then is to have SmtpUTF8Name respect = rfc822Name name constraints and vice versa. Well, no, the simplest proposal on the table is for SmtpUTF8Name to be *prohibited* when rfc822Name constraints are present and SmtpUTF8Name constraints are not. When both present, they can operate independently. The verifier logic is then: 1. If neither rfc822Name constraints nor SmtpUTF8Name = constraints are present in any CA certificate in the chain, any mixture = of rfc822Name and SmtpUTF8Name SAN elements is valid. 2. If some certificate in the chain contains *only* rfc822Name constraints, then these apply to rfc822Name SAN elements, but all SmtpUTF8Names are prohibited. 3. When both types of constraints are present in all CA = certificates that have either type, then constraints for each SAN type are exclusively based on just the corresponding constraint type. 4. If some certificate in the chain contains only SmtpUTF8Name constraints then those are unavoidably at risk of bypass via rfc822Name SAN elements when processed by legacy verifiers. Therefore, this should be avoided, and the CA needs to publish rfc822Name constraints that prevent bypass. Such constraints *need not* be equivalent (not always possible) to the desired SmtpUTF8Name constraints. Rather, it suffices to not permit rfc822Name elements that would be prohibited if they were simply cut/pasted (with no A-label to U-label conversions) as SmtpUTF8Name elements. It is not necessary for these to permit everything that SmtpUTF8Name permits. Thus for example, if SmtpUtf8Name only permits addresses in the non = NR-LDH domain "=D0=B4=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0=B9.org" (or a = specific set of addresses in such a domain), then the corresponding rfc822Name constraint could just permit "." (or = the reserved "invalid" TLD if that's preferable) which is not a usable email domain. This ensures that only the permitted SmtpUTF8Name SANs are used and no rfc822Name SANs are used. If, instead the Smtp8Name constraints are excluded non-ASCII address = forms, then since these have no literal rfc822Name equivalents, the rfc822Name constraints can be omitted with the same effect. Only when the intention is to permit NR-LDH domains with either ASCII or UTF-8 localparts (or an all-ASCII full address) do the rfc822Name and SmtpUTF8Name constraints need to be fully equivalent. This is of course trivial to do. Just cut/paste the same string into both types of constraint. --=20 Viktor. From nobody Thu Mar 9 08:19:09 2017 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 030D11293D6 for ; Thu, 9 Mar 2017 08:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gpS09mytGRO for ; Thu, 9 Mar 2017 08:19:06 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3FB12959C for ; Thu, 9 Mar 2017 08:19:03 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 198AD43343C for ; Thu, 9 Mar 2017 16:19:03 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id E87CB43341C for ; Thu, 9 Mar 2017 16:19:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489076342; bh=iY7q6mRSFXHKiSSdZLuIyLFyT413m4xn8stouvmardI=; l=3743; h=From:To:Date:From; b=RfjigYPp+ENFbR/VBTSmH5NTEHJtNrI0MzAHU8TGKtDBx5W4EhgykcuegtZitwV/S VCicQSwqGyPZf7cYJUn7mJWLSFjnSU7uPRDqgTPbM1Sz/1jQlssLqJVU5Nk1XEzwgS OHW27ZBr+hMToFjLjNqDxsMgNiJSmm9SJjYf32Gw= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id D74C31FC94 for ; Thu, 9 Mar 2017 16:19:02 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 9 Mar 2017 11:19:02 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Thu, 9 Mar 2017 11:19:02 -0500 From: "Salz, Rich" To: "spasm@ietf.org" Thread-Topic: An OCSP response extension Thread-Index: AdKY7ibhb+2MVJgFQpGlF716EDcwsA== Date: Thu, 9 Mar 2017 16:19:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.54] Content-Type: multipart/alternative; boundary="_000_b404a8551c8645b1aaa3675dc1d8da0fusma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: [Spasm] An OCSP response extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 16:19:08 -0000 --_000_b404a8551c8645b1aaa3675dc1d8da0fusma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like to propose an OCSP response extension. The intent is that a r= esponder can include a human-readable annotation in an OCSP response. This = is perhaps mainly for the responder auditors to use, and for simplicity/tra= de-off there are no language tags, etc. id-pkix-ocsp-text OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 10 } re-ocsp-text EXTENSION { SYNTAX UTF8String IDENTIFIED BY id-pkix-ocsp-text } -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz --_000_b404a8551c8645b1aaa3675dc1d8da0fusma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would like to propose an OCSP response extension.&= nbsp; The intent is that a responder can include a human-readable annotatio= n in an OCSP response. This is perhaps mainly for the responder auditors to= use, and for simplicity/trade-off there are no language tags, etc.

 

id-pkix-ocsp-text OBJECT IDENTIFIER ::=3D { id-pkix-= ocsp 10 }

 

re-ocsp-text EXTENSION { SYNTAX UTF8String

        &nbs= p;            &= nbsp;          IDENTIFIED BY i= d-pkix-ocsp-text }

 

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz<= /p>

 

--_000_b404a8551c8645b1aaa3675dc1d8da0fusma1exdag1mb1msgcorpak_-- From nobody Thu Mar 9 08:24:35 2017 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 B48F11296A9 for ; Thu, 9 Mar 2017 08:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyjE8SNVgasV for ; Thu, 9 Mar 2017 08:24:32 -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 8C9961296A8 for ; Thu, 9 Mar 2017 08:24:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0163D3004AE for ; Thu, 9 Mar 2017 11:24:31 -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 TeY3MhigZ8tp for ; Thu, 9 Mar 2017 11:24:31 -0500 (EST) Received: from russhousleymbp.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id E7D4A300268; Thu, 9 Mar 2017 11:24:30 -0500 (EST) From: Russ Housley Message-Id: <7B492EB7-CC0D-4706-85AC-8844F5BCF847@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_22F76274-CE74-494F-BB33-957DAFAE5F61" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 9 Mar 2017 11:24:33 -0500 In-Reply-To: To: Rich Salz References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: SPASM Subject: Re: [Spasm] An OCSP response extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 16:24:34 -0000 --Apple-Mail=_22F76274-CE74-494F-BB33-957DAFAE5F61 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Rich: Can you give one example of the kind of human readable text that would = be included in an OCSP response? All: If this were added to the LAMPS charter, would you implement it? Russ > On Mar 9, 2017, at 11:19 AM, Salz, Rich wrote: >=20 > I would like to propose an OCSP response extension. The intent is = that a responder can include a human-readable annotation in an OCSP = response. This is perhaps mainly for the responder auditors to use, and = for simplicity/trade-off there are no language tags, etc. > =20 > id-pkix-ocsp-text OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 10 } > =20 > re-ocsp-text EXTENSION { SYNTAX UTF8String > IDENTIFIED BY id-pkix-ocsp-text } > =20 > -- =20 > Senior Architect, Akamai Technologies > Member, OpenSSL Dev Team > IM: richsalz@jabber.at Twitter: RichSalz --Apple-Mail=_22F76274-CE74-494F-BB33-957DAFAE5F61 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Rich:

Can = you give one example of the kind of human readable text that would be = included in an OCSP response?

All:

If this were added to the LAMPS = charter, would you implement it?

Russ


On Mar 9, 2017, at 11:19 AM, = Salz, Rich <rsalz@akamai.com> wrote:

I would like to propose an = OCSP response extension.  The intent is that a responder can = include a human-readable annotation in an OCSP response. This is perhaps = mainly for the responder auditors to use, and for simplicity/trade-off = there are no language tags, etc.
 
id-pkix-ocsp-text OBJECT IDENTIFIER ::=3D= { id-pkix-ocsp 10 }
 
re-ocsp-text EXTENSION { SYNTAX UTF8String
          &nb= sp;            = ;         IDENTIFIED BY = id-pkix-ocsp-text }
 
--  
Senior = Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richsalz@jabber.at Twitter: RichSalz

= --Apple-Mail=_22F76274-CE74-494F-BB33-957DAFAE5F61-- From nobody Thu Mar 9 08:40:16 2017 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 EF6DF1296A0 for ; Thu, 9 Mar 2017 08:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KdKbYAEW3oS for ; Thu, 9 Mar 2017 08:40:14 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id DCFD71294FF for ; Thu, 9 Mar 2017 08:40:13 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 59B5743344F; Thu, 9 Mar 2017 16:40:13 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 43252433418; Thu, 9 Mar 2017 16:40:13 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489077613; bh=uoj+TK83yzhdXIph62jpE1nelBuqm2k0aCY9fErCpYo=; l=299; h=From:To:CC:Date:References:In-Reply-To:From; b=ci3wiThdOlzZa4XVWrPSQiDbuhSe/LtW2iDlUMt5sJbgpGFaIlDVNr/fAOdguNTMo i4yBNHkhE6osehDtjBuRaRKrsiEwzcL7fG/GmQ0ELGT19gODZO053tmlPfsohOQpfJ a547llcsiODYEzwL+FIdgrvUVuxLyYYrWp4u5pSU= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 3F94E1FC8B; Thu, 9 Mar 2017 16:40:13 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 9 Mar 2017 11:40:12 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Thu, 9 Mar 2017 11:40:12 -0500 From: "Salz, Rich" To: Russ Housley Thread-Topic: [Spasm] An OCSP response extension Thread-Index: AdKY7ibhb+2MVJgFQpGlF716EDcwsAALWSSAAApWhUA= Date: Thu, 9 Mar 2017 16:40:12 +0000 Message-ID: <244b0812054a41598425c6cdbf511392@usma1ex-dag1mb1.msg.corp.akamai.com> References: <7B492EB7-CC0D-4706-85AC-8844F5BCF847@vigilsec.com> In-Reply-To: <7B492EB7-CC0D-4706-85AC-8844F5BCF847@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.54] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: SPASM Subject: Re: [Spasm] An OCSP response extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 16:40:15 -0000 > Can you give one example of the kind of human readable text that would be= included in an OCSP response? A ticket number, a URL, the name of the operator that did it, etc. > If this were added to the LAMPS charter, would you implement it? OpenSSL would almost definitely implement it. From nobody Thu Mar 9 08:53:20 2017 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 257A4129499 for ; Thu, 9 Mar 2017 08:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAoA1VhamLlr for ; Thu, 9 Mar 2017 08:53:16 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id A489D128B44 for ; Thu, 9 Mar 2017 08:53:16 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2EF49433463; Thu, 9 Mar 2017 16:53:16 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 19193433468; Thu, 9 Mar 2017 16:53:16 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489078396; bh=7HvLUYH9Qm/al2ue484c7XjkdGZIx3gMv0iyzgnGlBQ=; l=938; h=From:To:CC:Date:References:In-Reply-To:From; b=Pook23DNdChrGJoT8mv7TmKKe+W9iWlb/xJQlgMtk2yhFG5fq5q3S2re4MkVSSoAo OzTz04UO6QYaG9oTjQ/57Pub3mukSkKNeiNJDTGbEDgSpplSElPrH4wwB5UTHje+uj XJgWSqCTOi2edoQ2RuZ+gaEK1OUQz3rrtF1tZ1Qo= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 164F51FC8B; Thu, 9 Mar 2017 16:53:16 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 9 Mar 2017 11:53:15 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 9 Mar 2017 11:53:15 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Thu, 9 Mar 2017 11:53:15 -0500 From: "Salz, Rich" To: "Salz, Rich" , Russ Housley Thread-Topic: [Spasm] An OCSP response extension Thread-Index: AdKY7ibhb+2MVJgFQpGlF716EDcwsAALWSSAAApWhUAAE+/dcA== Date: Thu, 9 Mar 2017 16:53:14 +0000 Message-ID: References: <7B492EB7-CC0D-4706-85AC-8844F5BCF847@vigilsec.com> <244b0812054a41598425c6cdbf511392@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <244b0812054a41598425c6cdbf511392@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.54] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: SPASM Subject: Re: [Spasm] An OCSP response extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 16:53:18 -0000 I've been asked off-list "why" ;) If an OCSP responder is driven only from CRL's, then it is easy to correlat= e why a particular OCSP response has revoked/good in its status -- just fin= d the appropriate CRL. But if a responder is driven by something like a Web= UI, or has an API that lets keyholders revoke their own key (such as an ACM= E based CA might), then having a place to put additional information can be= useful, if not required, to properly audit operations. I think this become= s more important as critical business applications are Web applications and= OCSP stapling becomes the norm. > > Can you give one example of the kind of human readable text that would > be included in an OCSP response? >=20 > A ticket number, a URL, the name of the operator that did it, etc. >=20 > > If this were added to the LAMPS charter, would you implement it? >=20 > OpenSSL would almost definitely implement it. From nobody Thu Mar 9 09:42:50 2017 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 95F2C1296C3 for ; Thu, 9 Mar 2017 09:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 gn5AoEdG0vjH for ; Thu, 9 Mar 2017 09:42:48 -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 36B5B1293E3 for ; Thu, 9 Mar 2017 09:42:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 91606300448 for ; Thu, 9 Mar 2017 12:42:47 -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 iZ0E3Nl5bU7x for ; Thu, 9 Mar 2017 12:42:46 -0500 (EST) Received: from russhousleymbp.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 9ABF0300266 for ; Thu, 9 Mar 2017 12:42:46 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 9 Mar 2017 12:42:48 -0500 References: To: SPASM In-Reply-To: Message-Id: <531F42E9-E7B2-4A40-B373-F616A4076FC2@vigilsec.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-rfc5750-bis-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 17:42:49 -0000 I think that the document is in very good shape, and it is ready to go = to the IESG. I have a few minor suggestions for improvements. I am not sure what this paragraph in Section 4.3 is trying to tell me: For 1024-bit through 3072-bit RSA with SHA-256 see [RFC4055] and [FIPS186-2] with Change Notice 1, and for 4096-bit RSA with SHA-256 see [RFC4055] and [RFC3447]. In either case, the first reference provides the signature algorithm's object identifier and the second provides the signature algorithm's definition. If I figured it out properly, I suggest: The signature algorithm object identifiers for RSA PKCS#1 v1.5 and RSASSA-PSS with SHA-256 using 1024-bit through 3072-bit public keys are specified in [RFC4055] and the signature algorithm definition is found in [FIPS186-2] with Change Notice 1. The signature algorithm object identifiers for RSA PKCS#1 v1.5 and RSASSA-PSS with SHA-256 using 4096-bit public keys are specified in [RFC4055] and the signature algorithm definition is found in [RFC3447]. The last paragraph of Section 4.3 says: For EdDSA see [I-D.ietf-curdle-pkix] and [I-D.irtf-cfrg-eddsa]. The first reference provides the signature algorithm's object identifier and the second provides the signature algorithm's definition. Other curves than curve 25519 MAY be used as well. There is only one other curve specified for EdDSA, so I suggest: For EdDSA see [I-D.ietf-curdle-pkix] and [I-D.irtf-cfrg-eddsa]. The first reference provides the signature algorithm's object identifier and the second provides the signature algorithm's definition. In addition to curve 25519, curve 448 MAY be used as well. For clarity, I think that we should change Section 4.3 as follows: OLD MUST- support RSA with SHA-256. NEW MUST- support RSA PKCS#1 v1.5 with SHA-256. and OLD The following are the RSA and RSASSA-PSS key size =E2=80=A6 NEW The following are the RSA PKCS#1 v1.5 and RSASSA-PSS key size ... Appendix C should also include S/MIME 4.0. Appendix C should probably say something about the LAMPS WG too. Russ From nobody Thu Mar 9 10:06:22 2017 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 E92BD1295B2 for ; Thu, 9 Mar 2017 10:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 uOHSBltWc754 for ; Thu, 9 Mar 2017 10:06:19 -0800 (PST) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 AFC1B129554 for ; Thu, 9 Mar 2017 10:06:19 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id h10so133274136ith.1 for ; Thu, 09 Mar 2017 10:06:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=IAmsN1th6k2CtYBcPxISMXjRZfjXFH9k8xFdBzXff+w=; b=s5WeKHfHDAv/V5KNvEpM8DzC+BxGHrGlfykmsIb8DKzoElio+FUSqIDwYsLMAO7jRK pj6M9zQqw+mh6Cewlxw8ZgPfDDmSO+dnGm+TpZPmjhmTfULQlyrSSD859XQ30Rf2hjrr uNfIhwoeF6bR3cpxRXXxogJ8S5D9+eWWdEvw9uSM1wcbCwEMWIbkQe0WKtASeZfuGSsw kgYJyH/KGxtcGfHapgBNa48MGj3xQM6HqXNErJx2/53mFhiLukSpRl1LxT5mi2AQB5tA 7er6ayFz/YkMVdZXw12uBnmBHdQG10PjOA+oa1nvAw+IsNCTHbYBxAHCV6s9obYm5k+P 4/2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=IAmsN1th6k2CtYBcPxISMXjRZfjXFH9k8xFdBzXff+w=; b=jj7ANLtHA1nGDbYCzdl/yer0TU+47eH/kiaRNGgPyD8CJKM9aikgcn6dP13gfksQto RNmg1SeMhISSLQGBrUCW2KNMLsV8EhBifkXWRM61IVVPnxDR99whEvFbeyZMaJwO5oOB 99QFahpdITGyK2w5R8wyfNkeQFYyzoL8TgX5ORT+j1HAb11ZjYQQhYIEuBgQ/BAGjVsu sfbwewtSLDzFw8L7bHsGTQYVv7QeWkwTnw8YcqST0724/TJQLuAbvVvlFt25A34stHvx SSGL28LpPo9lAz/4jdQZX1rUMF+WY0453EzSZ3DwIrofHpYhWpFC4zr6wXyr1IVMBZW9 XI1Q== X-Gm-Message-State: AMke39mCYb2it95TFuvlFdajOSox+BJEAEP1Jgt60+1AXG2mqMzo9w4273z/zihP4DV8vA5t6ZHFfKYqLXlsnw== X-Received: by 10.36.249.5 with SMTP id l5mr27554698ith.82.1489082779010; Thu, 09 Mar 2017 10:06:19 -0800 (PST) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.36.144.4 with HTTP; Thu, 9 Mar 2017 10:06:18 -0800 (PST) In-Reply-To: References: <7B492EB7-CC0D-4706-85AC-8844F5BCF847@vigilsec.com> <244b0812054a41598425c6cdbf511392@usma1ex-dag1mb1.msg.corp.akamai.com> From: Adam Langley Date: Thu, 9 Mar 2017 10:06:18 -0800 X-Google-Sender-Auth: EXlIO4dA-zQr5bZmNUtJ0u6oGKk Message-ID: To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: SPASM , Russ Housley Subject: Re: [Spasm] An OCSP response extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 18:06:21 -0000 On Thu, Mar 9, 2017 at 8:53 AM, Salz, Rich wrote: > I've been asked off-list "why" ;) > > If an OCSP responder is driven only from CRL's, then it is easy to correl= ate why a particular OCSP response has revoked/good in its status -- just f= ind the appropriate CRL. But if a responder is driven by something like a W= ebUI, or has an API that lets keyholders revoke their own key (such as an A= CME based CA might), then having a place to put additional information can = be useful, if not required, to properly audit operations. I think this beco= mes more important as critical business applications are Web applications a= nd OCSP stapling becomes the norm. Since the community is moving towards OCSP stapling and thus making each bytes of OCSP more costly for performance, couldn't this extra information simply be kept in CRLs for when it's needed? If machines aren't going to use it, why send it thousands of times a second to all clients? Cheers AGL --=20 Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Thu Mar 9 10:07:48 2017 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 31F971295CA for ; Thu, 9 Mar 2017 10:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FG7KukAGOqkc for ; Thu, 9 Mar 2017 10:07:46 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0361295B2 for ; Thu, 9 Mar 2017 10:07:46 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BEB2F433490; Thu, 9 Mar 2017 18:07:45 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id A8146433497; Thu, 9 Mar 2017 18:07:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489082865; bh=RAwjzsldrwLj7VBVDr9b4j72sAUkP6EQ0P97PNJWKYo=; l=604; h=From:To:CC:Date:References:In-Reply-To:From; b=grd7eHis3Y996YxTaKT3dqpwvMLFvXm/FpT8JuDhinCPw24Zc6ddPjRjTRyB7wMlF WD21aqyfRUybv+CUFu+h80UacgY//UXRqQSK89Bl1xPDZQHE+gSYit2yz2XyX1ftoS IvhsTfUNcK4h2DtMjqL14DZS3ovF/gQ2vKdqWdV0= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 5EF8C1FC88; Thu, 9 Mar 2017 18:07:45 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 9 Mar 2017 13:07:45 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Thu, 9 Mar 2017 13:07:45 -0500 From: "Salz, Rich" To: Adam Langley Thread-Topic: [Spasm] An OCSP response extension Thread-Index: AdKY7ibhb+2MVJgFQpGlF716EDcwsAALWSSAAApWhUAAE+/dcP//KjoAgABToiA= Date: Thu, 9 Mar 2017 18:07:45 +0000 Message-ID: <6d9976eb3fdd4bb2840a5d91ee66eec2@usma1ex-dag1mb1.msg.corp.akamai.com> References: <7B492EB7-CC0D-4706-85AC-8844F5BCF847@vigilsec.com> <244b0812054a41598425c6cdbf511392@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.54] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: SPASM , Russ Housley Subject: Re: [Spasm] An OCSP response extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 18:07:47 -0000 PiBTaW5jZSB0aGUgY29tbXVuaXR5IGlzIG1vdmluZyB0b3dhcmRzIE9DU1Agc3RhcGxpbmcgYW5k IHRodXMgbWFraW5nIGVhY2gNCj4gYnl0ZXMgb2YgT0NTUCBtb3JlIGNvc3RseSBmb3IgcGVyZm9y bWFuY2UsIGNvdWxkbid0IHRoaXMgZXh0cmEgaW5mb3JtYXRpb24NCj4gc2ltcGx5IGJlIGtlcHQg aW4gQ1JMcyBmb3Igd2hlbiBpdCdzIG5lZWRlZD8gSWYgbWFjaGluZXMgYXJlbid0IGdvaW5nIHRv IHVzZQ0KPiBpdCwgd2h5IHNlbmQgaXQgdGhvdXNhbmRzIG9mIHRpbWVzIGEgc2Vjb25kIHRvIGFs bCBjbGllbnRzPw0KDQpJJ2Qgb25seSB1c2UgaXQgZm9yIHJldm9rZWQgc3RhdHVzLg0KDQpBIHNl cnZlciBjb3VsZCBxdWVyeSBpdHMgc3RhdHVzIGFuZCB0aGVuIGZhaWwgdG8gc3RhcnQgd2l0aCBh IHVzZWZ1bCBtZXNzYWdlIGluIHRoZSBsb2csIGZvciBleGFtcGxlLg0K From nobody Thu Mar 9 10:09:15 2017 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 C6E8F1295CA for ; Thu, 9 Mar 2017 10:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtNBXB756nB7 for ; Thu, 9 Mar 2017 10:09:12 -0800 (PST) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 4BD0A129554 for ; Thu, 9 Mar 2017 10:09:12 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id o4so11554066ywd.3 for ; Thu, 09 Mar 2017 10:09:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iQmUPekmTQiwtSiPwsAFjwe7smaUfTJaBTAl1WW1/so=; b=xt+96QzLUWz26N+vYwIbdtX8057WIt43Pm7VODg7RocZJHMwl0cJlfvMIw4rkHio/K Tbi/x8hOns2JcueEjgGTd1L8ED17jl5ss2DGmPPTlUuEyHBlnTTEdmUFrbHeJXzlY30/ 150KYuYBQ9L59nE56lHrQYJNZ74+411VaUAa8OlqoKHXpr+ZCbZN1Nvs6uQbaqRQa2r3 aYANqicC7yqp2IycfZnmYRvdwokehy/7h1NtPaieljIiPNGazV19r364NhH241rxluAF Fmv1l39fyhiI361Vy/IbUOB3iaAsn80jeCk2yxWS3F1mnYSD9P3/Ec5/whogyIGJpZOM l8QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iQmUPekmTQiwtSiPwsAFjwe7smaUfTJaBTAl1WW1/so=; b=eyahCZ3+ydbOB51jnr501fS9L8B6PYNU6azqBLsAlpKM5HsANa7QrRS2J+MMGRKvRn Qh4wVe2l/bPSviSE0UxCKkiE5KC6CeJs1Dc7dLDv1aYKlP9dK2RtQ4zzocFPr+DLbXpH BDE0ugmP4AAkGZsQbp6vzBgkG6XcZ2kzaKddhwmbJ97YR8scxHgV+3UECsSW535lFBZ7 H3cEiQCAwjXeDgc+I2qcZs2IxhjFeGgcxJt3vQUxTpsREZ3vADvbYpgYRIrWSWDBX+UV x6uFVR/gphmxttnYLLN01GOdApF5GRiW1gVGVYhXmvp7Jwq7ejFbuCl2D36a44mbwpVR QIww== X-Gm-Message-State: AMke39nEDjtJXAFU0oQmjO/Pw0GIkrIG+Ao4g5OBQW/GcYl+kTirH4zuGYl7CqYel+Rho/7u9qaalw1tJDDuEA== X-Received: by 10.129.152.22 with SMTP id p22mr5157336ywg.276.1489082951527; Thu, 09 Mar 2017 10:09:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Thu, 9 Mar 2017 10:08:30 -0800 (PST) In-Reply-To: <6d9976eb3fdd4bb2840a5d91ee66eec2@usma1ex-dag1mb1.msg.corp.akamai.com> References: <7B492EB7-CC0D-4706-85AC-8844F5BCF847@vigilsec.com> <244b0812054a41598425c6cdbf511392@usma1ex-dag1mb1.msg.corp.akamai.com> <6d9976eb3fdd4bb2840a5d91ee66eec2@usma1ex-dag1mb1.msg.corp.akamai.com> From: Eric Rescorla Date: Thu, 9 Mar 2017 10:08:30 -0800 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=94eb2c0b8fb45e39c3054a5024d8 Archived-At: Cc: Adam Langley , SPASM , Russ Housley Subject: Re: [Spasm] An OCSP response extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 18:09:14 -0000 --94eb2c0b8fb45e39c3054a5024d8 Content-Type: text/plain; charset=UTF-8 It does seem like if an OCSP response is revoked you probably don't want to send it to clients :) -Ekr On Thu, Mar 9, 2017 at 10:07 AM, Salz, Rich wrote: > > Since the community is moving towards OCSP stapling and thus making each > > bytes of OCSP more costly for performance, couldn't this extra > information > > simply be kept in CRLs for when it's needed? If machines aren't going to > use > > it, why send it thousands of times a second to all clients? > > I'd only use it for revoked status. > > A server could query its status and then fail to start with a useful > message in the log, for example. > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > --94eb2c0b8fb45e39c3054a5024d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It does seem like if an OCSP response is revoked you proba= bly don't want to send it to clients :)

-Ekr


On Thu, Mar 9, 2017 at 10:07 AM, Salz, Rich <rsalz@akamai.com> wrote:
> Since th= e community is moving towards OCSP stapling and thus making each
> bytes of OCSP more costly for performance, couldn't this extra inf= ormation
> simply be kept in CRLs for when it's needed? If machines aren'= t going to use
> it, why send it thousands of times a second to all clients?

I'd only use it for revoked status.

A server could query its status and then fail to start with a useful messag= e in the log, for example.
______________________________= _________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

--94eb2c0b8fb45e39c3054a5024d8-- From nobody Thu Mar 9 10:13:04 2017 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 768661296EF for ; Thu, 9 Mar 2017 10:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5zhL3Q7au7R for ; Thu, 9 Mar 2017 10:12:59 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 055D61296F5 for ; Thu, 9 Mar 2017 10:12:56 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A447B200051; Thu, 9 Mar 2017 18:12:55 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 8E3DD200002; Thu, 9 Mar 2017 18:12:55 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489083175; bh=C0co3K9LTouziJJhyPFfYvEwY9CJ+liDDhXbZ1NnEuE=; l=300; h=From:To:CC:Date:References:In-Reply-To:From; b=v6x7a5iWZGNQPFQhtga+tDXdbKAODNN8hYxac3kXB67LrieH70rQ4II1CfLusl9r/ kkTGa70Bwjjtppkhw1T8av/7FxySJ6j5jvQTvjjHxok/n0nUo0cvkrkusFwNKngtNW DM8EaAU6EsCTz6iNRjb39SjN7rFP/kpMejC2jnb8= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 7454B1E07C; Thu, 9 Mar 2017 18:12:55 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 9 Mar 2017 13:12:54 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Thu, 9 Mar 2017 13:12:54 -0500 From: "Salz, Rich" To: Eric Rescorla Thread-Topic: [Spasm] An OCSP response extension Thread-Index: AdKY7ibhb+2MVJgFQpGlF716EDcwsAALWSSAAApWhUAAE+/dcP//KjoAgABToiD//6z8AIAAU0/g Date: Thu, 9 Mar 2017 18:12:54 +0000 Message-ID: <78cf7a16a10d4fc79e5cc889aa57ff2a@usma1ex-dag1mb1.msg.corp.akamai.com> References: <7B492EB7-CC0D-4706-85AC-8844F5BCF847@vigilsec.com> <244b0812054a41598425c6cdbf511392@usma1ex-dag1mb1.msg.corp.akamai.com> <6d9976eb3fdd4bb2840a5d91ee66eec2@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.54] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Adam Langley , SPASM , Russ Housley Subject: Re: [Spasm] An OCSP response extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 18:13:00 -0000 PiBJdCBkb2VzIHNlZW0gbGlrZSBpZiBhbiBPQ1NQIHJlc3BvbnNlIGlzIHJldm9rZWQgeW91IHBy b2JhYmx5IGRvbid0IHdhbnQgdG8gc2VuZCBpdCB0byBjbGllbnRzIDopDQoNClNvIHlvdSdkIHRo aW5rLCBidXQgZXhwZXJpZW5jZSBoYXMgc2hvd24gdXMgdGhhdCB0aGlzIGlzIG5vdCB0aGUgY2Fz ZS4gOiggIE9uIGJvdGggdGhlIGNsaWVudCBhbmQgc2VydmVyIHNpZGUuDQoNCg== From nobody Thu Mar 9 10:31:32 2017 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 10DB21294E0 for ; Thu, 9 Mar 2017 10:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 6EOF5ZrbS_yl for ; Thu, 9 Mar 2017 10:31:29 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 6FD271294C5 for ; Thu, 9 Mar 2017 10:31:29 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id h10so133685237ith.1 for ; Thu, 09 Mar 2017 10:31:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=7Up0gLBfXAIckhgygXgwd/eo4gnjjmnBaeF4vpf19Tk=; b=G/u0mjDGY+3Mi4e7TCgAqsNseskryMV9Dd13sXPmECaDx7YKbP5g9thTD3JFxGeKaZ jtzf0RxTPyLVXG+D74AEjw+eaLqx1Kzpj/+KB3oMTfw/VYVPWFyb9bUsGfJw0mUp7KzC 7eTlKMBOgLRh26D55x+fw2WFPongEFLOOew1HB8s1m77tZsmrHZh4dBWoSnCu7+nIWKD /8Pslg0EwPKDcUhMx+77jQ+9uKuV+GkiYebmUpj5k5qvZ30bQEKn0+GPMuQb7kWUynW+ 1xNwQk9DkuDONtOxX+4zP12E6TwP39x78o7qXUPwB6Buyi6N8csHh5XsPco0+EgN0IuA tK1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=7Up0gLBfXAIckhgygXgwd/eo4gnjjmnBaeF4vpf19Tk=; b=LOU6QbeehiVgHitiQOV55q7/ZANnnGcug1Cn4AT9QqRsxSV+ZKecrQ0BcwaF3Xw7Tm 5T4FKWknJT9T5/smI+Cb8YGf+J36lndGOhYGx7eplvRV2ixFSZ3XDHwfSQIq3PZ8/uUi TgI76g2Nxtqd1SqxvhdPplP26QqIEEAjpz5To/bF8qXEb5lVBaAqJJFw9rTSGgYDwK+B ckgxa29IULcQMeQ3espCOlB8WE/FkZ2KapHWWaqc/2KADF50CVQFEO+3L9FR1+WkwL5t ZIrtLi3gZLv8dAXgNUpGokRpl8Q9fKoh4rcUBfBztjDk+q3La+Jlm9g6AKsAOwYGOjnP Ov5A== X-Gm-Message-State: AMke39l9nUduxKDSp1eWbvec7sQOYidCMkLasf+qkp7hFO0jTvPpDfP5SN3xfgjfIb6jgz6xmL64Ar5qkVXAgg== X-Received: by 10.36.43.194 with SMTP id h185mr33966971ita.121.1489084288825; Thu, 09 Mar 2017 10:31:28 -0800 (PST) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.36.144.4 with HTTP; Thu, 9 Mar 2017 10:31:28 -0800 (PST) In-Reply-To: <6d9976eb3fdd4bb2840a5d91ee66eec2@usma1ex-dag1mb1.msg.corp.akamai.com> References: <7B492EB7-CC0D-4706-85AC-8844F5BCF847@vigilsec.com> <244b0812054a41598425c6cdbf511392@usma1ex-dag1mb1.msg.corp.akamai.com> <6d9976eb3fdd4bb2840a5d91ee66eec2@usma1ex-dag1mb1.msg.corp.akamai.com> From: Adam Langley Date: Thu, 9 Mar 2017 10:31:28 -0800 X-Google-Sender-Auth: SOYcVjYv7gZnVrTsOOuFIYDeTE8 Message-ID: To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: SPASM , Russ Housley Subject: Re: [Spasm] An OCSP response extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 18:31:31 -0000 On Thu, Mar 9, 2017 at 10:07 AM, Salz, Rich wrote: > I'd only use it for revoked status. Ah, I didn't get that point and, with that understanding, have no objection. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Thu Mar 9 11:19:07 2017 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 2FE56128824 for ; Thu, 9 Mar 2017 11:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 SdrQ-hOiAAMx for ; Thu, 9 Mar 2017 11:19:05 -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 BB56D129853 for ; Thu, 9 Mar 2017 11:19:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E79F4300449 for ; Thu, 9 Mar 2017 14:19:04 -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 6KIf9slfR7hd for ; Thu, 9 Mar 2017 14:19:04 -0500 (EST) Received: from russhousleymbp.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 066D13002C4; Thu, 9 Mar 2017 14:19:03 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Russ Housley In-Reply-To: Date: Thu, 9 Mar 2017 14:19:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2CDB8533-CB33-484A-AAB2-FD8FD0CB8D74@vigilsec.com> References: <7B492EB7-CC0D-4706-85AC-8844F5BCF847@vigilsec.com> <244b0812054a41598425c6cdbf511392@usma1ex-dag1mb1.msg.corp.akamai.com> <6d9976eb3fdd4bb2840a5d91ee66eec2@usma1ex-dag1mb1.msg.corp.akamai.com> To: Rich Salz X-Mailer: Apple Mail (2.3259) Archived-At: Cc: SPASM Subject: Re: [Spasm] An OCSP response extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 19:19:07 -0000 >> I'd only use it for revoked status. >=20 > Ah, I didn't get that point and, with that understanding, have no = objection. If that is the intended us, I=E2=80=99d suggest: id-pkix-ocsp-revoke-hint OBJECT IDENTIFIER ::=3D { id-pkix-ocsp TBD } =20 re-ocsp-revoke-hint EXTENSION { SYNTAX UTF8String IDENTIFIED BY id-pkix-ocsp-revoke-hint } =20 Russ= From nobody Thu Mar 9 12:05:28 2017 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 2A69F129463 for ; Thu, 9 Mar 2017 12:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.742 X-Spam-Level: X-Spam-Status: No, score=-6.742 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=eff.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 ihZRRej4PrOm for ; Thu, 9 Mar 2017 12:05:25 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1E7412944C for ; Thu, 9 Mar 2017 12:05:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:MIME-Version:Date:Message-ID:To:Subject:From; bh=QR2+inWsHvFm1VOqXl8otlAI1HPV7GvB9yxJZdYF3Vg=; b=J4Ky9TElwjdYfj8WrFgwMOWORzAZDg95HFaEQZVrp7LaaBJdWQZMb2jLaqt0BCGWViAJXgrH5vMGpDx5rmYRQWvpAS+R2TCdrcFO7X5re9kCi5R1vyiq0XVDGPGyndesdxWb6YjY3nMIVraSWeYnR47OBZrv+lxrub20XsL7cXI=; Received: ; Thu, 09 Mar 2017 12:05:23 -0800 From: Jacob Hoffman-Andrews To: SPASM , Ryan Sleevi , Phillip Hallam-Baker , Patrick Donahue , Peter Bowen , Gervase Markham , Rob Stradling Message-ID: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> Date: Thu, 9 Mar 2017 12:05:20 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------78C1DD85B7A24005A28EE38A" Received-SPF: skipped for local relay Archived-At: Subject: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 20:05:28 -0000 This is a multi-part message in MIME format. --------------78C1DD85B7A24005A28EE38A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Good news! The CA/Browser forum made CAA checking mandatory, effective 8 September 2017 . As part of the process, we had a very interesting conversation (see bottom for specific email links) about the processing algorithm specified in RFC 6844 section 4 and how to handle CNAMEs. Specifically, if there exists a set of records like so: www.staffie.dog. CNAME staffie.terrier.dog. staffie.terrier.dog. A 192.0.2.1 terrier.dog. CAA 0 issue "happy-hacker-fake-ca.net" Should issuance for www.staffie.dog require a CAA query for terrier.dog? Or should it only require CAA queries for www.staffie.dog and staffie.terrier.dog? It looks like we're not the first to be confused by this. In October 2015, Tom Clegg filed erratum 4515 , changing the behavior. My position is that his approach is better, and we should formally adopt it. I'd like to define some terms so we can speak clearly: - Recursion: What a recursive resolver does: finding and querying authoritative resolvers, and chasing CNAMEs. - Tree climbing: Looking up records for parent domains sequentially, e.g. "www.staffie.dog", "staffie.dog", "dog". The current RFC says that CA software should recurse, then tree climb on any CNAME results, then tree climb on the original name, and repeat. *The argument from naturalness* I think the most natural way to think of CNAMEs is analogous to symlinks. If you `dig A www.staffie.dog` from a recursive resolver, you get back an IP address and don't need to care about the chain of intervening CNAMEs. The CAA RFC asks CA software to "peek inside" the CNAME chain for further processing, which is a significant difference from how other resource record types are handled. *The argument from ease of implementation *Right now, recursive resolvers take care of all CNAME chasing, including loop detection. To implement CAA as it is defined today, CA software needs to implement some moderately complex code to tree climb not only the original name, but also CNAME results. This means the CA software needs to implement its own loop detection as well. I think we're likely to see inconsistent and buggy results. On the other hand, erratum 4515 allows CA software to make three simple, predictable requests to its recursive resolver: CAA www.staffie.dog. CAA staffie.dog. CAA dog. ** *The argument from you don't need that* As I understand it, the argument for the current algorithm is that it makes it easier for CDNs to deploy CAA records. For instance, if terrier.dog is a CDN serving the terrier community, and they only request certificates from Happy Hacker Fake CA, they can easily express that policy by putting a CAA record on terrier.dog. I would argue that it's just as easy for terrier.dog to configure their authoritative resolver to return a CAA record for *.terrier.dog. *The argument from CDNs don't want to do that* Cloudflare helpfully chimed in on the original thread saying that they wouldn't actually want to deploy a blanket CAA record for all their customers, even though Cloudflare uses a well-defined set of CAs. That's because doing so would prevent customers from getting their own certificates from other CAs for non-HTTPS uses, or for subdomains like party.www.staffie.dog. Even though the customers could override this by setting their own CAA resource records, this is a hassle that Cloudflare doesn't want to impose. Other CDNs are likely to feel similarly. *Hole punching and the includeSubDomains problem* Part of the debate is informed by deployment difficulties with HPKP includeSubDomains. For instance, in a previous job I deployed HTTPS at Twitter. We configured HPKP preloading with includeSubDomains on twitter.com, including all of the CAs that any of our CDNs used. Sometimes, for example, the marketing department, would hire a contractor to build a quickie website like superbowl2017.twitter.com. The contractor would have their own relationship with a hosting provider or CDN, who might use a CA not on the list. It would have been nice to be able to define hole punching, so superbowl2017.twitter.com could have its own definition of which CA keys are allowed. That's not possible with HPKP, but it is possible with CAA, intentionally. However, it's the tree climbing that gets us the hole punching property, not the alternating tree climb / recursion currently specified in RFC 6844. So adopting erratum 4515 would not break the hole punching property= =2E *Previous conversation* * [cabfpub] Ballot 187 - Make CAA Checking Mandatory=20 /p= hilliph at comodo.com/ * [cabfpub] Ballot 187 - Make CAA Checking Mandatory=20 /P= eter Bowen/ * [cabfpub] Ballot 187 - Make CAA Checking Mandatory=20 /p= hilliph at comodo.com/ * [cabfpub] Ballot 187 - Make CAA Checking Mandatory=20 /P= eter Bowen/ * [cabfpub] Ballot 187 - Make CAA Checking Mandatory=20 /P= eter Bowen/ * [cabfpub] Ballot 187 - Make CAA Checking Mandatory=20 /R= yan Sleevi/ * [cabfpub] Ballot 187 - Make CAA Checking Mandatory=20 /P= eter Bowen/ * [cabfpub] Ballot 187 - Make CAA Checking Mandatory=20 /R= yan Sleevi/ * [cabfpub] Ballot 187 - Make CAA Checking Mandatory=20 /p= hilliph at comodo.com/ * [cabfpub] Ballot 187 - Make CAA Checking Mandatory=20 /J= acob Hoffman-Andrews/ * [cabfpub] Ballot 187 - Make CAA Checking Mandatory=20 /R= yan Sleevi/ * [cabfpub] Ballot 187 - Make CAA Checking Mandatory=20 /J= acob Hoffman-Andrews/ * [cabfpub] Ballot 187 - Make CAA Checking Mandatory=20 /P= hillip Hallam-Baker/ /(whole thread: /https://cabforum.org/pipermail/public/2017-February/thread.html) --------------78C1DD85B7A24005A28EE38A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Good news! The CA/Browser forum made CAA checking mandatory, effective 8 September 2017. As part of the process, we had a very interesting conversation (see bottom for specific email links) about the processing algorithm specified in RFC 6844 section 4 and how to handle CNAMEs. Specifically, if there exists a set of records like so:

www.staffie.dog.        CNAME staffie.terrier.dog.
staffie.terrier.dog.    A 192.0.2.1
terrier.dog.            CAA 0 issue "happy-hacker-fake-ca.net"

Should issuance for www.staffie.dog require a CAA query for terrier.dog? Or should it only require CAA queries for www.staffie.dog and staffie.terrier.dog? It looks like we're not the first to be confused by this. In October 2015, Tom Clegg filed erratum 4515, changing the behavior. My position is that his approach is better, and we should formally adopt it.

I'd like to define some terms so we can speak clearly:

 - Recursion: What a recursive resolver does: finding and querying authoritative resolvers, and chasing CNAMEs.

 - Tree climbing: Looking up records for parent domains sequentially, e.g. "www.staffie.dog", "staffie.dog", "dog".

The current RFC says that CA software should recurse, then tree climb on any CNAME results, then tree climb on the original name, and repeat.

The argument from naturalness

I think the most natural way to think of CNAMEs is analogous to symlinks. If you `dig A www.staffie.dog` from a recursive resolver, you get back an IP address and don't need to care about the chain of intervening CNAMEs. The CAA RFC asks CA software to "peek inside" the CNAME chain for further processing, which is a significant difference from how other resource record types are handled.

The argument from ease of implementation

Right now, recursive resolvers take care of all CNAME chasing, including loop detection. To implement CAA as it is defined today, CA software needs to implement some moderately complex code to tree climb not only the original name, but also CNAME results. This means the CA software needs to implement its own loop detection as well. I think we're likely to see inconsistent and buggy results. On the other hand, erratum 4515 allows CA software to make three simple, predictable requests to its recursive resolver:

CAA www.staffie.dog.
CAA staffie.dog.
CAA dog.

The argument from you don't need that

As I understand it, the argument for the current algorithm is that it makes it easier for CDNs to deploy CAA records. For instance, if terrier.dog is a CDN serving the terrier community, and they only request certificates from Happy Hacker Fake CA, they can easily express that policy by putting a CAA record on terrier.dog. I would argue that it's just as easy for terrier.dog to configure their authoritative resolver to return a CAA record for *.terrier.dog.

The argument from CDNs don't want to do that

Cloudflare helpfully chimed in on the original thread saying that they wouldn't actually want to deploy a blanket CAA record for all their customers, even though Cloudflare uses a well-defined set of CAs. That's because doing so would prevent customers from getting their own certificates from other CAs for non-HTTPS uses, or for subdomains like party.www.staffie.dog. Even though the customers could override this by setting their own CAA resource records, this is a hassle that Cloudflare doesn't want to impose. Other CDNs are likely to feel similarly.

Hole punching and the includeSubDomains problem

Part of the debate is informed by deployment difficulties with HPKP includeSubDomains. For instance, in a previous job I deployed HTTPS at Twitter. We configured HPKP preloading with includeSubDomains on twitter.com, including all of the CAs that any of our CDNs used.

Sometimes, for example, the marketing department, would hire a contractor to build a quickie website like superbowl2017.twitter.com. The contractor would have their own relationship with a hosting provider or CDN, who might use a CA not on the list. It would have been nice to be able to define hole punching, so superbowl2017.twitter.com could have its own definition of which CA keys are allowed. That's not possible with HPKP, but it is possible with CAA, intentionally.

However, it's the tree climbing that gets us the hole punching property, not the alternating tree climb / recursion currently specified in RFC 6844. So adopting erratum 4515 would not break the hole punching property.


Previous conversation

(whole thread: https://cabforum.org/pipermail/public/2017-February/thread.html)

--------------78C1DD85B7A24005A28EE38A-- From nobody Thu Mar 9 12:35:32 2017 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 7B0E41293EE for ; Thu, 9 Mar 2017 12:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 fpCGo2Kyzjul for ; Thu, 9 Mar 2017 12:35:29 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DC4C120725 for ; Thu, 9 Mar 2017 12:35:29 -0800 (PST) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id D088620051C26 for ; Thu, 9 Mar 2017 12:35:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=kJlpEqQauISOylR2qGYBmP/A58s=; b= i5fuQdd/DXQqfpwO3cNNkRSJnOLpl85e2XDC+/8Zcff5JBBxydr4k6fPfyDKmpDK arOeniLXORm07imV+aOJiyemZiORBO0FI0D0+zD9+9ohZHBASUapYIzf3lXXlfOm 9WSgUhNEDzmmBIOhbGAj3WttFxiLuNcQ5VoL0wACGzc= Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id 73F6120051C22 for ; Thu, 9 Mar 2017 12:35:28 -0800 (PST) Received: by mail-lf0-f46.google.com with SMTP id a6so33204078lfa.0 for ; Thu, 09 Mar 2017 12:35:28 -0800 (PST) X-Gm-Message-State: AMke39m6r9ZY9/WLk3OTQcmuyJSq872VGDy4RIjcn0QThqBjbROQtuWAMSlT0sUChG3cw7RRNCMaiEEYSC281g== X-Received: by 10.46.83.29 with SMTP id h29mr4691322ljb.84.1489091726670; Thu, 09 Mar 2017 12:35:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.193.197 with HTTP; Thu, 9 Mar 2017 12:35:26 -0800 (PST) In-Reply-To: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> From: Ryan Sleevi Date: Thu, 9 Mar 2017 15:35:26 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary=94eb2c1ce7fa6804d6054a522f4c Archived-At: Cc: Patrick Donahue , Gervase Markham , Phillip Hallam-Baker , Peter Bowen , SPASM , Rob Stradling Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 20:35:30 -0000 --94eb2c1ce7fa6804d6054a522f4c Content-Type: text/plain; charset=UTF-8 On Thu, Mar 9, 2017 at 3:05 PM, Jacob Hoffman-Andrews wrote: > > *The argument from naturalness* > > I think the most natural way to think of CNAMEs is analogous to symlinks. > If you `dig A www.staffie.dog` from a recursive resolver, you get back an > IP address and don't need to care about the chain of intervening CNAMEs. > The CAA RFC asks CA software to "peek inside" the CNAME chain for further > processing, which is a significant difference from how other resource > record types are handled. > I think it might help if you could define what you mean by "peek inside" - I don't believe this is required in practice as defined, but perhaps it's because of the textual description of the algorithm is not optimized. That is, there are other formulations of the algorithm that can give the same result - see below, courtesy of Andrew Ayer > > > *The argument from ease of implementation *Right now, recursive resolvers > take care of all CNAME chasing, including loop detection. To implement CAA > as it is defined today, CA software needs to implement some moderately > complex code to tree climb not only the original name, but also CNAME > results. This means the CA software needs to implement its own loop > detection as well. I think we're likely to see inconsistent and buggy > results. On the other hand, erratum 4515 allows CA software to make three > simple, predictable requests to its recursive resolver: > > CAA www.staffie.dog. > CAA staffie.dog. > CAA dog. > I disagree with the assertion that it requires moderately complex code; this is something you can do with a dozen or so lines. Loop detection is a necessity, I agree, and that's certainly true of the currently defined algorithm, but a recursion limit is a sensible approach to this, and can either be normatively specified here or within the profile enacted by the CA/Browser Forum. An example of this highlighted by Andrew Ayer is that you can rewrite the current algorithm, while still obtaining equivalent results and the same queries, as R(X): if X is null: return null let caa = resolve('CAA', X) let target = resolve('CNAME', X) if caa is not null and target is null: return caa if target is not null: let recur = R(target) if recur is not null: return recur return R(parent(X)) If you wanted to prevent loops, you could add the recursion limit there. > *The argument from you don't need that* > > As I understand it, the argument for the current algorithm is that it > makes it easier for CDNs to deploy CAA records. For instance, if > terrier.dog is a CDN serving the terrier community, and they only request > certificates from Happy Hacker Fake CA, they can easily express that policy > by putting a CAA record on terrier.dog. I would argue that it's just as > easy for terrier.dog to configure their authoritative resolver to return a > CAA record for *.terrier.dog. > I want to be careful here restricting it to the notion of "CDNs", because that limits the discussion to the Cloudflare/Akamai/Fastly case. I would further advance that it applies to any form of delegation / multi-stakeholder relationship, as the Twitter case you point out. The question is largely one of operational deployment, and so I fully admit, it's a subjective argument about a future scenario in which we have incomplete data. My hope is to reduce the failure mode as much as possible, now that sites can reliably deploy CAA and expect it to be observed, so that we don't end up in situations where CAA is too complex to deploy. I appreciate you sharing the Twitter case, because I think that speaks to the concerns I have with erratum 4515. *Hole punching and the includeSubDomains problem* > > Part of the debate is informed by deployment difficulties with HPKP > includeSubDomains. For instance, in a previous job I deployed HTTPS at > Twitter. We configured HPKP preloading with includeSubDomains on > twitter.com, including all of the CAs that any of our CDNs used. > > Sometimes, for example, the marketing department, would hire a contractor > to build a quickie website like superbowl2017.twitter.com. The contractor > would have their own relationship with a hosting provider or CDN, who might > use a CA not on the list. It would have been nice to be able to define hole > punching, so superbowl2017.twitter.com could have its own definition of > which CA keys are allowed. That's not possible with HPKP, but it is > possible with CAA, intentionally. > > However, it's the tree climbing that gets us the hole punching property, > not the alternating tree climb / recursion currently specified in RFC 6844. > So adopting erratum 4515 would not break the hole punching property. > As you noted elsewhere, to effectively get this scenario, the operator of superbowl2017.twitter.com (which we'll call example.com) would need to set up the destination of CNAME in such a way as to be able to appropriately express the per-customer policy (if Twitter handles certificate provisioning) - that is, superbowl2017.twitter.example.com - or, as you noted, would need to effectively set the CAA record as a 'wildcard' / for every customer. Operationally, I totally accept that erratum 4515 can be a clear definition. Practically, I think it creates greater operational deployment challenges for such relationships, and as a result, requires greater effort to deploy. In my mind, perhaps incorrectly, it's far easier to ensure the CAA record on example.com than to handle the CAA "trampolining" for every subdomain or sub-sub-domain that may be necessary. With recursion, for example, if the marketing provider handled multiple Superbowls, they might have superbowl2015.twitter.example.com, superbowl2016.twitter.example.com, superbowl2017.twitter.example.com, and set the CAA at twitter.example.com (or, if they handle certificate provisioning, example.com). It makes it one less thing to remember to change. I suspect that CDN cases like Cloudflare/Akamai/Fastly would have no challenge with either approach, but I'm very concerned for the long-tail of the ecosystem and the challenges it would present. --94eb2c1ce7fa6804d6054a522f4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 9, 2017 at 3:05 PM, Jacob Hoffman-Andrews <jsha@eff.org>= wrote:
=20 =20 =20

The argument from naturalness

I think the most natural way to think of CNAMEs is analogous to symlinks. If you `dig A www.sta= ffie.dog` from a recursive resolver, you get back an IP address and don't need to care about the chain o= f intervening CNAMEs. The CAA RFC asks CA software to "peek inside&q= uot; the CNAME chain for further processing, which is a significant difference from how other resource record types are handled.
<= /blockquote>

I think it might help if you could define w= hat you mean by "peek inside" - I don't believe this is requi= red in practice as defined, but perhaps it's because of the textual des= cription of the algorithm is not optimized. That is, there are other formul= ations of the algorithm that can give the same result - see below, courtesy= of Andrew Ayer
=C2=A0
The argument from ease of implementation

Right now, recursive resolvers take care of all CNAME chasing, including loop detection. To implement CAA as it is defined today, CA software needs to implement some moderately complex code to tree climb not only the original name, but also CNAME results. This means the CA software needs to implement its own loop detection as well. I think we're likely to see inconsistent and buggy results. On the other hand, erratum 4515 allows CA software to make three simple, predictable requests to its recursive resolver:

CAA www.staffie.dog.
CAA staffie.dog.
CAA dog.

I disagree with the = assertion that it requires moderately complex code; this is something you c= an do with a dozen or so lines. Loop detection is a necessity, I agree, and= that's certainly true of the currently defined algorithm, but a recurs= ion limit is a sensible approach to this, and can either be normatively spe= cified here or within the profile enacted by the CA/Browser Forum.

An example of this highlighted by Andrew Ayer is that you = can rewrite the current algorithm, while still obtaining equivalent results= and the same queries, as

R(X):
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 if X is null:
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return null

=C2=A0= =C2=A0 =C2=A0 =C2=A0 let caa =3D resolve('CAA', X)
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 let target =3D resolve('CNAME', X)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 if caa is not null and target= is null:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= return caa

=C2=A0 =C2=A0 =C2=A0 =C2=A0 if target = is not null:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 let recur =3D R(target)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 if recur is not null:
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return recur=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 return R(parent(X))

If you wanted to prevent loops, you could= add the recursion limit there.
=C2=A0
=C2=A0
The argument from you don't need that

As I understand it, the argument for the current algorithm is that it makes it easier for CDNs to deploy CAA records. For instance, if terrier.dog is a CDN serving the terrier community, and they only request certificates from Happy Hacker Fake CA, they can easily express that policy by putting a CAA record on terrier.dog. I would argue that it's just as easy for terrier.dog to configure their authoritative resolver to return a CAA record for *.terrier.dog.

I want to be careful here restricting i= t to the notion of "CDNs", because that limits the discussion to = the Cloudflare/Akamai/Fastly case. I would further advance that it applies = to any form of delegation / multi-stakeholder relationship, as the Twitter = case you point out.

The question is largely one of= operational deployment, and so I fully admit, it's a subjective argume= nt about a future scenario in which we have incomplete data. My hope is to = reduce the failure mode as much as possible, now that sites can reliably de= ploy CAA and expect it to be observed, so that we don't end up in situa= tions where CAA is too complex to deploy.

I apprec= iate you sharing the Twitter case, because I think that speaks to the conce= rns I have with erratum 4515.

Hole punching and the includeSubDomains problem

Part of the debate is informed by deployment difficulties with HPKP includeSubDomains. For instance, in a previous job I deployed HTTPS at Twitter. We configured HPKP preloading with includeSubDomains on twitter.com, inclu= ding all of the CAs that any of our CDNs used.

Sometimes, for example, the marketing department, would hire a contractor to build a quickie website like superbow= l2017.twitter.com. The contractor would have their own relationship with a hosting provider or CDN, who might use a CA not on the list. It would have been nice to be able to define hole punching, so superbowl2017.twitter.com could have its own definition of which CA keys are allowed. That's not possible with HPKP, but it is possible with CAA, intentionally.

However, it's the tree climbing that gets us the hole punching property, not the alternating tree climb / recursion currently specified in RFC 6844. So adopting erratum 4515 would not break the hole punching property.

As yo= u noted elsewhere, to effectively get this scenario, the operator of superbowl2017.twitter.com (which= we'll call example.com) would need = to set up the destination of CNAME in such a way as to be able to appropria= tely express the per-customer policy (if Twitter handles certificate provis= ioning) - that is, sup= erbowl2017.twitter.example.com - =C2=A0or, as you noted, would need to = effectively set the CAA record as a 'wildcard' / for every customer= .

Operationally, I totally accept that erratum 451= 5 can be a clear definition. Practically, I think it creates greater operat= ional deployment challenges for such relationships, and as a result, requir= es greater effort to deploy. In my mind, perhaps incorrectly, it's far = easier to ensure the CAA record on example.c= om than to handle the CAA "trampolining" for every subdomain = or sub-sub-domain that may be necessary.

With recu= rsion, for example, if the marketing provider handled multiple Superbowls, = they might have superb= owl2015.twitter.example.com, superbowl2016.twitter.example.com, superbowl2017.twitter.example.com, and set = the CAA at twitter.example.com (= or, if they handle certificate provisioning, example.com). It makes it one less thing to remember to change. I susp= ect that CDN cases like Cloudflare/Akamai/Fastly would have no challenge wi= th either approach, but I'm very concerned for the long-tail of the eco= system and the challenges it would present.
--94eb2c1ce7fa6804d6054a522f4c-- From nobody Thu Mar 9 13:02:06 2017 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 8DD8B12952B for ; Thu, 9 Mar 2017 13:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 xu0uEftwpc9X for ; Thu, 9 Mar 2017 13:02:03 -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 B2951129534 for ; Thu, 9 Mar 2017 13:01:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1156B3002BC for ; Thu, 9 Mar 2017 16:01:58 -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 4x89umt_OZ_J for ; Thu, 9 Mar 2017 16:01:57 -0500 (EST) Received: from russhousleymbp.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 17420300268 for ; Thu, 9 Mar 2017 16:01:57 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 9 Mar 2017 16:01:56 -0500 References: <2AFA0160-B45D-456E-A642-41863274A7EE@vigilsec.com> To: SPASM In-Reply-To: <2AFA0160-B45D-456E-A642-41863274A7EE@vigilsec.com> Message-Id: <95D2BAF0-EC51-4EFB-889C-C782C4A8FD3E@vigilsec.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-rfc5751-bis-03 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 21:02:04 -0000 I have some WG Last Call comments on draft-ietf-lamps-rfc5751-bis-03. I = have divided my comments into MAJOR and MINOR. MAJOR Do we need to define a way for smimeCapabilities to state support for = AuthEnveloped? I=E2=80=99m trying to avoid interoperability failures. Section 2.1: I see no need to include the MUST for SHA-512 here since = none of the algorithms in Section 2.2 use it. Section 2.7.1.2: I worry about backward compatibility here. This = requires a capability that has never been used in S/MIME before, so it = seems premature to use AES-GCM when the capabilities of the recipient = are unknown. Instead, I would argue that AES-256 CBC offers = implementers so time to deploy authenticated encryption. This looks = like a fine thing for S/MIME 4.1 in a couple of years. Section 5.1: The S/MIME WG is closed. Would it be better to change the = contact to the IESG? MINOR Section 1.2, definition of Data Integrity Service: s/insuring/ensuring/ Section 1.2, definition of Data Confidentiality: s/authorize/authorized/ Section 1.7: there are two missing =E2=80=9C)=E2=80=9D characters Section 2.2: for clarity, please say, "MUST- support RSA PKCS#1 v1.5 = Signature with SHA-256=E2=80=9D for sending and receiving. Section 2.3: for clarity, please say, "MUST- support RSA PKCS#1 v1.5 = Encryption=E2=80=9D. Section 2.7: I think we need to continue to support both AES-128 CBC and = AES-256 CBC as MUST-. (See my comment on Section 2.7.1.2.) Section 3.2.2: s/authEnvelopedData/authEnveloped-data/ (All of the = other names end in =E2=80=9C-data=E2=80=9D.) Section 3.4: s/confidentiality and integrity/confidentiality and data = integrity/ Section 3.4: = s/smime-type=3DauthEnvelopedData/smime-type=3DauthEnveloped-data/ (See = my comment on Section 3.2.2.) Section 4.1: s/RSA signature algorithm/RSA PKCS#1 v1.5 Signature = algorithm/ Section 4.2: s/RSA and RSASSA-PSS signatures/RSA PKCS#1 v1.5 Signature = and RSASSA-PSS signatures/ Section 4.3: s/RSA and RSASSA-PSS signatures/RSA PKCS#1 v1.5 Signature = and RSASSA-PSS signatures/ Section 4.4: s/RSA and RSA-OAEP algorithms/RSA PKCS#1 v1.5 Encryption = and RSA-OAEP algorithms/ Section 4.5: s/RSA and RSA-OAEP algorithms/RSA PKCS#1 v1.5 Encryption = and RSA-OAEP algorithms/ Section 5.3: s/authEnvelopedData/authEnveloped-data/ (See my comment on = Section 3.2.2.) Section 6: s/shared secret when doing encryption/shared secret for = encryption/ Section 6: s/New key key agreement algorithms/New key agreement = algorithms/ Russ From nobody Thu Mar 9 13:07:57 2017 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 683B71294E7 for ; Thu, 9 Mar 2017 13:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=eff.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 TREw1ekQhCNM for ; Thu, 9 Mar 2017 13:07:55 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35CCA12940C for ; Thu, 9 Mar 2017 13:07:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=GSJqW+/rDKx/xhnOg4xAYGvMljyeOPOs3/8HhR7I3JI=; b=5tRC1RRaCbKaCK0a+zxXHi+hgaf8GAJZeR+9GGmMQA40CDvyavmhZFQwZDttLVg7+oTglGNUKCvVU4YiOYnoUiev/18632mcew5TIjsbJ6gx4n+ixxu2R7DxCmuAAEmty018p5mgAPvEohCBtRCZwZWAvOmTGdSnktezNCJ5oj0=; Received: ; Thu, 09 Mar 2017 13:07:56 -0800 To: Ryan Sleevi References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> From: Jacob Hoffman-Andrews Message-ID: <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> Date: Thu, 9 Mar 2017 13:07:53 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------85F20BC0B6CDC39EB1C2F5C4" Received-SPF: skipped for local relay Archived-At: Cc: Patrick Donahue , Gervase Markham , Phillip Hallam-Baker , Peter Bowen , SPASM , Rob Stradling Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 21:07:56 -0000 This is a multi-part message in MIME format. --------------85F20BC0B6CDC39EB1C2F5C4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/09/2017 12:35 PM, Ryan Sleevi wrote: > I want to be careful here restricting it to the notion of "CDNs", I'm using CDN as a shorthand for "hosting provider or CDN." In the Twitter example, the other stakeholders are the marketing department and the contractor who develops the web content, neither of whom have CNAMEs in the mix. Is there another entity type I'm missing? > *Hole punching and the includeSubDomains problem* > > As you noted elsewhere, to effectively get this scenario, the operator > of superbowl2017.twitter.com (which > we'll call example.com ) would need to set up the > destination of CNAME in such a way as to be able to appropriately > express the per-customer policy (if Twitter handles certificate > provisioning) - that is, superbowl2017.twitter.example.com > - or, as you noted, would > need to effectively set the CAA record as a 'wildcard' / for every > customer. I don't understand why example.com would need to set a per-customer policy. If terrier.dog handles certificates for their customers, they would do so with a limited set of CAs, and could set that as policy on their domain names. If a specified customer like www.staffie.dog needs a different policy, they can set it on their own hostname: www.staffie.dog. CAA 0 issue "sad-hacker-totally-real-ca.net" I don't think trampolining is necessary to make this work. If terrier.dog doesn't handle certificates, e.g., if they expect customers to bring their own cert from any CA, then they can't reasonably set a blanket policy for all their customers. In that situation, I think it would similarly be up to the customer to set a CAA policy on their own hostname if they wanted one, since the customer is the one with the CA relationship. --------------85F20BC0B6CDC39EB1C2F5C4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 03/09/2017 12:35 PM, Ryan Sleevi wrote:
I want to be careful here restricting it to the notion of "CDNs",
I'm using CDN as a shorthand for "hosting provider or CDN." In the Twitter example, the other stakeholders are the marketing department and the contractor who develops the web content, neither of whom have CNAMEs in the mix. Is there another entity type I'm missing?

Hole punching and the includeSubDomains problem
As you noted elsewhere, to effectively get this scenario, the operator of superbowl2017.twitter.com (which we'll call example.com) would need to set up the destination of CNAME in such a way as to be able to appropriately express the per-customer policy (if Twitter handles certificate provisioning) - that is, superbowl2017.twitter.example.com -  or, as you noted, would need to effectively set the CAA record as a 'wildcard' / for every customer.
I don't understand why example.com would need to set a per-customer policy. If terrier.dog handles certificates for their customers, they would do so with a limited set of CAs, and could set that as policy on their domain names. If a specified customer like www.staffie.dog needs a different policy, they can set it on their own hostname:

www.staffie.dog.        CAA 0 issue "sad-hacker-totally-real-ca.net"

I don't think trampolining is necessary to make this work.

If terrier.dog doesn't handle certificates, e.g., if they expect customers to bring their own cert from any CA, then they can't reasonably set a blanket policy for all their customers. In that situation, I think it would similarly be up to the customer to set a CAA policy on their own hostname if they wanted one, since the customer is the one with the CA relationship.

--------------85F20BC0B6CDC39EB1C2F5C4-- From nobody Thu Mar 9 13:45:31 2017 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 D613F1294FB for ; Thu, 9 Mar 2017 13:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 EV_3Ofc7MDVg for ; Thu, 9 Mar 2017 13:45:28 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 16929129498 for ; Thu, 9 Mar 2017 13:45:28 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id 1so140990550qkl.3 for ; Thu, 09 Mar 2017 13:45:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Hw2wzzldfF0UF8kcZZ9ZqVHwAATq1GQ6h1i19z4Hx4U=; b=dMClh/oy71PWT8IuZGbp9+HD1hveaYY9QWaou4z2WfyQhdizGtkqg3I77hIU+/l0pf uFkz1UPopMNP1GFqNDcyzy6IlSl9IW6yYqIiJP1DoKaNolrUjAtglfN6G5ChBfBYeucC KFy3UYxvDNILQtZhWZGFyrunq54VuuTH1uZyU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Hw2wzzldfF0UF8kcZZ9ZqVHwAATq1GQ6h1i19z4Hx4U=; b=cAORqrfY5reyjdZqrO9Ae60OR+IB3nOlLGL468u+T9RUAqgCoj18Hm6pJXpH1m0y1Q eh4pPw6BDmnowiFhMK4gAvG9xf4m1sl3XHX0Jb4m+fnM7UJ8raYW254kHMPrqA8JGQ84 seFR4/6zRZnRt/kYzPTjQV0AyjtxgVvjA1NobB7Cpc778V+ospPkRoaENP5s3miKVO9c uxeRNAbp5DFhDXN+DgzE/MtnvC5h4RLHCSAgIg7wJxPHEBKBlc5wJ4k3D8AW0ObLE1/l K7VzVthICh1tl4XOy7oOQy2tNuTL1PW2+3F9ya9h2WG63TP5/c/Ik4wwTiYKN3Q2zScV CbJQ== X-Gm-Message-State: AMke39lUTh/LvQ2Mfv8U55EGmXmUgKmEMBM10suutWN4YKFNM0mxo/J0x8OFC2guaFmOqZgWy7Prf5CjulWr5bhX X-Received: by 10.55.64.139 with SMTP id n133mr15732231qka.38.1489095927076; Thu, 09 Mar 2017 13:45:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.94.48 with HTTP; Thu, 9 Mar 2017 13:45:26 -0800 (PST) In-Reply-To: <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> From: Patrick Donahue Date: Thu, 9 Mar 2017 13:45:26 -0800 Message-ID: To: Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary=001a114897b4c5319d054a53290e Archived-At: Cc: Gervase Markham , Phillip Hallam-Baker , Ryan Sleevi , Peter Bowen , SPASM , Rob Stradling Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 21:45:30 -0000 --001a114897b4c5319d054a53290e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've previously shared my thoughts on this topic here: https://cabforum.org/pipermail/public/2017-February/009850.html. With respect to Jacob's initial tee-up: www.staffie.dog. CNAME staffie.terrier.dog. staffie.terrier.dog. A 192.0.2.1 terrier.dog. CAA 0 issue "happy-hacker-fake-ca.net" Should issuance for www.staffie.dog require a CAA query for terrier.dog? Or > should it only require CAA queries for www.staffie.dog and > staffie.terrier.dog? I'm a bit confused here as I would say "no" to the first question and I would say that staffie.terrier.dog is irrelevant in the second part of the question (but a CA may need to check staffie.dog if nothing set at www.staffie.dog). Can someone explain why the issuance check would need to do anything other than: 1. Look up CAA record for www.staffie.dog. 1. If present 1. Pass/fail based on contents. 2. Else (i.e., if not present) 1. Look up CAA record for staffie.dog. 1. If present, pass/fail based on contents. 2. If not present, pass. If you control where www.staffie.dog points, you can do anything you want with it content-wise. Why are we proposing tying certificate issuance to the underlying (hosting provider/CDN/whatever) implementation? If CAs are required to look up intermediate hostnames that are part of the CNAME chain, we=E2=80=94as a large managed DNS provider=E2=80=94will be far= less likely to encourage CAA adoption and build tools to facilitate it. Otherwise we risk not being able to issue certificates for our non-authoritative DNS customers and, as a result, provide a poorer user experience while simultaneously increasing our support costs. For example, I've had calls the past couple of weeks with SaaS customers that provide their app to hundreds of thousands of their end-customers on a "vanity" hostname, e.g., app.saas-customer.com (rather than a non-"vanity" hostname such as saas-customer.cloudflare-customer.com) During onboarding, our customer instructs their end-customer to CNAME the subdomain "app" (or whatever) to customers.cloudflare-customer.com, which is reverse proxied through our network and thus facilitates doing HTTP DCV at /.well-known/pki. Why should cloudflare-customer.com's CA preferences for their own domain affect what certificates their end-customer can receive? On Thu, Mar 9, 2017 at 1:07 PM, Jacob Hoffman-Andrews wrote: > On 03/09/2017 12:35 PM, Ryan Sleevi wrote: > > I want to be careful here restricting it to the notion of "CDNs", > > I'm using CDN as a shorthand for "hosting provider or CDN." In the Twitte= r > example, the other stakeholders are the marketing department and the > contractor who develops the web content, neither of whom have CNAMEs in t= he > mix. Is there another entity type I'm missing? > > *Hole punching and the includeSubDomains problem* >> > As you noted elsewhere, to effectively get this scenario, the operator of > superbowl2017.twitter.com (which we'll call example.com) would need to > set up the destination of CNAME in such a way as to be able to > appropriately express the per-customer policy (if Twitter handles > certificate provisioning) - that is, superbowl2017.twitter.example.com - > or, as you noted, would need to effectively set the CAA record as a > 'wildcard' / for every customer. > > I don't understand why example.com would need to set a per-customer > policy. If terrier.dog handles certificates for their customers, they wou= ld > do so with a limited set of CAs, and could set that as policy on their > domain names. If a specified customer like www.staffie.dog needs a > different policy, they can set it on their own hostname: > > www.staffie.dog. CAA 0 issue "sad-hacker-totally-real-ca.net" > > > I don't think trampolining is necessary to make this work. > > If terrier.dog doesn't handle certificates, e.g., if they expect customer= s > to bring their own cert from any CA, then they can't reasonably set a > blanket policy for all their customers. In that situation, I think it wou= ld > similarly be up to the customer to set a CAA policy on their own hostname > if they wanted one, since the customer is the one with the CA relationshi= p. > > --=20 Patrick R. Donahue pat@cloudflare.com PGP Fingerprint: 2E8D 5A38 682E EC00 C0F3 E7F2 D9BE 68D2 ABF3 6B24 --001a114897b4c5319d054a53290e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've previously shared my thoughts on this topic here:= https://cabforum.org/pipermail/public/2017-February/009850.html.
=
With respect to Jacob's initial tee-up:

www.staffie.dog. =C2=A0 =C2=A0= =C2=A0 =C2=A0CNAME staffie.terrier.dog.
staffie.terrier.dog. =C2=A0 =C2= =A0A 192.0.2.1
terrier.dog. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CAA= 0 issue "happy-hacker-fak= e-ca.net"


Should issuance for www.staffie.dog require a= CAA query for terrier.dog? Or should it only require CAA queries for www.s= taffie.dog and staffie.terrier.dog?

I= 'm a bit confused here as I would say "no" to the first quest= ion and I would say that staffie.terrier.dog is irrelevant in the second pa= rt of the question (but a CA may need to check staffie.dog if nothing set a= t www.staffie.dog).

Can someone explain why the is= suance check would need to do anything other than:
  1. Look u= p CAA record for www.staffie.dog.
    1. If present
      1. Pa= ss/fail based on contents.
    2. Else (i.e., if not present)
    3. Look up CAA record for staffie.dog.
      1. If present, pass/fail = based on contents.
      2. If not present, pass.

If you control where www.staffie.dog points, you can do a= nything you want with it content-wise. Why are we proposing tying certifica= te issuance to the underlying (hosting provider/CDN/whatever) implementatio= n?=C2=A0

If CAs are required to look up intermedia= te hostnames that are part of the CNAME chain, we=E2=80=94as a large manage= d DNS provider=E2=80=94will be far less likely to encourage CAA adoption an= d build tools to facilitate it. Otherwise we risk not being able to issue c= ertificates for our non-authoritative DNS customers and, as a result, provi= de a poorer user experience while simultaneously increasing our support cos= ts.

For example, I've had calls the past= couple of weeks with SaaS customers that provide their app to hundreds of = thousands of their end-customers on a "vanity" hostname, e.g., app.saas-customer.com (rather th= an a non-"vanity" hostname such as saas-customer.cloudflare-customer.com)
=

During onboarding, our customer instructs their end-cus= tomer to CNAME the subdomain "app" (or whatever) to customers.cloudflare-customer.com, which is reverse proxied through our network and thus facilitates doing= HTTP DCV at /.well-known/pki. Why should cloudflare-customer.com's CA preferences for their own do= main affect what certificates their end-customer can receive?

On Thu, Mar 9, 2017= at 1:07 PM, Jacob Hoffman-Andrews <jsha@eff.org> wrote:
=20 =20 =20
On 03/09/2017 12:35 PM, Ryan Sleevi wrote:
I want to be careful here restricting it to the notion of "CDNs",
 I'm using CDN as a shorthand for "hosting provider or CDN.&quo= t; In the Twitter example, the other stakeholders are the marketing department and the contractor who develops the web content, neither of whom have CNAMEs in the mix. Is there another entity type I'm missing?
Hole punching and the includeSubDomains problem
As you noted elsewhere, to effectively get this scenario, the operator of superbowl2017.twitter.com (which we'll call example.com) would need to set up the destination of CNAME in such a way as to be able to appropriately express the per-customer policy (if Twitter handles certificate provisioning) - that is, superbowl20= 17.twitter.example.com - =C2=A0or, as you noted, would need to effectively set the C= AA record as a 'wildcard' / for every customer.
I don't understand why example.com would need to set a per-customer policy. If terrier.dog handles certificates for their customers, they would do so with a limited set of CAs, and could set that as policy on their domain names. If a specified customer like www.staffie.dog needs a differen= t policy, they can set it on their own hostname:

www.staffie.dog.        CAA 0 is=
sue "sad-hacker-totally-real-ca.net"

I don't think trampolining is necessary to make this work.

If terrier.dog doesn't handle certificates, e.g., if they expect customers to bring their own cert from any CA, then they can't reasonably set a blanket policy for all their customers. In that situation, I think it would similarly be up to the customer to set a CAA policy on their own hostname if they wanted one, since the customer is the one with the CA relationship.




--
Patrick R. Donahue

PGP Fingerprint: 2E8D 5A38 682E EC00 C0F3 =C2=A0E7F2 D9BE 68D2 ABF= 3 6B24
--001a114897b4c5319d054a53290e-- From nobody Thu Mar 9 13:57:08 2017 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 59B42129443 for ; Thu, 9 Mar 2017 13:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=eff.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 KxYVDT77x8NM for ; Thu, 9 Mar 2017 13:57:04 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9081129420 for ; Thu, 9 Mar 2017 13:57:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=6T0nINTw6hSOM8ZrbvaEpYT41e8BU8GHnO3YkjIRTj0=; b=Qm2RoYXn6v/FG9HFrFi/MvPgNBJLPA/o332638bKaRj6z36CGu7UuUQLPoIVzaH8/Iy2utTSrNT/T9ikIBuHYeqhbEv0QeV4xTeus3XHT3EF801iy7GBymqx1vR+U+xbzQK/hZRVLApOoRIDukowVP58/+yX8cExDuLcMeiZdP0=; Received: ; Thu, 09 Mar 2017 13:57:05 -0800 To: Patrick Donahue References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> From: Jacob Hoffman-Andrews Message-ID: <1a31c80e-cabb-91ee-5768-683f98aa942d@eff.org> Date: Thu, 9 Mar 2017 13:57:02 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FAEEE18E6CDA12A0AFB9675A" Received-SPF: skipped for local relay Archived-At: Cc: Gervase Markham , Phillip Hallam-Baker , Ryan Sleevi , Peter Bowen , SPASM , Rob Stradling Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 09 Mar 2017 21:57:06 -0000 This is a multi-part message in MIME format. --------------FAEEE18E6CDA12A0AFB9675A Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/09/2017 01:45 PM, Patrick Donahue wrote: > www.staffie.dog. CNAME staffie.terrier.dog. > staffie.terrier.dog. A 192.0.2.1 > terrier.dog. CAA 0 issue "happy-hacker-fake-ca.net > " > > > Should issuance for www.staffie.dog require a CAA query for > terrier.dog? Or should it only require CAA queries for > www.staffie.dog and staffie.terrier.dog? > > > I'm a bit confused here as I would say "no" to the first question and > I would say that staffie.terrier.dog is irrelevant in the second part > of the question (but a CA may need to check staffie.dog if nothing set > at www.staffie.dog). Sorry, I was a little fuzzy in my language here. There are two questions: What queries does the CA make to its recursive resolver, and what queries does the recursive resolver make? If the CA queries "CAA www.staffie.dog.", the recursive resolver will query the authoritative resolver for "CAA www.staffie.dog." Failing to find it, the recursive resolver will then query the authoritative resolver for "CNAME www.staffie.dog." The recursive resolver will follow a sequence of CNAMEs, querying CAA (but not tree-climbing) at each step. In this case there's just one step, and the recursive resolver queries the authoritative resolver for "CAA staffie.terrier.dog." The recursive resolver includes the result in its response to the CA software. This is defined in RFC 1034 about DNS in general: https://tools.ietf.org/html/rfc1034#section-3.6.2 > CNAME RRs cause special action in DNS software. When a name server > fails to find a desired RR in the resource set associated with the > domain name, it checks to see if the resource set consists of a CNAME > record with a matching class. If so, the name server includes the CNAM= E > record in the response and restarts the query at the domain name > specified in the data field of the CNAME record. The one exception to > this rule is that queries which match the CNAME type are not restarted.= In other words, one CAA query to a recursive resolver can trigger multiple CAA queries from the recursive resolver to the authoritative resolver. --------------FAEEE18E6CDA12A0AFB9675A Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 03/09/2017 01:45 PM, Patrick Donahue wrote:
www.staffie.dog.        CNAME staffie.terrier.dog.
staffie.terrier.dog.    A 192.0.2.1
terrier.dog.            CAA 0 issue "happy-hacker-fake-ca.net"


Should issuance for www.staffie.dog require a CAA query for terrier.dog? Or should it only require CAA queries for www.staffie.dog and staffie.terrier.dog?

I'm a bit confused here as I would say "no" to the first question and I would say that staffie.terrier.dog is irrelevant in the second part of the question (but a CA may need to check staffie.dog if nothing set at www.staffie.dog).
Sorry, I was a little fuzzy in my language here. There are two questions: What queries does the CA make to its recursive resolver, and what queries does the recursive resolver make?

If the CA queries "CAA www.staffie.dog.", the recursive resolver will query the authoritative resolver for "CAA www.staffie.dog." Failing to find it, the recursive resolver will then query the authoritative resolver for "CNAME www.staffie.dog." The recursive resolver will follow a sequence of CNAMEs, querying CAA (but not tree-climbing) at each step. In this case there's just one step, and the recursive resolver queries the authoritative resolver for "CAA staffie.terrier.dog." The recursive resolver includes the result in its response to the CA software. This is defined in RFC 1034 about DNS in general:

https://tools.ietf.org/html/rfc1034#section-3.6.2
CNAME RRs cause special action in DNS software.  When a name server
fails to find a desired RR in the resource set associated with the
domain name, it checks to see if the resource set consists of a CNAME
record with a matching class.  If so, the name server includes the CNAME
record in the response and restarts the query at the domain name
specified in the data field of the CNAME record.  The one exception to
this rule is that queries which match the CNAME type are not restarted.

In other words, one CAA query to a recursive resolver can trigger multiple CAA queries from the recursive resolver to the authoritative resolver.
--------------FAEEE18E6CDA12A0AFB9675A-- From nobody Thu Mar 9 18:25:22 2017 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 5D9EC129477 for ; Thu, 9 Mar 2017 18:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bpGzyp7Xt4g for ; Thu, 9 Mar 2017 18:25:11 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id A061B1294CF for ; Thu, 9 Mar 2017 18:25:01 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1A4C5496C0A; Thu, 9 Mar 2017 22:46:35 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 045D1496C03; Thu, 9 Mar 2017 22:46:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489099595; bh=qIA4i5ayaph+PwUMdHkqV1Nl/GqYM7xczCw2mC8CXBM=; l=330; h=From:To:CC:Date:References:In-Reply-To:From; b=SaBqg4nUG8rk4jXb7KtwWDrWfO3DVqb9ilL/oTkgwjc6qpoUcXQ7H/xM9fcHps5YE Ajc/kG3k0ViLB4wR93RiO6LZZxPtbiz4pDZnBYGAkg5XR96IoOXf/ItW3aWYPsoyiF 3Ujov400z5XlHI/Z7XjpFhZn7p2VqnRjB78+8ZP4= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id DF40E98084; Thu, 9 Mar 2017 22:46:34 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 9 Mar 2017 17:46:34 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Thu, 9 Mar 2017 17:46:34 -0500 From: "Salz, Rich" To: Russ Housley Thread-Topic: [Spasm] An OCSP response extension Thread-Index: AdKY7ibhb+2MVJgFQpGlF716EDcwsAALWSSAAApWhUAAE+/dcP//KjoAgABToiD//7NmAIAADUyAgAAZ6OA= Date: Thu, 9 Mar 2017 22:46:33 +0000 Message-ID: <7a8b7349a2ce4629bf8f1c89b65c0461@usma1ex-dag1mb1.msg.corp.akamai.com> References: <7B492EB7-CC0D-4706-85AC-8844F5BCF847@vigilsec.com> <244b0812054a41598425c6cdbf511392@usma1ex-dag1mb1.msg.corp.akamai.com> <6d9976eb3fdd4bb2840a5d91ee66eec2@usma1ex-dag1mb1.msg.corp.akamai.com> <2CDB8533-CB33-484A-AAB2-FD8FD0CB8D74@vigilsec.com> In-Reply-To: <2CDB8533-CB33-484A-AAB2-FD8FD0CB8D74@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.72] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: SPASM Subject: Re: [Spasm] An OCSP response extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 02:25:18 -0000 PiBpZC1wa2l4LW9jc3AtcmV2b2tlLWhpbnQgT0JKRUNUIElERU5USUZJRVIgOjo9IHsgaWQtcGtp eC1vY3NwIFRCRCB9DQo+IA0KPiByZS1vY3NwLXJldm9rZS1oaW50IEVYVEVOU0lPTiB7IFNZTlRB WCBVVEY4U3RyaW5nDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSURFTlRJRklF RCBCWSBpZC1wa2l4LW9jc3AtcmV2b2tlLWhpbnQgfQ0KDQpUaGF0IG1ha2VzIGEgbG90IG9mIHNl bnNlIHRvIG1lLg0K From nobody Thu Mar 9 18:39:34 2017 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 156C212943B for ; Thu, 9 Mar 2017 18:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 PAQAu66RNQT1 for ; Thu, 9 Mar 2017 18:39:30 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 702771294C3 for ; Thu, 9 Mar 2017 18:39:28 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id v125so146496621qkh.2 for ; Thu, 09 Mar 2017 18:39:28 -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=tNzTCJ9utjjDTaU5p4ThZjOVnhebJSj5ZqecBtt5G/M=; b=aUx/FroDn9gDAyBwTv8fr8i9c20OEdInJl7qsd97y0InuiOQvkcEa/H/V9SN1gOeSm 7NdyR2cKv3CEn580eoWjqE20jU95+m64VEXWGPqESWAuCgZ7ueF75tYe97w2YgSCOaVw XdTSyNUEwSl88pDvnwTpEgvrD5TpBwVw2xMEs= 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=tNzTCJ9utjjDTaU5p4ThZjOVnhebJSj5ZqecBtt5G/M=; b=TI6TNj2lfR+XtAxXvkPNm1k1RzcxBS4Tdq3rZSWrgrQ7tOYSm1clISgukOEjcP1SJh 0cfhzd7U3gMBD+A9V4K3Kk0s1Puj93NvSI16occQAJ4pkTqmrl2UfW8SK1rPqnWQvu28 gfxtK3NccmfFlLDSiy2rskKid+AuWbvQ1l9anWx7PdpKH7CUG0SyigHaB9oMxlYoaZL+ RkNlqh3EzJmjLnjSghtMLWEqr8uHCTPFHdqk5MOgDKDL2o+slFU1QrVxRk5pGFY/iSwd xlJwQLi2M8EKzgmAP3fcGidscsgW34Vo/dBpMUAcB3pi9Z8ZR3zE6W5MQHe1ojnzM+s/ xYAg== X-Gm-Message-State: AFeK/H0F/GdHrpU3nlKjKuNZN5ua6ByCg2UxSFAL6k9jSnn13GleYqjRHCgkCkc4ObSnzw== X-Received: by 10.55.71.206 with SMTP id u197mr18040935qka.122.1489111993803; Thu, 09 Mar 2017 18:13:13 -0800 (PST) Received: from [172.16.0.18] ([96.231.228.203]) by smtp.gmail.com with ESMTPSA id s22sm5530066qts.10.2017.03.09.18.13.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 18:13:12 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Sean Turner In-Reply-To: <2CDB8533-CB33-484A-AAB2-FD8FD0CB8D74@vigilsec.com> Date: Thu, 9 Mar 2017 21:13:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6FC056E9-C31E-4E49-B9D8-63DC19AD419A@sn3rd.com> References: <7B492EB7-CC0D-4706-85AC-8844F5BCF847@vigilsec.com> <244b0812054a41598425c6cdbf511392@usma1ex-dag1mb1.msg.corp.akamai.com> <6d9976eb3fdd4bb2840a5d91ee66eec2@usma1ex-dag1mb1.msg.corp.akamai.com> <2CDB8533-CB33-484A-AAB2-FD8FD0CB8D74@vigilsec.com> To: Rich Salz X-Mailer: Apple Mail (2.3259) Archived-At: Cc: SPASM Subject: Re: [Spasm] An OCSP response extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 02:39:33 -0000 On Mar 9, 2017, at 2:19 PM, Russ Housley wrote: >=20 >=20 >>> I'd only use it for revoked status. >>=20 >> Ah, I didn't get that point and, with that understanding, have no = objection. >=20 > If that is the intended us, I=E2=80=99d suggest: >=20 > id-pkix-ocsp-revoke-hint OBJECT IDENTIFIER ::=3D { id-pkix-ocsp TBD } >=20 > re-ocsp-revoke-hint EXTENSION { SYNTAX UTF8String > IDENTIFIED BY id-pkix-ocsp-revoke-hint = } >=20 If this is going to be get widely implemented should we look at updating = RFC5019 which says: "The responder SHOULD NOT include responseExtensions=E2=80=9D? spt= From nobody Thu Mar 9 19:15:30 2017 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 CA693129552 for ; Thu, 9 Mar 2017 19:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 iJ9sW5wIWzrE for ; Thu, 9 Mar 2017 19:15:28 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE6E6129547 for ; Thu, 9 Mar 2017 19:15:27 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id AB2DDA004F17 for ; Thu, 9 Mar 2017 19:15:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=nrSYJ226lbnQx+sxj0meqs9g9Os=; b= CetGqI42WW4/R2F4I1bgc2gGlQU1qqQ0tZ9TArju30gKzQvQtR3WatAznQoyyBRg 1ATMFW39LWQHzDaRenYrW8gXm0Oc8L8dyvGXj32HCETtYjvKApCT2x2bsoptzDji 3pfmeIqbXmQCetWBMR4q1gFzpU2A00+JCEIMqSIY5aA= Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com [209.85.215.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 6039AA004F15 for ; Thu, 9 Mar 2017 19:15:27 -0800 (PST) Received: by mail-lf0-f48.google.com with SMTP id a6so35926868lfa.0 for ; Thu, 09 Mar 2017 19:15:27 -0800 (PST) X-Gm-Message-State: AMke39lE1dKhOAe1AT2xoABHWv+IvCtQtm8pBaqnms44qt77bvglvChTM9LK7LAvVDeimlyryGHV5o6lXMtM7g== X-Received: by 10.25.0.207 with SMTP id 198mr4282102lfa.134.1489115725606; Thu, 09 Mar 2017 19:15:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.193.197 with HTTP; Thu, 9 Mar 2017 19:15:24 -0800 (PST) In-Reply-To: <6FC056E9-C31E-4E49-B9D8-63DC19AD419A@sn3rd.com> References: <7B492EB7-CC0D-4706-85AC-8844F5BCF847@vigilsec.com> <244b0812054a41598425c6cdbf511392@usma1ex-dag1mb1.msg.corp.akamai.com> <6d9976eb3fdd4bb2840a5d91ee66eec2@usma1ex-dag1mb1.msg.corp.akamai.com> <2CDB8533-CB33-484A-AAB2-FD8FD0CB8D74@vigilsec.com> <6FC056E9-C31E-4E49-B9D8-63DC19AD419A@sn3rd.com> From: Ryan Sleevi Date: Thu, 9 Mar 2017 22:15:24 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=001a113c9f48dabc79054a57c556 Archived-At: Cc: SPASM , Rich Salz Subject: Re: [Spasm] An OCSP response extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 03:15:29 -0000 --001a113c9f48dabc79054a57c556 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 9, 2017 at 9:13 PM, Sean Turner wrote: > If this is going to be get widely implemented should we look at updating > RFC5019 which says: > "The responder SHOULD NOT include responseExtensions=E2=80=9D? > How do you see "widely implemented"? I mentioned to Rich privately, but I think this is something that the CA/Browser Forum should consider profiling out and expressly forbidding for the time being, and if later ended up valuable (e.g. in the context of must-staple certificates), would need to aggressively profile the acceptable values suitable for the Web PKI. In the context of other PKIs, however, I have no thought and experience to inform on the value of that, which is why I was asking about "widely implemented" - for example, if used by the FPKI or Grid PKI, would that be "widely implemented"? If 5019 dropped the SHOULD NOT for that reason, would the CA/B Forum need to profile it back in for the Web PKI? --001a113c9f48dabc79054a57c556 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 9, 2017 at 9:13 PM, Sean Turner <sean@sn3rd.com> wrote:
If this is going to be get widel= y implemented should we look at updating RFC5019 which says:
"The responder SHOULD NOT include responseExtensions=E2=80=9D?

How do you see "widely implemented"?=

I mentioned to Rich privately, but I think this i= s something that the CA/Browser Forum should consider profiling out and exp= ressly forbidding for the time being, and if later ended up valuable (e.g. = in the context of must-staple certificates), would need to aggressively pro= file the acceptable values suitable for the Web PKI.

In the context of other PKIs, however, I have no thought and experience = to inform on the value of that, which is why I was asking about "widel= y implemented" - for example, if used by the FPKI or Grid PKI, would t= hat be "widely implemented"? If 5019 dropped the SHOULD NOT for t= hat reason, would the CA/B Forum need to profile it back in for the Web PKI= ?
--001a113c9f48dabc79054a57c556-- From nobody Thu Mar 9 23:36:22 2017 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 8A1681295DD for ; Thu, 9 Mar 2017 23:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9G0edg2MY0mq for ; Thu, 9 Mar 2017 23:36:12 -0800 (PST) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 137AC1295D9 for ; Thu, 9 Mar 2017 23:36:10 -0800 (PST) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1489131362; h=from:subject:to:date:message-id; bh=eS+6L5LWSfLbG+5AiPTAAdeLbn/zQ22aN1gSsZVN5dM=; b=BFErpI5hhDqwwszBx7Qa/xK1gQG2IM/dfjz1uSarXjgfqqekY7/f4vKpsF+d0iZCXG0WG1LZ7ik wn9ELaNb1cDyNtafv5NMgcqleTqt5pPbHBV51RlIspGzzT4Hpe3o1JW6jY6gPTGufkYhIW959tFGq 5tnL5+eMIhr6ibuxAY2BfirEf2OKgSPQsYSB0SB5YSFgYTx5E8SY2GkM7RjdSc8YO51GlfXW8RjvE wk/5EqTmsG4QJsfLXNJ1gT3KnnQiNp2gFY6TtRoQNnYHKoUdVhZf6XYTcd110vr/OmmFKFQqQ4C/U QqtAtzoEmQLkEckJQ1EiFRr5msSbtFJWnL0w== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 9 Mar 2017 23:36:01 -0800 Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 9 Mar 2017 23:33:50 -0800 From: Jim Schaad To: 'Russ Housley' , 'SPASM' References: <2AFA0160-B45D-456E-A642-41863274A7EE@vigilsec.com> <95D2BAF0-EC51-4EFB-889C-C782C4A8FD3E@vigilsec.com> In-Reply-To: <95D2BAF0-EC51-4EFB-889C-C782C4A8FD3E@vigilsec.com> Date: Thu, 9 Mar 2017 23:36:02 -0800 Message-ID: <0a1601d29970$f9d5a200$ed80e600$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKLbLtO5xvmCpSqnexK1ZviUGvIIwJZ9TSsoAkwU9A= X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-rfc5751-bis-03 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 07:36:20 -0000 > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley > Sent: Thursday, March 9, 2017 1:02 PM > To: SPASM > Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-rfc5751-bis-03 >=20 > I have some WG Last Call comments on draft-ietf-lamps-rfc5751-bis-03. = I > have divided my comments into MAJOR and MINOR. >=20 >=20 > MAJOR >=20 > Do we need to define a way for smimeCapabilities to state support for > AuthEnveloped? I=E2=80=99m trying to avoid interoperability failures. We have that. If you support an AEAD algorithm then you must support = AuthEnveloped by definition. >=20 > Section 2.1: I see no need to include the MUST for SHA-512 here since = none > of the algorithms in Section 2.2 use it. This is to get a match for EdDSA w/ curve 25519. That uses SHA-512 = internally so that the correct match would be to use SHA-512 for the = external as well. >=20 > Section 2.7.1.2: I worry about backward compatibility here. This = requires a > capability that has never been used in S/MIME before, so it seems = premature > to use AES-GCM when the capabilities of the recipient are unknown. = Instead, > I would argue that AES-256 CBC offers implementers so time to deploy > authenticated encryption. This looks like a fine thing for S/MIME 4.1 = in a > couple of years. This has been the traditional wording over the last three versions of = the document. Only for 3851 was it clear that the algorithm existed as = a possibility prior to the version being released. The group has = normally recommended using the best algorithm here but permitted to use = of a different algorithm. I think there is sufficient guidance in the = text about why GCM was chosen and it allows for either it or AES-128 CBC = to be used. >=20 > Section 5.1: The S/MIME WG is closed. Would it be better to change = the > contact to the IESG? I thought about this and did not do it, but yes it makes sense. I = wonder how many people have used the contact, but as I am not on this = alias I would not know.=20 Jim >=20 >=20 > MINOR >=20 > Section 1.2, definition of Data Integrity Service: = s/insuring/ensuring/ >=20 > Section 1.2, definition of Data Confidentiality: = s/authorize/authorized/ >=20 > Section 1.7: there are two missing =E2=80=9C)=E2=80=9D characters >=20 > Section 2.2: for clarity, please say, "MUST- support RSA PKCS#1 v1.5 > Signature with SHA-256=E2=80=9D for sending and receiving. >=20 > Section 2.3: for clarity, please say, "MUST- support RSA PKCS#1 v1.5 > Encryption=E2=80=9D. >=20 > Section 2.7: I think we need to continue to support both AES-128 CBC = and > AES-256 CBC as MUST-. (See my comment on Section 2.7.1.2.) >=20 > Section 3.2.2: s/authEnvelopedData/authEnveloped-data/ (All of the = other > names end in =E2=80=9C-data=E2=80=9D.) >=20 > Section 3.4: s/confidentiality and integrity/confidentiality and data = integrity/ >=20 > Section 3.4: = s/smime-type=3DauthEnvelopedData/smime-type=3DauthEnveloped- > data/ (See my comment on Section 3.2.2.) >=20 > Section 4.1: s/RSA signature algorithm/RSA PKCS#1 v1.5 Signature = algorithm/ >=20 > Section 4.2: s/RSA and RSASSA-PSS signatures/RSA PKCS#1 v1.5 Signature = and > RSASSA-PSS signatures/ >=20 > Section 4.3: s/RSA and RSASSA-PSS signatures/RSA PKCS#1 v1.5 Signature = and > RSASSA-PSS signatures/ >=20 > Section 4.4: s/RSA and RSA-OAEP algorithms/RSA PKCS#1 v1.5 Encryption > and RSA-OAEP algorithms/ >=20 > Section 4.5: s/RSA and RSA-OAEP algorithms/RSA PKCS#1 v1.5 Encryption > and RSA-OAEP algorithms/ >=20 > Section 5.3: s/authEnvelopedData/authEnveloped-data/ (See my comment > on Section 3.2.2.) >=20 > Section 6: s/shared secret when doing encryption/shared secret for > encryption/ >=20 > Section 6: s/New key key agreement algorithms/New key agreement > algorithms/ >=20 > Russ >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Thu Mar 9 23:37:27 2017 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 1D1A51295D5 for ; Thu, 9 Mar 2017 23:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7S_7EsNqUNzi for ; Thu, 9 Mar 2017 23:37:24 -0800 (PST) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F30E8129476 for ; Thu, 9 Mar 2017 23:37:23 -0800 (PST) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1489131436; h=from:subject:to:date:message-id; bh=B3i0ewhGg90EN9BKuqJgDp6rbkLD9BY1OpidZFSY/Xg=; b=MR3l73QWjw86NKeG40JOU91YX+FPHRa48hddSe+Ec6qESzc9u7z/B5b1Ko4lkKdmqVsLXjBPeWF n0R1kyNPwh6g4kAseeK83uddMXN0ICgUaoktoawKCFsrWo3OUZKCNIBX8KZXn8o5haOEDWmLx4V2x 9ZYgdRJoh37LP8i1jHeXx099WH8gGoe4+ykfsTnLBGzq8Yb8YrGAPHnOl+FX8a8n2KzZY1G4+YOa3 JgqsADIgxAbOKqi99yW6g+3hDKUb22ama4V4F9924aySiqpw+bTq+/ffGUnVsF3IUCx6Bxx9AwdEc 1RgnJsyfM151EyCga7umiJr5UtPaEZoFhXHg== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 9 Mar 2017 23:37:15 -0800 Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 9 Mar 2017 23:35:04 -0800 From: Jim Schaad To: 'Russ Housley' , 'Sean Turner' References: <531F42E9-E7B2-4A40-B373-F616A4076FC2@vigilsec.com> In-Reply-To: <531F42E9-E7B2-4A40-B373-F616A4076FC2@vigilsec.com> Date: Thu, 9 Mar 2017 23:37:16 -0800 Message-ID: <0a1701d29971$25d620f0$718262d0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQD+TH9fg70r2/ftM1SZZBQE/vYlQwLsZVxYox4Y3CA= X-Originating-IP: [24.21.96.37] Archived-At: Cc: 'SPASM' Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-rfc5750-bis-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 07:37:25 -0000 > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley > Sent: Thursday, March 9, 2017 9:43 AM > To: SPASM > Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-rfc5750-bis-02 >=20 > I think that the document is in very good shape, and it is ready to go = to the > IESG. I have a few minor suggestions for improvements. >=20 > I am not sure what this paragraph in Section 4.3 is trying to tell me: >=20 > For 1024-bit through 3072-bit RSA with SHA-256 see [RFC4055] and > [FIPS186-2] with Change Notice 1, and for 4096-bit RSA with SHA-256 > see [RFC4055] and [RFC3447]. In either case, the first reference > provides the signature algorithm's object identifier and the second > provides the signature algorithm's definition. >=20 > If I figured it out properly, I suggest: >=20 > The signature algorithm object identifiers for RSA PKCS#1 v1.5 and > RSASSA-PSS with SHA-256 using 1024-bit through 3072-bit public keys > are specified in [RFC4055] and the signature algorithm definition = is > found in [FIPS186-2] with Change Notice 1. >=20 > The signature algorithm object identifiers for RSA PKCS#1 v1.5 and > RSASSA-PSS with SHA-256 using 4096-bit public keys are specified in > [RFC4055] and the signature algorithm definition is found in > [RFC3447]. That matches my reading of the paragraph, but as this is original text = added in RFC 5750, I defer to Sean for an opinion. >=20 > The last paragraph of Section 4.3 says: >=20 > For EdDSA see [I-D.ietf-curdle-pkix] and [I-D.irtf-cfrg-eddsa]. = The > first reference provides the signature algorithm's object = identifier > and the second provides the signature algorithm's definition. = Other > curves than curve 25519 MAY be used as well. >=20 > There is only one other curve specified for EdDSA, so I suggest: >=20 > For EdDSA see [I-D.ietf-curdle-pkix] and [I-D.irtf-cfrg-eddsa]. = The > first reference provides the signature algorithm's object = identifier > and the second provides the signature algorithm's definition. In > addition to curve 25519, curve 448 MAY be used as well. Yes, today there is only one other curve that is defined. I think that = it is possible that others will be added I the future and did not want = to close off that path by being explicit here. >=20 > For clarity, I think that we should change Section 4.3 as follows: >=20 > OLD > MUST- support RSA with SHA-256. > NEW > MUST- support RSA PKCS#1 v1.5 with SHA-256. >=20 > and >=20 > OLD > The following are the RSA and RSASSA-PSS key size =E2=80=A6 NEW > The following are the RSA PKCS#1 v1.5 and RSASSA-PSS key size ... I am not sure about this. I think that if this is done then it needs to = be done on a much larger basis that what you have suggested here. I = worry about this. Would an additional terminology item added to = section 1.1 be sufficient? >=20 > Appendix C should also include S/MIME 4.0. >=20 > Appendix C should probably say something about the LAMPS WG too. Yes - both of those will be added - probably the latter is missing from = 5751-bis as well. Jim >=20 > Russ >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Fri Mar 10 06:49:01 2017 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 AA924129626 for ; Fri, 10 Mar 2017 06:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 lZpQfnULYPvO for ; Fri, 10 Mar 2017 06:48:59 -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 49719129628 for ; Fri, 10 Mar 2017 06:48:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A1D323004AE for ; Fri, 10 Mar 2017 09:48:58 -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 ZATd_F7cMGei for ; Fri, 10 Mar 2017 09:48:57 -0500 (EST) Received: from russhousleymbp.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 84804300448; Fri, 10 Mar 2017 09:48:57 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Russ Housley In-Reply-To: <0a1601d29970$f9d5a200$ed80e600$@augustcellars.com> Date: Fri, 10 Mar 2017 09:48:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2AFA0160-B45D-456E-A642-41863274A7EE@vigilsec.com> <95D2BAF0-EC51-4EFB-889C-C782C4A8FD3E@vigilsec.com> <0a1601d29970$f9d5a200$ed80e600$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3259) Archived-At: Cc: SPASM Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-rfc5751-bis-03 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 14:49:00 -0000 >> I have some WG Last Call comments on draft-ietf-lamps-rfc5751-bis-03. = I >> have divided my comments into MAJOR and MINOR. >>=20 >>=20 >> MAJOR >>=20 >> Do we need to define a way for smimeCapabilities to state support for >> AuthEnveloped? I=E2=80=99m trying to avoid interoperability = failures. >=20 > We have that. If you support an AEAD algorithm then you must support = AuthEnveloped by definition. Sure. I think the document needs to be explicit on this point. >> Section 2.1: I see no need to include the MUST for SHA-512 here since = none >> of the algorithms in Section 2.2 use it. >=20 > This is to get a match for EdDSA w/ curve 25519. That uses SHA-512 = internally so that the correct match would be to use SHA-512 for the = external as well. Okay. This one is resolved. >> Section 2.7.1.2: I worry about backward compatibility here. This = requires a >> capability that has never been used in S/MIME before, so it seems = premature >> to use AES-GCM when the capabilities of the recipient are unknown. = Instead, >> I would argue that AES-256 CBC offers implementers so time to deploy >> authenticated encryption. This looks like a fine thing for S/MIME = 4.1 in a >> couple of years. >=20 > This has been the traditional wording over the last three versions of = the document. Only for 3851 was it clear that the algorithm existed as = a possibility prior to the version being released. The group has = normally recommended using the best algorithm here but permitted to use = of a different algorithm. I think there is sufficient guidance in the = text about why GCM was chosen and it allows for either it or AES-128 CBC = to be used. Since a new content type is involved, not just a new algorithm, I am = advocating a slower transition. I=E2=80=99d love to hear from others. = Am I being too conservative? >> Section 5.1: The S/MIME WG is closed. Would it be better to change = the >> contact to the IESG? >=20 > I thought about this and did not do it, but yes it makes sense. I = wonder how many people have used the contact, but as I am not on this = alias I would not know.=20 Let=E2=80=99 make it the IESG. Russ From nobody Fri Mar 10 07:04:21 2017 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 30AD5129974 for ; Fri, 10 Mar 2017 07:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONHMOsE2hRG8 for ; Fri, 10 Mar 2017 07:04:19 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id F3E3F12996E for ; Fri, 10 Mar 2017 07:04:18 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9486D20000F; Fri, 10 Mar 2017 15:04:17 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 7EA0A200001; Fri, 10 Mar 2017 15:04:17 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489158257; bh=nJaA6+PiSzqxnpkf165XArcnMgcM/MG4+vyEINfc99c=; l=1298; h=From:To:CC:Date:References:In-Reply-To:From; b=eoUgANjG8gox3yrhNPOPUdFT1IJ7Cq0cNYGxDbtM/OjnkurvQVELTwe4U5RC6qNjN xiRIpMd9c95dBKM72TBbeooD8w1COftCDEnzbsXrcD4FSJ2PQQRm/BW4And8gyqYjV yPATiOda4iXgXU0DCMW8nIX+z7TjzWDFVL5sd8PE= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 652BD1E080; Fri, 10 Mar 2017 15:04:17 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 10 Mar 2017 10:04:16 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Fri, 10 Mar 2017 10:04:16 -0500 From: "Salz, Rich" To: Ryan Sleevi , Sean Turner Thread-Topic: [Spasm] An OCSP response extension Thread-Index: AdKY7ibhb+2MVJgFQpGlF716EDcwsAALWSSAAApWhUAAE+/dcP//KjoAgABToiD//7NmAIAADUyAgABzsoCAABFlAP//jsfg Date: Fri, 10 Mar 2017 15:04:16 +0000 Message-ID: <63e8fce92e2d45ca87c4b90206fc731c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <7B492EB7-CC0D-4706-85AC-8844F5BCF847@vigilsec.com> <244b0812054a41598425c6cdbf511392@usma1ex-dag1mb1.msg.corp.akamai.com> <6d9976eb3fdd4bb2840a5d91ee66eec2@usma1ex-dag1mb1.msg.corp.akamai.com> <2CDB8533-CB33-484A-AAB2-FD8FD0CB8D74@vigilsec.com> <6FC056E9-C31E-4E49-B9D8-63DC19AD419A@sn3rd.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.105] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: SPASM Subject: Re: [Spasm] An OCSP response extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 15:04:20 -0000 U2VhbjoNCj4gSWYgdGhpcyBpcyBnb2luZyB0byBiZSBnZXQgd2lkZWx5IGltcGxlbWVudGVkIHNo b3VsZCB3ZSBsb29rIGF0IHVwZGF0aW5nIFJGQzUwMTkgd2hpY2ggc2F5czoNCj4iVGhlIHJlc3Bv bmRlciBTSE9VTEQgTk9UIGluY2x1ZGUgcmVzcG9uc2VFeHRlbnNpb25z4oCdPw0KDQpZZXMsIHRo ZSBkb2MgZm9yIHRoaXMgZXh0ZW5zaW9uIHdvdWxkIHVwZGF0ZSA1MDE5IHRvIGF0IGxlYXN0IGxp ZnQgaXQgZm9yIHRoaXMgb25lLg0KDQpSeWFuOg0KPkkgbWVudGlvbmVkIHRvIFJpY2ggcHJpdmF0 ZWx5LCBidXQgSSB0aGluayB0aGlzIGlzIHNvbWV0aGluZyB0aGF0IHRoZSBDQS9Ccm93c2VyIEZv cnVtIHNob3VsZCBjb25zaWRlciBwcm9maWxpbmcgb3V0IGFuZCBleHByZXNzbHkgZm9yYmlkZGlu ZyBmb3IgdGhlIHRpbWUgYmVpbmcsIGFuZCBpZiBsYXRlciBlbmRlZCB1cCB2YWx1YWJsZSAoZS5n LiBpbiB0aGUgY29udGV4dCBvZiBtdXN0LXN0YXBsZSBjZXJ0aWZpY2F0ZXMpLCB3b3VsZCBuZWVk IHRvIGFnZ3Jlc3NpdmVseSBwcm9maWxlIHRoZSBhY2NlcHRhYmxlIHZhbHVlcyBzdWl0YWJsZSBm b3IgdGhlIFdlYiBQS0kuDQoNCkkgdGhpbmsgdGhhdCdzIGEgbWlzdGFrZS4gIFdlJ2xsIG5ldmVy IGtub3cgaXQncyB2YWx1YWJsZSBpZiB5b3Ugc3RhcnQgYnkgcHJvaGliaXRpbmcgaXQuIEkgdGhp bmsgdGhlcmUgaXMgdmFsdWUgaW4gYSBzZXJ2ZXIgaGF2aW5nIGFkZGl0aW9uYWwgbWVzc2FnZSBm cm9tIHRoZSByZXNwb25kZXIgdGhhdCBzYXlzICp3aHkqIHRoZSBjZXJ0aWZpY2F0ZSBpcyBub3Qg Z29vZC4NCg0KSWYgdGhlIGRvYyBkZWZpbmVzIHRoaXMgb25lIGV4dGVuc2lvbiBhbmQgcmVtb3Zl cyB0aGUgcHJvaGliaXRpb24gKm9ubHkgZm9yIHRoYXQgZXh0ZW5zaW9uKiB3b3VsZCB5b3Ugc3Rp bGwgZmVlbCBpdCBuZWNlc3NhcnkgdG8gZm9yYmlkIGl0Pw0K From nobody Fri Mar 10 07:23:59 2017 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 5D606129632 for ; Fri, 10 Mar 2017 07:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 TMVGceKAytY1 for ; Fri, 10 Mar 2017 07:23:56 -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 4986E129625 for ; Fri, 10 Mar 2017 07:23:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9E7AB3004B6 for ; Fri, 10 Mar 2017 10:23:55 -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 bUGZ_YnzLj4i for ; Fri, 10 Mar 2017 10:23:54 -0500 (EST) Received: from [10.5.245.234] (wsip-98-172-24-238.dc.dc.cox.net [98.172.24.238]) by mail.smeinc.net (Postfix) with ESMTPSA id 2A9A8300267; Fri, 10 Mar 2017 10:23:54 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Russ Housley In-Reply-To: <0a1701d29971$25d620f0$718262d0$@augustcellars.com> Date: Fri, 10 Mar 2017 10:23:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <415CC5D7-5766-4A6D-9649-E8D9B7BF92D7@vigilsec.com> References: <531F42E9-E7B2-4A40-B373-F616A4076FC2@vigilsec.com> <0a1701d29971$25d620f0$718262d0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3259) Archived-At: Cc: SPASM , Sean Turner Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-rfc5750-bis-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 15:23:57 -0000 >> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley >> Sent: Thursday, March 9, 2017 9:43 AM >> To: SPASM >> Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-rfc5750-bis-02 >>=20 >> I think that the document is in very good shape, and it is ready to = go to the >> IESG. I have a few minor suggestions for improvements. >>=20 >> I am not sure what this paragraph in Section 4.3 is trying to tell = me: >>=20 >> For 1024-bit through 3072-bit RSA with SHA-256 see [RFC4055] and >> [FIPS186-2] with Change Notice 1, and for 4096-bit RSA with SHA-256 >> see [RFC4055] and [RFC3447]. In either case, the first reference >> provides the signature algorithm's object identifier and the second >> provides the signature algorithm's definition. >>=20 >> If I figured it out properly, I suggest: >>=20 >> The signature algorithm object identifiers for RSA PKCS#1 v1.5 and >> RSASSA-PSS with SHA-256 using 1024-bit through 3072-bit public keys >> are specified in [RFC4055] and the signature algorithm definition = is >> found in [FIPS186-2] with Change Notice 1. >>=20 >> The signature algorithm object identifiers for RSA PKCS#1 v1.5 and >> RSASSA-PSS with SHA-256 using 4096-bit public keys are specified in >> [RFC4055] and the signature algorithm definition is found in >> [RFC3447]. >=20 > That matches my reading of the paragraph, but as this is original text = added in RFC 5750, I defer to Sean for an opinion. >=20 >> The last paragraph of Section 4.3 says: >>=20 >> For EdDSA see [I-D.ietf-curdle-pkix] and [I-D.irtf-cfrg-eddsa]. = The >> first reference provides the signature algorithm's object = identifier >> and the second provides the signature algorithm's definition. = Other >> curves than curve 25519 MAY be used as well. >>=20 >> There is only one other curve specified for EdDSA, so I suggest: >>=20 >> For EdDSA see [I-D.ietf-curdle-pkix] and [I-D.irtf-cfrg-eddsa]. = The >> first reference provides the signature algorithm's object = identifier >> and the second provides the signature algorithm's definition. In >> addition to curve 25519, curve 448 MAY be used as well. >=20 > Yes, today there is only one other curve that is defined. I think = that it is possible that others will be added I the future and did not = want to close off that path by being explicit here. The reference would need to change to allow other curves, right? >> For clarity, I think that we should change Section 4.3 as follows: >>=20 >> OLD >> MUST- support RSA with SHA-256. >> NEW >> MUST- support RSA PKCS#1 v1.5 with SHA-256. >>=20 >> and >>=20 >> OLD >> The following are the RSA and RSASSA-PSS key size =E2=80=A6 NEW >> The following are the RSA PKCS#1 v1.5 and RSASSA-PSS key size ... >=20 > I am not sure about this. I think that if this is done then it needs = to be done on a much larger basis that what you have suggested here. I = worry about this. Would an additional terminology item added to = section 1.1 be sufficient? Yes, that would be fine with me. Russ From nobody Fri Mar 10 07:40:45 2017 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 A6EB5129649 for ; Fri, 10 Mar 2017 07:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 g68hvVNgXfJT for ; Fri, 10 Mar 2017 07:40:43 -0800 (PST) Received: from homiemail-a105.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 090C5129644 for ; Fri, 10 Mar 2017 07:40:43 -0800 (PST) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id A02D330002A2B for ; Fri, 10 Mar 2017 07:40:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=Ga5Y2Ob+tNv9H9Z1Pjty9wH+8rc=; b= L3i7uTc7aUU29jU2998BCBSak8qpoDrcBut5hhpPFTu5pT0XEa9y5irDTDruYh30 /twBcfqPvByHPWe+xp+IMD8d2pP66tzNuehxtg8f3+s40k5nrNTFKm9elZ0CJV8d HjPNEq9cjjKUXeK8ry08CLVHhkCRACuw6LCCpcVww9g= Received: from mail-lf0-f47.google.com (mail-lf0-f47.google.com [209.85.215.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPSA id 7194C30002A29 for ; Fri, 10 Mar 2017 07:40:42 -0800 (PST) Received: by mail-lf0-f47.google.com with SMTP id y193so42391133lfd.3 for ; Fri, 10 Mar 2017 07:40:42 -0800 (PST) X-Gm-Message-State: AMke39muU1lVPhbdfpo30gOG0SZ6GsahJ4OZNnJIZTTZBWceae04aKbkCAmd9aYzQxEvAMRmvLg+jVyKV4qVTg== X-Received: by 10.46.83.29 with SMTP id h29mr6230980ljb.84.1489160440737; Fri, 10 Mar 2017 07:40:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.193.197 with HTTP; Fri, 10 Mar 2017 07:40:40 -0800 (PST) In-Reply-To: <63e8fce92e2d45ca87c4b90206fc731c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <7B492EB7-CC0D-4706-85AC-8844F5BCF847@vigilsec.com> <244b0812054a41598425c6cdbf511392@usma1ex-dag1mb1.msg.corp.akamai.com> <6d9976eb3fdd4bb2840a5d91ee66eec2@usma1ex-dag1mb1.msg.corp.akamai.com> <2CDB8533-CB33-484A-AAB2-FD8FD0CB8D74@vigilsec.com> <6FC056E9-C31E-4E49-B9D8-63DC19AD419A@sn3rd.com> <63e8fce92e2d45ca87c4b90206fc731c@usma1ex-dag1mb1.msg.corp.akamai.com> From: Ryan Sleevi Date: Fri, 10 Mar 2017 10:40:40 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=94eb2c1ce7fa157926054a622f3d Archived-At: Cc: Ryan Sleevi , SPASM , Sean Turner Subject: Re: [Spasm] An OCSP response extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 15:40:43 -0000 --94eb2c1ce7fa157926054a622f3d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 10, 2017 at 10:04 AM, Salz, Rich wrote: > Sean: > > If this is going to be get widely implemented should we look at updatin= g > RFC5019 which says: > >"The responder SHOULD NOT include responseExtensions=E2=80=9D? > > Yes, the doc for this extension would update 5019 to at least lift it for > this one. > > Ryan: > >I mentioned to Rich privately, but I think this is something that the > CA/Browser Forum should consider profiling out and expressly forbidding f= or > the time being, and if later ended up valuable (e.g. in the context of > must-staple certificates), would need to aggressively profile the > acceptable values suitable for the Web PKI. > > I think that's a mistake. We'll never know it's valuable if you start by > prohibiting it. I think there is value in a server having additional > message from the responder that says *why* the certificate is not good. > I disagree, because at least within the Web PKI, it's only valuable if it's represented to the RP or if it can be automatically acted on. It's an unnecessary detail for RPs, and it cannot be automatically acted upon without normative specification of the contents. This is no different than the Baseline Requirements profiling 5280 to specify how the CN, O, and OU, or subjectAltName are normatively validated, so that there's a consistent standard to the information presented and relied upon. > If the doc defines this one extension and removes the prohibition *only > for that extension* would you still feel it necessary to forbid it? > Yes --94eb2c1ce7fa157926054a622f3d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 10, 2017 at 10:04 AM, Salz, Rich <rsalz@akamai.com><= /span> wrote:
Sean:
> If this is going to be get widely implemented should = we look at updating RFC5019 which says:
>"The responder SHOULD NOT include responseExtensions=E2=80=9D?

Yes, the doc for this extension would update 5019 to at least lift i= t for this one.

Ryan:
>I mentioned to Rich privately, but I think this is som= ething that the CA/Browser Forum should consider profiling out and expressl= y forbidding for the time being, and if later ended up valuable (e.g. in th= e context of must-staple certificates), would need to aggressively profile = the acceptable values suitable for the Web PKI.

I think that's a mistake.=C2=A0 We'll never know it's va= luable if you start by prohibiting it. I think there is value in a server h= aving additional message from the responder that says *why* the certificate= is not good.

I disagree, because at le= ast within the Web PKI, it's only valuable if it's represented to t= he RP or if it can be automatically acted on. It's an unnecessary detai= l for RPs, and it cannot be automatically acted upon without normative spec= ification of the contents. This is no different than the Baseline Requireme= nts profiling 5280 to specify how the CN, O, and OU, or subjectAltName are = normatively validated, so that there's a consistent standard to the inf= ormation presented and relied upon.
=C2=A0
If the doc defines this one extension and removes the prohibition *only for= that extension* would you still feel it necessary to forbid it?

Yes=C2=A0

--94eb2c1ce7fa157926054a622f3d-- From nobody Fri Mar 10 07:45:54 2017 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 612CD129650 for ; Fri, 10 Mar 2017 07:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EA37N3LtTs-b for ; Fri, 10 Mar 2017 07:45:52 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 69673129649 for ; Fri, 10 Mar 2017 07:45:52 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DAEFF16C641; Fri, 10 Mar 2017 15:45:51 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id C542116C63B; Fri, 10 Mar 2017 15:45:51 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489160751; bh=vhNHBSRSrd/RSOF+cz1Iynknyw0q/Gjr0UfLXdps5q8=; l=650; h=From:To:CC:Date:References:In-Reply-To:From; b=fKet5IZ+SfEKRpGOEk/rugMO4QYjjyFiTFsEWjyjAQeE6CFnOZbUvoGmEZ6e4l09F DAiX1kI87tO38UbJ/qGXJMPunjTdKzGbnEjFL1TfyUQL1VPXlQ+5lp47eweJZuAqzp 0ilJO6ZP2bB+GAB6zAlfc+a6NfMfjpP4Q9TRsgNQ= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id AAD2398082; Fri, 10 Mar 2017 15:45:51 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 10 Mar 2017 07:45:50 -0800 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Fri, 10 Mar 2017 10:45:50 -0500 From: "Salz, Rich" To: Ryan Sleevi Thread-Topic: [Spasm] An OCSP response extension Thread-Index: AdKY7ibhb+2MVJgFQpGlF716EDcwsAALWSSAAApWhUAAE+/dcP//KjoAgABToiD//7NmAIAADUyAgABzsoCAABFlAP//jsfggAFBcwCAAFNCUA== Date: Fri, 10 Mar 2017 15:45:50 +0000 Message-ID: References: <7B492EB7-CC0D-4706-85AC-8844F5BCF847@vigilsec.com> <244b0812054a41598425c6cdbf511392@usma1ex-dag1mb1.msg.corp.akamai.com> <6d9976eb3fdd4bb2840a5d91ee66eec2@usma1ex-dag1mb1.msg.corp.akamai.com> <2CDB8533-CB33-484A-AAB2-FD8FD0CB8D74@vigilsec.com> <6FC056E9-C31E-4E49-B9D8-63DC19AD419A@sn3rd.com> <63e8fce92e2d45ca87c4b90206fc731c@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.105] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: SPASM , Sean Turner Subject: Re: [Spasm] An OCSP response extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 15:45:53 -0000 PiBJIGRpc2FncmVlLCBiZWNhdXNlIGF0IGxlYXN0IHdpdGhpbiB0aGUgV2ViIFBLSSwgaXQncyBv bmx5IHZhbHVhYmxlIGlmIGl0J3MgcmVwcmVzZW50ZWQgdG8gdGhlIFJQIG9yIGlmIGl0IGNhbiBi ZSBhdXRvbWF0aWNhbGx5IGFjdGVkIG9uLg0KDQpHdWlkYW5jZSB0byB0aGUgc2VydmVyIG9wZXJh dG9yIGlzIHZlcnkgdXNlZnVsLiBBdCBsZWFzdCB3aXRoaW4gdGhlIHdlYnBraSwgdGhlcmUgYXJl IG1vcmUgdGhhbiBqdXN0IFJQJ3MsIHRoZXJlIGFyZSBhbHNvIHNldmVycy4gOikNCiANCj4+IElm IHRoZSBkb2MgZGVmaW5lcyB0aGlzIG9uZSBleHRlbnNpb24gYW5kIHJlbW92ZXMgdGhlIHByb2hp Yml0aW9uICpvbmx5IGZvciB0aGF0IGV4dGVuc2lvbiogd291bGQgeW91IHN0aWxsIGZlZWwgaXQg bmVjZXNzYXJ5IHRvIGZvcmJpZCBpdD8NCj4gWWVzwqANCg0KSG9waW5nIHRoZSBjYWJhbCBkb2Vz bid0IGdvIHRoYXQgd2F5Lg0K From nobody Fri Mar 10 07:52:03 2017 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 08C4212965A for ; Fri, 10 Mar 2017 07:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 7GxrIB8vv_DK for ; Fri, 10 Mar 2017 07:52:02 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 CCC46129649 for ; Fri, 10 Mar 2017 07:52:01 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id y76so173615518qkb.0 for ; Fri, 10 Mar 2017 07:52:01 -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=Kh43Gr8YaPGepPbDGGtN/rPnAkWMH6Pb9FFO8Rbw8nI=; b=RBey1881+BkLgfvhYH1hFc2UNvP+lySPGXGYT8WwHGu8NRomuunULb7lAp+Z1c42Uw frwixB0CCn5v4RvD8R3AxIQxnnxU6By9fhxYRK+VUXQM/NuPSrSusOMtAylrRWS4/gTL 2+jC9lnpnWef6b+moeDk5AMv5C8E9zDVkdcMQ= 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=Kh43Gr8YaPGepPbDGGtN/rPnAkWMH6Pb9FFO8Rbw8nI=; b=DTboEk9KnjnSPZhIZSnCXf14E1mX34vs+l6q3Pi0exazXBUJ3rLTJu+Veo06agVkT4 u6djVZ3fY3kJERVgTaHSlTeQmGD8QYR5uy2YCfGY5/i8l0ESNxkJfoG5EvS6HpOTi8tS ZqB+TBvd8WIeUp328SaOCqBehAE7QhdoBbUkcFP4OWLt3+HqLjLgJEjLDAb7jd3mie1z gQxd3oGSRw7Yrx8yeZjCgj1uY8SHo+3h1bN6nbzBcJsLwCUbXcjDwGq66QplqHvzfgfS 8VZzuxlLgUPMHX5r32dEs2K3IJVwjbfyAuticLC/tcfdfD2tiXZ42a5okXpQia30hRpO yl8w== X-Gm-Message-State: AMke39mGX0shtLoNwmrbMP4v3UUB0UrbPvQVtRa1LhtRxNBv3TwPsyciKCmx/HMC+H5ejQ== X-Received: by 10.200.51.252 with SMTP id d57mr19655511qtb.96.1489161120637; Fri, 10 Mar 2017 07:52:00 -0800 (PST) Received: from [172.16.0.18] ([96.231.228.203]) by smtp.gmail.com with ESMTPSA id k65sm6584314qkf.18.2017.03.10.07.51.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Mar 2017 07:51:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Sean Turner In-Reply-To: <0a1701d29971$25d620f0$718262d0$@augustcellars.com> Date: Fri, 10 Mar 2017 10:51:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0E4B2376-D1FF-4F5B-B59A-BDD3461E5D73@sn3rd.com> References: <531F42E9-E7B2-4A40-B373-F616A4076FC2@vigilsec.com> <0a1701d29971$25d620f0$718262d0$@augustcellars.com> To: Russ Housley X-Mailer: Apple Mail (2.3259) Archived-At: Cc: SPASM Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-rfc5750-bis-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 15:52:03 -0000 > On Mar 10, 2017, at 02:37, Jim Schaad wrote: >=20 >>=20 >> -----Original Message----- >> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ Housley >> Sent: Thursday, March 9, 2017 9:43 AM >> To: SPASM >> Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-rfc5750-bis-02 >>=20 >> I think that the document is in very good shape, and it is ready to = go to the >> IESG. I have a few minor suggestions for improvements. >>=20 >> I am not sure what this paragraph in Section 4.3 is trying to tell = me: >>=20 >> For 1024-bit through 3072-bit RSA with SHA-256 see [RFC4055] and >> [FIPS186-2] with Change Notice 1, and for 4096-bit RSA with SHA-256 >> see [RFC4055] and [RFC3447]. In either case, the first reference >> provides the signature algorithm's object identifier and the second >> provides the signature algorithm's definition. >>=20 >> If I figured it out properly, I suggest: >>=20 >> The signature algorithm object identifiers for RSA PKCS#1 v1.5 and >> RSASSA-PSS with SHA-256 using 1024-bit through 3072-bit public keys >> are specified in [RFC4055] and the signature algorithm definition = is >> found in [FIPS186-2] with Change Notice 1. >>=20 >> The signature algorithm object identifiers for RSA PKCS#1 v1.5 and >> RSASSA-PSS with SHA-256 using 4096-bit public keys are specified in >> [RFC4055] and the signature algorithm definition is found in >> [RFC3447]. >=20 >=20 > That matches my reading of the paragraph, but as this is original text = added in RFC 5750, I defer to Sean for an opinion. You interpreted it correctly so the rewording lgtm. spt= From nobody Fri Mar 10 07:53:15 2017 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 CACBC12965B for ; Fri, 10 Mar 2017 07:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 Ghw9oeZz3igz for ; Fri, 10 Mar 2017 07:53:12 -0800 (PST) Received: from homiemail-a102.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2F7F129649 for ; Fri, 10 Mar 2017 07:53:12 -0800 (PST) Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id 3145F2004760A for ; Fri, 10 Mar 2017 07:53:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=dmjqfGAqYQguwK4SudJYq9Gpx34=; b= mE7093UuXYhnHTBH4XfN4xdZYnMEv/qFt87xtjAPFMvzdeM1Lq//VenRnDC92gdX F8GZDchq+fzN2nUA2eH1QM55lKzS7Jp68/IlTM5Rd9vaUXMv+AYhNAtR448xqyI4 /t7bvdF91OWkCPJqPGNgdy8bpbrO40RYdqVX3iXZ5bw= Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com [209.85.215.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPSA id 0328220047604 for ; Fri, 10 Mar 2017 07:53:11 -0800 (PST) Received: by mail-lf0-f41.google.com with SMTP id a6so42631422lfa.0 for ; Fri, 10 Mar 2017 07:53:11 -0800 (PST) X-Gm-Message-State: AMke39lHhl+HJWw5UNNAhpaUihI4ZCfaCVr0YzAmecpgx/6NuuXokryUgFL8h1qnqeUSK0XNIT86sgIKTiF4iA== X-Received: by 10.25.0.207 with SMTP id 198mr5231222lfa.134.1489161190037; Fri, 10 Mar 2017 07:53:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.193.197 with HTTP; Fri, 10 Mar 2017 07:53:09 -0800 (PST) In-Reply-To: References: <7B492EB7-CC0D-4706-85AC-8844F5BCF847@vigilsec.com> <244b0812054a41598425c6cdbf511392@usma1ex-dag1mb1.msg.corp.akamai.com> <6d9976eb3fdd4bb2840a5d91ee66eec2@usma1ex-dag1mb1.msg.corp.akamai.com> <2CDB8533-CB33-484A-AAB2-FD8FD0CB8D74@vigilsec.com> <6FC056E9-C31E-4E49-B9D8-63DC19AD419A@sn3rd.com> <63e8fce92e2d45ca87c4b90206fc731c@usma1ex-dag1mb1.msg.corp.akamai.com> From: Ryan Sleevi Date: Fri, 10 Mar 2017 10:53:09 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a113c9f48bee3b0054a625bb3 Archived-At: Cc: Ryan Sleevi , SPASM , Sean Turner Subject: Re: [Spasm] An OCSP response extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 15:53:13 -0000 --001a113c9f48bee3b0054a625bb3 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 10, 2017 at 10:45 AM, Salz, Rich wrote: > > I disagree, because at least within the Web PKI, it's only valuable if > it's represented to the RP or if it can be automatically acted on. > > Guidance to the server operator is very useful. At least within the > webpki, there are more than just RP's, there are also severs. :) > I agree, but I disagree that guidance should be provided in a way that negatively affects RPs. There's no need to force that information be included to every RP who wants it, if it's only for the benefit of the server operator. There's perfectly reasonable alternatives to solve that concern, without conflating it with the RPs needs. > >> If the doc defines this one extension and removes the prohibition *only > for that extension* would you still feel it necessary to forbid it? > > Yes > > Hoping the cabal doesn't go that way. > You mean try to make OCSP more effective for RPs by preventing CAs from doing the equivalent of "Logotype" or "UserNotice" for OCSP - bloating responses unnecessarily? --001a113c9f48bee3b0054a625bb3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 10, 2017 at 10:45 AM, Salz, Rich <rsalz@akamai.com> w= rote:
> I disagree, b= ecause at least within the Web PKI, it's only valuable if it's repr= esented to the RP or if it can be automatically acted on.

Guidance to the server operator is very useful. At least within the = webpki, there are more than just RP's, there are also severs. :)

I agree, but I disagree that guidance should = be provided in a way that negatively affects RPs. There's no need to fo= rce that information be included to every RP who wants it, if it's only= for the benefit of the server operator. There's perfectly reasonable a= lternatives to solve that concern, without conflating it with the RPs needs= .
=C2=A0
>> If the doc defines this one extension and removes the prohibition = *only for that extension* would you still feel it necessary to forbid it? > Yes=C2=A0

Hoping the cabal doesn't go that way.

You mean try to mak= e OCSP more effective for RPs by preventing CAs from doing the equivalent o= f "Logotype" or "UserNotice" for OCSP - bloating respon= ses unnecessarily?
--001a113c9f48bee3b0054a625bb3-- From nobody Fri Mar 10 08:15:43 2017 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 E32A2129973 for ; Fri, 10 Mar 2017 08:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNimk5yFkHdj for ; Fri, 10 Mar 2017 08:15:40 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id A95BA129661 for ; Fri, 10 Mar 2017 08:15:40 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4072C20000A; Fri, 10 Mar 2017 16:15:40 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 29AAD200001; Fri, 10 Mar 2017 16:15:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489162540; bh=qN0GKeuSvbS5Sr/111S4XtTBXlr3tFuGD/dM80w0nc0=; l=1028; h=From:To:CC:Date:References:In-Reply-To:From; b=RzrHe5QVY9/taVFLnB78gpixklvKpWL5hSjk0ZGrN4GNj+aH5DRu7Am++75vlmhjP UQeqKip5nGABgNi8aB/NxbxNDceIt/Op2bTnwroPF05/dJ2X1jd1iXgeQUmSHn18Vw A1itiq2j/RZtEAb7qCoYJ3kqZCj8E525mORAjzPU= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 04FF098087; Fri, 10 Mar 2017 16:15:39 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 10 Mar 2017 11:15:38 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Fri, 10 Mar 2017 11:15:39 -0500 From: "Salz, Rich" To: Ryan Sleevi Thread-Topic: [Spasm] An OCSP response extension Thread-Index: AdKY7ibhb+2MVJgFQpGlF716EDcwsAALWSSAAApWhUAAE+/dcP//KjoAgABToiD//7NmAIAADUyAgABzsoCAABFlAP//jsfggAFBcwCAAFNCUP//sDqAAAnNLrA= Date: Fri, 10 Mar 2017 16:15:38 +0000 Message-ID: References: <7B492EB7-CC0D-4706-85AC-8844F5BCF847@vigilsec.com> <244b0812054a41598425c6cdbf511392@usma1ex-dag1mb1.msg.corp.akamai.com> <6d9976eb3fdd4bb2840a5d91ee66eec2@usma1ex-dag1mb1.msg.corp.akamai.com> <2CDB8533-CB33-484A-AAB2-FD8FD0CB8D74@vigilsec.com> <6FC056E9-C31E-4E49-B9D8-63DC19AD419A@sn3rd.com> <63e8fce92e2d45ca87c4b90206fc731c@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.105] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: SPASM , Sean Turner Subject: Re: [Spasm] An OCSP response extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 16:15:42 -0000 PiBJIGFncmVlLCBidXQgSSBkaXNhZ3JlZSB0aGF0IGd1aWRhbmNlIHNob3VsZCBiZSBwcm92aWRl ZCBpbiBhIHdheSB0aGF0IG5lZ2F0aXZlbHkgYWZmZWN0cyBSUHMuIFRoZXJlJ3Mgbm8gbmVlZCB0 byBmb3JjZSB0aGF0IGluZm9ybWF0aW9uIGJlIGluY2x1ZGVkIHRvIGV2ZXJ5IFJQIHdobyB3YW50 cyBpdCwgaWYgaXQncyBvbmx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VydmVyIG9wZXJhdG9y LiBUaGVyZSdzIHBlcmZlY3RseSByZWFzb25hYmxlIGFsdGVybmF0aXZlcyB0byBzb2x2ZSB0aGF0 IGNvbmNlcm4sIHdpdGhvdXQgY29uZmxhdGluZyBpdCB3aXRoIHRoZSBSUHMgbmVlZHMuDQoNCkRv IHNlcnZlcnMgbm9ybWFsbHkgc2VuZCBzdGF0dXMtcmV2b2tlZCBPQ1NQIHJlc3BvbnNlcyBhcyBw YXJ0IG9mIHN0YXBsaW5nPyAgTm90IGluIG15IGV4cGVyaWVuY2U7IGluIHlvdXJzPw0KDQo+IFlv dSBtZWFuIHRyeSB0byBtYWtlIE9DU1AgbW9yZSBlZmZlY3RpdmUgZm9yIFJQcyBieSBwcmV2ZW50 aW5nIENBcyBmcm9tIGRvaW5nIHRoZSBlcXVpdmFsZW50IG9mICJMb2dvdHlwZSIgb3IgIlVzZXJO b3RpY2UiIGZvciBPQ1NQIC0gYmxvYXRpbmcgcmVzcG9uc2VzIHVubmVjZXNzYXJpbHk/DQoNCldl IGRpc2FncmVlIHRoYXQgdGhpcyBwYXJ0aWN1bGFyIG9uZSBpcyBub3QgdXNlZnVsIG9yIG5lY2Vz c2FyeS4gIEFuZCBJIG5ldmVyIHNhaWQgdGhlIGNhYmFsIGRpZG7igJl0IGRvIGFueXRoaW5nIGdv b2QuIA0KDQo= From nobody Fri Mar 10 08:28:00 2017 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 07ADC129496 for ; Fri, 10 Mar 2017 08:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 xav7Sn8zoUIM for ; Fri, 10 Mar 2017 08:27:58 -0800 (PST) Received: from homiemail-a49.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27330129439 for ; Fri, 10 Mar 2017 08:27:58 -0800 (PST) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id CF1A16800318A for ; Fri, 10 Mar 2017 08:27:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=MmvD5PClkKVA6Saqe0lo+QBFD2U=; b= P2IgJg/v7zcKxYiZM0AZky6oKgQIPVzXU4/p9DbvdEsn0NYs3B1LLqKY3vIs8dRq blYGfJU3CJdDx6F/wepuLLHcFC5LaO3fnQrNCJrCLlq22/jGf61BW1cDjwar/HV1 9x6P1loiVSma0r1Yhz3xbzYHCHOOeHPnWUNd2V+MeZc= Received: from mail-lf0-f52.google.com (mail-lf0-f52.google.com [209.85.215.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPSA id 9C59968003187 for ; Fri, 10 Mar 2017 08:27:57 -0800 (PST) Received: by mail-lf0-f52.google.com with SMTP id a6so43031632lfa.0 for ; Fri, 10 Mar 2017 08:27:57 -0800 (PST) X-Gm-Message-State: AMke39lPQiZJXGcpDjBcVb7Ys4f/xr9Xps4oDsdY3tdTrXYONEmxDMOxAOd7LFSNrt/TZQtgGipS/lJlugYZKw== X-Received: by 10.25.56.72 with SMTP id d8mr5043853lfj.2.1489163275876; Fri, 10 Mar 2017 08:27:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.193.197 with HTTP; Fri, 10 Mar 2017 08:27:55 -0800 (PST) In-Reply-To: References: <7B492EB7-CC0D-4706-85AC-8844F5BCF847@vigilsec.com> <244b0812054a41598425c6cdbf511392@usma1ex-dag1mb1.msg.corp.akamai.com> <6d9976eb3fdd4bb2840a5d91ee66eec2@usma1ex-dag1mb1.msg.corp.akamai.com> <2CDB8533-CB33-484A-AAB2-FD8FD0CB8D74@vigilsec.com> <6FC056E9-C31E-4E49-B9D8-63DC19AD419A@sn3rd.com> <63e8fce92e2d45ca87c4b90206fc731c@usma1ex-dag1mb1.msg.corp.akamai.com> From: Ryan Sleevi Date: Fri, 10 Mar 2017 11:27:55 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=f403045ea32e12556f054a62d82b Archived-At: Cc: Ryan Sleevi , SPASM , Sean Turner Subject: Re: [Spasm] An OCSP response extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 16:27:59 -0000 --f403045ea32e12556f054a62d82b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 10, 2017 at 11:15 AM, Salz, Rich wrote: > > I agree, but I disagree that guidance should be provided in a way that > negatively affects RPs. There's no need to force that information be > included to every RP who wants it, if it's only for the benefit of the > server operator. There's perfectly reasonable alternatives to solve that > concern, without conflating it with the RPs needs. > > Do servers normally send status-revoked OCSP responses as part of > stapling? Not in my experience; in yours? > Yes, actually. IIS will happily do this in my experience. > > You mean try to make OCSP more effective for RPs by preventing CAs from > doing the equivalent of "Logotype" or "UserNotice" for OCSP - bloating > responses unnecessarily? > > We disagree that this particular one is not useful or necessary. And I > never said the cabal didn=E2=80=99t do anything good. To be clear: The point I was making about the Forum profiling 5019 was to make it clear not to set extensions. Similarly, with the introduction of an extension that is only relevant for certain statuses, if the registration didn't explicitly restrict it to specific status codes, the Forum would need to profile it as such. And if the Forum were to allow it, it would need to profile the values of it, so that it could/would be useful to site operators and RPs. The Forum's profile largely exists to take the giant bundle of configurability that is the set of PKIX (and LAMPs) documents and tune it for the least error prone. I think that's relatively uncontroversial, and is not meant to be a rejection outright, but to highlight that the default for any introduction of "a new option" is to ensure it's profiled out, until there is consensus on whether and how it should be profiled in to the Web PKI. --f403045ea32e12556f054a62d82b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 10, 2017 at 11:15 AM, Salz, Rich <rsalz@akamai.com> w= rote:
> I agree, but = I disagree that guidance should be provided in a way that negatively affect= s RPs. There's no need to force that information be included to every R= P who wants it, if it's only for the benefit of the server operator. Th= ere's perfectly reasonable alternatives to solve that concern, without = conflating it with the RPs needs.

Do servers normally send status-revoked OCSP responses as part of st= apling?=C2=A0 Not in my experience; in yours?

Yes, actually. IIS will happily do this in my experience.=C2=A0
=C2=A0
> You mean try to make OCSP more effective for RPs by preventing CAs fro= m doing the equivalent of "Logotype" or "UserNotice" fo= r OCSP - bloating responses unnecessarily?

We disagree that this particular one is not useful or necessary.=C2= =A0 And I never said the cabal didn=E2=80=99t do anything good.

To be clear: The point I was making about the Forum pr= ofiling 5019 was to make it clear not to set extensions. Similarly, with th= e introduction of an extension that is only relevant for certain statuses, = if the registration didn't explicitly restrict it to specific status co= des, the Forum would need to profile it as such. And if the Forum were to a= llow it, it would need to profile the values of it, so that it could/would = be useful to site operators and RPs.

The Forum'= ;s profile largely exists to take the giant bundle of configurability that = is the set of PKIX (and LAMPs) documents and tune it for the least error pr= one. I think that's relatively uncontroversial, and is not meant to be = a rejection outright, but to highlight that the default for any introductio= n of "a new option" is to ensure it's profiled out, until the= re is consensus on whether and how it should be profiled in to the Web PKI.=
--f403045ea32e12556f054a62d82b-- From nobody Fri Mar 10 09:03:04 2017 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 7EA6412967A for ; Fri, 10 Mar 2017 09:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 AyqpgJOm858s for ; Fri, 10 Mar 2017 09:03:01 -0800 (PST) Received: from homiemail-a102.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69E2212962E for ; Fri, 10 Mar 2017 09:03:01 -0800 (PST) Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id D9B102004760F for ; Fri, 10 Mar 2017 09:03:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=2UIgT2Hz9lqten19rg8M4nZT9XE=; b= YvR/9BO7aT/Dzn4v84AJVEP2N3CwHCTDmmvNkyPnEETEfdtbph8Q4O9ncLtZznGn f516GFB4hnUvew5PR4TOT2qRG6WbSHF3exjQNSEXfn1/A9nU36W2zbJNY0IUIxSO rotXx0lO8MN+LlWxB0IuMY0tlo+cjk7mCYJYg6MGFDo= Received: from mail-lf0-f42.google.com (mail-lf0-f42.google.com [209.85.215.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPSA id 79D3020047602 for ; Fri, 10 Mar 2017 09:03:00 -0800 (PST) Received: by mail-lf0-f42.google.com with SMTP id j90so43421399lfk.2 for ; Fri, 10 Mar 2017 09:03:00 -0800 (PST) X-Gm-Message-State: AMke39kyMfRbwC22hIub3azbQeSkKRnC9UTWhNIG3027t8lOngEHkA6GooFzAN1dbftx0lYM6BfvjYxmesi5hQ== X-Received: by 10.25.190.76 with SMTP id o73mr5313207lff.80.1489165378623; Fri, 10 Mar 2017 09:02:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.193.197 with HTTP; Fri, 10 Mar 2017 09:02:57 -0800 (PST) In-Reply-To: <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> From: Ryan Sleevi Date: Fri, 10 Mar 2017 12:02:57 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary=94eb2c1a1b3e67a442054a6355e7 Archived-At: Cc: Patrick Donahue , Gervase Markham , Phillip Hallam-Baker , Ryan Sleevi , Peter Bowen , SPASM , Rob Stradling Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 17:03:03 -0000 --94eb2c1a1b3e67a442054a6355e7 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 9, 2017 at 4:07 PM, Jacob Hoffman-Andrews wrote: > On 03/09/2017 12:35 PM, Ryan Sleevi wrote: > > I want to be careful here restricting it to the notion of "CDNs", > > I'm using CDN as a shorthand for "hosting provider or CDN." In the Twitter > example, the other stakeholders are the marketing department and the > contractor who develops the web content, neither of whom have CNAMEs in the > mix. Is there another entity type I'm missing? > > *Hole punching and the includeSubDomains problem* >> > As you noted elsewhere, to effectively get this scenario, the operator of > superbowl2017.twitter.com (which we'll call example.com) would need to > set up the destination of CNAME in such a way as to be able to > appropriately express the per-customer policy (if Twitter handles > certificate provisioning) - that is, superbowl2017.twitter.example.com - > or, as you noted, would need to effectively set the CAA record as a > 'wildcard' / for every customer. > > I don't understand why example.com would need to set a per-customer > policy. If terrier.dog handles certificates for their customers, they would > do so with a limited set of CAs, and could set that as policy on their > domain names. If a specified customer like www.staffie.dog needs a > different policy, they can set it on their own hostname: > > www.staffie.dog. CAA 0 issue "sad-hacker-totally-real-ca.net" > > > I don't think trampolining is necessary to make this work. > > If terrier.dog doesn't handle certificates, e.g., if they expect customers > to bring their own cert from any CA, then they can't reasonably set a > blanket policy for all their customers. In that situation, I think it would > similarly be up to the customer to set a CAA policy on their own hostname > if they wanted one, since the customer is the one with the CA relationship. > The pronouns here (re: "they") make it a bit confusing to follow your argument. I'm also trying to stick to using domains reserved for purpose, rather than use staffie.dog and terrier.dog. For sake of clarity, I'll rephrase it as: From: www.staffie.dog. CNAME staffie.terrier.dog. staffie.terrier.dog. A 192.0.2.1 terrier.dog. CAA 0 issue "happy-hacker-fake-ca.net" To: www.example.com CNAME staffie.example.net staffie.example.net A 192.0.2.1 example.net CAA 0 issue "evil-ca.example.org" Now that we've got that basic bit out, I'm going to try to briefly cover the permutations of configurations here, with the introduction of some terminology: - Self-Managed = The domain operator of example.com handles certificate acquisition for www.example.com - Externally-Managed = The domain operator of example.net handles certificate acquisition for www.example.com and - Recursive = As currently specified - Non-Recursive = As Erratum 4515 proposes Finally, one last dimension - whether or not a 'trampoline' is involved, where - Trampoline = example.com points their CNAME to a host at example.net that is dedicated 'for them' (the 'staffie.example.net' case) We end up with the following configurations: - Self-Managed, Recursive, Trampoline'd www.example.com CNAME staffie.example.net www.example.com CAA 0 issue "good-ca.example.org" example.com CAA 0 issue "good-ca.example.org" staffie.example.net A 192.0.2.1 example.net CAA 0 issue "evil-ca.example.org" - Externally-Managed, Recursive, Trampoline'd www.example.com CNAME staffie.example.net example.com CAA 0 issue "good-ca.example.org" staffie.example.net A 192.0.2.1 example.net CAA 0 issue "evil-ca.example.org" - Self-Managed, Non-Recursive, Trampolined www.example.com CNAME staffie.example.net example.com CAA 0 issue "good-ca.example.org" staffie.example.net A 192.0.2.1 example.net CAA 0 issue "evil-ca.example.org" - Externally-Managed, Non-Recursive, Trampolined EITHER: www.example.com CNAME staffie.example.net example.com CAA 0 issue "good-ca.example.org" staffie.example.net A 192.0.2.1 staffie.example.net CAA 0 issue "evil-ca.example.org" example.net CAA 0 issue "evil-ca.example.org" OR (and more problematically) www.example.com CNAME staffie.example.net www.example.com CAA 0 issue "evil-ca.example.org" example.com CAA 0 issue "good-ca.example.org" staffie.example.net A 192.0.2.1 example.net CAA 0 issue "evil-ca.example.org" I say problematic here, because now example.com is responsible for 'tracking' example.net's configuration, and if example.net wants to change configuration, it needs to notify example.com For the non-trampoline case, the initial configuration looks something like: www.example.com CNAME example.net example.com CAA 0 issue "good-ca.example.org" example.net A 192.0.2.1 example.net CAA 0 issue "evil-ca.example.org" For which we end up with the following permutations: - Self-managed, recursive www.example.com CNAME example.net www.example.com CAA 0 issue "good-ca.example.org" example.com CAA 0 issue "good-ca.example.org" example.net A 192.0.2.1 example.net CAA 0 issue "evil-ca.example.org" - Externally-managed, recursive www.example.com CNAME example.net example.com CAA 0 issue "good-ca.example.org" example.net A 192.0.2.1 example.net CAA 0 issue "evil-ca.example.org" - Self-managed, non-recursive www.example.com CNAME example.net www.example.com CAA 0 issue "good-ca.example.org" example.com CAA 0 issue "good-ca.example.org" example.net A 192.0.2.1 example.net CAA 0 issue "evil-ca.example.org" - Externally-managed, non-recursive www.example.com CNAME example.net example.com CAA 0 issue "good-ca.example.org" example.net A 192.0.2.1 example.net CAA 0 issue "evil-ca.example.org" Have I reasonably summarized at least what the configurations would need to look like, under the various algorithms? I figure it's probably important to checkpoint here, before starting the subjective portion. --94eb2c1a1b3e67a442054a6355e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 9, 2017 at 4:07 PM, Jacob Hoffman-Andrews <jsha@eff.org>= wrote:
=20 =20 =20
On 03/09/2017 12:35 PM, Ryan Sleevi wrote:
I want to be careful here restricting it to the notion of "CDNs",
 I'm using CDN as a shorthand for "hosting provider or CDN.&quo= t; In the Twitter example, the other stakeholders are the marketing department and the contractor who develops the web content, neither of whom have CNAMEs in the mix. Is there another entity type I'm missing?
Hole punching and the includeSubDomains problem
As you noted elsewhere, to effectively get this scenario, the operator of superbowl2017.twitter.com (which we'll call example.com) would need to set up the destination of CNAME in such a way as to be able to appropriately express the per-customer policy (if Twitter handles certificate provisioning) - that is, superbowl20= 17.twitter.example.com - =C2=A0or, as you noted, would need to effectively set the C= AA record as a 'wildcard' / for every customer.
I don't understand why example.com would need to set a per-customer policy. If terrier.dog handles certificates for their customers, they would do so with a limited set of CAs, and could set that as policy on their domain names. If a specified customer like www.staffie.dog needs a d= ifferent policy, they can set it on their own hostname:

www.staffie.dog.  =
      CAA 0 issue "sad-hacker-totally-real-ca.net"

I don't think trampolining is necessary to make this work.

If terrier.dog doesn't handle certificates, e.g., if they expect customers to bring their own cert from any CA, then they can't reasonably set a blanket policy for all their customers. In that situation, I think it would similarly be up to the customer to set a CAA policy on their own hostname if they wanted one, since the customer is the one with the CA relationship.

The pronouns here (re: "they") make it a bit con= fusing to follow your argument.

I'm also tryin= g to stick to using domains reserved for purpose, rather than use staffie.d= og and terrier.dog. For sake of clarity, I'll rephrase it as:

From:
www.staffie.dog. =C2=A0 =C2=A0 =C2=A0 = =C2=A0CNAME staffie.terrier.dog.
staffie.terrier.dog. =C2=A0 =C2= =A0A 192.0.2.1
terrier.dog. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0CAA 0 issue "happy-h= acker-fake-ca.net"

To:
www.example.com =C2=A0 =C2=A0CNAME staffie.example.net
staffie.example.net =C2=A0 A 192.0.2.1
example.net =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CAA 0 = issue "evil-ca.example.org&= quot;


Now that we've got that b= asic bit out, I'm going to try to briefly cover the permutations of con= figurations here, with the introduction of some terminology:

=
- Self-Managed =3D The domain operator of example.com handles certificate acquisition for www.example.com
- Externally-Managed =3D= The domain operator of example.net hand= les certificate acquisition for www.exam= ple.com

and
- Recursive =3D As curre= ntly specified
- Non-Recursive =3D As Erratum 4515 proposes
=

Finally, one last dimension - whether or not a 'tra= mpoline' is involved, where
- Trampoline =3D example.com points their CNAME to a host at example.net that is dedicated 'for them' (th= e 'staffie.example.net' = case)

We end up with the following configurations:=

- Self-Managed, Recursive, Trampoline'd<= /div><= div>www.example.com =C2=A0CAA 0 issu= e "good-ca.example.org"= ;
example.com =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0CAA 0 issue "good-ca.example.org"
example.net =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CAA 0 issue &quo= t;evil-ca.example.org"

- Externally-Managed, Recursive, Trampoline'= d
example.com =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0CAA 0 issue "g= ood-ca.example.org"
staffie.example.net =C2=A0A 192.0.2.1
example.net =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CAA 0 issue &q= uot;evil-ca.example.org"

- Self-Managed, Non-Recursive, Trampolined
www.example.com =C2=A0CNAME staffie.example.net
= example.com =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0CAA 0 issue "good-ca.exam= ple.org"
ex= ample.net =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CAA 0 issue "evil-ca.example.org"

- Externally-Managed, Non-Recursive, Trampolined
EITHER:
example.com =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0CAA 0 issue "good-ca.example.org"
example.net =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 CAA 0 issue "evil-ca.exa= mple.org"

OR (and more problematica= lly)

example.com =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CAA 0 issue "good-ca.example.org"
=
staffie.example.net A 192.0= .2.1
example.net =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 CAA 0 issue "evil-ca.example.org"

I say = problematic here, because now example.com is responsible for 'tracking' exam= ple.net's configuration, and if exam= ple.net wants to change configuration, it needs to notify example.com

For the non-tram= poline case, the initial configuration looks something like:
e= xample.com =C2=A0 =C2=A0 =C2=A0 =C2=A0 CAA 0 issue "good-ca.example.org"
example.net =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A 1= 92.0.2.1
example.net =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 CAA 0 issue "evil-ca.example.org"

For which = we end up with the following permutations:
- Self-managed, recurs= ive
example.com =C2=A0 =C2=A0 =C2=A0 =C2=A0 CAA 0 issue = "good-ca.example.org"<= /div>
example.net =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0A 192.0.2.1
examp= le.net =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CAA 0 issue "evil-ca.example.org"

- Externally-managed, recursive
example.com = =C2=A0 =C2=A0 =C2=A0 =C2=A0 CAA 0 issue "good-ca.example.org"
example.net =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A 192.0.2.1
example.net =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0CAA 0 issue "evil-= ca.example.org"

- Self-manage= d, non-recursive
<= div>www.example.com CAA 0 issue &quo= t;good-ca.example.org"
example.com =C2=A0 =C2=A0 =C2=A0 = =C2=A0 CAA 0 issue "good-ca.exa= mple.org"
example.net= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A 192.0.2.1
example.net =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CAA 0 issue = "evil-ca.example.org"<= /div>

- Externally-managed, non-recursive
example.com =C2=A0 =C2=A0 =C2=A0 =C2=A0 CAA 0 issue "good-ca.example.org"
=
example.net =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0A 192.0.2.1
example.n= et =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CAA 0 issue "evil-ca.example.org"


Have I reasonably summarized at least what the conf= igurations would need to look like, under the various algorithms? I figure = it's probably important to checkpoint here, before starting the subject= ive portion.
--94eb2c1a1b3e67a442054a6355e7-- From nobody Fri Mar 10 09:51:50 2017 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 9C74E129453 for ; Fri, 10 Mar 2017 09:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 pLwEcE32-koo for ; Fri, 10 Mar 2017 09:51:47 -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 7732612944F for ; Fri, 10 Mar 2017 09:51:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DD9053004AF for ; Fri, 10 Mar 2017 12:51:46 -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 mvHRDid4P1Jz for ; Fri, 10 Mar 2017 12:51:45 -0500 (EST) Received: from russhousleymbp.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id E9151300448 for ; Fri, 10 Mar 2017 12:51:45 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: Date: Fri, 10 Mar 2017 12:51:45 -0500 To: SPASM X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [Spasm] DRAFT LAMPS Agenda for IETF 98 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 17:51:48 -0000 Please review and comment =E2=80=A6 LAMPS WG Agenda 0) Minute Taker, Jabber Scribe, Bluesheets 1) Agenda Bash 2) Open issues from IETF Last Call a) draft-ietf-lamps-eai-addresses (Alexey and Wei) 3) Open issues from WG Last Call a) draft-ietf-lamps-rfc5750-bis (Jim) b) draft-ietf-lamps-rfc5751-bis (Jim) 4) Proposals for additional work items a) Adding SHA3 to PKIX and S/MIME (Sean) b) Updates to CAA for RFC Erratum 4514 (Jacob) c) OCSP response extension for revocation hint text (Rich) 5) Wrap Up From nobody Fri Mar 10 11:22:45 2017 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 9E0551296EA for ; Fri, 10 Mar 2017 11:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.003 X-Spam-Level: X-Spam-Status: No, score=-7.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=eff.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 mwFQRvvLZ9Hb for ; Fri, 10 Mar 2017 11:22:41 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDA2F1297A8 for ; Fri, 10 Mar 2017 11:22:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=5IgTvTH1ski/sw7WbJdiAt5IFiNFOKAFmifaI2UlS1c=; b=tqwIQLS+I8pHKW2F1gBDHClyUEwohq3dI5Fm2TOoC5JCQoAJ/jyeUSUEH79ZujY7tE16depfDr1BQSg4oiU027Nf5K3bg+aoM9ExeNO5JCErREncmzW0388EzOIP6xqgu/eCuQN04CslnPJJMYrHdia2cKNhgn0Jr0H9xftrl+g=; Received: ; Fri, 10 Mar 2017 11:22:41 -0800 To: Ryan Sleevi References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> From: Jacob Hoffman-Andrews Message-ID: <8f216ae1-d236-79c1-5baf-44cf7bfa619b@eff.org> Date: Fri, 10 Mar 2017 11:22:38 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------021AD533BD46CD5B1241D834" Received-SPF: skipped for local relay Archived-At: Cc: Patrick Donahue , Gervase Markham , Phillip Hallam-Baker , Peter Bowen , SPASM , Rob Stradling Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 19:22:44 -0000 This is a multi-part message in MIME format. --------------021AD533BD46CD5B1241D834 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/10/2017 09:02 AM, Ryan Sleevi wrote: > I'm also trying to stick to using domains reserved for purpose, rather > than use staffie.dog and terrier.dog. I chose these advisedly. Example.{com,net,org} are actively harmful for reading comprehension, because their distinguishing parts are small and come at the end rather than the beginning. Since this is a conversation, not a normative document, I believe there's no requirement to use the reserved domains. Do you disagree? > - Self-Managed =3D The domain operator of example.com > handles certificate acquisition for > www.example.com > - Externally-Managed =3D The domain operator of example.net > handles certificate acquisition for > www.example.com Good terms, agreed. > - Recursive =3D As currently specified > - Non-Recursive =3D As Erratum 4515 proposes Since we both care about terminology, I'm going to recommend we instead use the RFC 6844 terms I used in my previous email: tree climbing vs non-tree climbing. Recursive already has a technical meaning in RFC 1035 which differs from this one. > - Trampoline =3D example.com points their CNAME to= > a host at example.net that is dedicated 'for > them' (the 'staffie.example.net ' case) +1. > We end up with the following configurations: These configurations are a little confusing, since you don't define goals. I assume the goals in this example are: (a) Every domain and subdomain in the example is covered by a CAA policy, and (b) Those CAA records are compatible with these policies: (1) the owner of the user-facing domain will only buy certs from a certain CA (2) the owner of the CDN domain will only buy certs from another, different CA. Is that accurate? I'll adopt the CA names "user-facing.ca." and "enterprise.ca", since both our example CA names implied goodness or badness, which is not relevant to the discussion. I'm going to introduce one more assumption: the CDN issues certificates for their own internal subdomains, and wants a CAA policy for those. This is necessary to explain why the CDN sets any CAA records at all in the Self-managed case. And I think this is what's implied by your examples - right? I think it makes the most sense to start with two baseline configs: trampoline'd and non-trampoline'd, and from there define what *additional* CAA records are necessary in the various worlds of Self-managed vs Externally managed, and tree climbing vs non-. Trampoline'd config: www.staffie.dog. CNAME staffie.terrier.dog. staffie.terrier.dog. A 192.0.2.1 Non-trampoline'd config (all customers CNAME to the same www subdomain): www.beagle.dog. CNAME www.hound.dog. www.hound.dog. A 192.0.2.2 Self-managed, tree-climbing: www.staffie.dog. CAA 0 issue "user-facing.ca" staffie.dog. CAA 0 issue "user-facing.ca" www.beagle.dog. CAA 0 issue "user-facing.ca" beagle.dog. CAA 0 issue "user-facing.ca" terrier.dog. CAA 0 issue "enterprise.ca" hound.dog. CAA 0 issue "enterprise.ca" Self-managed, non-tree-climbing: staffie.dog. CAA 0 issue "user-facing.ca" beagle.dog. CAA 0 issue "user-facing.ca" terrier.dog. CAA 0 issue "enterprise.ca" hound.dog. CAA 0 issue "enterprise.ca" Externally-managed, tree-climbing: staffie.dog. CAA 0 issue "user-facing.ca" beagle.dog. CAA 0 issue "user-facing.ca" terrier.dog. CAA 0 issue "enterprise.ca" hound.dog. CAA 0 issue "enterprise.ca" Externally-managed, non-tree-climbing: staffie.dog. CAA 0 issue "user-facing.ca" beagle.dog. CAA 0 issue "user-facing.ca" staffie.terrier.dog. CAA 0 issue "enterprise.ca" terrier.dog. CAA 0 issue "enterprise.ca" www.hound.dog. CAA 0 issue "enterprise.ca" hound.dog. CAA 0 issue "enterprise.ca" Now, if we like, we can factor out the CAA records that appear in every example: those for the base domains staffie.dog, beagle.dog, terrier.dog, and hound.dog. That allows us to look at the differences between the worlds more closely, and see what CAA records are required beyond those: *Reduced examples* Self-managed, tree-climbing: www.staffie.dog. CAA 0 issue "user-facing.ca" www.beagle.dog. CAA 0 issue "user-facing.ca" Self-managed, non-tree-climbing: none Externally-managed, tree-climbing: none Externally-managed, non-tree-climbing: staffie.terrier.dog. CAA 0 issue "enterprise.ca" www.hound.dog. CAA 0 issue "enterprise.ca" *Mixed-management* Complicating things further, we additionally need to consider "Mixed-management," the use case that Patrick described, where CDN certificates are externally managed, but owners of user-facing domains also buy their own certificates for domains that are CDN-managed. I think in practice, all "Externally-managed" arrangements are actually "Mixed-management." Under the assumption that most owners of user-facing domains are unwilling or unable to deploy their own CAA records overriding CDN CAA records, this may make deployment of blanket CAA policies by CDNs impractical, regardless of tree-climbing or non-tree-climbing. --------------021AD533BD46CD5B1241D834 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 03/10/2017 09:02 AM, Ryan Sleevi wrote:
I'm also trying to stick to using domains reserved for purpose, rather than use staffie.dog and terrier.dog.
I chose these advisedly. Example.{com,net,org} are actively harmful for reading comprehension, because their distinguishing parts are small and come at the end rather than the beginning. Since this is a conversation, not a normative document, I believe there's no requirement to use the reserved domains. Do you disagree?

- Self-Managed = The domain operator of example.com handles certificate acquisition for www.example.com
- Externally-Managed = The domain operator of example.net handles certificate acquisition for www.example.com
Good terms, agreed.
- Recursive = As currently specified
- Non-Recursive = As Erratum 4515 proposes
Since we both care about terminology, I'm going to recommend we instead use the RFC 6844 terms I used in my previous email: tree climbing vs non-tree climbing. Recursive already has a technical meaning in RFC 1035 which differs from this one.
- Trampoline = example.com points their CNAME to a host at example.net that is dedicated 'for them' (the 'staffie.example.net' case)
+1.

We end up with the following configurations:
These configurations are a little confusing, since you don't define goals. I assume the goals in this example are:
 (a) Every domain and subdomain in the example is covered by a CAA policy, and
 (b) Those CAA records are compatible with these policies:
    (1) the owner of the user-facing domain will only buy certs from a certain CA
    (2) the owner of the CDN domain will only buy certs from another, different CA.

Is that accurate? I'll adopt the CA names "user-facing.ca." and "enterprise.ca", since both our example CA names implied goodness or badness, which is not relevant to the discussion.

I'm going to introduce one more assumption: the CDN issues certificates for their own internal subdomains, and wants a CAA policy for those. This is necessary to explain why the CDN sets any CAA records at all in the Self-managed case. And I think this is what's implied by your examples - right?

I think it makes the most sense to start with two baseline configs: trampoline'd and non-trampoline'd, and from there define what additional CAA records are necessary in the various worlds of Self-managed vs Externally managed, and tree climbing vs non-.

Trampoline'd config:
www.staffie.dog.        CNAME staffie.terrier.dog.
staffie.terrier.dog.    A 192.0.2.1

Non-trampoline'd config (all customers CNAME to the same www subdomain):
www.beagle.dog.        CNAME www.hound.dog.
www.hound.dog.         A 192.0.2.2


Self-managed, tree-climbing:

www.staffie.dog.        CAA 0 issue "user-facing.ca"
staffie.dog.            CAA 0 issue "user-facing.ca"
www.beagle.dog.         CAA 0 issue "user-facing.ca"
beagle.dog.             CAA 0 issue "user-facing.ca"
terrier.dog.            CAA 0 issue "enterprise.ca"
hound.dog.              CAA 0 issue "enterprise.ca"

Self-managed, non-tree-climbing:

staffie.dog.            CAA 0 issue "user-facing.ca"
beagle.dog.             CAA 0 issue "user-facing.ca"
terrier.dog.            CAA 0 issue "enterprise.ca"
hound.dog.              CAA 0 issue "enterprise.ca"

Externally-managed, tree-climbing:

staffie.dog.            CAA 0 issue "user-facing.ca"
beagle.dog.             CAA 0 issue "user-facing.ca"
terrier.dog.            CAA 0 issue "enterprise.ca"
hound.dog.              CAA 0 issue "enterprise.ca"

Externally-managed, non-tree-climbing:

staffie.dog.            CAA 0 issue "user-facing.ca"
beagle.dog.             CAA 0 issue "user-facing.ca"
staffie.terrier.dog.    CAA 0 issue "enterprise.ca"
terrier.dog.            CAA 0 issue "enterprise.ca"
www.hound.dog.          CAA 0 issue "enterprise.ca"
hound.dog.              CAA 0 issue "enterprise.ca"
Now, if we like, we can factor out the CAA records that appear in every example: those for the base domains staffie.dog, beagle.dog, terrier.dog, and hound.dog. That allows us to look at the differences between the worlds more closely, and see what CAA records are required beyond those:

Reduced examples
Self-managed, tree-climbing:

www.staffie.dog.        CAA 0 issue "user-facing.ca"
www.beagle.dog.         CAA 0 issue "user-facing.ca"

Self-managed, non-tree-climbing:

none

Externally-managed, tree-climbing:

none

Externally-managed, non-tree-climbing:

staffie.terrier.dog.    CAA 0 issue "enterprise.ca"
www.hound.dog.          CAA 0 issue "enterprise.ca"

Mixed-management

Complicating things further, we additionally need to consider "Mixed-management," the use case that Patrick described, where CDN certificates are externally managed, but owners of user-facing domains also buy their own certificates for domains that are CDN-managed. I think in practice, all "Externally-managed" arrangements are actually "Mixed-management." Under the assumption that most owners of user-facing domains are unwilling or unable to deploy their own CAA records overriding CDN CAA records, this may make deployment of blanket CAA policies by CDNs impractical, regardless of tree-climbing or non-tree-climbing.
--------------021AD533BD46CD5B1241D834-- From nobody Fri Mar 10 11:43:43 2017 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 197501299A3 for ; Fri, 10 Mar 2017 11:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 DVKHCjQDCZlu for ; Fri, 10 Mar 2017 11:43:40 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7B7C129998 for ; Fri, 10 Mar 2017 11:43:36 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 342D36000505 for ; Fri, 10 Mar 2017 11:43:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=XIr+F8xVLHQWCwhGILXJFlCompU=; b= Lm6ZiIbHm2F/Wg58g9gh6xM94Wjwo1MBLW8qR8eyI1kMAvbjzSVeVpfxfb4BboGO Zg+sPKh2jnOt8CgSFD3lGJhy0lmleSrCt8aFe1nJtMQYs6tQXlk1WsWLIcakpz2K TKn/oH2+8hw5k2d8TQFMofrGWmrNV/nYp3XsnCSP8s0= Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com [209.85.215.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id C74C86000502 for ; Fri, 10 Mar 2017 11:43:35 -0800 (PST) Received: by mail-lf0-f54.google.com with SMTP id z15so22880777lfd.1 for ; Fri, 10 Mar 2017 11:43:35 -0800 (PST) X-Gm-Message-State: AMke39mqv9ewBJlOfRsB5c1Qj6Qr/GNiR+gxe/inViEng36gG8vt46GWXxcdpE+Ptc+311wq0OKoQONM16+Q1Q== X-Received: by 10.25.157.65 with SMTP id g62mr5555391lfe.29.1489175013876; Fri, 10 Mar 2017 11:43:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.193.197 with HTTP; Fri, 10 Mar 2017 11:43:33 -0800 (PST) In-Reply-To: <8f216ae1-d236-79c1-5baf-44cf7bfa619b@eff.org> References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> <8f216ae1-d236-79c1-5baf-44cf7bfa619b@eff.org> From: Ryan Sleevi Date: Fri, 10 Mar 2017 14:43:33 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary=001a11411ca2b5f0f3054a659394 Archived-At: Cc: Patrick Donahue , Gervase Markham , Phillip Hallam-Baker , Ryan Sleevi , Peter Bowen , SPASM , Rob Stradling Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 19:43:42 -0000 --001a11411ca2b5f0f3054a659394 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 10, 2017 at 2:22 PM, Jacob Hoffman-Andrews wrote: > I chose these advisedly. Example.{com,net,org} are actively harmful for > reading comprehension, because their distinguishing parts are small and > come at the end rather than the beginning. Since this is a conversation, > not a normative document, I believe there's no requirement to use the > reserved domains. Do you disagree? > Considering how many 'discussion' examples I've seen get implemented in code as part of tests (often incorrectly), I try to err on the side of "Do no harm". Especially with countless email and spam filters that are going to start poking the domains to see if they should block the emails. > Since we both care about terminology, I'm going to recommend we instead > use the RFC 6844 terms I used in my previous email: tree climbing vs > non-tree climbing. Recursive already has a technical meaning in RFC 1035 > which differs from this one. > Fair point > These configurations are a little confusing, since you don't define goals. > I assume the goals in this example are: > (a) Every domain and subdomain in the example is covered by a CAA policy, > and > (b) Those CAA records are compatible with these policies: > (1) the owner of the user-facing domain will only buy certs from a > certain CA > (2) the owner of the CDN domain will only buy certs from another, > different CA. > > Is that accurate? I'll adopt the CA names "user-facing.ca." and " > enterprise.ca", since both our example CA names implied goodness or > badness, which is not relevant to the discussion. > I'm not sure user-facing and enterprise brings the level of clarity you hoped for, because it also implies a degree of policy that is different from the self-managed/externally managed case. But I think we're in agreement that we're talking "Foo" and "Bar" and never the twain shall meet. > I'm going to introduce one more assumption: the CDN issues certificates > for their own internal subdomains, and wants a CAA policy for those. This > is necessary to explain why the CDN sets any CAA records at all in the > Self-managed case. And I think this is what's implied by your examples - > right? > I think "internal subdomains" introduces an unnecessary degree of ambiguity, especially with your example of "enterprise.ca". I'm not sure if this is indicative that we're talking past each other or not. Both organizations want to set their own CAA policy as appropriate. I think that should be uncontroversial and without complication. > I think it makes the most sense to start with two baseline configs: > trampoline'd and non-trampoline'd, and from there define what *additional* > CAA records are necessary in the various worlds of Self-managed vs > Externally managed, and tree climbing vs non-. > > Trampoline'd config: > > www.staffie.dog. CNAME staffie.terrier.dog. > staffie.terrier.dog. A 192.0.2.1 > > > Non-trampoline'd config (all customers CNAME to the same www subdomain): > > www.beagle.dog. CNAME www.hound.dog.www.hound.dog. A 192.0.2.2 > > > Self-managed, tree-climbing: > > www.staffie.dog. CAA 0 issue "user-facing.ca"staffie.dog. CAA 0 issue "user-facing.ca"www.beagle.dog. CAA 0 issue "user-facing.ca"beagle.dog. CAA 0 issue "user-facing.ca" > terrier.dog. CAA 0 issue "enterprise.ca" > hound.dog. CAA 0 issue "enterprise.ca" > > I personally find this structure much harder to follow, so I may have missed things - if only because you're describing the permutations for trampoline and non-trampoline in the same configuration, and I think that makes it harder to compare the implications of these two configurations - which was very much my objective in providing further discussion. > Now, if we like, we can factor out the CAA records that appear in every > example: those for the base domains staffie.dog, beagle.dog, terrier.dog, > and hound.dog. That allows us to look at the differences between the worlds > more closely, and see what CAA records are required beyond those: > I'm sorry. At this point, I'm no longer able to follow your logic, despite having read this several times. --001a11411ca2b5f0f3054a659394 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 10, 2017 at 2:22 PM, Jacob Hoffman-Andrews <jsha@eff.org>= ; wrote:
=20 =20 =20
I chose these advisedly. Exampl= e.{com,net,org} are actively harmful for reading comprehension, because their distinguishing parts are small and come at the end rather than the beginning. Since this is a conversation, not a normative document, I believe there's no requirement to use the reserved domains. Do you disagree?

Considering how many 'discussion' examples= I've seen get implemented in code as part of tests (often incorrectly)= , I try to err on the side of "Do no harm". Especially with count= less email and spam filters that are going to start poking the domains to s= ee if they should block the emails.
=C2=A0
Since we both care = about terminology, I'm going to recommend we instead use the RFC 6844 terms I used in my previous email: tree climbing vs non-tree climbing. Recursive already has a technical meaning in RFC 1035 which differs from this one.

Fair point
=C2=A0
These configurations are a little confusing, since you don't define goals. I assume the goals in this example are:
=C2=A0(a) Every domain and subdomain in the example is covered by a CAA policy, and
=C2=A0(b) Those CAA records are compatible with these policies:
=C2=A0=C2=A0=C2=A0 (1) the owner of the user-facing domain will only bu= y certs from a certain CA
=C2=A0=C2=A0=C2=A0 (2) the owner of the CDN domain will only buy certs = from another, different CA.

Is that accurate? I'll adopt the CA names "user-facing.ca." and "enterprise.ca<= /a>", since both our example CA names implied goodness or badness, which is not relevant to the discussion.

I'm going to introduce one more assumption: the CDN issues certificates for their own internal subdomains, and wants a CAA policy for those. This is necessary to explain why the CDN sets any CAA records at all in the Self-managed case. And I think this is what's implied by your examples - right?

Both organizations want to set their own CAA policy as appropri= ate. I think that should be uncontroversial and without complication.
=
=C2=A0
I think it makes the most sense to start with two baseline configs: trampoline'd and non-trampoline'd, and from there define what <= b>additional CAA records are necessary in the various worlds of Self-managed vs Externally managed, and tree climbing vs non-.

Trampoline'd config:
www.staffie.dog.        CNAME staf=
fie.terrier.dog.
staffie.terrier.dog.    A 192.0.2.1

 Non-trampoline'd config (all customers CNAME to the same www subdomain):
www.beagle.dog.        CNAME www.hound.dog.
www.hound.dog.         A 192.0.2.2


Self-managed, tree-climbing:

www.staffie.dog.        CAA 0 issu=
e "user-facing.ca<=
/a>"
staffie.dog.            CAA 0 issue "user-facing.ca"
www.beagle.dog.         CAA 0 issue "user-facing.ca"
beagle.dog.             CAA 0 issue "user-facing.ca"
terrier.dog.            CAA 0 issue "enterprise.ca"
hound.dog.              CAA 0 issue "enterprise.ca"
I pe= rsonally find this structure much harder to follow, so I may have missed th= ings - if only because you're describing the permutations for trampolin= e and non-trampoline in the same configuration, and I think that makes it h= arder to compare the implications of these two configurations - which was v= ery much my objective in providing further discussion.
=C2=A0
Now, if we like, we can factor out the CAA records that appear in every example: those for the base domains staffie.dog, beagle.dog, terrier.dog, and hound.dog. That allows us to look at the differences between the worlds more closely, and see what CAA records are required beyond those:

I'm sorry. At this point, I'm no longer able to follow your l= ogic, despite having read this several times.

--001a11411ca2b5f0f3054a659394-- From nobody Fri Mar 10 12:22:38 2017 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 81FE3129452 for ; Fri, 10 Mar 2017 12:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.003 X-Spam-Level: X-Spam-Status: No, score=-7.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=eff.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 hw5lqVbSiIlc for ; Fri, 10 Mar 2017 12:22:33 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01CF3129424 for ; Fri, 10 Mar 2017 12:22:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=lJAsRenkMzGhrMGuSiLQrw/zSLKTjfZj9MFSVfNEFxw=; b=JphGtxV7RDTvRPKQyUrhidZBHFc19PxGJB4V9WJfg05hY7MckZXtbXDUlupwZdVpnw/D5y+npW2DVtXpQlK9SwXUK6neIXv5/Si7Hdx642uG4P8qV4YvJkUsvSeQR4K4Wjeue3IJheijy4qqzGTUYr5gpeO98dSo+CiZURg91Jo=; Received: ; Fri, 10 Mar 2017 12:22:34 -0800 To: Ryan Sleevi References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> <8f216ae1-d236-79c1-5baf-44cf7bfa619b@eff.org> From: Jacob Hoffman-Andrews Message-ID: <7f9c38ad-aa39-c403-0320-7300619b9986@eff.org> Date: Fri, 10 Mar 2017 12:22:30 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------ACC8B9E13D8915D03D20EB2A" Received-SPF: skipped for local relay Archived-At: Cc: Patrick Donahue , Gervase Markham , Phillip Hallam-Baker , Peter Bowen , SPASM , Rob Stradling Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 20:22:35 -0000 This is a multi-part message in MIME format. --------------ACC8B9E13D8915D03D20EB2A Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/10/2017 11:43 AM, Ryan Sleevi wrote: > I'm going to introduce one more assumption: the CDN issues > certificates for their own internal subdomains, and wants a CAA policy > for those. This is necessary to explain why the CDN sets any CAA > records at all in the Self-managed case. And I think this is what's > implied by your examples - right? > > I think "internal subdomains" introduces an unnecessary degree of > ambiguity, especially with your example of "enterprise.ca > ". I'm not sure if this is indicative that we're > talking past each other or not. > > Both organizations want to set their own CAA policy as appropriate. I > think that should be uncontroversial and without complication. Agreed. To aid understanding, could you re-explain in your own words why your examples show the CDN setting CAA records in the Self-managed case? I copied that into my own examples for consistency, by I had to guess at the reasons. > These configurations are a little confusing, since you don't define > goals. I assume the goals in this example are: > (a) Every domain and subdomain in the example is covered by a CAA > policy, and Can you confirm whether this is an implicit goal in your examples? > > Now, if we like, we can factor out the CAA records that appear in > every example: those for the base domains staffie.dog, beagle.dog, > terrier.dog, and hound.dog. That allows us to look at the > differences between the worlds more closely, and see what CAA > records are required beyond those: > > > I'm sorry. At this point, I'm no longer able to follow your logic, > despite having read this several times. Sure, I'll re-explain: If you look at the examples, you'll find they all have these four CAA entries in common: staffie.dog. CAA 0 issue "user-facing.ca" beagle.dog. CAA 0 issue "user-facing.ca" terrier.dog. CAA 0 issue "enterprise.ca" hound.dog. CAA 0 issue "enterprise.ca" The "reduced examples" are simply the regular examples with those common entries removed. > I personally find this structure much harder to follow, so I may have > missed things - if only because you're describing the permutations for > trampoline and non-trampoline in the same configuration, and I think > that makes it harder to compare the implications of these two > configurations - which was very much my objective in providing further > discussion. My goal here was to give trampoline and non-trampoline examples their own distinct names, so we can compare them side-by-side in each world. The conclusion I come to is that there is not a significant difference. Maybe we can come at this from a different angle: I think you are saying that in the non-tree-climbing world, CDNs would need to use the trampoline to make it possible (or convenient?) to express a certain CAA policy. You and I agree that forcing CDNs to use trampolines to express a certain CAA policy is undesirable. I disagree that trampolines are necessary in either the tree climbing or the non-tree-climbing world. Let's try to answer some specific questions: - Are you arguing that trampolines make a certain policy possible, or just more convenient? - In the non-tree-climbing world, are you arguing that trampolines are necessary for Self-managed, Externally-managed, or both? --------------ACC8B9E13D8915D03D20EB2A Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 03/10/2017 11:43 AM, Ryan Sleevi wrote:
I'm going to introduce one more assumption: the CDN issues certificates for their own internal subdomains, and wants a CAA policy for those. This is necessary to explain why the CDN sets any CAA records at all in the Self-managed case. And I think this is what's implied by your examples - right?

I think "internal subdomains" introduces an unnecessary degree of ambiguity, especially with your example of "enterprise.ca". I'm not sure if this is indicative that we're talking past each other or not.

Both organizations want to set their own CAA policy as appropriate. I think that should be uncontroversial and without complication.
Agreed. To aid understanding, could you re-explain in your own words why your examples show the CDN setting CAA records in the Self-managed case? I copied that into my own examples for consistency, by I had to guess at the reasons.

These configurations are a little confusing, since you don't define goals. I assume the goals in this example are:
 (a) Every domain and subdomain in the example is covered by a CAA policy, and
Can you confirm whether this is an implicit goal in your examples?


Now, if we like, we can factor out the CAA records that appear in every example: those for the base domains staffie.dog, beagle.dog, terrier.dog, and hound.dog. That allows us to look at the differences between the worlds more closely, and see what CAA records are required beyond those:

I'm sorry. At this point, I'm no longer able to follow your logic, despite having read this several times.
Sure, I'll re-explain: If you look at the examples, you'll find they all have these four CAA entries in common:

staffie.dog.            CAA 0 issue "user-facing.ca"
beagle.dog.             CAA 0 issue "user-facing.ca"
terrier.dog.            CAA 0 issue "enterprise.ca"
hound.dog.              CAA 0 issue "enterprise.ca"
The "reduced examples" are simply the regular examples with those common entries removed.

I personally find this structure much harder to follow, so I may have missed things - if only because you're describing the permutations for trampoline and non-trampoline in the same configuration, and I think that makes it harder to compare the implications of these two configurations - which was very much my objective in providing further discussion.
My goal here was to give trampoline and non-trampoline examples their own distinct names, so we can compare them side-by-side in each world. The conclusion I come to is that there is not a significant difference.

Maybe we can come at this from a different angle: I think you are saying that in the non-tree-climbing world, CDNs would need to use the trampoline to make it possible (or convenient?) to express a certain CAA policy.

You and I agree that forcing CDNs to use trampolines to express a certain CAA policy is undesirable. I disagree that trampolines are necessary in either the tree climbing or the non-tree-climbing world. Let's try to answer some specific questions:

- Are you arguing that trampolines make a certain policy possible, or just more convenient?
- In the non-tree-climbing world, are you arguing that trampolines are necessary for Self-managed, Externally-managed, or both?
--------------ACC8B9E13D8915D03D20EB2A-- From nobody Fri Mar 10 13:18:45 2017 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 61E8712946A for ; Fri, 10 Mar 2017 13:18:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 eKYRefgFMpRt for ; Fri, 10 Mar 2017 13:18:43 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60082129408 for ; Fri, 10 Mar 2017 13:18:43 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id E1232A00400E for ; Fri, 10 Mar 2017 13:18:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=gMbWMqMc6vOZ4cg8IeCuFYmbaaY=; b= qOgMtM9W/yT59SesWqj1FpgY+uWWokYm3S0BNB0gEmNlPAHvRGYxcgFL8+HKW2tQ j5/Q+nSyMV61t6X8VkY4IhJns1sFfIfNu08A7JujXSEF6u+c3QtyvH43+kFIyTeM GpDrzhFHbW5ZiiLHUo55EFa43Qc7lyMh6mDGpgcRKW0= Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com [209.85.215.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 81B7AA000107 for ; Fri, 10 Mar 2017 13:18:42 -0800 (PST) Received: by mail-lf0-f43.google.com with SMTP id y193so45684021lfd.3 for ; Fri, 10 Mar 2017 13:18:42 -0800 (PST) X-Gm-Message-State: AFeK/H0VGXsj7Ppqu1FOXondvykHTrH00oPwkZZcVhtmjAtrmrvPi14uz+4U/CDg3WTCzWL4oXGqZ2r2myOGaQ== X-Received: by 10.46.22.85 with SMTP id 21mr562848ljw.113.1489180720790; Fri, 10 Mar 2017 13:18:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.193.197 with HTTP; Fri, 10 Mar 2017 13:18:40 -0800 (PST) In-Reply-To: <7f9c38ad-aa39-c403-0320-7300619b9986@eff.org> References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> <8f216ae1-d236-79c1-5baf-44cf7bfa619b@eff.org> <7f9c38ad-aa39-c403-0320-7300619b9986@eff.org> From: Ryan Sleevi Date: Fri, 10 Mar 2017 16:18:40 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary=f403045fc1a0de88ab054a66e73c Archived-At: Cc: Patrick Donahue , Gervase Markham , Phillip Hallam-Baker , Ryan Sleevi , Peter Bowen , SPASM , Rob Stradling Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 21:18:44 -0000 --f403045fc1a0de88ab054a66e73c Content-Type: text/plain; charset=UTF-8 On Fri, Mar 10, 2017 at 3:22 PM, Jacob Hoffman-Andrews wrote: > On 03/10/2017 11:43 AM, Ryan Sleevi wrote: > > Agreed. To aid understanding, could you re-explain in your own words why > your examples show the CDN setting CAA records in the Self-managed case? I > copied that into my own examples for consistency, by I had to guess at the > reasons. > Which example? Are you talking about "example.net CAA 0 issue " evil-ca.example.org" ? That's because the site operator should be able to set their own policy for their own domains. This is why I dislike the "CDN" example, because it comes with it the implication that somehow "example.net" is reserved only for CDN customers, whereas I think the marketing site example, a more common scenario, has the marketing company providing services at their own domain (e.g. "www.example.net") and co-hosts one or more customer domains (" terrier.example.net"). The point here is that it's rare for a single domain tree to be limited to a single (self-hosted/externally-hosted) policy. > These configurations are a little confusing, since you don't define goals. > I assume the goals in this example are: > (a) Every domain and subdomain in the example is covered by a CAA policy, > and > > Can you confirm whether this is an implicit goal in your examples? > I'm not sure I would suggest it like that, but again, I think we may simply be agreeing but talking past eachother :) I see "example.com" and " example.net" as two independent organizations with their own policies, for which they wish to express as efficiently and simply as possible. > The "reduced examples" are simply the regular examples with those common > entries removed. > Right, but I think the understanding of these policies - and that these policies are in play - are key to making progress and discussion :) The fact that it involves remembering whether or not a policy is set (implicitly) is exactly why I tried to explicitly indicate in all of the examples what I mentioned above - different domains have different policies. > My goal here was to give trampoline and non-trampoline examples their own > distinct names, so we can compare them side-by-side in each world. The > conclusion I come to is that there is not a significant difference. > Right, and the conclusion I've come to is that the level of operational burden shifts, subtlely, and while I think both offer a degree of flexibility to allow the use cases, the burden for how that configuration is made and managed is sufficient enough to prefer one over the other - this is the subjective portion that I was leading to, by first making sure we had a consistent objective measure. > Maybe we can come at this from a different angle: I think you are saying > that in the non-tree-climbing world, CDNs would need to use the trampoline > to make it possible (or convenient?) to express a certain CAA policy. > If domain operators wish to operate with their own policy, but support customers with another policy, the trampoline is necessary or the customer has an additional configuration step. If domain operators wish to operate with their own policy, and support customers with the same policy (on the domains the domain operator operates), while allowing their customers to operate with their own policy on the customer domains, the trampoline is necessary. - Are you arguing that trampolines make a certain policy possible, or just > more convenient? > - In the non-tree-climbing world, are you arguing that trampolines are > necessary for Self-managed, Externally-managed, or both? > I think both of these questions misunderstands what I was trying to present. I think you're seeing it as a discussion about whether or not trampolines are required - I was attempting to discuss how the configuration looks when trampolines are used, and when they're not, and compare the operational difficulties that arise in supporting both self-managed and externally-managed issuance policies in both tree-walking and non-tree-walking scenarios. --f403045fc1a0de88ab054a66e73c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 10, 2017 at 3:22 PM, Jacob Hoffman-Andrews <jsha@eff.org>= ; wrote:
=20 =20 =20
On 03/10/2017 11:43 AM, Ryan Sleevi wrote:
 Agreed. To aid understanding, could you re-explain in your own words why your examples show the CDN setting CAA records in the Self-managed case? I copied that into my own examples for consistency, by I had to guess at the reasons.
<= br>
Which example? Are you talking about "example.net =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CAA 0 issue= "evil-ca.example.org"= ?

That's because the site operator should be = able to set their own policy for their own domains. This is why I dislike t= he "CDN" example, because it comes with it the implication that s= omehow "example.net" is reserv= ed only for CDN customers, whereas I think the marketing site example, a mo= re common scenario, has the marketing company providing services at their o= wn domain (e.g. "www.example.net") and co-hosts one or more customer domains ("terrier.example.net"). The point here is tha= t it's rare for a single domain tree to be limited to a single (self-ho= sted/externally-hosted) policy.

=C2=A0
These configurations are a little confusing, since you don't define goals. I assume the goals in this example are:
=C2=A0(a) Every domain and subdomain in the example is covered by a C= AA policy, and
 Can you confirm whether this is an implicit goal in your examples?

I'm not sure I would suggest it like = that, but again, I think we may simply be agreeing but talking past eachoth= er :) I see "example.com" and = "example.net" as two independe= nt organizations with their own policies, for which they wish to express as= efficiently and simply as possible.
=C2=A0
The "reduced examples" are simply the regular examples with t= hose common entries removed.

Right, bu= t I think the understanding of these policies - and that these policies are= in play - are key to making progress and discussion :) The fact that it in= volves remembering whether or not a policy is set (implicitly) is exactly w= hy I tried to explicitly indicate in all of the examples what I mentioned a= bove - different domains have different policies.
=C2=A0
My goal here was to give trampoline and non-trampoline examples their own distinct names, so we can compare them side-by-side in each world. The conclusion I come to is that there is not a significant difference.

Right= , and the conclusion I've come to is that the level of operational burd= en shifts, subtlely, and while I think both offer a degree of flexibility t= o allow the use cases, the burden for how that configuration is made and ma= naged is sufficient enough to prefer one over the other - this is the subje= ctive portion that I was leading to, by first making sure we had a consiste= nt objective measure.
=C2=A0
Maybe we can come at this from a different angle: I think you are saying that in the non-tree-climbing world, CDNs would need to use the trampoline to make it possible (or convenient?) to express a certain CAA policy.

If domain= operators wish to operate with their own policy, but support customers wit= h another policy, the trampoline is necessary or the customer has an additi= onal configuration step.
If domain operators wish to operate with= their own policy, and support customers with the same policy (on the domai= ns the domain operator operates), while allowing their customers to operate= with their own policy on the customer domains, the trampoline is necessary= .


- Are you arguing that trampolines make a certain policy possible, or just more convenient?
- In the non-tree-climbing w= orld, are you arguing that trampolines are necessary for Self-managed, Externally-managed, or both?

I think both of the= se questions misunderstands what I was trying to present. I think you'r= e seeing it as a discussion about whether or not trampolines are required -= I was attempting to discuss how the configuration looks when trampolines a= re used, and when they're not, and compare the operational difficulties= that arise in supporting both self-managed and externally-managed issuance= policies in both tree-walking and non-tree-walking scenarios.
--f403045fc1a0de88ab054a66e73c-- From nobody Fri Mar 10 13:50:58 2017 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 8888F1294AA for ; Fri, 10 Mar 2017 13:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.003 X-Spam-Level: X-Spam-Status: No, score=-7.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=eff.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 fwCnXF_fOygz for ; Fri, 10 Mar 2017 13:50:53 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 862BC129452 for ; Fri, 10 Mar 2017 13:50:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=WGQ+tCxAg5jZ9SzGQ+UxzgdXINP/a/4luaiC4LukRGQ=; b=iHoeJrmtgTx3bGE8Qa0Ks06ZinhvudwEKw501Ljn7eH35ZgAhsUtPxW66Thu7GW5Jj5OjPt+yZdOJJAa+v/DPXHSW9cj12FhYcZEA2mjU7OcmTnH4oKES+2LCeQrXipXH6rWt+hayeE0R8T7u/7GwGi0qbymIXdV58sp1cBQVfY=; Received: ; Fri, 10 Mar 2017 13:50:54 -0800 To: Ryan Sleevi References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> <8f216ae1-d236-79c1-5baf-44cf7bfa619b@eff.org> <7f9c38ad-aa39-c403-0320-7300619b9986@eff.org> From: Jacob Hoffman-Andrews Message-ID: Date: Fri, 10 Mar 2017 13:50:51 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EF636348A49E62651C6696DE" Received-SPF: skipped for local relay Archived-At: Cc: Patrick Donahue , Gervase Markham , Phillip Hallam-Baker , Peter Bowen , SPASM , Rob Stradling Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 21:50:55 -0000 This is a multi-part message in MIME format. --------------EF636348A49E62651C6696DE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/10/2017 01:18 PM, Ryan Sleevi wrote: > Which example? Are you talking about "example.net > CAA 0 issue "evil-ca.example.org = " ? Yep. > > That's because the site operator should be able to set their own > policy for their own domains. This is why I dislike the "CDN" example, > because it comes with it the implication that somehow "example.net > " is reserved only for CDN customers, whereas I > think the marketing site example, a more common scenario, has the > marketing company providing services at their own domain (e.g. > "www.example.net ") and co-hosts one or more > customer domains ("terrier.example.net "). > The point here is that it's rare for a single domain tree to be > limited to a single (self-hosted/externally-hosted) policy. Great, looks like we're in agreement here. Personally I was taking it for granted that CDNs (or hosting providers) often have a mix of subdomains serving both their own sites and their customer sites, so this didn't feel confusing, but I appreciate you clarifying it. > > =20 > >> These configurations are a little confusing, since you don't >> define goals. I assume the goals in this example are: >> (a) Every domain and subdomain in the example is covered by a >> CAA policy, and > Can you confirm whether this is an implicit goal in your examples? > > > I'm not sure I would suggest it like that, but again, I think we may > simply be agreeing but talking past eachother :) I see "example.com > " and "example.net " as two > independent organizations with their own policies, for which they wish > to express as efficiently and simply as possible. Yep, that makes sense. One thing that might help is to detail that there are actually three policies in play, that we've tended to squash into two= : 1. Policy set by user-facing domain owner for their own hostnames. 2. Blanket policy set by CDN for hostnames they operate on their customers' behalf. 3. Policy set by CDN for their own hostnames, which share the same base domain as the CNAME targets used in (2). The goal is that these can be set as three independent policies, without unintended interactions. Also, one thing I want to clarify: To what extent are you trying to incentivize (2) and make it easy to do? I've been assuming that's a core goal for you, but I may be misunderstanding that. > If domain operators wish to operate with their own policy, but support > customers with another policy, the trampoline is necessary or the > customer has an additional configuration step. This depends. Are the CDNs trying to support unique policies on a per-customer basis, or a blanket policy as in (2) above? If it's a blanket policy, no trampoline is needed. The CDN does need to have a CNAME target that is not a base domain, but that target doesn't need to be unique per-customer: i.e., not a trampoline. > If domain operators wish to operate with their own policy, and support > customers with the same policy (on the domains the domain operator > operates), while allowing their customers to operate with their own > policy on the customer domains, the trampoline is necessary. I don't think this case is significantly different than the above. One policy gets set on the CDN's base domain, while the other policy gets set on the CNAME target. If those policies happen to be the same, that's fine. --------------EF636348A49E62651C6696DE Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 03/10/2017 01:18 PM, Ryan Sleevi wrote:
Which example? Are you talking about "example.net           CAA 0 issue "evil-ca.example.org" ?
Yep.

That's because the site operator should be able to set their own policy for their own domains. This is why I dislike the "CDN" example, because it comes with it the implication that somehow "example.net" is reserved only for CDN customers, whereas I think the marketing site example, a more common scenario, has the marketing company providing services at their own domain (e.g. "www.example.net") and co-hosts one or more customer domains ("terrier.example.net"). The point here is that it's rare for a single domain tree to be limited to a single (self-hosted/externally-hosted) policy.
Great, looks like we're in agreement here. Personally I was taking it for granted that CDNs (or hosting providers) often have a mix of subdomains serving both their own sites and their customer sites, so this didn't feel confusing, but I appreciate you clarifying it.

 
These configurations are a little confusing, since you don't define goals. I assume the goals in this example are:
 (a) Every domain and subdomain in the example is covered by a CAA policy, and
 Can you confirm whether this is an implicit goal in your examples?

I'm not sure I would suggest it like that, but again, I think we may simply be agreeing but talking past eachother :) I see "example.com" and "example.net" as two independent organizations with their own policies, for which they wish to express as efficiently and simply as possible.
Yep, that makes sense. One thing that might help is to detail that there are actually three policies in play, that we've tended to squash into two:

1. Policy set by user-facing domain owner for their own hostnames.
2. Blanket policy set by CDN for hostnames they operate on their customers' behalf.
3. Policy set by CDN for their own hostnames, which share the same base domain as the CNAME targets used in (2).

The goal is that these can be set as three independent policies, without unintended interactions.

Also, one thing I want to clarify: To what extent are you trying to incentivize (2) and make it easy to do? I've been assuming that's a core goal for you, but I may be misunderstanding that.
If domain operators wish to operate with their own policy, but support customers with another policy, the trampoline is necessary or the customer has an additional configuration step.
This depends. Are the CDNs trying to support unique policies on a per-customer basis, or a blanket policy as in (2) above? If it's a blanket policy, no trampoline is needed. The CDN does need to have a CNAME target that is not a base domain, but that target doesn't need to be unique per-customer: i.e., not a trampoline.
If domain operators wish to operate with their own policy, and support customers with the same policy (on the domains the domain operator operates), while allowing their customers to operate with their own policy on the customer domains, the trampoline is necessary.
I don't think this case is significantly different than the above. One policy gets set on the CDN's base domain, while the other policy gets set on the CNAME target. If those policies happen to be the same, that's fine.
--------------EF636348A49E62651C6696DE-- From nobody Fri Mar 10 14:52:04 2017 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 CEC1E129410 for ; Fri, 10 Mar 2017 14:52:02 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 T-mUwfVKBbJ5 for ; Fri, 10 Mar 2017 14:52:01 -0800 (PST) Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50E751293E8 for ; Fri, 10 Mar 2017 14:52:01 -0800 (PST) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id C24E330005C24 for ; Fri, 10 Mar 2017 14:52:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=9oT03KG8ePgG96l2CvK6DQu4rFM=; b= hOAxIv6CMxtOFRmoWYoeQuiiqUKGYhaAnU/vkiesFwVMvzwMz5119dLit17aFFQx zcvtbu6sprrqOpdpCEvxZfdKZz+WAXKj1tgVnaRq79GYpBZDnp7qXnA3GwwTX+xC 3BwMCfpBls+0YBxmOuEkoTegTjeI1gRMBAWlZomkfho= Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPSA id 6A53F30005C20 for ; Fri, 10 Mar 2017 14:52:00 -0800 (PST) Received: by mail-lf0-f46.google.com with SMTP id a6so46419272lfa.0 for ; Fri, 10 Mar 2017 14:52:00 -0800 (PST) X-Gm-Message-State: AMke39lU+eNaJO1hH24QH3GHe3NfQ/H3tufHE2ovGcXUtJ+9eMYTYfUDda8/p2w+oYnjsm6ImrADn3ohufUkpA== X-Received: by 10.25.204.9 with SMTP id c9mr4957183lfg.107.1489186318705; Fri, 10 Mar 2017 14:51:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.193.197 with HTTP; Fri, 10 Mar 2017 14:51:58 -0800 (PST) In-Reply-To: References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> <8f216ae1-d236-79c1-5baf-44cf7bfa619b@eff.org> <7f9c38ad-aa39-c403-0320-7300619b9986@eff.org> From: Ryan Sleevi Date: Fri, 10 Mar 2017 17:51:58 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary=94eb2c1a1c8287eea5054a6835a2 Archived-At: Cc: Patrick Donahue , Gervase Markham , Phillip Hallam-Baker , Ryan Sleevi , Peter Bowen , SPASM , Rob Stradling Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 22:52:03 -0000 --94eb2c1a1c8287eea5054a6835a2 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 10, 2017 at 4:50 PM, Jacob Hoffman-Andrews wrote: > One thing that might help is to detail that there are actually three > policies in play, that we've tended to squash into two: > > 1. Policy set by user-facing domain owner for their own hostnames. > 2. Blanket policy set by CDN for hostnames they operate on their > customers' behalf. > 3. Policy set by CDN for their own hostnames, which share the same base > domain as the CNAME targets used in (2). > > The goal is that these can be set as three independent policies, without > unintended interactions. > > Also, one thing I want to clarify: To what extent are you trying to > incentivize (2) and make it easy to do? I've been assuming that's a core > goal for you, but I may be misunderstanding that. > Thanks for summarizing that, and I agree - it's really three different things. I don't even think I'm trying to incentivize (2), so much as try to figure out the solution that allows the least changes to be made re: DNS records to support the most number of variations of these policies, and to identify where the most likely failure points are with respect to complexity. Or, put differently, I want as many people to be able to set CAA policies that work "out of the box" with minimal configuration. This, of course, relies on a subjective interpretation of what the most likely scenarios are, and I want to fully acknowledge that up-front. I think both tree-climbing and non-tree-climbing can work, to be abundantly clear :) > If domain operators wish to operate with their own policy, but support > customers with another policy, the trampoline is necessary or the customer > has an additional configuration step. > > This depends. Are the CDNs trying to support unique policies on a > per-customer basis, or a blanket policy as in (2) above? If it's a blanket > policy, no trampoline is needed. The CDN does need to have a CNAME target > that is not a base domain, but that target doesn't need to be unique > per-customer: i.e., not a trampoline. > Fair point - some indirection is necessary, but it's not necessarily per-customer indirection. > If domain operators wish to operate with their own policy, and support > customers with the same policy (on the domains the domain operator > operates), while allowing their customers to operate with their own policy > on the customer domains, the trampoline is necessary. > > I don't think this case is significantly different than the above. One > policy gets set on the CDN's base domain, while the other policy gets set > on the CNAME target. If those policies happen to be the same, that's fine. > Fair point here as well. The complexity then comes from whether this reflects current deployment, or whether it reflects a point of deployment which would have to change to support. I think this is what you've identified in (2). The fewer things that need to change - and just work out of the box - the better the deployment scenario for CAA looks. My instinct - perhaps incorrectly - is that tree climbing allows fewer changes for the most participants, not that tree climbing is an intrinsic necessity. --94eb2c1a1c8287eea5054a6835a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 10, 2017 at 4:50 PM, Jacob Hoffman-Andrews <jsha@eff.org>= ; wrote:
=20 =20 =20
One thing that might help is to detail that there are actually three policies in play, that we've tended to squash into two:

1. Policy set by user-facing domain owner for their own hostnames.
2. Blanket policy set by CDN for hostnames they operate on their customers' behalf.
3. Policy set by CDN for their own hostnames, which share the same base domain as the CNAME targets used in (2).

The goal is that these can be set as three independent policies, without unintended interactions.

Also, one thing I want to clarify: To what extent are you trying to incentivize (2) and make it easy to do? I've been assuming that'= ;s a core goal for you, but I may be misunderstanding that.

Thanks for summarizing that, and I agree - it's r= eally three different things.

I don't even thi= nk I'm trying to incentivize (2), so much as try to figure out the solu= tion that allows the least changes to be made re: DNS records to support th= e most number of variations of these policies, and to identify where the mo= st likely failure points are with respect to complexity.

Or, put differently, I want as many people to be able to set CAA pol= icies that work "out of the box" with minimal configuration. This= , of course, relies on a subjective interpretation of what the most likely = scenarios are, and I want to fully acknowledge that up-front. I think both = tree-climbing and non-tree-climbing=C2=A0can work, to be abundantly clear := )
=C2=A0
<= div bgcolor=3D"#FFFFFF">
If domain operators wish to operate with their own policy, but support customers with another policy, the trampoline is necessary or the customer has an additional configuration step.
 This depends. Are the CDNs trying to support unique policies on a per-customer basis, or a blanket policy as in (2) above? If it's a blanket policy, no trampoline is needed. The CDN does need to have a CNAME target that is not a base domain, but that target doesn't nee= d to be unique per-customer: i.e., not a trampoline.

Fair point - some indirection is necessary, but it's = not necessarily per-customer indirection.
=C2=A0
If domain operators wish to operate with their own policy, and support customers with the same policy (on the domains the domain operator operates), while allowing their customers to operate with their own policy on the customer domains, the trampoline is necessary.
 I don't think this case is significantly different than the above. One policy gets set on the CDN's base domain, while the other polic= y gets set on the CNAME target. If those policies happen to be the same, that's fine.

Fair point here as = well. The complexity then comes from whether this reflects current deployme= nt, or whether it reflects a point of deployment which would have to change= to support. I think this is what you've identified in (2).

The fewer things = that need to change - and just work out of the box - the better the deploym= ent scenario for CAA looks. My instinct - perhaps incorrectly - is that tre= e climbing=C2=A0allows fewer changes for the most participants, not that tr= ee climbing is an intrinsic necessity.
--94eb2c1a1c8287eea5054a6835a2-- From nobody Fri Mar 10 15:47:54 2017 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 71CBA12948A for ; Fri, 10 Mar 2017 15:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.003 X-Spam-Level: X-Spam-Status: No, score=-7.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=eff.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 KC9c1LgJaYmJ for ; Fri, 10 Mar 2017 15:47:50 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1C61289C4 for ; Fri, 10 Mar 2017 15:47:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=nANXCFECHFPpdXvaTGXMLlhwF3asr7E9JvGBSpZ/ZzU=; b=QlP3+QzHVhh8ataGh2SPAIkKovS/Mt4JCjmim5Uz//X1ffvtErxh8Trq4YgcjsswHoDRJJYCa9ENHxOppLMKLB7WJTJn36+CKdX42PlDG4SW06UqjSLyCz36y7Q4V/71vR6BvDHCph+ooC3uJMrmQ5gf9+HsrbAGzzV9pMelHlY=; Received: ; Fri, 10 Mar 2017 15:47:51 -0800 To: Ryan Sleevi References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> <8f216ae1-d236-79c1-5baf-44cf7bfa619b@eff.org> <7f9c38ad-aa39-c403-0320-7300619b9986@eff.org> From: Jacob Hoffman-Andrews Message-ID: Date: Fri, 10 Mar 2017 15:47:48 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F1ABC4BB6CE4B5614E5101D9" Received-SPF: skipped for local relay Archived-At: Cc: Patrick Donahue , Gervase Markham , Phillip Hallam-Baker , Peter Bowen , SPASM , Rob Stradling Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 23:47:52 -0000 This is a multi-part message in MIME format. --------------F1ABC4BB6CE4B5614E5101D9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cool, sounds like we are now on the same page, and can start talking in more subjective terms. On 03/10/2017 02:51 PM, Ryan Sleevi wrote: > > 1. Policy set by user-facing domain owner for their own hostnames. > 2. Blanket policy set by CDN for hostnames they operate on their > customers' behalf. > 3. Policy set by CDN for their own hostnames, which share the same > base domain as the CNAME targets used in (2). > I think (1) is easily handled by both tree-climbing and non-tree-climbing implementations. Both (2) and (3) are handled by both tree-climbing and non-tree-climbing implementations with deployment of two CAA records. If the policies happen to be the same, tree climbing allows the CDN to economize on CAA records by deploying just one, on their base domain. However, I think the policies are not likely to be the same. The feedback we've gotten so far from Patrick is that Cloudflare is unlikely to implement (2) because, like most CDNs and hosting providers, they are effectively a Mixed-management setup. So, what if a CDN wants to implement (3), but specifically avoid (2)? This is very easy in the non-tree-climbing world: they set a single CAA record on their base domain. In the tree-climbing world, it's very hard. The CDN would need to specify a restrictive CAA record on their base domain, and then another CAA record that specifies "Nevermind, everything is allowed again" on their CNAME target, in order to block tree-climbing to their root domain. As far as I can see, RFC 6844 doesn't define a "Nevermind, everything is allowed" CAA record. I think you could achieve the effect by creating a CAA record containing a random tag that is not otherwise used, and setting the critical bit to 0. But this is pretty hacky. Do you see a better way to implement "(3) but not (2)" in the tree-climbing world? >> If domain operators wish to operate with their own policy, and >> support customers with the same policy (on the domains the domain >> operator operates), while allowing their customers to operate >> with their own policy on the customer domains, the trampoline is >> necessary. > I don't think this case is significantly different than the above. > One policy gets set on the CDN's base domain, while the other > policy gets set on the CNAME target. If those policies happen to > be the same, that's fine. > > > Fair point here as well. The complexity then comes from whether this > reflects current deployment, or whether it reflects a point of > deployment which would have to change to support. I think this is what > you've identified in (2). Is the question here whether CNAME targets are generally subdomains or base domains? In my experience, almost always subdomains. --------------F1ABC4BB6CE4B5614E5101D9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Cool, sounds like we are now on the same page, and can start talking in more subjective terms.

On 03/10/2017 02:51 PM, Ryan Sleevi wrote:

1. Policy set by user-facing domain owner for their own hostnames.
2. Blanket policy set by CDN for hostnames they operate on their customers' behalf.
3. Policy set by CDN for their own hostnames, which share the same base domain as the CNAME targets used in (2).
I think (1) is easily handled by both tree-climbing and non-tree-climbing implementations.

Both (2) and (3) are handled by both tree-climbing and non-tree-climbing implementations with deployment of two CAA records. If the policies happen to be the same, tree climbing allows the CDN to economize on CAA records by deploying just one, on their base domain.

However, I think the policies are not likely to be the same. The feedback we've gotten so far from Patrick is that Cloudflare is unlikely to implement (2) because, like most CDNs and hosting providers, they are effectively a Mixed-management setup.

So, what if a CDN wants to implement (3), but specifically avoid (2)? This is very easy in the non-tree-climbing world: they set a single CAA record on their base domain. In the tree-climbing world, it's very hard. The CDN would need to specify a restrictive CAA record on their base domain, and then another CAA record that specifies "Nevermind, everything is allowed again" on their CNAME target, in order to block tree-climbing to their root domain.

As far as I can see, RFC 6844 doesn't define a "Nevermind, everything is allowed" CAA record. I think you could achieve the effect by creating a CAA record containing a random tag that is not otherwise used, and setting the critical bit to 0. But this is pretty hacky. Do you see a better way to implement "(3) but not (2)" in the tree-climbing world?

If domain operators wish to operate with their own policy, and support customers with the same policy (on the domains the domain operator operates), while allowing their customers to operate with their own policy on the customer domains, the trampoline is necessary.
 I don't think this case is significantly different than the above. One policy gets set on the CDN's base domain, while the other policy gets set on the CNAME target. If those policies happen to be the same, that's fine.

Fair point here as well. The complexity then comes from whether this reflects current deployment, or whether it reflects a point of deployment which would have to change to support. I think this is what you've identified in (2).
Is the question here whether CNAME targets are generally subdomains or base domains? In my experience, almost always subdomains.



--------------F1ABC4BB6CE4B5614E5101D9-- From nobody Fri Mar 10 21:31:54 2017 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 A35B8129470 for ; Fri, 10 Mar 2017 21:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPifwHY5jwqx for ; Fri, 10 Mar 2017 21:31:51 -0800 (PST) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21A151294C2 for ; Fri, 10 Mar 2017 21:31:51 -0800 (PST) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1489210299; h=from:subject:to:date:message-id; bh=RpvuBgtBvKbQdqy2WQd4a20XblvGb8kZiEbhY4bnuBw=; b=NOsEpYGRadBuv39yUXOKxOyst99KU4cozQYyLLXdApKpY6CelnT4Rr4Yb2zwO6KQwMpyIhotz+Q 9ISQJOogDS4lfwai82XD7CPoMxfc44GqLCjW9dP6fR7EwHsAjo+dzD3T0Z9IEKRAjgu9YddDrFv5w 4LthWXgBAnksoXMLxIiGqjg0fPU2iqAgeC1eN9BZCf20IpdOVQFUVsb2PNUb5PzWA2R46UtN9/EOE 4Lx6LSamdzeARtalAdCeq8fQ+HB3bKyzH6d6XrsZUUzE/jOMF39oPsOE54YJ58rh46oI4Lih/5rc7 TT8XWe3K6s50xB1fIopEwugAkxe/AN/viAKg== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 10 Mar 2017 21:31:39 -0800 Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 10 Mar 2017 21:29:29 -0800 From: Jim Schaad To: 'Russ Housley' References: <531F42E9-E7B2-4A40-B373-F616A4076FC2@vigilsec.com> <0a1701d29971$25d620f0$718262d0$@augustcellars.com> <415CC5D7-5766-4A6D-9649-E8D9B7BF92D7@vigilsec.com> In-Reply-To: <415CC5D7-5766-4A6D-9649-E8D9B7BF92D7@vigilsec.com> Date: Fri, 10 Mar 2017 21:31:41 -0800 Message-ID: <0ace01d29a28$c511e7a0$4f35b6e0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQD+TH9fg70r2/ftM1SZZBQE/vYlQwLsZVxYAriVCVoBwxCOqKL8cgAg X-Originating-IP: [24.21.96.37] Archived-At: Cc: 'SPASM' , 'Sean Turner' Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-rfc5750-bis-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 11 Mar 2017 05:31:52 -0000 > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Friday, March 10, 2017 7:24 AM > To: Jim Schaad > Cc: Sean Turner ; SPASM > Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-rfc5750-bis-02 >=20 >=20 > >> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ > Housley > >> Sent: Thursday, March 9, 2017 9:43 AM > >> To: SPASM > >> Subject: Re: [Spasm] WG Last Call for = draft-ietf-lamps-rfc5750-bis-02 > >> > >> I think that the document is in very good shape, and it is ready to > >> go to the IESG. I have a few minor suggestions for improvements. > >> > >> The last paragraph of Section 4.3 says: > >> > >> For EdDSA see [I-D.ietf-curdle-pkix] and [I-D.irtf-cfrg-eddsa]. = The > >> first reference provides the signature algorithm's object = identifier > >> and the second provides the signature algorithm's definition. = Other > >> curves than curve 25519 MAY be used as well. > >> > >> There is only one other curve specified for EdDSA, so I suggest: > >> > >> For EdDSA see [I-D.ietf-curdle-pkix] and [I-D.irtf-cfrg-eddsa]. = The > >> first reference provides the signature algorithm's object = identifier > >> and the second provides the signature algorithm's definition. In > >> addition to curve 25519, curve 448 MAY be used as well. > > > > Yes, today there is only one other curve that is defined. I think = that it is > possible that others will be added I the future and did not want to = close off > that path by being explicit here. >=20 > The reference would need to change to allow other curves, right? I don't follow this line of reasoning. I would not expect that the = S/MIME document would need to have a specific reference for a new EdDSA = algorithm w/ a new curve assuming such a document exists. This would be = the same as if you defined a new hash algorithm to with RSAPSS or = defined a new curve with ECDSA. The details do not need to be placed in = this document nor, since they are not listed algorithms, do we need to = have a reference to this potential document. If the algorithm becomes = standard, then a 4.1 version might need this. Jim >=20 > Yes, that would be fine with me. >=20 > Russ From nobody Sat Mar 11 07:47:35 2017 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 4636912941E for ; Sat, 11 Mar 2017 07:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 8miMWEovXFjV for ; Sat, 11 Mar 2017 07:47:34 -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 E404812941D for ; Sat, 11 Mar 2017 07:47:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 07BD83004B7 for ; Sat, 11 Mar 2017 10:47:33 -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 0L_9d4rECH1T for ; Sat, 11 Mar 2017 10:47:31 -0500 (EST) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 62BA6300448; Sat, 11 Mar 2017 10:47:31 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Russ Housley In-Reply-To: <0ace01d29a28$c511e7a0$4f35b6e0$@augustcellars.com> Date: Sat, 11 Mar 2017 10:47:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7E862628-6513-45DE-823A-24FF5BD2AF7F@vigilsec.com> References: <531F42E9-E7B2-4A40-B373-F616A4076FC2@vigilsec.com> <0a1701d29971$25d620f0$718262d0$@augustcellars.com> <415CC5D7-5766-4A6D-9649-E8D9B7BF92D7@vigilsec.com> <0ace01d29a28$c511e7a0$4f35b6e0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3259) Archived-At: Cc: SPASM , Sean Turner Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-rfc5750-bis-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 11 Mar 2017 15:47:35 -0000 > On Mar 11, 2017, at 12:31 AM, Jim Schaad = wrote: >=20 >=20 >=20 >> -----Original Message----- >> From: Russ Housley [mailto:housley@vigilsec.com] >> Sent: Friday, March 10, 2017 7:24 AM >> To: Jim Schaad >> Cc: Sean Turner ; SPASM >> Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-rfc5750-bis-02 >>=20 >>=20 >>>> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Russ >> Housley >>>> Sent: Thursday, March 9, 2017 9:43 AM >>>> To: SPASM >>>> Subject: Re: [Spasm] WG Last Call for = draft-ietf-lamps-rfc5750-bis-02 >>>>=20 >>>> I think that the document is in very good shape, and it is ready to >>>> go to the IESG. I have a few minor suggestions for improvements. >>>>=20 >=20 >=20 >>>> The last paragraph of Section 4.3 says: >>>>=20 >>>> For EdDSA see [I-D.ietf-curdle-pkix] and [I-D.irtf-cfrg-eddsa]. = The >>>> first reference provides the signature algorithm's object = identifier >>>> and the second provides the signature algorithm's definition. = Other >>>> curves than curve 25519 MAY be used as well. >>>>=20 >>>> There is only one other curve specified for EdDSA, so I suggest: >>>>=20 >>>> For EdDSA see [I-D.ietf-curdle-pkix] and [I-D.irtf-cfrg-eddsa]. = The >>>> first reference provides the signature algorithm's object = identifier >>>> and the second provides the signature algorithm's definition. In >>>> addition to curve 25519, curve 448 MAY be used as well. >>>=20 >>> Yes, today there is only one other curve that is defined. I think = that it is >> possible that others will be added I the future and did not want to = close off >> that path by being explicit here. >>=20 >> The reference would need to change to allow other curves, right? >=20 > I don't follow this line of reasoning. I would not expect that the = S/MIME document would need to have a specific reference for a new EdDSA = algorithm w/ a new curve assuming such a document exists. This would be = the same as if you defined a new hash algorithm to with RSAPSS or = defined a new curve with ECDSA. The details do not need to be placed in = this document nor, since they are not listed algorithms, do we need to = have a reference to this potential document. If the algorithm becomes = standard, then a 4.1 version might need this. The EdDSA with yet-to-be-named-hash-function would ned to be assigned an = object identifier, and that would happen in some specification. = However, I agree that the S/MIME Message specification does not need to = be updated for MAY implement it. I withdraw this comment. Russ From nobody Sat Mar 11 12:19:07 2017 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 8B3011293FB for ; Sat, 11 Mar 2017 12:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 WM5Aud0rZkuH for ; Sat, 11 Mar 2017 12:19:05 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6278D1295A3 for ; Sat, 11 Mar 2017 12:19:05 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 59A517A3309; Sat, 11 Mar 2017 20:19:04 +0000 (UTC) Date: Sat, 11 Mar 2017 20:19:04 +0000 From: Viktor Dukhovni To: SPASM Message-ID: <20170311201904.GQ7733@mournblade.imrryr.org> References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: spasm@ietf.org 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, 11 Mar 2017 20:19:06 -0000 On Fri, Mar 10, 2017 at 12:02:57PM -0500, Ryan Sleevi wrote: > We end up with the following configurations: > > - Self-Managed, Recursive, Trampoline'd > www.example.com CNAME staffie.example.net > www.example.com CAA 0 issue "good-ca.example.org" This should not be possible, one surely can't have both CNAME and CAA records for the same owner domain. > OR (and more problematically) > > www.example.com CNAME staffie.example.net > www.example.com CAA 0 issue "evil-ca.example.org" Ditto. -- Viktor. From nobody Sat Mar 11 16:04:04 2017 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 F144912969F for ; Sat, 11 Mar 2017 16:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3KNodA-edmq for ; Sat, 11 Mar 2017 16:04:02 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE901296A3 for ; Sat, 11 Mar 2017 16:04:01 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B2A8916C505 for ; Sun, 12 Mar 2017 00:04:00 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 9CA2C16C501 for ; Sun, 12 Mar 2017 00:04:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489277040; bh=FS+6vHm4fYNWXk+/vKJbtFCxsaaVacef0RvNY6RUzu4=; l=174; h=From:To:Date:References:In-Reply-To:From; b=vVxu1pq+wf9f/zjwvhj6ETC6IRVLxoxY9Yk3KU27D/Pn1W1L5x5F9HmFZtdWo9KPh IYg7eBfKQs5gPQjCwA9XQByj+9Qk0A8I5iTnVwE47JVlygXKFfF4HhUregUxQvqwK8 +ntXlBhXCe9kBz5tSKNVXf0G5ynUZw6ss1NPhN6o= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 66E7D1E08E for ; Sun, 12 Mar 2017 00:04:00 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 11 Mar 2017 16:03:59 -0800 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Sat, 11 Mar 2017 19:03:59 -0500 From: "Salz, Rich" To: "spasm@ietf.org" Thread-Topic: [Spasm] CAA erratum 4515 Thread-Index: AQHSmRCCM7EZ0a0WGUaDqFWlZ2kYcqGNSw4AgAAJEYCAAU3mgIABySAA///q7WA= Date: Sun, 12 Mar 2017 00:03:58 +0000 Message-ID: References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> <20170311201904.GQ7733@mournblade.imrryr.org> In-Reply-To: <20170311201904.GQ7733@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.175] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 00:04:03 -0000 > This should not be possible, one surely can't have both CNAME and CAA > records for the same owner domain. Right, if there's a CNAME record it can be the only record. From nobody Sun Mar 12 11:06:15 2017 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 CCFB2129458 for ; Sun, 12 Mar 2017 11:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.004 X-Spam-Level: X-Spam-Status: No, score=-7.004 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=eff.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 V6Iy8K9SeWyU for ; Sun, 12 Mar 2017 11:06:11 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B242F129416 for ; Sun, 12 Mar 2017 11:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=GG4VTpgwA0+EoKZ3JJ1n+MQma2gSrm94giUt7d956qs=; b=sgAv6NRvtYBqRSILSsBE4cF0sXZq7TFHUX5Kydh7ceqoZgZI1ZzvG4jrcPcPZ52p/WkRUOHCacQbdckTSB12TGoBq8PyqzFWAtCN+L3Ct7ZXzwaygyLcDtDLqQwkfi4F1zWHjRX2q5AN3iGta0gzXPqoK1JhkpO9hPJfO+rE1DQ=; Received: ; Sun, 12 Mar 2017 11:06:08 -0700 To: "Salz, Rich" , "spasm@ietf.org" , Patrick Donahue , Gervase Markham , Phillip Hallam-Baker , Peter Bowen , Rob Stradling , Ryan Sleevi References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> <20170311201904.GQ7733@mournblade.imrryr.org> From: Jacob Hoffman-Andrews Message-ID: <389a248f-37e4-9ff7-b330-b840e7c47931@eff.org> Date: Sun, 12 Mar 2017 11:06:05 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Received-SPF: skipped for local relay Archived-At: Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 18:06:14 -0000 (Adding back the CC'ed participants who may not be subscribed to SPASM). On 03/11/2017 12:19 PM, Viktor Dukhovni wrote: > On Fri, Mar 10, 2017 at 12:02:57PM -0500, Ryan Sleevi wrote: > >> We end up with the following configurations: >> >> - Self-Managed, Recursive, Trampoline'd >> www.example.com CNAME staffie.example.net >> www.example.com CAA 0 issue "good-ca.example.org" > This should not be possible, one surely can't have both CNAME and > CAA records for the same owner domain. > >> OR (and more problematically) >> >> www.example.com CNAME staffie.example.net >> www.example.com CAA 0 issue "evil-ca.example.org" > Ditto. Ah, good point. https://tools.ietf.org/html/rfc1912#section-2.4 > A CNAME record is not allowed to coexist with any other data. Looking at the types of policy I described earlier: > 1. Policy set by user-facing domain owner for their own hostnames. > 2. Blanket policy set by CDN for hostnames they operate on their customers' behalf. > 3. Policy set by CDN for their own hostnames, which share the same base domain as the CNAME targets used in (2). In the tree-climbing world, given the above restriction on CNAMEs coexisting, it would be impossible for a CDN to express "(3) without (2)". Worse, if some CDN did express (3), it would be impossible for their customers to opt out by setting CAA records on their own domains. This would effectively bar CDNs from expressing (3) in the tree-climbing world. I think this is sufficient to say that tree climbing is undesirable. What do other folks think? From nobody Sun Mar 12 11:44:00 2017 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 A9C9212949E for ; Sun, 12 Mar 2017 11:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 lIkVPutAcha7 for ; Sun, 12 Mar 2017 11:43:57 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 56631129481 for ; Sun, 12 Mar 2017 11:43:57 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id p77so48294122ywg.1 for ; Sun, 12 Mar 2017 11:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=o6hwVEZx5z3iYCkvAIUsY73syUbOYO9Ko+ihvtQlGj4=; b=Hz9CUbcxqtfJ394BLdiL4KfI5u+QwE1E3vU3ifr71TeulRwDgsAXxgNilzXRbdriqt 0h9G4KcT3UbFK4uezI7s5uFs1zzUCU+FX6hmoMDXrpUBobWbsLlYouaRGAs7wlN1pnJZ qqy7shXn0PngW95m+XI5MNFqN+b7pj45iZ7sIiM1/+P1cTrp1f0aQ7RgR9NKpRnMoIpv sHCBnHC9zmx/oGw5+5Xr7gr9paW3vo2LFyfu05Dy8f36dP13QWFUKgIb75t7WvzwwBPN vypqmFCAwPmn/TI3DiN7qi3UNaqHLl9kYDw9duhcbjTECDRaMptJUFn1wgl3TdkyDIjM 6gqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=o6hwVEZx5z3iYCkvAIUsY73syUbOYO9Ko+ihvtQlGj4=; b=Gg4YbEvCKesz9JsLyJF3y/RX0syyYp/4Ax9ZgPyKg/75AUkcl1I4okCzAxbtWS2m3K uH4hqB1USnVlsdsgjRH4lWnKfLdKMoATlCgYvl3cbxD281q9Vu3e8Bt3ete7sG/BVQOK WBYTCoI5fN4Jgcvu9svNbiCBc7ARMCiPlTPndBFTlNCBUdB7vJ2nCsUBX46Qa5os3/eF toPvt1MFe2cUqzD5kGS/Ia8gt1QCLiMLNkfoGVsz6D/3NHsnWRtidvYgNMkejlYFF3BK Bi2pDUkuDGd06CmyvQK4auFzUD67cZIizB8yi6cSGe31A31DWcOoK1OjKvOJGBdZqYpW IDyA== X-Gm-Message-State: AMke39kGAJX+Mc11HGhH1d+jaaoW/6r8+Sas1YVmFr6pfYtPJu1x8iJIER8LQdczNEAW4Wgwrs+TYzKfipfhzw== X-Received: by 10.129.115.84 with SMTP id o81mr15871755ywc.186.1489344236518; Sun, 12 Mar 2017 11:43:56 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.83.19.20 with HTTP; Sun, 12 Mar 2017 11:43:55 -0700 (PDT) In-Reply-To: References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> <8f216ae1-d236-79c1-5baf-44cf7bfa619b@eff.org> <7f9c38ad-aa39-c403-0320-7300619b9986@eff.org> From: Phillip Hallam-Baker Date: Sun, 12 Mar 2017 14:43:55 -0400 X-Google-Sender-Auth: I2KYfWSAnF9YSRgO1OlcaqUYu44 Message-ID: To: Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary=001a1147e3022a8530054a8cfa0d Archived-At: Cc: Patrick Donahue , Gervase Markham , Phillip Hallam-Baker , Ryan Sleevi , Peter Bowen , SPASM , Rob Stradling Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 18:43:58 -0000 --001a1147e3022a8530054a8cfa0d Content-Type: text/plain; charset=UTF-8 If people want an escape hole 'anyone can issue' in CAA, I would rather do it by defining generic domains: ev.cabforum.org dv.cabforum.org That avoids the need to define new tags or update processing code. They are simply domains that any WebTrust or ETSI audited CA issuing to those requirements can issue. --001a1147e3022a8530054a8cfa0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If = people want an escape hole 'anyone can issue' in CAA, I would rathe= r do it by defining generic domains:

ev.cabforum.org
dv.cabforum.org

That avoids the need to define new tags or update processing code. T= hey are simply domains that any WebTrust or ETSI audited CA issuing to thos= e requirements can issue.
--001a1147e3022a8530054a8cfa0d-- From nobody Sun Mar 12 12:30:25 2017 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 E8F721294DD for ; Sun, 12 Mar 2017 12:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 GgZQL9CgI5a5 for ; Sun, 12 Mar 2017 12:30:19 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 747EE129525 for ; Sun, 12 Mar 2017 12:30:10 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 2E9E8A004F15 for ; Sun, 12 Mar 2017 12:30:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=XEJntxT3mPbWRx4YZ/cAzZw1MQA=; b= XiPRuVEauEn+rkN6FFf1MPNJcdlI3+/ShiCltoKfekT2vLQap7j0GDAKihxw9Pv+ G+F2qxxeImFOuhXkVsOhINunwAMxqpl1+GRq4/LX9RIUi9enkwzVwz5k3ZGVEDGo aKH4n0cvWCIoFGKDwzJDVv7XfK25yaO4UAe0kZ2/So0= Received: from mail-lf0-f54.google.com (mail-lf0-f54.google.com [209.85.215.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id EDF33A004F14 for ; Sun, 12 Mar 2017 12:30:09 -0700 (PDT) Received: by mail-lf0-f54.google.com with SMTP id z15so34499007lfd.1 for ; Sun, 12 Mar 2017 12:30:09 -0700 (PDT) X-Gm-Message-State: AMke39nsJphVxm8A4WW37SmKDD7z7fJy81yb8S2Aqv124aWS+aNfi7h7omgqrJ+d749NrnT/k/i10N/gcyFzOg== X-Received: by 10.46.83.29 with SMTP id h29mr8923797ljb.84.1489347008081; Sun, 12 Mar 2017 12:30:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.193.197 with HTTP; Sun, 12 Mar 2017 12:30:07 -0700 (PDT) In-Reply-To: References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> <8f216ae1-d236-79c1-5baf-44cf7bfa619b@eff.org> <7f9c38ad-aa39-c403-0320-7300619b9986@eff.org> From: Ryan Sleevi Date: Sun, 12 Mar 2017 12:30:07 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=94eb2c1ce7fa5d3b49054a8d9fbc Archived-At: Cc: Patrick Donahue , Gervase Markham , Jacob Hoffman-Andrews , Ryan Sleevi , Peter Bowen , SPASM , Rob Stradling , Phillip Hallam-Baker Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 19:30:21 -0000 --94eb2c1ce7fa5d3b49054a8d9fbc Content-Type: text/plain; charset=UTF-8 On Sun, Mar 12, 2017 at 11:43 AM, Phillip Hallam-Baker < phill@hallambaker.com> wrote: > If people want an escape hole 'anyone can issue' in CAA, I would rather do > it by defining generic domains: > > ev.cabforum.org > dv.cabforum.org > > That avoids the need to define new tags or update processing code. They > are simply domains that any WebTrust or ETSI audited CA issuing to those > requirements can issue. > I think there are several flaws with this argument: - It's only applicable to set the of CAs bound by such a profile; that is, a CA who is not WebTrust audited could just as easily issue such a certificate without 'violating' either the letter or spirit of CAA, so it's pointless to try to describe policy in that way - The idea of introducing audits into the technical description is flawed, in as much as audits are post-facto evaluations of operations. So it wouldn't be a violation - of CAA or program requirements - for a CA with an EV audit to issue such a certificate as DV if their CP/CPS dictated - it'd only be post-facto misissuance. - It still effectively limits the ability to express, for a given CA, the desired policies of issuance. One organizations 'EV' can be another organizations QCP+. Let's keep to a simple principle - of simply saying 'any' - and leave distinctions about certificate policies relevant to the set of CAs being interacted with (e.g. as tags). That's the only way that really makes a defensible - and auditable - security boundary, without relying on external evaluations (whether or not a given CA is 'trusted' for EV, whether or not a given CA is audited for EV, etc) --94eb2c1ce7fa5d3b49054a8d9fbc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 12, 2017 at 11:43 AM, Phillip Hallam-Baker <phill@hall= ambaker.com> wrote:
If people want an escape hole '= ;anyone can issue' in CAA, I would rather do it by defining generic dom= ains:


That avoids the need to define ne= w tags or update processing code. They are simply domains that any WebTrust= or ETSI audited CA issuing to those requirements can issue.

I think there are s= everal flaws with this argument:

=
- It's only applicable to set the of CAs bou= nd by such a profile; that is, a CA who is not WebTrust audited could just = as easily issue such a certificate without 'violating' either the l= etter or spirit of CAA, so it's pointless to try to describe policy in = that way
- The idea of introducing audits i= nto the technical description is flawed, in as much as audits are post-fact= o evaluations of operations. So it wouldn't be a violation - of CAA or = program requirements - for a CA with an EV audit to issue such a certificat= e as DV if their CP/CPS dictated - it'd only be post-facto misissuance.=
- It still effectively limits the ability = to express, for a given CA, the desired policies of issuance. One organizat= ions 'EV' can be another organizations QCP+.

Let's keep to a simple p= rinciple - of simply saying 'any' - and leave distinctions about ce= rtificate policies relevant to the set of CAs being interacted with (e.g. a= s tags). That's the only way that really makes a defensible - and audit= able - security boundary, without relying on external evaluations (whether = or not a given CA is 'trusted' for EV, whether or not a given CA is= audited for EV, etc)
--94eb2c1ce7fa5d3b49054a8d9fbc-- From nobody Sun Mar 12 12:33:50 2017 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 0A17E12944F for ; Sun, 12 Mar 2017 12:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 vdicP59b-4Cg for ; Sun, 12 Mar 2017 12:33:47 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD40D1293F4 for ; Sun, 12 Mar 2017 12:33:47 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 65F02A00762E for ; Sun, 12 Mar 2017 12:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=saTAHFRsVsyBTQNZy5flSXUJp1g=; b= EJDAgSt65+JMGWNifQJSofmhCwfNh62eGERR8Sh+ivUxoDE0gFaQ0ylDytLLjXqf Z+WF/f9qblRpsOB16iVGTcso7iuGNcpie3sl0h8+Mm6G5BpbncvmF+yZQIf6dW6/ A2cg6CtkZw4HaWrLsuW/af+W+x5QbjWw7cFaUmhLnUI= Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com [209.85.215.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 34B4FA00762C for ; Sun, 12 Mar 2017 12:33:47 -0700 (PDT) Received: by mail-lf0-f41.google.com with SMTP id a6so56601952lfa.0 for ; Sun, 12 Mar 2017 12:33:47 -0700 (PDT) X-Gm-Message-State: AMke39nn4IRuujsbGYha6bdnto3xoU6Ejb6C0swYnT9+hGwRYXCxhrsKIrKSrjlOOWc6mCbs491aF09EWwEHBQ== X-Received: by 10.46.9.75 with SMTP id 72mr8843406ljj.10.1489347225474; Sun, 12 Mar 2017 12:33:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.193.197 with HTTP; Sun, 12 Mar 2017 12:33:44 -0700 (PDT) In-Reply-To: <389a248f-37e4-9ff7-b330-b840e7c47931@eff.org> References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> <20170311201904.GQ7733@mournblade.imrryr.org> <389a248f-37e4-9ff7-b330-b840e7c47931@eff.org> From: Ryan Sleevi Date: Sun, 12 Mar 2017 12:33:44 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary=001a114b10365269e6054a8dacd8 Archived-At: Cc: Patrick Donahue , Gervase Markham , Rob Stradling , Ryan Sleevi , "Salz, Rich" , Peter Bowen , "spasm@ietf.org" , Phillip Hallam-Baker Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 19:33:49 -0000 --001a114b10365269e6054a8dacd8 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 12, 2017 at 11:06 AM, Jacob Hoffman-Andrews wrote: > > Looking at the types of policy I described earlier: > > > 1. Policy set by user-facing domain owner for their own hostnames. > > 2. Blanket policy set by CDN for hostnames they operate on their > customers' behalf. > > 3. Policy set by CDN for their own hostnames, which share the same > base domain as the CNAME targets used in (2). > > In the tree-climbing world, given the above restriction on CNAMEs > coexisting, it would be impossible for a CDN to express "(3) without > (2)". Worse, if some CDN did express (3), it would be impossible for > their customers to opt out by setting CAA records on their own domains. > This would effectively bar CDNs from expressing (3) in the tree-climbing > world. > I think this is sufficient to say that tree climbing is undesirable. > What do other folks think? I think you're correct in that, in the absence of some form of trampoline - and an 'any' policy - it can't be expressed. However, am I mistaken in thinking that with those two - it could be? I just want to make sure we know where the differences lie. Removing tree climbing is arguably a substantive change to the specification, and would likely require a document update. An 'any' expression and trampoline become operational guidance, but don't require changing the specification. Not to suggest one is more or less desirable than the other, but making sure we've got a fully articulated set of guidance for "How you can configure these cases with tree-climbing" and "How you can configure cases without tree-climbing", and then evaluate their relative costs (to site operators, to CAs, and 'process' wise). Does that sound reasonable? --001a114b10365269e6054a8dacd8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 12, 2017 at 11:06 AM, Jacob Hoffman-Andrews <jsha@eff.org&g= t; wrote:
Looking at the types of policy I described earlier:

> 1. Policy set by user-facing domain owner for their own hostnames.
> 2. Blanket policy set by CDN for hostnames they operate on their
customers' behalf.
> 3. Policy set by CDN for their own hostnames, which share the same
base domain as the CNAME targets used in (2).

In the tree-climbing world, given the above restriction on CNAMEs coexisting, it would be impossible for a CDN to express "(3) without (2)". Worse, if some CDN did express (3), it would be impossible for their customers to opt out by setting CAA records on their own domains.
This would effectively bar CDNs from expressing (3) in the tree-climbing world.=C2=A0

I think this is sufficient to say that tree climbing is undesirable.
What do other folks think?

I think you'= re correct in that, in the absence of some form of trampoline - and an '= ;any' policy - it can't be expressed.

Howe= ver, am I mistaken in thinking that with those two - it could be? I just wa= nt to make sure we know where the differences lie. Removing tree climbing i= s arguably a substantive change to the specification, and would likely requ= ire a document update. An 'any' expression and trampoline become op= erational guidance, but don't require changing the specification.
=

Not to suggest one is more or less desirable than the o= ther, but making sure we've got a fully articulated set of guidance for= "How you can configure these cases with tree-climbing" and "= ;How you can configure cases without tree-climbing", and then evaluate= their relative costs (to site operators, to CAs, and 'process' wis= e). Does that sound reasonable?
--001a114b10365269e6054a8dacd8-- From nobody Sun Mar 12 12:48:42 2017 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 E21581294C7 for ; Sun, 12 Mar 2017 12:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.003 X-Spam-Level: X-Spam-Status: No, score=-7.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=eff.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 kZkoxaUXdSJV for ; Sun, 12 Mar 2017 12:48:39 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8F3A1294C0 for ; Sun, 12 Mar 2017 12:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=uoZ6/lI1w+nezl1BE8dqBlbUVEltNwogYtcG+2VofFA=; b=wsJHC6EsMWD6EdJ5k0FdpX+gy2OSWthoIY/UZUKv6h0Y4RG1pyqfoo/kNEFFsHDHHSg25wUkxX+7iPV++ug8UFI9a9BhOIj5AMoPN14Mb1agiws01+Oou312NRbEeZmvPeE8YvSYzuriZYcuEtmDYke+lHoMfUDz40QWHnfWAMc=; Received: ; Sun, 12 Mar 2017 12:48:40 -0700 To: Ryan Sleevi References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> <20170311201904.GQ7733@mournblade.imrryr.org> <389a248f-37e4-9ff7-b330-b840e7c47931@eff.org> From: Jacob Hoffman-Andrews Message-ID: <0d7afa83-a9d7-f977-ca36-533fc13b720e@eff.org> Date: Sun, 12 Mar 2017 12:48:37 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------21232E4F3FF10312B7935172" Received-SPF: skipped for local relay Archived-At: Cc: Patrick Donahue , Gervase Markham , "Salz, Rich" , Peter Bowen , "spasm@ietf.org" , Rob Stradling , Phillip Hallam-Baker Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 19:48:41 -0000 This is a multi-part message in MIME format. --------------21232E4F3FF10312B7935172 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/12/2017 12:33 PM, Ryan Sleevi wrote: > On Sun, Mar 12, 2017 at 11:06 AM, Jacob Hoffman-Andrews > wrote: > > Looking at the types of policy I described earlier: > > > 1. Policy set by user-facing domain owner for their own hostnames= =2E > > 2. Blanket policy set by CDN for hostnames they operate on their > customers' behalf. > > 3. Policy set by CDN for their own hostnames, which share the sam= e > base domain as the CNAME targets used in (2). > > In the tree-climbing world, given the above restriction on CNAMEs > coexisting, it would be impossible for a CDN to express "(3) withou= t > (2)". Worse, if some CDN did express (3), it would be impossible fo= r > their customers to opt out by setting CAA records on their own > domains. > This would effectively bar CDNs from expressing (3) in the > tree-climbing > world.=20 > > > I think this is sufficient to say that tree climbing is undesirable= =2E > What do other folks think? > > > I think you're correct in that, in the absence of some form of > trampoline - and an 'any' policy - it can't be expressed. > > However, am I mistaken in thinking that with those two - it could be? Actually, thinking about it some more, all that's needed is an 'any' policy. Even without a trampoline, the CDN only has to set the 'any' policy on their CNAME target. Separately: since we now realize that customers can't override CDN policy by adding CAA records to their own zone, if a customer wants to set their own CAA policy, the records have to be present on the CNAME target. That is, the CDN would have to cooperate in adding that record. Because different customers would no doubt want to express different policies, the CDN would have to use a trampoline if they wanted to offer per-customer CAA settings. However, this is true in both tree-climbing and non-tree-climbing worlds. Do you agree? --------------21232E4F3FF10312B7935172 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 03/12/2017 12:33 PM, Ryan Sleevi wrote:
On Sun, Mar 12, 2017 at 11:06 AM, Jacob Hoffman-Andrews <jsha@eff.org> wrote:
Looking at the types of policy I described earlier:

> 1. Policy set by user-facing domain owner for their own hostnames.
> 2. Blanket policy set by CDN for hostnames they operate on their
customers' behalf.
> 3. Policy set by CDN for their own hostnames, which share the same
base domain as the CNAME targets used in (2).

In the tree-climbing world, given the above restriction on CNAMEs
coexisting, it would be impossible for a CDN to express "(3) without
(2)". Worse, if some CDN did express (3), it would be impossible for
their customers to opt out by setting CAA records on their own domains.
This would effectively bar CDNs from expressing (3) in the tree-climbing
world. 

I think this is sufficient to say that tree climbing is undesirable.
What do other folks think?

I think you're correct in that, in the absence of some form of trampoline - and an 'any' policy - it can't be expressed.

However, am I mistaken in thinking that with those two - it could be?
Actually, thinking about it some more, all that's needed is an 'any' policy. Even without a trampoline, the CDN only has to set the 'any' policy on their CNAME target.

Separately: since we now realize that customers can't override CDN policy by adding CAA records to their own zone, if a customer wants to set their own CAA policy, the records have to be present on the CNAME target. That is, the CDN would have to cooperate in adding that record. Because different customers would no doubt want to express different policies, the CDN would have to use a trampoline if they wanted to offer per-customer CAA settings. However, this is true in both tree-climbing and non-tree-climbing worlds. Do you agree?

--------------21232E4F3FF10312B7935172-- From nobody Sun Mar 12 14:23:11 2017 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 592F1126DFB; Sun, 12 Mar 2017 14:23:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148935378931.24645.12365174028574120124@ietfa.amsl.com> Date: Sun, 12 Mar 2017 14:23:09 -0700 Archived-At: Cc: spasm@ietf.org Subject: [Spasm] I-D Action: draft-ietf-lamps-eai-addresses-08.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 21:23:09 -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 of the IETF. Title : Internationalized Email Addresses in X.509 certificates Authors : Alexey Melnikov Weihaw Chuang Filename : draft-ietf-lamps-eai-addresses-08.txt Pages : 14 Date : 2017-03-12 Abstract: This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternate Name extension that allows a certificate subject to be associated with an Internationalized Email Address. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-eai-addresses/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-addresses-08 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 Sun Mar 12 14:40:56 2017 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 53E1812943A for ; Sun, 12 Mar 2017 14:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 KyioHDjgI4nR for ; Sun, 12 Mar 2017 14:40:48 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 05513129415 for ; Sun, 12 Mar 2017 14:40:47 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id m124so70771997oig.1 for ; Sun, 12 Mar 2017 14:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=rMU2MCNcroOGJ8WCZDC389TRL5m3HRBoV3Sac6n/QcA=; b=hsHvUj+BTRBkLWIP3zyWeszOs1SZ0n6oD1UoLN8NlQgLAsdoiXJCOx6yE/CDVPtcG+ HCIRMrqaSsKc5ZnpzvhHhtjCvfDGna1DieNAPOn8zr68EfNX0LojyvufjvpE0lB6bZb4 /zDz+eoP6aYEtfLBFza90l2Sv7Nfv66XXI4nseVZeEHcvB3fDnyybzaeOU8XFfJizvRP o0pYIMSCdolwV2IkEtlx5afg0qJBu1Pc/ON50NiB9EdHqSwYI90Xdr4gOlCoEvIR8WJA ICmjeuvJ6rzHHze/zuGPo7zrIm60XY+ibpGntVk7QhDhdF+ZEt696rQbdYUL3W0atrA6 dkeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=rMU2MCNcroOGJ8WCZDC389TRL5m3HRBoV3Sac6n/QcA=; b=CqlpZlJZ6lS1SR+wAs6iqwiJNtYRkQTGrqGZ1kobdUuyLngHXOIG0KSZpLLzfP0sj1 teTv+AnpQ9dqFhj33HISKw2Z4KqzwtdEXCvYnefTnspPU7LgBkC61d+seBWey+JxQKQv SE+2//EdFF3AEq7yh+IiAIjV2Tmi7qTrxEr+lOmP8t3aJKDrTIf3knDBJ/PNRv7jXvKZ 1NcONo4QL6v3rx8eZlDf6lGexKxdjkf1PYnYYHlBCgEFVK97rPTAyowoIqCTpOv8GdVB fzKwflZVv0x0mo2BVBb/pE2IgKEgsAe8xY2XN//tsEsnlJAUt0o2n+BekMNl+rC7p/3c xeHQ== X-Gm-Message-State: AMke39ngyzAjdrgoeJJ5UyNRR/Y0V4+6x/8+R4v+5ZxuiuIZ9+ln6pdsHi1ZpQFMc4pqhwU4VohGXhE5RHbvG9fP X-Received: by 10.202.226.146 with SMTP id z140mr14326118oig.166.1489354847134; Sun, 12 Mar 2017 14:40:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.41.226 with HTTP; Sun, 12 Mar 2017 14:40:45 -0700 (PDT) In-Reply-To: References: <841bb724-7403-4682-3d50-f878f63b0346@cs.tcd.ie> <6d114340-c9a7-e311-e6f9-0614600cafd2@cs.tcd.ie> <00c401d298b8$616fffa0$4001a8c0@gateway.2wire.net> From: Wei Chuang Date: Sun, 12 Mar 2017 14:40:45 -0700 Message-ID: To: IETF general list , SPASM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11408a3aa04c46054a8f722c" Archived-At: Subject: Re: [Spasm] Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 21:40:51 -0000 --001a11408a3aa04c46054a8f722c Content-Type: multipart/alternative; boundary=001a11408a3a9bf658054a8f7273 --001a11408a3a9bf658054a8f7273 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The latest draft 08 is up: https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-08 The diff is: https://tools.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-addresses-08.txt This draft attempts to capture Viktor's name constraint verifier logic, and illustrate the examples in the diagrams. -Wei On Thu, Mar 9, 2017 at 10:22 AM, Wei Chuang wrote: > There seems to be a consensus here and internally to the changes that > Viktor proposes. We can put that in the next draft update. > > -Wei > > On Thu, Mar 9, 2017 at 1:34 AM, tom p. wrote: > >> ----- Original Message ----- >> From: "Viktor Dukhovni" >> To: ; "IETF general list" >> Sent: Thursday, March 09, 2017 3:19 AM >> > On Mar 8, 2017, at 8:17 PM, Wei Chuang wrote: >> > >> > Okay. I think the direction then is to have SmtpUTF8Name respect >> rfc822Name name constraints and vice versa. >> >> Well, no, the simplest proposal on the table is for SmtpUTF8Name to >> be *prohibited* when rfc822Name constraints are present and SmtpUTF8Name >> constraints are not. When both present, they can operate independently. >> >> >> >> Getting security right can be tricky as the legion of failed attempts >> that make it to RFC testify but what you are proposing here seems so >> simple, so obviously the right thing to do that I am puzzled, bewildered >> even, that anyone can disagree with you. >> >> Tom Petch >> >> The verifier logic is then: >> >> 1. If neither rfc822Name constraints nor SmtpUTF8Name constraints >> are present in any CA certificate in the chain, any mixture >> of >> rfc822Name and SmtpUTF8Name SAN elements is valid. >> >> 2. If some certificate in the chain contains *only* rfc822Name >> constraints, then these apply to rfc822Name SAN elements, but >> all SmtpUTF8Names are prohibited. >> >> 3. When both types of constraints are present in all CA certificates >> that have either type, then constraints for each SAN type are >> exclusively based on just the corresponding constraint type. >> >> 4. If some certificate in the chain contains only SmtpUTF8Name >> constraints then those are unavoidably at risk of bypass via >> rfc822Name SAN elements when processed by legacy verifiers. >> Therefore, this should be avoided, and the CA needs to >> publish rfc822Name constraints that prevent bypass. Such >> constraints *need not* be equivalent (not always possible) >> to the desired SmtpUTF8Name constraints. Rather, it suffices >> to not permit rfc822Name elements that would be prohibited >> if they were simply cut/pasted (with no A-label to U-label >> conversions) as SmtpUTF8Name elements. It is not necessary >> for these to permit everything that SmtpUTF8Name permits. >> >> Thus for example, if SmtpUtf8Name only permits addresses in the non >> NR-LDH >> domain "духовный.org " (or a specific set >> of addresses in such a domain), >> then the corresponding rfc822Name constraint could just permit "." (or >> the >> reserved "invalid" TLD if that's preferable) which is not a usable email >> domain. This ensures that only the permitted SmtpUTF8Name SANs are used >> and no rfc822Name SANs are used. >> >> If, instead the Smtp8Name constraints are excluded non-ASCII address >> forms, >> then since these have no literal rfc822Name equivalents, the rfc822Name >> constraints can be omitted with the same effect. >> >> Only when the intention is to permit NR-LDH domains with either ASCII or >> UTF-8 localparts (or an all-ASCII full address) do the rfc822Name and >> SmtpUTF8Name constraints need to be fully equivalent. This is of course >> trivial to do. Just cut/paste the same string into both types of >> constraint. >> >> -- >> Viktor. >> >> > --001a11408a3a9bf658054a8f7273 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
The latest draft 08 is up:

The diff is:

This draft attempts to capture Viktor's name constraint verifier logic, and illustrate the examples in the diagrams.

-Wei
 

On Thu, Mar 9, 2017 at 10:22 AM, Wei Chuang <weihaw@google.com> wrote:
There seems to be a consensus here and internally to the changes that Viktor proposes.  We can put that in the next draft update.

-Wei

On Thu, Mar 9, 2017 at 1:34 AM, tom p. <daedulus@btconnect.com> wrote:
----- Original Message -----
From: "Viktor Dukhovni" <ietf-dane@dukhovni.org>
To: <spasm@ietf.org>; "IETF general list" <ietf@ietf.org>
Sent: Thursday, March 09, 2017 3:19 AM
> On Mar 8, 2017, at 8:17 PM, Wei Chuang <weihaw@google.com> wrote:
>
> Okay.  I think the direction then is to have SmtpUTF8Name respect
rfc822Name name constraints and vice versa.

Well, no, the simplest proposal on the table is for SmtpUTF8Name to
be *prohibited* when rfc822Name constraints are present and SmtpUTF8Name
constraints are not.  When both present, they can operate independently.

<tp>

Getting security right can be tricky as the legion of failed attempts
that make it to RFC testify but what you are proposing here seems so
simple, so obviously the right thing to do that I am puzzled, bewildered
even, that anyone can disagree with you.

Tom Petch

The verifier logic is then:

1. If neither rfc822Name constraints nor SmtpUTF8Name constraints
           are present in any CA certificate in the chain, any mixture
of
           rfc822Name and SmtpUTF8Name SAN elements is valid.

2. If some certificate in the chain contains *only* rfc822Name
   constraints, then these apply to rfc822Name SAN elements, but
   all SmtpUTF8Names are prohibited.

3. When both types of constraints are present in all CA certificates
           that have either type, then constraints for each SAN type are
   exclusively based on just the corresponding constraint type.

4. If some certificate in the chain contains only SmtpUTF8Name
     constraints then those are unavoidably at risk of bypass via
           rfc822Name SAN elements when processed by legacy verifiers.
   Therefore, this should be avoided, and the CA needs to
     publish rfc822Name constraints that prevent bypass.  Such
   constraints *need not* be equivalent (not always possible)
   to the desired SmtpUTF8Name constraints.  Rather, it suffices
   to not permit rfc822Name elements that would be prohibited
   if they were simply cut/pasted (with no A-label to U-label
           conversions) as SmtpUTF8Name elements.  It is not necessary
   for these to permit everything that SmtpUTF8Name permits.

Thus for example, if SmtpUtf8Name only permits addresses in the non
NR-LDH
domain "духовный.org" (or a specific set of addresses in such a domain),
then the corresponding rfc822Name constraint could just permit "." (or
the
reserved "invalid" TLD if that's preferable) which is not a usable email
domain.  This ensures that only the permitted SmtpUTF8Name SANs are used
and no rfc822Name SANs are used.

If, instead the Smtp8Name constraints are excluded non-ASCII address
forms,
then since these have no literal rfc822Name equivalents, the rfc822Name
constraints can be omitted with the same effect.

Only when the intention is to permit NR-LDH domains with either ASCII or
UTF-8 localparts (or an all-ASCII full address) do the rfc822Name and
SmtpUTF8Name constraints need to be fully equivalent.  This is of course
trivial to do.  Just cut/paste the same string into both types of
constraint.

--
Viktor.



--001a11408a3a9bf658054a8f7273-- --001a11408a3aa04c46054a8f722c Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMZN1N4N3KNCF5ZBTQMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTAyNjE4NDI0NVoXDTE3MDQy NDE4NDI0NVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDiNpZ5E2IqcxktrcD1X5jWksphe1Ur882fsZM99Y4hiVugSVOb zIZIxoh3ckmGpUFyK1un6AU9Rxq9GSSkRskGAaSGrGcy7ncPi7Z1NlOJN25oXFmzituZsZeYIs0S QqT9hlDpLGc95r1CpsuTlaIB8m9Uvi+H6sGecVb2TOuGbRViQIWWf5GWk2AlJYhBFyJv7regqVa8 v3fx6SLkn/hIzBQf7xpVJzG6kAa09ZE0LoPdp5YV+Hv38EqDOWjm+g6Qbh1NADhdGpbmQDp9kdlm 6WZjCMwryQukdCypLKI2BPa08F18LZktaQNlJ2s7VxDJj2ozxomeBpSK6rxSxLAjAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFIMwgx+nNfYP3NyOZfiHYydFyNdQMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAO0J2vGX8ye90RegS3 HS+OE2hGEdDYJlR+S9ZSpla5AC9eejUKUc9JZR3y0ocGeQ3FQyXjM5/azBblqz/ajAbj2Fxuge45 SdRXrItDhAGWtQNl3utu2Uhf4y3re4ZRjApnhEBBX1l0E2BJuHf8MmqMhVU70Ko6Lk3lyPxnBeWo Q3tG2He3CNCkq/SDImq9vf8CNoxKxEkCP+kI+/NaCh5peLygU1h7Dc0ryWAcrxRWn8GUeEOg28MI vpwttw54cNR4YJYJVuiXCNc6PqkT/JxCiMvHS1woXJuET6QZSPtpNtvhNu90sV68Q7b2m6Vp8QTn xbzoEIHhiQWIcfphXjbeMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMZN1N4N3K NCF5ZBTQMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCClXM0EpYvJoJThWe3EHGiL ANHzuq+ewSQNKQwn4rBf0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAzMTIyMTQwNDdaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEANNJSTLujn3Rbz0Q0kY/yltLuVX334qbp2vB6Qu+A WJNXPwdADStnxrz0MYDCG8XPYBjltRZWkY62x1dDyzx5TAFL7GtTdblpXt+iHaQy0kku7JFhU9fh rlS0aGVyrlXxcUzcqR+j9z1ZLNsBwj8qmlBjJRnbFL+iOl/i2Ofoh8envBAEUUacJwtQnSoy6LwO jmucy46yl/Gc1KYEyeiB1DYRZa1W2DilalnCfYgIFqKZ7QQTzjC/I4/K5Q9GHCUsJcGTB9YelDCv 7sTruyw0Mtzcu81dTNELInCOtIwXvFNRNCW27W/xM+1wNynTEEYMP14nr0QNAAsTC1veA3kboQ== --001a11408a3aa04c46054a8f722c-- From nobody Sun Mar 12 16:08:32 2017 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 BF4F91293F3 for ; Sun, 12 Mar 2017 16:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 kA0ySUlOE1Xm for ; Sun, 12 Mar 2017 16:08:29 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 885C9126D74 for ; Sun, 12 Mar 2017 16:08:29 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 504B6A00400B for ; Sun, 12 Mar 2017 16:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=N90evqPlFmg8EWQU4mn7Yfmf300=; b= CV4ArdDufUvTdC7XoMRP8vUimp/tJ4hKq4/E5SXtIF1+5o18TbA3NtWh8clmnAjO bctVJfdpkkoPQBQQVuYPQgi0dzqsDqa13W441HepsMdqxkl3AK9CL8bUM69UCgVN xzm3ChGeOhMN/7zvRZkbG6vppr/w2sKXTe3u55LzEVM= Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com [209.85.215.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 1D178A00012B for ; Sun, 12 Mar 2017 16:08:28 -0700 (PDT) Received: by mail-lf0-f41.google.com with SMTP id z15so35388171lfd.1 for ; Sun, 12 Mar 2017 16:08:28 -0700 (PDT) X-Gm-Message-State: AMke39mxAE9+sdL4EF5PWketLYSj5wqNX5Ig7/g9J+/0zpnlFcF0UttwaseOy+TssYW9oUk8b3gfNQ5ir5XVrQ== X-Received: by 10.25.0.207 with SMTP id 198mr7854065lfa.134.1489360106304; Sun, 12 Mar 2017 16:08:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.193.197 with HTTP; Sun, 12 Mar 2017 16:08:25 -0700 (PDT) In-Reply-To: <0d7afa83-a9d7-f977-ca36-533fc13b720e@eff.org> References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> <20170311201904.GQ7733@mournblade.imrryr.org> <389a248f-37e4-9ff7-b330-b840e7c47931@eff.org> <0d7afa83-a9d7-f977-ca36-533fc13b720e@eff.org> From: Ryan Sleevi Date: Sun, 12 Mar 2017 16:08:25 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary=001a113c9f48144052054a90ac37 Archived-At: Cc: Patrick Donahue , Gervase Markham , Ryan Sleevi , "Salz, Rich" , Peter Bowen , "spasm@ietf.org" , Rob Stradling , Phillip Hallam-Baker Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 23:08:30 -0000 --001a113c9f48144052054a90ac37 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 12, 2017 at 12:48 PM, Jacob Hoffman-Andrews wrote: > > Separately: since we now realize that customers can't override CDN policy > by adding CAA records to their own zone, if a customer wants to set their > own CAA policy, the records have to be present on the CNAME target. That > is, the CDN would have to cooperate in adding that record. Because > different customers would no doubt want to express different policies, the > CDN would have to use a trampoline if they wanted to offer per-customer CAA > settings. However, this is true in both tree-climbing and non-tree-climbing > worlds. Do you agree? > That sounds correct --001a113c9f48144052054a90ac37 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 12, 2017 at 12:48 PM, Jacob Hoffman-Andrews <jsha@eff.org&g= t; wrote:
Separately: since we now realize that customers can't override CDN policy by adding CAA records to their own zone, if a customer wants to set their own CAA policy, the records have to be present on the CNAME target. That is, the CDN would have to cooperate in adding that record. Because different customers would no doubt want to express different policies, the CDN would have to use a trampoline if they wanted to offer per-customer CAA settings. However, this is true in both tree-climbing and non-tree-climbing worlds. Do you agree?

That sounds correct=C2= =A0
--001a113c9f48144052054a90ac37-- From nobody Sun Mar 12 16:53:59 2017 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 C6D4A12940C for ; Sun, 12 Mar 2017 16:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.003 X-Spam-Level: X-Spam-Status: No, score=-7.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=eff.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 En_jq6lxjZgZ for ; Sun, 12 Mar 2017 16:53:57 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D3C9129401 for ; Sun, 12 Mar 2017 16:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=RmFlKJA7qaOZroCGCrNPvHLifm1l+TzGdrnJWUP6KWw=; b=3sY/yiFL7L5uRD8UUWuMJk+6F9IcY+/rg3KBUhnwZbAz6ep1C3JuYOwGofRu0LsAQ3SlUaRprXvh6y9hvTKvdf5hRTIlJm+/UV9/6uO857PLUadY/MrSvL1zgFGeaczh9gHSz+XaMMns1NyMQDvFqaXsjN0XsvvMydKVqM5xtyo=; Received: ; Sun, 12 Mar 2017 16:53:56 -0700 To: Ryan Sleevi References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> <20170311201904.GQ7733@mournblade.imrryr.org> <389a248f-37e4-9ff7-b330-b840e7c47931@eff.org> <0d7afa83-a9d7-f977-ca36-533fc13b720e@eff.org> From: Jacob Hoffman-Andrews Message-ID: <7129a939-35f1-f55b-703b-9f39f6110520@eff.org> Date: Sun, 12 Mar 2017 16:53:53 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9B5D47D07268D7AF1A72187B" Received-SPF: skipped for local relay Archived-At: Cc: Patrick Donahue , Gervase Markham , "Salz, Rich" , Peter Bowen , "spasm@ietf.org" , Rob Stradling , Phillip Hallam-Baker Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 23:53:58 -0000 This is a multi-part message in MIME format. --------------9B5D47D07268D7AF1A72187B Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > 1. Policy set by user-facing domain owner for their own hostnames. > 2. Blanket policy set by CDN for hostnames they operate on their customers' behalf. > 3. Policy set by CDN for their own hostnames, which share the same base domain as the CNAME targets used in (2). So, back to the subjective evaluation: Now it's clear that the CDN in our scenario is the only one who can add CAA records. If a customer wants (1) they need cooperation from their CDN, and the CDN needs to implement a trampoline no matter what. *In the non-tree-climbing world* If a CDN wants to implement (3), they put in place a single CAA record and it doesn't impact (1) or (2). If the CDN wants to implement (1) or (2), they put in a CAA record at each of their CNAME targets. Neither policy affects the other in any way, assuming that CNAME targets are never base domains. *In the tree-climbing world* If a CDN wants to implement (3), they have to carefully understand CAA and be sure to add a separate "any" record to each of their CNAME targets. They also have to make sure to copy that CAA record to any new CNAME targets they create. I argue that this is less intuitive and more difficult than in the tree-climbing world. More difficult, because it requires deploying extra CAA records to express a straightforward policy. Less intuitive, because most DNS-using applications don't care about the hostnames that are part of a CNAME chain, only the "final value" received from a recursive resolver. For instance, when looking up an A record, Chrome doesn't care about the CNAME aliases in between, only the final A record. Also, as a concrete example of the non-intuitiveness, Rob (one of the CAA authors) mentioned on the CA/Browser Forum list that he has had to double-check the lookup algorithm with Phill, his co-author. I've also been confused by the CAA lookup algorithm, as have my coworkers. I can't speak for Rob, but for me a big part of the confusion has been the fact that tree-climbing seems like an anomaly in the DNS world. --------------9B5D47D07268D7AF1A72187B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit > 1. Policy set by user-facing domain owner for their own hostnames.
> 2. Blanket policy set by CDN for hostnames they operate on their
customers' behalf.
> 3. Policy set by CDN for their own hostnames, which share the same
base domain as the CNAME targets used in (2).

So, back to the subjective evaluation: Now it's clear that the CDN in our scenario is the only one who can add CAA records. If a customer wants (1) they need cooperation from their CDN, and the CDN needs to implement a trampoline no matter what.

In the non-tree-climbing world

If a CDN wants to implement (3), they put in place a single CAA record and it doesn't impact (1) or (2). If the CDN wants to implement (1) or (2), they put in a CAA record at each of their CNAME targets. Neither policy affects the other in any way, assuming that CNAME targets are never base domains.

In the tree-climbing world

If a CDN wants to implement (3), they have to carefully understand CAA and be sure to add a separate "any" record to each of their CNAME targets. They also have to make sure to copy that CAA record to any new CNAME targets they create.

I argue that this is less intuitive and more difficult than in the tree-climbing world. More difficult, because it requires deploying extra CAA records to express a straightforward policy. Less intuitive, because most DNS-using applications don't care about the hostnames that are part of a CNAME chain, only the "final value" received from a recursive resolver. For instance, when looking up an A record, Chrome doesn't care about the CNAME aliases in between, only the final A record.

Also, as a concrete example of the non-intuitiveness, Rob (one of the CAA authors) mentioned on the CA/Browser Forum list that he has had to double-check the lookup algorithm with Phill, his co-author. I've also been confused by the CAA lookup algorithm, as have my coworkers. I can't speak for Rob, but for me a big part of the confusion has been the fact that tree-climbing seems like an anomaly in the DNS world.
--------------9B5D47D07268D7AF1A72187B-- From nobody Mon Mar 13 07:44:24 2017 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 D96D71296C3 for ; Mon, 13 Mar 2017 07:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0ECSFgmO_EA for ; Mon, 13 Mar 2017 07:44:21 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3B811294F1 for ; Mon, 13 Mar 2017 07:44:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5BD35300250 for ; Mon, 13 Mar 2017 10:44:20 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9-58hmTcqRgy for ; Mon, 13 Mar 2017 10:44:18 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 625503001A6 for ; Mon, 13 Mar 2017 10:44:18 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_038FD95C-8249-4FBD-800C-2CB2BB93248F" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 13 Mar 2017 10:44:32 -0400 References: <841bb724-7403-4682-3d50-f878f63b0346@cs.tcd.ie> <6d114340-c9a7-e311-e6f9-0614600cafd2@cs.tcd.ie> <00c401d298b8$616fffa0$4001a8c0@gateway.2wire.net> To: SPASM In-Reply-To: Message-Id: <9EC9BC6B-B1AB-4B1C-AC73-5501AA94465B@vigilsec.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Spasm] Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 14:44:23 -0000 --Apple-Mail=_038FD95C-8249-4FBD-800C-2CB2BB93248F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 These changes were made in response to an IETF Last Call comment. = Please review them. The vast bulk of the changes are in Section 6. = Please speak promptly if you think this is the word technical solution. Russ > On Mar 12, 2017, at 5:40 PM, Wei Chuang wrote: >=20 > The latest draft 08 is up: > https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-08 = >=20 > The diff is: > = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-eai-addresses-08.tx= t = >=20 > This draft attempts to capture Viktor's name constraint verifier = logic, and illustrate the examples in the diagrams. >=20 > -Wei > =20 >=20 > On Thu, Mar 9, 2017 at 10:22 AM, Wei Chuang > wrote: > There seems to be a consensus here and internally to the changes that = Viktor proposes. We can put that in the next draft update. >=20 > -Wei >=20 > On Thu, Mar 9, 2017 at 1:34 AM, tom p. > wrote: > ----- Original Message ----- > From: "Viktor Dukhovni" > > To: >; "IETF general list" = > > Sent: Thursday, March 09, 2017 3:19 AM > > On Mar 8, 2017, at 8:17 PM, Wei Chuang > wrote: > > > > Okay. I think the direction then is to have SmtpUTF8Name respect > rfc822Name name constraints and vice versa. >=20 > Well, no, the simplest proposal on the table is for SmtpUTF8Name to > be *prohibited* when rfc822Name constraints are present and = SmtpUTF8Name > constraints are not. When both present, they can operate = independently. >=20 > >=20 > Getting security right can be tricky as the legion of failed attempts > that make it to RFC testify but what you are proposing here seems so > simple, so obviously the right thing to do that I am puzzled, = bewildered > even, that anyone can disagree with you. >=20 > Tom Petch >=20 > The verifier logic is then: >=20 > 1. If neither rfc822Name constraints nor SmtpUTF8Name constraints > are present in any CA certificate in the chain, any mixture > of > rfc822Name and SmtpUTF8Name SAN elements is valid. >=20 > 2. If some certificate in the chain contains *only* rfc822Name > constraints, then these apply to rfc822Name SAN elements, but > all SmtpUTF8Names are prohibited. >=20 > 3. When both types of constraints are present in all CA certificates > that have either type, then constraints for each SAN type = are > exclusively based on just the corresponding constraint type. >=20 > 4. If some certificate in the chain contains only SmtpUTF8Name > constraints then those are unavoidably at risk of bypass via > rfc822Name SAN elements when processed by legacy verifiers. > Therefore, this should be avoided, and the CA needs to > publish rfc822Name constraints that prevent bypass. Such > constraints *need not* be equivalent (not always possible) > to the desired SmtpUTF8Name constraints. Rather, it suffices > to not permit rfc822Name elements that would be prohibited > if they were simply cut/pasted (with no A-label to U-label > conversions) as SmtpUTF8Name elements. It is not necessary > for these to permit everything that SmtpUTF8Name permits. >=20 > Thus for example, if SmtpUtf8Name only permits addresses in the non > NR-LDH > domain "=D0=B4=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0=B9.org = " (or a specific set of addresses in such = a domain), > then the corresponding rfc822Name constraint could just permit "." (or > the > reserved "invalid" TLD if that's preferable) which is not a usable = email > domain. This ensures that only the permitted SmtpUTF8Name SANs are = used > and no rfc822Name SANs are used. >=20 > If, instead the Smtp8Name constraints are excluded non-ASCII address > forms, > then since these have no literal rfc822Name equivalents, the = rfc822Name > constraints can be omitted with the same effect. >=20 > Only when the intention is to permit NR-LDH domains with either ASCII = or > UTF-8 localparts (or an all-ASCII full address) do the rfc822Name and > SmtpUTF8Name constraints need to be fully equivalent. This is of = course > trivial to do. Just cut/paste the same string into both types of > constraint. >=20 > -- > Viktor. >=20 >=20 >=20 --Apple-Mail=_038FD95C-8249-4FBD-800C-2CB2BB93248F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 These changes were made in response to an IETF Last Call = comment.  Please review them.  The vast bulk of the changes = are in Section 6.  Please speak promptly if you think this is the = word technical solution.

Russ



On = Mar 12, 2017, at 5:40 PM, Wei Chuang <weihaw@google.com> = wrote:

The latest draft 08 is up:
https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-08

The diff is:
https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-eai-addr= esses-08.txt

This draft attempts to capture Viktor's = name constraint verifier logic, and illustrate the examples in the = diagrams.

-Wei
 

On Thu, = Mar 9, 2017 at 10:22 AM, Wei Chuang <weihaw@google.com> wrote:
There seems to be a consensus here and internally to the changes that Viktor = proposes.  We can put that in the next draft update.

-Wei

On Thu, = Mar 9, 2017 at 1:34 AM, tom p. <daedulus@btconnect.com> wrote:
----- = Original Message -----
From: "Viktor Dukhovni" <ietf-dane@dukhovni.org>
= To: <spasm@ietf.org>; "IETF general list" <ietf@ietf.org>
Sent: Thursday, March 09, 2017 3:19 AM
> On Mar 8, 2017, at 8:17 PM, Wei Chuang <weihaw@google.com> wrote:
>
> Okay.  I think the direction then is to have SmtpUTF8Name = respect
rfc822Name name constraints and vice versa.

Well, no, the simplest proposal on the table is for SmtpUTF8Name to
be *prohibited* when rfc822Name constraints are present and = SmtpUTF8Name
constraints are not.  When both present, they can operate = independently.

<tp>

Getting security right can be tricky as the legion of failed attempts
that make it to RFC testify but what you are proposing here seems so
simple, so obviously the right thing to do that I am puzzled, = bewildered
even, that anyone can disagree with you.

Tom Petch

The verifier logic is then:

1. If neither rfc822Name constraints nor SmtpUTF8Name constraints
           are present in any CA = certificate in the chain, any mixture
of
           rfc822Name and SmtpUTF8Name SAN = elements is valid.

2. If some certificate in the chain contains *only* rfc822Name
   constraints, then these apply to rfc822Name SAN elements, = but
   all SmtpUTF8Names are prohibited.

3. When both types of constraints are present in all CA certificates
           that have either type, then = constraints for each SAN type are
   exclusively based on just the corresponding constraint = type.

4. If some certificate in the chain contains only SmtpUTF8Name
     constraints then those are unavoidably at risk of = bypass via
           rfc822Name SAN elements when = processed by legacy verifiers.
   Therefore, this should be avoided, and the CA needs to
     publish rfc822Name constraints that prevent = bypass.  Such
   constraints *need not* be equivalent (not always = possible)
   to the desired SmtpUTF8Name constraints.  Rather, it = suffices
   to not permit rfc822Name elements that would be = prohibited
   if they were simply cut/pasted (with no A-label to = U-label
           conversions) as SmtpUTF8Name = elements.  It is not necessary
   for these to permit everything that SmtpUTF8Name = permits.

Thus for example, if SmtpUtf8Name only permits addresses in the non
NR-LDH
domain "=D0=B4=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0= =B9.org" (or a specific set of addresses in such a domain),
then the corresponding rfc822Name constraint could just permit "." = (or
the
reserved "invalid" TLD if that's preferable) which is not a usable = email
domain.  This ensures that only the permitted SmtpUTF8Name SANs are = used
and no rfc822Name SANs are used.

If, instead the Smtp8Name constraints are excluded non-ASCII address
forms,
then since these have no literal rfc822Name equivalents, the = rfc822Name
constraints can be omitted with the same effect.

Only when the intention is to permit NR-LDH domains with either ASCII = or
UTF-8 localparts (or an all-ASCII full address) do the rfc822Name and
SmtpUTF8Name constraints need to be fully equivalent.  This is of = course
trivial to do.  Just cut/paste the same string into both types = of
constraint.

--
Viktor.




= --Apple-Mail=_038FD95C-8249-4FBD-800C-2CB2BB93248F-- From nobody Mon Mar 13 08:14:07 2017 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 4AB851296D8 for ; Mon, 13 Mar 2017 08:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 eC77iINMntNM for ; Mon, 13 Mar 2017 08:14:04 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92334129650 for ; Mon, 13 Mar 2017 08:14:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D56F030048E for ; Mon, 13 Mar 2017 11:14:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vbOR5UMpu1-u for ; Mon, 13 Mar 2017 11:13:56 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id D057F30041B for ; Mon, 13 Mar 2017 11:13:56 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_C0D63AE0-9A7B-48E5-932D-C640AB498025" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 13 Mar 2017 11:14:11 -0400 References: <841bb724-7403-4682-3d50-f878f63b0346@cs.tcd.ie> <6d114340-c9a7-e311-e6f9-0614600cafd2@cs.tcd.ie> <00c401d298b8$616fffa0$4001a8c0@gateway.2wire.net> <9EC9BC6B-B1AB-4B1C-AC73-5501AA94465B@vigilsec.com> To: SPASM In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Spasm] Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 15:14:06 -0000 --Apple-Mail=_C0D63AE0-9A7B-48E5-932D-C640AB498025 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It appears that autocorrect made a typo much worse. I meant so say... These changes were made in response to an IETF Last Call comment. = Please review them. The vast bulk of the changes are in Section 6. = Please speak promptly if you think this is the wrong technical solution. Russ > From: Russ Housley [mailto:housley@vigilsec.com = ]=20 Sent: Monday, March 13, 2017 10:45 AM To: SPASM Subject: Re: [Spasm] Last Call: = (Internationalized Email Addresses in X.509 certificates) to Proposed = Standard =20 These changes were made in response to an IETF Last Call comment. = Please review them. The vast bulk of the changes are in Section 6. = Please speak promptly if you think this is the word technical solution. =20 Russ =20 =20 =20 On Mar 12, 2017, at 5:40 PM, Wei Chuang > wrote: =20 The latest draft 08 is up: https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-08 = =20 The diff is: = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-eai-addresses-08.tx= t = =20 This draft attempts to capture Viktor's name constraint verifier logic, = and illustrate the examples in the diagrams. =20 -Wei =20 =20 On Thu, Mar 9, 2017 at 10:22 AM, Wei Chuang > wrote: There seems to be a consensus here and internally to the changes that = Viktor proposes. We can put that in the next draft update. =20 -Wei =20 On Thu, Mar 9, 2017 at 1:34 AM, tom p. > wrote: ----- Original Message ----- From: "Viktor Dukhovni" > To: >; "IETF general list" = > Sent: Thursday, March 09, 2017 3:19 AM > On Mar 8, 2017, at 8:17 PM, Wei Chuang > wrote: > > Okay. I think the direction then is to have SmtpUTF8Name respect rfc822Name name constraints and vice versa. Well, no, the simplest proposal on the table is for SmtpUTF8Name to be *prohibited* when rfc822Name constraints are present and SmtpUTF8Name constraints are not. When both present, they can operate independently. Getting security right can be tricky as the legion of failed attempts that make it to RFC testify but what you are proposing here seems so simple, so obviously the right thing to do that I am puzzled, bewildered even, that anyone can disagree with you. Tom Petch The verifier logic is then: 1. If neither rfc822Name constraints nor SmtpUTF8Name constraints are present in any CA certificate in the chain, any mixture of rfc822Name and SmtpUTF8Name SAN elements is valid. 2. If some certificate in the chain contains *only* rfc822Name constraints, then these apply to rfc822Name SAN elements, but all SmtpUTF8Names are prohibited. 3. When both types of constraints are present in all CA certificates that have either type, then constraints for each SAN type are exclusively based on just the corresponding constraint type. 4. If some certificate in the chain contains only SmtpUTF8Name constraints then those are unavoidably at risk of bypass via rfc822Name SAN elements when processed by legacy verifiers. Therefore, this should be avoided, and the CA needs to publish rfc822Name constraints that prevent bypass. Such constraints *need not* be equivalent (not always possible) to the desired SmtpUTF8Name constraints. Rather, it suffices to not permit rfc822Name elements that would be prohibited if they were simply cut/pasted (with no A-label to U-label conversions) as SmtpUTF8Name elements. It is not necessary for these to permit everything that SmtpUTF8Name permits. Thus for example, if SmtpUtf8Name only permits addresses in the non NR-LDH domain "=D0=B4=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0=B9.org = " (or a specific set of addresses in such a = domain), then the corresponding rfc822Name constraint could just permit "." (or the reserved "invalid" TLD if that's preferable) which is not a usable email domain. This ensures that only the permitted SmtpUTF8Name SANs are used and no rfc822Name SANs are used. If, instead the Smtp8Name constraints are excluded non-ASCII address forms, then since these have no literal rfc822Name equivalents, the rfc822Name constraints can be omitted with the same effect. Only when the intention is to permit NR-LDH domains with either ASCII or UTF-8 localparts (or an all-ASCII full address) do the rfc822Name and SmtpUTF8Name constraints need to be fully equivalent. This is of course trivial to do. Just cut/paste the same string into both types of constraint. -- Viktor. --Apple-Mail=_C0D63AE0-9A7B-48E5-932D-C640AB498025 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 It appears that autocorrect made a typo much worse.  I = meant so say...

These = changes were made in response to an IETF Last Call comment.  Please = review them.  The vast bulk of the changes are in Section 6. =  Please speak promptly if you think this is the wrong technical = solution.

Russ

From: Russ Housley [mailto:housley@vigilsec.com] 
Sent: Monday, March 13, 2017 = 10:45 AM
To: SPASM
Subject: Re: [Spasm] Last Call: = <draft-ietf-lamps-eai-addresses-05.txt> (Internationalized Email = Addresses in X.509 certificates) to Proposed Standard
 
These changes were made in response to an IETF Last Call = comment.  Please review them.  The vast bulk of the changes = are in Section 6.  Please speak promptly if you think this is the = word technical solution.
 
Russ
 
 
 
On Mar 12, 2017, at = 5:40 PM, Wei Chuang <weihaw@google.com> wrote:
 
The latest draft 08 is up:
 
The diff is:
 
This draft attempts to capture Viktor's name = constraint verifier logic, and illustrate the examples in the = diagrams.
 
-Wei
 
 
On Thu, Mar 9, 2017 at 10:22 AM, Wei = Chuang <weihaw@google.com> wrote:
There seems to be a consensus here and internally to the = changes that Viktor proposes.  We can put that in the next draft = update.
 
-Wei
 
On Thu, Mar 9, 2017 at 1:34 AM, tom p. = <daedulus@btconnect.com> wrote:
----- = Original Message -----
From: "Viktor Dukhovni" <ietf-dane@dukhovni.org>
To: <spasm@ietf.org>; "IETF = general list" <ietf@ietf.org>
Sent: Thursday, March 09, = 2017 3:19 AM
> On Mar 8, 2017, at 8:17 PM, Wei Chuang = <weihaw@google.com>= wrote:
>
> Okay.  I think the = direction then is to have SmtpUTF8Name respect
rfc822Name = name constraints and vice versa.

Well, no, = the simplest proposal on the table is for SmtpUTF8Name to
be= *prohibited* when rfc822Name constraints are present and = SmtpUTF8Name
constraints are not.  When both present, = they can operate independently.

<tp>
Getting security right can be tricky as the = legion of failed attempts
that make it to RFC testify but = what you are proposing here seems so
simple, so obviously = the right thing to do that I am puzzled, bewildered
even, = that anyone can disagree with you.

Tom = Petch


The verifier = logic is then:

1. If neither rfc822Name = constraints nor SmtpUTF8Name constraints
    =        are present in any CA certificate in the = chain, any mixture
of
      =      rfc822Name and SmtpUTF8Name SAN elements is = valid.

2. If some certificate in the chain = contains *only* rfc822Name
   constraints, then = these apply to rfc822Name SAN elements, but
  =  all SmtpUTF8Names are prohibited.

3. = When both types of constraints are present in all CA certificates
           that have either = type, then constraints for each SAN type are
  =  exclusively based on just the corresponding constraint type.

4. If some certificate in the chain contains = only SmtpUTF8Name
     constraints then = those are unavoidably at risk of bypass via
    =        rfc822Name SAN elements when processed by = legacy verifiers.
   Therefore, this should be = avoided, and the CA needs to
     publish = rfc822Name constraints that prevent bypass.  Such
   constraints *need not* be equivalent (not always = possible)
   to the desired SmtpUTF8Name = constraints.  Rather, it suffices
   to not = permit rfc822Name elements that would be prohibited
  =  if they were simply cut/pasted (with no A-label to U-label
           conversions) as = SmtpUTF8Name elements.  It is not necessary
  =  for these to permit everything that SmtpUTF8Name permits.

Thus for example, if SmtpUtf8Name only permits = addresses in the non
NR-LDH
domain "=D0=B4=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0=B9.org" (or = a specific set of addresses in such a domain),
then the = corresponding rfc822Name constraint could just permit "." (or
the
reserved "invalid" TLD if that's = preferable) which is not a usable email
domain.  This = ensures that only the permitted SmtpUTF8Name SANs are used
and no rfc822Name SANs are used.

If, instead the Smtp8Name constraints are excluded non-ASCII = address
forms,
then since these have no = literal rfc822Name equivalents, the rfc822Name
constraints = can be omitted with the same effect.

Only = when the intention is to permit NR-LDH domains with either ASCII or
UTF-8 localparts (or an all-ASCII full address) do the = rfc822Name and
SmtpUTF8Name constraints need to be fully = equivalent.  This is of course
trivial to do.  = Just cut/paste the same string into both types of
constraint.

--
Viktor.


= --Apple-Mail=_C0D63AE0-9A7B-48E5-932D-C640AB498025-- From nobody Mon Mar 13 12:34:23 2017 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 EEBA1129496; Mon, 13 Mar 2017 12:34:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148943366194.20405.16431515603847843900@ietfa.amsl.com> Date: Mon, 13 Mar 2017 12:34:21 -0700 Archived-At: Cc: spasm@ietf.org Subject: [Spasm] I-D Action: draft-ietf-lamps-rfc5750-bis-03.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 19:34:22 -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 of the IETF. Title : Secure/Multipurpose Internet Mail Extensions (S/ MIME) Version 4.0 Certificate Handling Authors : Jim Schaad Blake Ramsdell Sean Turner Filename : draft-ietf-lamps-rfc5750-bis-03.txt Pages : 25 Date : 2017-03-13 Abstract: This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 3850. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5750-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc5750-bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc5750-bis-03 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 Mar 13 12:34:47 2017 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 14907129AC8; Mon, 13 Mar 2017 12:34:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148943368006.20354.3658517723914013390@ietfa.amsl.com> Date: Mon, 13 Mar 2017 12:34:40 -0700 Archived-At: Cc: spasm@ietf.org Subject: [Spasm] I-D Action: draft-ietf-lamps-rfc5751-bis-04.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 13 Mar 2017 19:34:40 -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 of the IETF. Title : Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification Authors : Jim Schaad Blake Ramsdell Sean Turner Filename : draft-ietf-lamps-rfc5751-bis-04.txt Pages : 57 Date : 2017-03-13 Abstract: This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc5751-bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc5751-bis-04 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 Mar 13 12:51:04 2017 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 42803129481 for ; Mon, 13 Mar 2017 12:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPc0yDXXnSLs for ; Mon, 13 Mar 2017 12:51:00 -0700 (PDT) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 400F2129A92 for ; Mon, 13 Mar 2017 12:40:48 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1489434045; h=from:subject:to:date:message-id; bh=VfCz/YhrHH2Yz+mScpXvx9LD37yPvG/LQyb2QI2sJBA=; b=NkAGQ0BWP/vHbwC9SzfT0TRkwkos/h10b7mAlKUPvhyGVCpppp6n023CTlG5SDE3+FivS2tKyzS /YiBDPNIIxBfzJgV+4ARga7v9hvmbBHdNki0LifhsVFWSUiexKxNgEcbzb4nAE1KV1FULE+PEtke7 kJt3oOYuNxMzCkvDM9kAdjIUSMl1194wGNNQCDttI4lzWUG3yksH8apQkrbMcRGyMcSxCdJqKk/8k MIbLZBmZ4m4vbQTF1vX8hblXx4DgD4q5E7iWSYo5+7INAsK4ORcOWN3ZiEL6P5f3vl6bLr7kwyrtQ yCO6TZ8j8nUgs/OKxBQPWdSOm6Cza+jR54Vw== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 13 Mar 2017 12:40:44 -0700 Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 13 Mar 2017 12:38:26 -0700 From: Jim Schaad To: 'SPASM' Date: Mon, 13 Mar 2017 12:40:41 -0700 Message-ID: <0bea01d29c31$b4930430$1db90c90$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdKcMO0yswrR1gmNTpyE1sH3gy3XdQ== X-Originating-IP: [24.21.96.37] Archived-At: Subject: [Spasm] Document Updates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 19:51:02 -0000 I have released new versions of the two S/MIME documents to address all last call comments received. I have not dealt with one comment which has to do with the first default algorithm to be used for encryption when there is no knowledge of what the recipient of the message is capable of. This has traditionally always been the "best possible recommendation" that we can provide. For this reason, I have set it to AES-128 GCM. Russ has requested that this be changed to AES-256 CBC because we are introducing not only a new algorithm but a new CMS structure at the same time. This means that not only would a down client be unable to decrypt the message but would not recognize it as being an encrypted message. I do not really think that I care about this possible problem as it should be dealt with cleanly, an ASN.1 decode error needs to be coped with. For this reason I do not think there is going to be a significant behavior difference between an ASN.1 decode/message type recognition problem and a cannot decrypt because the algorithm is unknown. Jim From nobody Mon Mar 13 13:01:13 2017 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 28EE9129A92 for ; Mon, 13 Mar 2017 13:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 PoPYGlh5xzbX for ; Mon, 13 Mar 2017 13:01:11 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06D0612949D for ; Mon, 13 Mar 2017 13:01:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6014930041B for ; Mon, 13 Mar 2017 16:01:10 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gQS_q0jjyutg for ; Mon, 13 Mar 2017 16:01:09 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 51FA130048E for ; Mon, 13 Mar 2017 16:01:09 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 13 Mar 2017 16:01:08 -0400 References: <0bea01d29c31$b4930430$1db90c90$@augustcellars.com> To: SPASM In-Reply-To: <0bea01d29c31$b4930430$1db90c90$@augustcellars.com> Message-Id: <5701426C-F82E-4E2E-9205-50F11FEC0F88@vigilsec.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Spasm] Document Updates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 20:01:12 -0000 > I have released new versions of the two S/MIME documents to address = all last > call comments received. >=20 > I have not dealt with one comment which has to do with the first = default > algorithm to be used for encryption when there is no knowledge of what = the > recipient of the message is capable of. This has traditionally always = been > the "best possible recommendation" that we can provide. For this = reason, I > have set it to AES-128 GCM. =20 >=20 > Russ has requested that this be changed to AES-256 CBC because we are > introducing not only a new algorithm but a new CMS structure at the = same > time. This means that not only would a down client be unable to = decrypt the > message but would not recognize it as being an encrypted message.=20 >=20 > I do not really think that I care about this possible problem as it = should > be dealt with cleanly, an ASN.1 decode error needs to be coped with. = For > this reason I do not think there is going to be a significant behavior > difference between an ASN.1 decode/message type recognition problem = and a > cannot decrypt because the algorithm is unknown. Implementer=E2=80=99s please state you preference.= From nobody Mon Mar 13 19:55:49 2017 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 DB212129B0A for ; Mon, 13 Mar 2017 19:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 0oj5sjHt1zfp for ; Mon, 13 Mar 2017 19:55:45 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A45E7129B35 for ; Mon, 13 Mar 2017 19:55:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D5AD1300498 for ; Mon, 13 Mar 2017 22:55:44 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Xi6x6UCsscGV for ; Mon, 13 Mar 2017 22:55:43 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id DFC463001A6 for ; Mon, 13 Mar 2017 22:55:43 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 13 Mar 2017 22:55:44 -0400 References: <210541ED-1BCA-4B0D-B69E-90DE81DBDA79@amsl.com> To: SPASM In-Reply-To: <210541ED-1BCA-4B0D-B69E-90DE81DBDA79@amsl.com> Message-Id: X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [Spasm] LAMPS in Experimental Room Layout X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2017 02:55:48 -0000 Since we are a small group, I thought we would try an experimental = layout. Hopefully everyone will have a seat at the table. > The LAMPS session has been placed in the experimental layout room on = Thursday, March 30. The room will have U-shape seating for roughly 30 = people with theater style seating behind it. There will microphones = available to those seated at the U-shape table and standing microphones = for the theater seats behind (typical Q&A mic set). MeetEcho will be = supporting these meetings. If you have any questions regarding this, = please let me know! Russ= From nobody Tue Mar 14 01:02:48 2017 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 7C49F1294A6 for ; Tue, 14 Mar 2017 01:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 trpR-_J3A1KU for ; Tue, 14 Mar 2017 01:02:44 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 8A77C126CD8 for ; Tue, 14 Mar 2017 01:02:44 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id m124so89008230oig.1 for ; Tue, 14 Mar 2017 01:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Dpv3Lalffm/O5dA9Rkk/E0zzJa9qA+DywzC0Qn/etHs=; b=VJovPmfo5lt/hVXMtsjeGWH+xAvfwLj68ADI1TpZaOtRnL2DcNf32uTmMJKzIGFeEM pxzNgBPkXXu3delXQ7d9dd9YqQ5+uy+klXVQ9arqqMArwFG+qAXZkdv8N3ga5nVOVWkA +oz8WRORtzc41g2vGNLfGRXVZms50dj/3vvK4uAYny4+H0jsksHaOBNSf3nQMCW+6mYL 5YRNVwoAD2NECGgqcyMjoD/fqeJOLaT2ngjL61ARdJv4jtwS4s//5Juu1zVZx6wWWITc amJqx4koW/BJ0M1wZ9K3AWAVW678abQyfKGgLrNC9yfDjMX66y6NskJ30W78d6GpyxYP twqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Dpv3Lalffm/O5dA9Rkk/E0zzJa9qA+DywzC0Qn/etHs=; b=tSTUpkuOxgLnE/NMxP7fYJvYRggrwARC2NkUb9Dr8MDyAJW5KYnJT10JLOQ1+R/wrE EKaFD5YIn+4zVWRsFDZ8EZzOhE4qRWw16ciJBYrvzzOl+/hqwt07eDhgM/6PTwU01rxc NHyFJ942zOYLSYj415xc5ho1mzigBk2ddsRc4BhQR8/l4uaAh/JTC8H+EFW3SP75IzVd RsqsLFzPEvwxtOA8PY3sbeoRHfxARQWQJht/iDn0yFMj92GGYfFom7Gp+qIVc8ILIZoL l/bCE5gNMyLVvfeQ6jXFpehi2RIFXLZfaZjL94xmBS8zzOHHpzeVSApfNdokE1W9a76U nftA== X-Gm-Message-State: AMke39noVJDFY/kOdjb4VSWp5P8MkVlGrX5MYKJ6BP2eyptC0hzOxuE/Pr9pGH7ShrCckLszVLUbXJ4b7WtbQ8Er X-Received: by 10.202.79.18 with SMTP id d18mr20286819oib.9.1489478563676; Tue, 14 Mar 2017 01:02:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.41.226 with HTTP; Tue, 14 Mar 2017 01:02:42 -0700 (PDT) In-Reply-To: <5701426C-F82E-4E2E-9205-50F11FEC0F88@vigilsec.com> References: <0bea01d29c31$b4930430$1db90c90$@augustcellars.com> <5701426C-F82E-4E2E-9205-50F11FEC0F88@vigilsec.com> From: Wei Chuang Date: Tue, 14 Mar 2017 01:02:42 -0700 Message-ID: To: Russ Housley Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a113d85c4b62f95054aac40b2" Archived-At: Cc: SPASM Subject: Re: [Spasm] Document Updates X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2017 08:02:46 -0000 --001a113d85c4b62f95054aac40b2 Content-Type: multipart/alternative; boundary=001a113d85c4b0fd8e054aac40e2 --001a113d85c4b0fd8e054aac40e2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Mon, Mar 13, 2017 at 1:01 PM, Russ Housley wrote: > > I have released new versions of the two S/MIME documents to address all > last > > call comments received. > > > > I have not dealt with one comment which has to do with the first default > > algorithm to be used for encryption when there is no knowledge of what > the > > recipient of the message is capable of. This has traditionally always > been > > the "best possible recommendation" that we can provide. For this > reason, I > > have set it to AES-128 GCM. > > > > Russ has requested that this be changed to AES-256 CBC because we are > > introducing not only a new algorithm but a new CMS structure at the same > > time. This means that not only would a down client be unable to decrypt > the > > message but would not recognize it as being an encrypted message. > > > > I do not really think that I care about this possible problem as it > should > > be dealt with cleanly, an ASN.1 decode error needs to be coped with. For > > this reason I do not think there is going to be a significant behavior > > difference between an ASN.1 decode/message type recognition problem and a > > cannot decrypt because the algorithm is unknown. > > Implementer’s please state you preference. After conferring with some folks over here, our preference is for AES GCM since it provides integrity. We agree its better to make these updates 'cleanly' rather than string out the updates. -Wei --001a113d85c4b0fd8e054aac40e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On Mon, Mar 13, 2017 at 1:01 PM, Russ Housley <housley@vigilsec.com> wrote:
> I have released new versions of the two S/MIME documents to address all last
> call comments received.
>
> I have not dealt with one comment which has to do with the first default
> algorithm to be used for encryption when there is no knowledge of what the
> recipient of the message is capable of.  This has traditionally always been
> the "best possible recommendation" that we can provide.  For this reason, I
> have set it to AES-128 GCM.
>
> Russ has requested that this be changed to AES-256 CBC because we are
> introducing not only a new algorithm but a new CMS structure at the same
> time.  This means that not only would a down client be unable to decrypt the
> message but would not recognize it as being an encrypted message.
>
> I do not really think that I care about this possible problem as it should
> be dealt with cleanly, an ASN.1 decode error needs to be coped with.  For
> this reason I do not think there is going to be a significant behavior
> difference between an ASN.1 decode/message type recognition problem and a
> cannot decrypt because the algorithm is unknown.

Implementer’s please state you preference.

After conferring with some folks over here, our preference is for AES GCM since it provides integrity.  We agree its better to make these updates 'cleanly' rather than string out the updates.

-Wei

--001a113d85c4b0fd8e054aac40e2-- --001a113d85c4b62f95054aac40b2 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMZN1N4N3KNCF5ZBTQMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTAyNjE4NDI0NVoXDTE3MDQy NDE4NDI0NVowIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDiNpZ5E2IqcxktrcD1X5jWksphe1Ur882fsZM99Y4hiVugSVOb zIZIxoh3ckmGpUFyK1un6AU9Rxq9GSSkRskGAaSGrGcy7ncPi7Z1NlOJN25oXFmzituZsZeYIs0S QqT9hlDpLGc95r1CpsuTlaIB8m9Uvi+H6sGecVb2TOuGbRViQIWWf5GWk2AlJYhBFyJv7regqVa8 v3fx6SLkn/hIzBQf7xpVJzG6kAa09ZE0LoPdp5YV+Hv38EqDOWjm+g6Qbh1NADhdGpbmQDp9kdlm 6WZjCMwryQukdCypLKI2BPa08F18LZktaQNlJ2s7VxDJj2ozxomeBpSK6rxSxLAjAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFIMwgx+nNfYP3NyOZfiHYydFyNdQMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAO0J2vGX8ye90RegS3 HS+OE2hGEdDYJlR+S9ZSpla5AC9eejUKUc9JZR3y0ocGeQ3FQyXjM5/azBblqz/ajAbj2Fxuge45 SdRXrItDhAGWtQNl3utu2Uhf4y3re4ZRjApnhEBBX1l0E2BJuHf8MmqMhVU70Ko6Lk3lyPxnBeWo Q3tG2He3CNCkq/SDImq9vf8CNoxKxEkCP+kI+/NaCh5peLygU1h7Dc0ryWAcrxRWn8GUeEOg28MI vpwttw54cNR4YJYJVuiXCNc6PqkT/JxCiMvHS1woXJuET6QZSPtpNtvhNu90sV68Q7b2m6Vp8QTn xbzoEIHhiQWIcfphXjbeMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMZN1N4N3K NCF5ZBTQMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBJxz6NfNLpoN5jucWYPCFY uIzxxOp9vXqgGk27+6NV+jAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAzMTQwODAyNDRaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAonmR0pDL5oAqp8lFA3V/tySFzVUhWmWsOnZbaS2M TWcru2PWab6o6u8JJPBd5NKVbSHL50zwKaV5ePo0XURcvE/pcIt65o43NzJ4aCs3jKBVSYmM8OHA GK0bUsfJUTTHhcq88aqmxp+Xi90gq7XXbD574CBwRdnu2Paty/+V3u8rdB6cacT3TPEMAURv7yoo RwlTsNrwqk5jM7fw7W7ZaiGxEO2cw8NR9JIV+9PFUKwu5l06t/M9SaxHU/n+i1GNvL4pGak5gemc i3UuBgSyPZWi3wkv/5gTj+Ho0psOi96sbXjkl4aFFh9n/TGbj1hXPnlxc7VH54oQtxQBxSyqoQ== --001a113d85c4b62f95054aac40b2-- From nobody Tue Mar 14 04:22:09 2017 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 1DCB4127078; Tue, 14 Mar 2017 04:22:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stewart Bryant To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148949052209.12632.10288586023034172850@ietfa.amsl.com> Date: Tue, 14 Mar 2017 04:22:02 -0700 Archived-At: Cc: spasm@ietf.org, ietf@ietf.org, draft-ietf-lamps-eai-addresses.all@ietf.org Subject: [Spasm] Review of draft-ietf-lamps-eai-addresses-08 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2017 11:22:02 -0000 Reviewer: Stewart Bryant Review result: Ready 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 wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-lamps-eai-addresses-?? Reviewer: Stewart Bryant Review Date: 2017-03-14 IETF LC End Date: 2017-01-30 IESG Telechat date: 2017-03-16 Summary: I though that -6 was ready. Since then a lot of new text was added. I have checked the diffs and as a non-specialist I cannot see any problem with the added text, and so conclude that it is still ready. Major issues: None Minor issues: None Nits/editorial comments: None From nobody Tue Mar 14 06:44:11 2017 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 F3F4312717B for ; Tue, 14 Mar 2017 06:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-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=cs.tcd.ie 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 mD6CizMkbkkE for ; Tue, 14 Mar 2017 06:44:06 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2879B128DE8 for ; Tue, 14 Mar 2017 06:44:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D05CFBEAA; Tue, 14 Mar 2017 13:44:03 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tspnjEsj2SGl; Tue, 14 Mar 2017 13:43:57 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E8B5ABE74; Tue, 14 Mar 2017 13:43:56 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1489499037; bh=iHgzECNC/U8CMhP77mcT6+tccfCoPfS5cqm1zBHIojU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=3Y0EGYaaWx0ZbDppXCb+VLjonQ/KDc86nXCqH6jWwxWuMiLg4MlwcM+BKOUVFKnt8 eQ8VecgqTa8SKws8jZiIilOhnpfLApXDvz0x4R+49TKFGgmp/PrUCAWVdpAiYzIYZW c+q4QdVoxadBkhva2u6dwsdeJtF/YHK0u3d+HUBU= To: Russ Housley , SPASM References: <841bb724-7403-4682-3d50-f878f63b0346@cs.tcd.ie> <6d114340-c9a7-e311-e6f9-0614600cafd2@cs.tcd.ie> <00c401d298b8$616fffa0$4001a8c0@gateway.2wire.net> <9EC9BC6B-B1AB-4B1C-AC73-5501AA94465B@vigilsec.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 14 Mar 2017 13:43:53 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wfcdCJV0qo0qLn2KUV04ku5xr1RHEfeJd" Archived-At: Subject: Re: [Spasm] Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 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, 14 Mar 2017 13:44:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wfcdCJV0qo0qLn2KUV04ku5xr1RHEfeJd Content-Type: multipart/mixed; boundary="fs2GaOb1c9BEF1q1410HhOUj497rqllAU"; protected-headers="v1" From: Stephen Farrell To: Russ Housley , SPASM Message-ID: Subject: Re: [Spasm] Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard References: <841bb724-7403-4682-3d50-f878f63b0346@cs.tcd.ie> <6d114340-c9a7-e311-e6f9-0614600cafd2@cs.tcd.ie> <00c401d298b8$616fffa0$4001a8c0@gateway.2wire.net> <9EC9BC6B-B1AB-4B1C-AC73-5501AA94465B@vigilsec.com> In-Reply-To: --fs2GaOb1c9BEF1q1410HhOUj497rqllAU Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Russ, all, So I've thought about this a bit and chatted with a few folks, and I'm just not quite convinced that we've had enough time or eyeballs to process the perfectly reasonable looking (but significant) changes that were made during and since the end of IETF LC by this Thursday's IESG telechat. So I've taken this document off that agenda. Apologies that that'll cause a bit more delay due to the handover of ADs around IETF98 but I hope that that won't be a bad delay. I guess these LC changes are ones that it'd be good to go over in Chicago as well, just to be sure that we've landed in a good place. Note that after Chicago, the new AD can re-inject the document back into the process at IESG evaluation again if that's the right thing to do, so this change does not mean that a new IETF last call will be needed. Though of course if there are further changes that might end up being the right thing to do. In any case, for those who like process minutiae, I've left this in the "waiting for writeup" state but just taken it off this week's agenda. Cheers, and sorry again for being a cause of delay, S. On 13/03/17 15:14, Russ Housley wrote: > It appears that autocorrect made a typo much worse. I meant so say... >=20 > These changes were made in response to an IETF Last Call comment. Plea= se review them. The vast bulk of the changes are in Section 6. Please s= peak promptly if you think this is the wrong technical solution. >=20 > Russ >=20 >> From: Russ Housley [mailto:housley@vigilsec.com ]=20 > Sent: Monday, March 13, 2017 10:45 AM > To: SPASM > Subject: Re: [Spasm] Last Call: = (Internationalized Email Addresses in X.509 certificates) to Proposed St= andard > =20 > These changes were made in response to an IETF Last Call comment. Plea= se review them. The vast bulk of the changes are in Section 6. Please s= peak promptly if you think this is the word technical solution. > =20 > Russ > =20 > =20 > =20 > On Mar 12, 2017, at 5:40 PM, Wei Chuang > wrote: > =20 > The latest draft 08 is up: > https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-08 > =20 > The diff is: > https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-eai-addresses-08= =2Etxt > =20 > This draft attempts to capture Viktor's name constraint verifier logic,= and illustrate the examples in the diagrams. > =20 > -Wei > =20 > =20 > On Thu, Mar 9, 2017 at 10:22 AM, Wei Chuang > wrote: > There seems to be a consensus here and internally to the changes that V= iktor proposes. We can put that in the next draft update. > =20 > -Wei > =20 > On Thu, Mar 9, 2017 at 1:34 AM, tom p. > wrote: > ----- Original Message ----- > From: "Viktor Dukhovni" > > To: >; "IETF general list" > > Sent: Thursday, March 09, 2017 3:19 AM >> On Mar 8, 2017, at 8:17 PM, Wei Chuang > wrote: >> >> Okay. I think the direction then is to have SmtpUTF8Name respect > rfc822Name name constraints and vice versa. >=20 > Well, no, the simplest proposal on the table is for SmtpUTF8Name to > be *prohibited* when rfc822Name constraints are present and SmtpUTF8Nam= e > constraints are not. When both present, they can operate independently= =2E >=20 > >=20 > Getting security right can be tricky as the legion of failed attempts > that make it to RFC testify but what you are proposing here seems so > simple, so obviously the right thing to do that I am puzzled, bewildere= d > even, that anyone can disagree with you. >=20 > Tom Petch >=20 > The verifier logic is then: >=20 > 1. If neither rfc822Name constraints nor SmtpUTF8Name constraints > are present in any CA certificate in the chain, any mixture > of > rfc822Name and SmtpUTF8Name SAN elements is valid. >=20 > 2. If some certificate in the chain contains *only* rfc822Name > constraints, then these apply to rfc822Name SAN elements, but > all SmtpUTF8Names are prohibited. >=20 > 3. When both types of constraints are present in all CA certificates > that have either type, then constraints for each SAN type ar= e > exclusively based on just the corresponding constraint type. >=20 > 4. If some certificate in the chain contains only SmtpUTF8Name > constraints then those are unavoidably at risk of bypass via > rfc822Name SAN elements when processed by legacy verifiers. > Therefore, this should be avoided, and the CA needs to > publish rfc822Name constraints that prevent bypass. Such > constraints *need not* be equivalent (not always possible) > to the desired SmtpUTF8Name constraints. Rather, it suffices > to not permit rfc822Name elements that would be prohibited > if they were simply cut/pasted (with no A-label to U-label > conversions) as SmtpUTF8Name elements. It is not necessary > for these to permit everything that SmtpUTF8Name permits. >=20 > Thus for example, if SmtpUtf8Name only permits addresses in the non > NR-LDH > domain "=D0=B4=D1=83=D1=85=D0=BE=D0=B2=D0=BD=D1=8B=D0=B9.org " (or a specific set of addresses in such a domain), > then the corresponding rfc822Name constraint could just permit "." (or > the > reserved "invalid" TLD if that's preferable) which is not a usable emai= l > domain. This ensures that only the permitted SmtpUTF8Name SANs are use= d > and no rfc822Name SANs are used. >=20 > If, instead the Smtp8Name constraints are excluded non-ASCII address > forms, > then since these have no literal rfc822Name equivalents, the rfc822Name= > constraints can be omitted with the same effect. >=20 > Only when the intention is to permit NR-LDH domains with either ASCII o= r > UTF-8 localparts (or an all-ASCII full address) do the rfc822Name and > SmtpUTF8Name constraints need to be fully equivalent. This is of cours= e > trivial to do. Just cut/paste the same string into both types of > constraint. >=20 > -- > Viktor. >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm >=20 --fs2GaOb1c9BEF1q1410HhOUj497rqllAU-- --wfcdCJV0qo0qLn2KUV04ku5xr1RHEfeJd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYx/OZAAoJEC88hzaAX42iuqkH+QHDQWr3yPYFayE9tWHQbnhp uSwICN5cBc2T6WaHJ3nupV+D4fk+mN+nvNSdg2ZmVQcX5qg845yPHYXQwvPaOlB+ h4eFgjum3XnIGuAB23uia7QG0U+2Q2w3LEDJ7w6Ey9nMBfo5iKJl/RHbDxrL3H2T d3B5ui6OkAQKFDMLgEWAdmlaZ4qtVlIk15EZDOUGddU/NEBQDwPfb/hGDVLsliXb tVJtj+MXwzWQHeDrDKgMG+T+rfgZjxYYFC3ow+NBLxwPQSEv65tuvD3yDGcpeIei zrNkF7yF21/3vnN14ap/Zc7aaF5eKLmFgEkssueIvFscbSsuVVPot3mXQEPmGTM= =Owqz -----END PGP SIGNATURE----- --wfcdCJV0qo0qLn2KUV04ku5xr1RHEfeJd-- From nobody Tue Mar 14 07:49:06 2017 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 6B1E212709A for ; Tue, 14 Mar 2017 07:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_FILL_THIS_FORM_SHORT=0.01] 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 BGlOXl4-C6Qa for ; Tue, 14 Mar 2017 07:49:03 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F8BD12025F for ; Tue, 14 Mar 2017 07:49:03 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 334E57A3309; Tue, 14 Mar 2017 14:49:02 +0000 (UTC) Date: Tue, 14 Mar 2017 14:49:02 +0000 From: Viktor Dukhovni To: SPASM Message-ID: <20170314144901.GK4095@mournblade.imrryr.org> References: <841bb724-7403-4682-3d50-f878f63b0346@cs.tcd.ie> <6d114340-c9a7-e311-e6f9-0614600cafd2@cs.tcd.ie> <00c401d298b8$616fffa0$4001a8c0@gateway.2wire.net> <9EC9BC6B-B1AB-4B1C-AC73-5501AA94465B@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9EC9BC6B-B1AB-4B1C-AC73-5501AA94465B@vigilsec.com> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [Spasm] Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: spasm@ietf.org 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, 14 Mar 2017 14:49:05 -0000 On Mon, Mar 13, 2017 at 10:44:32AM -0400, Russ Housley wrote: > > On Mar 12, 2017, at 5:40 PM, Wei Chuang wrote: > > > > The latest draft 08 is up: > > > > https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-08 > > > > The diff is: > > > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-lamps-eai-addresses-08.txt > > > > This draft attempts to capture Viktor's name constraint verifier logic, > > and illustrate the examples in the diagrams. > > These changes were made in response to an IETF Last Call comment. Please > review them. The vast bulk of the changes are in Section 6. Please speak > promptly if you think this is the word technical solution. I think that while the new section 6 is technically on track, that it still needs a bit more effort to improve clarity. The design would be more clear if the rationale were stated clearly and concisely up-front. Therefore, after the second paragraph, I would like to see something along the lines of (please improve as needed): Some legacy actors (either CAs or relying parties) support only rfc822Name SANs and rfc822Name constraints. While limits on the new SmtpUTF8Name SANs will be expressed via new SmtpUTF8Name constraints defined in this document, these will not be generated or understood by the above legacy actors. When a legacy CA has only rfc822Name constraints, with the intent of limiting the scope of email addresses allowed in end-entity certificates it can issue, there would be a potential constraint bypass risk, if as a result all SmtpUTF8Name SANs were allowed to be used for lack of corresponding constraints. When a non-legacy CA has only SMTPUTF8Name constraints, with the intent of limiting the scope of allowed addresses to particular UTF8 forms, there is again a risk of bypass when a legacy relying party remains unaware of this intent. To avoid the above constraint bypass issues, we obligate SmtpUTF8Name-aware relying parties to disallow SmtpUTF8Name SANS in end-entity certificates whose chain includes (presumed) legacy CAs that have only rfc822Name constraints. Similarly, we obligate SmtpUTF8-aware CAs issuing constrained CA certificates, to also include sufficient rfc822Name constraints so that the set of email addresses acceptable in end-entity certificates is not unintentionally larger for legacy SmtpUTF8-unaware relying parties. I also think that the text below points 1--4 could be more clear. Instead of a single explosion of text that tries to explain all the diagrams, it is perhaps better to interleave the diagrams with corresponding explanatory text. Also there could be a better explanation of how to craft rfc822Name constraints to avoid constraint bypass against legacy relying parties. That is, the paragraph: If the issuer wishes to represent the name constraint asymmetrically, with either rfc822Name or SmtpUTF8Name to respectively represent some A-label or U-label in the domain or host, the alternate name constraint form must still be present. If nothing needs be represented by the alternate form, then empty name constraint can described by the "invalid" TLD that helps initialize the name constraint path validation set. Or alternatively it may be omitted if some other name constraint pair, provides a name constraint of that form. In particular this initialization may be needed when SmtpUTF8Name is used to represent an email address name constraint with an UTF-8 local-part and rfc822Name cannot represent such a email address constraint. may be too concise. With luck the suggested rationale additions may help readers figure out an appropriate strategy that meets the same goals, but this text could probably be improved. -- Viktor. From nobody Tue Mar 14 08:16:35 2017 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 72560129502 for ; Tue, 14 Mar 2017 08:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 M7qJoAQgXtIv for ; Tue, 14 Mar 2017 08:16:29 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 2752212965D for ; Tue, 14 Mar 2017 08:16:28 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id r45so58000448qte.3 for ; Tue, 14 Mar 2017 08:16:28 -0700 (PDT) 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=cqJVWWSJLPuBL6bR6GJa56KR8ITgLjlu2lbGBpReWTY=; b=MvCFdOOpaIxpy9pJNTob1GqB52/0Qwgbl6Io6BkM2enCBe3C90ufBkV5ErRMvtY+Uf fdqYktpsODgQePXxJ8cRj8xp0CJq8obLy3biORzTopgBC/cd8UAozr65jOnBE3/CIg3A evb1mmEiQ+FMdlGarGowoJHWHGZyVqSJQNq3c= 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=cqJVWWSJLPuBL6bR6GJa56KR8ITgLjlu2lbGBpReWTY=; b=GOELMbXiT9dfY8I+VvbvP8pOsod42ll8afdFDeQop7c195xIXDd84AYPXHibENrm4A ZvWcB7DeFBnMceHhBjvFUeOAVa39lLTMLowMTCmZ5DMQEyNsPslx5reJ15Wx6pBV7EoS TYq+iZEnaUG0ZMoHvoC1Q0xEyckOi4V4noShUcw3fc2m4IAqyiwypciFy+cjEWd9dcDz q2Utuc155hQ2FjiyD0AltC+aLpYNQ35q188yYnwoXt0LWYJenVIFVW773mleUja6+s5+ fORY3cXGUGmtv9rpugzGR5336qZedU1SJcKQrqRa7/GoxfPERfZ4anYbHQSpaon1k7Px 4FOg== X-Gm-Message-State: AMke39n30AAIn81D+ZXnSodJ5+AKdqry/bLmNFKAck0QrJA8v9Tyh+uqK0cnTDHt3s1Vww== X-Received: by 10.237.34.8 with SMTP id n8mr40529877qtc.98.1489504587154; Tue, 14 Mar 2017 08:16:27 -0700 (PDT) Received: from [172.16.0.18] ([96.231.228.203]) by smtp.gmail.com with ESMTPSA id j1sm14555584qkf.57.2017.03.14.08.16.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Mar 2017 08:16:26 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Sean Turner In-Reply-To: Date: Tue, 14 Mar 2017 11:16:23 -0400 Cc: Rich Salz , SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <3591C2E8-27D6-4F4E-86DC-546859742995@sn3rd.com> References: <7B492EB7-CC0D-4706-85AC-8844F5BCF847@vigilsec.com> <244b0812054a41598425c6cdbf511392@usma1ex-dag1mb1.msg.corp.akamai.com> <6d9976eb3fdd4bb2840a5d91ee66eec2@usma1ex-dag1mb1.msg.corp.akamai.com> <2CDB8533-CB33-484A-AAB2-FD8FD0CB8D74@vigilsec.com> <6FC056E9-C31E-4E49-B9D8-63DC19AD419A@sn3rd.com> To: Ryan Sleevi X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Spasm] An OCSP response extension X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.21 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, 14 Mar 2017 15:16:32 -0000 > On Mar 9, 2017, at 22:15, Ryan Sleevi wrote: >=20 >=20 >=20 > On Thu, Mar 9, 2017 at 9:13 PM, Sean Turner wrote: > If this is going to be get widely implemented should we look at = updating RFC5019 which says: > "The responder SHOULD NOT include responseExtensions=E2=80=9D? >=20 > How do you see "widely implemented=E2=80=9D? I naively was thinking along the =E2=80=9Cworldly=E2=80=9D level (aka = WebPKI). > I mentioned to Rich privately, but I think this is something that the = CA/Browser Forum should consider profiling out and expressly forbidding = for the time being, and if later ended up valuable (e.g. in the context = of must-staple certificates), would need to aggressively profile the = acceptable values suitable for the Web PKI. >=20 > In the context of other PKIs, however, I have no thought and = experience to inform on the value of that, which is why I was asking = about "widely implemented" - for example, if used by the FPKI or Grid = PKI, would that be "widely implemented"? If 5019 dropped the SHOULD NOT = for that reason, would the CA/B Forum need to profile it back in for the = Web PKI? So this is an interesting point and it=E2=80=99s kind of like when we = looked at profiling OCSP for STIR (i.e., getting cert status for = originators of digital signed SIP requests). The HA OCSP profile was = close to what we wanted so we use it as the base and then profiled stuff = in (in some case back in and in some cases new stuff in). If the HA = OCSP profile had an applicability statement, which really nobody was = doing back in the day, then it would be clear where it applied and where = it didn=E2=80=99t. I=E2=80=99m certainly not proposing anybody write up = an applicability statement because well different communities can = profile it as they see fit. The only wrinkle here is that some = communities are more hesitant than other to profile things back in = because they get push back about being =E2=80=9Cnon-standard,=E2=80=9D = but this might just have to go with the territory. spt= From nobody Tue Mar 14 08:23:52 2017 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 41491129470 for ; Tue, 14 Mar 2017 08:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 hi9JFsDynQ7J for ; Tue, 14 Mar 2017 08:23:49 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09A43128DF6 for ; Tue, 14 Mar 2017 08:23:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 247793004AE for ; Tue, 14 Mar 2017 11:23:48 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vskLZOWRN1_r for ; Tue, 14 Mar 2017 11:23:46 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id C9C2C30009D; Tue, 14 Mar 2017 11:23:46 -0400 (EDT) From: Russ Housley Message-Id: <80485F90-EDF8-42D7-A314-837E1358A121@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_256D5E88-B970-46AD-9EB2-975F1D7000C9" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 14 Mar 2017 11:23:49 -0400 In-Reply-To: <415CC5D7-5766-4A6D-9649-E8D9B7BF92D7@vigilsec.com> Cc: Sean Turner , SPASM To: Jim Schaad References: <531F42E9-E7B2-4A40-B373-F616A4076FC2@vigilsec.com> <0a1701d29971$25d620f0$718262d0$@augustcellars.com> <415CC5D7-5766-4A6D-9649-E8D9B7BF92D7@vigilsec.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-rfc5750-bis-02 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.21 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, 14 Mar 2017 15:23:50 -0000 --Apple-Mail=_256D5E88-B970-46AD-9EB2-975F1D7000C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > The reference would need to change to allow other curves, right? >=20 >>> For clarity, I think that we should change Section 4.3 as follows: >>>=20 >>> OLD >>> MUST- support RSA with SHA-256. >>> NEW >>> MUST- support RSA PKCS#1 v1.5 with SHA-256. >>>=20 >>> and >>>=20 >>> OLD >>> The following are the RSA and RSASSA-PSS key size =E2=80=A6 NEW >>> The following are the RSA PKCS#1 v1.5 and RSASSA-PSS key size ... >>=20 >> I am not sure about this. I think that if this is done then it needs = to be done on a much larger basis that what you have suggested here. I = worry about this. Would an additional terminology item added to = section 1.1 be sufficient? >=20 > Yes, that would be fine with me. It looks like you made the text changes in Section 4.3. The changes in = -03 resolve my comment. Russ --Apple-Mail=_256D5E88-B970-46AD-9EB2-975F1D7000C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
The reference would need to change to allow other curves, = right?

For clarity, I think that we should change Section 4.3 as = follows:

OLD
 MUST- = support RSA with SHA-256.
NEW
 MUST- = support RSA PKCS#1 v1.5 with SHA-256.

and

OLD
 The following are the = RSA and RSASSA-PSS key size =E2=80=A6 NEW
 The = following are the RSA PKCS#1 v1.5  and RSASSA-PSS key size ...

I am not sure about this.  I = think that if this is done then it needs to be done on a much larger = basis that what you have suggested here.  I worry about this. =  Would an additional terminology  item added to section 1.1 be = sufficient?

Yes, that would be fine with = me.

It = looks like you made the text changes in Section 4.3.  The changes = in -03 resolve my comment.

Russ

= --Apple-Mail=_256D5E88-B970-46AD-9EB2-975F1D7000C9-- From nobody Tue Mar 14 08:55:03 2017 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 DB4CB12EE46 for ; Tue, 14 Mar 2017 08:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 8Ql0bG1K7PBJ for ; Tue, 14 Mar 2017 08:55:00 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB78D129642 for ; Tue, 14 Mar 2017 08:55:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1CF1E3004AE for ; Tue, 14 Mar 2017 11:55:00 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6TgE3d6RaGVE for ; Tue, 14 Mar 2017 11:54:58 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id D3BF530009D; Tue, 14 Mar 2017 11:54:58 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Russ Housley In-Reply-To: Date: Tue, 14 Mar 2017 11:55:01 -0400 Cc: SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <38473133-587B-47FB-9B47-D79F456B966A@vigilsec.com> References: <2AFA0160-B45D-456E-A642-41863274A7EE@vigilsec.com> <95D2BAF0-EC51-4EFB-889C-C782C4A8FD3E@vigilsec.com> <0a1601d29970$f9d5a200$ed80e600$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [Spasm] WG Last Call for draft-ietf-lamps-rfc5751-bis-03 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.21 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, 14 Mar 2017 15:55:02 -0000 i want to confirm that version -04 resolves all of my comments, except = one. That one is being discussed on the thread that Jim started = yesterday. Russ > On Mar 10, 2017, at 9:48 AM, Russ Housley = wrote: >=20 >=20 >>> I have some WG Last Call comments on = draft-ietf-lamps-rfc5751-bis-03. I >>> have divided my comments into MAJOR and MINOR. >>>=20 >>>=20 >>> MAJOR >>>=20 >>> Do we need to define a way for smimeCapabilities to state support = for >>> AuthEnveloped? I=E2=80=99m trying to avoid interoperability = failures. >>=20 >> We have that. If you support an AEAD algorithm then you must support = AuthEnveloped by definition. >=20 > Sure. I think the document needs to be explicit on this point. >=20 >>> Section 2.1: I see no need to include the MUST for SHA-512 here = since none >>> of the algorithms in Section 2.2 use it. >>=20 >> This is to get a match for EdDSA w/ curve 25519. That uses SHA-512 = internally so that the correct match would be to use SHA-512 for the = external as well. >=20 > Okay. This one is resolved. >=20 >>> Section 2.7.1.2: I worry about backward compatibility here. This = requires a >>> capability that has never been used in S/MIME before, so it seems = premature >>> to use AES-GCM when the capabilities of the recipient are unknown. = Instead, >>> I would argue that AES-256 CBC offers implementers so time to deploy >>> authenticated encryption. This looks like a fine thing for S/MIME = 4.1 in a >>> couple of years. >>=20 >> This has been the traditional wording over the last three versions of = the document. Only for 3851 was it clear that the algorithm existed as = a possibility prior to the version being released. The group has = normally recommended using the best algorithm here but permitted to use = of a different algorithm. I think there is sufficient guidance in the = text about why GCM was chosen and it allows for either it or AES-128 CBC = to be used. >=20 > Since a new content type is involved, not just a new algorithm, I am = advocating a slower transition. I=E2=80=99d love to hear from others. = Am I being too conservative? >=20 >>> Section 5.1: The S/MIME WG is closed. Would it be better to change = the >>> contact to the IESG? >>=20 >> I thought about this and did not do it, but yes it makes sense. I = wonder how many people have used the contact, but as I am not on this = alias I would not know.=20 >=20 > Let=E2=80=99 make it the IESG. >=20 > Russ >=20 From nobody Wed Mar 15 07:46:59 2017 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 329CC1315B8 for ; Wed, 15 Mar 2017 07:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.294 X-Spam-Level: X-Spam-Status: No, score=-4.294 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 y1cp3HC3UIYf for ; Wed, 15 Mar 2017 07:46:55 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 898D21315BB for ; Wed, 15 Mar 2017 07:46:55 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 11ADD20051C26 for ; Wed, 15 Mar 2017 07:46:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=ui92KfIXM0E5iWnocnymxLdSgZk=; b= PS45row3e8PYCX/UMNEAzC7oVDPC30pAb4ZF89GPtafkcxrj2bzp6Z7QcL4Dc0qA 6B497PLN6FiY5gaRaJG9AuCYzxtKRuTxDiTG1g2wz3Ezr0xrXiMWp8Y54kN9Ck5I QOi02qSWtRYSjTWGzResfK73k90hDjw90nieiy5TPek= Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com [209.85.215.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id D64A220051C23 for ; Wed, 15 Mar 2017 07:46:54 -0700 (PDT) Received: by mail-lf0-f53.google.com with SMTP id z15so7952688lfd.1 for ; Wed, 15 Mar 2017 07:46:54 -0700 (PDT) X-Gm-Message-State: AFeK/H3Dk6rM27s5BuaKqZmE58Flm+oiBat2Yx4FYRjgdjhnwqCME/lmhqsuD0o/kqEh4Ms1My4M5AwXxeCISw== X-Received: by 10.25.171.9 with SMTP id u9mr1120153lfe.151.1489589212937; Wed, 15 Mar 2017 07:46:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.193.197 with HTTP; Wed, 15 Mar 2017 07:46:52 -0700 (PDT) In-Reply-To: <7129a939-35f1-f55b-703b-9f39f6110520@eff.org> References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> <20170311201904.GQ7733@mournblade.imrryr.org> <389a248f-37e4-9ff7-b330-b840e7c47931@eff.org> <0d7afa83-a9d7-f977-ca36-533fc13b720e@eff.org> <7129a939-35f1-f55b-703b-9f39f6110520@eff.org> From: Ryan Sleevi Date: Wed, 15 Mar 2017 10:46:52 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Jacob Hoffman-Andrews Cc: Ryan Sleevi , Patrick Donahue , Gervase Markham , "Salz, Rich" , Peter Bowen , "spasm@ietf.org" , Rob Stradling , Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=94eb2c1cc5e6e6082d054ac60399 Archived-At: Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 15 Mar 2017 14:46:57 -0000 --94eb2c1cc5e6e6082d054ac60399 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 12, 2017 at 7:53 PM, Jacob Hoffman-Andrews wrote: > > 1. Policy set by user-facing domain owner for their own hostnames. > > 2. Blanket policy set by CDN for hostnames they operate on their > customers' behalf. > > 3. Policy set by CDN for their own hostnames, which share the same > base domain as the CNAME targets used in (2). > > So, back to the subjective evaluation: Now it's clear that the CDN in our > scenario is the only one who can add CAA records. If a customer wants (1) > they need cooperation from their CDN, and the CDN needs to implement a > trampoline no matter what. > > *In the non-tree-climbing world* > > If a CDN wants to implement (3), they put in place a single CAA record and > it doesn't impact (1) or (2). If the CDN wants to implement (1) or (2), > they put in a CAA record at each of their CNAME targets. Neither policy > affects the other in any way, assuming that CNAME targets are never base > domains. > > *In the tree-climbing world* > > If a CDN wants to implement (3), they have to carefully understand CAA and > be sure to add a separate "any" record to each of their CNAME targets. They > also have to make sure to copy that CAA record to any new CNAME targets > they create. > > I argue that this is less intuitive and more difficult than in the > tree-climbing world. > Agreed. I think the lack of 'client' override - and apologies for my own ignorance here, as I couldn't find where the exclusivity was stated that ONLY a CNAME record may exist - is a pretty compelling argument against the tree climbing. While I disagree with some of the points below, I think this is the key argument about why recursion-into-CNAME-and-tree-climb may not be desirable - because it affords less control in the default configuration, and makes it easier to misconfigure. > More difficult, because it requires deploying extra CAA records to express > a straightforward policy. Less intuitive, because most DNS-using > applications don't care about the hostnames that are part of a CNAME chain, > only the "final value" received from a recursive resolver. For instance, > when looking up an A record, Chrome doesn't care about the CNAME aliases in > between, only the final A record. > As an argument, I think this is unnecessary/unrelated, right? As in, you can look up the existence *of* a CNAME record without transiting that CNAME record. Put differently, and perhaps selfishly, it's "just" DNS :) > Also, as a concrete example of the non-intuitiveness, Rob (one of the CAA > authors) mentioned on the CA/Browser Forum list that he has had to > double-check the lookup algorithm with Phill, his co-author. > I don't know how well this as an argument works. It's been nearly four years since CAA was published before CAs got around to using it, nearly seven years since it was first proposed, and the algorithm went through several substantive revisions as part of the process :) I would say it's reasonable to expect the people most involved and invested in it to have a lot more mental state to sort through as to where "the process" finally ended up ;) > I've also been confused by the CAA lookup algorithm, as have my coworkers. > I can't speak for Rob, but for me a big part of the confusion has been the > fact that tree-climbing seems like an anomaly in the DNS world. > Perhaps in the DNS world, but it's SOP for the Certificate Authority world. Consider the act of validating using approved email addresses - or validating the 'registerable' domain. Both of these algorithms start with an FQDN and then climb the tree until they are able to establish an authortative link, and then everything below that tree is accepted as validated. --94eb2c1cc5e6e6082d054ac60399 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 12, 2017 at 7:53 PM, Jacob Hoffman-Andrews <jsha@eff.org>= ; wrote:
=20 =20 =20
> 1. Policy set by user-facing domain owner for their own hostnames.
> 2. Blanket policy set by CDN for hostnames they operate on their
customers' behalf.
> 3. Policy set by CDN for their own hostnames, which share the same
base domain as the CNAME targets used in (2).

So, back to the subjective evaluation: Now it's clear= that the CDN in our scenario is the only one who can add CAA records. If a customer wants (1) they need cooperation from their CDN, and the CDN needs to implement a trampoline no matter what.

In the non-tree-climbing world

If a CDN wants to implement (3), they put in place a single CAA record and it doesn't impact (1) or (2). If the CDN wants to implement (1) or (2), they put in a CAA record at each of their CNAME targets. Neither policy affects the other in any way, assuming that CNAME targets are never base domains.

In the tree-climbing world

If a CDN wants to implement (3), they have to carefully understand CAA and be sure to add a separate "any" record to each of the= ir CNAME targets. They also have to make sure to copy that CAA record to any new CNAME targets they create.

I argue that this is less intuitive and more difficult than in the tree-climbing world.

Agreed. I t= hink the lack of 'client' override - and apologies for my own ignor= ance here, as I couldn't find where the exclusivity was stated that ONL= Y a CNAME record may exist - is a pretty compelling argument against the tr= ee climbing.

While I disagree with some of the poi= nts below, I think this is the key argument about why recursion-into-CNAME-= and-tree-climb may not be desirable - because it affords less control in th= e default configuration, and makes it easier to misconfigure.
=C2= =A0
More difficult, because it requires deploying extra CAA records to express a straightforward policy. Less intuitive, because most DNS-using applications don't care about the hostnames that are part of a CNAME chain, only the "final value&qu= ot; received from a recursive resolver. For instance, when looking up an A record, Chrome doesn't care about the CNAME aliases in between, only the final A record.

As a= n argument, I think this is unnecessary/unrelated, right? As in, you can lo= ok up the existence *of* a CNAME record without transiting that CNAME recor= d. Put differently, and perhaps selfishly, it's "just" DNS :)=
=C2=A0
Also, as a concrete example of the non-intuitiveness, Rob (one of the CAA authors) mentioned on the CA/Browser Forum list that he has had to double-check the lookup algorithm with Phill, his co-author.

I don't know how well this as an= argument works. It's been nearly four years since CAA was published be= fore CAs got around to using it, nearly seven years since it was first prop= osed, and the algorithm went through several substantive revisions as part = of the process :) I would say it's reasonable to expect the people most= involved and invested in it to have a lot more mental state to sort throug= h as to where "the process" finally ended up ;)
=C2=A0<= /div>
I've also been confused by the CAA lookup algorithm, as have my coworkers. I can't speak for Rob, but for me a big part of the confusion has been the fact that tree-climbing seems like an anomaly in the DNS world.

Perhaps in the DNS = world, but it's SOP for the Certificate Authority world. Consider the a= ct of validating using approved email addresses - or validating the 're= gisterable' domain. Both of these algorithms start with an FQDN and the= n climb the tree until they are able to establish an authortative link, and= then everything below that tree is accepted as validated.
--94eb2c1cc5e6e6082d054ac60399-- From nobody Wed Mar 15 07:57:41 2017 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 EB75A1315DB for ; Wed, 15 Mar 2017 07:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZoPUEHhfctJ for ; Wed, 15 Mar 2017 07:57:38 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id AD4F21315C7 for ; Wed, 15 Mar 2017 07:57:38 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2A66E496C26; Wed, 15 Mar 2017 14:57:38 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 13FCF496C17; Wed, 15 Mar 2017 14:57:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1489589858; bh=xbzJ3OgIZBK6z47U9uiubvCH1Q02r/5/G9nP2/T6664=; l=786; h=From:To:CC:Date:References:In-Reply-To:From; b=McN4eqlhpVAvUtKUZbd9jVfyYd6BOOCmg74h0V66+LAi8FFTJivXQtsuxlkPfNPpX 4jrK5T0iLGgxxA5H7K7p5aaHZEfWiHTsH6ZJg5lSCj55Xvq7I4BUyMI8E2TuR/YZH4 B4A0nlc27QzF5WOmQDzUsUDEo9raNSnwcCTyj5XY= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id EDDC41E07C; Wed, 15 Mar 2017 14:57:37 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 15 Mar 2017 10:57:37 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Wed, 15 Mar 2017 10:57:37 -0400 From: "Salz, Rich" To: Ryan Sleevi , Jacob Hoffman-Andrews CC: Patrick Donahue , Gervase Markham , Peter Bowen , "spasm@ietf.org" , Rob Stradling , Phillip Hallam-Baker Thread-Topic: [Spasm] CAA erratum 4515 Thread-Index: AQHSmRCCM7EZ0a0WGUaDqFWlZ2kYcqGNSw4AgAAJEYCAAU3mgIABySAA///q7WCAAXF9gIAAGH0AgAAEKICAADfTgIAADLSAgAQeKQD//76PgA== Date: Wed, 15 Mar 2017 14:57:36 +0000 Message-ID: References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> <20170311201904.GQ7733@mournblade.imrryr.org> <389a248f-37e4-9ff7-b330-b840e7c47931@eff.org> <0d7afa83-a9d7-f977-ca36-533fc13b720e@eff.org> <7129a939-35f1-f55b-703b-9f39f6110520@eff.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.15] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 15 Mar 2017 14:57:40 -0000 PiBJIGFyZ3VlIHRoYXQgdGhpcyBpcyBsZXNzIGludHVpdGl2ZSBhbmQgbW9yZSBkaWZmaWN1bHQg dGhhbiBpbiB0aGUgdHJlZS1jbGltYmluZyB3b3JsZC4gDQoNCkRpZCB5b3UgbWVhbiAidGhhbiBp biB0aGUgKm5vbiogdHJlZS1jbGltYmluZyB3b3JsZD8NCg0KPiBhbmQgYXBvbG9naWVzIGZvciBt eSBvd24gaWdub3JhbmNlIGhlcmUsIGFzIEkgY291bGRuJ3QgZmluZCB3aGVyZSB0aGUgZXhjbHVz aXZpdHkgd2FzIHN0YXRlZCB0aGF0IE9OTFkgYSBDTkFNRSByZWNvcmQgbWF5IGV4aXN0IC0gaXMg YSBwcmV0dHkgY29tcGVsbGluZyBhcmd1bWVudCBhZ2FpbnN0IHRoZSB0cmVlIGNsaW1iaW5nLg0K DQpTZWMgMTAuMSBvZiBSRkMgMjE4MSwgd2hpY2ggY2xhcmlmaWVzIDMuNi4yIG9mIFJGQyAxMDM0 IHNheXMgKGV4Y2VycHQpOg0KICAgQW4gYWxpYXMgbmFtZSAobGFiZWwgb2YgYSBDTkFNRSByZWNv cmQpIG1heSwNCiAgIGlmIEROU1NFQyBpcyBpbiB1c2UsIGhhdmUgU0lHLCBOWFQsIGFuZCBLRVkg UlJzLCBidXQgbWF5IGhhdmUgbm8NCiAgIG90aGVyIGRhdGEuDQoNCkhvcGUgdGhpcyBoZWxwcy4N Cg== From nobody Wed Mar 15 10:17:49 2017 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 6F9F8131721 for ; Wed, 15 Mar 2017 10:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.798 X-Spam-Level: X-Spam-Status: No, score=-9.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.796, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=eff.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 VVLmn0rMldQ9 for ; Wed, 15 Mar 2017 10:17:45 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B47C13172B for ; Wed, 15 Mar 2017 10:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=bYwBs2x6CWc/uI11vuQKdYUaLYFMOVETa7Z5Xhfm8tg=; b=DXaZoNkgrdqc58ah48N8gl4tkpPmULruGL2+h46ysFtl/oTsax2a3dCP5Xgmddh4VL8KiJc9s7Sb4D3IOEBTNvnucTAjvOrGZ+7squNZDk5unbXCRvP79P8lNBqdDFe7twvTYdQ3j2OYeJmEtYDTpIqZbj8wp39PrG1SPrHViyk=; Received: ; Wed, 15 Mar 2017 10:17:44 -0700 To: "Salz, Rich" , Ryan Sleevi References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> <20170311201904.GQ7733@mournblade.imrryr.org> <389a248f-37e4-9ff7-b330-b840e7c47931@eff.org> <0d7afa83-a9d7-f977-ca36-533fc13b720e@eff.org> <7129a939-35f1-f55b-703b-9f39f6110520@eff.org> Cc: Patrick Donahue , Gervase Markham , Peter Bowen , "spasm@ietf.org" , Rob Stradling , Phillip Hallam-Baker From: Jacob Hoffman-Andrews Message-ID: Date: Wed, 15 Mar 2017 10:17:38 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F9178EAEBC982B3F4BFE8C0F" Received-SPF: skipped for local relay Archived-At: Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 15 Mar 2017 17:17:47 -0000 This is a multi-part message in MIME format. --------------F9178EAEBC982B3F4BFE8C0F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/15/2017 07:46 AM, Ryan Sleevi wrote: > Agreed. I think the lack of 'client' override - and apologies for my > own ignorance here, as I couldn't find where the exclusivity was > stated that ONLY a CNAME record may exist - is a pretty compelling > argument against the tree climbing. > > While I disagree with some of the points below, I think this is the > key argument about why recursion-into-CNAME-and-tree-climb may not be > desirable - because it affords less control in the default > configuration, and makes it easier to misconfigure. Great. So should I take it that you are now in support of revising the RFC to specify non-tree-climbing behavior? > As an argument, I think this is unnecessary/unrelated, right? As in, > you can look up the existence *of* a CNAME record without transiting > that CNAME record. Put differently, and perhaps selfishly, it's "just" > DNS :) Ultimately, as long as we agree, I'm not too concerned about which argument carried the day. For me, the argument about being "intuitive" or "similar to other DNS operations" is important for the same reason you cite above: I think doing otherwise makes it easier to misconfigure. > Perhaps in the DNS world, but it's SOP for the Certificate Authority > world. Consider the act of validating using approved email addresses - > or validating the 'registerable' domain. Both of these algorithms > start with an FQDN and then climb the tree until they are able to > establish an authortative link, and then everything below that tree is > accepted as validated. Yes, but Certificate Authorities certainly don't tree-climb on CNAME targets, which is what this conversation is about. On 03/15/2017 07:57 AM, Salz, Rich wrote: >> I argue that this is less intuitive and more difficult than in the tre= e-climbing world.=20 > Did you mean "than in the *non* tree-climbing world? Yep, thanks for spotting that. --------------F9178EAEBC982B3F4BFE8C0F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 03/15/2017 07:46 AM, Ryan Sleevi wrote:
Agreed. I think the lack of 'client' override - and apologies for my own ignorance here, as I couldn't find where the exclusivity was stated that ONLY a CNAME record may exist - is a pretty compelling argument against the tree climbing.

While I disagree with some of the points below, I think this is the key argument about why recursion-into-CNAME-and-tree-climb may not be desirable - because it affords less control in the default configuration, and makes it easier to misconfigure.
Great. So should I take it that you are now in support of revising the RFC to specify non-tree-climbing behavior?

As an argument, I think this is unnecessary/unrelated, right? As in, you can look up the existence *of* a CNAME record without transiting that CNAME record. Put differently, and perhaps selfishly, it's "just" DNS :)
Ultimately, as long as we agree, I'm not too concerned about which argument carried the day. For me, the argument about being "intuitive" or "similar to other DNS operations" is important for the same reason you cite above: I think doing otherwise makes it easier to misconfigure.

Perhaps in the DNS world, but it's SOP for the Certificate Authority world. Consider the act of validating using approved email addresses - or validating the 'registerable' domain. Both of these algorithms start with an FQDN and then climb the tree until they are able to establish an authortative link, and then everything below that tree is accepted as validated.
Yes, but Certificate Authorities certainly don't tree-climb on CNAME targets, which is what this conversation is about.


On 03/15/2017 07:57 AM, Salz, Rich wrote:
I argue that this is less intuitive and more difficult than in the tree-climbing world. 

Did you mean "than in the *non* tree-climbing world?
Yep, thanks for spotting that.
--------------F9178EAEBC982B3F4BFE8C0F-- From nobody Wed Mar 15 14:09:50 2017 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 6E8D113184C for ; Wed, 15 Mar 2017 14:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01, UNPARSEABLE_RELAY=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 sxb6ibO_1BU3 for ; Wed, 15 Mar 2017 14:09:43 -0700 (PDT) Received: from rmdccgokm1.reyn.mcr.dc.comodo.net (sgomail.comodogroup.com [IPv6:2a02:1788:402:430::9708:41f4]) (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 64CB7131848 for ; Wed, 15 Mar 2017 14:09:43 -0700 (PDT) Received: (korumail 23336 invoked from network); 15 Mar 2017 21:09:40 -0000 Received: from unknown (HELO maileu.comodo.net) () by 0 with SMTP; 15 Mar 2017 21:09:40 -0000 Received: from [192.168.0.58] ([192.168.0.58]) by maileu.comodo.net (IceWarp 11.4.5.0 DEB8 x64) with ASMTP (SSL) id 201703152109380826; Wed, 15 Mar 2017 21:09:38 +0000 To: Ryan Sleevi , Jacob Hoffman-Andrews References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> <20170311201904.GQ7733@mournblade.imrryr.org> <389a248f-37e4-9ff7-b330-b840e7c47931@eff.org> <0d7afa83-a9d7-f977-ca36-533fc13b720e@eff.org> <7129a939-35f1-f55b-703b-9f39f6110520@eff.org> Cc: Patrick Donahue , Gervase Markham , "Salz, Rich" , Peter Bowen , "spasm@ietf.org" , Phillip Hallam-Baker From: Rob Stradling Message-ID: <158147fc-a40b-9015-7e62-d4ada29eb6a8@comodo.com> Date: Wed, 15 Mar 2017 21:09:37 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: X-SMTP-Filter: Korumail SMTP Filter Engine Korumail 6.5 X-KORUMAIL-Result: Clean (Content eval: 0.000000 points) X-KORUMAIL-Reason: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 15 Mar 2017 21:09:47 -0000 On 15/03/17 14:46, Ryan Sleevi wrote: > Also, as a concrete example of the non-intuitiveness, Rob (one of > the CAA authors) mentioned on the CA/Browser Forum list that he has > had to double-check the lookup algorithm with Phill, his co-author. > > > I don't know how well this as an argument works. It's been nearly four > years since CAA was published before CAs got around to using it, nearly > seven years since it was first proposed, and the algorithm went through > several substantive revisions as part of the process :) I would say it's > reasonable to expect the people most involved and invested in it to have > a lot more mental state to sort through as to where "the process" > finally ended up ;) > > > I've also been confused by the CAA lookup algorithm, as have my > coworkers. I can't speak for Rob, but for me a big part of the > confusion has been the fact that tree-climbing seems like an anomaly > in the DNS world. > > > Perhaps in the DNS world, but it's SOP for the Certificate Authority > world. Consider the act of validating using approved email addresses - > or validating the 'registerable' domain. Both of these algorithms start > with an FQDN and then climb the tree until they are able to establish an > authortative link, and then everything below that tree is accepted as > validated. The DNS world is not my natural habitat. ;-) I don't think I had much additional mental state to sort through when I came to implement CAA for Comodo. I read RFC6844 section 4, and then I re-read it numerous times, but I could not determine with certainty whether or not I should tree climb after following a CNAME. So I sought clarification from Phill, since he was the primary author. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Thu Mar 16 16:23:54 2017 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 6F543129B59 for ; Thu, 16 Mar 2017 16:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.295 X-Spam-Level: X-Spam-Status: No, score=-4.295 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 tKpLhZT5FhvU for ; Thu, 16 Mar 2017 16:23:51 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 075E3129A9B for ; Thu, 16 Mar 2017 16:23:51 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id A032A30002724 for ; Thu, 16 Mar 2017 16:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=77wEXsXEtQlw3RcUlTHK9gNuLnU=; b= BCEUjgkofnLpX2Fb9b4XHw42fz4dmeahrrjDj37xbSM8EC5pYcZSyj52Gebw6I9l ZyADbjrj7Zo7nqYUSFGuo58ypJChT0OGayu5R3+7SpM0Rotpq80K1hTaRYGBK6QB MUTAzoXuJeCLm0MThlLPFOkwIPfOuf5mpzseKFlFzf4= Received: from mail-lf0-f47.google.com (mail-lf0-f47.google.com [209.85.215.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPSA id 740D43000271F for ; Thu, 16 Mar 2017 16:23:50 -0700 (PDT) Received: by mail-lf0-f47.google.com with SMTP id a6so26677732lfa.0 for ; Thu, 16 Mar 2017 16:23:50 -0700 (PDT) X-Gm-Message-State: AFeK/H0Vs9CUy1lbrqym42QRT6cuOUmwgG1A0TkpxFvMH7lBBAvgIDYQyV3LxvNuwBMpE2gTUwU1CJMxucW6Mg== X-Received: by 10.25.204.9 with SMTP id c9mr3108678lfg.107.1489706628658; Thu, 16 Mar 2017 16:23:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.193.197 with HTTP; Thu, 16 Mar 2017 16:23:47 -0700 (PDT) In-Reply-To: References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> <20170311201904.GQ7733@mournblade.imrryr.org> <389a248f-37e4-9ff7-b330-b840e7c47931@eff.org> <0d7afa83-a9d7-f977-ca36-533fc13b720e@eff.org> <7129a939-35f1-f55b-703b-9f39f6110520@eff.org> From: Ryan Sleevi Date: Thu, 16 Mar 2017 19:23:47 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Jacob Hoffman-Andrews Cc: "Salz, Rich" , Ryan Sleevi , Patrick Donahue , Gervase Markham , Rob Stradling , Peter Bowen , "spasm@ietf.org" , Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=94eb2c1a1c826bc01e054ae15a6a Archived-At: Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 16 Mar 2017 23:23:52 -0000 --94eb2c1a1c826bc01e054ae15a6a Content-Type: text/plain; charset=UTF-8 On Wed, Mar 15, 2017 at 1:17 PM, Jacob Hoffman-Andrews wrote: > On 03/15/2017 07:46 AM, Ryan Sleevi wrote: > > Agreed. I think the lack of 'client' override - and apologies for my own > ignorance here, as I couldn't find where the exclusivity was stated that > ONLY a CNAME record may exist - is a pretty compelling argument against the > tree climbing. > > While I disagree with some of the points below, I think this is the key > argument about why recursion-into-CNAME-and-tree-climb may not be > desirable - because it affords less control in the default configuration, > and makes it easier to misconfigure. > > Great. So should I take it that you are now in support of revising the RFC > to specify non-tree-climbing behavior? > Yeah, I think the issues related to expressing policies highlight why tree-climbing is probably not desirable for actual CAA deployment. --94eb2c1a1c826bc01e054ae15a6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 15, 2017 at 1:17 PM, Jacob Hoffman-Andrews <jsha@eff.org>= ; wrote:
=20 =20 =20
On 03/15/2017 07:46 AM, Ryan Sleevi wrote:
Agreed. I think the lack of 'client' overrid= e - and apologies for my own ignorance here, as I couldn't find where the exclusivity was stated that ONLY a CNAME record may exist - is a pretty compelling argument against the tree climbing.

While I disagree with some of the points below, I think this is the key argument about why recursion-into-CNAME-and-tree-climb may not be desirable= - because it affords less control in the default configuration, and makes it easier to misconfigure.
 Great. So should I take it that you are now in support of revising the RFC to specify non-tree-climbing behavior?
<= br>
Yeah, I think the issues related to expressing policies highl= ight why tree-climbing is probably not desirable for actual CAA deployment.=
--94eb2c1a1c826bc01e054ae15a6a-- From nobody Thu Mar 16 16:50:53 2017 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 0FB7712971E for ; Thu, 16 Mar 2017 16:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 7AHHKyWgUmLo for ; Thu, 16 Mar 2017 16:50:51 -0700 (PDT) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (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 CFDD6129717 for ; Thu, 16 Mar 2017 16:50:51 -0700 (PDT) Received: by mail-ot0-x236.google.com with SMTP id a12so4824904ota.0 for ; Thu, 16 Mar 2017 16:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6u157xNC6NCDQloA1zoA1etMV/qjUDE2N4V8y/K2yG0=; b=H39xSSMvexMKO3heTLGAtgts5ZsLo7fbqIjQWkODSF/iPMmhhHQ19S2LTYJvacPndU g7EPj/ZZApCGvQ2qP6MXFcNbIkrIqjy2kJb5ViA2VdDcqo8Z7XwYrQaOrrfssBxWmuXt pl7Jvq2Z6OK10fJ+AYk0fLZkedP18vxjqN13NRyGSlJseYXTIv6hYjclzuJ55Ci21EdC REfspSXS8qb6oPINSvGi6fLGQUx3JVc4uAfOls6bMn7oUzCnGFkKAqT5zY1vC/VXHlvE 3Z18BBbIBfPwtia0gvX28RHOhD5nCA/iEgxcmPupQ65f/6YlLHH7UQrUzacTS7AgS4Yc IeVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=6u157xNC6NCDQloA1zoA1etMV/qjUDE2N4V8y/K2yG0=; b=bCJiSRuHq2TyGDg+9QTbKgbpbqj7u9JiwvWjIvFOX4yLBP29zYqzqwPCOEL1kfxNSi TH6sxHef2q9U+XJh6zEek3B+EpVTS0Dso2ksYpEflWtqN4XhpqTRms3hnh+YDHVA1BXc MUjAnZk1fooFJ3Qcmmp5gLTKgq7ziDxMoKayn9m/VFWK5O3bskP6eFdYSv+W8MDN/1yO HIlWBVKXcXlv7zd1hyx6TdXWl5mDLEbxPVYgRRgdk9RSMQP045HP/8j+vb7Z23yabcph 3Fbh/MlZ6MPOQgrHJJa1dV/uPLg/hwHI8qLEooXZXF4YFXj2zJ5M+H5i4m9zUeV+5B6S SNdg== X-Gm-Message-State: AFeK/H3xEb6ss2HTy1WPBTm7VoLITEdCF0p67R6ALhBlVcyT7MbWwgu5b6efx2LB2lJZRogtBmrhIHUpzHzUeQ== X-Received: by 10.202.79.18 with SMTP id d18mr6392678oib.9.1489708251201; Thu, 16 Mar 2017 16:50:51 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.14.123 with HTTP; Thu, 16 Mar 2017 16:50:50 -0700 (PDT) In-Reply-To: References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> <20170311201904.GQ7733@mournblade.imrryr.org> <389a248f-37e4-9ff7-b330-b840e7c47931@eff.org> <0d7afa83-a9d7-f977-ca36-533fc13b720e@eff.org> <7129a939-35f1-f55b-703b-9f39f6110520@eff.org> From: Phillip Hallam-Baker Date: Thu, 16 Mar 2017 19:50:50 -0400 X-Google-Sender-Auth: FRe1D55LVkEVMFKjhPJqdGbLuNo Message-ID: To: Ryan Sleevi Cc: Jacob Hoffman-Andrews , "Salz, Rich" , Patrick Donahue , Gervase Markham , Rob Stradling , Peter Bowen , "spasm@ietf.org" Content-Type: multipart/alternative; boundary=001a113d85c421c62c054ae1bbf2 Archived-At: Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 16 Mar 2017 23:50:53 -0000 --001a113d85c421c62c054ae1bbf2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 16, 2017 at 7:23 PM, Ryan Sleevi wrote: > > > On Wed, Mar 15, 2017 at 1:17 PM, Jacob Hoffman-Andrews > wrote: > >> On 03/15/2017 07:46 AM, Ryan Sleevi wrote: >> >> Agreed. I think the lack of 'client' override - and apologies for my own >> ignorance here, as I couldn't find where the exclusivity was stated that >> ONLY a CNAME record may exist - is a pretty compelling argument against = the >> tree climbing. >> >> While I disagree with some of the points below, I think this is the key >> argument about why recursion-into-CNAME-and-tree-climb may not be >> desirable - because it affords less control in the default configuration= , >> and makes it easier to misconfigure. >> >> Great. So should I take it that you are now in support of revising the >> RFC to specify non-tree-climbing behavior? >> > > Yeah, I think the issues related to expressing policies highlight why > tree-climbing is probably not desirable for actual CAA deployment. > =E2=80=8BYou mean tree climbing or tree climbing on CNAME? If the second, I concur. --001a113d85c421c62c054ae1bbf2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Ma= r 16, 2017 at 7:23 PM, Ryan Sleevi <ryan-ietf@sleevi.com>= wrote:


On Wed, Ma= r 15, 2017 at 1:17 PM, Jacob Hoffman-Andrews <jsha@eff.org> wrot= e:
=20 =20 =20
On 03/15/2017 07:46 AM, Ryan Sleevi wrote:
Agreed. I think the lack of 'client' overrid= e - and apologies for my own ignorance here, as I couldn't find where the exclusivity was stated that ONLY a CNAME record may exist - is a pretty compelling argument against the tree climbing.

While I disagree with some of the points below, I think this is the key argument about why recursion-into-CNAME-and-tree-climb may not be desirable= - because it affords less control in the default configuration, and makes it easier to misconfigure.
 Great. So should I take it that you are now in support of revising the RFC to specify non-tree-climbing behavior?
<= br>
Yeah, I think the issues related to expressing policie= s highlight why tree-climbing is probably not desirable for actual CAA depl= oyment.

=E2=80=8BYou mean tree climbing or tree= climbing on CNAME?

If th= e second, I concur.


<= /div>
--001a113d85c421c62c054ae1bbf2-- From nobody Thu Mar 16 17:20:59 2017 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 D96A1129B6F for ; Thu, 16 Mar 2017 17:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.798 X-Spam-Level: X-Spam-Status: No, score=-9.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.796, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=eff.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 xged3hIF6s2t for ; Thu, 16 Mar 2017 17:20:55 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6EA7129A54 for ; Thu, 16 Mar 2017 17:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=Yx3NV1L5talqyKH3PGe7A9BmB8RiWF0yh3lpMEoembc=; b=0fO5H/89hKdq+QdCGRAz6/PeGn72FBEvouihbEZSfFdsYwkD4LaVKLz2/fIJOqdT/GJpCIphEEw/f9jc51vkNL4M6H9LqshzOoQfcud5U/6WULAaR8BngeHQW/I6ChfCxhqY9ZiHGyAXCkGW5tMG0sACQpqlkiBxWFCfDMfDh88=; Received: ; Thu, 16 Mar 2017 17:20:57 -0700 To: Phillip Hallam-Baker , Ryan Sleevi References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> <20170311201904.GQ7733@mournblade.imrryr.org> <389a248f-37e4-9ff7-b330-b840e7c47931@eff.org> <0d7afa83-a9d7-f977-ca36-533fc13b720e@eff.org> <7129a939-35f1-f55b-703b-9f39f6110520@eff.org> Cc: Patrick Donahue , Gervase Markham , "Salz, Rich" , Peter Bowen , "spasm@ietf.org" , Rob Stradling From: Jacob Hoffman-Andrews Message-ID: <269e5cb2-41f9-2605-759c-2478d816e591@eff.org> Date: Thu, 16 Mar 2017 17:20:54 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DC9EB82DFAD3A63758D4ED1D" Received-SPF: skipped for local relay Archived-At: Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 17 Mar 2017 00:20:57 -0000 This is a multi-part message in MIME format. --------------DC9EB82DFAD3A63758D4ED1D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit > ​You mean tree climbing or tree climbing on CNAME? > > If the second, I concur. Yep, we've been using "tree climbing" as shorthand for "tree climbing on CNAME." --------------DC9EB82DFAD3A63758D4ED1D Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
​You mean tree climbing or tree climbing on CNAME?

If the second, I concur.
Yep, we've been using "tree climbing" as shorthand for "tree climbing on CNAME."
--------------DC9EB82DFAD3A63758D4ED1D-- From nobody Fri Mar 17 07:39:45 2017 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 72B2F129450 for ; Fri, 17 Mar 2017 07:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 W5EmFaqxosqj for ; Fri, 17 Mar 2017 07:39:42 -0700 (PDT) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (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 2ACC1128B44 for ; Fri, 17 Mar 2017 07:39:42 -0700 (PDT) Received: by mail-ot0-x235.google.com with SMTP id o24so92842200otb.1 for ; Fri, 17 Mar 2017 07:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=fF+ATgyARX12OCzE68WDGGRbo8ijjOfh7pkej10aSCk=; b=tZCEZy79tQwqflK2BUJXCmkYHm3Hp3a4ujjbppEQUXlKO0d5rAhx4K/uwTSmsKnlea dDnhDtk5QVmVA3XFUhFXrFmNUssDLbwI4JsLtnXMJF8/OSyDuG0P9dcNSxgyO4B57vlh r5J4tdfSRB56Wd/RiSc2LNGR6RNHagA5Hn/aX+DZ0/PgvzLl4t39ICM8JIiMslT40z7Q S1wBCVsEEabErCQ+kxkiKNwDSUeeQT2MKefN23fGWFmQMHBN8q7bT1F9X7RVmrdnc0pP pvQM1onwRo51tG1AF/qf25t3wyavDhmQ/EeeHlVMpqXd2jGUgsCQ2tMgYq0rVXELclcp td6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=fF+ATgyARX12OCzE68WDGGRbo8ijjOfh7pkej10aSCk=; b=GiF+Hp0z7Nvpm9UpzrHgAC0g128MfbBayneRuOT+C4OaIcYl8C1RlHDmxFh9G7q7x5 piSH9XRDjWqWKxhEYH1p6QynrFFAkRnk09FdaUuPw9lVaUEW//56at/jGPMkcqPWPC5B GjCOggvVOUX/q9aqSopWPw1y5NMHY+7/fz36Z+C95brY5J7C8nGzx4JFI4JQqFOaNHoA u0nBvzyQurdW+vE/ysHgGO3u2LnyQ81yCnIippK/n3wo2AC4VRkB65dcZPD9vgMTHRYD aVATF+Qgu4y6ba1fenxvBHIwM6VxvQUf1OYfNLdfojqvw0MVBLD3rXCZh9N153WrgXui Wp1Q== X-Gm-Message-State: AFeK/H2pygF6d9dlpZ3r4RnhK1HpLh8yInvmPESEnfmJyCZKKqA/73CHYlt97xVBjVYKWTyc705REXnKi0QlFQ== X-Received: by 10.157.4.141 with SMTP id 13mr8724796otm.243.1489761581360; Fri, 17 Mar 2017 07:39:41 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.14.123 with HTTP; Fri, 17 Mar 2017 07:39:40 -0700 (PDT) In-Reply-To: <269e5cb2-41f9-2605-759c-2478d816e591@eff.org> References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <9c55abf5-b81b-d9cb-c88c-7ea5bc6390c8@eff.org> <20170311201904.GQ7733@mournblade.imrryr.org> <389a248f-37e4-9ff7-b330-b840e7c47931@eff.org> <0d7afa83-a9d7-f977-ca36-533fc13b720e@eff.org> <7129a939-35f1-f55b-703b-9f39f6110520@eff.org> <269e5cb2-41f9-2605-759c-2478d816e591@eff.org> From: Phillip Hallam-Baker Date: Fri, 17 Mar 2017 10:39:40 -0400 X-Google-Sender-Auth: oIIitglftvLMv4sa3Ht-vjM31mg Message-ID: To: Jacob Hoffman-Andrews Cc: Ryan Sleevi , Patrick Donahue , Gervase Markham , "Salz, Rich" , Peter Bowen , "spasm@ietf.org" , Rob Stradling Content-Type: multipart/alternative; boundary=94eb2c095680db6b5f054aee252a Archived-At: Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 17 Mar 2017 14:39:43 -0000 --94eb2c095680db6b5f054aee252a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 16, 2017 at 8:20 PM, Jacob Hoffman-Andrews wrote= : > > =E2=80=8BYou mean tree climbing or tree climbing on CNAME? > > If the second, I concur. > > Yep, we've been using "tree climbing" as shorthand for "tree climbing on > CNAME." > =E2=80=8BSo at this point, does anyone object to the =E2=80=8Bfollowing cou= rse of action: =E2=80=8B* Amend the CABForum =E2=80=8B'clarification' ballot to state that= CAs must implement RFC 6844 as amended by erratum 4515 * Write new ID to accept the substantive change described in Erratum 4515 * Request publication as a new RFC =E2=80=8BNow whether we do this inside or outside the WG is for the chairs = and AD to consider. I don't think this is currently a WG item.=E2=80=8B But if we = have concurrence and there is no real dispute, that probably isn't such an issue= . --94eb2c095680db6b5f054aee252a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Ma= r 16, 2017 at 8:20 PM, Jacob Hoffman-Andrews <jsha@eff.org> wrot= e:
=20 =20 =20

=E2=80=8BYou mean tree climbing or tree climbing on CNAME?

If the second, I concur.
 Yep, we've been using "tree climbing" as shorthand for &q= uot;tree climbing on CNAME."


= =E2=80=8BSo at this point, does anyone object to the =E2=80=8Bfollowing cou= rse of action:
=
=E2=80=8B*= Amend the CABForum =E2=80=8B'clarification' ballot to state that C= As must implement RFC 6844 as amended by erratum 4515

* Write new ID to accept the substantive= change described in Erratum 4515

* Request publication as a new RFC

=E2=80=8BNow whether we do this inside or outside= the WG is for the chairs and AD to consider. I don't think this is cur= rently a WG item.=E2=80=8B But if we have concurrence and there is no real = dispute, that probably isn't such an issue.

--94eb2c095680db6b5f054aee252a-- From nobody Fri Mar 17 11:09:02 2017 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 08B71124D68 for ; Fri, 17 Mar 2017 11:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.798 X-Spam-Level: X-Spam-Status: No, score=-9.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.796, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=eff.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 tPY0_zBk6nIw for ; Fri, 17 Mar 2017 11:08:57 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C90C1273E2 for ; Fri, 17 Mar 2017 11:08:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=L2XQbKiClbTYlIhvjqXIbn9EeFNYVhWT96uxSFSSpZk=; b=qR34UfQdezwIKHLCGQjKb/f8yidtWxPg3r75WqJtTqCIiacys4YnR7E/dMmqTbY8lIB8m9AdG1OG5EjNboTXWd+KfqEziZ29lO/3sXygSI4RZowwI3VGiTjm6lROQuurTMvHBBpZKPYrjhArZB35MC2VMmTIXXOMOBN4bN1yZc8=; Received: ; Fri, 17 Mar 2017 11:08:58 -0700 To: Phillip Hallam-Baker References: <79cf5707-693e-abf0-9e35-5dcc94a3e877@eff.org> <20170311201904.GQ7733@mournblade.imrryr.org> <389a248f-37e4-9ff7-b330-b840e7c47931@eff.org> <0d7afa83-a9d7-f977-ca36-533fc13b720e@eff.org> <7129a939-35f1-f55b-703b-9f39f6110520@eff.org> <269e5cb2-41f9-2605-759c-2478d816e591@eff.org> Cc: Patrick Donahue , Gervase Markham , Ryan Sleevi , "Salz, Rich" , Peter Bowen , "spasm@ietf.org" , Rob Stradling From: Jacob Hoffman-Andrews Message-ID: Date: Fri, 17 Mar 2017 11:08:55 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9E085DE36A377D795D655F1F" Received-SPF: skipped for local relay Archived-At: Subject: Re: [Spasm] CAA erratum 4515 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 17 Mar 2017 18:09:01 -0000 This is a multi-part message in MIME format. --------------9E085DE36A377D795D655F1F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 03/17/2017 07:39 AM, Phillip Hallam-Baker wrote: > =E2=80=8BSo at this point, does anyone object to the =E2=80=8Bfollowing= course of action: > > =E2=80=8B* Amend the CABForum =E2=80=8B'clarification' ballot to state = that CAs must > implement RFC 6844 as amended by erratum 4515 > > * Write new ID to accept the substantive change described in Erratum 45= 15 > > * Request publication as a new RFC > > =E2=80=8BNow whether we do this inside or outside the WG is for the cha= irs and > AD to consider. I don't think this is currently a WG item.=E2=80=8B But= if we > have concurrence and there is no real dispute, that probably isn't > such an issue. This seems like a reasonable course of action. The only quibble I have is that, while erratum 4515 is the minimal change to express the behavior we've agreed to, it leaves the algorithm section overly detailed in a way that is potentially confusing to readers. I'd like to propose this version, which relies on the RFC 1034 language for CNAME resolution in order to clarify the behavior: ----- Proposal ----- Let CAA(X) be the record set returned by performing a CAA record query on the domain name X, according to the name server lookup algorithm specified in RFC 1034 section 4.3.2 (in particular including CNAME responses). Let P(X) be the domain name produced by removing the leftmost label of X. - If CAA(X) contains any CAA resource records, R(X) =3D CAA(X), otherwis= e - If P(X) is the root domain '.', then R(X) is empty, otherwise - R(X) =3D R(P(X)) ----- End proposal ----- =20 For reference, current RFC 6844 with 4515 applied: Let CAA(X) be the record set returned in response to performing a CAA record query on the label X, P(X) be the DNS label immediately above X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME alias record specified at the label X. o If CAA(X) is not empty, R(X) =3D CAA (X), otherwise o If A(X) is not null, and CAA(A(X)) is not empty, then R(X) =3D CAA(A(X)), otherwise o If X is not a top-level domain, then R(X) =3D R(P(X)), otherwise o R(X) is empty. For example, if a certificate is requested for X.Y.Z the issuer will search for the relevant CAA record set in the following order: X.Y.Z Alias (X.Y.Z) Y.Z Alias (Y.Z) Z Alias (Z) Return Empty --------------9E085DE36A377D795D655F1F Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 03/17/2017 07:39 AM, Phillip Hallam-Baker wrote:
​So at this point, does anyone object to the ​following course of action:

​* Amend the CABForum ​'clarification' ballot to state that CAs must implement RFC 6844 as amended by erratum 4515

* Write new ID to accept the substantive change described in Erratum 4515

* Request publication as a new RFC

​Now whether we do this inside or outside the WG is for the chairs and AD to consider. I don't think this is currently a WG item.​ But if we have concurrence and there is no real dispute, that probably isn't such an issue.
This seems like a reasonable course of action. The only quibble I have is that, while erratum 4515 is the minimal change to express the behavior we've agreed to, it leaves the algorithm section overly detailed in a way that is potentially confusing to readers. I'd like to propose this version, which relies on the RFC 1034 language for CNAME resolution in order to clarify the behavior:

----- Proposal -----
   Let CAA(X) be the record set returned by performing a CAA record query on the domain name X, according to the name server lookup algorithm specified in RFC 1034 section 4.3.2 (in particular including CNAME responses). Let P(X) be the domain name produced by removing the leftmost label of X.

 - If CAA(X) contains any CAA resource records, R(X) = CAA(X), otherwise
 - If P(X) is the root domain '.', then R(X) is empty, otherwise
 - R(X) = R(P(X))

----- End proposal -----
  

For reference, current RFC 6844 with 4515 applied: 
   Let CAA(X) be the record set returned in response to performing a CAA
   record query on the label X, P(X) be the DNS label immediately above
   X in the DNS hierarchy, and A(X) be the target of a CNAME or DNAME
   alias record specified at the label X.

   o  If CAA(X) is not empty, R(X) = CAA (X), otherwise

   o  If A(X) is not null, and CAA(A(X)) is not empty, then R(X) =
      CAA(A(X)), otherwise

   o  If X is not a top-level domain, then R(X) = R(P(X)), otherwise

   o  R(X) is empty.

   For example, if a certificate is requested for X.Y.Z the issuer will
   search for the relevant CAA record set in the following order:

      X.Y.Z

      Alias (X.Y.Z)

      Y.Z

      Alias (Y.Z)

      Z

      Alias (Z)

      Return Empty
--------------9E085DE36A377D795D655F1F-- From nobody Mon Mar 27 08:44:43 2017 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 19E7A1297C5 for ; Mon, 27 Mar 2017 08:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBv-bNLv-dn2 for ; Mon, 27 Mar 2017 08:44:30 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFBBC129693 for ; Mon, 27 Mar 2017 08:44:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4EE6C3004D0 for ; Mon, 27 Mar 2017 11:44:28 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id D3AJQ5EUAJiz for ; Mon, 27 Mar 2017 11:44:27 -0400 (EDT) Received: from dhcp-9516.meeting.ietf.org (dhcp-9516.meeting.ietf.org [31.133.149.22]) by mail.smeinc.net (Postfix) with ESMTPSA id 26E443000DC for ; Mon, 27 Mar 2017 11:44:27 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_F78B7878-D93E-4CC4-B9F6-273EA4993064" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <2AE8ED2A-990E-40D3-A1A8-71479AACA62B@vigilsec.com> References: <149062936304.30477.2728387405705533505.idtracker@ietfa.amsl.com> To: SPASM Date: Mon, 27 Mar 2017 11:44:26 -0400 X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [Spasm] Fwd: New Version Notification for draft-housley-lamps-cms-sha3-hash-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 15:44:33 -0000 --Apple-Mail=_F78B7878-D93E-4CC4-B9F6-273EA4993064 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Since people wanted to talk about SHA3 in certificates and S/MIME =E2=80=A6= Russ > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-housley-lamps-cms-sha3-hash-00.txt > Date: March 27, 2017 at 11:42:43 AM EDT > To: "Russ Housley" >=20 >=20 > A new version of I-D, draft-housley-lamps-cms-sha3-hash-00.txt > has been successfully submitted by Russ Housley and posted to the > IETF repository. >=20 > Name: draft-housley-lamps-cms-sha3-hash > Revision: 00 > Title: Use of the SHA3 One-way Hash Functions in the = Cryptographic Message Syntax (CMS) > Document date: 2017-03-27 > Group: Individual Submission > Pages: 7 > URL: = https://www.ietf.org/internet-drafts/draft-housley-lamps-cms-sha3-hash-00.= txt > Status: = https://datatracker.ietf.org/doc/draft-housley-lamps-cms-sha3-hash/ > Htmlized: = https://tools.ietf.org/html/draft-housley-lamps-cms-sha3-hash-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-housley-lamps-cms-sha3-hash-00= >=20 >=20 > Abstract: > This document describes the conventions for using the four one-way > hash functions in the SHA3 family with the Cryptographic Message > Syntax (CMS). --Apple-Mail=_F78B7878-D93E-4CC4-B9F6-273EA4993064 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Since people wanted to talk about SHA3 in certificates and = S/MIME =E2=80=A6

Russ


From: internet-drafts@ietf.org
Subject: = New Version = Notification for draft-housley-lamps-cms-sha3-hash-00.txt
Date: = March 27, 2017 at 11:42:43 AM = EDT
To: = "Russ Housley" <housley@vigilsec.com>


A new version = of I-D, draft-housley-lamps-cms-sha3-hash-00.txt
has been = successfully submitted by Russ Housley and posted to the
IETF repository.

Name: = draft-housley-lamps-cms-sha3-hash
Revision: 00
Title:= = Use of the SHA3 One-way Hash Functions in the Cryptographic = Message Syntax (CMS)
Document date: = 2017-03-27
Group: Individual Submission
Pages:= = 7
URL: =            https://www.ietf.org/internet-drafts/draft-housley-lamps-cms-sh= a3-hash-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-housley-lamps-cms-sha3-h= ash/
Htmlized:       https://tools.ietf.org/html/draft-housley-lamps-cms-sha3-hash-0= 0
Htmlized:       https://datatracker.ietf.org/doc/html/draft-housley-lamps-cms-s= ha3-hash-00


Abstract:
  This document describes the conventions for = using the four one-way
  hash functions in the = SHA3 family with the Cryptographic Message
=   Syntax (CMS).
= --Apple-Mail=_F78B7878-D93E-4CC4-B9F6-273EA4993064-- From nobody Mon Mar 27 13:38:17 2017 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 3208312965D for ; Mon, 27 Mar 2017 13:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dbCwlu4kD4t for ; Mon, 27 Mar 2017 13:38:04 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0132.outbound.protection.outlook.com [23.103.201.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE542129637 for ; Mon, 27 Mar 2017 13:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OWJDDf8GGiyoY5cyXmtxrniv+tW22Wwa443KADbUOnM=; b=GlQnI227keWEv57HJ2yOeYlJYZ0E4bH0wBh+STFBTZ8hvcjWx/5FiBqwwf0UyGNWsOGilbTPJaIvbVhyhoC4E7XOgv2MpBGMX6VsX+tuz0MnecuGkE4yYCjWwPXOBugtkY9Yc6rtTG7OD6Qa6t1jCfvAIxThCzkiIhC9IC4zmT4= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Mon, 27 Mar 2017 20:38:00 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0991.020; Mon, 27 Mar 2017 20:38:00 +0000 From: "Dang, Quynh (Fed)" To: Russ Housley , SPASM Thread-Topic: [Spasm] Fwd: New Version Notification for draft-housley-lamps-cms-sha3-hash-00.txt Thread-Index: AQHSpxELOpu+W84vNEmUdUzFC9lo4qGpI6EN Date: Mon, 27 Mar 2017 20:38:00 +0000 Message-ID: References: <149062936304.30477.2728387405705533505.idtracker@ietfa.amsl.com>, <2AE8ED2A-990E-40D3-A1A8-71479AACA62B@vigilsec.com> In-Reply-To: <2AE8ED2A-990E-40D3-A1A8-71479AACA62B@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [31.133.130.145] x-microsoft-exchange-diagnostics: 1; CY4PR09MB1464; 7:k9/g2rP/d7BQV7lMmqLxDCaiAKq/Fyl4Jr2F/aiD+U0jpkYXHT/A/I4WElkGPLS/OBRPoNDXj0QTe21Dp3u4RYjIv9xm9wPLjolptj997GmYWvb/jtNwrOLfUYjRLpT9K7dwTT0+iHuA8TwmqzY/B5uDQGhTdqEJ3jK/mBRSEkJEK1dPV31Y7HAKNuiUcIGdaaktQWwiTGVaY1lmAlTdXOPbzIhlRJdRSLk9++v8TAbnKobMnne6PwgMftiiTCySOOv7AOIS2KqcxvatFBmpoSRN3aVf49iPf/j90d6kon3iTFt4B7egU7+EY3jXn8lexvnXfcaYgFJHx1UyOu+l1A== x-ms-office365-filtering-correlation-id: 13d72eae-e159-4074-11a5-08d4755128de x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:CY4PR09MB1464; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(20161123558025)(6072148); SRVR:CY4PR09MB1464; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1464; x-forefront-prvs: 02596AB7DA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39840400002)(39860400002)(39410400002)(39850400002)(377424004)(377454003)(2906002)(6306002)(6436002)(606005)(9686003)(99286003)(55016002)(3660700001)(3280700002)(33656002)(38730400002)(15650500001)(53936002)(54896002)(229853002)(25786009)(6246003)(2900100001)(189998001)(6116002)(102836003)(3846002)(66066001)(236005)(54356999)(5660300001)(86362001)(76176999)(50986999)(81166006)(8676002)(230783001)(7696004)(2950100002)(7736002)(74316002)(7906003)(19627405001)(122556002)(77096006)(53546009)(6506006)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1464; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR09MB146440F3F7A0E4E3CF52D10BF3330CY4PR09MB1464namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2017 20:38:00.2023 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1464 Archived-At: Subject: Re: [Spasm] Fwd: New Version Notification for draft-housley-lamps-cms-sha3-hash-00.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 20:38:06 -0000 --_000_CY4PR09MB146440F3F7A0E4E3CF52D10BF3330CY4PR09MB1464namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Russ and all, Why don't we just specify SHAKE128/256 and SHAKE256/512 ? If we would like = 224 and 384 bit hashes, we can add SHAKE128/224 and SHAKE256/384 respective= ly. Those 4 SHAKEs have better performances than the 4 SHA3s and are also NIST-= approved hash functions. I could assign new OIDs for those 4 SHAKEs above with their fixed output le= ngths if desired. Regards, Quynh. ________________________________ From: Spasm on behalf of Russ Housley Sent: Monday, March 27, 2017 11:44:26 AM To: SPASM Subject: [Spasm] Fwd: New Version Notification for draft-housley-lamps-cms-= sha3-hash-00.txt Since people wanted to talk about SHA3 in certificates and S/MIME =85 Russ From: internet-drafts@ietf.org Subject: New Version Notification for draft-housley-lamps-cms-sha3-hash-00.= txt Date: March 27, 2017 at 11:42:43 AM EDT To: "Russ Housley" > A new version of I-D, draft-housley-lamps-cms-sha3-hash-00.txt has been successfully submitted by Russ Housley and posted to the IETF repository. Name: draft-housley-lamps-cms-sha3-hash Revision: 00 Title: Use of the SHA3 One-way Hash Functions in the Cryptographic Message = Syntax (CMS) Document date: 2017-03-27 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-housley-lamps-cm= s-sha3-hash-00.txt Status: https://datatracker.ietf.org/doc/draft-housley-lamps-cms-sh= a3-hash/ Htmlized: https://tools.ietf.org/html/draft-housley-lamps-cms-sha3-ha= sh-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-housley-lamps-c= ms-sha3-hash-00 Abstract: This document describes the conventions for using the four one-way hash functions in the SHA3 family with the Cryptographic Message Syntax (CMS). --_000_CY4PR09MB146440F3F7A0E4E3CF52D10BF3330CY4PR09MB1464namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Russ and all,


Why don't we just specify SHAKE128/256 and SHAKE256/512 ? If we w= ould like 224 and 384 bit hashes, we can add SHAKE128/224 and SHAKE256/384 = respectively.

Those 4 SHAKEs have better performances than the 4 SHA3s and are also = NIST-approved hash functions.

I could assign new OIDs for those 4=  SHAKEs above with their fixed output lengths if desired. 

Regards,
Quynh.  

From: Spasm <spasm-bounc= es@ietf.org> on behalf of Russ Housley <housley@vigilsec.com>
Sent: Monday, March 27, 2017 11:44:26 AM
To: SPASM
Subject: [Spasm] Fwd: New Version Notification for draft-housley-lam= ps-cms-sha3-hash-00.txt
 
Since people wanted to talk about SHA3 in certificates and S/MIME =85

Russ


From: internet-drafts@ietf.org
Subject: New Version Notification = for draft-housley-lamps-cms-sha3-hash-00.txt
Date: March 27, 2017 at 11:42:43 AM EDT
To: "Russ Housley" <housley@vigilsec.com>


A new version of I-D, draft-housley-lamps-cms-sha3-hash-00.txt
has been successfully submitted by Russ Housley and posted to the
IETF repository.

Name: draft-housley-la= mps-cms-sha3-hash
Revision: 0= 0
Title: Use of the SHA3= One-way Hash Functions in the Cryptographic Message Syntax (CMS)
Document date: 2017-03-27
Group: Individual Subm= ission
Pages: 7
URL:            https://www.ietf.org/internet-drafts/draft-housley-la= mps-cms-sha3-hash-00.txt
Status:         htt= ps://datatracker.ietf.org/doc/draft-housley-lamps-cms-sha3-hash/
Htmlized:       https://tools.ie= tf.org/html/draft-housley-lamps-cms-sha3-hash-00
Htmlized:       https:= //datatracker.ietf.org/doc/html/draft-housley-lamps-cms-sha3-hash-00

Abstract:
  This document describes the conventions for using the four one-= way
  hash functions in the SHA3 family with the Cryptographic Messag= e
  Syntax (CMS).

--_000_CY4PR09MB146440F3F7A0E4E3CF52D10BF3330CY4PR09MB1464namp_-- From nobody Tue Mar 28 15:44:22 2017 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 5350D127B57; Tue, 28 Mar 2017 15:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ey7jtiiybL2t; Tue, 28 Mar 2017 15:43:49 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 0D145124234; Tue, 28 Mar 2017 15:43:49 -0700 (PDT) X-AuditID: c6180641-c3fff70000000a06-42-58daa0c92dec Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by (Symantec Mail Security) with SMTP id 50.A7.02566.9C0AAD85; Tue, 28 Mar 2017 19:43:40 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0339.000; Tue, 28 Mar 2017 18:43:44 -0400 From: Daniel Migault To: Jim Schaad , "curdle@ietf.org" CC: "saag@ietf.org" , "spasm@ietf.org" , "tls@ietf.org" , IPsecME WG Thread-Topic: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.txt Thread-Index: AQEf37CDGDDCSU9BXbxVbCIypDLQd6MQV6aggAAQoyA= Date: Tue, 28 Mar 2017 22:43:44 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BB7D3A@eusaamb107.ericsson.se> References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> In-Reply-To: <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZXLonQffMglsRBlf/qlhsXTiL2WL19O9s Fvu3vGCzmNLfyWQx71qyxafzXYwObB4b50xn81iy5CdTAFMUl01Kak5mWWqRvl0CV8bMva+Z CmaJV7z5MI2xgfG1UBcjB4eEgIlEU6dJFyMXh5DABkaJ3YfPsEE4yxklju+/wNTFyMnBJmAk 0Xaonx3EFhHwkbjy4AwrSBGzQAujxIorPxlBEsICYRKzZ79ngygKlzjd+ZkFwraSmLd/CyuI zSKgKnHh2XdGkM28Ar4SU954QSxrYpS4crgZbA6ngIPErca5YIsZBcQkvp9aA2YzC4hL3Hoy H8yWEBCQWLLnPDOELSrx8vE/VghbSeLj7/nsEPU6Egt2f2KDsLUlli18DVbPKyAocXLmE5YJ jKKzkIydhaRlFpKWWUhaFjCyrGLkKC0uyMlNNzLcxAiMmmMSbI47GPf2eh5iFOBgVOLhVTC5 FSHEmlhWXJl7iFGCg1lJhHf+MqAQb0piZVVqUX58UWlOavEhRmkOFiVx3nflFyKEBNITS1Kz U1MLUotgskwcnFINjOsanG9H7tCr+HAwitn45eSlPqKHWv7UhyuH2VjdcGmW6cxYespAukhA xKd0ztH7NgIdAeoLOLdfzTl4bnpTcm4jx/vHuueYL89ZMXtK9butNncZzPfo/H9RsmfHnw13 jD/lbOg4NHfRFfufv24uyFCb2m7X3fF9rk3Ywy9eb/4nm4tfr+UzmqbEUpyRaKjFXFScCAAN fttwlgIAAA== Archived-At: Subject: Re: [Spasm] [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 28 Mar 2017 22:43:51 -0000 Hi,=20 Thank you Jim for the update. Here is the version resulting from the discus= sion we had during the WG meeting yesterday. Please review the document an= d provide your feed backs by April 4 so we can move the draft to the IESG.= =20 Yours,=20 Daniel -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Tuesday, March 28, 2017 4:40 PM To: curdle@ietf.org Subject: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-0= 4.txt Here is the promised updated draft. Changes: 1. Fixed an example that David Benjamin found was wrong. (Incorrect sign = bit in public key.) 2. Remove all of the pre-hash text except to note that= it does exist. 3. No changes to the OID arc being used despite the agreement during the m= eeting. After the meeting, Russ, the chairs and I had a short talk and dec= ided that this did not need to occur. The problem was only with getting ne= w values assigned not with the current values which were already assigned. That should be the final issues in the draft Jim > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, March 28, 2017 4:31 PM > To: Jim Schaad ; Simon Josefsson=20 > > Subject: New Version Notification for draft-ietf-curdle-pkix-04.txt >=20 >=20 > A new version of I-D, draft-ietf-curdle-pkix-04.txt has been=20 > successfully submitted by Jim Schaad and posted to the IETF repository. >=20 > Name: draft-ietf-curdle-pkix > Revision: 04 > Title: Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for > use in the Internet X.509 Public Key Infrastructure > Document date: 2017-03-28 > Group: curdle > Pages: 15 > URL: https://www.ietf.org/internet-drafts/draft-ietf-curdle-pk= ix-04.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ > Htmlized: https://tools.ietf.org/html/draft-ietf-curdle-pkix-04 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-curdle-p= kix-04 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-pki= x-04 >=20 > Abstract: > This document specifies algorithm identifiers and ASN.1 encoding > formats for Elliptic Curve constructs using the Curve25519 and > Curve448 curves. The signature algorithms covered are Ed25519 and > Ed448. The key agreement algorithm covered are X25519 and X448. The > encoding for Public Key, Private Key and EdDSA digital signature > structures is provided. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > The IETF Secretariat _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Thu Mar 30 09:31:23 2017 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 BD2121299A8 for ; Thu, 30 Mar 2017 09:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.691 X-Spam-Level: X-Spam-Status: No, score=-2.691 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 SWMvBx_sW1Os for ; Thu, 30 Mar 2017 09:31:15 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (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 1D80B1297AA for ; Thu, 30 Mar 2017 09:31:10 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id z204so61189878vkd.1 for ; Thu, 30 Mar 2017 09:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=deo5jEBI7LzQAd9NSscvBMuSgrPsBnXKtBtALpMmQiw=; b=tpkDgdkI2s0dlHwGoQiH5cYAIvCxVJNsltSTSVDw7hNAT3fcWJTHem8p22duykk13K 13ZYxTFZhXwVpD9ND+2p+40brp5FC0IedfvHxBTXgRSQAonKfTzWdpqq15n1Wl2H3LaL tBZbKScTB06lQkWNDnVk3+pxiHoNmZG0/DvdPfWjUMbi/CIqExUf8phYdv/xMVQbpSaa uqH2ceHH881JPlmV2DVmj559MfMzOM3juVfyxmSUQ3W44FovSNe4x0nu70TpbXWstvOn hPpKueL67kkZ3EE1C0pqz7cls2IlTjgAGIKMlhXKk7IA1q1Vgi5yxvEi7XHnPPGaCvim CKww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=deo5jEBI7LzQAd9NSscvBMuSgrPsBnXKtBtALpMmQiw=; b=jSzheOumG03lBI+IWMlsey3PFc9Fx7HREl+GSFUq3VvBMlW8dhYpdd+SpMVGllY/uh +ddp4UTUMGoHGCgezrAKR6NSKShElSz9PO55rOgoVxiMg7IV8REXYGsRq/iZ5DtCUSsE WUJ4F2oGx2VyMcOFC6XUizAoy9vGzqnBkhLaPsMlpuA+ttHbQKjmneAsU4oWztbYiZ30 XoUy4N19clRvg91okrV/pavnSpWKmjCYdjkUePcdqxg+cWe1clP96dnFJvEqVwNhcH5L 1zsAoFnSekC20YIyA0UgWob08IEHCMAV6ubh3gh1lcaEBs2a7XA/HGylQD+AounMxw/K W6Zw== X-Gm-Message-State: AFeK/H3JGcG7YAC2fIXyqnVhwf8Ac941xSmX11zpUeZJRxxsWNaKKGG4IijSicDr+toiG1AybqyeIpUV5s6M2L/v X-Received: by 10.31.170.68 with SMTP id t65mr277217vke.133.1490891468695; Thu, 30 Mar 2017 09:31:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.8.6 with HTTP; Thu, 30 Mar 2017 09:31:07 -0700 (PDT) In-Reply-To: <20170314144901.GK4095@mournblade.imrryr.org> References: <841bb724-7403-4682-3d50-f878f63b0346@cs.tcd.ie> <6d114340-c9a7-e311-e6f9-0614600cafd2@cs.tcd.ie> <00c401d298b8$616fffa0$4001a8c0@gateway.2wire.net> <9EC9BC6B-B1AB-4B1C-AC73-5501AA94465B@vigilsec.com> <20170314144901.GK4095@mournblade.imrryr.org> From: Wei Chuang Date: Thu, 30 Mar 2017 11:31:07 -0500 Message-ID: To: SPASM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11431b666cc535054bf53873" Archived-At: Subject: Re: [Spasm] Last Call: (Internationalized Email Addresses in X.509 certificates) to Proposed Standard X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 16:31:20 -0000 --001a11431b666cc535054bf53873 Content-Type: multipart/alternative; boundary=001a11431b66645eb2054bf53812 --001a11431b66645eb2054bf53812 Content-Type: text/plain; charset=UTF-8 Thanks for the comments. Reply inline below: On Tue, Mar 14, 2017 at 9:49 AM, Viktor Dukhovni wrote: > On Mon, Mar 13, 2017 at 10:44:32AM -0400, Russ Housley wrote: > > > > On Mar 12, 2017, at 5:40 PM, Wei Chuang wrote: > > > > > > The latest draft 08 is up: > > > > > > https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-08 > > > > > > The diff is: > > > > > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-lamps- > eai-addresses-08.txt > > > > > > This draft attempts to capture Viktor's name constraint verifier logic, > > > and illustrate the examples in the diagrams. > > > > These changes were made in response to an IETF Last Call comment. Please > > review them. The vast bulk of the changes are in Section 6. Please > speak > > promptly if you think this is the word technical solution. > > I think that while the new section 6 is technically on track, that > it still needs a bit more effort to improve clarity. > > The design would be more clear if the rationale were stated clearly > and concisely up-front. Therefore, after the second paragraph, I > would like to see something along the lines of (please improve as > needed): > > Some legacy actors (either CAs or relying parties) > support only rfc822Name SANs and rfc822Name constraints. > While limits on the new SmtpUTF8Name SANs will be > expressed via new SmtpUTF8Name constraints defined in > this document, these will not be generated or understood > by the above legacy actors. > > When a legacy CA has only rfc822Name constraints, with > the intent of limiting the scope of email addresses > allowed in end-entity certificates it can issue, there > would be a potential constraint bypass risk, if as a > result all SmtpUTF8Name SANs were allowed to be used > for lack of corresponding constraints. > > When a non-legacy CA has only SMTPUTF8Name constraints, > with the intent of limiting the scope of allowed > addresses to particular UTF8 forms, there is again a > risk of bypass when a legacy relying party remains unaware > of this intent. > > To avoid the above constraint bypass issues, we obligate > SmtpUTF8Name-aware relying parties to disallow SmtpUTF8Name > SANS in end-entity certificates whose chain includes > (presumed) legacy CAs that have only rfc822Name > constraints. > > Similarly, we obligate SmtpUTF8-aware CAs issuing > constrained CA certificates, to also include sufficient > rfc822Name constraints so that the set of email addresses > acceptable in end-entity certificates is not unintentionally > larger for legacy SmtpUTF8-unaware relying parties. > How about the following language to represent the above: This specification pays particular attention to interaction between legacy and SmtpUTF8Name aware systems as there is the risk of name constraint bypass through these interactions. More specifically the risk is between legacy CA and SmtpUTF8Name aware path verifiers, and between SmtpUTF8Name aware CA and legacy path verifiers. A legacy CA is only aware of rfc822Name subjectAltName and name constraints, and GeneralName subject. While a legacy CA may intend to limit the scope of all email addresses through rfc822Name name constraint, a SmtpUTF8Name aware path verifier may mistakenly interpret the path as only constraining rfc822Name subjectAltName names and not SmtpUTF8Name subjectAltName names. The following section requires that the SmtpUTF8Name aware verifier protect against this scenario in the following section (as bullet 2). Similarly there is a bypass risk when a legacy path verifier is only aware of the legacy rfc822Name name constraints and subject name forms, and a SmtpUTF8Name aware CA intends to contrains all email addresses including SmtpUTF8Name form. The bypass in this scenario is prevented by the compliant path verifier that sees the unknown SmtpUTF8Name subjectAltName name and name constraint whose extensions are marked critical, then fails the verification. The referred to bullet 2 is If issuer CA certificates contain only rfc822Name name constraints, then those constraints apply to rfc822Name subject alternative name in children certificates. SmtpUTF8Name subject alternative name are prohibited in those same certificates, that is those certificates MUST be rejected by the path verifier > > I also think that the text below points 1--4 could be more clear. > Instead of a single explosion of text that tries to explain all > the diagrams, it is perhaps better to interleave the diagrams > with corresponding explanatory text. > I've put the example text next to the respective diagram of which there three. The largest blob still looks like: The name constraint requirement with SmtpUTF8Name subject alternative name is illustrated in the non-normative diagram with several examples. The example numbering corresponding to the above rule numbering. (3a) shows an issuer constraining a NR-LDH hostname with rfc822Name and SmtpUTF8Name so that they can issue ASCII and UTF-8 local-name email addresses certificates. (3b) shows an issuer constraining a hostname containing a non-ASCII label for u+5C0Fu+5B66 (elementary school). (3c) demonstrates that a hostname constraint with an rfc822Name is distinguishable from its SmtpUTF8Name constraint, and that only the rfc822Name form is permitted. No 'invalid' SmtpUTF8Name constraint is needed since other SmtpUTF8Name constraints are present. (3d) similarly demonstrates this capability to restrict a name constraint to SmtpUTF8Name only. (3e) shows that a non-ASCII local- part email address can also be constrained to be permitted using SmtpUTF8Name. It too does not need an 'invalid' rfc822Name as other rfc822Name constrains are present. +-------------------------------------------------------------------+ | Root CA Cert | +-------------------------------------------------------------------+ | v +-------------------------------------------------------------------+ | Intermediate CA Cert | | Permitted | | rfc822Name: nr.ldh.host.example.com (3a) | | SmtpUTF8Name: nr.ldh.host.example.com (3a) | | | | rfc822Name: u+5C0Fu+5B66.host.example.com (3b) | | SmtpUTF8Name: xn--48s3o.host.example.com (3b) | | | | rfc822Name: xn--pss25c.a.label.example.com (3c) | | | | SmtpUTF8Name: u+4E2Du+5B66.u.label.example.com (3d) | | | | SmtpUTF8Name: u+8001u+5E2B@i18n.email.example.com (3e) | +-------------------------------------------------------------------+ | v +-------------------------------------------------------------------+ | Entity Cert (w/explicitly permitted subjects) | | SubjectAltName Extension | | rfc822Name: student@nr.ldh.host.example.com (3a) | | SmtpUTF8Name: u+5B66u+751F@nr.ldh.host.example.com (3a) | | | | rfc822Name: student@u+5C0Fu+5B66.host.example.com (3b) | | SmtpUTF8Name: u+5B66u+751F@xn--48s3o.host.example.com (3b) | | | | rfc822Name: student@xn--pss25c.a.label.example.com (3c) | | | | SmtpUTF8Name: student@u+4E2Du+5B66.u.label.example.com (3d) | | | | SmtpUTF8Name: u+8001u+5E2B@i18n.email.example.com (3e) | +-------------------------------------------------------------------+ Are you suggesting to break this up further? > > Also there could be a better explanation of how to craft rfc822Name > constraints to avoid constraint bypass against legacy relying > parties. That is, the paragraph: > > If the issuer wishes to represent the name constraint asymmetrically, > with either rfc822Name or SmtpUTF8Name to respectively represent some > A-label or U-label in the domain or host, the alternate name > constraint form must still be present. If nothing needs be > represented by the alternate form, then empty name constraint can > described by the "invalid" TLD that helps initialize the name > constraint path validation set. Or alternatively it may be omitted > if some other name constraint pair, provides a name constraint of > that form. In particular this initialization may be needed when > SmtpUTF8Name is used to represent an email address name constraint > with an UTF-8 local-part and rfc822Name cannot represent such a email > address constraint. > > may be too concise. With luck the suggested rationale additions may > help readers figure out an appropriate strategy that meets the same > goals, but this text could probably be improved. > What about: The issuer may wish to distinguish the features of the two different name constraint forms as well as they can represents names differently. For example the issuer may wish to constraint a name with A-label differently than U-label. Another example is constraining a UTF-8 local-part email address via SmtpUTF8Name that rfc822Name cannot do. If the intent is to allow SmtpUTF8Name subjectAltName, then both name constraint forms, rfc822Name and SmtpUTF8Name, must be present though with some caveats. If nothing needs be represented by the alternate form, then the empty name constraint can be described by the "invalid" TLD that helps initialize the name constraint path validation set. Or alternatively it may be omitted if some other name constraint pair, provides a name constraint of that form. -Wei --001a11431b66645eb2054bf53812 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the comments.=C2=A0 Reply inline below:

On Tue, Mar 14, 2017 = at 9:49 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> wr= ote:
On Mon, Mar 13, 2017 at 10:44:32AM -0400, Russ Housley wrote:

> > On Mar 12, 2017, at 5:40 PM, Wei Chuang <weihaw@google.com> wrote:
> >
> > The latest draft 08 is up:
> >
> > https://tools.ietf.org/html/<= wbr>draft-ietf-lamps-eai-addresses-08
> >
> > The diff is:
> >
> > https://tools.i= etf.org/rfcdiff?url2=3Ddraft-ietf-lamps-eai-addresses-08.txt<= br> > >
> > This draft attempts to capture Viktor's name constraint verif= ier logic,
> > and illustrate the examples in the diagrams.
>
> These changes were made in response to a= n IETF Last Call comment.=C2=A0 Please
> review them.=C2=A0 The vast bulk of the changes are in Section 6.=C2= =A0 Please speak
> promptly if you think this is the word technical solution.

I think that while the new section 6 is technically on track, that it still needs a bit more effort to improve clarity.

The design would be more clear if the rationale were stated clearly
and concisely up-front.=C2=A0 Therefore, after the second paragraph, I
would like to see something along the lines of (please improve as
needed):

=C2=A0 =C2=A0 Some legacy actors (either CAs or relying parties)
=C2=A0 =C2=A0 support only rfc822Name SANs and rfc822Name constraints.
=C2=A0 =C2=A0 While limits on the new SmtpUTF8Name SANs will be
=C2=A0 =C2=A0 expressed via new SmtpUTF8Name constraints defined in
=C2=A0 =C2=A0 this document, these will not be generated or understood
=C2=A0 =C2=A0 by the above legacy actors.

=C2=A0 =C2=A0 When a legacy CA has only rfc822Name constraints, with
=C2=A0 =C2=A0 the intent of limiting the scope of email addresses
=C2=A0 =C2=A0 allowed in end-entity certificates it can issue, there
=C2=A0 =C2=A0 would be a potential constraint bypass risk, if as a
=C2=A0 =C2=A0 result all SmtpUTF8Name SANs were allowed to be used
=C2=A0 =C2=A0 for lack of corresponding constraints.

=C2=A0 =C2=A0 When a non-legacy CA has only SMTPUTF8Name constraints,
=C2=A0 =C2=A0 with the intent of limiting the scope of allowed
=C2=A0 =C2=A0 addresses to particular UTF8 forms, there is again a
=C2=A0 =C2=A0 risk of bypass when a legacy relying party remains unaware =C2=A0 =C2=A0 of this intent.

=C2=A0 =C2=A0 To avoid the above constraint bypass issues, we obligate
=C2=A0 =C2=A0 SmtpUTF8Name-aware relying parties to disallow SmtpUTF8Name =C2=A0 =C2=A0 SANS in end-entity certificates whose chain includes
=C2=A0 =C2=A0 (presumed) legacy CAs that have only rfc822Name
=C2=A0 =C2=A0 constraints.

=C2=A0 =C2=A0 Similarly, we obligate SmtpUTF8-aware CAs issuing
=C2=A0 =C2=A0 constrained CA certificates, to also include sufficient
=C2=A0 =C2=A0 rfc822Name constraints so that the set of email addresses
=C2=A0 =C2=A0 acceptable in end-entity certificates is not unintentionally<= br> =C2=A0 =C2=A0 larger for legacy SmtpUTF8-unaware relying parties.


How about the following language = to represent the above:

This specification pays particula= r attention to interaction between legacy and SmtpUTF8Name
aware = systems as there is the risk of name constraint bypass through these intera= ctions.=C2=A0 More
specifically the risk is between legacy CA and= SmtpUTF8Name aware path verifiers, and between
SmtpUTF8Name awar= e CA and legacy path verifiers.=C2=A0 A legacy CA is only aware of rfc822Na= me
subjectAltName and name constraints, and GeneralName subject.= =C2=A0 While a legacy CA may intend to limit
the scope of all ema= il addresses through rfc822Name name constraint, a SmtpUTF8Name aware path<= /div>
verifier may mistakenly interpret the path as only constraining r= fc822Name subjectAltName names and
not SmtpUTF8Name subjectAltNam= e names.=C2=A0 The following section requires that the SmtpUTF8Name aware
verifier protect against this scenario in the following section (a= s bullet 2).=C2=A0 Similarly there is a
bypass risk when a legacy= path verifier is only aware of the legacy rfc822Name name constraints and<= /div>
subject name forms, and a SmtpUTF8Name aware CA intends to contra= ins all email addresses including
SmtpUTF8Name form.=C2=A0 The by= pass in this scenario is prevented by the <xref target=3D'RFC5280= 9;/>
compliant path verifier that sees the unknown SmtpUTF8Nam= e subjectAltName name and name constraint
whose extensions are ma= rked critical, then fails the verification.

The referred to bullet 2 is
If issuer CA certi= ficates contain only rfc822Name name constraints, then those constraints
=C2=A0apply to rfc822Name subject alternative name in children cert= ificates.=C2=A0 SmtpUTF8Name
=C2=A0subject alternative name are p= rohibited in those same certificates, that is those
=C2=A0 certif= icates MUST be rejected by the path verifier
=C2=A0

I also think that the text below points 1--4 could be more clear.
Instead of a single explosion of text that tries to explain all
the diagrams, it is perhaps better to interleave the diagrams
with corresponding explanatory text.

I&= #39;ve put the example text next to the respective diagram of which there t= hree.=C2=A0 The largest blob still looks like:

T= he name constraint requirement with SmtpUTF8Name subject alternative name i= s illustrated in the
non-normative diagram <xref = target=3D"example_permitted_matched_constraint" /> with severa= l examples.
The example numbering corresponding to t= he above rule numbering.
(3a) shows an issuer constr= aining a NR-LDH hostname with rfc822Name and SmtpUTF8Name so that they
can issue ASCII and UTF-8 local-name email addresses cer= tificates. =C2=A0(3b) shows an issuer
constraining a= hostname containing a non-ASCII label for u+5C0Fu+5B66 (elementary school)= . =C2=A0(3c)
<= div class=3D"gmail_quote">
demonstrates that a hostname constraint= with an rfc822Name is distinguishable from its SmtpUTF8Name
<= div>
constraint, and that only the rfc822Name form is permitted.=C2=A0 = No 'invalid' SmtpUTF8Name constraint is
need= ed since other SmtpUTF8Name constraints are present. =C2=A0(3d) similarly d= emonstrates this
capability to restrict a name const= raint to SmtpUTF8Name only. =C2=A0(3e) shows that a non-ASCII local-
<= /div>
part email address can also be constrained to be permitted= using SmtpUTF8Name.=C2=A0 It too does not need
an &= #39;invalid' rfc822Name as other rfc822Name constrains are present.

<ar= twork>
=C2=A0 +----= ---------------------------------------------------------------+
=C2=A0 | =C2=A0Root CA Cert =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 +-------------------------------------------------------= ------------+
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 v
=C2=A0 +--------= -----------------------------------------------------------+
=C2=A0 | =C2=A0Intermediate CA Cert = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
=C2=A0 | =C2= =A0 =C2=A0 =C2=A0Permitted =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0= rfc822Name: nr.ldh.host.example.= com (3a) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= |
=C2=A0 | =C2=A0 =C2= =A0 =C2=A0 =C2=A0SmtpUTF8Name: n= r.ldh.host.example.com (3a) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0= | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0= | =C2=A0 =C2=A0 =C2=A0 =C2=A0rfc822Name: u+5C0Fu+5B66.host.example.com (3b) =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0= | =C2=A0 =C2=A0 =C2=A0 =C2=A0SmtpUTF8Name: xn--48s3o.host.example.com (3b) =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0rfc822Name: xn--pss25c.a.label.example.com (3c) =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0SmtpUTF8Name: u+4E2Du+5B66.u.label.example.com (3d) =C2= =A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0SmtpUTF8Name: u+8001u+5E2B@i18n.email.example.com = (3e) =C2=A0 =C2=A0 |
= =C2=A0 +-------------------------------------------------------------------= +
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v
=C2=A0 +------------------------= -------------------------------------------+
=C2=A0 | =C2=A0Entity Cert (w/explicitly permitted s= ubjects) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
=C2=A0 | =C2=A0 = =C2=A0SubjectAltName Extension =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
= =C2=A0 | =C2=A0 =C2=A0 =C2=A0rfc822Name: student@nr.ldh.host.example.com (3a) =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0SmtpUTF8Name: u+5B66u+751F@nr.ldh.host.example.com (= 3a) =C2=A0 =C2=A0 =C2=A0|
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0rfc822Name: student@u+5C0Fu+5B66.host.example.com (3b) =C2=A0 =C2=A0 =C2=A0= |
=C2=A0 | =C2=A0 =C2= =A0 =C2=A0SmtpUTF8Name: u+5B66u+751F@xn--48s3o.host.example.com (3b) =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=
=C2=A0 | =C2=A0 =C2=A0 =C2= =A0rfc822Name: st= udent@xn--pss25c.a.label.example.com (3c) =C2=A0 =C2=A0 =C2=A0|<= /div>
=C2=A0 | =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0Smt= pUTF8Name: student@u+4E2Du+5B66= .u.label.example.com (3d) =C2=A0|
=C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 | =C2=A0 =C2=A0 =C2=A0SmtpUTF8Name: u+8001u+5E2B@i18n.email.example.c= om (3e) =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 +------------------------------------------------------= -------------+
</ar= twork>

Are you sug= gesting to break this up further?
=C2=A0

Also there could be a better explanation of how to craft rfc822Name
constraints to avoid constraint bypass against legacy relying
parties.=C2=A0 That is, the paragraph:

=C2=A0 =C2=A0If the issuer wishes to represent the name constraint asymmetr= ically,
=C2=A0 =C2=A0with either rfc822Name or SmtpUTF8Name to respectively represe= nt some
=C2=A0 =C2=A0A-label or U-label in the domain or host, the alternate name =C2=A0 =C2=A0constraint form must still be present.=C2=A0 If nothing needs = be
=C2=A0 =C2=A0represented by the alternate form, then empty name constraint = can
=C2=A0 =C2=A0described by the "invalid" TLD that helps initialize= the name
=C2=A0 =C2=A0constraint path validation set.=C2=A0 Or alternatively it may = be omitted
=C2=A0 =C2=A0if some other name constraint pair, provides a name constraint= of
=C2=A0 =C2=A0that form.=C2=A0 In particular this initialization may be need= ed when
=C2=A0 =C2=A0SmtpUTF8Name is used to represent an email address name constr= aint
=C2=A0 =C2=A0with an UTF-8 local-part and rfc822Name cannot represent such = a email
=C2=A0 =C2=A0address constraint.

may be too concise.=C2=A0 With luck the suggested rationale additions may help readers figure out an appropriate strategy that meets the same
goals, but this text could probably be improved.

<= /div>
What about:

The issuer may wish to dis= tinguish the features of the two different name constraint forms as
well as they can represents names differently.=C2=A0 For example the iss= uer may wish to constraint a name
with A-label differently than U= -label.=C2=A0 Another example is constraining a UTF-8 local-part email
address via SmtpUTF8Name that rfc822Name cannot do.=C2=A0 If the inte= nt is to allow SmtpUTF8Name
subjectAltName, then both name constr= aint forms, rfc822Name and SmtpUTF8Name, must be present though
w= ith some caveats.=C2=A0 If nothing needs be represented by the alternate fo= rm, then the empty name
constraint can be described by the "= invalid" TLD that helps initialize the name constraint path
= validation set.=C2=A0 Or alternatively it may be omitted if some other name= constraint pair, provides a
name constraint of that form.
<= /div>
=C2=A0

-Wei
--001a11431b66645eb2054bf53812-- --001a11431b666cc535054bf53873 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMAQEwAHyjxWs8sJNjMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDMyNTE4NDI0N1oXDTE3MDky MTE4NDI0N1owIjEgMB4GCSqGSIb3DQEJAQwRd2VpaGF3QGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDf/V6s9+sy7fHvy6Z2bKp63d5w85JpcZW9SebsKdycSAUATqgb Gvo6SYD4qMWY3mR+O3LHmJ6WoHqr9xEd7uZ5JxxpfjGhe3MqgS5JaXuKn34q4li1EdMk8F7MB0FD 6VFzmd2OYPpKF8f3d8oyqQUHPnZvoOqCVlO4+fHapq+Rz9++cSI1UbK7KX/kOsi1q+tNEVGP1oVC Cmy/1WK7EEGMOLo2K48AS9T3IP15I1hn/Sj4vVJrpW0rzvRpahOxWKo7SqLcwSRvDvKNue5di7iQ eVceAPcahROEy4P20dimQXpxTVyjQG8wz75b4hwykEgPruaXn1J1usP830/0Tet5AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRF3ZWloYXdAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFF4Fc4YKhOL19j17oEbz6tlaKO/DMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCPihhAVF7RDXtgpruF 0d7ukFX3Ki/I7JD6lTgEGdekylp4bPtLcnIZKM5+JhwalsTbInvGVI6e3VlIyVIOonCf+lIxwC0A enfp52lsFIy12dunCtSJckTlT9LYuxSK5sA4krofdq0ZtSxJ3y8CYHzzolTGaEPqf2BhIpboO4QI zEaRD8w652Rjfo/zP+yI+qYXzACs8erQN0B+8+hT/7Ir8NQcOztDBlNey/ynwE+p1/85y8IHPR8Y Ssm0jF6cpyP/WDat2BbKzT0O1XuZF24UCNxasGcYjYuz3a2+JwQEfSFyFVu/lslEsd8Ehcd9siGL t+pE4LJq0i8cDdnBhWcIMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMAQEwAHyj xWs8sJNjMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCD6rofAnj8s7uGcLV1wFvqm jf5pM6NJFKVGqs75vqz7nDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAzMzAxNjMxMDlaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAyRjNitSQiT8FmVd3tqjzz7jQx/KzvghXWgQ/5YFW EDfzwe2rMPsy4eEoqKyx4z8xwTC65BQ2faRFFCS7PJJJE3389mMPLILlsfPn1/nlC1KaX1wc/pdS DWcfVLdia/05Ksxrtb+GIbSM2Jb1d1GN9gSuMsbiOmC06dNh6LfYLjfln74E92OlRp76rMWnH02W uuXrMDQ4yeu4dD8YrSI+sN7RrxbiGOoENbY24AjiwE5Qg72/o+/0SlGxvPavsVEAJMgeL44rRXIq ef+7duWAi+DIp+TaryVuXtubr1XgZfBEkp8XC50lB2ankkzQZtq7iCQUbNAhCZe0lClLq39pWg== --001a11431b666cc535054bf53873-- From nobody Thu Mar 30 13:42:43 2017 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 68C521294A2 for ; Thu, 30 Mar 2017 13:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 IQpdAxWg0Ol6 for ; Thu, 30 Mar 2017 13:42:30 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDF151294CC for ; Thu, 30 Mar 2017 13:42:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3C990300431 for ; Thu, 30 Mar 2017 16:42:11 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RW4De97irMvf for ; Thu, 30 Mar 2017 16:42:10 -0400 (EDT) Received: from dhcp-8696.meeting.ietf.org (dhcp-8696.meeting.ietf.org [31.133.134.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 853E630022B for ; Thu, 30 Mar 2017 16:42:10 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <8EA15B79-C727-4214-908B-EAA203EB6A25@vigilsec.com> Date: Thu, 30 Mar 2017 16:42:10 -0400 To: SPASM X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [Spasm] LAMPS minute taker and jabber scribe X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 30 Mar 2017 20:42:31 -0000 I need volunteers, please From nobody Fri Mar 31 15:29:40 2017 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 00BFB126DCA for ; Fri, 31 Mar 2017 15:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.397 X-Spam-Level: X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62zGqwpM96z2 for ; Fri, 31 Mar 2017 15:29:37 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 C48621293F4 for ; Fri, 31 Mar 2017 15:29:35 -0700 (PDT) Received: from [10.171.73.68] (unknown [12.125.215.110]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 70EC3509B8; Fri, 31 Mar 2017 18:29:34 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Leonard In-Reply-To: <1488383684.31660.10.camel@redhat.com> Date: Fri, 31 Mar 2017 17:29:34 -0500 Cc: Russ Housley , SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <0EBE3043-BB94-495D-8BB5-BCDB1C7BD6DD@seantek.com> References: <1488362424.31660.6.camel@redhat.com> <1488383684.31660.10.camel@redhat.com> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Spasm] Add SHA-3 to PKIX X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.22 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, 31 Mar 2017 22:29:39 -0000 > On Mar 1, 2017, at 9:54 AM, Nikos Mavrogiannopoulos = wrote: >=20 > On Wed, 2017-03-01 at 10:32 -0500, Russ Housley wrote: >=20 >>>> I agree about not wanting to document stuff that is not going to >>>> be >>>> used. >>>>=20 >>>> The point of this is to get a sounding from the parties that >>>> would be >>>> doing the deployment in CABForum. To pass a ballot has to have a >>>> majority of the Browsers and 2/3rd of the CAs. >>>>=20 >>>> We can't hold a ballot on adding anything to the approved >>>> algorithms >>>> until we have the RFC. But we can have a motion of intent to do >>>> so. >>>=20 >>> I second that. Note also that I already have an implementation of >>> SHA3 >>> for PKIX certificates. >> Did you assign your own OIDs? >=20 > I have used the NIST OIDs. I would implement it (SHA-3) as well, and I would use the NIST OIDs. Regards, Sean