From nobody Fri Jun 2 02:34:04 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E157A129512 for ; Fri, 2 Jun 2017 02:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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=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 p5WRrlX2_Fsj for ; Fri, 2 Jun 2017 02:34:01 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::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 3BD4E129478 for ; Fri, 2 Jun 2017 02:34:01 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id 7so18730352wmo.1 for ; Fri, 02 Jun 2017 02:34:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=0fX2fddxJja90X1nCOmi3L+09lrRMOp/hnpSgqN/su8=; b=o3Yd0rLmFo+UuCjC5mS47uqKvf4pE/BIYjh7qXquLIoQTEO7YuDDKdsjNwbPaPqDZQ aQoEAy2XjR9951A4HQqKawkg5kN11vOGRI+ScvYexDQ9PlPZ1jcxGpPL4pxW6bMiypTf eaQmh1tzXTuxMqnN9jXpozB9Wdie2v0UbgWxbyEK4h/22ukWdb0gEItjIQMq2DgBWZOu qHzopafdyOoTeiybyPLEoq4QIrd6meVvCaAjBzY/wsHzwZJaR0rfxbCD2YG6KTFbT0TF jX/gjAw8aU6OJyu11ImXFl1QvxBv7RlRoJwPlZM52SNHI4r8vGKRg4kNQJE4kVb211QI kxvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=0fX2fddxJja90X1nCOmi3L+09lrRMOp/hnpSgqN/su8=; b=K0nUwois8w4yiejkfj7u3z8JYd+xIa3zzsOD509dORWosN6YgpJfVmhCmUHxzHRY63 u7pasJeSIASaed4B62KpGtICSnSB42Z1iW5i3MHV+bQQIpXq1/a24YKvXqB7nK8CYG66 /oY58qzduzUnGdoKYRFDdF+pYsA1cj2CenOtL3TxrprtfMjHTL1qs61rWQidzFz8z4Pj vLb1jFuAGsP2kdzlhxNej0U5nB5EUWEtvLFhMO6ovKw8iLNd8hfQXoA9XBFFVXJ10Y7P G9NbPWwc/Zb7JvFKP/ckUVP7oZbUo1NBtdq1dCKXdoUpr4Vx3EDUF0OFo9onq7DmxtHU Nqeg== X-Gm-Message-State: AODbwcC6jVZmeI/Dtp77ygOeQOV4wcE4sPJdULpKdRD5UysgN6JqbEqF IY20sHMXJYBHWc1TSB0= X-Received: by 10.223.138.139 with SMTP id y11mr4947313wry.22.1496396039491; Fri, 02 Jun 2017 02:33:59 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-178-58-28.red.bezeqint.net. [79.178.58.28]) by smtp.gmail.com with ESMTPSA id n49sm1200934wrn.30.2017.06.02.02.33.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Jun 2017 02:33:58 -0700 (PDT) From: Yaron Sheffer To: acme@ietf.org References: Message-ID: <2d5695fe-0fcf-1f26-9f94-2df3ef72e419@gmail.com> Date: Fri, 2 Jun 2017 12:33:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Acme] ACME -06: smaller issues X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 09:34:03 -0000 Resending, this post seems to have been lost in the noise. Should I open a PR? Multiple PRs? Thanks, Yaron On 30/05/17 18:52, Yaron Sheffer wrote: > * Order Objects, "authorizations". The text says, "For final orders, > the authorizations that were completed." Are we using "completed" to > mean "successfully completed"? Maybe we should say so explicitly. > > * Directory object: not wishing to be drawn into the TOS discussion > again, but I think the example would be more useful, if the URL was > https://example.com/acme/terms/2017-5-30 instead of > https://example.com/acme/terms, because clients can then detect > changes more easily. > > * Changes of Terms of Service: the example is missing the mandatory > Link header that's mentioned in the text. > > * Account key roll-over: the current check #8 is "Check that the > “newKey” field of the key-change object also verifies the inner JWS." > I think that requiring that "newKey" is bitwise identical to the inner > "jwk" is both strictier and more correct. > > * Account deactivation: shouldn't we also say that all pending Orders > MUST be invalidated? > > * Downloading the Certificate: in the example, the client asks for a > single cert (Accept: application/pkix-cert) and receives a chain > (application/pem-certificate-chain) - is this legal? This also seems > to conflict with the last paragraph of the section. > > * MIME Type: application/pem-certificate-chain - typo: "Carries a > cryptographic certificate" should be "Carries a list of cryptographic > certificates" > > Thanks, > Yaron > From nobody Fri Jun 2 03:36:02 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435ED129AF1 for ; Fri, 2 Jun 2017 03:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-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 LYS_HACBkZej for ; Fri, 2 Jun 2017 03:35:58 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:102:211::1:7]) (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 56EAD126BF0 for ; Fri, 2 Jun 2017 03:35:57 -0700 (PDT) To: acme@ietf.org MIME-Version: 1.0 X-KeepSent: 8A4181BD:23A425F2-C1258133:0039A243; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0.1FP6 Octobe4, 2013 From: Marcos Sanz Message-ID: Date: Fri, 2 Jun 2017 12:35:47 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 02.06.2017 12:35:48, Serialize complete at 02.06.2017 12:35:48 Content-Type: text/plain; charset="US-ASCII" Archived-At: Subject: [Acme] acme-06: Yet more editorial issues plus one real protocol thing X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 10:36:00 -0000 Dear all, please allow a couple of comments from a person who reads the draft for the first time: 1) Structural comment: It is a bit confusing that something like, for instance, chapter "7.3.4 Account Deactivation" is logically ordered under "7.3 Account Creation". Suggestion: Chapter 7.3 should be renamed from "Account Creation" to "Account Administration" and then there should be a new "7.3.1 Account Creation". 2) The challenge object in the example of section 7.1.4 is of type http. It is missing the mandatory fields "url" and "token". 3) Section 7.5.1 says "For example, if the client were to respond to the "http-01" challenge in the above authorization, it would send the following request: POST /acme/authz/asdf/0" However the URI of the refered authorization was /acme/authz/1234/0. As a matter of fact, it looks to me like all six "authz/asdf" occurrences in the draft should be "authz/1234" instead... 4) The example in section 8.2 GET .well-known/acme-challenge/evaGxfADs6pSRb2LAv9IZf17 Host: example.com should be directed to the Host "example.org" which is the domain to be validated, not to "example.com" which is the acme server. And then the body of the response HTTP/1.1 200 OK LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9fm21mqTI looks strange to me. It should match the key authorization, which should start with the token "evaGxfADs6pSRb2LAv9IZf17", and not "Loq..." 5) The text in section 8.4 "For example, if the domain name being validated is "example.com", then the client would provision the following DNS record: acme-challenge.example.com. 300 IN TXT "gfj9Xq...Rg85nM" would better use "example.org" for the same reasons explained above. 6) To make acme a real "REST application" and not just a REST-buzzword freerider, the PUT method should be used consistently for the update of existing resources. For instance, where in 7.5.1 the client "updates back to the server" the details of an existing resource (the challenge) via POST /acme/authz/asdf/0 HTTP/1.1 , it should use instead PUT /acme/authz/asdf/0 HTTP/1.1 Has the latter been discussed before by the working group? Sorry if so, then I'd be thankful for a pointer. Best, Marcos From nobody Fri Jun 2 05:41:37 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11DD12EB62 for ; Fri, 2 Jun 2017 05:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Rei77GHTvUQj for ; Fri, 2 Jun 2017 05:41:33 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 9AC07129515 for ; Fri, 2 Jun 2017 05:41:33 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id f55so57989255qta.3 for ; Fri, 02 Jun 2017 05:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=rSG6kBfzKPCI2n12fbxwH/9OiSn+uz9FhuOdzJunzRc=; b=B5o7p1Tb5rR0JDZTtGyKRFQYv+I17LAmDCYS4eoE9SM3efQVtiuq/h8DnqA39NB69D kyUbY/1OmixcqAmwcRec3K+nktIyduuPPE2AQhO82kQf2vQShCevt44APnAIh3Na7CC+ 6EcaRZm2bVK+cFfmEmVR3/wU7b6a2dZg2TCv2H7Z5FvkhYsE871llkWTg8A8uSNcxyGx HA2mvagtDhFwlHPm/iJns9I++tWOPcvlz45ZZZoXJR/g9a8lewvXZBgqgpmV60zn9Jht PBNwldS4FdgefHhCjedFqPlQAnswbyGeXGO90E5Ba8tzGA7IqiXrmCcqh45T02xf+i2r vl0g== 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=rSG6kBfzKPCI2n12fbxwH/9OiSn+uz9FhuOdzJunzRc=; b=BPtRWSF/Gmhlg1KC0pBdAJxdG1lPrKjiUQC+th4RGxk/BkuS7/p5jFbAvZuqeePwkd 6CpmCT5Ev5C6x9mtA0Cntz0ETbXIAl5YQS4BfCi7sOOQ3m95lhjdBOll/QUJ+zE3wA2P JUgoRI+jV3BoChdNiZpT7A25rLx0dfhZpiqtSOChCKdYEm/Ot3CAXMsdquT1a87LCtGT T+ZTYAT39TqMxc3rl1cOKfa1AyGAZP5bCHrb1C8frrBBktbQNEgQvfU92p8twJEPPZs2 GDlAScGhVzHbSVuPSRKaG0uwjE71S/Czy5srP6Ud0gZ6u7U+B0N2AiRZPJgkn2LRPQ/z MQ8Q== X-Gm-Message-State: AODbwcBFNxhDpiadcaL+RpTuhaMtR2I5pu4m8tfEXEqQdNfEpoV0xEJZ s/NUyoCa4lIYDOgTqPD1E84+7TcNhAg/ X-Received: by 10.200.44.101 with SMTP id e34mr8687991qta.146.1496407292470; Fri, 02 Jun 2017 05:41:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.43.37 with HTTP; Fri, 2 Jun 2017 05:41:31 -0700 (PDT) In-Reply-To: <149640707576.31902.16787330763202651014@ietfa.amsl.com> References: <149640707576.31902.16787330763202651014@ietfa.amsl.com> From: Mary Barnes Date: Fri, 2 Jun 2017 07:41:31 -0500 Message-ID: To: ACME WG Content-Type: multipart/alternative; boundary="001a1145069e1b6a660550f9791e" Archived-At: Subject: [Acme] Fwd: I-D Action: draft-barnes-acme-service-provider-01.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 12:41:36 -0000 --001a1145069e1b6a660550f9791e Content-Type: text/plain; charset="UTF-8" Hi all, We have a made a couple changes around naming - changing the Identifier type to "TNAuthList" and the "token" to "spc-token" to avoid confusion with the "token" in the challenge which we have added to align with the other challenge types. These changes are based on revisions to the ATIS/SIP Forum NNI task group specification, with the latest version of that document available here: http://access.atis.org/apps/group_public/document.php?document_id=34724&wg_abbrev=ipnni Regards, Mary ---------- Forwarded message ---------- From: Date: Fri, Jun 2, 2017 at 7:37 AM Subject: I-D Action: draft-barnes-acme-service-provider-01.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ACME Identifiers and Challenges for VoIP Service Providers Authors : Mary Barnes Chris Wendt Filename : draft-barnes-acme-service-provider-01.txt Pages : 8 Date : 2017-06-02 Abstract: This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for VoIP service providers to support Secure Telephony Identity (STI). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-barnes-acme-service-provider/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-barnes-acme-service-provider-01 https://datatracker.ietf.org/doc/html/draft-barnes-acme-service-provider-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-barnes-acme-service-provider-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --001a1145069e1b6a660550f9791e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

We have a made a couple changes= around naming - changing the Identifier type to "TNAuthList" and= the "token" to "spc-token" to avoid confusion with the= "token" in the challenge which we have added to align with the o= ther challenge types. =C2=A0

These changes are bas= ed on revisions to the ATIS/SIP Forum NNI task group specification, with th= e latest version of that document available here:

Reg= ards,
Mary


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Fri, Jun 2, 2017 at 7:37= AM
Subject: I-D Action: draft-barnes-acme-service-provider-01.txt
To= : i-d-announce@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= ACME Identifiers and Challenges for VoIP Service Providers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mary= Barnes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Chris Wendt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-bar= nes-acme-service-provider-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 8
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-06-02

Abstract:
=C2=A0 =C2=A0This document specifies identifiers and challenges required to= enable
=C2=A0 =C2=A0the Automated Certificate Management Environment (ACME) to iss= ue
=C2=A0 =C2=A0certificates for VoIP service providers to support Secure Tele= phony
=C2=A0 =C2=A0Identity (STI).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-barnes-acme-service-provider/

There are also htmlized versions available at:
https://tools.ietf.org/html/dr= aft-barnes-acme-service-provider-01
https://datatracker.ietf.= org/doc/html/draft-barnes-acme-service-provider-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdif= f?url2=3Ddraft-barnes-acme-service-provider-01


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/m= ailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html<= /a>
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--001a1145069e1b6a660550f9791e-- From nobody Fri Jun 2 05:54:05 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E61127444 for ; Fri, 2 Jun 2017 05:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 (1024-bit key) header.d=isode.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 Yt-6JF7DRpNU for ; Fri, 2 Jun 2017 05:54:02 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 4842B126DCA for ; Fri, 2 Jun 2017 05:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1496408041; d=isode.com; s=june2016; i=@isode.com; bh=S0l8enn+0Ljr5vG82vZ5L7NEt5JDahzX6lmtWf4wiI0=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=TT7LjEo+a1Jj/tPiGwz83JWF6sqk6KMkFUQiUgstvqegC2SKpKkn2ri30jtaQy1U1xVifZ bH9RFpl9LB2AzNOR3yulB3oQc0d/mWF4r5OaQZYGoDt9TBBFxWbOepm6ZtIZmw3MeZYCbb OkhU0n+pFrPVQRsU29gOaWOVOCH/xp0=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 2 Jun 2017 13:54:01 +0100 To: acme@ietf.org References: <149511235670.6643.9258509651795173920@ietfa.amsl.com> From: Alexey Melnikov Message-ID: Date: Fri, 2 Jun 2017 13:53:34 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 In-Reply-To: <149511235670.6643.9258509651795173920@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Acme] Automated Certificate Management Environment (acme) WG Virtual Meeting: 2017-06-02 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 12:54:04 -0000 Hi, On 18/05/2017 13:59, IESG Secretary wrote: > The Automated Certificate Management Environment (acme) Working Group will= hold > a virtual interim meeting on 2017-06-02 from 11:00 to 12:00 America/New_Yo= rk. > > Agenda: > In the early message thread that was labeled =E2=80=9CFutures=E2=80=9D the= following possible work items came up: > Hugo=E2=80=99s CAA draft (already adopted, short, might b= e ready for WGLC) -- https://tools.ietf.org/html/draft-ietf-acme-caa-01 > > The following drafts are possible calls for adoption: > Yaron Sheffer et al draft on STAR -- https://tools.ietf.o= rg/html/draft-sheffer-acme-star-lurk-00 > Mary Barnes on an ACME challenge for ATIS/SIP -- https://= tools.ietf.org/html/draft-barnes-acme-service-provider-00 > Roland Shoemaker on an ACME challenge for validating IP a= ddresses -- https://tools.ietf.org/html/draft-shoemaker-acme-ip-00 > And also Jon Petersonet al https://tools.ietf.org/html/dra= ft-peterson-acme-telephone-00 > > In addition, Alexey is interested in helping with an ACME challenge for em= ail certificates. Is anyone else interested in helping to draft drafting? I appreciate that people probably don't have time to read the draft I've=20 just posted=20 ,=20 but it provides description of new ACME challenges for issuing TLS=20 certificates for email (SMTP, IMAP, etc.) services, as well as a very=20 rough outline of how email address ownership validation can be done for=20 S/MIME. If people find the above useful, I am looking for some co-editors to=20 complete this work. Best Regards, Alexey From nobody Fri Jun 2 07:56:39 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66E812EBD6 for ; Fri, 2 Jun 2017 07:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 OCR5U4kTLlYI for ; Fri, 2 Jun 2017 07:56:34 -0700 (PDT) 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 881CD12EBD2 for ; Fri, 2 Jun 2017 07:56:34 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id p66so44974311qkf.3 for ; Fri, 02 Jun 2017 07:56:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CzyOqVr2Atfw/8gS7BgX0xierWfR163UYZ+sctrJtOA=; b=tef45oYaA8eRSCNBdsVn11dRgcsVH+klm9N/sg3YZ0zLYGszW1ZxkhMdz5lRvoJpwq MNh7T26l60M5ZeWkz88ZNZQp6j4NDV3Ck0yqE5kE8sZu0txeQ68G3HDB3KrUJ+gpX2d8 5CcXQCWqA00kKjMu+mfrW4NeEwj4RrTY7XT4G/ZX9qv9AUv9vL+G2H66My3Fff9og6mg paGxsCcxogw0OIiSvgWAn4fO/q4vIPONTH6UUzH36kmumpe0P0hznAZ0uVlLkSfKtHJi 3wbSUQ+k+M5ntroNGW4jNiVZIeZ/YnGEJ4UTnNSqPUW1I0GZzQKb7r6wUCDqhqObDx50 aNXg== 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=CzyOqVr2Atfw/8gS7BgX0xierWfR163UYZ+sctrJtOA=; b=RSSg8VkXz7xANU6WX3S73a9xIql4ZP9fovDF9ieUVVRYz2bc8QsvH108eJA9PlesOG E4GBd+t/OELwCXBiGSGHWxlMH3yKvuzfLehKbXUNc1ES1Qvpj/BYTJrOAY87vBNouXWi i4aCrvvW6tZGxU1YIbejLgsLJkcV8PFN6UZSQFTmwsanfjAlPVPTHb8muD/w7aXrs5IE LySR3qDKc13g4yXNd0dc9enUKenblu1WQ3i4JuysYghDO/RMI9PqpRatM6FzYCMpI6SD mQ3RkKcPGLg3pIHJ9V9UcD14NuvNhCG3CKEXH8pWdvx5LjItVZhHqYyD/+6eUEjupfq8 0Xkw== X-Gm-Message-State: AKS2vOxwPUZng+pbCM5ow2VeNCMorswbhI8Nb76z4iJHrC/NTdfAvCzI dnyJ1lDgtc82dZ90WC2Nr8h4vLFDeQ== X-Received: by 10.55.154.134 with SMTP id c128mr8374415qke.231.1496415393537; Fri, 02 Jun 2017 07:56:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.63.45 with HTTP; Fri, 2 Jun 2017 07:56:03 -0700 (PDT) In-Reply-To: <2d5695fe-0fcf-1f26-9f94-2df3ef72e419@gmail.com> References: <2d5695fe-0fcf-1f26-9f94-2df3ef72e419@gmail.com> From: Ted Hardie Date: Fri, 2 Jun 2017 07:56:03 -0700 Message-ID: To: Yaron Sheffer Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c054f8ef7e34b0550fb5b24" Archived-At: Subject: Re: [Acme] ACME -06: smaller issues X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 14:56:37 -0000 --94eb2c054f8ef7e34b0550fb5b24 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Opening a PR seems like a reasonable thing; you can split it into multiple PRs if you like, but that's largely a style thing for issues at this scale. Ted On Fri, Jun 2, 2017 at 2:33 AM, Yaron Sheffer wrote= : > Resending, this post seems to have been lost in the noise. Should I open = a > PR? Multiple PRs? > > Thanks, > > Yaron > > > > On 30/05/17 18:52, Yaron Sheffer wrote: > >> * Order Objects, "authorizations". The text says, "For final orders, the >> authorizations that were completed." Are we using "completed" to mean >> "successfully completed"? Maybe we should say so explicitly. >> >> * Directory object: not wishing to be drawn into the TOS discussion >> again, but I think the example would be more useful, if the URL was >> https://example.com/acme/terms/2017-5-30 instead of >> https://example.com/acme/terms, because clients can then detect changes >> more easily. >> >> * Changes of Terms of Service: the example is missing the mandatory Link >> header that's mentioned in the text. >> >> * Account key roll-over: the current check #8 is "Check that the =E2=80= =9CnewKey=E2=80=9D >> field of the key-change object also verifies the inner JWS." I think tha= t >> requiring that "newKey" is bitwise identical to the inner "jwk" is both >> strictier and more correct. >> >> * Account deactivation: shouldn't we also say that all pending Orders >> MUST be invalidated? >> >> * Downloading the Certificate: in the example, the client asks for a >> single cert (Accept: application/pkix-cert) and receives a chain >> (application/pem-certificate-chain) - is this legal? This also seems to >> conflict with the last paragraph of the section. >> >> * MIME Type: application/pem-certificate-chain - typo: "Carries a >> cryptographic certificate" should be "Carries a list of cryptographic >> certificates" >> >> Thanks, >> Yaron >> >> > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --94eb2c054f8ef7e34b0550fb5b24 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Opening a PR seems like a reasonable thing; you can s= plit it into multiple PRs if you like, but that's largely a style thing= for issues at this scale.

Ted

On Fri, Jun 2, 2017 at 2:33 AM, Yaron S= heffer <yaronf.ietf@gmail.com> wrote:
Resending, this post seems to have been lost in the noise. = Should I open a PR? Multiple PRs?

Thanks,

=C2=A0 =C2=A0 Yaron



On 30/05/17 18:52, Yaron Sheffer wrote:
* Order Objects, "authorizations". The text says, "For final= orders, the authorizations that were completed." Are we using "c= ompleted" to mean "successfully completed"? Maybe we should = say so explicitly.

* Directory object: not wishing to be drawn into the TOS discussion again, = but I think the example would be more useful, if the URL was https://example.com/acme/terms/2017-5-30 instead of https://= example.com/acme/terms, because clients can then detect changes mo= re easily.

* Changes of Terms of Service: the example is missing the mandatory Link he= ader that's mentioned in the text.

* Account key roll-over: the current check #8 is "Check that the =E2= =80=9CnewKey=E2=80=9D field of the key-change object also verifies the inne= r JWS." I think that requiring that "newKey" is bitwise iden= tical to the inner "jwk" is both strictier and more correct.

* Account deactivation: shouldn't we also say that all pending Orders M= UST be invalidated?

* Downloading the Certificate: in the example, the client asks for a single= cert (Accept: application/pkix-cert) and receives a chain (application/pem= -certificate-chain) - is this legal? This also seems to conflict with = the last paragraph of the section.

* MIME Type: application/pem-certificate-chain - typo: "Carries a= cryptographic certificate" should be "Carries a list of cryptogr= aphic certificates"

Thanks,
=C2=A0 =C2=A0 Yaron


_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

--94eb2c054f8ef7e34b0550fb5b24-- From nobody Fri Jun 2 08:50:29 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD9212700F for ; Fri, 2 Jun 2017 08:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 guesAuPimM1k for ; Fri, 2 Jun 2017 08:50:26 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (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 89EBB129B70 for ; Fri, 2 Jun 2017 08:50:26 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id v104so9099873wrb.0 for ; Fri, 02 Jun 2017 08:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=eAH931XlyYlcxg6zl3xY3KAfUCwSUfMn+aPnVhJiEos=; b=VSDZg8KD/qRmsTs08uTNjfgx+S4uIGerQgaoZdDkt7mXVMC3Y+/sr719gO81qweU5V Ztj2zunqdXHGcyZc7jVSDi7CXM7zJ4a+aQ3MwlOWmYOamJ3GcFjh/hczkt8lM6f+9SmV pKRgkkJ/M95k7k7joqaBa1MeY86DcW6sFxUUhWDOkWY88i28rgGJiy6zJkZDWwkS5Br5 4gG2lSLCiecd03k8w94zmieaeTRi2GaX45weneshg0mBlr4zMRTxR4nD+S4AzMXzMbnB +gJPykjsN8I23Ap8nGVJ47kso7+kQxnkajkAS+iHE4oBtP5HlR26Af4X/hjWHeGkrlrl jQSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=eAH931XlyYlcxg6zl3xY3KAfUCwSUfMn+aPnVhJiEos=; b=g9tYlI2Z7hGNiJkcwwCXpfU5tf3XjUDmDmHJtBjtRgF31v8xnHOiP9OJcECjoRe8Nq PSPlMEQBSx0VzMzAJNAPSkt9f4RAfmpOxmVHZwfAMYJEhIame2DuMqoLPzIdcyFJdzHD NHrOqfOyKXIM5MSIOAJRmfICWHhDtuzQc83HVoSkWAr2NspqXIY+t4FrW/f4y9MmG44d faJoaGWBDCNAHB5UQmb5ceN4pH3epqXZTxzoGB82Yxjocehwxt4y+fT1IvZuDwDNdzQe 2kk4UHBonUd8av+PgIriVkHkPk2c36Oke0CzFJCefivLNauBaPNhRkzUtEbQt4qhydl/ +gjw== X-Gm-Message-State: AODbwcAllKAXFBFtiKeLUZQy/ihqf4njiEyg4xswm+1KKw6ceF0B/k/R xfx+QaJ/ryoC7oOTeOU= X-Received: by 10.223.149.2 with SMTP id 2mr5372713wrs.46.1496418624803; Fri, 02 Jun 2017 08:50:24 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-178-58-28.red.bezeqint.net. [79.178.58.28]) by smtp.gmail.com with ESMTPSA id y2sm4882170wrd.23.2017.06.02.08.50.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Jun 2017 08:50:24 -0700 (PDT) To: "acme@ietf.org" From: Yaron Sheffer Message-ID: <230386d1-b02d-4316-fd11-9de1bc4f490d@gmail.com> Date: Fri, 2 Jun 2017 18:50:22 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Acme] ACME IP Identifier Validation X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 15:50:28 -0000 Following on comments made in the interim meeting, I would like to request the author to add a few paragraphs to clarify the use case(s) of these IP-based certs and rev the draft, before we go into the adoption discussion on the list. Thanks, Yaron From nobody Fri Jun 2 12:43:18 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4A9129AAA for ; Fri, 2 Jun 2017 12:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spSePfL0AdXp for ; Fri, 2 Jun 2017 12:43:14 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E1E9129C11 for ; Fri, 2 Jun 2017 12:36:17 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v52JVraB008112 for ; Fri, 2 Jun 2017 20:36:15 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=9zm5GexDH0UdegG1UZ3ZMZBvn5lTSwFthFdVZkaQcgU=; b=iWsyTIrDnaWZZ2G0jxP2s3DrNGySNLF4wzvOrc8sJ/xy6Jnue7orjwtibYhqpR3eKcTK nUWLzmXcpxDIyr54qtlc0yw8u6tUiOoeGjhtR2om7ZJFqDW7Qce28MirH2nrtBkvi3nG pAX3AS89sGH09tZBNeEr9YFAX+9rvUqHKmtfg5v17UoAhkxo5scj3TmrsAWbSEgbzEdV 1aqrXEzHaK6MS9/QjU2TnAQi0cW1leVJIG5l7FgjRW6SNKwfeu+JyyOKiIcWFlNKVJow sN0O+BUb3pjArWVv+JxvgMgHCjPDpXH3REJBC/suFIkjPUjmwKje+LjQr4izOH7MdQ+/ Gg== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2au2d6ktfd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 02 Jun 2017 20:36:15 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v52JZPdI000740 for ; Fri, 2 Jun 2017 15:36:14 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2aq4supb76-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 02 Jun 2017 15:36:14 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 2 Jun 2017 15:36:13 -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.1263.000; Fri, 2 Jun 2017 15:36:13 -0400 From: "Salz, Rich" To: ACME WG Thread-Topic: draft minutes from june 2 interim Thread-Index: AdLb1ZnVH2FODVYURIOAiiNYTjNF0Q== Date: Fri, 2 Jun 2017 19:36:13 +0000 Message-ID: <72fa186121d54786b4bf30411726e6b8@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.138] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-02_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706020349 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-02_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706020348 Archived-At: Subject: [Acme] draft minutes from june 2 interim X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 19:43:17 -0000 There were about 20 people present on the call. It lasted about 50 minutes= . Would those who were on the call please post corrections here? Thank yo= u. > Hugo's CAA draft (already adopted, short, might be ready f= or WGLC) -- https://tools.ietf.org/html/draft-ietf-acme-caa-01 Chairs will call for consensus on moving to WGLC. > Yaron Sheffer et al draft on STAR -- https://tools.ietf.or= g/html/draft-sheffer-acme-star-lurk-00 There was discussion on how this overlaps with the tls-subcert document. Af= ter some discussion, there was good consensus to ask that this be split int= o two parts (the ACME-related revalidation and the CDN-related deployment) = and the chairs will ask for consensus on adoption. The split will happen b= efore or after adoption. > Mary Barnes on an ACME challenge for ATIS/SIP -- https://t= ools.ietf.org/html/draft-barnes-acme-service-provider-00 There was some discussion, but strong consensus to adopt this by the WG. C= hairs will confirm on the list. > And also Jon Peterson et al https://tools.ietf.org/html/dra= ft-peterson-acme-telephone-00 Also similar discussion. General agreement to also adopt this, and keep in= close contact with STIR to make sure things progress properly. =20 > Roland Shoemaker on an ACME challenge for validating IP ad= dresses -- https://tools.ietf.org/html/draft-shoemaker-acme-ip-00 Briefly discussed; Yaron requested clarification on the use-case before con= sidering adoption. > In addition, Alexey is interested in helping with an ACME challenge for e= mail certificates. Is anyone else interested in helping to draft drafting? Alex posted a draft just before the meeting. Consensus was to split the SM= TP-server related part and the user S/MIME related part and work on them se= parately. At the end of the meeting, Kathleen pointed out that Ted has a new role as = IAB Chair, and wants to step down from ACME co-chair. The plan would be to = have a new co-chair for Prague, and then after the Prague meeting, for Ted = to abandonXXXXXX relinquish the co-chair role. If you are interested in vo= lunteering, please let Kathleen (and perhaps ekr and the current chairs) kn= ow. Related to this, the ACME base document is almost done. The Chairs strongly= encouraged Richard et al to finish by mid-June so that we could enter WGLC= and address any issues that might come up (if any do) at the Prague meetin= g. Please send/post any corrections by mid-next-week so that we can start the = calls for adoption right away. From nobody Fri Jun 2 13:12:24 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC04124BE8 for ; Fri, 2 Jun 2017 13:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 bBKJqG6ZplHs for ; Fri, 2 Jun 2017 13:12:21 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 474DD1201FA for ; Fri, 2 Jun 2017 13:12:21 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id b84so33452281wmh.0 for ; Fri, 02 Jun 2017 13:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2irYXfPrqo1o4oSBYChAt9Mfv6hb4kf63CazipS/dfk=; b=nPmOHlllshg7IjN/CHfoIZNVZBCw796ikp3RjoUWq3Nk0IQjiLAdx+rgYSB4Y+KK9V XSC3ezWKA6++iMxOw1rouJD8JGAZ1zll+MTsV6akiEybBpCZEKSLXCNHgNeq/L1oV0EB jcqiv5gSiOmHKHAKYVtKdH/gGBxnpVFTcn6+nefEy48c4P4zoNf8KSwntK1r+J4ldzei ZvbhMRIFwdwrNTfeRl8ie68zaUP8G1QIIleQA1iNWNjplf619wsu6p/RZ9lvoxHidy9v p2KYCSiPLtqOPb1/I9TWE0HFvE3dvWrILrFc4KsHtsuwzZY7oZu2PFEKzKO4Oz4BlDgx IwhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2irYXfPrqo1o4oSBYChAt9Mfv6hb4kf63CazipS/dfk=; b=YcElz/hZBFn+D7AHNGqhpRoopKhXSYGZJr3kupixcUPta477tEb38rApaLhw2/W0Lc rxpSFpl7Hkx5rIorYj30XkutaLufuexn64QeEur8q1+hlu+QqPKD+IoYiWUJzQ1LUlZw CS7QlG7Gvi/RX+fLWQvyKNA+QdNF4FmCgTDrbAi8dzN4F1eSyQwXwIe0RJAWD32bdIXu UoGmMBBsQhdrulxKkRomOaSmRWh8BqVo1XxV5yCwfdv3a/4cMCD7KEqLUyWilbHcIumr VrJ1pfJ/UjqBJMnv8hKT698aK+4XRVk6quIBXb9qDAcwHVrrVn3xAN4ZGwdcpcqkQqaL IaYQ== X-Gm-Message-State: AODbwcAVe44FRXhI/0o3GMTp/BBvBwxtkXo5DaiSuJFcZo+g8xgIhnPK 0Om1mKy7d1urOCIBBGI= X-Received: by 10.28.132.210 with SMTP id g201mr640942wmd.26.1496434339106; Fri, 02 Jun 2017 13:12:19 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id s13sm610013wma.21.2017.06.02.13.12.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Jun 2017 13:12:17 -0700 (PDT) From: Yoav Nir Message-Id: <13D10AA2-B480-4758-9C43-B2DA36AEC80D@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_5EAAB0F7-897E-4FFA-99AD-4B2CACB8ACDC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 2 Jun 2017 23:12:15 +0300 In-Reply-To: <72fa186121d54786b4bf30411726e6b8@usma1ex-dag1mb1.msg.corp.akamai.com> Cc: ACME WG To: Rich Salz References: <72fa186121d54786b4bf30411726e6b8@usma1ex-dag1mb1.msg.corp.akamai.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Acme] draft minutes from june 2 interim X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 20:12:23 -0000 --Apple-Mail=_5EAAB0F7-897E-4FFA-99AD-4B2CACB8ACDC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Slight correction On 2 Jun 2017, at 22:36, Salz, Rich wrote: >=20 >=20 >> In addition, Alexey is interested in helping with an ACME challenge = for email certificates. Is anyone else interested in helping to draft = drafting? >=20 > Alex posted a draft just before the meeting. Consensus was to split = the SMTP-server related part and the user S/MIME related part and work = on them separately. The first part is any MTA certificate. It obviously applies to SMTP = servers but also IMAP servers (where they are not co-located with SMTP), = and I suppose also POP3 although the draft doesn=E2=80=99t mention that. The reasoning is that MTAs typically have certificates now (although = many use self-issued) and they have DNS records, so automating the = certificate issuance is clear and straight-forward. Mail users don=E2=80=99t have any central registry ([1]) and in practice = most users don=E2=80=99t have certificates so it=E2=80=99s not clear we = can solve this even if we try. Better to separate the high-risk from = the low-risk. Yoav [1] Claims by all those emails I=E2=80=99m getting telling me that I won = Google=E2=80=99s email address lottery notwithstanding. --Apple-Mail=_5EAAB0F7-897E-4FFA-99AD-4B2CACB8ACDC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZMcafAAoJELhJCxUKWMyZ7KEIAKr7bcqyqDOl0/XiLLP2y0vC W4y07epJdpZ0rUJlkPGVlXnsm5Y9XxdJVjVuY38jkkVWMfTgCag8ELNCHMimvkWz kwHdEGzb9UIeeDXod0K0lLPaHw5zcEiNTdQJwdrIJeCB3ghow9bAOVVdyDJb8Q0N BcXd3UHp51F6DhXb0JmOjKrT7IluueOFW7bWmI+Qfm2hPm1+Z8BSx+koNLDE2SlL 25pN41p2eJR4dBs624rvh06Metqs98bzU/4Lg1mWQ101Ciz7koEPR5OFWYz0NPuO eNZKWNIyVKO5Tokk21raESsdN+c722BimVa4xqRdiM3hBJ15ElQmpAkMY3hIwRw= =a+r7 -----END PGP SIGNATURE----- --Apple-Mail=_5EAAB0F7-897E-4FFA-99AD-4B2CACB8ACDC-- From nobody Fri Jun 2 13:34:59 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDEB5129BB8 for ; Fri, 2 Jun 2017 13:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 58kYyw7Fo6Wu for ; Fri, 2 Jun 2017 13:34:56 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 42492129BE8 for ; Fri, 2 Jun 2017 13:34:56 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id v111so5689840wrc.3 for ; Fri, 02 Jun 2017 13:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=OBvfpW7Zvzqgx0puhZNHij3VvVs58LBN6/DvEA5c+s0=; b=LoTm5j3qRfMusjp7Dko/8TfqKFqCkiZn4hODFaoKeZtEMwd/aztH0iCh7Aq8vH3Xb2 WsKpAwy7aM/Z7gv2VNTytI3KvsLrA2a6SwfqXGEH0FiMStIDqStoDJEbPP3GvWLaRe5y g44u+KIHpP39dnWSxJllIhtj+piXWsRQrATd6WEISwjTjQBnr48nTN/ohGvyP4x/aqt+ rbn1YOA6MxECcnJqSw7AXDk+SBo8p8CbNRo/PT6DBfWiBzNkXkTekFoPfPPoHDuDEfMS HNNoDVzhudY3R8rb47LNCz65FaxoM0tzbC/SeIbhigcO+20F5kxtbLvK4HY8l5OLOQk7 r6vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=OBvfpW7Zvzqgx0puhZNHij3VvVs58LBN6/DvEA5c+s0=; b=diIbNN4ZnqV+AtkaN5SM7RENBjH5/Alo9mLbu1LWrIzcVvfaSfeIauGl+X5gcqfVC0 p5UFut5V8fURJf5PiqIjkTKaYzrNb9AwkonD2xXwRRRDsksAkrVW0mwAt5yAFRDtucJq KwGp6KEFjaXWfV7ku3zSX+tc70qxAO9Y4jfNwfN+YzTc+DUgJaaWOsCn+UQ6IAKERdRW v6/aDLtoCnj68YdMDzptmhh55YNGXllj8iYX7gHXgy5rAHRySFe8+cZbINAlYJr91Yte 6ovJyh7Z6Fb6YAn3l0f9wAJivqU3uLEe0thMUVH3DJXjHTSXdUSVZjemvc0RALbzTwaF 5s1g== X-Gm-Message-State: AODbwcBKuGcm6hofxsZuVN+5DdaaNQr5rKfYYUG1Ka9CzxKyg/3XnN2P 7MuYQFLPzHGOoaFrras= X-Received: by 10.223.132.163 with SMTP id 32mr6278605wrg.154.1496435694357; Fri, 02 Jun 2017 13:34:54 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-178-58-28.red.bezeqint.net. [79.178.58.28]) by smtp.gmail.com with ESMTPSA id l26sm4614576wrl.15.2017.06.02.13.34.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Jun 2017 13:34:53 -0700 (PDT) From: Yaron Sheffer To: "acme@ietf.org" Message-ID: <1d86f12a-f9b8-a16f-48f8-6cb7b95c1d57@gmail.com> Date: Fri, 2 Jun 2017 23:34:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Acme] ACME -06: account key roll-over X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 20:34:58 -0000 I opened PRs for my other comments, but this one is not editorial. There's a long list of checks to be run by the CA for account key roll-over, and the current check #8 is "Check that the “newKey” field of the key-change object also verifies the inner JWS." I think that requiring that "newKey" is bitwise identical to the inner "jwk" is both simpler and a stricter check. In principle there may be two different public keys that verify the same signature, but I don't think we want to see such a case here. Thanks, Yaron From nobody Fri Jun 2 14:01:43 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFA612714F for ; Fri, 2 Jun 2017 14:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 H2jOl-gM0e0R for ; Fri, 2 Jun 2017 14:01:38 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9545112422F for ; Fri, 2 Jun 2017 14:01:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 3178224F0F; Sat, 3 Jun 2017 00:01:37 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id c78UBCHhVDKO; Sat, 3 Jun 2017 00:01:36 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id BD9872319; Sat, 3 Jun 2017 00:01:36 +0300 (EEST) Date: Sat, 3 Jun 2017 00:01:33 +0300 From: Ilari Liusvaara To: Yoav Nir Cc: Rich Salz , ACME WG Message-ID: <20170602210133.GA20935@LK-Perkele-V2.elisa-laajakaista.fi> References: <72fa186121d54786b4bf30411726e6b8@usma1ex-dag1mb1.msg.corp.akamai.com> <13D10AA2-B480-4758-9C43-B2DA36AEC80D@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <13D10AA2-B480-4758-9C43-B2DA36AEC80D@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] draft minutes from june 2 interim X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 21:01:41 -0000 On Fri, Jun 02, 2017 at 11:12:15PM +0300, Yoav Nir wrote: > Slight correction > > On 2 Jun 2017, at 22:36, Salz, Rich wrote: > > > > > >> In addition, Alexey is interested in helping with an ACME challenge for email certificates. Is anyone else interested in helping to draft drafting? > > > > Alex posted a draft just before the meeting. Consensus was to split the SMTP-server related part and the user S/MIME related part and work on them separately. > > The first part is any MTA certificate. It obviously applies to SMTP servers but also IMAP servers (where they are not co-located with SMTP), and I suppose also POP3 although the draft doesn’t mention that. > > The reasoning is that MTAs typically have certificates now (although many use self-issued) and they have DNS records, so automating the certificate issuance is clear and straight-forward. One thing to note is that only mail-related port that is currently allowed for "server" type validation in CABForum BRs is port 25. So for IMAP, one would presumably want to get port 993 (IMAPS) added to that list. And 587 (SUBMISSION) could be another candidate. Also, AFAIK, port 465 is not actually SMTPS, but something totally unrelated to mail. It is also one of the dirtiest TCP port out there. You can not assume it works even between consenting endpoints (there are boxes that capture port 465 connections, even if not addressed to them). -Ilari From nobody Sat Jun 3 03:25:50 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66AA126D74 for ; Sat, 3 Jun 2017 03:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 Y3u_nxhtLv4y for ; Sat, 3 Jun 2017 03:25:47 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id BDDCB126BF6 for ; Sat, 3 Jun 2017 03:25:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 42E9E20779; Sat, 3 Jun 2017 13:25:45 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id vD8rrPX3oD-t; Sat, 3 Jun 2017 13:25:45 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 11B2D286; Sat, 3 Jun 2017 13:25:45 +0300 (EEST) Date: Sat, 3 Jun 2017 13:25:41 +0300 From: Ilari Liusvaara To: Yaron Sheffer Cc: "acme@ietf.org" Message-ID: <20170603102541.GA22362@LK-Perkele-V2.elisa-laajakaista.fi> References: <1d86f12a-f9b8-a16f-48f8-6cb7b95c1d57@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1d86f12a-f9b8-a16f-48f8-6cb7b95c1d57@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] ACME -06: account key roll-over X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 10:25:50 -0000 On Fri, Jun 02, 2017 at 11:34:51PM +0300, Yaron Sheffer wrote: > I opened PRs for my other comments, but this one is not editorial. > > There's a long list of checks to be run by the CA for account key roll-over, > and the current check #8 is "Check that the “newKey” field of the key-change > object also verifies the inner JWS." I think that requiring that "newKey" is > bitwise identical to the inner "jwk" is both simpler and a stricter check. > In principle there may be two different public keys that verify the same > signature, but I don't think we want to see such a case here. Yeah, violation of DRY principle causing problems. The standard signature security notion does not preclude various unpleasant things, like: - Key recovery (compute a public key that verifies a given signature for a given message). - Aliases (two keys that validate the same things) - Weak keys (keys that admit signatures that validate for all messages). (Plus variations where probability of those things happening is high, or "bad" keys not being efficiently recognizable). And weak keys could be even nastier here than aliases here. IIRC CryptoNote had a vulernability due to misusing Ed25519 in a way that was weak to weak keys (there are 8 such keys for Ed25519). -Ilari From nobody Tue Jun 6 08:24:56 2017 Return-Path: X-Original-To: acme@ietf.org Delivered-To: acme@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D16B128B8E; Tue, 6 Jun 2017 08:24:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: Kathleen.Moriarty.ietf@gmail.com, acme@ietf.org, smccammon@amsl.com, acme-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.53.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149676269427.3975.6955527144861088616.idtracker@ietfa.amsl.com> Date: Tue, 06 Jun 2017 08:24:54 -0700 Archived-At: Subject: [Acme] acme - New Meeting Session Request for IETF 99 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2017 15:24:54 -0000 A new meeting session request has just been submitted by Stephanie McCammon, on behalf of the acme working group. --------------------------------------------------------- Working Group Name: Automated Certificate Management Environment Area Name: Security Area Session Requester: Stephanie McCammon Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: httpbis sidr rtcweb tls perc Second Priority: dprive tcpinc uta dispatch netvc cfrg ace Third Priority: maprg hrpc irtfopen opsec People who must be present: Eric Rescorla Rich Salz Stephen Farrell Kathleen Moriarty Martin Thomson Richard Barnes Ted Hardie Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Jun 7 05:50:32 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E472E12EC10 for ; Wed, 7 Jun 2017 05:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 XlaIA22lhQov for ; Wed, 7 Jun 2017 05:50:30 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 4269F129459 for ; Wed, 7 Jun 2017 05:50:30 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id q15so5371124uaa.2 for ; Wed, 07 Jun 2017 05:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=oh9OddPR6PrXRc7IgxwrtMVw8kDcrOuAOiX4+Z1FNNY=; b=I0NGJCfeLkBVcW7dY9T2GIJeh+e0zW0xp9+I/PqHzma5mUv5igz4cntViWbreNAQq5 m6sfaNP12aWQxF7d8zo3+VCzGwrH4hyPuNkVYkAFDfhNCbPxmQQrfk2YfWT2gOGdA9rs xKDanVpoz3N0eY5svwLLVAh4+HTnu0AjbE9Z0qbHI5ZwhcsSSuDHu/VcKvjJDGR5X0pT iCnk/G6xoWdIsiqHf65hwLAHRK5fd0nUSjepamsDu/yKDWt+Y5t7KqMholkRZ0OPOQOB LwKy5zgorgFDygwOgh8IAo7vrZgRYh7ICap5nc/YeeC8i+g9g/h9Z8JVJhFT1UyVkAUR OQ+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=oh9OddPR6PrXRc7IgxwrtMVw8kDcrOuAOiX4+Z1FNNY=; b=DGk9KHmMVGU8h9yKlo+tduZRlWOIAlsbyP1QZilhdEZB5JO5ZTXnrIR6yfo6Gal8vG hLIgvhJyikA8RzObqpfRNyPWD0MtN0VEHKNEtFFq0fPrE1w9FH6VbKOLTsT+U0uaW06i CMBwOOwCq6qCNMC/liXS7N3+1NDIncJFysvgtq9ZZEHw9jaUZLBTJtLmIQRF42tVn6my tyzZnLxagIuhbtGytGtrjQU+bPmTpkJ5v0dqGuJRIlBDs/2q7ZkBek4EWG4BLrHpmmu0 N2nQgzoAe9pQfqY5n9ibRxz/GY/XzdDe+6SLWXu1lPB1u9I8pgJCRNO+9+vgGZgFIXCO lP6Q== X-Gm-Message-State: AODbwcBCzjbcVP/KkvKpGzG1C2oNBYFoKTMep24dm2Cowusf88MTBRON e1s4gRspc1alcNlI5EMfa7hciiwZiA== X-Received: by 10.176.17.216 with SMTP id q24mr13911612uac.96.1496839829208; Wed, 07 Jun 2017 05:50:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.76.91 with HTTP; Wed, 7 Jun 2017 05:50:28 -0700 (PDT) From: Rifaat Shekh-Yusef Date: Wed, 7 Jun 2017 08:50:28 -0400 Message-ID: To: acme@ietf.org Content-Type: multipart/alternative; boundary="f403043664204e49a105515e2e18" Archived-At: Subject: [Acme] ACME v06 - Pre-Authorization X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 12:50:32 -0000 --f403043664204e49a105515e2e18 Content-Type: text/plain; charset="UTF-8" Hi, I am exploring the idea of using ACME for issuing certificates for endpoints using the Pre-Authorization process, and I have a question about that process. I reviewed the editor's version published May 22, 2017. Section 7.4.1. Pre-Authorization states that after the client sends a request and received a valid response, that the client would then follow the process of section 7.5 Identifier Authorization. This seems to assume that the client will be able to complete the authorization process before it sends the certificate issuance request, and without the involvement of the virtual server (or endpoint in my case). What is the expected behavior of the server if the client sends the certificate issuance request after it sends the pre-authorization request but before it completes the pre-authorization process? Also, since the pre-authorization process is expected to deal with multiple servers/endpoints requesting certificates, should this process be enhanced to support bulk requests? Nits: * Section 7.3.5, first paragraph, second line: A "bind" word is missing between the words "to" and "an" * Section 7.4.1, - second paragraph, second sentence: "case" should be "cases". - When the server builds the authorization object, the document is stating that the response would include "challenges" and "combinations". Remove the "combinations" as it is not being used. * Section 7.5.1, the Request URIs in the examples: Should not this be /acme/authz/1234/0? Regards, Rifaat --f403043664204e49a105515e2e18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I am exploring the idea = of using ACME for issuing certificates for
endpoints using the Pr= e-Authorization process, and I have a question about
that process= .

I reviewed the editor's version published Ma= y 22, 2017.


Section 7.4.1. Pre-Auth= orization states that after the client sends a
request and receiv= ed a valid response, that the client would then follow
the proces= s of section 7.5 Identifier Authorization. This seems to assume
t= hat the client will be able to complete the authorization process before
it sends the certificate issuance request, and without the involvem= ent of
the virtual server (or endpoint in my case).
What is the expected behavior of the server if the client sends= the
certificate issuance request after it sends the pre-authoriz= ation request but=C2=A0
before it completes the pre-authorization= process?

Also, since the pre-authorization proces= s is expected to deal with multiple
servers/endpoints requesting = certificates, should this process be enhanced
to support bulk req= uests?


Nits:

* Section 7.3.5, first paragraph, second line:
=C2=A0 A "= bind" word is missing between the words "to" and "an&qu= ot;


* Section 7.4.1,
=C2= =A0 - second paragraph, second sentence: "case" should be "c= ases".
=C2=A0 - When the server builds the authorization obj= ect, the document is
=C2=A0 =C2=A0 stating that the response woul= d include "challenges" and "combinations".
= =C2=A0 =C2=A0 Remove the "combinations" as it is not being used.<= /div>

* Section 7.5.1, the Request URIs in the examples:=
=C2=A0 Should not this be /acme/authz/1234/0?


Regards,
=C2=A0Rifaat

<= /div> --f403043664204e49a105515e2e18-- From nobody Wed Jun 7 11:08:15 2017 Return-Path: X-Original-To: acme@ietf.org Delivered-To: acme@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 554FE129ADE; Wed, 7 Jun 2017 11:08:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: Kathleen.Moriarty.ietf@gmail.com, acme@ietf.org, smccammon@amsl.com, acme-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.53.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149685889425.2604.11862422803630037277.idtracker@ietfa.amsl.com> Date: Wed, 07 Jun 2017 11:08:14 -0700 Archived-At: Subject: [Acme] acme - Update to a Meeting Session Request for IETF 99 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 18:08:14 -0000 An update to a meeting session request has just been submitted by Stephanie McCammon, on behalf of the acme working group. --------------------------------------------------------- Working Group Name: Automated Certificate Management Environment Area Name: Security Area Session Requester: Stephanie McCammon Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: httpbis sidr rtcweb tls perc stir Second Priority: dprive tcpinc uta dispatch netvc cfrg ace Third Priority: maprg hrpc irtfopen opsec People who must be present: Eric Rescorla Rich Salz Stephen Farrell Kathleen Moriarty Martin Thomson Richard Barnes Ted Hardie Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Jun 7 13:58:30 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A481128D6F for ; Wed, 7 Jun 2017 13:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=letsencrypt.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcSeZs7nAFfr for ; Wed, 7 Jun 2017 13:58:25 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (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 B1DD1128854 for ; Wed, 7 Jun 2017 13:58:25 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id k71so9029671pgd.2 for ; Wed, 07 Jun 2017 13:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=jyvHSZkAD5/hPcaj5bqUiMzzeBTUwT2SUb0XDnIeNjU=; b=BpA44K4pOxz27ypcp55xLrLRuLQm45QUrqE/3txVv9BHA3j+C8PHyzGyFgXhU0yH1a W6iX0HOntLF6Zw7g3hjglHZiZgOOcLWRJ9yikExtrN9XTzRknJ6RQs8mYiC6S5ibX/pC V13Y7Kl0+LjdX5Vh4I8IEobYFmQwGTtnPb/C8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jyvHSZkAD5/hPcaj5bqUiMzzeBTUwT2SUb0XDnIeNjU=; b=OMHTm+qohbLWW5OV8pLoO2BEoP+udmcq2LlJW11PJt1Ai/QMuIewPIeSfrfzMg1QVQ 7JIR9reotl5fpvEzleXL/Bj8HOzyTX/XEE/HRzlvrS4yJ0M7pP8hCDraHn2lBWjbqWYj iY2JSwCbQnOUJsMfbKfoXAlOofsU8yzfK8BOuGvxjKv5G6j+14mjZ6tLWIX64wyPxfb2 AXpzZZrCgBJI5URkaDuTWYVHNrufzsuokLeV9tZetUy5gC1tf2TWeiGsLHlFIWM5kY9N h7uxnSKYi4npPlcAY3Lgh47au3HXMIJ633M5ps5BQhfW/Q8op+xkBcGISah0cSouuFmY CgaA== X-Gm-Message-State: AODbwcDIJmWQAjkp6nnaTmmZiKFD+qCn8P1fvZpXgCiGft+wzzr1CUiR x95PaLQyv3e5uNPG8BrUzQ== X-Received: by 10.99.141.200 with SMTP id z191mr22079671pgd.99.1496869104886; Wed, 07 Jun 2017 13:58:24 -0700 (PDT) Received: from [10.120.0.195] (eff.static.monkeybrains.net. [208.90.213.162]) by smtp.gmail.com with ESMTPSA id 15sm6011885pfk.115.2017.06.07.13.58.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jun 2017 13:58:24 -0700 (PDT) To: acme@ietf.org References: <72fa186121d54786b4bf30411726e6b8@usma1ex-dag1mb1.msg.corp.akamai.com> From: Roland Shoemaker Message-ID: <06214217-70e8-d3e2-9ad0-8e6d195a8385@letsencrypt.org> Date: Wed, 7 Jun 2017 13:58:23 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <72fa186121d54786b4bf30411726e6b8@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] draft minutes from june 2 interim X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 20:58:28 -0000 Sorry I wasn't able to make it for this call, comments inline: On 06/02/2017 12:36 PM, Salz, Rich wrote: > There were about 20 people present on the call. It lasted about 50 minutes. Would those who were on the call please post corrections here? Thank you. > > >> Hugo's CAA draft (already adopted, short, might be ready for WGLC) -- https://tools.ietf.org/html/draft-ietf-acme-caa-01 > > Chairs will call for consensus on moving to WGLC. > >> Yaron Sheffer et al draft on STAR -- https://tools.ietf.org/html/draft-sheffer-acme-star-lurk-00 > > There was discussion on how this overlaps with the tls-subcert document. After some discussion, there was good consensus to ask that this be split into two parts (the ACME-related revalidation and the CDN-related deployment) and the chairs will ask for consensus on adoption. The split will happen before or after adoption. > >> Mary Barnes on an ACME challenge for ATIS/SIP -- https://tools.ietf.org/html/draft-barnes-acme-service-provider-00 > > There was some discussion, but strong consensus to adopt this by the WG. Chairs will confirm on the list. > >> And also Jon Peterson et al https://tools.ietf.org/html/draft-peterson-acme-telephone-00 > > Also similar discussion. General agreement to also adopt this, and keep in close contact with STIR to make sure things progress properly. > >> Roland Shoemaker on an ACME challenge for validating IP addresses -- https://tools.ietf.org/html/draft-shoemaker-acme-ip-00 > > Briefly discussed; Yaron requested clarification on the use-case before considering adoption. I think there are two main use-cases for this: people who want certificates for public IPv4/6 addresses which is not incredibly common but is a feature offered by a number of existing commercial CAs, and is therefore something ACME should attempt to provide parity with; and people who want to use ACME in an internal non-public CA for generating certificates for various services which use them for, i.e., RPC endpoint authentication. > >> In addition, Alexey is interested in helping with an ACME challenge for email certificates. Is anyone else interested in helping to draft drafting? > > Alex posted a draft just before the meeting. Consensus was to split the SMTP-server related part and the user S/MIME related part and work on them separately. > > At the end of the meeting, Kathleen pointed out that Ted has a new role as IAB Chair, and wants to step down from ACME co-chair. The plan would be to have a new co-chair for Prague, and then after the Prague meeting, for Ted to abandonXXXXXX relinquish the co-chair role. If you are interested in volunteering, please let Kathleen (and perhaps ekr and the current chairs) know. > > Related to this, the ACME base document is almost done. The Chairs strongly encouraged Richard et al to finish by mid-June so that we could enter WGLC and address any issues that might come up (if any do) at the Prague meeting. > > Please send/post any corrections by mid-next-week so that we can start the calls for adoption right away. > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > -- Roland Bracewell Shoemaker Software Engineer Linux Foundation / Internet Security Research Group From nobody Thu Jun 8 08:16:04 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304771205D3 for ; Thu, 8 Jun 2017 08:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 KlHJm_RFdVBl for ; Thu, 8 Jun 2017 08:16:01 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 924B8124D85 for ; Thu, 8 Jun 2017 08:16:01 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v58FCJtl000591 for ; Thu, 8 Jun 2017 16:16:00 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=FAzxRurOpAgIIiv8cyHiS+VrDXAigDa1k4TRjYA1Y5s=; b=UuqlQP5JGaMVkBdMJ1LG0YDxpesBnne+ANafDFhX+FL5Shah1kZHvU4C6dZn21jt/bzK XffjuEjkr3Lrd/8E1qiBZMdatSMybw5YVNEGBZAQwEFvH8nHbPgmyiwCL5r4dLVOfg7w wsof6sJHF9pWDLHJK4+yJa11LMA+6dIrtYwUw4mOhiahCtZ8T8sP2npse4p3AO3DLpdp ADr2eIgyPyfbpElyuHScpmypE6v4ne1ZVfJjM+7Ft/kV8r04YCT4IkkJZAQuDEc+rSN1 jUGylawE7F6P51NMndLckZZfmzXx/KKk46zEg0OrXPTJRsVuJr7eTc+ZhoDQO11nEolc Tw== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2ay1tmab4c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 08 Jun 2017 16:15:59 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v58FAbKg027444 for ; Thu, 8 Jun 2017 11:15:58 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2aurevadsb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 08 Jun 2017 11:15:58 -0400 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.1263.5; Thu, 8 Jun 2017 08:15:57 -0700 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.1263.000; Thu, 8 Jun 2017 11:15:57 -0400 From: "Salz, Rich" To: "acme@ietf.org" Thread-Topic: [Acme] draft minutes from june 2 interim Thread-Index: AQHS39EfGBa2yYr51EOmd2sbytSgtqIbFFNw Date: Thu, 8 Jun 2017 15:15:57 +0000 Message-ID: <935ade582fdb4ab1bae1e74cec9ea940@usma1ex-dag1mb1.msg.corp.akamai.com> References: <72fa186121d54786b4bf30411726e6b8@usma1ex-dag1mb1.msg.corp.akamai.com> <06214217-70e8-d3e2-9ad0-8e6d195a8385@letsencrypt.org> In-Reply-To: <06214217-70e8-d3e2-9ad0-8e6d195a8385@letsencrypt.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.34.112] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-08_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706080273 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-08_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706080273 Archived-At: Subject: Re: [Acme] draft minutes from june 2 interim X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 15:16:03 -0000 The minutes for the June 2 interim are now available: https://datatracker.ietf.org/doc/minutes-interim-2017-acme-01-20170602110= 0/ The next couple of messages will be to call for various WG adoptions and WG= LC. From nobody Thu Jun 8 08:28:02 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E659129476 for ; Thu, 8 Jun 2017 08:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCY0sElaFU1Y for ; Thu, 8 Jun 2017 08:27:58 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C59ED129466 for ; Thu, 8 Jun 2017 08:27:58 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v58FRwhB019425 for ; Thu, 8 Jun 2017 16:27:58 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=4luCd+b5QYYFd863bDNxCOYD3a9koFHTSfRVG0H6FZs=; b=YdYlx62/PCD1kXMN9wEL+kBgADiEO5x6+EIlxeyvTFY29b9CSBqrBhIc5wbS9IQh3Iov MEMUhNWzOWJQlkKSMpUPhkXP12xottUeu5ZCuSW6EGHV16F0Ljr7w0prFI3ajEnDspwu C9b5vga2KxBLHOnTGOhOL7HxgjNbnU8/v4ie2HXnBGLlck/wczZzFNvP9PACk3JGzSBs f0PCHBY2f1f2xdLhsH6PWkLPHGf8N1taywjBabs3BUK0eGemfEXu8EFUD/kvDHQEACUx BspfHDCC8wp+johVE9CpiOY3ngpq2MzFujCiJiQf/NFFE3jDV/lb1eJ+kfDdE8s2k4bX Gw== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2ay1tmadra-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 08 Jun 2017 16:27:58 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v58FQBYG024571 for ; Thu, 8 Jun 2017 11:27:57 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2aurev2f5a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 08 Jun 2017 11:27:56 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 8 Jun 2017 11:27:56 -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.1263.000; Thu, 8 Jun 2017 11:27:56 -0400 From: "Salz, Rich" To: "acme@ietf.org" Thread-Topic: Consensus -- CAA draft to WGLC? Thread-Index: AdLgaixZ2HxcGKQGRUWoL8+FK3tFFw== Date: Thu, 8 Jun 2017 15:27:56 +0000 Message-ID: <40e652477a2f47b0848330e64f72e8b2@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.34.112] Content-Type: multipart/alternative; boundary="_000_40e652477a2f47b0848330e64f72e8b2usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-08_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706080277 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-08_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706080277 Archived-At: Subject: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 15:28:00 -0000 --_000_40e652477a2f47b0848330e64f72e8b2usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >> Hugo's CAA draft (already adopted, short, might be >> ready for WGLC) -- https://tools.ietf.org/html/draft-ietf-acme-caa-01 This has moved to WGLC. If you know of any reason why it should not advanc= e to the IESG, please post by end of next week. If you are willing to be the document shepherd for this document (see https= ://www.ietf.org/iesg/template/doc-writeup.html; an essay style writeup is f= ine), please let the chairs know soon. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz --_000_40e652477a2f47b0848330e64f72e8b2usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>>       = ;         Hugo's CAA draft (already= adopted, short, might be

>> ready for WGLC) -- https://tools.ietf.org/html/draft-ietf-acme-caa-01

 

This has moved to WGLC.  If you know of any rea= son why it should not advance to the IESG, please post by end of next week.=

 

If you are willing to be the document shepherd for t= his document (see https://www= .ietf.org/iesg/template/doc-writeup.html; an essay style writeup is fin= e), please let the chairs know soon.

 

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

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

 

--_000_40e652477a2f47b0848330e64f72e8b2usma1exdag1mb1msgcorpak_-- From nobody Thu Jun 8 08:32:29 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F04F128B90 for ; Thu, 8 Jun 2017 08:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ki9rk6bEVPS7 for ; Thu, 8 Jun 2017 08:32:26 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D322F128B51 for ; Thu, 8 Jun 2017 08:32:26 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v58FRllQ008854 for ; Thu, 8 Jun 2017 16:32:25 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=pG4kP5kdMmp2m4SqjsHlthRSGq3sOmiwVzWC8S9dx+s=; b=SY9hemgW52L9MwzU237JxjoKoOs5TXNm8gLAfnakKtWi6xerdpwpcRbWgPfzkNilZ6iX umLDwfzJkTYqmPNa7eCYwCeWDtztCJB9qbEEITq3dpoIFEY1dPw8/cejr1/KAIRgVvWA h95FDxsQGjN3Gi8G9ayrcDXGoIvub7N/ffzyYDqoccMkyb98n2rKexvU+xed2c8gUFwS UnWmtsNERr4bNaT6WVkdvBEEPQl8crgqeP6Cv48NbYZCd0hlNy/pF/r/0Pi25Bki69dY WVXNEN+9zbgckHjiiUXJl3PyxKhJeQg9Kfd+Q496H7wQvnjcFXSnTV2fCMkNQUFViK+Q vA== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2ay024313j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 08 Jun 2017 16:32:25 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v58FVTRi028424 for ; Thu, 8 Jun 2017 11:32:23 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2aurev2fnj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 08 Jun 2017 11:32:23 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb3.msg.corp.akamai.com (172.27.123.58) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 8 Jun 2017 11:32:23 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 8 Jun 2017 11:32:23 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Thu, 8 Jun 2017 11:32:23 -0400 From: "Salz, Rich" To: "acme@ietf.org" Thread-Topic: Call for adoption; (1) ACME challenge for ATIS/SIP (2) identifiers and challenges for telephone numbers Thread-Index: AdLgbEQuVuUjEnvcQcyaedMqYdi3kQ== Date: Thu, 8 Jun 2017 15:32:22 +0000 Message-ID: <615c6cca39444b0db7a4e3c960576c40@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.34.112] Content-Type: multipart/alternative; boundary="_000_615c6cca39444b0db7a4e3c960576c40usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-08_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706080278 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-08_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706080277 Archived-At: Subject: [Acme] Call for adoption; (1) ACME challenge for ATIS/SIP (2) identifiers and challenges for telephone numbers X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 15:32:28 -0000 --_000_615c6cca39444b0db7a4e3c960576c40usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At the interim we had strong consensus to adopt these two drafts as WG docu= ments. I am grouping them in a single email because they are related, and = to point out that with both of these we will be collaborating with the STIR= WG. If you feel it is not appropriate for us to adopt, please post to the list = by the end of next week: https://tools.ietf.org/html/draft-barnes-acme-service-provider-00 https://tools.ietf.org/html/draft-peterson-acme-telephone-00 -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz --_000_615c6cca39444b0db7a4e3c960576c40usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

At the interim we had strong consensus to adopt thes= e two drafts as WG documents.  I am grouping them in a single email be= cause they are related, and to point out that with both of these we will be= collaborating with the STIR WG.

 

If you feel it is not appropriate for us to adopt, p= lease post to the list by the end of next week:

    https://tools.ietf.org/html/draft-barnes-acme-service-provider-00<= /o:p>

 

    https://tools.ietf.org/html/draft-peterson-acme-telephone-00

 

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

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

 

--_000_615c6cca39444b0db7a4e3c960576c40usma1exdag1mb1msgcorpak_-- From nobody Thu Jun 8 08:35:53 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D189128B90 for ; Thu, 8 Jun 2017 08:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qXc4pd9_hYN for ; Thu, 8 Jun 2017 08:35:50 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6771A1243F3 for ; Thu, 8 Jun 2017 08:35:50 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v58FXHCJ014792 for ; Thu, 8 Jun 2017 16:35:50 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=EThcds+NzypkaYE3UCxxmsUNfwxj6DT/i4EWqwYd0Ww=; b=kBpd7EGNrpazT53eApLfxskrYfy9YoUguh5R5npph1fiO4TV8bg/Y3hFP09eI41uwfwp IFJhCYCVQMNV9aWUVftGOWbMIxEsI0aJyhkoZ/3ONm3srs1TFELBizu+zF2yjTCRCinM dQYPzUZEEocyoJb4oq90F+STXzb8JKzSYnkP9mYWkxJTwKKUs2fjdADOmXZS88mmlCJb 0xcCICZMGe/KSvJHSG/rY9KAqfunpphNVfTv1e5kP9NvYEcwGdDNxPygBBrkPjkGAOLK sR/KjuY32Jm5n9FE4X7SRD5sqs8kz/2BJE9+DRBgnx3N5gltRXGIVKHGs099vDGdGpCY Sw== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2ay02431tu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 08 Jun 2017 16:35:49 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v58FVTIj009503 for ; Thu, 8 Jun 2017 11:35:48 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2aurevag16-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 08 Jun 2017 11:35:48 -0400 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.1263.5; Thu, 8 Jun 2017 08:35:47 -0700 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.1263.000; Thu, 8 Jun 2017 11:35:47 -0400 From: "Salz, Rich" To: "acme@ietf.org" Thread-Topic: Adopt two email-related drafts Thread-Index: AdLgbJuc0dhEqbWLTtCs5mdI02qNtw== Date: Thu, 8 Jun 2017 15:35:47 +0000 Message-ID: <80560dd786e74f0c89f8858a7f1981d1@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.34.112] Content-Type: multipart/alternative; boundary="_000_80560dd786e74f0c89f8858a7f1981d1usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-08_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706080278 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-08_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706080278 Archived-At: Subject: [Acme] Adopt two email-related drafts X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 15:35:52 -0000 --_000_80560dd786e74f0c89f8858a7f1981d1usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At the interim, we had strong consensus to adopt Alexsey's draft (was one, = is now two) on ACME challenges and certs for email services and users: https://datatracker.ietf.org/doc/draft-melnikov-acme-email-smime/ https://datatracker.ietf.org/doc/draft-melnikov-acme-email-tls/ If you are opposed to adoption, please post to the list by the end of next = week. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz --_000_80560dd786e74f0c89f8858a7f1981d1usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

At the interim, we had strong consensus to adopt Ale= xsey’s draft (was one, is now two) on ACME challenges and certs for e= mail services and users:

 

  https://datatracker.ietf.org/doc/draft-melnikov-acme-email-smime/<= /o:p>

 

  https://datatracker.ietf.org/doc/draft-= melnikov-acme-email-tls/

 

If you are opposed to adoption, please post to the l= ist by the end of next week.

 

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

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

 

--_000_80560dd786e74f0c89f8858a7f1981d1usma1exdag1mb1msgcorpak_-- From nobody Thu Jun 8 08:40:47 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB3D128DF3 for ; Thu, 8 Jun 2017 08:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYvGvjhfUezW for ; Thu, 8 Jun 2017 08:40:43 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAF4A128C81 for ; Thu, 8 Jun 2017 08:40:43 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v58FXJaG026203 for ; Thu, 8 Jun 2017 16:40:43 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=UlUr2DIL1jYi2+GFCRsahEWgULjGCqhc/RafnBYDo7Y=; b=VY999ozXA898VRdyRpoAKDQF33kF2NGZr5pOJktZ//CdR3k/gejj9yeWmikdtFWxDQh9 J5f9q3FZXr/YPWZ0/CA7+S1HMUkWU25HYf7DuxDVLDkRn0FCGZxWsAU+X+u2wOgPViOC 2FIUboOSXEPLRIk2yJqq023o8eFgDbT7GHwVhEY1nsJU0G0C1uH1JpWLc7hURtGlABCx QcGZHYwl75EkRGcqkJMjqje/w+l56xYHwMNS8bU/VmbXAK1klbDtRCRXk0H7Sg3GEY83 dWDjM19TYWdaAzwq1LTY9NzOFn5PKj3vk1KuoGMY+aj3Nnj7UgDXTOAYWf9+wrlAJQ1H Rw== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2ay1tmagev-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 08 Jun 2017 16:40:43 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v58FVVUZ009097 for ; Thu, 8 Jun 2017 11:40:42 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint3.akamai.com with ESMTP id 2avfe5kfge-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 08 Jun 2017 11:40:41 -0400 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.1263.5; Thu, 8 Jun 2017 11:40:40 -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.1263.000; Thu, 8 Jun 2017 11:40:40 -0400 From: "Salz, Rich" To: "acme@ietf.org" Thread-Topic: Call for adoption, ACME challenge for validating IP addresses Thread-Index: AdLgbWF13pMUk2nZRU6p+WHHuooPGA== Date: Thu, 8 Jun 2017 15:40:40 +0000 Message-ID: <619a3410875a451a91ca83cb8c39eeca@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.34.112] Content-Type: multipart/alternative; boundary="_000_619a3410875a451a91ca83cb8c39eecausma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-08_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706080278 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-08_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706080278 Archived-At: Subject: [Acme] Call for adoption, ACME challenge for validating IP addresses X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 15:40:46 -0000 --_000_619a3410875a451a91ca83cb8c39eecausma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At the interim, we briefly discussed this document: https://tools.ietf.org/html/draft-shoemaker-acme-ip-00 Yaron had some questions about use-cases, which Roland replied to on the ma= iling list. Should we adopt this draft? (Recall that adoption means it's a good starti= ng point, not that it's almost done.) Please reply by the end of next week. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz --_000_619a3410875a451a91ca83cb8c39eecausma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

At the interim, we briefly discussed this document:<= o:p>

     https://tools.ietf.org/html/draft-s= hoemaker-acme-ip-00

 

Yaron had some questions about use-cases, which Rola= nd replied to on the mailing list.

 

Should we adopt this draft?  (Recall that adopt= ion means it’s a good starting point, not that it’s almost done= .)

 

Please reply by the end of next week.

 

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

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

 

--_000_619a3410875a451a91ca83cb8c39eecausma1exdag1mb1msgcorpak_-- From nobody Thu Jun 8 09:25:54 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C28A12943C for ; Thu, 8 Jun 2017 09:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRHhZ4mYwqX8 for ; Thu, 8 Jun 2017 09:25:50 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A701293F4 for ; Thu, 8 Jun 2017 09:25:49 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v58GMD9q029375 for ; Thu, 8 Jun 2017 17:25:47 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=uklyRNm4z8oOp0AIfHClmPBAk4twoU/zSybR1ctLzBw=; b=Y+3vtV1NeWvEkeWVvB8ofrOgWmgF8PtQ/tEUyE+e73rihzsa/sbymx1pLXN2hOUf0GCQ eXHZsNRWg3HjdI2hPj+BpgIvIu2InTuD7CcpsxNc7qgbdFupL7SR77+jW39RcoPhC1X3 /HM51zVpJAKQwRjLIACVcojnOYTaRqkbFFNDUfDs7j/motVGEr1DHcS0JbBr8iaQacE4 n+dKgdAd5nL+EuQ4u53CUDPTxm5KkcuQpEEI1oyKHZu0eSOzxQXD9PSl4aG3hXgv3AB4 xBvFfiUdviA9GekD4/fVDka5b6oaZP5+MBi23T8q0ifIq3aGvWOh26aztsN51tB6PgEc DA== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2ay1n3tn38-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 08 Jun 2017 17:25:46 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v58GKoQW011863 for ; Thu, 8 Jun 2017 12:25:46 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2aurevan3p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 08 Jun 2017 12:25:46 -0400 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.1263.5; Thu, 8 Jun 2017 09:25:45 -0700 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.1263.000; Thu, 8 Jun 2017 12:25:45 -0400 From: "Salz, Rich" To: "acme@ietf.org" Thread-Topic: Call for adoption STAR (short-term automatically-renewed) certificates Thread-Index: AdLgb8DFIV0Qb+TDSFGZ+Vszbaxneg== Date: Thu, 8 Jun 2017 16:25:45 +0000 Message-ID: <38420507dd4a4d0ab1e82ff5a8c07a00@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.34.112] Content-Type: multipart/alternative; boundary="_000_38420507dd4a4d0ab1e82ff5a8c07a00usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-08_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706080286 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-08_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706080287 Archived-At: Subject: [Acme] Call for adoption STAR (short-term automatically-renewed) certificates X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 16:25:52 -0000 --_000_38420507dd4a4d0ab1e82ff5a8c07a00usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At the June 2 interim, we had consensus to adopt https://datatracker.ietf.o= rg/doc/draft-sheffer-acme-star/ as a WG document, subject to splitting It into two documents, the ACME extension in one, and the delegation protoc= ol in another. This corresponds to #1 and #2 in the abstract of the draft. The authors have agreed to do this. Assuming that the split document is do= ne, are there any objections to adopting *the ACME extensions* as a WG docu= ment? Please respond by the end of next week. We will have a separate dis= cussion on the other protocol. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz --_000_38420507dd4a4d0ab1e82ff5a8c07a00usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

At the June 2 interim, we had consensus to adopt https://datatracker.ietf.org/doc/draft-sheffer-acme-star/ as a WG docum= ent, subject to splitting

It into two documents, the ACME extension in one, an= d the delegation protocol in another.  This corresponds to #1 and #2 i= n the abstract of the draft.

 

The authors have agreed to do this.  Assuming t= hat the split document is done, are there any objections to adopting *th= e ACME extensions* as a WG document?  Please respond by the end of= next week.  We will have a separate discussion on the other protocol.

 

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

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

 

--_000_38420507dd4a4d0ab1e82ff5a8c07a00usma1exdag1mb1msgcorpak_-- From nobody Thu Jun 8 12:43:18 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F95B127863 for ; Thu, 8 Jun 2017 12:43:17 -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 tmUikPyiLPH1 for ; Thu, 8 Jun 2017 12:43:15 -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 78F20126C2F for ; Thu, 8 Jun 2017 12:43:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C66C73004CA for ; Thu, 8 Jun 2017 15:43:14 -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 u5tHXNdmzODw for ; Thu, 8 Jun 2017 15:43:13 -0400 (EDT) Received: from new-host-6.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 35B4D3004B7; Thu, 8 Jun 2017 15:43:13 -0400 (EDT) From: Russ Housley Message-Id: <9162C522-19D1-4ED3-AA56-86CC14C5BE9D@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3AB8E021-82FD-4D55-97AC-5F974AF0CA20" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 8 Jun 2017 15:43:12 -0400 In-Reply-To: <615c6cca39444b0db7a4e3c960576c40@usma1ex-dag1mb1.msg.corp.akamai.com> Cc: IETF ACME To: Rich Salz References: <615c6cca39444b0db7a4e3c960576c40@usma1ex-dag1mb1.msg.corp.akamai.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Acme] Call for adoption; (1) ACME challenge for ATIS/SIP (2) identifiers and challenges for telephone numbers X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 19:43:17 -0000 --Apple-Mail=_3AB8E021-82FD-4D55-97AC-5F974AF0CA20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think the ACME group should adopt both of these documents. Russ > On Jun 8, 2017, at 11:32 AM, Salz, Rich wrote: >=20 > At the interim we had strong consensus to adopt these two drafts as WG = documents. I am grouping them in a single email because they are = related, and to point out that with both of these we will be = collaborating with the STIR WG. > =20 > If you feel it is not appropriate for us to adopt, please post to the = list by the end of next week: > https://tools.ietf.org/html/draft-barnes-acme-service-provider-00 = > =20 > https://tools.ietf.org/html/draft-peterson-acme-telephone-00 = > =20 > -- =20 > Senior Architect, Akamai Technologies > Member, OpenSSL Dev Team > IM: richsalz@jabber.at Twitter: RichSalz > =20 --Apple-Mail=_3AB8E021-82FD-4D55-97AC-5F974AF0CA20 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I think the ACME group should adopt both of these = documents.

Russ


On Jun 8, 2017, at 11:32 AM, Salz, Rich <rsalz@akamai.com> = wrote:

At the interim we had strong consensus to adopt these two = drafts as WG documents.  I am grouping them in a single email = because they are related, and to point out that with both of these we = will be collaborating with the STIR WG.
 
If you feel it is not appropriate for = us to adopt, please post to the list by the end of next week:
 
 
Senior = Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richsalz@jabber.at Twitter: RichSalz
 
<= /html>= --Apple-Mail=_3AB8E021-82FD-4D55-97AC-5F974AF0CA20-- From nobody Thu Jun 8 12:50:22 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8056F12778E for ; Thu, 8 Jun 2017 12:50:20 -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 ABl5iI5-Wuc3 for ; Thu, 8 Jun 2017 12:50:19 -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 DF342126C2F for ; Thu, 8 Jun 2017 12:50:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 421063004B7 for ; Thu, 8 Jun 2017 15:50:18 -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 F5-XMLGyU1Ku for ; Thu, 8 Jun 2017 15:50:17 -0400 (EDT) Received: from new-host-6.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id EB5AF3003FE; Thu, 8 Jun 2017 15:50:16 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0E478970-8C34-40F8-A3AF-26B2160A048C" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 8 Jun 2017 15:50:16 -0400 In-Reply-To: <80560dd786e74f0c89f8858a7f1981d1@usma1ex-dag1mb1.msg.corp.akamai.com> Cc: IETF ACME To: Rich Salz References: <80560dd786e74f0c89f8858a7f1981d1@usma1ex-dag1mb1.msg.corp.akamai.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Acme] Adopt two email-related drafts X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 19:50:20 -0000 --Apple-Mail=_0E478970-8C34-40F8-A3AF-26B2160A048C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > At the interim, we had strong consensus to adopt Alexsey=E2=80=99s = draft (was one, is now two) on ACME challenges and certs for email = services and users: > =20 > https://datatracker.ietf.org/doc/draft-melnikov-acme-email-smime/ = Why is the email address limited to all ASCII? The LAMPS WG is almost = done with the document for a certificate to include internationalized = email addresses in certificates, so I would like to see them included = here too. =20 > https://datatracker.ietf.org/doc/draft-melnikov-acme-email-tls/ = I hope we are not depended in any way on AUTH=3DSCRAM-SHA-1. Russ --Apple-Mail=_0E478970-8C34-40F8-A3AF-26B2160A048C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
At= the interim, we had strong consensus to adopt Alexsey=E2=80=99s draft = (was one, is now two) on ACME challenges and certs for email services = and users:
 

Why is the email address limited to all ASCII? =  The LAMPS WG is almost done with the document for a certificate to = include internationalized email addresses in certificates, so I would = like to see them included here too.
  
  https://datatracker.ietf.org/doc/draft-melnikov-acme-email-tls/=

I hope = we are not depended in any way on AUTH=3DSCRAM-SHA-1.

Russ

= --Apple-Mail=_0E478970-8C34-40F8-A3AF-26B2160A048C-- From nobody Thu Jun 8 12:55:11 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FB41293D9 for ; Thu, 8 Jun 2017 12:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 soz576w8r-dl for ; Thu, 8 Jun 2017 12:55:08 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE7451242F5 for ; Thu, 8 Jun 2017 12:55:07 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 9D29B2421519; Thu, 8 Jun 2017 19:55:05 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jim Reid In-Reply-To: <9162C522-19D1-4ED3-AA56-86CC14C5BE9D@vigilsec.com> Date: Thu, 8 Jun 2017 20:55:05 +0100 Cc: IETF ACME Content-Transfer-Encoding: 7bit Message-Id: References: <615c6cca39444b0db7a4e3c960576c40@usma1ex-dag1mb1.msg.corp.akamai.com> <9162C522-19D1-4ED3-AA56-86CC14C5BE9D@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Acme] Call for adoption; (1) ACME challenge for ATIS/SIP (2) identifiers and challenges for telephone numbers X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 19:55:09 -0000 > On 8 Jun 2017, at 20:43, Russ Housley wrote: > > I think the ACME group should adopt both of these documents. +1 From nobody Thu Jun 8 12:56:37 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873FA127BA3 for ; Thu, 8 Jun 2017 12:56:36 -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 KZSpkhhCF8ud for ; Thu, 8 Jun 2017 12:56:35 -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 1819D1242F5 for ; Thu, 8 Jun 2017 12:56:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7AE173004B7 for ; Thu, 8 Jun 2017 15:56:34 -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 UE3f9UiAGCgP for ; Thu, 8 Jun 2017 15:56:33 -0400 (EDT) Received: from new-host-6.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 2A8D13003FE; Thu, 8 Jun 2017 15:56:33 -0400 (EDT) From: Russ Housley Message-Id: <3A8069D0-9194-4773-A991-31DC70891912@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_275DE485-8765-447A-BA6F-9784E2ADC1F1" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 8 Jun 2017 15:56:32 -0400 In-Reply-To: <38420507dd4a4d0ab1e82ff5a8c07a00@usma1ex-dag1mb1.msg.corp.akamai.com> Cc: IETF ACME To: Rich Salz References: <38420507dd4a4d0ab1e82ff5a8c07a00@usma1ex-dag1mb1.msg.corp.akamai.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Acme] Call for adoption STAR (short-term automatically-renewed) certificates X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 19:56:36 -0000 --Apple-Mail=_275DE485-8765-447A-BA6F-9784E2ADC1F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii After very quickly looking at the document, I am not clear which parts = will make up the ACME extensions. I need more clarity to offer an = opinion. Russ > On Jun 8, 2017, at 12:25 PM, Salz, Rich wrote: >=20 > At the June 2 interim, we had consensus to adopt = https://datatracker.ietf.org/doc/draft-sheffer-acme-star/ = as a WG = document, subject to splitting > It into two documents, the ACME extension in one, and the delegation = protocol in another. This corresponds to #1 and #2 in the abstract of = the draft. > =20 > The authors have agreed to do this. Assuming that the split document = is done, are there any objections to adopting *the ACME extensions* as a = WG document? Please respond by the end of next week. We will have a = separate discussion on the other protocol. > =20 > -- =20 > Senior Architect, Akamai Technologies > Member, OpenSSL Dev Team > IM: richsalz@jabber.at Twitter: RichSalz > =20 --Apple-Mail=_275DE485-8765-447A-BA6F-9784E2ADC1F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii After very quickly looking at the document, I am not clear = which parts will make up the ACME extensions.  I need more clarity = to offer an opinion.

Russ


On Jun 8, 2017, at 12:25 PM, Salz, Rich <rsalz@akamai.com> = wrote:

At the June 2 interim, we had consensus to adopt https://datatracker.ietf.org/doc/draft-sheffer-acme-star/ as a WG document, = subject to splitting
It into two documents, the ACME extension in one, and the = delegation protocol in another.  This corresponds to #1 and #2 in = the abstract of the draft.
 
The authors have agreed to do = this.  Assuming that the split document is done, are there any = objections to adopting *the ACME extensions* as a WG = document?  Please respond by the end of next week.  We will = have a separate discussion on the other protocol.
 
--  
Senior = Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richsalz@jabber.at Twitter: RichSalz
 
<= /html>= --Apple-Mail=_275DE485-8765-447A-BA6F-9784E2ADC1F1-- From nobody Thu Jun 8 13:58:37 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABF31294D8 for ; Thu, 8 Jun 2017 13:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=nokia.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 cZQ71z737aZx for ; Thu, 8 Jun 2017 13:58:29 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10099.outbound.protection.outlook.com [40.107.1.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45C70127B52 for ; Thu, 8 Jun 2017 13:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=g561SAdw2emBj4px9hQmtkZPcv7GJDQ3tbjVyllaF0s=; b=iMT2cuNFbnrMklSUUJ8wy6nGz3djWSrNYD6OfSM1V5n9b/qz0baazsySwluek+dZr5IgFsRV2HgeOUbUcFRGbb+po0p7vmSJILZDKD4IZ2PYT9yg49hqR+6HAzuL6BVF90fBm89C9OubWkqOqQ4dxV9frUsXcT1ZZG5XqAhp3vI= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1455.eurprd07.prod.outlook.com (10.165.238.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.3; Thu, 8 Jun 2017 20:58:26 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::9a3:9232:3cfb:3aaf]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::9a3:9232:3cfb:3aaf%13]) with mapi id 15.01.1157.010; Thu, 8 Jun 2017 20:58:25 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Russ Housley , Rich Salz CC: IETF ACME , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Thread-Topic: [Acme] Call for adoption STAR (short-term automatically-renewed) certificates Thread-Index: AdLgb8DFIV0Qb+TDSFGZ+VszbaxnegAIZKMAAARBRgA= Date: Thu, 8 Jun 2017 20:58:24 +0000 Message-ID: <10401162-CE07-4612-BC02-AC9591F2F8F0@on.nokia.com> References: <38420507dd4a4d0ab1e82ff5a8c07a00@usma1ex-dag1mb1.msg.corp.akamai.com> <3A8069D0-9194-4773-A991-31DC70891912@vigilsec.com> In-Reply-To: <3A8069D0-9194-4773-A991-31DC70891912@vigilsec.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [92.20.249.149] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1455; 7:scFr9uVG6InL6Ivru5T0Dpx0bRKsVJKgrEr9SIcpEd7U9Z7b6AJWVpqDfQsih3mS+JpupxXH/2Ouqf16FHza1RrLLjdm5KJyDwBF2uGv46nWDLy5JlUVDPidzIIG8dPg240wMfUWFRyuavg3aXMz7rQR1P3fgJ2dlRknHcPzcvmMNBvvGssjEAf0hEaWXpNwy39aC8BryeYdNndMr0m5Cebid2H0hyf84LrrDJBb2X686GLZO7+ry+NrzxC5tLUhtXkwIJXDiJhbwI3NQ/5xE5gHtlZYGrsSknRlvlNDvvDHAbxDAy0TQhA+t+LRNFwnYJKi33bMAXOzbGyw8019sQ== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39400400002)(39860400002)(39410400002)(39850400002)(377454003)(24454002)(5660300001)(7736002)(50986999)(54356999)(83716003)(2950100002)(76176999)(6512007)(966005)(2906002)(6306002)(107886003)(3280700002)(14454004)(82746002)(2900100001)(5250100002)(6506006)(3846002)(102836003)(3660700001)(6436002)(99286003)(53546009)(53936002)(54906002)(6246003)(189998001)(66066001)(25786009)(6486002)(8676002)(86362001)(229853002)(81166006)(8936002)(305945005)(33656002)(38730400002)(478600001)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1455; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-traffictypediagnostic: VI1PR07MB1455: x-ms-office365-filtering-correlation-id: 67f40681-1341-4c55-d8d6-08d4aeb11af1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR07MB1455; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(148322886591682)(120809045254105)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(20161123558100)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB1455; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB1455; x-forefront-prvs: 0332AACBC3 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <5DBC2B0662BA4045B3C4EF7CFCE384C5@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2017 20:58:24.9593 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1455 Archived-At: Subject: Re: [Acme] Call for adoption STAR (short-term automatically-renewed) certificates X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 20:58:32 -0000 SGkgUnVzcywNCg0KT24gMDgvMDYvMjAxNywgMjA6NTYsICJBY21lIG9uIGJlaGFsZiBvZiBSdXNz IEhvdXNsZXkiIDxhY21lLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGhvdXNsZXlAdmln aWxzZWMuY29tPiB3cm90ZToNCj4gQWZ0ZXIgdmVyeSBxdWlja2x5IGxvb2tpbmcgYXQgdGhlIGRv Y3VtZW50LCBJIGFtIG5vdCBjbGVhciB3aGljaA0KPiBwYXJ0cyB3aWxsIG1ha2UgdXAgdGhlIEFD TUUgZXh0ZW5zaW9ucy4gwqBJIG5lZWQgbW9yZSBjbGFyaXR5IHRvDQo+IG9mZmVyIGFuIG9waW5p b24uIA0KDQpUaGUgbmV3IHNjb3BlIHdvdWxkIGJlIHRoZSBleHRlbnNpb24gdG8gQUNNRSB0aGF0 IGFsbG93cyBhdXRvbWF0aWMNCnJlbmV3YWwgb2YgdGhlIG9yZGVyLCBpLmUuLCBzZWN0aW9ucyAz LjQgYW5kIDMuNSBvZiB0aGUgY3VycmVudCBkcmFmdC4NCg0KQ2hlZXJzLCB0DQoNCj4gUnVzcw0K PiANCj4gDQo+IE9uIEp1biA4LCAyMDE3LCBhdCAxMjoyNSBQTSwgU2FseiwgUmljaCA8cnNhbHpA YWthbWFpLmNvbT4gd3JvdGU6DQo+ID4gDQo+ID4gQXQgdGhlIEp1bmUgMiBpbnRlcmltLCB3ZSBo YWQgY29uc2Vuc3VzIHRvDQo+ID4gYWRvcHTCoGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LXNoZWZmZXItYWNtZS1zdGFyL8KgYXMNCj4gPiBhIFdHIGRvY3VtZW50LCBzdWJq ZWN0IHRvIHNwbGl0dGluZyBpdCBpbnRvIHR3byBkb2N1bWVudHMsIHRoZQ0KPiA+IEFDTUUgZXh0 ZW5zaW9uIGluIG9uZSwgYW5kIHRoZSBkZWxlZ2F0aW9uIHByb3RvY29sIGluIGFub3RoZXIuwqAN Cj4gPiBUaGlzIGNvcnJlc3BvbmRzIHRvICMxIGFuZCAjMiBpbiB0aGUgYWJzdHJhY3Qgb2YgdGhl IGRyYWZ0Lg0KPiA+IMKgDQo+ID4gVGhlIGF1dGhvcnMgaGF2ZSBhZ3JlZWQgdG8gZG8gdGhpcy7C oCBBc3N1bWluZyB0aGF0IHRoZSBzcGxpdA0KPiA+IGRvY3VtZW50IGlzIGRvbmUsIGFyZSB0aGVy ZSBhbnkgb2JqZWN0aW9ucyB0byBhZG9wdGluZyAqdGhlIEFDTUUNCj4gPiBleHRlbnNpb25zKiBh cyBhIFdHIGRvY3VtZW50P8KgIFBsZWFzZSByZXNwb25kIGJ5IHRoZSBlbmQgb2YgbmV4dA0KPiA+ IHdlZWsuwqAgV2Ugd2lsbCBoYXZlIGEgc2VwYXJhdGUgZGlzY3Vzc2lvbiBvbiB0aGUgb3RoZXIg cHJvdG9jb2wuDQo+ID4gwqANCj4gPiAtLcKgwqANCj4gPiBTZW5pb3IgQXJjaGl0ZWN0LCBBa2Ft YWkgVGVjaG5vbG9naWVzDQo+ID4gTWVtYmVyLCBPcGVuU1NMIERldiBUZWFtDQo+ID4gSU06wqBy aWNoc2FsekBqYWJiZXIuYXTCoFR3aXR0ZXI6IFJpY2hTYWx6DQoNCg== From nobody Fri Jun 9 02:10:45 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B166F12956D for ; Fri, 9 Jun 2017 02:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=isode.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 ZecoN53OxSsF for ; Fri, 9 Jun 2017 02:10:42 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE76126CD8 for ; Fri, 9 Jun 2017 02:10:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1496999440; d=isode.com; s=june2016; i=@isode.com; bh=9fXT3sWIP8cSSRQ9kP3T8XlI8O3fx/Mnd0Llfsbbx8w=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=l2fFDv9ui74qjLQQHQbu0+pksIm+JeaamjbD28dBJ/IM4euix8bRH98BMjmiWtHdjLln0N KWiQfWZOwpiWQMhxg2oMF8TM7dShdXtKezGeqB6CtJq5fpu6oTuxaFyqC7SdmbvCLlzZPF Cu0b1DSFosJ7IglUECGhkcO7ryCUdgo=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 9 Jun 2017 10:10:40 +0100 To: Russ Housley , Rich Salz Cc: IETF ACME References: <80560dd786e74f0c89f8858a7f1981d1@usma1ex-dag1mb1.msg.corp.akamai.com> From: Alexey Melnikov Message-ID: <5c2648a6-0a42-fb78-aa0c-3f7d678ae19f@isode.com> Date: Fri, 9 Jun 2017 10:10:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------3F23D814245B2AC649CE6C81" Content-Language: en-US Archived-At: Subject: Re: [Acme] Adopt two email-related drafts X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 09:10:44 -0000 --------------3F23D814245B2AC649CE6C81 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Russ, On 08/06/2017 20:50, Russ Housley wrote: >> At the interim, we had strong consensus to adopt Alexsey=E2=80=99s draft = (was=20 >> one, is now two) on ACME challenges and certs for email services and=20 >> users: >> _https://datatracker.ietf.org/doc/draft-melnikov-acme-email-smime/_ > > Why is the email address limited to all ASCII? The LAMPS WG is almost=20 > done with the document for a certificate to include internationalized=20 > email addresses in certificates, so I would like to see them included=20 > here too. I've done the quickest job I could do to get something published before=20 the ACME Interim. As email addresses require new ACME identity type=20 anyway, supporting Internationalized Emails should be relatively=20 straightforward. So yes, I am happy to do that. > >> _https://datatracker.ietf.org/doc/draft-melnikov-acme-email-tls/_ > > I hope we are not depended in any way on AUTH=3DSCRAM-SHA-1. There is no obvious dependency on SCRAM at this point. If you are=20 talking about example EHLO response, it includes all sort of other=20 capabilities that are not relevant. I am happy to clarify this in the=20 document. Best Regards, Alexey --------------3F23D814245B2AC649CE6C81 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Russ,

On 08/06/2017 20:50, Russ Housley wrote:

At the interim, we had strong consensus to adopt Alexsey=E2=80=99s draf= t (was one, is now two) on ACME challenges and certs for email services and users:
=C2=A0
=C2=A0=C2=A0https://datatracke= r.ietf.org/doc/draft-melnikov-acme-email-smime/

Why is the email address limited to all ASCII? =C2=A0The LAMPS WG is almost done with the document for a certificate to include internationalized email addresses in certificates, so I would like to see them included here too.

I've done the quickest job I could do to get something published before the ACME Interim. As email addresses require new ACME identity type anyway, supporting Internationalized Emails should be relatively straightforward.
So yes, I am happy to do that.
=C2=A0=C2=A0
=
=C2=A0=C2=A0https://datatracker.= ietf.org/doc/draft-melnikov-acme-email-tls/

I hope we are not depended in any way on=C2=A0AUTH=3DSCRAM-SHA-1.

There is no obvious dependency on SCRAM at this point. If you are talking about example EHLO response, it includes all sort of other capabilities that are not relevant. I am happy to clarify this in the document.

Best Regards,
Alexey


--------------3F23D814245B2AC649CE6C81-- From nobody Fri Jun 9 09:27:33 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF9F128B51 for ; Fri, 9 Jun 2017 09:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 W1ElfuM9kJGY for ; Fri, 9 Jun 2017 09:27: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 D25C9124234 for ; Fri, 9 Jun 2017 09:27:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2B26A300494 for ; Fri, 9 Jun 2017 12:27:29 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GB3B8jbqnrFA for ; Fri, 9 Jun 2017 12:27:26 -0400 (EDT) Received: from new-host-4.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id BE34330048E; Fri, 9 Jun 2017 12:27:26 -0400 (EDT) From: Russ Housley Message-Id: <6E66C4D6-881E-4832-BAF6-78D03AF54BDF@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A1E2F485-0B31-4834-86E5-4F05A0F19650" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 9 Jun 2017 12:27:26 -0400 In-Reply-To: <5c2648a6-0a42-fb78-aa0c-3f7d678ae19f@isode.com> Cc: Rich Salz , IETF ACME To: Alexey Melnikov References: <80560dd786e74f0c89f8858a7f1981d1@usma1ex-dag1mb1.msg.corp.akamai.com> <5c2648a6-0a42-fb78-aa0c-3f7d678ae19f@isode.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Acme] Adopt two email-related drafts X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 16:27:32 -0000 --Apple-Mail=_A1E2F485-0B31-4834-86E5-4F05A0F19650 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >>> At the interim, we had strong consensus to adopt Alexsey=E2=80=99s = draft (was one, is now two) on ACME challenges and certs for email = services and users: >>> =20 >>> https://datatracker.ietf.org/doc/draft-melnikov-acme-email-smime/ = >> Why is the email address limited to all ASCII? The LAMPS WG is = almost done with the document for a certificate to include = internationalized email addresses in certificates, so I would like to = see them included here too. >=20 > I've done the quickest job I could do to get something published = before the ACME Interim. As email addresses require new ACME identity = type anyway, supporting Internationalized Emails should be relatively = straightforward. > So yes, I am happy to do that. >> =20 >>> https://datatracker.ietf.org/doc/draft-melnikov-acme-email-tls/ = >> I hope we are not depended in any way on AUTH=3DSCRAM-SHA-1. >=20 > There is no obvious dependency on SCRAM at this point. If you are = talking about example EHLO response, it includes all sort of other = capabilities that are not relevant. I am happy to clarify this in the = document. Good. I=E2=80=99m pleased to see these documents become the starting = point for the WG. Russ --Apple-Mail=_A1E2F485-0B31-4834-86E5-4F05A0F19650 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
At the interim, we had strong consensus to adopt Alexsey=E2=80=99s = draft (was one, is now two) on ACME challenges and certs for email services and users:
 
  https://datatracker.ietf.org/doc/draft-melnikov-a= cme-email-smime/

Why is the email address limited to all ASCII?  The LAMPS = WG is almost done with the document for a certificate to include internationalized email addresses in certificates, so I would like to see them included here too.

I've done the quickest job I could do to get something published before the ACME Interim. As email addresses require new ACME identity type anyway, supporting Internationalized Emails should be relatively straightforward.
So yes, I am happy to do that.
=
  
  https://datatracker.ietf.org/doc/draft-melnikov-a= cme-email-tls/

I hope we are not depended in any way = on AUTH=3DSCRAM-SHA-1.

There is no obvious dependency on SCRAM at this point. If you are talking about example EHLO response, it includes all sort of other capabilities that are not relevant. I am happy to clarify this in the document.

Good.  I=E2=80=99m pleased to see these = documents become the starting point for the WG.

Russ


= --Apple-Mail=_A1E2F485-0B31-4834-86E5-4F05A0F19650-- From nobody Fri Jun 9 12:36:23 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D543C129458 for ; Fri, 9 Jun 2017 12:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, TVD_PH_BODY_ACCOUNTS_PRE=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 hzTcAntmemtN for ; Fri, 9 Jun 2017 12:36:20 -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 DD16912944A for ; Fri, 9 Jun 2017 12:36:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 43B723004CA for ; Fri, 9 Jun 2017 15:36:19 -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 CxGFZ8sr-jUn for ; Fri, 9 Jun 2017 15:36:17 -0400 (EDT) Received: from new-host-4.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 9FAFD3002C1; Fri, 9 Jun 2017 15:36:17 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E23A548E-E230-4D18-B0BC-AF8127FEEE37" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 9 Jun 2017 15:36:17 -0400 In-Reply-To: <40e652477a2f47b0848330e64f72e8b2@usma1ex-dag1mb1.msg.corp.akamai.com> Cc: IETF ACME To: Rich Salz References: <40e652477a2f47b0848330e64f72e8b2@usma1ex-dag1mb1.msg.corp.akamai.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 19:36:22 -0000 --Apple-Mail=_E23A548E-E230-4D18-B0BC-AF8127FEEE37 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 8, 2017, at 11:27 AM, Salz, Rich wrote: >=20 > >> Hugo's CAA draft (already adopted, short, might be > >> ready for WGLC) -- = https://tools.ietf.org/html/draft-ietf-acme-caa-01 = > =20 > This has moved to WGLC. If you know of any reason why it should not = advance to the IESG, please post by end of next week. Section 2 includes this text: . . . A CA MUST only consider a property with an "account-uri" parameter to authorize issuance where the URI specified is an URI that the CA recognises as identifying the account making a certificate issuance request. This is not a crust MUST statement. I think it is trying to say two = things when the "account-uri=E2=80=9D is present:=20 (1) the CA MUST NOT issue a certificate containing the domain name that = contains the CAA Resource Record if it does not recognize the account = referenced by the URI. (2) the CA MUST use the account referenced by the URI in the = authorization process for a certificate request for the domain = containing the CAA Resource Record. If this is correct, please separate these two requirements. If it is = not correct, please explain the text. Russ --Apple-Mail=_E23A548E-E230-4D18-B0BC-AF8127FEEE37 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 8, 2017, at 11:27 AM, Salz, Rich <rsalz@akamai.com> = wrote:

>>         &= nbsp;      Hugo's CAA draft (already adopted, = short, might be
 
This has = moved to WGLC.  If you know of any reason why it should not advance = to the IESG, please post by end of next = week.


Section 2 includes this text:

   . . .  A CA MUST only = consider a property with an "account-uri"
  =  parameter to authorize issuance where the URI specified is an = URI
   that the CA recognises as identifying the = account making a
   certificate issuance = request.

This is not a crust MUST = statement.  I think it is trying to say two things when the = "account-uri=E2=80=9D is present: 

(1)  the CA MUST NOT issue a certificate = containing the domain name that contains the CAA Resource Record if it = does not recognize the account referenced by the URI.

(2)  the CA MUST use the account referenced = by the URI in the authorization process for a certificate request for = the domain containing the CAA Resource Record.

If this is correct, please separate these two = requirements.  If it is not correct, please explain the = text.

Russ




= --Apple-Mail=_E23A548E-E230-4D18-B0BC-AF8127FEEE37-- From nobody Fri Jun 9 13:47:53 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56594129407 for ; Fri, 9 Jun 2017 13:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6EqxSvSKqkm for ; Fri, 9 Jun 2017 13:47: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 C8D061292F4 for ; Fri, 9 Jun 2017 13:47:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 26BAF300435 for ; Fri, 9 Jun 2017 16:47:49 -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 S1oVmdN-S_13 for ; Fri, 9 Jun 2017 16:47:48 -0400 (EDT) Received: from new-host-4.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 2273F300425; Fri, 9 Jun 2017 16:47:48 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <10401162-CE07-4612-BC02-AC9591F2F8F0@on.nokia.com> Date: Fri, 9 Jun 2017 16:47:47 -0400 Cc: Rich Salz , IETF ACME Content-Transfer-Encoding: quoted-printable Message-Id: <10D554E3-B5C0-4587-B0D9-B36AA37AC2F4@vigilsec.com> References: <38420507dd4a4d0ab1e82ff5a8c07a00@usma1ex-dag1mb1.msg.corp.akamai.com> <3A8069D0-9194-4773-A991-31DC70891912@vigilsec.com> <10401162-CE07-4612-BC02-AC9591F2F8F0@on.nokia.com> To: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Acme] Call for adoption STAR (short-term automatically-renewed) certificates X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 20:47:51 -0000 > On 08/06/2017, 20:56, "Acme on behalf of Russ Housley" = wrote: >> After very quickly looking at the document, I am not clear which >> parts will make up the ACME extensions. I need more clarity to >> offer an opinion.=20 >=20 > The new scope would be the extension to ACME that allows automatic > renewal of the order, i.e., sections 3.4 and 3.5 of the current draft. Thanks. This seems like a reasonable way to extend the ACME protocol to = handle Recurring Orders After reading those two sections, I looked at the discussion of = extensions in draft-ietf-acme-acme, and there could be a bit of clarity = added there. Particularly, each place that the word extension is used, = it should be very clear whether the text is talking about an certificate = extension, and TLS protocol extension, or an extension to the ACME = protocol. All of them come up in that document. Russ= From nobody Mon Jun 12 13:26:57 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A9C1296B0 for ; Mon, 12 Jun 2017 13:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 6GVb2f8V-bkk for ; Mon, 12 Jun 2017 13:26:54 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::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 650A1129432 for ; Mon, 12 Jun 2017 13:26:54 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id v111so112376222wrc.3 for ; Mon, 12 Jun 2017 13:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aQrQSYvO2RiBPahJJiL7oWTFFDvkoAsFalAuk9wE9qQ=; b=FoDNsFT/BOtQN3Tid3LbJ0rnkyfvS+VFFEKiiUSYDp2oQXlZ5yahsUya+j+kHnv4hk p4sCcf9DNictunhTPOc10RWDOrDB3PXzN68//n2LE03Ijis0JxoRJ+gwQ30ifLBV6B1V QGt2B71gvmDL39disSGfLyRT9Kw4427jkwxLNX9ClrNLssl4pSH1fFY9eehaKqHGOXvB GNSEFSMfwko0kcviHs/ZApcW18CjDTZVg+k6su0Oc1Z/ojlxtrH+r9a/zjlxvQx0lS/q oTGjFkUscfY2kXXzidkO7HL/Epb3ViPb6uoOOUDNp1ZOW75LxWw9qM8971mMUkZFhmRd tlhQ== 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=aQrQSYvO2RiBPahJJiL7oWTFFDvkoAsFalAuk9wE9qQ=; b=A+D72snoCxdLjQFKKbpR2p98YKyOYb9RXjiryjrtjIi/kWAl4UxWGlDjyeuZqlPael ixFaGcgMZ/ONcvtvT5u9V+9XmqzcOkAQQKLjwumPjPzERtfE4aqWWFxtT+ayn1yMMkUs waynY2pTJ+/9g7S2yy+j5TvS8ts1mRtP44ha+g8NcEwXL9RV9qcpgawFs1eZVLPbzTT1 vE7IyVE0QIyypn/SOj0fJ2gnZvGpF4xpYP1SqIyywKv6POtnT4P4upChESVJFs7DZIGe 7YZEkJj9rXziWPW3z5h4dylOW4AwYwZomU0vZ8hp6udkwS4JDOF9EEf0gubNKIFKGFrF bUYQ== X-Gm-Message-State: AKS2vOyFA9/+1D4HRvSZByjel+Ay9ioiRTkx98nwbCZYLzF3mhzJ8h0O KXlH0U2MqdPOcrCBKp8u0BwH1e71W6e8 X-Received: by 10.223.142.150 with SMTP id q22mr462101wrb.180.1497299212798; Mon, 12 Jun 2017 13:26:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.109.16 with HTTP; Mon, 12 Jun 2017 13:26:52 -0700 (PDT) In-Reply-To: <10D554E3-B5C0-4587-B0D9-B36AA37AC2F4@vigilsec.com> References: <38420507dd4a4d0ab1e82ff5a8c07a00@usma1ex-dag1mb1.msg.corp.akamai.com> <3A8069D0-9194-4773-A991-31DC70891912@vigilsec.com> <10401162-CE07-4612-BC02-AC9591F2F8F0@on.nokia.com> <10D554E3-B5C0-4587-B0D9-B36AA37AC2F4@vigilsec.com> From: Richard Barnes Date: Mon, 12 Jun 2017 16:26:52 -0400 Message-ID: To: Russ Housley Cc: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , Rich Salz , IETF ACME Content-Type: multipart/alternative; boundary="f403045f50b8b3b5b20551c92337" Archived-At: Subject: Re: [Acme] Call for adoption STAR (short-term automatically-renewed) certificates X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 20:26:57 -0000 --f403045f50b8b3b5b20551c92337 Content-Type: text/plain; charset="UTF-8" I don't think we should adopt this until the Recurring Orders stuff has been split out. I'm still not convinced of the need for the other interface here, much less the need to do it in this WG. On Fri, Jun 9, 2017 at 4:47 PM, Russ Housley wrote: > > > On 08/06/2017, 20:56, "Acme on behalf of Russ Housley" < > acme-bounces@ietf.org on behalf of housley@vigilsec.com> wrote: > >> After very quickly looking at the document, I am not clear which > >> parts will make up the ACME extensions. I need more clarity to > >> offer an opinion. > > > > The new scope would be the extension to ACME that allows automatic > > renewal of the order, i.e., sections 3.4 and 3.5 of the current draft. > > Thanks. This seems like a reasonable way to extend the ACME protocol to > handle Recurring Orders > > After reading those two sections, I looked at the discussion of extensions > in draft-ietf-acme-acme, and there could be a bit of clarity added there. > Particularly, each place that the word extension is used, it should be very > clear whether the text is talking about an certificate extension, and TLS > protocol extension, or an extension to the ACME protocol. All of them come > up in that document. > > Russ > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --f403045f50b8b3b5b20551c92337 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think we should adopt this until the Recu= rring Orders stuff has been split out.

I'm sti= ll not convinced of the need for the other interface here, much less the ne= ed to do it in this WG.

On Fri, Jun 9, 2017 at 4:47 PM, Russ Housley <hou= sley@vigilsec.com> wrote:
<= span class=3D"">
> On 08/06/2017, 20:56, "Acme on behalf of Russ Housley" <<= a href=3D"mailto:acme-bounces@ietf.org">acme-bounces@ietf.org on behalf= of housley@vigilsec.com> wr= ote:
>> After very quickly looking at the document, I am not clear which >> parts will make up the ACME extensions.=C2=A0 I need more clarity = to
>> offer an opinion.
>
> The new scope would be the extension to ACME that allows automatic
> renewal of the order, i.e., sections 3.4 and 3.5 of the current draft.=

Thanks.=C2=A0 This seems like a reasonable way to extend the ACME pr= otocol to handle Recurring Orders

After reading those two sections, I looked at the discussion of extensions = in draft-ietf-acme-acme, and there could be a bit of clarity added there.= =C2=A0 Particularly, each place that the word extension is used, it should = be very clear whether the text is talking about an certificate extension, a= nd TLS protocol extension, or an extension to the ACME protocol.=C2=A0 All = of them come up in that document.

Russ
_____________________= __________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

--f403045f50b8b3b5b20551c92337-- From nobody Mon Jun 12 13:32:18 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3DA1298BA for ; Mon, 12 Jun 2017 13:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 FWG3lgGPjdgK for ; Mon, 12 Jun 2017 13:32:16 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB10C129432 for ; Mon, 12 Jun 2017 13:32:15 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5CKRReT007380; Mon, 12 Jun 2017 21:32:13 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=NUP8hqbpQP7JnrtQJyj8N05Y+Eij5WiC+rfaml15bNU=; b=COmRjgm6uzdWkEs8F9zJQ6bGk7b5X57tDwQN8owl3KYiBMvbxpj1iIS7QNjKHYN+PUZl oxlNKun8ENipRZHHFziBErfVsgYxcw7qCAQ/t42u+Jhd/l+eJg20me8QMpdjZ6T6t2a+ nvTPqGC0aFGA1LqWS+Oqw3Nl5UP/fAgJV9WIc4qzR8R4SJwAMA+vhklBKgV99VSffmy9 UUZ14d5XGKQDQvqs2zeqGK+CIudubayfXPoKfeIM0Q0ch7kmOfkrmMlmK0nOwPd34qG8 TRGUuEZZiFRanToRNywuSosxtFs2d47Rft6cOt1t+7K3AZV19RcSDG6hLc+1/gQ3pMY5 kQ== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2b1rnbk36a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Jun 2017 21:32:13 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5CKUxP8016926; Mon, 12 Jun 2017 16:32:12 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2b0c3ufmvg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 12 Jun 2017 16:32:12 -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 Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 12 Jun 2017 16:32:11 -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.1263.000; Mon, 12 Jun 2017 16:32:11 -0400 From: "Salz, Rich" To: Richard Barnes , Russ Housley CC: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , IETF ACME Thread-Topic: [Acme] Call for adoption STAR (short-term automatically-renewed) certificates Thread-Index: AdLgb8DFIV0Qb+TDSFGZ+VszbaxnegAQxmcAAAIpIgAAMeuvgACWJM0AAAhdVAA= Date: Mon, 12 Jun 2017 20:32:11 +0000 Message-ID: <151507f4b79e4bf49658f09a1586a3c7@usma1ex-dag1mb1.msg.corp.akamai.com> References: <38420507dd4a4d0ab1e82ff5a8c07a00@usma1ex-dag1mb1.msg.corp.akamai.com> <3A8069D0-9194-4773-A991-31DC70891912@vigilsec.com> <10401162-CE07-4612-BC02-AC9591F2F8F0@on.nokia.com> <10D554E3-B5C0-4587-B0D9-B36AA37AC2F4@vigilsec.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.218] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-12_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706120360 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-12_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706120359 Archived-At: Subject: Re: [Acme] Call for adoption STAR (short-term automatically-renewed) certificates X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 20:32:17 -0000 PiBJIGRvbid0IHRoaW5rIHdlIHNob3VsZCBhZG9wdCB0aGlzIHVudGlsIHRoZSBSZWN1cnJpbmcg T3JkZXJzIHN0dWZmIGhhcyBiZWVuIHNwbGl0IG91dC4NCg0KPiBJJ20gc3RpbGwgbm90IGNvbnZp bmNlZCBvZiB0aGUgbmVlZCBmb3IgdGhlIG90aGVyIGludGVyZmFjZSBoZXJlLCBtdWNoIGxlc3Mg dGhlIG5lZWQgdG8gZG8gaXQgaW4gdGhpcyBXRy4NCg0KVGhlIGRvY3VtZW50IHdpbGwgYmUgc3Bs aXQgaW50byB0aGUgcmVjdXJyaW5nLW9yZGVyL3JlbmV3YWwgcGFydCwgYW5kIHRoZSBkZWxlZ2F0 aW9uIHBhcnQuIFRoaXMgd2lsbCBiZSBkb25lIEFTQVAsIGJ1dCBjZXJ0YWlubHkgYnkgdGhlIFBy YWd1ZSBwdWJsaWNhdGlvbiBkZWFkbGluZS4gIE9uIHRoZSBjYWxsL2ludGVyaW0sIHdlIGhhZCBj b25zZW5zdXMgdG8gZG8gdGhhdCBhbmQgYWNjZXB0IHRoZSByZW5ld2FsIHBhcnQgYXMgYSBXRyBp dGVtLiBXZSBhcmUgaW4gdGhlIG1pZHN0IG9mIGNvbmZpcm1pbmcgdGhhdCBoZXJlIG9uIHRoZSBs aXN0IG5vdy4gIFRoZSBleGlzdGluZyBkb2Mgd2lsbCBub3QgYmUgYWRvcHRlZCBhcy1pcy4NCg0K QWZ0ZXIgZGlzY3Vzc2lvbiB3aXRoIHRoZSBBRCdzLCB0aGUgV0cgd2lsbCBkZWNpZGUgaWYgaXQg d2FudHMgdG8gYWRvcHQgdGhlIG90aGVyIHByb3RvY29sOyB3ZSBjYW4gcm9sbCB0aGF0IHVwIHdp dGggYW55IG90aGVyIGNoYXJ0ZXIgY2hhbmdlcyBwbGFubmVkIGZvciBQcmFndWUuDQoNCkkgdGhp bmsgaXQncyBhY2NlcHRhYmxlIHRvIHRydXN0IHRoYXQgdGhlIGF1dGhvcnMgKHdobyBoYXZlIGFn cmVlZCBpbiBwdWJsaWMgYW5kIHJlY29uZmlybWVkKSB3aWxsIGRvIHdoYXQncyBiZWVuIGFza2Vk Lg0KDQoJL3IkDQoNCg== From nobody Mon Jun 12 13:39:12 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A883129A9D for ; Mon, 12 Jun 2017 13:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 opabJytV3B32 for ; Mon, 12 Jun 2017 13:39:09 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 8EDA11293E8 for ; Mon, 12 Jun 2017 13:39:09 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id x63so56221357pff.3 for ; Mon, 12 Jun 2017 13:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=6/fIobGVzJtvYXkFfvF51w4NM5X91VTIJBk2U0NLxz0=; b=OG7+5xdzwN1qLrJlBN9pdxSWJzZGce/PK5i6BYMEqf19diqmNdUuCPKXWWBUcmtgX8 RW7gL2A5H9awT+6AdbXBn/PUGjo5U+QEkBNE0xiou9QdmCdtPVwKUSm9JT3Ce4WETMTJ 6PzX0B6S7i1sN5UHABhlhVsRGr3ifDizmixTUJhrbOgdfGx4HgaUpofzeFNg0ween2BK XR0vrOxdH0ZNWR94Mofxp3BilLjtzR2y5SRvDbw70dcQA3B7Wy18OqZe8yP+fS33gx7q rjN4/JJ2fSpB1BfzEZ1nKOauz1ESDey8SmzzUbsNsgeP/UiXZEkz8eVUENRFEHN+ter3 U34A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=6/fIobGVzJtvYXkFfvF51w4NM5X91VTIJBk2U0NLxz0=; b=V2YtYuUHODVDCWCEiGomZLnDWvkHBWx+usuU9UsTW2zKRhemK+Jd72NihNAtngeWQy Tt4JaGhyWfU9SC0wb0f/Ug7MH9QmWM8muZPxTL6TWyDk874RWBaAYXhHqUvz+XkJFKk9 NQkwoMzsBjOe30qj2SRWYENipBMXWSH6Yu7y3QEnIP+g4UQybB885KbZiI3GTsGNtAJk 6rF6t3RY68Kuz5nlG16SICc21HZ6JjYBwLgFW7c0qdfSDkq8bQGtJvFxJsJdVeBMXk40 nj7g1faT0SVDJo1wGCCsMH1rI+RAjITritchWaDgILkcXgP2avYHDLMI67neOe3UEcp2 lzKQ== X-Gm-Message-State: AKS2vOyOpM7MukjmSBgWTx1yJQX++TvaUVPXXicA98gSf7m2EOaHCnKk 2J6cZi6InqHBum+BFWE= X-Received: by 10.84.129.98 with SMTP id 89mr12143605plb.35.1497299948860; Mon, 12 Jun 2017 13:39:08 -0700 (PDT) Received: from Melindas-MacBook-Pro.local (216-67-26-16-radius.dynamic.acsalaska.net. [216.67.26.16]) by smtp.gmail.com with ESMTPSA id s131sm19735742pgs.6.2017.06.12.13.39.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jun 2017 13:39:07 -0700 (PDT) To: acme@ietf.org References: <38420507dd4a4d0ab1e82ff5a8c07a00@usma1ex-dag1mb1.msg.corp.akamai.com> <3A8069D0-9194-4773-A991-31DC70891912@vigilsec.com> <10401162-CE07-4612-BC02-AC9591F2F8F0@on.nokia.com> <10D554E3-B5C0-4587-B0D9-B36AA37AC2F4@vigilsec.com> <151507f4b79e4bf49658f09a1586a3c7@usma1ex-dag1mb1.msg.corp.akamai.com> From: Melinda Shore Message-ID: <9a537639-85bc-da17-c5fe-388a7cff5c8e@gmail.com> Date: Mon, 12 Jun 2017 12:39:05 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <151507f4b79e4bf49658f09a1586a3c7@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="d8vj2X6URiJ6U7SfpxHQPXtQ7APX7vLoj" Archived-At: Subject: Re: [Acme] Call for adoption STAR (short-term automatically-renewed) certificates X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 20:39:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --d8vj2X6URiJ6U7SfpxHQPXtQ7APX7vLoj Content-Type: multipart/mixed; boundary="dNQ7TtucrTEeFFHvOw7LrEFqPgIciLnHU"; protected-headers="v1" From: Melinda Shore To: acme@ietf.org Message-ID: <9a537639-85bc-da17-c5fe-388a7cff5c8e@gmail.com> Subject: Re: [Acme] Call for adoption STAR (short-term automatically-renewed) certificates References: <38420507dd4a4d0ab1e82ff5a8c07a00@usma1ex-dag1mb1.msg.corp.akamai.com> <3A8069D0-9194-4773-A991-31DC70891912@vigilsec.com> <10401162-CE07-4612-BC02-AC9591F2F8F0@on.nokia.com> <10D554E3-B5C0-4587-B0D9-B36AA37AC2F4@vigilsec.com> <151507f4b79e4bf49658f09a1586a3c7@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <151507f4b79e4bf49658f09a1586a3c7@usma1ex-dag1mb1.msg.corp.akamai.com> --dNQ7TtucrTEeFFHvOw7LrEFqPgIciLnHU Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/12/17 12:32 PM, Salz, Rich wrote: > On the call/interim, we had consensus > to do that and accept the renewal part as a WG item. We are in the > midst of confirming that here on the list now.=20 Just a reminder that consensus is established on mailing lists, not in meetings. That is to say, what's currently under way is *the* consensus call. I think the proposal as it stands is not very clear and personally I'd prefer to see what's in the revised document(s) before agreeing to adoption. Melinda --dNQ7TtucrTEeFFHvOw7LrEFqPgIciLnHU-- --d8vj2X6URiJ6U7SfpxHQPXtQ7APX7vLoj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZPvvpAAoJELiGRpM6HoEusYQQAJVgHUAwYrLXCk5MHfUO0IfC A2TDhx1fbcQlcWdNpnyZilKYH/BbAjHi+W6vS1KE8Q68I2/qhLdl4ma57RnHHWT1 4hI1X3Azq+DeEjjN49LcecVzRGeQuzn5SrV+Ur0D/GE5R03GHzYv3RgmtkbHVVF8 udYj9AGbfg43HBlnQwdCsBZJp4Zn+uFbrp5teWCXdX77kOY4SBMtX3i4AyF+QPxz c0OWWhJziUq+eQRd7KBeK4vDaB/EDKVhROIhBSojc5Ht5iMEj0B5chpr8bWTEKQv FMSzJAqvpfDWVYYpohdE0Ap+VJgCkjsHCMq3IIUeoX271KqKB0k1iMNap3UUclaz FiHXsVaqenM3PWVWQf3sL/brjA2mIQ5tDDeWj0YBI6gtIWgAbR/yhniSIQLGi2Vr eZoVFWF4a3IE/9hgIBD9YYlVFULV/qPZY6kCPjr/5NN88K35j3a0BCaQ7JkNxhca fdlfhgeyIk9U1njcJAP50C64G9ou8yLS+9UA3hfbLXJPNUJLxRXmF1IpR4ntgtlN cnavLo8Bx4AHxj831Ujsmu9T8x1+VaHKeizrwiEmWsdKdN5Q9ctRHaML24qiDbWH F3l4S9Iq3VwiZfckLq4mFzLgbntRFhUK08mnsTs52rNyiiql0KLpSeq8u68whc8X 7mG1aEXo7UiPIQurPyKj =o5ce -----END PGP SIGNATURE----- --d8vj2X6URiJ6U7SfpxHQPXtQ7APX7vLoj-- From nobody Mon Jun 12 14:05:55 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0205F1292C5 for ; Mon, 12 Jun 2017 14:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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=nokia.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 Syga5adaN3r2 for ; Mon, 12 Jun 2017 14:05:52 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0129.outbound.protection.outlook.com [104.47.0.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88BC512025C for ; Mon, 12 Jun 2017 14:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+Xk+udxD4o1CBtu7F7gkkfEogN4a++ju34VpGWLukFs=; b=na2F1K4frlKp9XWsXtGlmUqJ6ZNOfCG//duf6SVkY5AV/7beqUnICGHq0nd1bpNIMoZ4ENkrXi67CU2n0zQq60VpliCPkSoH/BM1C8kzJAW91gnJ1esEOjoDPOnEnFhuW5KNkgzTdfp5HpBJOFZgQD0Xg3QeS8u7i7BHz3hgMg0= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1037.eurprd07.prod.outlook.com (10.161.111.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.5; Mon, 12 Jun 2017 21:05:48 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::9a3:9232:3cfb:3aaf]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::9a3:9232:3cfb:3aaf%13]) with mapi id 15.01.1178.008; Mon, 12 Jun 2017 21:05:48 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Melinda Shore , "acme@ietf.org" CC: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Thread-Topic: [Acme] Call for adoption STAR (short-term automatically-renewed) certificates Thread-Index: AdLgb8DFIV0Qb+TDSFGZ+VszbaxnegAIZKMAAARBRgAAL9OKgACWJM0AAAAviYAAAD2xgAADBrYA Date: Mon, 12 Jun 2017 21:05:47 +0000 Message-ID: References: <38420507dd4a4d0ab1e82ff5a8c07a00@usma1ex-dag1mb1.msg.corp.akamai.com> <3A8069D0-9194-4773-A991-31DC70891912@vigilsec.com> <10401162-CE07-4612-BC02-AC9591F2F8F0@on.nokia.com> <10D554E3-B5C0-4587-B0D9-B36AA37AC2F4@vigilsec.com> <151507f4b79e4bf49658f09a1586a3c7@usma1ex-dag1mb1.msg.corp.akamai.com> <9a537639-85bc-da17-c5fe-388a7cff5c8e@gmail.com> In-Reply-To: <9a537639-85bc-da17-c5fe-388a7cff5c8e@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [2.96.98.46] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1037; 7:Rv1l6Qm/qhfo0uBV1lYZJEZPys35slMxNyP9ksTw4fSCVzN6FCwJn425AjYO1n0WRQLR88gByaK57yZAfp5E0BJOHfQ9nR8h0oqN2OuV8Hj9T2ZsDlLfWp70gGHIgKfWziQSzzWhjlO/2cywC/MT/gWI8jABJJfoQQLwIcMqZjKEm27RQuOuXuJ/R/hw2q7KdvjYJcB/V1PHzjNc/+mKlyDrlK687jgMSiLe84XGBBVIq8/06twsS4SjRCDN4gqSfYCTHnPZMBOgv1amyzSd+N7RrsJhYQwCm4NWQVy+RnD9/1XLmB3rghmQi7X1BiXoxfWMWzTOTlcl5Yf8x1Y8i+Cq3WzzJTsEoemlUOEVGyU2Xm+vuImXEI1yjlfGPckLFbvwR/tcXmvuM0t+q0MtSCDQONZZr6OH/JmGYk57qAVe1HXqKgdbvG/VdY0IS9Swc08YmNxppGBzTkzixgnV8wDqIKzI/nwC3EJqL1whbRHRMaN+DbppMdjalkoJlrejCfWq/6B7YOOktbnpH5aFf38wNXbuV/QFclWJx4kl3MGWO/OA7jXIplPwYqZnKKsZmitDdeR0D85Uc4K9HegRJcYlMHbB0u+MSSyhC0UZhiyq6Fox1XekbKThxwG4TzJhtQqyvNVURufDGiA+adyYEy2mZk+5vgeS/wUT4gEm5MQvdw0kLbS21B8dSDT6f7oXQZ1D7TU+MJEN0CgjmOoJ+L1p/p8zq370Mx20LfcZCyX0wSyVGLQ1ejHpHXdU5ChTkdWCxKiZQDCRW0YoeukXjnJPSuD4wA09p3R8+dcbYWU= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39850400002)(39400400002)(39860400002)(39840400002)(39450400003)(53484002)(24454002)(469094003)(4001350100001)(189998001)(6306002)(6512007)(53936002)(8936002)(3280700002)(3660700001)(66066001)(2950100002)(229853002)(6506006)(93886004)(38730400002)(8676002)(2906002)(83716003)(99286003)(81166006)(86362001)(107886003)(83506001)(82746002)(6246003)(4326008)(478600001)(50986999)(561944003)(5660300001)(54356999)(3846002)(6116002)(76176999)(102836003)(33656002)(966005)(5250100002)(2900100001)(6486002)(2501003)(39060400002)(7736002)(6436002)(14454004)(25786009)(305945005)(53546009); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1037; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-office365-filtering-correlation-id: 05f489f7-d3ca-4ff5-adc6-08d4b1d6ccad x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR07MB1037; x-ms-traffictypediagnostic: VI1PR07MB1037: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123558100)(20161123555025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB1037; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB1037; x-forefront-prvs: 03361FCC43 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2017 21:05:48.0053 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1037 Archived-At: Subject: Re: [Acme] Call for adoption STAR (short-term automatically-renewed) certificates X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 21:05:54 -0000 SGkgTWVsaW5kYSwNCg0KT24gMTIvMDYvMjAxNywgMjE6MzksICJBY21lIG9uIGJlaGFsZiBvZiBN ZWxpbmRhIFNob3JlIiA8YWNtZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBtZWxpbmRh LnNob3JlQGdtYWlsLmNvbT4gd3JvdGU6DQo+IEkgdGhpbmsgdGhlIHByb3Bvc2FsIGFzIGl0IHN0 YW5kcyBpcyBub3QgdmVyeSBjbGVhciBhbmQgcGVyc29uYWxseQ0KPiBJJ2QgcHJlZmVyIHRvIHNl ZSB3aGF0J3MgaW4gdGhlIHJldmlzZWQgZG9jdW1lbnQocykgYmVmb3JlIGFncmVlaW5nDQo+IHRv IGFkb3B0aW9uLg0KDQpBcyBJIHNhaWQgdXB0aHJlYWQgaW4gcmVwbHkgdG8gYSBzaW1pbGFyIGNv bmNlcm4gZXhwcmVzc2VkIGJ5IFJ1c3MNCmFib3V0IHRoZSBzY29wZSBvZiB0aGUgc3BsaXQgZHJh ZnQsIHRoZSBuZXcgZG9jdW1lbnQgd2lsbCBkZXNjcmliZSB0aGUNCkFDTUUgZXh0ZW5zaW9uIGFs cmVhZHkgZG9jdW1lbnRlZCBpbiBbMV0gYW5kIFsyXSB0bzoNCi0gYWxsb3cgcmVxdWVzdGluZyB0 aGUgYXV0b21hdGljIHJlbmV3YWwgb2YgYW4gb3JkZXI7DQotIHByb3ZpZGUgdGhlIGVuZHBvaW50 IGZyb20gd2hpY2ggdGhlIGF1dG9tYXRpY2FsbHkgcmVuZXdlZCBjZXJ0cw0KICBhcmUgZmV0Y2hl ZDsNCi0gY2FuY2VsIGFuIGV4aXN0aW5nIHJlY3VycmluZyBvcmRlciBiZWZvcmUgaXQgcmVhY2hl cyBlbmQtb2YtbGlmZS4NCg0KSSBob3BlIHRoaXMgaGVscHMgY2xlYXJpbmcgeW91ciBkb3VidHMu DQoNCkNoZWVycywgdA0KDQpbMV0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNo ZWZmZXItYWNtZS1zdGFyLTAyI3NlY3Rpb24tMy40DQpbMl0gaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXNoZWZmZXItYWNtZS1zdGFyLTAyI3NlY3Rpb24tMy41DQoNCg== From nobody Tue Jun 13 01:35:08 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0170129BFC for ; Tue, 13 Jun 2017 01:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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=nokia.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 KzFzgcjdFniO for ; Tue, 13 Jun 2017 01:35:06 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0118.outbound.protection.outlook.com [104.47.1.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D354129C00 for ; Tue, 13 Jun 2017 01:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lIWRyoAka0T8EVbH44/iZNY0dyR8qFDRfiusgxSNIT4=; b=PEIQTzonBOv665+Mm9KT8cNYfwtWLBkP2hIxcJBe8fYGtzYyqJSPvjpsI05krokSjjZVnFAQ8iP1wRj7k16PNfZaaKY9JtGQ7YCVVZUin6WsuSLDh/kfRxOmr61L2swe2Vb7JYjUMxNgOluzhJH1o7s2XOuN3mVo/Z5znL+brfs= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1423.eurprd07.prod.outlook.com (10.165.238.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.5; Tue, 13 Jun 2017 08:35:01 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::9a3:9232:3cfb:3aaf]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::9a3:9232:3cfb:3aaf%13]) with mapi id 15.01.1178.008; Tue, 13 Jun 2017 08:35:00 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Richard Barnes , Russ Housley CC: Rich Salz , IETF ACME , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Thread-Topic: [Acme] Call for adoption STAR (short-term automatically-renewed) certificates Thread-Index: AdLgb8DFIV0Qb+TDSFGZ+VszbaxnegAIZKMAAARBRgAAL9OKgACWJM0AABuGUIA= Date: Tue, 13 Jun 2017 08:35:00 +0000 Message-ID: <7D11EE23-C5C5-48EB-8428-8ACCAADB2F30@on.nokia.com> References: <38420507dd4a4d0ab1e82ff5a8c07a00@usma1ex-dag1mb1.msg.corp.akamai.com> <3A8069D0-9194-4773-A991-31DC70891912@vigilsec.com> <10401162-CE07-4612-BC02-AC9591F2F8F0@on.nokia.com> <10D554E3-B5C0-4587-B0D9-B36AA37AC2F4@vigilsec.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-originating-ip: [81.134.152.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1423; 7:eXUmzhSPB4fDmvSG2mK0u6P5v8lVmWTjmK0ip3+o2q5XVVJokriywFl2OPWpP03UMkJsZ1GjyYEapnbdF/wAOUUkIk77JyEnzRS4Tw7KF9OPGCzczIXPpAtaQC2mTGHBCoXq1eggKbH8ohfvUU4l9zdlbHkcB5n/QZrXlUJ8WmTpkMz1PmeDxoCQMYC0wsq6ndGOVlChj8qSypuK7V87a6mWiDuW0LRVcPRuucetI2q5mtttSnEDiN2Ob49n8ApALRkmixcLxowivaPE000EvG+Jf0qfi1Zfgo4kdxCrwDvBdi/i42oBQ5wpu4KYGeEXE9BN7sh64lAJ69gQ0GAWMTZnll4uQbEr5WmNDQh7Fzdp+Cu8X9DTVnkOvtLdoH+0DzR184Y97NH51fWVhU30Sp3NGaOWWm0pRtulGRnKr32PylBhL8WRvwSMmQmBG0mNfZShjRdaL4XhEZX79LTHPzuJekE/BD/Xu168aGMzawAjdKxLrPEQSZ4YI8x6+ZwO93fnaXw9pzHmMzmDuXUrmK1qaeeKzn9oRSeRj49Hp4OZ+8Vo8SFPY4ou1EgBOQ8ifInGgqPnQ3dDsALVPnOqee5jMC5JX1yQeLDNm/k/qTiwMEsXSP2ZfFk9o5Rdax2h3Ebh7JMVF4BhfIV0vz49ypMVuRdjyCByGBZ/Ae/Dccb2psPEHiJ7gjIh9l6Ez+laaeI0vqjWoIlYz4y8b+DzG5GWarU/CivjwLia/vVuGZ4wnUHrOjXSQ9uinpuJptJqOY7qSkenX5NqBXaArU6h1A9dXkBajNsziH12MaFPDQM= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39860400002)(39450400003)(39840400002)(39850400002)(24454002)(189002)(199003)(107886003)(53546009)(81156014)(97736004)(81166006)(38730400002)(33656002)(8676002)(50986999)(76176999)(54356999)(2950100002)(6436002)(66066001)(4001350100001)(2900100001)(101416001)(4326008)(478600001)(6512007)(6246003)(5660300001)(68736007)(189998001)(53936002)(102836003)(3846002)(106356001)(25786009)(105586002)(305945005)(83716003)(7736002)(83506001)(6486002)(82746002)(14454004)(86362001)(2906002)(5250100002)(6506006)(93886004)(54906002)(99286003)(229853002)(3660700001)(3280700002)(8936002)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1423; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: 975f75fc-ac90-42de-2320-08d4b23714dd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:VI1PR07MB1423; x-ms-traffictypediagnostic: VI1PR07MB1423: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB1423; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB1423; x-forefront-prvs: 0337AFFE9A received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <188D166ABB4051499FF87CDA2A15E636@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2017 08:35:00.7502 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1423 Archived-At: Subject: Re: [Acme] Call for adoption STAR (short-term automatically-renewed) certificates X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 08:35:08 -0000 SGkgUmljaGFyZCwNCg0KT24gMTIvMDYvMjAxNywgMjE6MjYsICJSaWNoYXJkIEJhcm5lcyIgPHJs YkBpcHYuc3g+IHdyb3RlOg0KPiBJJ20gc3RpbGwgbm90IGNvbnZpbmNlZCBvZiB0aGUgbmVlZCBm b3IgdGhlIG90aGVyIGludGVyZmFjZSBoZXJlLA0KDQpEZXNwaXRlIGFwcGVhcmFuY2VzLCB0aGUg Im90aGVyIiBpbnRlcmZhY2UgaXMgbm90IGFuIGludGVybmFsIG9uZS4NCg0KVGhlIGFjdG9ycyBh cmUgc2VwYXJhdGUgYnVzaW5lc3MgZW50aXRpZXMsIHdoaWNoIHZhcnkgaW4gdGltZSBhbmQNCnNw YWNlOg0KIC0gYSBDRE4gdHlwaWNhbGx5IGhhcyBtYW55IGRpZmZlcmVudCBjdXN0b21lcnM7DQog LSBhIGNvbnRlbnQgcHJvdmlkZXIgbWF5IHJlbHkgb24gbW9yZSB0aGFuIG9uZSBDRE4uDQoNClRo ZXJlZm9yZSwgSSB0aGluayB0aGVyZSBpcyB2YWx1ZSBpbiBkZWZpbmluZyBhICh2ZXJ5KSBzaW1w bGUgcHJvdG9jb2wNCnRvIG1vZGVsIHRoZWlyIGludGVyYWN0aW9uLCBpbnN0ZWFkIG9mIGhhdmlu ZyB0byByZWludmVudCB0aGUgc2FtZQ0Kd2hlZWwgZWFjaCB0aW1lIGEgY29udGVudCBwcm92aWRl ciB3YW50cyB0byB1c2UgYSBuZXcgQ0ROLCBvciBhIENETg0KbXVzdCBwbHVnIGluIHRvIGEgZGlm ZmVyZW50IGNvbnRlbnQgcHJvdmlkZXIuDQoNClRoZSBpbnRlcmZhY2UgaXMgdHJpdmlhbCAtLSBi dXQgdGhpcyBpcyBub3QgYW4gYXJndW1lbnQgZm9yIG5vdCBoYXZpbmcNCmFuIGludGVyZmFjZSA6 LSkNCg0KQ2hlZXJzLCB0DQoNCg== From nobody Tue Jun 13 04:05:55 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27861314C4 for ; Tue, 13 Jun 2017 04:05:54 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=devever.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppG03__TtXYF for ; Tue, 13 Jun 2017 04:05:53 -0700 (PDT) Received: from umbriel.devever.net (umbriel.devever.net [149.202.51.241]) (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 3BB75131522 for ; Tue, 13 Jun 2017 04:03:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 8658A1D5B6; Tue, 13 Jun 2017 13:03:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=devever.net; h= user-agent:in-reply-to:content-transfer-encoding :content-disposition:content-type:content-type:mime-version :references:message-id:subject:subject:from:from:date:date :received:received; s=mimas; t=1497351831; x=1515541192; bh=ypjt NN7+D0Z8Td3WkFMChNDFy8BJmORsFgrauvfQCeY=; b=RWu3XT/qx2YvQedXu/IR W77JD0cXqwEDvTVoKjRQd1s2oXeFCVJpWKqlflUzzaTvGY1G8o7s5J8XKT6FYSBY 8wme5DaMcTEVELwNXoHiRj5luxjVrLEEkq8+M2egCMf4px789baV1Ksh4pHxA40k ewJKiE5ZGnSWW4EEmc2ZzUfpf+nG6VwSb8cbGi9F9YLxTIaTY5CEPckg8TZrbxKQ W6aOwRKQGkmI6BecSVlfjExCaUbp2XcJ0AnFUUVepvxk12tkJwqHoEbjnDz0md8X xTDQGnzfp0NOrmfdnSyfYFZqkNlASVLqJJspmSpmd7o7pVdeWHe7Dbf7Lnw4wp5X Bg== Received: from umbriel.devever.net ([127.0.0.1]) by localhost (umbriel.devever.net [127.0.0.1]) (amavisd-new, port 10026) with LMTP id AnSHczUtDnYf; Tue, 13 Jun 2017 13:03:51 +0200 (CEST) Received: from andover.lhh.devever.net (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 4C66E1D5A7; Tue, 13 Jun 2017 13:03:51 +0200 (CEST) Date: Tue, 13 Jun 2017 12:03:51 +0100 From: Hugo Landau To: Russ Housley Cc: acme@ietf.org Message-ID: <20170613110351.GA25244@andover.lhh.devever.net> References: <40e652477a2f47b0848330e64f72e8b2@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.8.1 (2017-04-11) Archived-At: Subject: Re: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 11:05:55 -0000 > Section 2 includes this text: >    . . .  A CA MUST only consider a property with an "account-uri" >    parameter to authorize issuance where the URI specified is an URI >    that the CA recognises as identifying the account making a >    certificate issuance request. > This is not a crust MUST statement.  I think it is trying to say two > things when the "account-uri” is present:  > (1)  the CA MUST NOT issue a certificate containing the domain name that > contains the CAA Resource Record if it does not recognize the account > referenced by the URI. > (2)  the CA MUST use the account referenced by the URI in the > authorization process for a certificate request for the domain containing > the CAA Resource Record. > If this is correct, please separate these two requirements.  If it is not > correct, please explain the text. What does "crust MUST" mean? I don't understand your interpretation. A CA does not "use" (select) an account as part of the issuance process; the account has already been determined from the context of the issuance request. From nobody Tue Jun 13 06:23:08 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A99131857 for ; Tue, 13 Jun 2017 06:23:07 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 PB_f13e72qSA for ; Tue, 13 Jun 2017 06:23:04 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 458421314F8 for ; Tue, 13 Jun 2017 06:23:04 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id q97so143388204wrb.2 for ; Tue, 13 Jun 2017 06:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hvVszYHQXYyzwHOyJXi5eF4bIkkkxDQw/28lOj4G5fs=; b=qRJsBfiX0QveltV8+cTNd3Gf/4ZCF2+9NEZ8GTH5gXBE/BFrW3qRbUOw7NXpYiS1G6 2ggfYJ33u/VjlyfIxKYboqJvYj5sTXyMnk3BeeFt25LKZkdM8oSPFOagotc+prnWgUBf fFmegf2MHgVH5bdGhGj2zZNhzmzC2Jl7AhGSr95b9cawtUvhrNx5Za/+hwha7q5ja8ED 1+0czlhDKLLbTobJBALNuBVNFnKd5BVG6GsRNRhno72lxn0JPQ2dpu5aNawZrTKgw+Jk bB3oMPdIYuQkTcIXx/vTE+NNmFhZc0GaMGWgA7O9wDh9dis2bHJu+3ykM1GPNY+DEfNk 8UGg== 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=hvVszYHQXYyzwHOyJXi5eF4bIkkkxDQw/28lOj4G5fs=; b=Lnl4mpmh0c2N8FYmvMBoaNMCouiBqQQfn2heGrNAiB4VdPhRZvcBkm1B5NdQA2+MsD MCwsAQmDly0c1aZZvxaN6EBZcZoCwCcRqurVWNFFUs7e6yjsLAyp9CWEtQApYPsvbpry IXP2fTfbfbKpd3KsoqrZTTfP7JkbA4f50mW0iVoUa6gAfORgJ+ChhRkhvgd6UPHyvl0n bv5V0aa85ljiXCRONKe/uaTHLyQwr+iiYklGaLTLJbOBtD7+ixyuwU6m0hFuakagKciB YoXJrEHV7ZXXFXyxo2S9m1Skxko/7JC6gPDOaAOzOvqPd1swnqdm1UGshXtJjbeOoPjP rjpw== X-Gm-Message-State: AKS2vOzFpE7+i2CaHUSUc6hk1KkBAJTL+wf33vZIcUmVU9pO4IZd/fN4 ZnZrd121sDGnRAZxAeEKdhYt8pSSDTjC X-Received: by 10.223.144.69 with SMTP id h63mr2791301wrh.187.1497360182515; Tue, 13 Jun 2017 06:23:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.109.16 with HTTP; Tue, 13 Jun 2017 06:23:01 -0700 (PDT) In-Reply-To: <40e652477a2f47b0848330e64f72e8b2@usma1ex-dag1mb1.msg.corp.akamai.com> References: <40e652477a2f47b0848330e64f72e8b2@usma1ex-dag1mb1.msg.corp.akamai.com> From: Richard Barnes Date: Tue, 13 Jun 2017 09:23:01 -0400 Message-ID: To: "Salz, Rich" Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a114c182ec7d1b20551d755de" Archived-At: Subject: Re: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 13:23:07 -0000 --001a114c182ec7d1b20551d755de Content-Type: text/plain; charset="UTF-8" Couple of minor comments: - It might be useful to specify validation methods even without ACME. The CAB Forum is working on whittling down the space of available mechanisms to an enumerated list, and while these might not completely overlap with ACME methods, it will be a small enough list to enumerate in a registry. I think the only impacts to this spec would be (1) to change from "acme-methods" to "validation-methods" and (2) to remove the "non-acme" value. - With regard to Section 5.1, it might be useful to note that as of Sept 2017, all Web PKI CAs will be required to check CAA; see 3.2.2.8 in https://github.com/cabforum/documents/blob/master/docs/BR.md - Using "CA A" as an example is kind of confusing :) Maybe "CA X" and "CA Y"? On Thu, Jun 8, 2017 at 11:27 AM, Salz, Rich wrote: > >> Hugo's CAA draft (already adopted, short, might be > > >> ready for WGLC) -- https://tools.ietf.org/html/draft-ietf-acme-caa-01 > > > > This has moved to WGLC. If you know of any reason why it should not > advance to the IESG, please post by end of next week. > > > > If you are willing to be the document shepherd for this document (see > https://www.ietf.org/iesg/template/doc-writeup.html; an essay style > writeup is fine), please let the chairs know soon. > > > > -- > > Senior Architect, Akamai Technologies > > Member, OpenSSL Dev Team > > IM: richsalz@jabber.at Twitter: RichSalz > > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --001a114c182ec7d1b20551d755de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Couple of minor comments:

- = It might be useful to specify validation methods even without ACME.=C2=A0 T= he CAB Forum is working on whittling down the space of available mechanisms= to an enumerated list, and while these might not completely overlap with A= CME methods, it will be a small enough list to enumerate in a registry.=C2= =A0 I think the only impacts to this spec would be (1) to change from "= ;acme-methods" to "validation-methods" and (2) to remove the= "non-acme" value.

- With regard to Sect= ion 5.1, it might be useful to note that as of Sept 2017, all Web PKI CAs w= ill be required to check CAA; see 3.2.2.8 in

- Using "CA A" as an example is kind of confusing :)= =C2=A0 Maybe "CA X" and "CA Y"?



On Thu, Jun 8, 2017 at 11:27 AM, Salz, Rich <rsalz@akamai.com>= ; wrote:

>>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hu= go's CAA draft (already adopted, short, might be

>> ready for WGLC) -- = https://tools.ietf.org/html/draft-ietf-acme-caa-01

=C2=A0

This has moved to WGLC.=C2=A0 If you know of any rea= son why it should not advance to the IESG, please post by end of next week.=

=C2=A0

If you are willing to be the document shepherd for t= his document (see https://www.ietf.org/iesg/template/doc-writeup.html; an ess= ay style writeup is fine), please let the chairs know soon.

=C2=A0

--=C2=A0

Senior Architect, Akamai Technologies<= /p>

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz

=C2=A0


_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


--001a114c182ec7d1b20551d755de-- From nobody Tue Jun 13 06:42:18 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F7412EABC for ; Tue, 13 Jun 2017 06:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=letsencrypt.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHy5Dgp2Zlly for ; Tue, 13 Jun 2017 06:42:15 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 E1826127201 for ; Tue, 13 Jun 2017 06:42:14 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id l6so29112215iti.1 for ; Tue, 13 Jun 2017 06:42:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=RQNGXkZ3H1j7QmoxAdDumXy0x2ss3HsjNYPNHaeRR1s=; b=cW1yVCy3F7bDEHY7pOv76sFWZkRx/Mm9vMKvI2jK/QimU+ZGBxJjEXOnFME2Bm8ZHL /7iYO9hq5X/G7OzmQRxc0m8utPfTYRX+3AhjwKKYd+T5y2/IDAul3l1upN8Hv/vxNbZ+ IpTeTlxzLPlMN/IE8xTuVQFAF4po2GAjXIQds= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=RQNGXkZ3H1j7QmoxAdDumXy0x2ss3HsjNYPNHaeRR1s=; b=kqNyQZ62UcOLqBHkhtbs08AztKUeqzgtAohiMZWPeoZKUKJk1FNH/16IJsMMOt+lHO k+H8S2vBWHVC7BGkPFSimQwMpxOKnvinfcAE1LkqWnVP0GRWOzPSl9UwhPiHbVznTcMx TKzfruvus8Q7Gh6QPk0yZyTAUKTzO8smKrfiuE96ZX5hrsthhQ83AYYpPeUElr0MGpl0 aPv1UeN5C/QR0s0RboVPzDLRiO3ulra3oMTlGWv/KgwOV3DccCPvzbltEHi8Wf7PO/A4 WygRTtQwUjYWWBgGoQirx++UhszAFFl4e0PV1UgbtA9nrX8fl67c4p9O5v/qtpOTpk2b izkQ== X-Gm-Message-State: AODbwcD/qwnb1vnaPfgS5RZ/+e7W4zSSzMcHMRtpl/n2Aq5xjoJSdQFi Cp1ATNKBJdq5W4ulyAVrgpJ43aETzMdi X-Received: by 10.36.190.139 with SMTP id i133mr17212636itf.3.1497361334195; Tue, 13 Jun 2017 06:42:14 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.140.134 with HTTP; Tue, 13 Jun 2017 06:42:13 -0700 (PDT) In-Reply-To: <619a3410875a451a91ca83cb8c39eeca@usma1ex-dag1mb1.msg.corp.akamai.com> References: <619a3410875a451a91ca83cb8c39eeca@usma1ex-dag1mb1.msg.corp.akamai.com> From: Daniel McCarney Date: Tue, 13 Jun 2017 09:42:13 -0400 Message-ID: To: "Salz, Rich" Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c19658c6cf1330551d79a9f" Archived-At: Subject: Re: [Acme] Call for adoption, ACME challenge for validating IP addresses X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 13:42:17 -0000 --94eb2c19658c6cf1330551d79a9f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > Should we adopt this draft? (Recall that adoption means it=E2=80=99s a g= ood > starting point, not that it=E2=80=99s almost done.) I'm a +1 in favour of the working group adopting this draft. On Thu, Jun 8, 2017 at 11:40 AM, Salz, Rich wrote: > At the interim, we briefly discussed this document: > > https://tools.ietf.org/html/draft-shoemaker-acme-ip-00 > > > > Yaron had some questions about use-cases, which Roland replied to on the > mailing list. > > > > Should we adopt this draft? (Recall that adoption means it=E2=80=99s a g= ood > starting point, not that it=E2=80=99s almost done.) > > > > Please reply by the end of next week. > > > > -- > > Senior Architect, Akamai Technologies > > Member, OpenSSL Dev Team > > IM: richsalz@jabber.at Twitter: RichSalz > > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --94eb2c19658c6cf1330551d79a9f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Should w= e adopt this draft?=C2=A0 (Recall that adoption means it=E2=80=99s a good s= tarting point, not that it=E2=80=99s almost done.)


I'm a +1 in f= avour of the working group adopting this draft.



On Thu, Ju= n 8, 2017 at 11:40 AM, Salz, Rich <rsalz@akamai.com> wrote:

At the interim, we briefly discussed this document:<= u>

=C2=A0=C2=A0=C2=A0 =C2=A0https://tools.iet= f.org/html/draft-shoemaker-acme-ip-00

=C2=A0

Yaron had some questions about use-cases, which Rola= nd replied to on the mailing list.

=C2=A0

Should we adopt this draft?=C2=A0 (Recall that adopt= ion means it=E2=80=99s a good starting point, not that it=E2=80=99s almost = done.)

=C2=A0

Please reply by the end of next week.

=C2=A0

--=C2=A0

Senior Architect, Akamai Technologies<= /p>

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz

=C2=A0


_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


--94eb2c19658c6cf1330551d79a9f-- From nobody Tue Jun 13 08:28:46 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A06131C25 for ; Tue, 13 Jun 2017 08:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 eN4m5k5eLt6d for ; Tue, 13 Jun 2017 08:28:42 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E1B01316DA for ; Tue, 13 Jun 2017 08:14:53 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5DF7Akh002069; Tue, 13 Jun 2017 16:14:51 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=1aLhVR02LcGCqarkBwYnHIpcGq6VvGboaJnmUEF4vmg=; b=hhPSL2+A8KMmiDCjnlst+VoV15cVZyrYDyaTcmp1aUHfE4XVhibiLCSQ7EDVOn6rxWrk gvxOaSeLtClq+sxvlFd60YXeHI8asIvlCZ01OhFKhWf+mm8KfqWsNKJqkUB2s3rbgPvq ZLm1VvdIV6ClYQoSmgNRJsyBokVRnDBSxGHsb1ExHfCLNzpoccWRt4vTdauYyR5bejoh 3AvgqvMtqiBFxecXuiPmE4Yf3fPakRgGPGjD73f+G1p1MAG7qvvHdtwp+cT627yBGb6X UUhac6gih4DrLo1Kv0+p8/P68EuL+QBYvhHyzVGXhi/xHhp0ByK0WqqL3jNKZ2QNOLus Yw== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2b29hrbrbx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Jun 2017 16:14:50 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5DF0ZBN025695; Tue, 13 Jun 2017 11:14:48 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2b0c3ujh7y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 13 Jun 2017 11:14:47 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 13 Jun 2017 11:14:47 -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.1263.000; Tue, 13 Jun 2017 11:14:47 -0400 From: "Salz, Rich" To: Richard Barnes CC: "acme@ietf.org" Thread-Topic: [Acme] Consensus -- CAA draft to WGLC? Thread-Index: AdLgaixZ2HxcGKQGRUWoL8+FK3tFFwD/4jaAAAR+qwA= Date: Tue, 13 Jun 2017 15:14:46 +0000 Message-ID: <177d761f214441a0b20bfc4ddc8dee9b@usma1ex-dag1mb1.msg.corp.akamai.com> References: <40e652477a2f47b0848330e64f72e8b2@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.34.162] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706130261 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706130262 Archived-At: Subject: Re: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 15:28:44 -0000 PiBDb3VwbGUgb2YgbWlub3IgY29tbWVudHM6DQoNClRoZXNlIHNlZW0gbGlrZSBhbGwgc3RyaWN0 bHkgZWRpdG9yaWFsIHRvIG1lLiAgQW55b25lIGRpc2FncmVlPw0KDQotLSAgDQpTZW5pb3IgQXJj aGl0ZWN0LCBBa2FtYWkgVGVjaG5vbG9naWVzDQpNZW1iZXIsIE9wZW5TU0wgRGV2IFRlYW0NCklN OiByaWNoc2FsekBqYWJiZXIuYXQgVHdpdHRlcjogUmljaFNhbHoNCg== From nobody Tue Jun 13 08:40:50 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEFF1319B5 for ; Tue, 13 Jun 2017 08:40:49 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 KTVeGWQ_044W for ; Tue, 13 Jun 2017 08:40:47 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 316FE131BDD for ; Tue, 13 Jun 2017 08:26:21 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id q97so148625613wrb.2 for ; Tue, 13 Jun 2017 08:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=5urQAWVQ38Efmhe2e7Z+jH4n1Ky/KzFEh1OsRBwd/SU=; b=Svce/X69OUWozpwsxQV+Eqfw5X4RoO2axPKb3rKjCTCcTCdThd3Ls7Y5aoW7p9t6TG NJXmyvKoD67lvHPL5XKFdw98XkMoplPzhqCBSyAZ8fWH7wON3Vlf2CtjLmSFgBvSeKoy oB0pHD1GEZAYtcEghuRS8idW85/GilyCsP4IkGLhOPD/Je9FB3W0/iT+PPcFs98GogMU unfMkvTxfxkx1ORKEAqCocjppJ9T/RVdwKwcjZayjRHOxVRzOXNsrlAnFGNbmxvo1D+C M5LSJ1z5QYzul/3JgZtdYuP9MvVMhqeA6c/xNV8xYwv0xvA8JHRBh1IU9v0FfVB9+jww fVjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5urQAWVQ38Efmhe2e7Z+jH4n1Ky/KzFEh1OsRBwd/SU=; b=qFkUEZQGQ2KGTZfMN1QTcVJuUeqDugd+3ZddxtSpyc0my9rW5SSUal2ovMNr2Tfoho NhMPQ5rQNjmGCnSzMRjs+aW7tO7Fj7XfgIkpnSy7jTYX2p20oULEYjktRV0XE6pLTXMa zNO6eOEScY/HbDdybnJfAMsCH2tGO7JjiTxzUbSvCJdW9B3gEoqF56Cz/cPCIReVNkMY koL1S+Seejd14O7vT3Szpnv9XpW+VQL4bEVYEmJMt5/P2zzBUES7C6Mf1wWTmqT3+fqY e05DRmzaqohSopLazMs0ueLeS7ohIHKNz7m/a709gxX6XAioXfKLShQxqynyIl/xMv+W XCIQ== X-Gm-Message-State: AKS2vOxF5HK5pkLdb+u1ZJn27GVkPyoQ7WuE3lhpzEk+iGVyqct2ZNQ1 dvI8DhtNfHnmGpKhd7XOHJVDxZ2dGobso+syWw== X-Received: by 10.223.173.137 with SMTP id w9mr3693998wrc.49.1497367579215; Tue, 13 Jun 2017 08:26:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.109.16 with HTTP; Tue, 13 Jun 2017 08:26:18 -0700 (PDT) From: Richard Barnes Date: Tue, 13 Jun 2017 11:26:18 -0400 Message-ID: To: "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a114b63a8a872460551d90e94" Archived-At: Subject: [Acme] v2 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 15:40:49 -0000 --001a114b63a8a872460551d90e94 Content-Type: text/plain; charset="UTF-8" (Everyone get your bike shed paint out....) In talking with a few folks around the community, I've heard people refer to the IETF version of ACME as "v2", where implicitly "v1" is the initial version deployed by Let's Encrypt and its clients right now. How would people feel about reflecting this in the draft / RFC? I've posted a PR with the changes this would entail: https://github.com/ietf-wg-acme/acme/pull/321 The only question this raises for me is what to do about v1. Given that Let's Encrypt has evolved their interface some since the first version, I'm not sure there's one consolidated spec out there for what they currently have deployed. So while it would be nice to have a reference to v1 in this document if we make it v2, I'm not inclined to worry about it too much. I'm willing to leave it up to the LE folks if they want to submit a v1 later for historical purposes. Any objections to merging the above PR? --Richard --001a114b63a8a872460551d90e94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Everyone get your bike shed paint out....)

In talking with a few folks around the community, I've = heard people refer to the IETF version of ACME as "v2", where imp= licitly "v1" is the initial version deployed by Let's Encrypt= and its clients right now.

How would people feel = about reflecting this in the draft / RFC?=C2=A0 I've posted a PR with t= he changes this would entail:


The only question this raises for me = is what to do about v1.=C2=A0 Given that Let's Encrypt has evolved thei= r interface some since the first version, I'm not sure there's one = consolidated spec out there for what they currently have deployed.=C2=A0 So= while it would be nice to have a reference to v1 in this document if we ma= ke it v2, I'm not inclined to worry about it too much.=C2=A0 I'm wi= lling to leave it up to the LE folks if they want to submit a v1 later for = historical purposes.

Any objections to merging= the above PR?

--Richard

--001a114b63a8a872460551d90e94-- From nobody Tue Jun 13 09:02:15 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C18131BBE for ; Tue, 13 Jun 2017 09:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 DwrtX0Z2MbsY for ; Tue, 13 Jun 2017 09:02:11 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 36A77131CC8 for ; Tue, 13 Jun 2017 08:52:02 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id m77so50526435lfe.0 for ; Tue, 13 Jun 2017 08:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=PsjwE+08v4XCtBUSl5eiSm4hSeE+0EKVUi/nT2zjYA4=; b=ixpOSMuUtNzFrOZ7zZviuGR1nUiVddRNB3CDZgWyNH3AkAvQIMkJBvwVo9e8ew82QS pJJmi7c3HobNfoks6/L+55gDx8nFqIYmFehBTIYy2t8QWLND1DHTJjk9SYPosHqFYkS1 TK4JfJITEw+ce3ZeZ2PFMw5rEtcLOyDd+I82JDNr9P/0dAZxiqiMUUAVrJDSWV500wMq gMvMPxNcNBUHO5VlfuF++J4wKOaDgGH+BZuHdvBbMPHn15q+Qsxj5HMxRKNJ+rDg04sf BApaKVuOjC8PU1+yhZs1lC2SIaLkRzg+BaarDEXseIFqXsfAik6Ml1S5tO/cn/aSl2bX IwoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=PsjwE+08v4XCtBUSl5eiSm4hSeE+0EKVUi/nT2zjYA4=; b=OlkUCOsmmbHPBFCqL3xGWYEX3sHsNJ6iG8hGE4HDE9WeUc1Jo7Y9r0y660YhbibvFO VvWqex9tC5ZIQK6s8w+IltANe1er7SYT0PVJSTdoS72ao/PTUkH/p1hE3Tg21/xhet3I Q8X+T2kZax7T+BkNKlJEW1pkAToRy2Sf1o1si7vVKulKctAZQLskrsEvNpqnc3fL5r+f Rzn6+qXHswUiG+ToumdWRAXzdergI6Z+Onys5OVY54ad4LEpoJ+FFibqBMvduibAlNDb JEAjVtKUCwjQbQ5u5y2ky0Nmn1cpLwSh7ifZgD9PBCGf+n2cTV3Os7ShFc/oUgzGIv+w CwVQ== X-Gm-Message-State: AKS2vOw3MJU3HzSDDLTKozFMZkR3JYMc023VaPV/cqPW4IGuaNrJJRqY qxRI214aHXqpJ1RjeEU= X-Received: by 10.80.135.208 with SMTP id 16mr414375edz.124.1497369120395; Tue, 13 Jun 2017 08:52:00 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id w16sm7205720eda.53.2017.06.13.08.51.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Jun 2017 08:51:59 -0700 (PDT) From: Yoav Nir Message-Id: <812A2F19-DF6F-4977-8FBD-B219A684ED3E@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_37707CCF-75F2-4133-853A-020C34DFEE97"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 13 Jun 2017 18:51:57 +0300 In-Reply-To: Cc: "acme@ietf.org" To: Richard Barnes References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Acme] v2 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 16:02:14 -0000 --Apple-Mail=_37707CCF-75F2-4133-853A-020C34DFEE97 Content-Type: multipart/alternative; boundary="Apple-Mail=_661BDC12-4BA0-4458-B7EE-14864FFEDAF1" --Apple-Mail=_661BDC12-4BA0-4458-B7EE-14864FFEDAF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Richard, I don=E2=80=99t feel strongly one way or the other, but I prefer to = think of what LE deployed as a PoC, like Google=E2=80=99s SPDY to the = IETF=E2=80=99s HTTP/2, or like Google=E2=80=99s QUIC to the IETF=E2=80=99s= =E2=80=A6 QUIC. Ot the Oakley protocol to IKE. But if someone needs LE=E2=80=99s protocol to be retroactively called = ACMEv1, I don=E2=80=99t mind. Yoav > On 13 Jun 2017, at 18:26, Richard Barnes wrote: >=20 > (Everyone get your bike shed paint out....) >=20 > In talking with a few folks around the community, I've heard people = refer to the IETF version of ACME as "v2", where implicitly "v1" is the = initial version deployed by Let's Encrypt and its clients right now. >=20 > How would people feel about reflecting this in the draft / RFC? I've = posted a PR with the changes this would entail: >=20 > https://github.com/ietf-wg-acme/acme/pull/321 = >=20 > The only question this raises for me is what to do about v1. Given = that Let's Encrypt has evolved their interface some since the first = version, I'm not sure there's one consolidated spec out there for what = they currently have deployed. So while it would be nice to have a = reference to v1 in this document if we make it v2, I'm not inclined to = worry about it too much. I'm willing to leave it up to the LE folks if = they want to submit a v1 later for historical purposes. >=20 > Any objections to merging the above PR? >=20 > --Richard >=20 > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme --Apple-Mail=_661BDC12-4BA0-4458-B7EE-14864FFEDAF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Richard,

I don=E2=80=99t feel strongly one way or the other, but I = prefer to think of what LE deployed as a PoC, like Google=E2=80=99s SPDY = to the IETF=E2=80=99s HTTP/2, or like Google=E2=80=99s QUIC to the = IETF=E2=80=99s=E2=80=A6 QUIC. Ot the Oakley protocol to = IKE. 

But = if someone needs LE=E2=80=99s protocol to be retroactively called = ACMEv1, I don=E2=80=99t mind.

Yoav

On = 13 Jun 2017, at 18:26, Richard Barnes <rlb@ipv.sx> wrote:

(Everyone get your bike shed paint = out....)

In = talking with a few folks around the community, I've heard people refer = to the IETF version of ACME as "v2", where implicitly "v1" is the = initial version deployed by Let's Encrypt and its clients right = now.

How would = people feel about reflecting this in the draft / RFC?  I've posted = a PR with the changes this would entail:

https://github.com/ietf-wg-acme/acme/pull/321

The only question this = raises for me is what to do about v1.  Given that Let's Encrypt has = evolved their interface some since the first version, I'm not sure = there's one consolidated spec out there for what they currently have = deployed.  So while it would be nice to have a reference to v1 in = this document if we make it v2, I'm not inclined to worry about it too = much.  I'm willing to leave it up to the LE folks if they want to = submit a v1 later for historical purposes.

Any objections to = merging the above PR?

--Richard

_______________________________________________
Acme = mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

= --Apple-Mail=_661BDC12-4BA0-4458-B7EE-14864FFEDAF1-- --Apple-Mail=_37707CCF-75F2-4133-853A-020C34DFEE97 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZQAodAAoJELhJCxUKWMyZwawIAKGb7qK/5LdWLGVYCPQLRIIv Amll3PazUS5IOIRJwuyPdM+DlAbmZfLNlxMZCa7WvWcPQ0kWlCZRXv5K/fS04GO3 yykNml1Qqm6gERVhIT7Os0tcNRJby4HY/jsHzy37O8E1tYysICvUzVMWT+QB5nxH 9K431LBGfMHzs/grb8wDAl5I3TNdy46Xg+QmUrJvyTzCthuhOcGKUv4s8w/etYWr S/2WHWHK8szwUWbsZS/qB+zwjTHRiReTiUn+le37Slq+gGgJyfHKtOsJ28D3M9+o rr2M3Bi+vwzy7850sPVRkYsdtWp7Ga3TU8WowstyJAwYAv4tae3bN8TcbRlXkLA= =ajB3 -----END PGP SIGNATURE----- --Apple-Mail=_37707CCF-75F2-4133-853A-020C34DFEE97-- From nobody Tue Jun 13 09:09:12 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4BA12EAF0 for ; Tue, 13 Jun 2017 09:09:11 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 v1GRpIB_SgBM for ; Tue, 13 Jun 2017 09:09:09 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 4F3E112EAF9 for ; Tue, 13 Jun 2017 08:59:25 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id 77so2372417wrb.1 for ; Tue, 13 Jun 2017 08:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lAsfkXdzQ7UhexCfIKBmdbCLGd7ImuNoTIUHkU5+Ed8=; b=owSwpQGU6j90emAyQPDVHyFIygs6QnH5KJWrqKhpo0vUyL2vwdtcrrWrjyQ981+s0A 5dg8mj3bT5jNmEwfjgP6h4AztiZWtViVWYBpzPmFSkoj2vmpkowiOxqbzwRKQpN/uDMO 8gDUFNyDkUhBTcLdEUjsFSEipBdgahVfIe+zM414cwW/ZsSL0GStlTNO2a/agWStVzyG iEFcEBepc/XFBP0K1BR7TH2GclLPAlRahtzYAgswdeDMWdtATn2fZKD6eFOCtUNm6FeN jmcJdbFa++gCz0pn+3d4bPt8TQmvWb92JOHGf5w+Dpl7TO2T1cslYTJZV/sYjimIdRZy 4ybg== 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=lAsfkXdzQ7UhexCfIKBmdbCLGd7ImuNoTIUHkU5+Ed8=; b=t3B6+uyCEyFmXVzR76UUGL0AYVgN8vxdLLSikgNReBVzoAVw54Rk1aff1PWKfLJPvx rdWCVedVrKE5OrxeC2v/PW3HXwY2ZumK+gepvUPK7LHhV6VtdqReC1DRE8u+zPuzM8lH Q5yHT51YR9OaOXGl8YQhRQrvC3OivHNml9YfbEY08PifMkgh8Uujc93TFyNhx+giIY6g 9AQ3kjtaPfBmCqfHTibY5473TU63o5rEELbx8Ja4qazuXZ5Z6hwFC8g0QsWB1G0/CpLR FOKrOprC+zC3k9h/FIizeFQJ8xYMwQq/lcfWySPetf/guy+IQyRMPYvtheP1/RwRMpsO 53sA== X-Gm-Message-State: AKS2vOx9/JlvgyMy0IYMnITYwm+E/pHwGYSSuYGG8Qck+C92s05ETH5e q+oZZjqyBZbPldLICWf8M/RmEcriY8c6 X-Received: by 10.28.26.135 with SMTP id a129mr3352351wma.11.1497369562220; Tue, 13 Jun 2017 08:59:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.109.16 with HTTP; Tue, 13 Jun 2017 08:59:21 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Tue, 13 Jun 2017 11:59:21 -0400 Message-ID: To: Zach Shepherd Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a114cd8ccdabaf60551d98488" Archived-At: Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 16:09:11 -0000 --001a114cd8ccdabaf60551d98488 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Zach, Thanks for submitting a PR on this. I just filed a review with some specific comments: https://github.com/ietf-wg-acme/acme/pull/312#pullrequestreview-43769669 This change seems fine to me, especially if we make the change I propose in there to digest the whole key authorization instead of just the token. I don't think there's a security problem here, but I also don't think stateless clients are tremendously valuable to the ecosystem, and it seems conservative to require more knowledge on the part of the verification host= . Looking at the thread, I'm not seeing strong objections. Unless I hear something here before Zach updates the PR, I'll go ahead and merge once that's done. --Richard On Mon, May 8, 2017 at 6:21 PM, Zach Shepherd wrote: > The following feedback is based on cd7c5e9 (current HEAD of master). > > Section 8.3 states that the token value for HTTP validation "MUST have at > least 128 bits of entropy." > > Section 11.3 explains that one goal of this is that "the entropy > requirement prevents ACME clients from implementing a =E2=80=9Cnaive=E2= =80=9D validation > server that automatically replies to challenges without participating in > the creation of the intial authorization request." > > However, because of the way the token is used in the validation process, > as a part of the request, this goal is not met. It is possible to configu= re > a webserver to respond to all requests under .well-known/acme-challenge > with the ASCII representation of the key authorization. (See, e.g., > https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode.) > > Essentially, the server informs the client of the token during the > validation process, removing any need for the client to have known it. > > If this is acceptable, the entropy requirement should be removed. If this > is unacceptable, the challenge and validation should be revised. > > Regards, > Zach Shepherd > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --001a114cd8ccdabaf60551d98488 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Zach,

Thanks for submitt= ing a PR on this.=C2=A0 I just filed a review with some specific comments:<= /div>


This change s= eems fine to me, especially if we make the change I propose in there to dig= est the whole key authorization instead of just the token.=C2=A0 I don'= t think there's a security problem here, but I also don't think sta= teless clients are tremendously valuable to the ecosystem, and it seems con= servative to require more knowledge on the part of the verification host.

Looking at the thread, I'm not seeing strong ob= jections.=C2=A0=C2=A0 Unless I hear something here before Zach updates the = PR, I'll go ahead and merge once that's done.

<= div>--Richard


=
On Mon, May 8, 2017 at 6:21 PM, Zach Shepherd <shepherdz@vmware.com> wrote:

The following feedback is based on cd7c5e9 (current HEAD of master).
Section 8.3 states that the token value for HTTP validation "MUST have= at least 128 bits of entropy."

Section 11.3 explains that one goal of this is that "the entropy requi= rement prevents ACME clients from implementing a =E2=80=9Cnaive=E2=80=9D va= lidation server that automatically replies to challenges without participat= ing in the creation of the intial authorization request."

However, because of the way the token is used in the validation process, as= a part of the request, this goal is not met. It is possible to configure a= webserver to respond to all requests under .well-known/acme-challenge with= the ASCII representation of the key authorization. (See, e.g., https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode.)

Essentially, the server informs the client of the token during the validati= on process, removing any need for the client to have known it.

If this is acceptable, the entropy requirement should be removed. If this i= s unacceptable, the challenge and validation should be revised.

Regards,
Zach Shepherd


_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


--001a114cd8ccdabaf60551d98488-- From nobody Tue Jun 13 09:11:25 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761901318DB for ; Tue, 13 Jun 2017 09:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 SFF_3Nd9n2Bo for ; Tue, 13 Jun 2017 09:11:20 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002: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 437E0131B3F for ; Tue, 13 Jun 2017 09:01:25 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id 63so53003898ywr.0 for ; Tue, 13 Jun 2017 09:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ggfvlqiRqbqhZDWbiP9XgaQ/e35lzkE1eovm7Yq6eTk=; b=cPkqyaggiGkTQsBcDsf5hXUktOod/oOjfAZx2Ngf0dgrVEaSP28z1L9r7U5m/VZd0e ZVAktHF9hKeoRa43snwPL41ILsjnpplvqs1evcI+xT3nuFGNl8UaPul3wOBMTtAXqxlG RAZkSgH///IO2Wf5MDrueCQEQYwYSfHhkBppHOmPORjHDIwgN9CdkEco9oZ5gHEo3gGk kXgnLa1JL9AITjfyw+QgCN1fR5hteq3tGPe971+hL0pQ2FQhgTz4+YgefoFZZyzMEjEV dwyGHF3R3b1+gqoMQexNIU3dQajhz7wq2j+1cpH2QltwqgB5o0MrejYiUjAt2o/c0ejo MgGA== 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=ggfvlqiRqbqhZDWbiP9XgaQ/e35lzkE1eovm7Yq6eTk=; b=kFvUqojBTB8+Lp0pwpuekHcz8q+3/WIdi4eWtxBhLZ2/ol88jmOiWbSWY6AuAx7J3P T0UqEGUQdyQHrzBuVZUN3nLf3I3RZuF6PTVe/R5dS7EMjsugavMBMf9Ahu5+07bqbVpl 9k+YsHYhCTc7j56BbDRtb7WlQxdypbaxjs1PsuKJMRMjy8dBent/+sgFA1tX+1qaow+R UWM+8Q2rk5ReahI0fQFUl/4UXZNaewwHfdGuvPxFMVICgFsTNMPAXj0Uw4pZvZwNH26G eFMugVV5dDVeJjwWzySC7mSfJwMgHRdzKI/hjgPVYiSodfZWbIgVCfmEHL3v5IDnzr0r OMjQ== X-Gm-Message-State: AKS2vOzyMYm/xsPE14uvEU4isqiesIoLzKfCd3W2I6ohF9cuPbmdA44B whXR2u2WdlL1vIfim8CVDngCkvVU7ASu X-Received: by 10.55.162.145 with SMTP id l139mr788673qke.162.1497369684326; Tue, 13 Jun 2017 09:01:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.34.9 with HTTP; Tue, 13 Jun 2017 09:00:53 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Tue, 13 Jun 2017 09:00:53 -0700 Message-ID: To: Richard Barnes Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a114fc6a621bcff0551d98ca7" Archived-At: Subject: Re: [Acme] v2 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 16:11:22 -0000 --001a114fc6a621bcff0551d98ca7 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 13, 2017 at 8:26 AM, Richard Barnes wrote: > (Everyone get your bike shed paint out....) > > The IETF logo has a goldenrod-colored network path in it--how about that? Or that pay lavender? > In talking with a few folks around the community, I've heard people refer > to the IETF version of ACME as "v2", where implicitly "v1" is the initial > version deployed by Let's Encrypt and its clients right now. > > How would people feel about reflecting this in the draft / RFC? I've > posted a PR with the changes this would entail: > > https://github.com/ietf-wg-acme/acme/pull/321 > > I would personally prefer this to be "Automatic Certificate Management Environment (ACME), IETF Version One". That's clear about where we are and let's us finesse the question of what version or version there were prior to the IETF version set starting. As you note, there are potentially multiple versions of the non-IETF version, given the evolution which has occurred. > The only question this raises for me is what to do about v1. Given that > Let's Encrypt has evolved their interface some since the first version, I'm > not sure there's one consolidated spec out there for what they currently > have deployed. So while it would be nice to have a reference to v1 in this > document if we make it v2, I'm not inclined to worry about it too much. > I'm willing to leave it up to the LE folks if they want to submit a v1 > later for historical purposes. > > Any objections to merging the above PR? > > In case it was not clear, my opinion above was as an individual. Ted > --Richard > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --001a114fc6a621bcff0551d98ca7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 13, 2017 at 8:26 AM, Richard Barnes <rlb@ipv.sx= > wrote:
(E= veryone get your bike shed paint out....)


The IETF logo has a goldenrod-colored network pat= h in it--how about that?=C2=A0 Or that pay lavender?
=C2=A0
In talking with a few folks around the community, I've hear= d people refer to the IETF version of ACME as "v2", where implici= tly "v1" is the initial version deployed by Let's Encrypt and= its clients right now.

How would people feel abou= t reflecting this in the draft / RFC?=C2=A0 I've posted a PR with the c= hanges this would entail:



I would personally prefer this to be "Automatic Certificate Management Environment (ACME), IETF Version One".=C2=A0 That's clear about where we are and let's us finesse= the question of what version or version there were prior to the IETF versi= on set starting.=C2=A0 As you note, there are potentially multiple versions= of the non-IETF version, given the evolution which has occurred.
=
=C2=A0
The only question this raises for me is what to do= about v1.=C2=A0 Given that Let's Encrypt has evolved their interface s= ome since the first version, I'm not sure there's one consolidated = spec out there for what they currently have deployed.=C2=A0 So while it wou= ld be nice to have a reference to v1 in this document if we make it v2, I&#= 39;m not inclined to worry about it too much.=C2=A0 I'm willing to leav= e it up to the LE folks if they want to submit a v1 later for historical pu= rposes.

Any objections to merging the above PR= ?

=

In case it was not cle= ar, my opinion above was as an individual.

Ted=
=C2=A0
--Richard


_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


--001a114fc6a621bcff0551d98ca7-- From nobody Tue Jun 13 09:54:32 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1729C12EC15 for ; Tue, 13 Jun 2017 09:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 M4Iy9UlxgC-D for ; Tue, 13 Jun 2017 09:54:29 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 C172F129AA4 for ; Tue, 13 Jun 2017 09:54:28 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id m77so51831529lfe.0 for ; Tue, 13 Jun 2017 09:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BQSLFhgbuW1z70/wMOPiRbcJsDcE20Vf7R9QwDS3zvU=; b=u9txQdQDBkQLWgC4dqZ9YSuexkTfqngUlbkAx5OlloDUffBs4aTYcXJGJybTrcGy8L 08JSaiZ/mp5NY9UXnv+njXvN4oJVLZeAmb7lr11Cb2uoWYQpOdzCV9sj3ANg5Igl23NE oSjBrrVTysS9znC20P2vNH4OSTG1tu5zCbtD8hrsR7p5q4ZVtSV/ynMcWhkq9VgKKO9G QDlwu79IbNxrEH+YxQz6gjODqzLg/xUKMD2AgxOxOvDur9vulKIiEzeKCa1/IX2+nHnk nHvhEusdx3FHuuYx/8AmX+00m4p126MiJjWcls68CWSzOlc6Uj/xwfmT/mKBrOtGPyTs EqUA== 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=BQSLFhgbuW1z70/wMOPiRbcJsDcE20Vf7R9QwDS3zvU=; b=b+Fvyw/skWZHbQ1LAJ95klWvHfm5Ikl6BjOQL28ZUccn/+GftO7ITJ5Pbze1TRFx2l 5Bili83A7U1hg/wyiYEoG6Z9veGcnMg5X2dhCRtQjFaE9qPvu8TzJCo+Id+F+xabyTMG T2lWwpanGAhtaXVV9zYZQ1Lrivz8V7YRWtjud/UBauLRl6QQecTmPDthK8aRx12fQris KTNi3JkDtkwn7Xa8cZYoh1NiFTlJaWzjHrhB261gY9VeYELr+Mcd0JUGaWRo/lL8MDA5 0kwyEbVVMPW31rftPdq7DBBCcCXRDCMtawAttMmZVy3GNiNQ9Q8tkB/CzD32qALevl46 SMfw== X-Gm-Message-State: AKS2vOyALZDYozoqg5iF/8VtK879WCyrJbcTZkgh/F2C9t8+Q2HWCOg1 EUk1vbOfG4YwnFKQYoVsjCy8tLsu1OQy X-Received: by 10.46.20.22 with SMTP id u22mr317598ljd.113.1497372866880; Tue, 13 Jun 2017 09:54:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.8.66 with HTTP; Tue, 13 Jun 2017 09:54:26 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 13 Jun 2017 17:54:26 +0100 Message-ID: To: Richard Barnes Cc: "acme@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Acme] v2 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 16:54:31 -0000 I don't see the distinction between what LE deploy and ACME as defined by the IETF being any different to the distinction between whatever any other CA currently deploy and the IETF spec. It's a thing that exists, but I see no reason to accord the LE proprietary protocol any special status other than by acknowledging provenance. This is the IETF version of ACME, and as such it needs no version qualification. I doubt that there will be any confusion from this being deployed alongside the proprietary LE protocol. On 13 June 2017 at 16:26, Richard Barnes wrote: > (Everyone get your bike shed paint out....) > > In talking with a few folks around the community, I've heard people refer to > the IETF version of ACME as "v2", where implicitly "v1" is the initial > version deployed by Let's Encrypt and its clients right now. > > How would people feel about reflecting this in the draft / RFC? I've posted > a PR with the changes this would entail: > > https://github.com/ietf-wg-acme/acme/pull/321 > > The only question this raises for me is what to do about v1. Given that > Let's Encrypt has evolved their interface some since the first version, I'm > not sure there's one consolidated spec out there for what they currently > have deployed. So while it would be nice to have a reference to v1 in this > document if we make it v2, I'm not inclined to worry about it too much. I'm > willing to leave it up to the LE folks if they want to submit a v1 later for > historical purposes. > > Any objections to merging the above PR? > > --Richard > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > From nobody Tue Jun 13 10:23:59 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE72612941D for ; Tue, 13 Jun 2017 10:23:57 -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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 a7bi9L_TZ-bj for ; Tue, 13 Jun 2017 10:23:55 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id CC18F1272E1 for ; Tue, 13 Jun 2017 10:23:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 760C0395E8; Tue, 13 Jun 2017 20:23:52 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id uOrqGDS6oNR8; Tue, 13 Jun 2017 20:23:52 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 2A2E2C4; Tue, 13 Jun 2017 20:23:52 +0300 (EEST) Date: Tue, 13 Jun 2017 20:23:47 +0300 From: Ilari Liusvaara To: Richard Barnes Cc: Zach Shepherd , "acme@ietf.org" Message-ID: <20170613172347.GA12048@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 17:23:58 -0000 On Tue, Jun 13, 2017 at 11:59:21AM -0400, Richard Barnes wrote: > Hey Zach, > > Thanks for submitting a PR on this. I just filed a review with some > specific comments: > > https://github.com/ietf-wg-acme/acme/pull/312#pullrequestreview-43769669 > > This change seems fine to me, especially if we make the change I propose in > there to digest the whole key authorization instead of just the token. I > don't think there's a security problem here, but I also don't think > stateless clients are tremendously valuable to the ecosystem, and it seems > conservative to require more knowledge on the part of the verification host. > > Looking at the thread, I'm not seeing strong objections. Unless I hear > something here before Zach updates the PR, I'll go ahead and merge once > that's done. I think that if one wanted to be consistent among different validation methods, then challenges would be based on hash of one thing, and the responses would be (hash of) another. However, I do not think it is sufficient for security to take just the random token for request, and random token + accout JWT for response. The problems with do not manifest in HTTP nor DNS, since HTTP and DNS requests are also bound to the validatio name (via virtual host and QNAME respectively) as fundamential part of request process. However, TLS-SNI is another matter. There is nothing binding validation to domain name, not even if preimages are disclosed. And this in my view causes TLS-SNI to fail to validate the domain itself, instead validating the underlying IP address. Now, the lack of this binding does not manifest when the server is dedicated and the webmaster has full control of the entiere server, however it does manifest if the server is shared between multiple tenants. The server has no way of determining if the challenge- response pairs are legimate or not. To fix this, I think that the identifier being validated should be included in requests (and possibly responses). One scheme I considered earlier (but didn't actually send a mail about, due to writing the mail to a wrong place): Request form would be (before hashing): TR... And response form would be (possibly before hashing): KA.... (I included message tags and methods to follow good practice of separating different messages, altough in this case, there is no way to confuse the two, since number of periods is different.) Now, disclosing the preimages allows verifying that the challenge- response pair is a validation of legimate domain. -Ilari From nobody Tue Jun 13 10:31:23 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD981319F9 for ; Tue, 13 Jun 2017 10:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 o7rnv4-gOJpl for ; Tue, 13 Jun 2017 10:31:20 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 34276131A09 for ; Tue, 13 Jun 2017 10:31:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 31A9E636AE; Tue, 13 Jun 2017 20:31:10 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id OBmLnM_6ccEz; Tue, 13 Jun 2017 20:31:10 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 055B427B; Tue, 13 Jun 2017 20:31:10 +0300 (EEST) Date: Tue, 13 Jun 2017 20:31:05 +0300 From: Ilari Liusvaara To: "Salz, Rich" Cc: Richard Barnes , "acme@ietf.org" Message-ID: <20170613173105.GB12048@LK-Perkele-V2.elisa-laajakaista.fi> References: <40e652477a2f47b0848330e64f72e8b2@usma1ex-dag1mb1.msg.corp.akamai.com> <177d761f214441a0b20bfc4ddc8dee9b@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <177d761f214441a0b20bfc4ddc8dee9b@usma1ex-dag1mb1.msg.corp.akamai.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 17:31:22 -0000 On Tue, Jun 13, 2017 at 03:14:46PM +0000, Salz, Rich wrote: > > Couple of minor comments: > > These seem like all strictly editorial to me. Anyone disagree? The two last ones are editorial, but the first about enumerating all BR methods isn't (since it needs new validation method identifiers). One list of all BR methods is: "contact-applicant" (method 1 validation) "contact-email" (method 2 validation) "contact-fax" (method 2 validation) "contact-sms" (method 2 validation) <-- Anyone scared yet? "contact-postal" (method 2 validation) "contact-phone" (method 3 validation) "domain-email" (method 4 validation) "authz-doc" (method 5 validation) "http" (method 6 validation) <-- ACME HTTP-xx. "dns" (method 7 validation) <-- ACME DNS-xx "ip" (method 8 validation) "test-cert" (method 9 validation) "random-cert" (method 10 validation) <-- Possbibly TLS-SNI-xx? (The method 2 has email, fax, SMS and postal mail as options, those four have rather different security properties). -Ilari From nobody Tue Jun 13 10:33:55 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E752A1319F8 for ; Tue, 13 Jun 2017 10:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 SDwtreWjuGrf for ; Tue, 13 Jun 2017 10:33:53 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EF1F12EC38 for ; Tue, 13 Jun 2017 10:33:53 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5DHXU5w029593; Tue, 13 Jun 2017 18:33:52 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=52Qo+UrieFoaMt8hQcLAEaaldmd42mpa3mp3OEGEU54=; b=cjckaTzfazI23PbACuBKG3VByVlIYcRU0xYqNRkeX6btxa6FTv7cdDQdBEICTmWjIRHa 8y2EwoPntgv+HRbhbj2dTGWup6wLOVGJDR0VGuQzyAHo+CGOhMsZEO6kr0hzBJYeXIHh LlpiCKK7kvvpX3XS01SpHekyD/S0eMCdc4iBR89u5xMl6Di0XyTfQKpf3sjFpHMQZFxL jVzt4vWNH+SamOuHaG6rcEL7AAA1YIvt4/R8oP4KiTcyI2EdE041arnMMC1FtTD2l0U3 yqZk5YFYbKeXd/lcZLELsoqI6kL3aXwnsfudaFVzMXPiTMuRj/t3GMg6Vf/6457lxQyQ HA== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2b29hrcqnn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Jun 2017 18:33:51 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5DHQ0qQ028511; Tue, 13 Jun 2017 13:33:49 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2b0c3uax8w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 13 Jun 2017 13:33:49 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb4.msg.corp.akamai.com (172.27.123.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 13 Jun 2017 10:33:49 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 13 Jun 2017 13:33:49 -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.1263.000; Tue, 13 Jun 2017 13:33:49 -0400 From: "Salz, Rich" To: "ilariliusvaara@welho.com" CC: Richard Barnes , "acme@ietf.org" Thread-Topic: [Acme] Consensus -- CAA draft to WGLC? Thread-Index: AdLgaixZ2HxcGKQGRUWoL8+FK3tFFwD/4jaAAAR+qwAABCs5gAAIUaCA Date: Tue, 13 Jun 2017 17:33:48 +0000 Message-ID: <8baacb86ea9b455291fab177ce85b5ce@usma1ex-dag1mb1.msg.corp.akamai.com> References: <40e652477a2f47b0848330e64f72e8b2@usma1ex-dag1mb1.msg.corp.akamai.com> <177d761f214441a0b20bfc4ddc8dee9b@usma1ex-dag1mb1.msg.corp.akamai.com> <20170613173105.GB12048@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20170613173105.GB12048@LK-Perkele-V2.elisa-laajakaista.fi> 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.162] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706130299 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706130301 Archived-At: Subject: Re: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 17:33:55 -0000 PiBUaGUgdHdvIGxhc3Qgb25lcyBhcmUgZWRpdG9yaWFsLCBidXQgdGhlIGZpcnN0IGFib3V0IGVu dW1lcmF0aW5nIGFsbCBCUg0KPiBtZXRob2RzIGlzbid0IChzaW5jZSBpdCBuZWVkcyBuZXcgdmFs aWRhdGlvbiBtZXRob2QgaWRlbnRpZmllcnMpLg0KDQpUaGlua2luZyBhYm91dCBpdCBhIGJpdCBt b3JlLCBJIGRvbid0IHRoaW5rIGl0IGlzIGFwcHJvcHJpYXRlIGZvciBBQ01FIHRvIGxpc3QgQ0FC RiB0aGluZ3MuICBUaGF0J3MgYSBzdHJvbmcgdmlldyBhcyBhbiBpbmRpdmlkdWFsLCBhbmQgYSBt b2RlcmF0ZSB2aWV3IGFzIGEgV0cgY2hhaXIuDQo= From nobody Tue Jun 13 10:36:30 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3787D1319F1 for ; Tue, 13 Jun 2017 10:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=letsencrypt.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dppcjwVpOiru for ; Tue, 13 Jun 2017 10:36:25 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 731FB12940E for ; Tue, 13 Jun 2017 10:36:25 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id k93so78043882ioi.2 for ; Tue, 13 Jun 2017 10:36:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=RUIRlkx3aHH04JQm4JCr4SSGeSovCKTNrZ3DPhbEcPo=; b=KaUux/d83Ro0AEdd7Wp+584quH4Qw6lV8H5c8YzzhiyMeGR0Y7KEoIrg/YBRYv3L+J ocftGcK/onvpkEitvK6w53/7QYjsADIVYB2nyhYVI4amjrKsjH9VVSpjFhsGG8kgtVku tx5xa+gBH4J+h4a+e5Q823jS3b1KPKjtiQLdM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=RUIRlkx3aHH04JQm4JCr4SSGeSovCKTNrZ3DPhbEcPo=; b=VtnxuV0jgSUoGnJHkNNjTdhh8wTILTNG8LV5XR4cZTHpYgeJtzQ2KAqo15vEChbTaO RuWHHWEoiPlzPDaysYIHXYDoX5klu88SVAMgx89cJYWuLMykXobbXba8H7N+zSStFtYb VMwSX2GltA9t63PYC7EDCz/CGfCNWCiCB3F/kytD/lNFqVp6xo9n2W9I0rZP4JeXOSqh lgsgkUkfNeGwnJV6053PrmC9G8v+DBT5StNwjSwZoIBuwsYfE4288hTnM3NqcHB+fJ7F lMvWhPKp554D5GGdd8UNQXrZ6s1VGhi4w6WeelUcKeHJj6li223F71MLLiU25aIrA3nt iv+Q== X-Gm-Message-State: AKS2vOzLe6WU9Jc3Pf8b9CV2zs5xQrJiUTsheauL19EwTW9RCq+65PP3 Zy65K9JgBn3Pc2XT8Ja/mtl6G91yNBm+jdihvA== X-Received: by 10.107.16.217 with SMTP id 86mr1488862ioq.134.1497375384778; Tue, 13 Jun 2017 10:36:24 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.140.134 with HTTP; Tue, 13 Jun 2017 10:36:24 -0700 (PDT) In-Reply-To: References: From: Daniel McCarney Date: Tue, 13 Jun 2017 13:36:24 -0400 Message-ID: To: Richard Barnes Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a113ecee8e7f1340551dadfe5" Archived-At: Subject: Re: [Acme] v2 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 17:36:28 -0000 --001a113ecee8e7f1340551dadfe5 Content-Type: text/plain; charset="UTF-8" > > Given that Let's Encrypt has evolved their interface some since the first > version, I'm not sure there's one consolidated spec out there for what they > currently have deployed. There isn't AFAIK - the closest thing is the list of "boulder divergences" we maintain along with the current-most draft: https://github.com/letsencrypt/boulder/blob/master/docs/acme-divergences.md I'm willing to leave it up to the LE folks if they want to submit a v1 > later for historical purposes. I suspect that since LE & Boulder evolved alongside the drafts its probably more trouble than its worth to try and create a snapshot of a specific point in LE's existence to describe the protocol at that point. On Tue, Jun 13, 2017 at 11:26 AM, Richard Barnes wrote: > (Everyone get your bike shed paint out....) > > In talking with a few folks around the community, I've heard people refer > to the IETF version of ACME as "v2", where implicitly "v1" is the initial > version deployed by Let's Encrypt and its clients right now. > > How would people feel about reflecting this in the draft / RFC? I've > posted a PR with the changes this would entail: > > https://github.com/ietf-wg-acme/acme/pull/321 > > The only question this raises for me is what to do about v1. Given that > Let's Encrypt has evolved their interface some since the first version, I'm > not sure there's one consolidated spec out there for what they currently > have deployed. So while it would be nice to have a reference to v1 in this > document if we make it v2, I'm not inclined to worry about it too much. > I'm willing to leave it up to the LE folks if they want to submit a v1 > later for historical purposes. > > Any objections to merging the above PR? > > --Richard > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --001a113ecee8e7f1340551dadfe5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Given that Let's Encrypt has evolved their int= erface some since the first version, I'm not sure there's one conso= lidated spec out there for what they currently have deployed.

There isn't AFAIK - the closest thing is the list of &qu= ot;boulder divergences" we maintain along with the current-most draft:= https://github.com/letsencrypt/boulder/blob/master/docs/acme-= divergences.md

=C2=A0=C2=A0I'm willing to leave it up to the LE folks if they want to s= ubmit a v1 later for historical purposes.

I sus= pect that since LE & Boulder evolved alongside the drafts its probably = more trouble than its worth to try and create a snapshot of a specific poin= t in LE's existence to describe the protocol at that point.
=

=
On Tue, Jun 13, 2017 at 11:26 AM, Richard Ba= rnes <= rlb@ipv.sx> wrote:
(Everyone get your bike shed paint out....)

In talking with a few folks around the community, I've heard pe= ople refer to the IETF version of ACME as "v2", where implicitly = "v1" is the initial version deployed by Let's Encrypt and its= clients right now.

How would people feel about re= flecting this in the draft / RFC?=C2=A0 I've posted a PR with the chang= es this would entail:


The only question this= raises for me is what to do about v1.=C2=A0 Given that Let's Encrypt h= as evolved their interface some since the first version, I'm not sure t= here's one consolidated spec out there for what they currently have dep= loyed.=C2=A0 So while it would be nice to have a reference to v1 in this do= cument if we make it v2, I'm not inclined to worry about it too much.= =C2=A0 I'm willing to leave it up to the LE folks if they want to submi= t a v1 later for historical purposes.

Any obje= ctions to merging the above PR?

--Richard


_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


--001a113ecee8e7f1340551dadfe5-- From nobody Tue Jun 13 10:39:47 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 084F4131A0B for ; Tue, 13 Jun 2017 10:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=letsencrypt.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0esInuC2B2vm for ; Tue, 13 Jun 2017 10:39:42 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 3C4181319F3 for ; Tue, 13 Jun 2017 10:39:42 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id k93so78099352ioi.2 for ; Tue, 13 Jun 2017 10:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=65Y4NM1cjitvJ5Y0By/SaUjqCeK3oTRKn39+/ZsicKE=; b=JjwoWg/aI3jxIhUMEknnvRIlUC0gmZ/eVINhrtvCV5AarjWwrz/Mrll9bxuvd81dYD UbuOnN7xBsUZAL1vKZP+Fy/C3goNrfFTB5+qWqKRHnAPQGoYhTiBngD9JNSWoTrdmIfL QwJM88SyKWYt6NLhvGvzJlHGf637xIarJ0fyo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=65Y4NM1cjitvJ5Y0By/SaUjqCeK3oTRKn39+/ZsicKE=; b=gtYIBMiSFGl1Hq5d/BimN4vHKVR5TsUj8e6M7sT53Hu8ReyCQAwJnUV8ulIP1NUKhA 67Qp55OmFUh4ooNJkQfuvAJlFDjexdWjJmmaFhQuSXicYQjCjCitNfCM3KoV7nb4VjoL 7u7Iw9VvBrYWK2Fa22M1vx3fl0dhDx9LB64pfSydcHt/qGehpsbMcgwgWCPBAPK5s0IQ Twh2zR42fTdveUr9ktcdEgRsulKgqJFmE4xHjEEtFwYR4PaEeMWVBy3cO46M15rkbI8j 8Dj3EHFJnS01wAqI2wPKg3aDdX7lq73nFgaoV3nE3sYuSA5DTJPS8lXCAyG6m0zEv8Rz v3gA== X-Gm-Message-State: AKS2vOxxu0DtlNX4f1aloMzvzqhMFNhanib0zrjwlejQUhNO6+0IXQUF ZWUjbouQFzBfAl9scs27qSpjaR5hZfRL X-Received: by 10.107.16.217 with SMTP id 86mr1508081ioq.134.1497375581525; Tue, 13 Jun 2017 10:39:41 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.140.134 with HTTP; Tue, 13 Jun 2017 10:39:41 -0700 (PDT) In-Reply-To: References: From: Daniel McCarney Date: Tue, 13 Jun 2017 13:39:41 -0400 Message-ID: To: Martin Thomson Cc: Richard Barnes , "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a113ecee8a1e9990551daebaa" Archived-At: Subject: Re: [Acme] v2 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 17:39:45 -0000 --001a113ecee8a1e9990551daebaa Content-Type: text/plain; charset="UTF-8" > > I don't see the distinction between what LE deploy and ACME as defined by > the IETF being any different to the distinction between whatever any > other CA currently deploy and the IETF spec. The relatively ad-hoc things that CAs deploy today aren't referred to as ACME, or used by what people refer to as ACME clients. I don't think its a fair comparison to the situation we're in today where there are a number of clients that call themselves "ACME clients" written to work with "ACME v1" who are likely to be confused by the fact their clients don't work out-of-box with IETF ACME. I doubt that there will be any confusion from this being deployed alongside > the proprietary LE protocol I disagree. There is already fairly substantial confusion among client developers, server developers and users about what ACME is and how it relates to the Let's Encrypt service. On Tue, Jun 13, 2017 at 12:54 PM, Martin Thomson wrote: > I don't see the distinction between what LE deploy and ACME as defined > by the IETF being any different to the distinction between whatever > any other CA currently deploy and the IETF spec. It's a thing that > exists, but I see no reason to accord the LE proprietary protocol any > special status other than by acknowledging provenance. > > This is the IETF version of ACME, and as such it needs no version > qualification. I doubt that there will be any confusion from this > being deployed alongside the proprietary LE protocol. > > On 13 June 2017 at 16:26, Richard Barnes wrote: > > (Everyone get your bike shed paint out....) > > > > In talking with a few folks around the community, I've heard people > refer to > > the IETF version of ACME as "v2", where implicitly "v1" is the initial > > version deployed by Let's Encrypt and its clients right now. > > > > How would people feel about reflecting this in the draft / RFC? I've > posted > > a PR with the changes this would entail: > > > > https://github.com/ietf-wg-acme/acme/pull/321 > > > > The only question this raises for me is what to do about v1. Given that > > Let's Encrypt has evolved their interface some since the first version, > I'm > > not sure there's one consolidated spec out there for what they currently > > have deployed. So while it would be nice to have a reference to v1 in > this > > document if we make it v2, I'm not inclined to worry about it too much. > I'm > > willing to leave it up to the LE folks if they want to submit a v1 later > for > > historical purposes. > > > > Any objections to merging the above PR? > > > > --Richard > > > > > > _______________________________________________ > > Acme mailing list > > Acme@ietf.org > > https://www.ietf.org/mailman/listinfo/acme > > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a113ecee8a1e9990551daebaa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't see the distinction between what LE de= ploy and ACME as defined=C2=A0by th= e IETF being any different to the distinction between whatever=C2=A0= any other CA currently deploy and the IETF= spec.=C2=A0=C2=A0

The relatively ad-hoc things= that CAs deploy today aren't referred to as ACME, or used by what peop= le refer to as ACME clients. I don't think its a fair comparison to the= situation we're in today where there are a number of clients that call= themselves "ACME clients" written to work with "ACME v1&quo= t; who are likely to be confused by the fact their clients don't work o= ut-of-box with IETF ACME.

I doubt that there will be any con= fusion from this=C2=A0being deploye= d alongside the proprietary LE protocol

I disag= ree. There is already fairly substantial confusion among client developers,= server developers and users about what ACME is and how it relates to the L= et's Encrypt service.=C2=A0

On Tue, Jun 13, 2017 at 12:54 PM, Martin Th= omson <martin.thomson@gmail.com> wrote:
I don't see the distinction between what LE deploy= and ACME as defined
by the IETF being any different to the distinction between whatever
any other CA currently deploy and the IETF spec.=C2=A0 It's a thing tha= t
exists, but I see no reason to accord the LE proprietary protocol any
special status other than by acknowledging provenance.

This is the IETF version of ACME, and as such it needs no version
qualification.=C2=A0 I doubt that there will be any confusion from this
being deployed alongside the proprietary LE protocol.

On 13 June 2017 at 16:26, Richard Barnes <rlb@ipv.sx> wrote:
> (Everyone get your bike shed paint out....)
>
> In talking with a few folks around the community, I've heard peopl= e refer to
> the IETF version of ACME as "v2", where implicitly "v1&= quot; is the initial
> version deployed by Let's Encrypt and its clients right now.
>
> How would people feel about reflecting this in the draft / RFC?=C2=A0 = I've posted
> a PR with the changes this would entail:
>
> https://github.com/ietf-wg-acme/acme/pull/321=
>
> The only question this raises for me is what to do about v1.=C2=A0 Giv= en that
> Let's Encrypt has evolved their interface some since the first ver= sion, I'm
> not sure there's one consolidated spec out there for what they cur= rently
> have deployed.=C2=A0 So while it would be nice to have a reference to = v1 in this
> document if we make it v2, I'm not inclined to worry about it too = much.=C2=A0 I'm
> willing to leave it up to the LE folks if they want to submit a v1 lat= er for
> historical purposes.
>
> Any objections to merging the above PR?
>
> --Richard
>
>
> __________________= _____________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme >

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

--001a113ecee8a1e9990551daebaa-- From nobody Tue Jun 13 10:44:02 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36FF012947D for ; Tue, 13 Jun 2017 10:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 Mnr__Uj7b5EO for ; Tue, 13 Jun 2017 10:43:58 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id A4FF5129478 for ; Tue, 13 Jun 2017 10:43:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id C8505394A2; Tue, 13 Jun 2017 20:43:57 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id qR02wkdFGS3E; Tue, 13 Jun 2017 20:43:57 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 90E60C4; Tue, 13 Jun 2017 20:43:57 +0300 (EEST) Date: Tue, 13 Jun 2017 20:43:53 +0300 From: Ilari Liusvaara To: "Salz, Rich" Cc: Richard Barnes , "acme@ietf.org" Message-ID: <20170613174352.GD12048@LK-Perkele-V2.elisa-laajakaista.fi> References: <40e652477a2f47b0848330e64f72e8b2@usma1ex-dag1mb1.msg.corp.akamai.com> <177d761f214441a0b20bfc4ddc8dee9b@usma1ex-dag1mb1.msg.corp.akamai.com> <20170613173105.GB12048@LK-Perkele-V2.elisa-laajakaista.fi> <8baacb86ea9b455291fab177ce85b5ce@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <8baacb86ea9b455291fab177ce85b5ce@usma1ex-dag1mb1.msg.corp.akamai.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 17:44:00 -0000 On Tue, Jun 13, 2017 at 05:33:48PM +0000, Salz, Rich wrote: > > The two last ones are editorial, but the first about enumerating all BR > > methods isn't (since it needs new validation method identifiers). > > Thinking about it a bit more, I don't think it is appropriate for > ACME to list CABF things. That's a strong view as an individual, > and a moderate view as a WG chair. Yeah, the major problem includes keeping the list up to date if a new method comes about. Or if some method is modified in major way. -Ilari From nobody Wed Jun 14 01:50:21 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3A1128B37 for ; Wed, 14 Jun 2017 01:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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] 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 YjJXZLoBfbUp for ; Wed, 14 Jun 2017 01:50:17 -0700 (PDT) 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 AF38A126BF0 for ; Wed, 14 Jun 2017 01:50:17 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id l75so61964481ywc.3 for ; Wed, 14 Jun 2017 01:50:17 -0700 (PDT) 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=e0+Cj9P9wmBpeAqSbTNOSZs3toMyfGY1ny8aS7GvhGo=; b=t0twXXCLbKxCMsDZELTeTk9Mr732YhsQgr5puwWGpE7C3bJ1EviHT+j6M+nfNMauzP lzWapMOuvLP4ZUBOC/xb+k4rRrgR3o6iiLhR176M50fS8Sy2HBlhhOhCoEMswLKFx4RX DURC+4W8HaaoTjj8N8IJ/cOturLxeyoiX7UZYisUA61xu2uph6BIB4vn64zo5GKum4Hp BWrU7n2zmxoPY31CM0utcEe+X63w04Zfc7Mbu01FuA6xqWV22waLDvNll9wJDALYdCYN 9VyCSQ/OB2fhxoATsNjCOT3HYmt5/qfY9WgZ7cdTaLs9eW/jPJ6GTMNscVvUtI2bppd5 g64g== 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=e0+Cj9P9wmBpeAqSbTNOSZs3toMyfGY1ny8aS7GvhGo=; b=TVb+E8NPmn0UChTnIpSk02OehNe+9hD4u99ziv+d5OKDsQO+Y3xkc3nfbJJQ8KRZkW VeYV+aBgk6pPnGGkGnibuLj8tWPpRHuXzXyywvUbUWEU66IrF1wle7KzRGw+jdlcJfEs pUAbH8BWHzowcSK3i87ro7PwcSb7KF/jw0K0gG+a4XaXiHxDaxV6mrRJylYmpkTCIU73 qTMSM8a3MWsdEvag+tj1aHw06k5k+WzRHspTxVyAoTE8UqVs40Cpx/Azo92SRApygDq1 //w9JzVAj5mfmvE4XpI74HjoASjNFH864Vb2MOPmnz0qci9X81zqBiPc0s074lVDDDha JSQw== X-Gm-Message-State: AKS2vOxRzczt47awNJHG5MuJnpnBFSxRXNz+EtQ7rFQog2J1jPvmybgf r42B8PiNBUWhCrbPgl1zAzjy7Lo9l1vr X-Received: by 10.129.68.10 with SMTP id r10mr6183921ywa.85.1497430216996; Wed, 14 Jun 2017 01:50:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Wed, 14 Jun 2017 01:49:36 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 14 Jun 2017 09:49:36 +0100 Message-ID: To: Martin Thomson Cc: Richard Barnes , "acme@ietf.org" Content-Type: multipart/alternative; boundary="f403045eb768292ac40551e7a43c" Archived-At: Subject: Re: [Acme] v2 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 08:50:20 -0000 --f403045eb768292ac40551e7a43c Content-Type: text/plain; charset="UTF-8" I agree with MT here. We should just name it v1. That's what IETF change control means On Tue, Jun 13, 2017 at 5:54 PM, Martin Thomson wrote: > I don't see the distinction between what LE deploy and ACME as defined > by the IETF being any different to the distinction between whatever > any other CA currently deploy and the IETF spec. It's a thing that > exists, but I see no reason to accord the LE proprietary protocol any > special status other than by acknowledging provenance. > > This is the IETF version of ACME, and as such it needs no version > qualification. I doubt that there will be any confusion from this > being deployed alongside the proprietary LE protocol. > > On 13 June 2017 at 16:26, Richard Barnes wrote: > > (Everyone get your bike shed paint out....) > > > > In talking with a few folks around the community, I've heard people > refer to > > the IETF version of ACME as "v2", where implicitly "v1" is the initial > > version deployed by Let's Encrypt and its clients right now. > > > > How would people feel about reflecting this in the draft / RFC? I've > posted > > a PR with the changes this would entail: > > > > https://github.com/ietf-wg-acme/acme/pull/321 > > > > The only question this raises for me is what to do about v1. Given that > > Let's Encrypt has evolved their interface some since the first version, > I'm > > not sure there's one consolidated spec out there for what they currently > > have deployed. So while it would be nice to have a reference to v1 in > this > > document if we make it v2, I'm not inclined to worry about it too much. > I'm > > willing to leave it up to the LE folks if they want to submit a v1 later > for > > historical purposes. > > > > Any objections to merging the above PR? > > > > --Richard > > > > > > _______________________________________________ > > Acme mailing list > > Acme@ietf.org > > https://www.ietf.org/mailman/listinfo/acme > > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --f403045eb768292ac40551e7a43c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with MT here. We should just name it v1. That'= s what IETF change control means

On Tue, Jun 13, 2017 at 5:54 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
I don't see the distinction between what LE deploy and ACME as= defined
by the IETF being any different to the distinction between whatever
any other CA currently deploy and the IETF spec.=C2=A0 It's a thing tha= t
exists, but I see no reason to accord the LE proprietary protocol any
special status other than by acknowledging provenance.

This is the IETF version of ACME, and as such it needs no version
qualification.=C2=A0 I doubt that there will be any confusion from this
being deployed alongside the proprietary LE protocol.

On 13 June 2017 at 16:26, Richard Barnes <rlb@ipv.sx> wrote:
> (Everyone get your bike shed paint out....)
>
> In talking with a few folks around the community, I've heard peopl= e refer to
> the IETF version of ACME as "v2", where implicitly "v1&= quot; is the initial
> version deployed by Let's Encrypt and its clients right now.
>
> How would people feel about reflecting this in the draft / RFC?=C2=A0 = I've posted
> a PR with the changes this would entail:
>
> https://github.com/ietf-wg-acme/acme/pull/321=
>
> The only question this raises for me is what to do about v1.=C2=A0 Giv= en that
> Let's Encrypt has evolved their interface some since the first ver= sion, I'm
> not sure there's one consolidated spec out there for what they cur= rently
> have deployed.=C2=A0 So while it would be nice to have a reference to = v1 in this
> document if we make it v2, I'm not inclined to worry about it too = much.=C2=A0 I'm
> willing to leave it up to the LE folks if they want to submit a v1 lat= er for
> historical purposes.
>
> Any objections to merging the above PR?
>
> --Richard
>
>
> __________________= _____________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme >

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

--f403045eb768292ac40551e7a43c-- From nobody Wed Jun 14 06:24:24 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEFF12EC1A for ; Wed, 14 Jun 2017 06:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 qshQGvlzB50H for ; Wed, 14 Jun 2017 06:24:02 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 48E6412EC10 for ; Wed, 14 Jun 2017 06:24:02 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id 36so542728wry.3 for ; Wed, 14 Jun 2017 06:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Oym1y743skxl6K7tfQOmxcaSnmv3QAnA7B445DJOAO8=; b=UqeCVWnJha8LRk7vq6azfck5n/lVo2FWeFoTtnG23P0CEl0eDPzDBOIqLYqMf/kZCr ZZ6vycEfUmETYI/72GLPUYrbLNjRpJfCNXRQtAm3+uYiTgz6+hB/DpPnA3qznoxKcgqH dvALMBG6MI0usQ8Rz41OzjurCxpHpIdT/slL29gO2f48L5sV9mNhdrGN6G/HxU9IrZaA ifYfj7BbzSLe0H8vtQEnzVAmInsgUvbeurzIjyANRzxo6kG9wvtL0/cl7BY6am/gM/NM O/o9cPjYQC3vAozb2p62HX621NLOffW48UltzIfg8TOaMX/eDUod5S75ogKyYEkPfMQm wEPA== 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=Oym1y743skxl6K7tfQOmxcaSnmv3QAnA7B445DJOAO8=; b=n5bvnzRVJLOsp7jaKd25sqPdMmBF7XHhXd0trGF7s5OVIQfnMbxXfbY+ZI1ROaRjlI molwIEUW2W6vc7rO3r3TM4EZpcjeeT7YvHgcQLsZsOFfZSxLzRlOJtVWesbENyoduiOn rofY2htd38sgNqWwxQmJb41RXbpB9AaNM62lXDH3KxJoHsogvZO7peaUIQC44cZzyTaE FbemyQvHYwCZdncVrNR9ypZf4460Fwc0x8NINRsR96RZvoliSEsIi4HNkbClmfNE4nmg 02OvGc84+67Rum793MaYI2aNx5zbtw6d0j8bMipO6zeaSlXq2Nf3gIQ4PW8igpKALryb 8X3Q== X-Gm-Message-State: AKS2vOwae2Qy4DS2FsiGZRxY9gnyElCqeKhcG//b45BxpZlMcdI8Edd2 5Tib3DRjJhGoxocPzUxPS/oXhNN/8XQ3bjhChg== X-Received: by 10.28.238.70 with SMTP id m67mr50753wmh.74.1497446640452; Wed, 14 Jun 2017 06:24:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.109.16 with HTTP; Wed, 14 Jun 2017 06:23:59 -0700 (PDT) In-Reply-To: <20170613172347.GA12048@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170613172347.GA12048@LK-Perkele-V2.elisa-laajakaista.fi> From: Richard Barnes Date: Wed, 14 Jun 2017 09:23:59 -0400 Message-ID: To: Ilari Liusvaara Cc: Zach Shepherd , "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a1146b2501322f60551eb77dd" Archived-At: Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 13:24:23 -0000 --001a1146b2501322f60551eb77dd Content-Type: text/plain; charset="UTF-8" Hey Ilari, Thanks for this analysis. I agree that a tighter and clearer binding of the challenge/response pair to the validation transaction would be desireable, as would more uniformity across challenges. I would like to propose a slightly different structure, though. === The essential elements of a challenge are (1) the content of the challenge, (2) the content of the response, (3) the content of the validation query, and (4) the content of the validation response (where in 3 and 4, we mean the part that is specific to the validation, vs. .well-known or _acme-challenge). Right now, (1) and (2) are the same for all challenges, but (3) and (4) differ. http: (1) token (2) keyAuthorization (3) token (4) keyAuthorization tls: (1) token (2) keyAuthorization (3) H(token) (4) H(keyAuthorization) dns: (1) token (2) keyAuthorization (3) (nil) (4) H(keyAuthorization) I think we could meet the requirements above with the following steps: 1. Update the keyAuthorization structure to be a JSON object binding the validation to a bunch of stuff, e.g.: { "identifier": {"type": "dns", "value": "example.com"}, "method": "dns-01", "key": { ... }, "nonce: "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA" } 2. Have the client provide the serialized keyAuthorization in its response to the challenge (in ACME) and have the server verify that it decodes properly, has only the identified fields, and the fields have the proper values. 3. Derive the validation query and response values from the serialized keyAuthorization value provided in the response, using a "reveal the preimage" pattern, either: 3.a. query = H(kA), response=kA, or 3.b. query = H(H(kA)), response=H(kA) I kind of like the latter better, because it meets all the transport requirements for DNS and TLS (since the hashes are small). It also enables the server to verify that a challenge/response pair is valid without necessarily revealing to the server the details of the validation; if the server really wants to know, it can demand the raw key authorization. That would give us a uniform structure across challenges: all: (1) token (2) keyAuthorization (3) H(H(keyAuthorization)) (4) H(keyAuthorization) What would folks think of that? It's a large-ish change for this stage of the process, but it seems like the regularity it provides will help simplify analysis and make implementation easier, so I'm inclined to do it. Thanks, --Richard On Tue, Jun 13, 2017 at 1:23 PM, Ilari Liusvaara wrote: > On Tue, Jun 13, 2017 at 11:59:21AM -0400, Richard Barnes wrote: > > Hey Zach, > > > > Thanks for submitting a PR on this. I just filed a review with some > > specific comments: > > > > https://github.com/ietf-wg-acme/acme/pull/312#pullrequestreview-43769669 > > > > This change seems fine to me, especially if we make the change I propose > in > > there to digest the whole key authorization instead of just the token. I > > don't think there's a security problem here, but I also don't think > > stateless clients are tremendously valuable to the ecosystem, and it > seems > > conservative to require more knowledge on the part of the verification > host. > > > > Looking at the thread, I'm not seeing strong objections. Unless I hear > > something here before Zach updates the PR, I'll go ahead and merge once > > that's done. > > I think that if one wanted to be consistent among different validation > methods, then challenges would be based on hash of one thing, and the > responses would be (hash of) another. > > However, I do not think it is sufficient for security to take just the > random token for request, and random token + accout JWT for response. > > The problems with do not manifest in HTTP nor DNS, since HTTP and DNS > requests are also bound to the validatio name (via virtual host > and QNAME respectively) as fundamential part of request process. > > However, TLS-SNI is another matter. There is nothing binding validation > to domain name, not even if preimages are disclosed. And this in my view > causes TLS-SNI to fail to validate the domain itself, instead validating > the underlying IP address. > > Now, the lack of this binding does not manifest when the server is > dedicated and the webmaster has full control of the entiere server, > however it does manifest if the server is shared between multiple > tenants. The server has no way of determining if the challenge- > response pairs are legimate or not. > > To fix this, I think that the identifier being validated should be > included in requests (and possibly responses). > > > One scheme I considered earlier (but didn't actually send a mail about, > due to writing the mail to a wrong place): > > > Request form would be (before hashing): > > TR... > > > And response form would be (possibly before hashing): > > KA.... > > > (I included message tags and methods to follow good practice of > separating different messages, altough in this case, there is no > way to confuse the two, since number of periods is different.) > > > Now, disclosing the preimages allows verifying that the challenge- > response pair is a validation of legimate domain. > > > > > -Ilari > --001a1146b2501322f60551eb77dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Ilari,

Thanks for this a= nalysis.=C2=A0 I agree that a tighter and clearer binding of the challenge/= response pair to the validation transaction would be desireable, as would m= ore uniformity across challenges.=C2=A0 I would like to propose a slightly = different structure, though.

=3D=3D=3D
<= br>
The essential elements of a challenge are (1) the content of = the challenge, (2) the content of the response, (3) the content of the vali= dation query, and (4) the content of the validation response=C2=A0 (where i= n 3 and 4, we mean the part that is specific to the validation, vs. .well-k= nown or _acme-challenge).=C2=A0 Right now, (1) and (2) are the same for all= challenges, but (3) and (4) differ.

http: (1) tok= en (2) keyAuthorization (3) token (4) keyAuthorization
tls: (= 1) token (2) keyAuthorization (3) H(token) (4) H(keyAuthorization)
dns: (1) token (2) keyAuthorization (3) (nil) (4) H(keyAuthorization)=

I think we could meet the requirements above with= the following steps:

1. Update the keyAuthorizati= on structure to be a JSON object binding the validation to a bunch of stuff= , e.g.:

{
=C2=A0 "identifier":= {"type": "dns", "value": "example.com"},
=C2=A0 "method&quo= t;: "dns-01",
=C2=A0 "key": { ... },
=C2=A0 "nonce: "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA= "
}

2. Have the client provide the = serialized keyAuthorization in its response to the challenge (in ACME) and = have the server verify that it decodes properly, has only the identified fi= elds, and the fields have the proper values.

3. De= rive the validation query and response values from the serialized keyAuthor= ization value provided in the response, using a "reveal the preimage&q= uot; pattern, either:
3.a. query =3D H(kA), response=3DkA, or
3.b. query =3D H(H(kA)), response=3DH(kA)

I= kind of like the latter better, because it meets all the transport require= ments for DNS and TLS (since the hashes are small).=C2=A0 It also enables t= he server to verify that a challenge/response pair is valid without necessa= rily revealing to the server the details of the validation; if the server r= eally wants to know, it can demand the raw key authorization.
That would give us a uniform structure across challenges:
=

all: (1) token (2) keyAuthorization (3) H(H(keyAuthoriz= ation)) (4) H(keyAuthorization)

What would folks t= hink of that?=C2=A0 It's a large-ish change for this stage of the proce= ss, but it seems like the regularity it provides will help simplify analysi= s and make implementation easier, so I'm inclined to do it.
<= br>
Thanks,
--Richard


On Tue, Jun 13, 2017= at 1:23 PM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Tue, Jun 13= , 2017 at 11:59:21AM -0400, Richard Barnes wrote:
> Hey Zach,
>
> Thanks for submitting a PR on this.=C2=A0 I just filed a review with s= ome
> specific comments:
>
> https://github.com/ietf= -wg-acme/acme/pull/312#pullrequestreview-43769669
>
> This change seems fine to me, especially if we make the change I propo= se in
> there to digest the whole key authorization instead of just the token.= =C2=A0 I
> don't think there's a security problem here, but I also don= 9;t think
> stateless clients are tremendously valuable to the ecosystem, and it s= eems
> conservative to require more knowledge on the part of the verification= host.
>
> Looking at the thread, I'm not seeing strong objections.=C2=A0 =C2= =A0Unless I hear
> something here before Zach updates the PR, I'll go ahead and merge= once
> that's done.

I think that if one wanted to be consistent among different validati= on
methods, then challenges would be based on hash of one thing, and the
responses would be (hash of) another.

However, I do not think it is sufficient for security to take just the
random token for request, and random token + accout JWT for response.

The problems with do not manifest in HTTP nor DNS, since HTTP and DNS
requests are also bound to the validatio name (via virtual host
and QNAME respectively) as fundamential part of request process.

However, TLS-SNI is another matter. There is nothing binding validation
to domain name, not even if preimages are disclosed. And this in my view causes TLS-SNI to fail to validate the domain itself, instead validating the underlying IP address.

Now, the lack of this binding does not manifest when the server is
dedicated and the webmaster has full control of the entiere server,
however it does manifest if the server is shared between multiple
tenants. The server has no way of determining if the challenge-
response pairs are legimate or not.

To fix this, I think that the identifier being validated should be
included in requests (and possibly responses).


One scheme I considered earlier (but didn't actually send a mail about,=
due to writing the mail to a wrong place):


Request form would be (before hashing):

TR.<random>.<method>.<identifierbase64url>


And response form would be (possibly before hashing):

KA.<random>.<method>.<identifierbase64url>.<= accountjwt>


(I included message tags and methods to follow good practice of
separating different messages, altough in this case, there is no
way to confuse the two, since number of periods is different.)


Now, disclosing the preimages allows verifying that the challenge-
response pair is a validation of legimate domain.




-Ilari

--001a1146b2501322f60551eb77dd-- From nobody Wed Jun 14 08:22:19 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D4012EC21 for ; Wed, 14 Jun 2017 08:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 k8dKWA0DlOrV for ; Wed, 14 Jun 2017 08:22:13 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id A178912EB69 for ; Wed, 14 Jun 2017 08:22:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 8122C2275D; Wed, 14 Jun 2017 18:22:10 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id C0-Itd0BhxsM; Wed, 14 Jun 2017 18:22:10 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 1EC0E2313; Wed, 14 Jun 2017 18:22:10 +0300 (EEST) Date: Wed, 14 Jun 2017 18:22:04 +0300 From: Ilari Liusvaara To: Richard Barnes Cc: Zach Shepherd , "acme@ietf.org" Message-ID: <20170614152204.GA17525@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170613172347.GA12048@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 15:22:15 -0000 On Wed, Jun 14, 2017 at 09:23:59AM -0400, Richard Barnes wrote: > Hey Ilari, > > Thanks for this analysis. I agree that a tighter and clearer binding of > the challenge/response pair to the validation transaction would be > desireable, as would more uniformity across challenges. I would like to > propose a slightly different structure, though. > > === > > The essential elements of a challenge are (1) the content of the challenge, > (2) the content of the response, (3) the content of the validation query, > and (4) the content of the validation response (where in 3 and 4, we mean > the part that is specific to the validation, vs. .well-known or > _acme-challenge). Right now, (1) and (2) are the same for all challenges, > but (3) and (4) differ. > > http: (1) token (2) keyAuthorization (3) token (4) keyAuthorization > tls: (1) token (2) keyAuthorization (3) H(token) (4) H(keyAuthorization) > dns: (1) token (2) keyAuthorization (3) (nil) (4) H(keyAuthorization) > > I think we could meet the requirements above with the following steps: > > 1. Update the keyAuthorization structure to be a JSON object binding the > validation to a bunch of stuff, e.g.: > > { > "identifier": {"type": "dns", "value": "example.com"}, > "method": "dns-01", > "key": { ... }, > "nonce: "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA" > } > > 2. Have the client provide the serialized keyAuthorization in its response > to the challenge (in ACME) and have the server verify that it decodes > properly, has only the identified fields, and the fields have the proper > values. This has the raw key, which means one has to compare raw keys. IIRC, that is somewhat frowned on. > 3. Derive the validation query and response values from the serialized > keyAuthorization value provided in the response, using a "reveal the > preimage" pattern, either: > 3.a. query = H(kA), response=kA, or > 3.b. query = H(H(kA)), response=H(kA) > > I kind of like the latter better, because it meets all the transport > requirements for DNS and TLS (since the hashes are small). It also enables > the server to verify that a challenge/response pair is valid without > necessarily revealing to the server the details of the validation; if the > server really wants to know, it can demand the raw key authorization. I expect the most common check is check for identifier. But being able to calculate where the response goes from the key authorization (e.g. 'http://somehost3.example.net/.well-known/acme-challenge/yeag2...', '_acme-validation.somehost3.example.net' or 'gesc3<...>.token.acme.invalid') is sure nice to have. > That would give us a uniform structure across challenges: > > all: (1) token (2) keyAuthorization (3) H(H(keyAuthorization)) (4) > H(keyAuthorization) I don't think there is any extra space in DNS for the query. IIRC, there is 255 byte total length restriction for DNS QNAMEs in addition to the 63 byte per-component limit. > What would folks think of that? It's a large-ish change for this stage of > the process, but it seems like the regularity it provides will help > simplify analysis and make implementation easier, so I'm inclined to do it. -Ilari From nobody Wed Jun 14 15:39:27 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B61A1293E8 for ; Wed, 14 Jun 2017 15:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 iFas4zRdFtve for ; Wed, 14 Jun 2017 15:39:20 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::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 7F4E212947D for ; Wed, 14 Jun 2017 15:39:20 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id 77so20017677wrb.1 for ; Wed, 14 Jun 2017 15:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zy/J6jtrfaMFUJj8cHiSaj75tXP0EsqIchF9va3WZ30=; b=RtwEvrFImrEq7o9j7ktKGG76Ylu52NcLwoiIWY+j+fOHyhnLMsc2T1ZPKO3Bm4w6IS KrxlajVA8jSDnTjKM44dEw+AELVpD4cQiC55d3U+fZhQi2QytOzEvv1f7uR6U80JjUoN RvMMM0yInH++YR/gMK2ArK4etgkbA7Prv0rUyRmBTYeudfgHV+KLycHW7blxxP15xTIc nixLCQe+mnfEwObFQ0VRP2lZY7j21DXA/0ItatSawS2/NasxEsGikQ+1JdgNW8iE8deO SnSarW9Z7x4RqTuvGIZo5dtmUiD70VK+TDgvxVTPzlldJzuFYddjI3bd7vZYSxs0Aeww fXiw== 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=zy/J6jtrfaMFUJj8cHiSaj75tXP0EsqIchF9va3WZ30=; b=I6GqDDIcmAvePbxn5tCdF7DTA3RPMa7JfGSJnYgEkzRydPrMirjgxDWDmIQTRSzsBw EYOZJt5YwXGTQZXgVAaTDL/p/LQkgN6Pj/VmKOk4zfElO7lXuXYybqUQtYJEn/KpDvc5 xJgeGS4UUD4T0r8OOSDGQqvxq2crVjGT4Fi29pAqnhPU8Xl2wVYP3A+iJ+c6mG5MZyqH HrYdL8vF4tzVtmzBKoz3cG2rUd076gx8mEabLuOVjS4Lz83jhNR7MH1fSCeljZbSR+38 wK9IrPPToslxmVjdsyzWzeUpShuWZ3cY7GPORcLaJ7lfTSvkKpgCL57RMaZ1JrBz84li nEjg== X-Gm-Message-State: AKS2vOxmXWQg03nMaaiTns4yCo9ee9adOE2QMHuz7usMiFbf8+Ri7rac u0B52CU5CnwETfh5J29WEO+gYaJ6StBE X-Received: by 10.28.146.12 with SMTP id u12mr1460386wmd.15.1497479958895; Wed, 14 Jun 2017 15:39:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.109.16 with HTTP; Wed, 14 Jun 2017 15:39:18 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Wed, 14 Jun 2017 18:39:18 -0400 Message-ID: To: Eric Rescorla Cc: Martin Thomson , "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a114434a00233db0551f3394f" Archived-At: Subject: Re: [Acme] v2 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 22:39:25 -0000 --001a114434a00233db0551f3394f Content-Type: text/plain; charset="UTF-8" For some context: https://letsencrypt.org/2017/06/14/acme-v2-api.html To be clear about my opinion here: I'm not super enthusiastic about v2; I think we can muddle through the transition just fine. But if people feel strongly that it would help to have a clear version (there's not even a "v1" notation right now), that would be OK with me. On Wed, Jun 14, 2017 at 4:49 AM, Eric Rescorla wrote: > I agree with MT here. We should just name it v1. That's what IETF change > control means > > On Tue, Jun 13, 2017 at 5:54 PM, Martin Thomson > wrote: > >> I don't see the distinction between what LE deploy and ACME as defined >> by the IETF being any different to the distinction between whatever >> any other CA currently deploy and the IETF spec. It's a thing that >> exists, but I see no reason to accord the LE proprietary protocol any >> special status other than by acknowledging provenance. >> >> This is the IETF version of ACME, and as such it needs no version >> qualification. I doubt that there will be any confusion from this >> being deployed alongside the proprietary LE protocol. >> >> On 13 June 2017 at 16:26, Richard Barnes wrote: >> > (Everyone get your bike shed paint out....) >> > >> > In talking with a few folks around the community, I've heard people >> refer to >> > the IETF version of ACME as "v2", where implicitly "v1" is the initial >> > version deployed by Let's Encrypt and its clients right now. >> > >> > How would people feel about reflecting this in the draft / RFC? I've >> posted >> > a PR with the changes this would entail: >> > >> > https://github.com/ietf-wg-acme/acme/pull/321 >> > >> > The only question this raises for me is what to do about v1. Given that >> > Let's Encrypt has evolved their interface some since the first version, >> I'm >> > not sure there's one consolidated spec out there for what they currently >> > have deployed. So while it would be nice to have a reference to v1 in >> this >> > document if we make it v2, I'm not inclined to worry about it too >> much. I'm >> > willing to leave it up to the LE folks if they want to submit a v1 >> later for >> > historical purposes. >> > >> > Any objections to merging the above PR? >> > >> > --Richard >> > >> > >> > _______________________________________________ >> > Acme mailing list >> > Acme@ietf.org >> > https://www.ietf.org/mailman/listinfo/acme >> > >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> > > --001a114434a00233db0551f3394f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

To be clear about my opinion here: I'= ;m not super enthusiastic about v2; I think we can muddle through the trans= ition just fine.=C2=A0 But if people feel strongly that it would help to ha= ve a clear version (there's not even a "v1" notation right no= w), that would be OK with me.
On Wed, Jun 14, 2017 at 4:49 AM, Eric Rescorla = <ekr= @rtfm.com> wrote:
I agree with MT here. We should just name it v1. That's what I= ETF change control means

On Tue, Jun 13, 2017 a= t 5:54 PM, Martin Thomson <martin.thomson@gmail.com> = wrote:
I don't see the distinction be= tween what LE deploy and ACME as defined
by the IETF being any different to the distinction between whatever
any other CA currently deploy and the IETF spec.=C2=A0 It's a thing tha= t
exists, but I see no reason to accord the LE proprietary protocol any
special status other than by acknowledging provenance.

This is the IETF version of ACME, and as such it needs no version
qualification.=C2=A0 I doubt that there will be any confusion from this
being deployed alongside the proprietary LE protocol.

On 13 June 2017 at 16:26, Richard Barnes <rlb@ipv.sx> wrote:
> (Everyone get your bike shed paint out....)
>
> In talking with a few folks around the community, I've heard peopl= e refer to
> the IETF version of ACME as "v2", where implicitly "v1&= quot; is the initial
> version deployed by Let's Encrypt and its clients right now.
>
> How would people feel about reflecting this in the draft / RFC?=C2=A0 = I've posted
> a PR with the changes this would entail:
>
> https://github.com/ietf-wg-acme/acme/pull/321=
>
> The only question this raises for me is what to do about v1.=C2=A0 Giv= en that
> Let's Encrypt has evolved their interface some since the first ver= sion, I'm
> not sure there's one consolidated spec out there for what they cur= rently
> have deployed.=C2=A0 So while it would be nice to have a reference to = v1 in this
> document if we make it v2, I'm not inclined to worry about it too = much.=C2=A0 I'm
> willing to leave it up to the LE folks if they want to submit a v1 lat= er for
> historical purposes.
>
> Any objections to merging the above PR?
>
> --Richard
>
>
> ______________________________________________= _
> Acme mailing list
> Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


--001a114434a00233db0551f3394f-- From nobody Fri Jun 16 05:19:45 2017 Return-Path: X-Original-To: acme@ietf.org Delivered-To: acme@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7DA129BAF; Fri, 16 Jun 2017 05:19:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: acme@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149761557766.24143.14359431560325982499@ietfa.amsl.com> Date: Fri, 16 Jun 2017 05:19:37 -0700 Archived-At: Subject: [Acme] I-D Action: draft-ietf-acme-star-00.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 12:19:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Automated Certificate Management Environment of the IETF. Title : Use of Short-Term, Automatically-Renewed (STAR) Certificates to Delegate Authority over Web Sites Authors : Yaron Sheffer Diego Lopez Oscar Gonzalez de Dios Antonio Agustin Pastor Perales Thomas Fossati Filename : draft-ietf-acme-star-00.txt Pages : 13 Date : 2017-06-16 Abstract: This memo proposes an ACME extension to enable the issuance of short- term and automatically renewed certificates. This allows a domain name owner to delegate the use of certificates to another party, while retaining the capability to cancel this delegation at any time with no need to rely on certificate revocation mechanisms. [RFC Editor: please remove before publication] While the draft is being developed, the editor's version can be found at https://github.com/yaronf/I-D/tree/master/STAR. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-acme-star/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-acme-star-00 https://datatracker.ietf.org/doc/html/draft-ietf-acme-star-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 16 05:34:55 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0FF129BB6 for ; Fri, 16 Jun 2017 05:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vy1Hvxus1dNv for ; Fri, 16 Jun 2017 05:34:52 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23CD5129BA5 for ; Fri, 16 Jun 2017 05:34:52 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5GCWDwZ014829; Fri, 16 Jun 2017 13:34:49 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=SUKt832wIFPbwCAPbm+3md97fwQ9tUEqhfCJ6AQpCKU=; b=RmTDsoT5pS+ThShPNad9z4Sb3Wz4WUMkQtz8BIn9kuIqw/d2SSltkAclASdTfheSntLt uzZEpRx2bSd8z8a4Sev5YHjFaUMjg9/ba28rbFu5eHzAUkuOcfvs15UcLboVm5ccOilN xM1SwL/RpUnDAGkf0/o3fVidQYPMQXvrjzEbch64H/6QRVu3BlLRB6eeDmjyMqioDTsU +IZ44qRiih5zzoVrcbFf9RGRNEYBWT3nZJxZro5mKbML3cx72qz1K5cs4KH0Tu5WyOoW o+mcLISRAEmSeZANODCvLuODn6oxgHdmkw77fhnh0+zInuSVxEJyYnbx8pYgW02DReJl +w== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050093.ppops.net-00190b01. with ESMTP id 2b3v05f03h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Jun 2017 13:34:49 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5GCUh2n024242; Fri, 16 Jun 2017 08:34:48 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2b0c3v84ch-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 16 Jun 2017 08:34:48 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 16 Jun 2017 08:34:47 -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.1263.000; Fri, 16 Jun 2017 08:34:47 -0400 From: "Salz, Rich" To: "Mary Barnes (mary.ietf.barnes@gmail.com)" , Roland Bracewell Shoemaker , "jon.peterson@neustar.biz" , Alexey Melnikov CC: "acme@ietf.org" Thread-Topic: Please submit your I-D as WG documents Thread-Index: AdLmnNPzPGNvpk/nQdODDh4HYj/s+Q== Date: Fri, 16 Jun 2017 12:34:47 +0000 Message-ID: <32a791cfd2dc4191b1e8904739556408@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.32.79] Content-Type: multipart/alternative; boundary="_000_32a791cfd2dc4191b1e8904739556408usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-16_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706160206 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-16_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706160206 Archived-At: Subject: [Acme] Please submit your I-D as WG documents X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 12:34:54 -0000 --_000_32a791cfd2dc4191b1e8904739556408usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Authors, Please submit your drafts as WG documents for adoption, thank you! -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz --_000_32a791cfd2dc4191b1e8904739556408usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Authors,

 

Please submit your drafts as WG documents for adopti= on, thank you!

 

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

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

 

--_000_32a791cfd2dc4191b1e8904739556408usma1exdag1mb1msgcorpak_-- From nobody Fri Jun 16 05:40:14 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B441294DF for ; Fri, 16 Jun 2017 05:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXkJBSICA6sO for ; Fri, 16 Jun 2017 05:40:11 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18DD81270AC for ; Fri, 16 Jun 2017 05:40:11 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5GCavxx026302; Fri, 16 Jun 2017 13:40:07 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=R1Du20fD7kKblR45v3z0cIi3ArhqQfQiF2dI0hEN+is=; b=Q3XCoRJppXdhFQeWIR8kPhXcSNKh0ZSjKjGeOahDFtgjCjyhzIleCKhJL7Wp4ESkKg/8 i2WRLKkWgT3Hx4aGoDgfyqlObjfXAMw4ypik25nVcbq9aH3mIhzuJnuusl2wimssrp1e rccl0KQm6iUoOApS2KYumjiNhGcdLRpIOPlYUj6uqsejXVrpc2uakIr+yIcHx2LdvvDF Iq8Zxkvo14x+hS76R5xgKZBRQmu8KPyk0i3beAXTV2bX5dl70+ORzCUVhZQcmcN4je1+ Ab5t7kQqEpF95uL+IGRPxRyrbllntBDRTJ7katPPlJSjBSEVVjboni/Rw6Q7EL8/9Z1G vw== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2b4911abfc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Jun 2017 13:40:07 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5GCa1JG027968; Fri, 16 Jun 2017 08:40:06 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2b0c3uwmj5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 16 Jun 2017 08:40:06 -0400 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.1263.5; Fri, 16 Jun 2017 08:40:05 -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.1263.000; Fri, 16 Jun 2017 08:40:05 -0400 From: "Salz, Rich" To: Hugo Landau CC: "acme@ietf.org" Thread-Topic: Before entering WGLC ... Thread-Index: AdLmnPm9U5O+8VQ1RlutqFMR3rfl7g== Date: Fri, 16 Jun 2017 12:40:05 +0000 Message-ID: <5997299eae9a4ca7bbd8f3798c5db6cd@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.32.79] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-16_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706160207 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-16_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706160207 Archived-At: Subject: [Acme] Before entering WGLC ... X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 12:40:13 -0000 Hugo, the CAA document is in WGLC. Russ raised the following issue on some= text in section 2: =A0 =A0. . . =A0A CA MUST only consider a property with an "account-uri" =A0 =A0parameter to authorize issuance where the URI specified is an URI =A0 =A0that the CA recognises as identifying the account making a =A0 =A0certificate issuance request. > This is not a [crisp] MUST statement. =A0I think it is trying to say two = things when=A0the "account-uri" is present:=A0 > (1) =A0the CA MUST NOT issue a certificate containing the domain name tha= t contains the CAA Resource Record if it does not recognize the account ref= erenced by the URI. > (2) =A0the CA MUST use the account referenced by the URI in the authoriza= tion process for a certificate request for the domain containing the CAA Re= source Record. > If this is correct, please separate these two requirements. If it is not= correct, please explain the text. Can you post an update next week? If not, would it help to add another aut= hor to do so? I would like to move this forward to the IESG soon. Please = respond by early next week. Thank you. -- =20 Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz From nobody Fri Jun 16 09:52:35 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1CD1295A0 for ; Fri, 16 Jun 2017 09:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 pFoam-yjXc-8 for ; Fri, 16 Jun 2017 09:52:32 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 C1201129463 for ; Fri, 16 Jun 2017 09:52:31 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id 36so41340980wry.3 for ; Fri, 16 Jun 2017 09:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=kzakWOiETOWpmxQmjqpHVCeON6eJmkI8RAqPJL9puNA=; b=dfa7hQvYyy4J2I9w001phREgi1br8n6hmEL8IUBhq0j+2QkknGloW+IkOwCRqg/nPB VO8RkOpZmgasc5abugv/Q5JWEKpu2CQYeIxXn6jVa8Ke0zm28cYq7q0rgRqFNZF6vmlJ hSzP5cQXNhO9Hzl1K/EZbk7hBhhsxuDBElBVIs9nA75+UMNRAeqikfT0Iy+Q2O9bb2Nk eo1usPF59ZKw/9zfHNryqMm5zjgQP4dtIDanvOBNZr/oGXRcJUNL485/YZsjolREDlUx bSM1jYeRi9PtMm6iYHBjQ8udTqyYXS8GCAOkvSc6RJMBTtpmd1kKyhzxYoy2lus9ieI0 v5hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=kzakWOiETOWpmxQmjqpHVCeON6eJmkI8RAqPJL9puNA=; b=Y1iN4/wqEs7LFuzNVTT71+Bv9cbCCTMuyb8hCb7ucIfQgrSvqkh+0ZT1JjtDvayRUv b0lEqgUPGvKc4E5+beXYl9MfO0wtIN+m6Z2okT0LJHLoFBofnxZx78Y4PpEalce9GP+N OlWr8LPo8DbaIukD30dbo2OtY1Bj/WYawmvhHlg2wj3PO0S4HD7Vz1PhStdInAFHunnp DJZRSTFWCUWQb5KcQ5SNCC7dcw1NwZ7+/A6Jh6+mluNnT3s33jHN2Dmocx73UqD0WmZH j46Oig3ikLDvXZdoCUROzzms9MtT2HJO4zIAFCnE5ckrwYEp5RORle5Coa31WRbQGdaF NAnw== X-Gm-Message-State: AKS2vOxc/Jtukqhi5slhUcYyxhCt7f5rJLHeQLT36bPeE982MWASM6R2 /SHFkZNzfD9qm1CjNjc= X-Received: by 10.223.169.203 with SMTP id b69mr8797441wrd.1.1497631950088; Fri, 16 Jun 2017 09:52:30 -0700 (PDT) Received: from [10.0.0.9] (bzq-109-66-161-210.red.bezeqint.net. [109.66.161.210]) by smtp.gmail.com with ESMTPSA id 137sm4003466wmm.29.2017.06.16.09.52.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Jun 2017 09:52:29 -0700 (PDT) To: "acme@ietf.org" From: Yaron Sheffer Message-ID: <910852fe-2170-b5c5-5bb5-65c5c6534dc5@gmail.com> Date: Fri, 16 Jun 2017 19:52:28 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Acme] Short term certificate drafts X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 16:52:34 -0000 Hi, At the request of the WG chairs we split the document into two. One is now a WG document: draft-ietf-acme-star-00 (https://datatracker.ietf.org/doc/draft-ietf-acme-star/). This is the ACME extension that allows the ACME client to request recurrent, short term certificates. The second document is still an individual submission, draft-sheffer-acme-star-request-01 (https://datatracker.ietf.org/doc/draft-sheffer-acme-star-request/). This is a REST API where the consumer of delegated certificates (e.g. a CDN) can request from the Domain Name Owner to initiate the ACME request. Comments are as always welcome. For simple, editorial comments you might want to issue pull requests at https://github.com/yaronf/I-D/tree/master/STAR. Thanks, Yaron From nobody Sat Jun 17 06:47:29 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFDA12955D for ; Sat, 17 Jun 2017 06:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 rwScbPMJgtuE for ; Sat, 17 Jun 2017 06:47:24 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 6D9931200F1 for ; Sat, 17 Jun 2017 06:47:24 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id l89so34377932pfi.2 for ; Sat, 17 Jun 2017 06:47:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WpJMXEe4cgH5THyvfUmoXQWXxkWlh5spvYm0W8I8zB0=; b=J3yJPW0JSetMKuhLQOBZQzzJa+Bpju2AL+Xtt8b33D5fQEeIecOudO8wq/dT5HU7hW WzM+7HkW3/oHXa2o0wuHv3bYeUMO1l4HZphCBRsi66DBgSC5bnEzgbJcWXKjEYEl8ABH NAClUheCmQg5OgH9smjlYrzBfRbDhDAB7nDNS28NZmqSce3nJnKw2a/nmgNS7dAPG2zS 9IWM0CuhMRf3Yq4Z0CGqQ8fvYEWR9M+3ArwUCdB58GYURy/5wLXjPzblyLCj7XNBn/st dHqAj7BfTb1oty/Vzo/oqXYvvUdSZh5cIpuUqNasRVpKXlwODDCfkJGyrroPOa7Ijpy2 SKQg== 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=WpJMXEe4cgH5THyvfUmoXQWXxkWlh5spvYm0W8I8zB0=; b=CoRiD0oEzSCoDD/ibJW/HfRIlFuV2WmW+1CP8c0T+2ajlc3siQCKlXe1pIHBUVdDbI efywCfXTgwUjXPCcUDCbxhWUE2WHgh0JQevqocOosY4QD6vqQe5wMOTa3DynZMI+jJo/ vtY8F+z65oaytMpVF1Azefg7VN5/sabEDNyFy964O67Gpx8NC+k+uMjk8FDh375TKJG5 uyG9wn6QRwlP6FcJR97VHgdO3FG6mbyHEimthxpik1fRgfrrCxFgyi1g8yIN4u1LtU0q oEwpuMz58lLATTLUJYGHsNq97MCPTQMAGS9A7PmJEygA1udS6Gf4vn3LxSxwZtuoTEX/ 6EeQ== X-Gm-Message-State: AKS2vOxUxCLrD/8CQsQcamhi6AGPC/4aOk0tD/usIhAVyl/CuiTyIrvo AOvJeZ6E85GsRDXRhbutW3sv4/MO7A== X-Received: by 10.98.158.138 with SMTP id f10mr16619715pfk.177.1497707244025; Sat, 17 Jun 2017 06:47:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.168.8 with HTTP; Sat, 17 Jun 2017 06:47:23 -0700 (PDT) Received: by 10.100.168.8 with HTTP; Sat, 17 Jun 2017 06:47:23 -0700 (PDT) In-Reply-To: <20170614152204.GA17525@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170613172347.GA12048@LK-Perkele-V2.elisa-laajakaista.fi> <20170614152204.GA17525@LK-Perkele-V2.elisa-laajakaista.fi> From: Logan Widick Date: Sat, 17 Jun 2017 08:47:23 -0500 Message-ID: To: Ilari Liusvaara Cc: ACME WG , Zach Shepherd , Richard Barnes Content-Type: multipart/alternative; boundary="94eb2c04fd8a41fc820552282479" Archived-At: Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 13:47:27 -0000 --94eb2c04fd8a41fc820552282479 Content-Type: text/plain; charset="UTF-8" Would it be possible to add a section for how to follow this pattern in the presence of space constraints? One possible way would be to divide H(H(kA)) and H(kA) into N pieces as needed to get through the system. Each request would include the "piece number" in some way so that the system can work even in the (probably rare) event that pieces of either H(H(kA)) or H(kA) are identical. The ACME server would make N requests (one for each of the N pieces). If N=1, the piece number would be omitted and only 1 request would be made. In the event of failure, the problem document could indicate the failing pieces in an array. That way, the same pattern works regardless of space constraints. As for key comparison, here are some ideas: 1. Put the key thumbprint (produced using the same hash function H specified in the challenge) in the revised key authorization structure in lieu of the key. Include the key ID as another field in the key authorization structure. 2. Require that only a given subset of JWK fields appears (like the fields required for thumbprints). Include the key ID as another field in the key authorization structure. Sincerely, Logan Widick On Jun 14, 2017 10:22, "Ilari Liusvaara" wrote: On Wed, Jun 14, 2017 at 09:23:59AM -0400, Richard Barnes wrote: > Hey Ilari, > > Thanks for this analysis. I agree that a tighter and clearer binding of > the challenge/response pair to the validation transaction would be > desireable, as would more uniformity across challenges. I would like to > propose a slightly different structure, though. > > === > > The essential elements of a challenge are (1) the content of the challenge, > (2) the content of the response, (3) the content of the validation query, > and (4) the content of the validation response (where in 3 and 4, we mean > the part that is specific to the validation, vs. .well-known or > _acme-challenge). Right now, (1) and (2) are the same for all challenges, > but (3) and (4) differ. > > http: (1) token (2) keyAuthorization (3) token (4) keyAuthorization > tls: (1) token (2) keyAuthorization (3) H(token) (4) H(keyAuthorization) > dns: (1) token (2) keyAuthorization (3) (nil) (4) H(keyAuthorization) > > I think we could meet the requirements above with the following steps: > > 1. Update the keyAuthorization structure to be a JSON object binding the > validation to a bunch of stuff, e.g.: > > { > "identifier": {"type": "dns", "value": "example.com"}, > "method": "dns-01", > "key": { ... }, > "nonce: "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA" > } > > 2. Have the client provide the serialized keyAuthorization in its response > to the challenge (in ACME) and have the server verify that it decodes > properly, has only the identified fields, and the fields have the proper > values. This has the raw key, which means one has to compare raw keys. IIRC, that is somewhat frowned on. > 3. Derive the validation query and response values from the serialized > keyAuthorization value provided in the response, using a "reveal the > preimage" pattern, either: > 3.a. query = H(kA), response=kA, or > 3.b. query = H(H(kA)), response=H(kA) > > I kind of like the latter better, because it meets all the transport > requirements for DNS and TLS (since the hashes are small). It also enables > the server to verify that a challenge/response pair is valid without > necessarily revealing to the server the details of the validation; if the > server really wants to know, it can demand the raw key authorization. I expect the most common check is check for identifier. But being able to calculate where the response goes from the key authorization (e.g. 'http://somehost3.example.net/.well-known/acme-challenge/yeag2...', '_acme-validation.somehost3.example.net' or 'gesc3<...>.token.acme.invalid') is sure nice to have. > That would give us a uniform structure across challenges: > > all: (1) token (2) keyAuthorization (3) H(H(keyAuthorization)) (4) > H(keyAuthorization) I don't think there is any extra space in DNS for the query. IIRC, there is 255 byte total length restriction for DNS QNAMEs in addition to the 63 byte per-component limit. > What would folks think of that? It's a large-ish change for this stage of > the process, but it seems like the regularity it provides will help > simplify analysis and make implementation easier, so I'm inclined to do it. -Ilari _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme --94eb2c04fd8a41fc820552282479 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Would it be possible to add a section for how to fol= low this pattern in the presence of space constraints?=C2=A0

One possible way would be to divide H= (H(kA)) and H(kA) into N pieces as needed to get through the system. Each r= equest would include the "piece number" in some way so that the s= ystem can work even in the (probably rare) event that pieces of either H(H(= kA)) or H(kA) are identical. The ACME server would make N requests (one for= each of the N pieces). If N=3D1, the piece number would be omitted and onl= y 1 request would be made. In the event of failure, the problem document co= uld indicate the failing pieces in an array.=C2=A0
<= br>
That way, the same pattern works regardless of s= pace constraints.=C2=A0

= As for key comparison, here are some ideas:
1. Put t= he key thumbprint (produced using the same hash function H specified in the= challenge) in the revised key authorization structure in lieu of the key.= =C2=A0Include the key ID as another = field in the key authorization structure.=C2=A0
2. Require that only a given subset of JWK fields appears (like the fiel= ds required for thumbprints).=C2=A0I= nclude the key ID as another field in the key authorization structure.

Sincerely,
<= div dir=3D"auto">
Logan Widick

On Jun = 14, 2017 10:22, "Ilari Liusvaara" <ilariliusvaara@welho.com> wrote:
On Wed, Jun 14, 2= 017 at 09:23:59AM -0400, Richard Barnes wrote:
> Hey Ilari,
>
> Thanks for this analysis.=C2=A0 I agree that a tighter and clearer bin= ding of
> the challenge/response pair to the validation transaction would be
> desireable, as would more uniformity across challenges.=C2=A0 I would = like to
> propose a slightly different structure, though.
>
> =3D=3D=3D
>
> The essential elements of a challenge are (1) the content of the chall= enge,
> (2) the content of the response, (3) the content of the validation que= ry,
> and (4) the content of the validation response=C2=A0 (where in 3 and 4= , we mean
> the part that is specific to the validation, vs. .well-known or
> _acme-challenge).=C2=A0 Right now, (1) and (2) are the same for all ch= allenges,
> but (3) and (4) differ.
>
> http: (1) token (2) keyAuthorization (3) token (4) keyAuthorization > tls: (1) token (2) keyAuthorization (3) H(token) (4) H(keyAuthorizatio= n)
> dns: (1) token (2) keyAuthorization (3) (nil) (4) H(keyAuthorization)<= br> >
> I think we could meet the requirements above with the following steps:=
>
> 1. Update the keyAuthorization structure to be a JSON object binding t= he
> validation to a bunch of stuff, e.g.:
>
> {
>=C2=A0 =C2=A0"identifier": {"type": "dns"= , "value": "example.com"},
>=C2=A0 =C2=A0"method": "dns-01",
>=C2=A0 =C2=A0"key": { ... },
>=C2=A0 =C2=A0"nonce: "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA"
> }
>
> 2. Have the client provide the serialized keyAuthorization in its resp= onse
> to the challenge (in ACME) and have the server verify that it decodes<= br> > properly, has only the identified fields, and the fields have the prop= er
> values.

This has the raw key, which means one has to compare raw keys. IIRC,<= br> that is somewhat frowned on.

> 3. Derive the validation query and response values from the serialized=
> keyAuthorization value provided in the response, using a "reveal = the
> preimage" pattern, either:
> 3.a. query =3D H(kA), response=3DkA, or
> 3.b. query =3D H(H(kA)), response=3DH(kA)
>
> I kind of like the latter better, because it meets all the transport > requirements for DNS and TLS (since the hashes are small).=C2=A0 It al= so enables
> the server to verify that a challenge/response pair is valid without > necessarily revealing to the server the details of the validation; if = the
> server really wants to know, it can demand the raw key authorization.<= br>
I expect the most common check is check for identifier.

But being able to calculate where the response goes from the key
authorization (e.g.
'http://somehost3.example.net/.well-known/acme-challenge/yeag2...',
'_acme-validation.somehost3.example.net'= ; or
'gesc3<...>.token.acme.invalid') is sure nice to have.

> That would give us a uniform structure across challenges:
>
> all: (1) token (2) keyAuthorization (3) H(H(keyAuthorization)) (4)
> H(keyAuthorization)

I don't think there is any extra space in DNS for the query. IIRC= ,
there is 255 byte total length restriction for DNS QNAMEs in addition
to the 63 byte per-component limit.

> What would folks think of that?=C2=A0 It's a large-ish change for = this stage of
> the process, but it seems like the regularity it provides will help > simplify analysis and make implementation easier, so I'm inclined = to do it.


-Ilari

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

--94eb2c04fd8a41fc820552282479-- From nobody Sat Jun 17 07:56:00 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7DA128CDC for ; Sat, 17 Jun 2017 07:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 m9ZSVAgwSnoi for ; Sat, 17 Jun 2017 07:55:56 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD301294D4 for ; Sat, 17 Jun 2017 07:55:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 43AA3635DF; Sat, 17 Jun 2017 17:55:52 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id N2jVIjxwQkrY; Sat, 17 Jun 2017 17:55:51 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id B6D8521C; Sat, 17 Jun 2017 17:55:47 +0300 (EEST) Date: Sat, 17 Jun 2017 17:55:42 +0300 From: Ilari Liusvaara To: Logan Widick Cc: ACME WG , Zach Shepherd , Richard Barnes Message-ID: <20170617145541.GA31569@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170613172347.GA12048@LK-Perkele-V2.elisa-laajakaista.fi> <20170614152204.GA17525@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 14:55:59 -0000 On Sat, Jun 17, 2017 at 08:47:23AM -0500, Logan Widick wrote: > Would it be possible to add a section for how to follow this pattern in the > presence of space constraints? > > One possible way would be to divide H(H(kA)) and H(kA) into N pieces as > needed to get through the system. Each request would include the "piece > number" in some way so that the system can work even in the (probably rare) > event that pieces of either H(H(kA)) or H(kA) are identical. The ACME > server would make N requests (one for each of the N pieces). If N=1, the > piece number would be omitted and only 1 request would be made. In the > event of failure, the problem document could indicate the failing pieces in > an array. The even you call "probably rare" is in fact extremely unlikely. Even under deliberate manipulation trying to make it happen. In fact, if |kA| != |H(x)|, finding any such kA breaks the hash function outright. There are two places which have space constraints: - DNS QNAME: Eating challenge space in addition to what already needs to be there is pretty harsh. Additionally, adding challenge there would break delegated setups. - TLS certificate SAN names: The DNS 63 byte limit for name component may be relevant. Can be worked around by inserting a period in the middle of the challenge / response. The DNS name limit is not relevant: The postfixes are fixed, limiting the name to 85 bytes or so. The primary reason for having challenge is for the target to find the response(s) to return. In case of HTTP or TLS-SNI, returning multiple responses at once is highly problematic (demultiplexing requests problem). Not so with DNS: It can easily return multiple responses at once (up to around 18 without fallback, around 1000 with fallback to TCP). And the reason for having the challenge and response be (statistically) different is prevent careless servers from just copying the challlenge to response and passing validation. TLS-SNI-01 has that problem (HTTP-01 does not, due to the account thumbprint being added). > That way, the same pattern works regardless of space constraints. > > As for key comparison, here are some ideas: > 1. Put the key thumbprint (produced using the same hash function H > specified in the challenge) in the revised key authorization structure in > lieu of the key. Include the key ID as another field in the key > authorization structure. > > 2. Require that only a given subset of JWK fields appears (like the fields > required for thumbprints). Include the key ID as another field in the key > authorization structure. Doesn't that put the same information in two places (which is legendary source of all sorts of problems)? Computing thumbprints and comparing those does not detect keys that are different as the same, but can detect the same keys as different (due to noncanonical representations. However, those are either illegal JWKs, or just crazy, like RSA key with e > n). -Ilari From nobody Sat Jun 17 08:01:32 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C94E126B7E for ; Sat, 17 Jun 2017 08:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=devever.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLqlBDgFynbS for ; Sat, 17 Jun 2017 08:01:28 -0700 (PDT) Received: from umbriel.devever.net (umbriel.devever.net [149.202.51.241]) (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 781331294F3 for ; Sat, 17 Jun 2017 08:01:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 8B75C1D5C6; Sat, 17 Jun 2017 17:01:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=devever.net; h= user-agent:in-reply-to:content-transfer-encoding :content-disposition:content-type:content-type:mime-version :references:message-id:subject:subject:from:from:date:date :received:received; s=mimas; t=1497711682; x=1515901043; bh=Gh8m 0EmxYebx8Pbz2KzAh4AJgpoWjDp41d++4jjQCII=; b=POHgU2Tx3EtUvkUS3Ksx 2G8ktYBR+fFLAv46wQ9Tv5zHIWQEGvUcaUODXn4zSa8KFui0VG80itwCitEU73xk t2x1o8hNaIO9LCYVWsKYZSH6Mb1fzUTalXEWlHRrwWxfXjXcM4RmpIaLPED0gBMm heVSJCPxyWWDXp8jsluIKk6Cw78fMCo7KPKn6zv++5vSSAf4Ze5Pe4RaQjBA/dtH wwYawewPNcFWNaqy39D29gHXZDy+anyykMs/oUT15AaApv7UXGjuhQbD2GygwBN9 TrCRYMa4oEuFARFOfYDbQEyi/5recB+VkyoC4P+/RyMJffOvjVxhoB3hmrq+u70z YA== Received: from umbriel.devever.net ([127.0.0.1]) by localhost (umbriel.devever.net [127.0.0.1]) (amavisd-new, port 10026) with LMTP id 5Fg41fYEO2cI; Sat, 17 Jun 2017 17:01:22 +0200 (CEST) Received: from andover.lhh.devever.net (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 4EF041D5C5; Sat, 17 Jun 2017 17:01:22 +0200 (CEST) Date: Sat, 17 Jun 2017 16:01:22 +0100 From: Hugo Landau To: "Salz, Rich" Cc: acme@ietf.org Message-ID: <20170617150121.GA2175@andover.lhh.devever.net> References: <5997299eae9a4ca7bbd8f3798c5db6cd@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5997299eae9a4ca7bbd8f3798c5db6cd@usma1ex-dag1mb1.msg.corp.akamai.com> User-Agent: Mutt/1.8.1 (2017-04-11) Archived-At: Subject: Re: [Acme] Before entering WGLC ... X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 15:01:30 -0000 > Hugo, the CAA document is in WGLC. Russ raised the following issue on some text in section 2: > > . . . A CA MUST only consider a property with an "account-uri" > parameter to authorize issuance where the URI specified is an URI > that the CA recognises as identifying the account making a > certificate issuance request. > > > This is not a [crisp] MUST statement. I think it is trying to say two things whenthe "account-uri" is present: > > > (1) the CA MUST NOT issue a certificate containing the domain name that contains the CAA Resource Record if it does not recognize the account referenced by the URI. > > > (2) the CA MUST use the account referenced by the URI in the authorization process for a certificate request for the domain containing the CAA Resource Record. > > > If this is correct, please separate these two requirements. If it is not correct, please explain the text. > > Can you post an update next week? If not, would it help to add another author to do so? I would like to move this forward to the IESG soon. Please respond by early next week. I don't understand this issue. The wording is clear. From nobody Sat Jun 17 16:03:42 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89BC21242F7 for ; Sat, 17 Jun 2017 16:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 OZhkwO-vnPox for ; Sat, 17 Jun 2017 16:03:39 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0321A1243F6 for ; Sat, 17 Jun 2017 16:03:38 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5HN1uGf031417; Sun, 18 Jun 2017 00:03:35 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=ylSkYvA9bwwyqCa/S2n9V91HoDiAsFroB7j9QPM9yB4=; b=O7qVeoiiQ3LJKJThIj5tgNSPB2JrQYMTSVOL/OSPcYtWIsU/leuebE3GDaiea7c/XDFu QWjFdAT5/gdJIV7HnVthn/IhHNZTfG4RSwzP6R4yRjxKWQFsgSwcPt6Xj5XLDf+Tp3cu s161Vcnvjhuo58P/AMpm15uQQO9t2ebLtQXYKh6MalRnsgJz8+yaATBz0nz+MQrfnn/m AjoZNu94JpK1w5/GGHYCaR4IJEdQEMyZnK10rX7nMuhEIaOGEe0pnXK5K55jxjICZGWu 0dPHGhbS/eE7i8QJ9wJ+ka/4EZ+PtlujBmpMNwvwrX95o6Ob4yHB+8p7Z0NPqqP1FuJj eg== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2b4uy73w8t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 18 Jun 2017 00:03:35 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5HN0sbl032015; Sat, 17 Jun 2017 19:03:33 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2b4yru9r69-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 17 Jun 2017 19:03:33 -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 Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 17 Jun 2017 19:03:33 -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.1263.000; Sat, 17 Jun 2017 19:03:33 -0400 From: "Salz, Rich" To: Hugo Landau CC: "acme@ietf.org" Thread-Topic: [Acme] Before entering WGLC ... Thread-Index: AdLmnPm9U5O+8VQ1RlutqFMR3rfl7gA/yJgAAAhbzoA= Date: Sat, 17 Jun 2017 23:03:32 +0000 Message-ID: <5e52c9cbec7843cd8ab2117ee06c24e7@usma1ex-dag1mb1.msg.corp.akamai.com> References: <5997299eae9a4ca7bbd8f3798c5db6cd@usma1ex-dag1mb1.msg.corp.akamai.com> <20170617150121.GA2175@andover.lhh.devever.net> In-Reply-To: <20170617150121.GA2175@andover.lhh.devever.net> 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.44.131] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-17_18:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706170432 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-17_18:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706170432 Archived-At: Subject: Re: [Acme] Before entering WGLC ... X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 23:03:40 -0000 > > =A0 =A0. . . =A0A CA MUST only consider a property with an "account-uri= " > > =A0 =A0parameter to authorize issuance where the URI specified is an UR= I > > =A0 =A0that the CA recognises as identifying the account making a > > =A0 =A0certificate issuance request. > > > > > This is not a [crisp] MUST statement. =A0I think it is trying to say = two things > when=A0the "account-uri" is present: > > > > > (1) =A0the CA MUST NOT issue a certificate containing the domain name= that > contains the CAA Resource Record if it does not recognize the account > referenced by the URI. > > > > > (2) =A0the CA MUST use the account referenced by the URI in the > authorization process for a certificate request for the domain containing= the > CAA Resource Record. > > > > > If this is correct, please separate these two requirements. If it is= not > correct, please explain the text. > > > > Can you post an update next week? If not, would it help to add another > author to do so? I would like to move this forward to the IESG soon. Pl= ease > respond by early next week. >=20 > I don't understand this issue. The wording is clear. It's understandable, yes. Does Russ's proposal have the same meaning? I= 'm not sure. That means, I think that the original wording could stand a b= it of clarification. From nobody Sun Jun 18 02:02:25 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BED8129577 for ; Sun, 18 Jun 2017 02:02:24 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=devever.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udcyjNPs842l for ; Sun, 18 Jun 2017 02:02:22 -0700 (PDT) Received: from umbriel.devever.net (umbriel.devever.net [149.202.51.241]) (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 29F4912700F for ; Sun, 18 Jun 2017 02:02:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id EF2881D5C6; Sun, 18 Jun 2017 11:02:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=devever.net; h= user-agent:in-reply-to:content-transfer-encoding :content-disposition:content-type:content-type:mime-version :references:message-id:subject:subject:from:from:date:date :received:received; s=mimas; t=1497776539; x=1515965900; bh=nIio F2aNBof4ciFB/+b1obvBtyp+t/3wgDENSyRNooE=; b=PBi6YF9FlQx8eXg+OINj etRwIaODxy2H1WVFv50R5f0B+eRgEpsWjUSFFKk3w7Up51lFi2x2vb7lXON75rGF sRfQ5+7Nvp0JaNJWZ5DcFqGPLwXWk06WtEH+iXHRiV/Vgb1ik77n9esWvKWJRQsG NRm/+DC3ebJFY8XmpltXXGQDYEsc/pKN8UVWVTJ/EjWKjjs1Sq55281DhcEtZCyc 91fM5Oy0a1w9jw4bf6Z99ymTIWSjImtpkI3wL8u7v0v6riCMWuFWQS4rSSq/bhBj oPdUWwkDoyjbTU2iXGA88Pd+NECRQgRXK0MWgLEYnmkdDg2QCQPQ09x6R4ovRY2d eQ== Received: from umbriel.devever.net ([127.0.0.1]) by localhost (umbriel.devever.net [127.0.0.1]) (amavisd-new, port 10026) with LMTP id XJMNZJOBM36k; Sun, 18 Jun 2017 11:02:19 +0200 (CEST) Received: from andover.lhh.devever.net (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 988641D5C4; Sun, 18 Jun 2017 11:02:19 +0200 (CEST) Date: Sun, 18 Jun 2017 10:02:19 +0100 From: Hugo Landau To: "Salz, Rich" Cc: acme@ietf.org Message-ID: <20170618090219.GA28902@andover.lhh.devever.net> References: <5997299eae9a4ca7bbd8f3798c5db6cd@usma1ex-dag1mb1.msg.corp.akamai.com> <20170617150121.GA2175@andover.lhh.devever.net> <5e52c9cbec7843cd8ab2117ee06c24e7@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5e52c9cbec7843cd8ab2117ee06c24e7@usma1ex-dag1mb1.msg.corp.akamai.com> User-Agent: Mutt/1.8.1 (2017-04-11) Archived-At: Subject: Re: [Acme] Before entering WGLC ... X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2017 09:02:24 -0000 On Sat, Jun 17, 2017 at 11:03:32PM +0000, Salz, Rich wrote: > > > . . . A CA MUST only consider a property with an "account-uri" > > > parameter to authorize issuance where the URI specified is an URI > > > that the CA recognises as identifying the account making a > > > certificate issuance request. > > > > > > > This is not a [crisp] MUST statement. I think it is trying to say two things > > whenthe "account-uri" is present: > > > > > > > (1) the CA MUST NOT issue a certificate containing the domain name that > > contains the CAA Resource Record if it does not recognize the account > > referenced by the URI. > > > > > > > (2) the CA MUST use the account referenced by the URI in the > > authorization process for a certificate request for the domain containing the > > CAA Resource Record. > > > > > > > If this is correct, please separate these two requirements. If it is not > > correct, please explain the text. > > > > > > Can you post an update next week? If not, would it help to add another > > author to do so? I would like to move this forward to the IESG soon. Please > > respond by early next week. > > > > I don't understand this issue. The wording is clear. > > It's understandable, yes. Does Russ's proposal have the same meaning? I'm not sure. That means, I think that the original wording could stand a bit of clarification. (2) is weird. It talks about 'using an account', as though a CAA record can dictate what account is to be used. It almost suggests something like this: - I register account A and issue for example.com and setup ACME-CAA for that account - An unrelated party creates account B and requests issuance for example.com without control over that domain; the CA identifies the account specified in ACME-CAA, finds it authorised to issue for example.com and issues under it (!!!) Moreover it talks about how the CA MUST NOT issue a certificate under certain circumstances. But an individual CAA record never prevents issuance, per se (although the presence of any CAA records creates the requirement that at least one pass); at the worst it merely fails to authorize issuance in a particular case (but other adjacent CAA records might). Because of this I think it's necessary to keep the wording in terms of whether a CAA property authorizes issuance, rather than an enumeration of cases in which issuance MUST NOT occur. That's simply not possible when speaking about a single CAA record without regard to the other CAA records which might be adjacent to it. I'm open to clearer wording but I can't see any better way to express this accurately than talking about whether a given CAA property authorizes issuance. From nobody Sun Jun 18 07:16:13 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF731270AC for ; Sun, 18 Jun 2017 07:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 n8vQttgAleCw for ; Sun, 18 Jun 2017 07:16:10 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 299021271DF for ; Sun, 18 Jun 2017 07:16:10 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5IEC91i027741; Sun, 18 Jun 2017 15:16:07 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=SRN7jzQ8qquY3Zyz5iOhlVjTCF21e1dpLtrZEbPwRjA=; b=gAm9+9P83tsReIIrq/S0B751eK4HjHWJ7ihmO/UhiO5HJBC67fUKCcbWbwDGPScp0cBC 0lv4M0TMcyiga1MFXDcktyBFvDYlxYRbey1AOQKbVxtsb8b5GK0MRJgRkV44FQQbK0k3 mPd1WwS4cQt5/GnTwFHiF7Xa0o+1ytioYrA0ab1ldtkAgerwPmqlWxhiA6o2OuTfLOHR 2zGNWY8dFFywqDg6ObkJgbmfRVMss9oYZr/QIKur44D5DtUOoeL53ZR/5cOLPZPqM5wX jxZqdFtAtwOG499Ot80SExnqIbi26PJkJ32ATPP6lHptJQe+0VKiPIIrNpV5GNCMvgvP Bw== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2b4upp6wtv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 18 Jun 2017 15:16:07 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5IEG4YZ008481; Sun, 18 Jun 2017 10:16:06 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2b4yrubfq0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 18 Jun 2017 10:16:06 -0400 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.1263.5; Sun, 18 Jun 2017 07:16:05 -0700 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.1263.000; Sun, 18 Jun 2017 10:16:05 -0400 From: "Salz, Rich" To: Hugo Landau CC: "acme@ietf.org" Thread-Topic: [Acme] Before entering WGLC ... Thread-Index: AdLmnPm9U5O+8VQ1RlutqFMR3rfl7gA/yJgAAAhbzoAAHWSlgAACj8Ww Date: Sun, 18 Jun 2017 14:16:04 +0000 Message-ID: References: <5997299eae9a4ca7bbd8f3798c5db6cd@usma1ex-dag1mb1.msg.corp.akamai.com> <20170617150121.GA2175@andover.lhh.devever.net> <5e52c9cbec7843cd8ab2117ee06c24e7@usma1ex-dag1mb1.msg.corp.akamai.com> <20170618090219.GA28902@andover.lhh.devever.net> In-Reply-To: <20170618090219.GA28902@andover.lhh.devever.net> 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.35.22] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-18_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706180253 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-18_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706180254 Archived-At: Subject: Re: [Acme] Before entering WGLC ... X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2017 14:16:12 -0000 Thank you. For me, it addresses the issue. Russ, are you ok? From nobody Sun Jun 18 16:30:23 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479A8129571 for ; Sun, 18 Jun 2017 16:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 g26vY6y4Ogns for ; Sun, 18 Jun 2017 16:30:20 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 20C5112956C for ; Sun, 18 Jun 2017 16:30:20 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id p189so46478765lfe.2 for ; Sun, 18 Jun 2017 16:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S1y4pDloKmcbMCvoAVMSQ/hkVWb1vyBCqLVnywF4/Dk=; b=RPKvjWRSKRlo5rZrL1Beg5VwDHOuwNfso3XVtPuRL151DOr0mOX3OYoYf25i62P4bZ M+KIsYEEHS/hm27evylT55bWmsD3yS/X5GS+1zCcqm7q3f5T0xpQxgPRtgGCsm+b1iO/ iSAS0Ayytf+zvKtkL7ky4RGHWi5yiz5AldNaHy1Mmnl0XKbqqCsN4Hm1NX+hkKN+5V/s Q1wuSQe3cTcsk9w+V7G8DyRuQ5qMEjevF7hYGvvr75kbrF5mOKlQXkZsimZZVXc0hEBl WYAts+6PoRPQfrHXNDMlBQpNwmi5SXIjc+aUKoISPQZZABDx3FGkhsqyCI/zPQoByziI mcSw== 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=S1y4pDloKmcbMCvoAVMSQ/hkVWb1vyBCqLVnywF4/Dk=; b=o2EESC3suiAtqJhCxCtjI1NnBkCyt3EQhZB8tky2r7h5IgAHHiuIFU1k/GQqAIR5SC EWL6ZxdJ739sdGW5nLGLHS01LS3rTic72FINn3y7IVc+Qj1bVATk03A2dBxp3Kf3+/bh OAjkWBMDnYoIuxq2lkYlgNTQZ+ZRCO+A+4hDMdwP4qifWSsWnRLMXUpgaWMi8JOcnDT/ RnroypYOJePEK7z9/KehZJ4SrOs2V9ZI4vCCiVKAGfnu5JeAJGxDb4tvElWcI3t6oxok 3CwBOEdEixqBchlr20ekX7XT3B5URsceLjofBQAWMdgK+eHIkHr5pjD1Rmh98PS30qOp 9S2g== X-Gm-Message-State: AKS2vOxW1t7j3ObgyHj18Oq4ADaR/DhE0wxFzCdhqJSuJLZDuSdVfQRi H8SggRxJzAFGsyK/GIYwrU/599kDlxkp6Es= X-Received: by 10.25.196.17 with SMTP id u17mr5683108lff.19.1497828618283; Sun, 18 Jun 2017 16:30:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Sun, 18 Jun 2017 16:30:17 -0700 (PDT) In-Reply-To: References: <5997299eae9a4ca7bbd8f3798c5db6cd@usma1ex-dag1mb1.msg.corp.akamai.com> <20170617150121.GA2175@andover.lhh.devever.net> <5e52c9cbec7843cd8ab2117ee06c24e7@usma1ex-dag1mb1.msg.corp.akamai.com> <20170618090219.GA28902@andover.lhh.devever.net> From: Martin Thomson Date: Mon, 19 Jun 2017 09:30:17 +1000 Message-ID: To: "Salz, Rich" Cc: Hugo Landau , "acme@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Acme] Before entering WGLC ... X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2017 23:30:22 -0000 Like Russ, I find the statement very difficult to read. Would inverting it be better? > A CA MUST NOT issue authorize issuance if a CAA record is present unless the "account-uri" parameter identifies the account making a certificate issuance request. On 19 June 2017 at 00:16, Salz, Rich wrote: > Thank you. For me, it addresses the issue. Russ, are you ok? > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme From nobody Sun Jun 18 17:08:22 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E276126B6D for ; Sun, 18 Jun 2017 17:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 oOXj5I8oo-_C for ; Sun, 18 Jun 2017 17:08:18 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 3B0B3127078 for ; Sun, 18 Jun 2017 17:08:18 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id p189so46662587lfe.2 for ; Sun, 18 Jun 2017 17:08:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=wDquXOf1s/ttxa30PHRGTqiG6ZE8rbBz3XonqGkT7O0=; b=DO+FD6IIoCPLDFEXjWNXY0ZUyIkX0K5sdp5VM2Ev6rehndF8WWq50Tu/VngEIbGF07 ayw0z3jTfAnj02eO7CfZxkjof7Ur5pn1YzVX4Ikmn/3/k15B1HxVMV0yTYkfqiS0fvba Cs8zhySfK7rOypRMfeBNJpzlrxETPn9XBzXnN0mszztyVzUqOINLu91P6lZicCp9vweB LxlZAec+vNjjOCPVn9idByUc4W+Io691LcrorpXAwGpWJX9tNmOUxaCs/nJA8ORyexGK 0Js7IbCTifjQbDW4kFcwGtghyV/SRLbC7XX9stQLyaMKSb4vr8jYy8tV4U8+HFl4tx+c izlw== 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=wDquXOf1s/ttxa30PHRGTqiG6ZE8rbBz3XonqGkT7O0=; b=ZtfsNwp7yItCvLE9pUyZPtQrswLfNb2MhvEqaeZehslMlCCtbNb6AzGD0SgsxdJCU8 S30PBti8wpeB1SVZi3fmiepieoToVLQPgodQ4CJenPQcagno0OUix6OwaVhxrWYv8Shg /PUJC9P7qQbfPHbxsq8W3xfMRzHMxh01l6YBuVoyxed5poFRfwbNpO6lK6Ht3CdFEM1x 0kX4MQ1bjS6m8aAsDQrEeQ6HJ8MvfLWyIkFgsVfhFg0aT28mT3F9/SyBs70DnjyUu782 FWYpupbJsfevXzd0ctJ6C04Z7bAKux2Cj4C6YHWk2bga0mLz9/ZuN/9wBbhkwUKEe7Z3 IsDQ== X-Gm-Message-State: AKS2vOzxDPJNuIxPG+i9k73gBIYd+tmcLhxrBs21BHErqFn5ExMlIHq1 BpnTS2nYFo7RjKFLRHi8isYfCtuYBZUSOEI= X-Received: by 10.25.148.66 with SMTP id w63mr6590720lfd.169.1497830896287; Sun, 18 Jun 2017 17:08:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Sun, 18 Jun 2017 17:08:15 -0700 (PDT) In-Reply-To: <149761557766.24143.14359431560325982499@ietfa.amsl.com> References: <149761557766.24143.14359431560325982499@ietfa.amsl.com> From: Martin Thomson Date: Mon, 19 Jun 2017 10:08:15 +1000 Message-ID: To: "acme@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 00:08:20 -0000 A few brief comments on this draft. On 16 June 2017 at 22:19, wrote: > This memo proposes an ACME extension to enable the issuance of short- > term and automatically renewed certificates. This allows a domain > name owner to delegate the use of certificates to another party, > while retaining the capability to cancel this delegation at any time > with no need to rely on certificate revocation mechanisms. I found the introduction overly specific. The generic use case is to simplify the deployment of certificates to unprivileged nodes. The unprivileged nodes then only need to be configured with a URL for their certificates. That requires a couple of paragraphs of exposition at most. This extends to Section 2, which describes a system architecture that implies the existence of protocol elements that are simply not defined in this document. Sections 1 and 2 could much more clearly describe what *this* document provides. It provides an extension to ACME that allows for the creation of a certificate that automatically renews. The focus on the CDN case affects the entire document. The point is that the authorized entity is delegating the ability to use a certificate for its name to an unprivileged node. Don't use "CDN", "content owner" or any of these highly specific terms. Use generic terms; make new terms if necessary. FWIW, while NDC is a cute reversal, "consumer" really isn't accurate. draft-iab-web-pki-problems has been abandoned. It's not a great idea to cite it. In Section 3.1.1, I think that the resolution of these fields, being in days, is not conducive to reducing granularity. (Or will you permit 5.7e-3 as a value?) Section 3.1.1 needs to clearly articulate how "recurrent-certificate-validity" (could this be any more verbose and hard to type?) relates to "expires". Please include a definition for the new attributes, rather than just providing an example and commenting the JSON. In Section 3.1.2, you REALLY, REALLY need to authenticate this request. My suggestion is to change this to a POST request with { "recurrent": false }. (I'd have suggested PUT or PATCH, but ACME's reliance on JWS perverts that in ways that is incompatible with those methods.) In Section 3.2, the discussion about a Proxy is misleading. The only relevant actor in this is an ACME client. This section could be reduced to: An ACME client discovers whether a server supports this extension by examining a newly created order. The "recurrent" member will exist if the server supports automatic recurring certificate issuance; the "recurrent" member will be true if the server accepts the request. Can the server specify a shorter value for "recurrent-total-lifetime"? I don't understand Section 3.3 at all. I'd recommend removing this section. The DNO will decide what authorizations it requests amply without this level of proscription in standards. In Section 3.4, the use of the Expires header field is a common mistake. This is an HTTP caching directive. It should probably be shorter than the expiration time of the certificate (half in fact), but not for the reasons that you might think. The purpose of a recommendation on Expires is to ensure that the certificate is not cached beyond the point where a newer certificate will be issued. You should remove this text. Section 5.1 should be promoted to Section 5 Don't mention time-sensitive policy actions by the CA/B Forum. Can't you simply ensure that the CDN can't modify the CAA record? From nobody Mon Jun 19 09:14:00 2017 Return-Path: X-Original-To: acme@ietf.org Delivered-To: acme@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C3113154E; Mon, 19 Jun 2017 09:13:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: acme@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149788883702.10700.7423447308552160324@ietfa.amsl.com> Date: Mon, 19 Jun 2017 09:13:57 -0700 Archived-At: Subject: [Acme] I-D Action: draft-ietf-acme-email-tls-00.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 16:13:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Automated Certificate Management Environment of the IETF. Title : Extensions to Automatic Certificate Management Environment for email TLS Author : Alexey Melnikov Filename : draft-ietf-acme-email-tls-00.txt Pages : 7 Date : 2017-06-19 Abstract: This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for use by TLS email services. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-acme-email-tls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-acme-email-tls-00 https://datatracker.ietf.org/doc/html/draft-ietf-acme-email-tls-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 19 09:18:07 2017 Return-Path: X-Original-To: acme@ietf.org Delivered-To: acme@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA1413157B; Mon, 19 Jun 2017 09:18:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: acme@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149788908546.10765.11996233083865339127@ietfa.amsl.com> Date: Mon, 19 Jun 2017 09:18:05 -0700 Archived-At: Subject: [Acme] I-D Action: draft-ietf-acme-email-smime-00.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 16:18:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Automated Certificate Management Environment of the IETF. Title : Extensions to Automatic Certificate Management Environment for end user S/MIME certificates Author : Alexey Melnikov Filename : draft-ietf-acme-email-smime-00.txt Pages : 4 Date : 2017-06-19 Abstract: This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for use for email recipients that want to use S/MIME. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-acme-email-smime/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-acme-email-smime-00 https://datatracker.ietf.org/doc/html/draft-ietf-acme-email-smime-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 19 09:22:37 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81369129453 for ; Mon, 19 Jun 2017 09:22:35 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=devever.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JydB5nFpoDJ2 for ; Mon, 19 Jun 2017 09:22:34 -0700 (PDT) Received: from umbriel.devever.net (umbriel.devever.net [149.202.51.241]) (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 D63141292F5 for ; Mon, 19 Jun 2017 09:22:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 434B01D5CB; Mon, 19 Jun 2017 18:22:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=devever.net; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received; s=mimas; t=1497889352; x=1516078713; bh=nwWYvzLJprW4ujqQM0C2CS76IwokLQRz2HWVdp+Yy8g=; b= nT1Xy5UGnWE5FezU79GnWrT7MSvvhL5ihJU9qdgcYwe7wu+U59vVJiDsjhGRTkPj D90PfVVz6ez90YwkjLvFrLWrZFfs4EEOy9EGO408dpw8VyVO8WDJgCR0u4hnkTdo AvWq3ZJCaB62s0Xu4Afq2vQQeAiLgWdGZ9BfxzCVELCCi7iO7nh6eYwdRl8UqPL3 BMw7Uk3opNwVBHK3dVreNluca8TCyMnsHIISXsp/A64sXYu+iJPxM3RJlsqaZPCI QGbUaArBIcGebAk7lzuzQqGjtxLUguxpH2o0HykT6Bnl7V1pIkfjnzz5VPNUwB1E isFWy5rQX6lXS8ckBSkegQ== Received: from umbriel.devever.net ([127.0.0.1]) by localhost (umbriel.devever.net [127.0.0.1]) (amavisd-new, port 10026) with LMTP id XkMcReN4LLeJ; Mon, 19 Jun 2017 18:22:32 +0200 (CEST) Received: from andover.lhh.devever.net (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with SMTP id EF7511D5C4; Mon, 19 Jun 2017 18:22:31 +0200 (CEST) Date: Mon, 19 Jun 2017 17:22:31 +0100 From: Hugo Landau To: Martin Thomson Cc: acme@ietf.org Message-ID: <20170619162231.GA20324@andover.lhh.devever.net> References: <5997299eae9a4ca7bbd8f3798c5db6cd@usma1ex-dag1mb1.msg.corp.akamai.com> <20170617150121.GA2175@andover.lhh.devever.net> <5e52c9cbec7843cd8ab2117ee06c24e7@usma1ex-dag1mb1.msg.corp.akamai.com> <20170618090219.GA28902@andover.lhh.devever.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.1 (2017-04-11) Archived-At: Subject: Re: [Acme] Before entering WGLC ... X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 16:22:35 -0000 > Like Russ, I find the statement very difficult to read. Would > inverting it be better? > > > A CA MUST NOT issue authorize issuance if a CAA record is present unless the "account-uri" parameter identifies the account making a certificate issuance request. See previous reply. Issuance is not determined by the presence of "a" CAA record; there may be multiple and issuance is authorized if any are considered to match the request. Establishing that a specific CAA record is not matched is not a sufficient condition for refusing issuance, because another adjacent CAA record might authorise it. I think any attempt to describe this criterion in terms of specific situational MUST NOTs with regard to a single CAA record is futile. From nobody Mon Jun 19 09:31:57 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2741A131585 for ; Mon, 19 Jun 2017 09:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 maVfshLLFxm3 for ; Mon, 19 Jun 2017 09:31:52 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360DB1314CA for ; Mon, 19 Jun 2017 09:31:52 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5JGRMBI004456; Mon, 19 Jun 2017 17:31:47 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Mm05Ldowh5Wsl2rFUQ6lu80FsGCIxDnnMN5nc0Pakbk=; b=gWw45GNXbCQx+3l1R1S6r5f2/IOdE1xNC7VweGMEPtJwKOpQyW9fDY5mjTbUrirXDFMT BtWsVRzZbFczSw5+2iKIbHjsn0misZ5xms1mqEh5FKkjf/FQYYmT87t6qXzKNWsc5XPd 5ZWjsFOJuhJdzAtL2ZTFtFHw4SfVDkDA2YKKRMYGwi1sGvAJRHuWbWf+p1/97d6Iyo4S MA8/Gd0DcCA1dhZy9Pb/s6UG+plkJfGwNLx5eL2BtQqKTvIG+a76g8pjliK5wjRh+94j sGlQimMgvDRC+CqRthXMBl/6YHsl/7kZL/eeitB0uT6YxTwQY71+o0eK2lZ/cmvadQP7 IQ== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2b6ddvtact-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Jun 2017 17:31:47 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5JGR3FG012628; Mon, 19 Jun 2017 12:31:44 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2b4yruf4mg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 19 Jun 2017 12:31:44 -0400 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.1263.5; Mon, 19 Jun 2017 12:31:44 -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.1263.000; Mon, 19 Jun 2017 12:31:44 -0400 From: "Salz, Rich" To: Hugo Landau , Martin Thomson CC: "acme@ietf.org" Thread-Topic: [Acme] Before entering WGLC ... Thread-Index: AdLmnPm9U5O+8VQ1RlutqFMR3rfl7gA/yJgAAAhbzoAAHWSlgAACj8WwABvAdYAAI1oSgAAIG+Ug Date: Mon, 19 Jun 2017 16:31:43 +0000 Message-ID: <9016cef38c404a5e85984763a9270449@usma1ex-dag1mb1.msg.corp.akamai.com> References: <5997299eae9a4ca7bbd8f3798c5db6cd@usma1ex-dag1mb1.msg.corp.akamai.com> <20170617150121.GA2175@andover.lhh.devever.net> <5e52c9cbec7843cd8ab2117ee06c24e7@usma1ex-dag1mb1.msg.corp.akamai.com> <20170618090219.GA28902@andover.lhh.devever.net> <20170619162231.GA20324@andover.lhh.devever.net> In-Reply-To: <20170619162231.GA20324@andover.lhh.devever.net> 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.216] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-19_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706190271 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-19_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706190272 Archived-At: Subject: Re: [Acme] Before entering WGLC ... X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 16:31:55 -0000 How about this: A CA MAY proceed with issuance if a CAA record is present whose value match= es the account-uri parameter of the account making the request. If no CAA records have such a match, then the CA MUST NOT proceed with issu= ance. From nobody Mon Jun 19 11:08:23 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A0C1317A2 for ; Mon, 19 Jun 2017 11:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 HSkqyxDO6onc for ; Mon, 19 Jun 2017 11:08:19 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C6013179F for ; Mon, 19 Jun 2017 11:08:19 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5JI2nl5005345 for ; Mon, 19 Jun 2017 19:08:18 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=LHwiL8o8eex+yWf8PbuiDVJ5h2SnaRDOt/czRMhFjTc=; b=NJL28NparZwX0P7NCJAfbZbZB4hB9XxxTPYN0VDes3bKfcXArzBK4P1jaCJKFXO1IQcQ 6KkUrdHJUMFiBj/8dHYpOvfbqsrvvHKdOavrLYpLN/SqmQJLlRYJm0PUmYI035pIRj0o aQAQZ5u7nWz312pQ/vqD8sXNUQF5e4s+vGre8AlkHPdDKCKJWzW6ruLmhvCY2Ev4zfaG Vgfw2lDTEIIBfR7ca0naDcSzi7+JLZQfSbMBubnJ5/vAanvxXtCjGimXsaSSeAZoWPgt aQwjNtV3GSFmxiA5F/4dK9iRwKQ7itIhvd8Qn38BeuUGlocgOviWR6iYLBMV1zP+PQuC uA== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2b6ddvtyvw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 19 Jun 2017 19:08:17 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5JI19YE008152 for ; Mon, 19 Jun 2017 14:08:17 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint4.akamai.com with ESMTP id 2b4yruw8rn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 19 Jun 2017 14:08:16 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb2.msg.corp.akamai.com (172.27.123.59) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 19 Jun 2017 14:08:11 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 19 Jun 2017 14:08:11 -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.1263.000; Mon, 19 Jun 2017 14:08:11 -0400 From: "Salz, Rich" To: "acme@ietf.org" Thread-Topic: Rolling keys and pending validations Thread-Index: AdLpJhpoh06PBTCkQemxb0Jtd47K7A== Date: Mon, 19 Jun 2017 18:08:10 +0000 Message-ID: <0896b144e7e942b1ac68db9ead4c42bb@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.32.216] Content-Type: multipart/alternative; boundary="_000_0896b144e7e942b1ac68db9ead4c42bbusma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-19_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706190297 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-19_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706190297 Archived-At: Subject: [Acme] Rolling keys and pending validations X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 18:08:22 -0000 --_000_0896b144e7e942b1ac68db9ead4c42bbusma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Speaking purely as an individual. This is about Section 7.3.3 It can be difficult to change the account credentials, because you have to = make sure that nothing is "in transit." For a large client, or perhaps a r= eseller type of arrangement, this can be difficult if not impossible. I would like to see a sentence added to the end of the section that says "r= olling keys does not invalidate any challenges currently in progress." I leave this to the WG as to whether or not this is strictly editorial. Ev= en if there is no consensus, an explicit statement about the validity shoul= d be added. I think NOT invalidation is better, as the inverse makes chang= es hard. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz --_000_0896b144e7e942b1ac68db9ead4c42bbusma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Speaking purely as an individual.

 

This is about Section 7.3.3

 

It can be difficult to change the account credential= s, because you have to make sure that nothing is “in transit.”&= nbsp; For a large client, or perhaps a reseller type of arrangement, this c= an be difficult if not impossible.

 

I would like to see a sentence added to the end of t= he section that says “rolling keys does not invalidate any challenges= currently in progress.”

 

I leave this to the WG as to whether or not this is = strictly editorial.  Even if there is no consensus, an explicit statem= ent about the validity should be added.  I think NOT invalidation is b= etter, as the inverse makes changes hard.

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

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

 

--_000_0896b144e7e942b1ac68db9ead4c42bbusma1exdag1mb1msgcorpak_-- From nobody Mon Jun 19 11:35:00 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE0A1241FC for ; Mon, 19 Jun 2017 11:34:58 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 n32qbuy_uH05 for ; Mon, 19 Jun 2017 11:34:49 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::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 AEC6C1317F3 for ; Mon, 19 Jun 2017 11:34:47 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id c11so23832894wrc.3 for ; Mon, 19 Jun 2017 11:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mXXcUlKaNhVaT0CMy6fQSaCFbnN6XYTD0AYXT5W7q60=; b=h6mXDntSurSPH5RHIbGgK+YDKl02olgrhcAgOCLOhabGYD5TU5GBB7mg3RxI4vDYLs UhXqaIaIB+XKzqgiNKZZQSwnItw0rhmNH1WMcuP9Pv/fUcmLlOmpUMDOBj+hyHuw6z9F Em5e3Dvgysmf5izt2xd16BZ6NW+HKMLZqIPEu3qYWQvmeCiUNk2DLs5RXi10vjJBVyh+ MX9ymkIeTMLtB6LO48I9B37uRWRRO/KbmNYS+7ew9e17Sr8pNovB2P+8tExKkTv2j/o9 DtuME7pnfJd0V1CoxrGHLbrpSg4DFSEZvKi+MOTZ6I5bMBMxuF0Fyss5o2KztFShP+gN 4k+Q== 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=mXXcUlKaNhVaT0CMy6fQSaCFbnN6XYTD0AYXT5W7q60=; b=pe0fsbeEZXDiZRRGM2Do0/gSnsdaTcHjgl5FUQboaKC9L9v7p3FqXCpjF1D6ZZYM8I rWvFS5NgmoG6ubdRDO1XYD/UMBDyyamOPR25ZBqvOBx3cYx14fbZi1yOu8H6ztub5Mhl TEp3v30dny8PUvH3EXxRJ7rO73Uqci4dvlr+81PHxzdCuSyx+NQ4HqxaTUB4XOK/Se2G A7ryziF2+M+gygUJsqI9ubXsZbdmsKmPxqX/v7jgkkUaSqEcVy+4u7rAWX40VHjpiS08 ulDo/t2wG0z5gw3vNUFJ/cs+y3hwYAwIaR3DEHQWvaD1P8Oe/UyphEYaj+dV+JLD0QSD sTqw== X-Gm-Message-State: AKS2vOyX9bY0g1sdtNArV59M3Ygr6FGMpIvPh0sH9SuPTB26yqjtP15/ 18UmKe13DAaLTXRsEclSuvbk4EBxtPDPvkTLaA== X-Received: by 10.223.142.143 with SMTP id q15mr12917664wrb.180.1497897286085; Mon, 19 Jun 2017 11:34:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.109.16 with HTTP; Mon, 19 Jun 2017 11:34:45 -0700 (PDT) In-Reply-To: <0896b144e7e942b1ac68db9ead4c42bb@usma1ex-dag1mb1.msg.corp.akamai.com> References: <0896b144e7e942b1ac68db9ead4c42bb@usma1ex-dag1mb1.msg.corp.akamai.com> From: Richard Barnes Date: Mon, 19 Jun 2017 14:34:45 -0400 Message-ID: To: "Salz, Rich" Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="f403045f517ca5c7b5055254638f" Archived-At: Subject: Re: [Acme] Rolling keys and pending validations X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 18:34:58 -0000 --f403045f517ca5c7b5055254638f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This seems sensible; rolling keys shouldn't invalidate things in transit any more than changing your Gmail password should delete your drafts folder= . I would have a little bit of a hard time calling this "purely editorial", since it specifies server behavior. But it seems like you're just codifying an expectation that at least I already had (TBH, I would not have thought to build a server otherwise), so I would be inclined to go ahead and merge it if at least one or two other people chime in. Here's a PR: https://github.com/ietf-wg-acme/acme/pull/323 --Richard On Mon, Jun 19, 2017 at 2:08 PM, Salz, Rich wrote: > Speaking purely as an individual. > > > > This is about Section 7.3.3 > > > > It can be difficult to change the account credentials, because you have t= o > make sure that nothing is =E2=80=9Cin transit.=E2=80=9D For a large clie= nt, or perhaps a > reseller type of arrangement, this can be difficult if not impossible. > > > > I would like to see a sentence added to the end of the section that says > =E2=80=9Crolling keys does not invalidate any challenges currently in pro= gress.=E2=80=9D > > > > I leave this to the WG as to whether or not this is strictly editorial. > Even if there is no consensus, an explicit statement about the validity > should be added. I think NOT invalidation is better, as the inverse make= s > changes hard. > > -- > > Senior Architect, Akamai Technologies > > Member, OpenSSL Dev Team > > IM: richsalz@jabber.at Twitter: RichSalz > > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --f403045f517ca5c7b5055254638f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This seems sensible; rolling keys shouldn't inval= idate things in transit any more than changing your Gmail password should d= elete your drafts folder.

I would have a littl= e bit of a hard time calling this "purely editorial", since it sp= ecifies server behavior.=C2=A0 But it seems like you're just codifying = an expectation that at least I already had (TBH, I would not have thought t= o build a server otherwise), so I would be inclined to go ahead and merge i= t if at least one or two other people chime in.


--Richard

<= br>
On Mon, Jun 19, 2017 at 2:08 PM, Salz, Rich <= span dir=3D"ltr"><= rsalz@akamai.com> wrote:

Speaking purely as an individual.

=C2=A0

This is about Section 7.3.3

=C2=A0

It can be difficult to change the account credential= s, because you have to make sure that nothing is =E2=80=9Cin transit.=E2=80= =9D=C2=A0 For a large client, or perhaps a reseller type of arrangement, th= is can be difficult if not impossible.

=C2=A0

I would like to see a sentence added to the end of t= he section that says =E2=80=9Crolling keys does not invalidate any challeng= es currently in progress.=E2=80=9D

=C2=A0

I leave this to the WG as to whether or not this is = strictly editorial.=C2=A0 Even if there is no consensus, an explicit statem= ent about the validity should be added.=C2=A0 I think NOT invalidation is b= etter, as the inverse makes changes hard. <= /span>

--=C2=A0

Senior Architect, Akamai Technologies<= /p>

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz

=C2=A0


_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


--f403045f517ca5c7b5055254638f-- From nobody Mon Jun 19 11:44:35 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60AD3131808 for ; Mon, 19 Jun 2017 11:44:32 -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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 YG59qgRTndkY for ; Mon, 19 Jun 2017 11:44:29 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0064A131807 for ; Mon, 19 Jun 2017 11:44:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id A060723243; Mon, 19 Jun 2017 21:44:26 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id 3zOyGRt2BVhu; Mon, 19 Jun 2017 21:44:26 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 364E0286; Mon, 19 Jun 2017 21:44:23 +0300 (EEST) Date: Mon, 19 Jun 2017 21:44:23 +0300 From: Ilari Liusvaara To: Richard Barnes Cc: "Salz, Rich" , "acme@ietf.org" Message-ID: <20170619184423.wtpj2qtq6awk3rju@LK-Perkele-VII> References: <0896b144e7e942b1ac68db9ead4c42bb@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170306 (1.8.0) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] Rolling keys and pending validations X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 18:44:32 -0000 On Mon, Jun 19, 2017 at 02:34:45PM -0400, Richard Barnes wrote: > This seems sensible; rolling keys shouldn't invalidate things in transit > any more than changing your Gmail password should delete your drafts folder. > > I would have a little bit of a hard time calling this "purely editorial", > since it specifies server behavior. But it seems like you're just > codifying an expectation that at least I already had (TBH, I would not have > thought to build a server otherwise), so I would be inclined to go ahead > and merge it if at least one or two other people chime in. > > Here's a PR: https://github.com/ietf-wg-acme/acme/pull/323 If there is pending validation over key change, which key hash should the validation use when it is resolved? The old one? The new one? -Ilari From nobody Mon Jun 19 15:34:31 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF8A129C29 for ; Mon, 19 Jun 2017 15:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 fsFeX2_iKMXT for ; Mon, 19 Jun 2017 15:34:27 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 B771012954B for ; Mon, 19 Jun 2017 15:34:26 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id o83so63834938lff.3 for ; Mon, 19 Jun 2017 15:34:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=430ABUWJcN7pknpm7h30QbSFHE/bxA6W4A1mQIm5i/k=; b=IhI99XAE1Kg5X3I1aqR8+QIj++abnZd235nWz+G9Eq/bMUhl9ba8l/sTMTTeAVPXGj Ty37TchvlHM4OGvxHZ0jT6iq2aFdbCye595HT5V9Ja0eNasyKPZL2O6rbOhFzFieZVsD g24VHwFEBm8lLgY0VAMtgigc8S2OCw/WSJzHJbQil+Z7Beh7sit+vUjkSCSGGguRn3YO qkAIjxsCzDRqVExJfsHJnDz9MKvLB4dvGBE0wxxp9K4fu59Fnsty8dFZF4Ib+KAQ5sLg 0p4MXpmuTRmLqcBYZYWvJrq5GetLWQETQB0leubGBddjmORqx86GTcMlIIymIi2Nt+s4 thFw== 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=430ABUWJcN7pknpm7h30QbSFHE/bxA6W4A1mQIm5i/k=; b=Md6R1+WeNhD5Kbnd0iyDy2xOhQq9pkADz1V0nbt3poJmNziCTPBDgfw0TydqtR1OfT 0UnQtnHVEuf+uX7r2S0Yav8oZaAsUMM/TrXz3Vpg+oC1oEepgeRPQnAjS15oEwZtUzR0 My4fzOd9tMP5cXKIAh96xCwgydcSOSiSeSbqtwzyVZ0WR0QJ2cR20O0rV0FkTyHv/N3J rLWeyd8qs6iQx60YpqIUSgqMV7yJ7eLXzQlH6GIeKCYxLpOFL2XZtxohFaNVqEqIDMqJ WefMyc04D5sXV5oM0F75zlOgbHHKep86hAnK3z/xsVGBw5/8JY5auG/MAFFryOS9DtDl yRkQ== X-Gm-Message-State: AKS2vOyTI6O5Wnb5YAvzahS3/gHsb1J+R0jeXxUuF8FvSZik4eQhVqDY C6+f5pKRUc/ENic0NBoBCXlGy+xCCM0d X-Received: by 10.25.201.18 with SMTP id z18mr8493596lff.172.1497911664708; Mon, 19 Jun 2017 15:34:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Mon, 19 Jun 2017 15:34:23 -0700 (PDT) Received: by 10.46.78.17 with HTTP; Mon, 19 Jun 2017 15:34:23 -0700 (PDT) In-Reply-To: References: <149761557766.24143.14359431560325982499@ietfa.amsl.com> From: Martin Thomson Date: Tue, 20 Jun 2017 08:34:23 +1000 Message-ID: To: acme@ietf.org Content-Type: multipart/alternative; boundary="001a114b2c78ae1478055257bc0e" Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 22:34:30 -0000 --001a114b2c78ae1478055257bc0e Content-Type: text/plain; charset="UTF-8" One further thought. ACME uses an absolute time for expiration. This uses a relative time. I think that I prefer the former. I realize that consistency might be impossible in this case, since the recurrent duration is necessarily relative, but I though it worth raising. On 19 Jun. 2017 10:08 am, "Martin Thomson" wrote: > A few brief comments on this draft. > > On 16 June 2017 at 22:19, wrote: > > This memo proposes an ACME extension to enable the issuance of short- > > term and automatically renewed certificates. This allows a domain > > name owner to delegate the use of certificates to another party, > > while retaining the capability to cancel this delegation at any time > > with no need to rely on certificate revocation mechanisms. > > I found the introduction overly specific. The generic use case is to > simplify the deployment of certificates to unprivileged nodes. The > unprivileged nodes then only need to be configured with a URL for > their certificates. > > That requires a couple of paragraphs of exposition at most. This > extends to Section 2, which describes a system architecture that > implies the existence of protocol elements that are simply not defined > in this document. > > Sections 1 and 2 could much more clearly describe what *this* document > provides. It provides an extension to ACME that allows for the > creation of a certificate that automatically renews. > > The focus on the CDN case affects the entire document. The point is > that the authorized entity is delegating the ability to use a > certificate for its name to an unprivileged node. Don't use "CDN", > "content owner" or any of these highly specific terms. Use generic > terms; make new terms if necessary. FWIW, while NDC is a cute > reversal, "consumer" really isn't accurate. > > draft-iab-web-pki-problems has been abandoned. It's not a great idea > to cite it. > > In Section 3.1.1, I think that the resolution of these fields, being > in days, is not conducive to reducing granularity. (Or will you > permit 5.7e-3 as a value?) > > Section 3.1.1 needs to clearly articulate how > "recurrent-certificate-validity" (could this be any more verbose and > hard to type?) relates to "expires". > > Please include a definition for the new attributes, rather than just > providing an example and commenting the JSON. > > In Section 3.1.2, you REALLY, REALLY need to authenticate this > request. My suggestion is to change this to a POST request with { > "recurrent": false }. (I'd have suggested PUT or PATCH, but ACME's > reliance on JWS perverts that in ways that is incompatible with those > methods.) > > In Section 3.2, the discussion about a Proxy is misleading. The only > relevant actor in this is an ACME client. This section could be > reduced to: > > An ACME client discovers whether a server supports this extension by > examining a newly created order. The "recurrent" member will exist if > the server supports automatic recurring certificate issuance; the > "recurrent" member will be true if the server accepts the request. > > Can the server specify a shorter value for "recurrent-total-lifetime"? > > I don't understand Section 3.3 at all. I'd recommend removing this > section. The DNO will decide what authorizations it requests amply > without this level of proscription in standards. > > In Section 3.4, the use of the Expires header field is a common > mistake. This is an HTTP caching directive. It should probably be > shorter than the expiration time of the certificate (half in fact), > but not for the reasons that you might think. The purpose of a > recommendation on Expires is to ensure that the certificate is not > cached beyond the point where a newer certificate will be issued. You > should remove this text. > > Section 5.1 should be promoted to Section 5 > > Don't mention time-sensitive policy actions by the CA/B Forum. > > Can't you simply ensure that the CDN can't modify the CAA record? > --001a114b2c78ae1478055257bc0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One further thought. ACME uses an absolute time for expir= ation. This uses a relative time. I think that I prefer the former. I reali= ze that consistency might be impossible in this case, since the recurrent d= uration is necessarily relative, but I though it worth raising.

On 19 Jun. 2017 10:08 a= m, "Martin Thomson" <martin.thomson@gmail.com> wrote:
A few brief comments on this draft.

On 16 June 2017 at 22:19,=C2=A0 <internet-drafts@ietf.org> wrote:
>=C2=A0 =C2=A0 This memo proposes an ACME extension to enable the issuan= ce of short-
>=C2=A0 =C2=A0 term and automatically renewed certificates.=C2=A0 This a= llows a domain
>=C2=A0 =C2=A0 name owner to delegate the use of certificates to another= party,
>=C2=A0 =C2=A0 while retaining the capability to cancel this delegation = at any time
>=C2=A0 =C2=A0 with no need to rely on certificate revocation mechanisms= .

I found the introduction overly specific.=C2=A0 The generic use case is to<= br> simplify the deployment of certificates to unprivileged nodes.=C2=A0 The unprivileged nodes then only need to be configured with a URL for
their certificates.

That requires a couple of paragraphs of exposition at most.=C2=A0 This
extends to Section 2, which describes a system architecture that
implies the existence of protocol elements that are simply not defined
in this document.

Sections 1 and 2 could much more clearly describe what *this* document
provides.=C2=A0 It provides an extension to ACME that allows for the
creation of a certificate that automatically renews.

The focus on the CDN case affects the entire document.=C2=A0 The point is that the authorized entity is delegating the ability to use a
certificate for its name to an unprivileged node.=C2=A0 Don't use "= ;CDN",
"content owner" or any of these highly specific terms.=C2=A0 Use = generic
terms; make new terms if necessary.=C2=A0 FWIW, while NDC is a cute
reversal, "consumer" really isn't accurate.

draft-iab-web-pki-problems has been abandoned.=C2=A0 It's not a great i= dea
to cite it.

In Section 3.1.1, I think that the resolution of these fields, being
in days, is not conducive to reducing granularity.=C2=A0 (Or will you
permit 5.7e-3 as a value?)

Section 3.1.1 needs to clearly articulate how
"recurrent-certificate-validity" (could this be any more ver= bose and
hard to type?) relates to "expires".

Please include a definition for the new attributes, rather than just
providing an example and commenting the JSON.

In Section 3.1.2, you REALLY, REALLY need to authenticate this
request.=C2=A0 My suggestion is to change this to a POST request with {
"recurrent": false }.=C2=A0 (I'd have suggested PUT or PATCH,= but ACME's
reliance on JWS perverts that in ways that is incompatible with those
methods.)

In Section 3.2, the discussion about a Proxy is misleading.=C2=A0 The only<= br> relevant actor in this is an ACME client.=C2=A0 This section could be
reduced to:

An ACME client discovers whether a server supports this extension by
examining a newly created order.=C2=A0 The "recurrent" member wil= l exist if
the server supports automatic recurring certificate issuance; the
"recurrent" member will be true if the server accepts the request= .

Can the server specify a shorter value for "recurrent-total-lifetime&q= uot;?

I don't understand Section 3.3 at all.=C2=A0 I'd recommend removing= this
section.=C2=A0 The DNO will decide what authorizations it requests amply without this level of proscription in standards.

In Section 3.4, the use of the Expires header field is a common
mistake.=C2=A0 This is an HTTP caching directive.=C2=A0 It should probably = be
shorter than the expiration time of the certificate (half in fact),
but not for the reasons that you might think.=C2=A0 The purpose of a
recommendation on Expires is to ensure that the certificate is not
cached beyond the point where a newer certificate will be issued.=C2=A0 You=
should remove this text.

Section 5.1 should be promoted to Section 5

Don't mention time-sensitive policy actions by the CA/B Forum.

Can't you simply ensure that the CDN can't modify the CAA record?
--001a114b2c78ae1478055257bc0e-- From nobody Mon Jun 19 18:55:17 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F66131839 for ; Mon, 19 Jun 2017 18:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 FNyjCVmFYEfR for ; Mon, 19 Jun 2017 18:55:14 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9994E13167E for ; Mon, 19 Jun 2017 18:55:14 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5K1qGQH006019; Tue, 20 Jun 2017 02:55:12 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=sctv4wq82HtpXprjxaD6Hgp85pVV90cr8e18t49Wlqs=; b=MmppVECu2rUClc2d6zVSkhUoGw7T3M14jW7Cj+YbLTel9hppP6rIqCSsT+QMD2FMXFtt 5aEzeXEvungyXcri634nTvPE2LORQ+qLdCbEde+hvv1Hu94qHTU4p4o/ywgSZnFkSpxN XXq9m6fs7KSHgZcFYZR39BOU/qJEgUTjxT/xkrE9kxOKxlh5G+HYiSchTIrB3WepXQjG K0gQkIqFmjvDCVEUfk2TLx0PXj9kb66rAuP7N51bsU/TQZKirrTKuCFLVH0asnA55pMU uqH+3mosN1ZbHroYfPOijANneUa+bVybo1iw3SOP/WcrDKIkgvgkWJxlBVrRmCnVi3Lg Gw== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2b6ddvw815-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Jun 2017 02:55:12 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5K1p4WR001448; Mon, 19 Jun 2017 21:55:10 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2b4yrugqge-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 19 Jun 2017 21:55:10 -0400 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.1263.5; Mon, 19 Jun 2017 18:55:09 -0700 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.1263.000; Mon, 19 Jun 2017 21:55:09 -0400 From: "Salz, Rich" To: "acme@ietf.org" CC: Martin Thomson Thread-Topic: I-D Action: draft-ietf-acme-star-00.txt Thread-Index: AdLpaDVmsXanv5UhTNiKrN5FX4735w== Date: Tue, 20 Jun 2017 01:55:08 +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.47.26] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-19_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706200035 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-19_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706200035 Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 01:55:16 -0000 As chair: Thanks for the detailed review. =20 As an individual: I agree we need a new term other than CDN. All the good w= ords are taken, but perhaps Agent works? > draft-iab-web-pki-problems has been abandoned. I didn't notice that. Rats. -- =20 Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz From nobody Tue Jun 20 04:10:48 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B531294D2 for ; Tue, 20 Jun 2017 04:10:47 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=devever.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJE5ViITLXHv for ; Tue, 20 Jun 2017 04:10:46 -0700 (PDT) Received: from umbriel.devever.net (umbriel.devever.net [149.202.51.241]) (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 2B1F4127337 for ; Tue, 20 Jun 2017 04:10:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 63F921D5D2; Tue, 20 Jun 2017 13:10:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=devever.net; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received; s=mimas; t=1497957043; x=1516146404; bh=GtEYRBfszN7upqUsWDj1GtSIVYp2yvV7u8xbM6N8oV4=; b= KycgU5iyJj99sblB/NS2CEZntCPKhEsv8iE/AWUy/G/Myqlzqz7L7uwejU3udfDA M5nCkaj6ojLiWjQDmq+uWY6bzOZk/YfFEVWl7wqYNCh4tKX+kDfeyPc+zgDkBv0H vBmsDFsSrWVSKS3bt/ibqFRHfJpUXWvACXmHfTRZt9PGHc+aJjCVFg0xRQR36j5n ETSUyTB/oeeC3JXbddUPj/3vTCzcagwCXEY4T/O1v6MXqqIPliZwyZYf/K/8mQwp KwSyqlapNu3Re8B7xTAH5KHOn/wQdjwyFKw7oi2/Gqvbv/mQMSd+kGQ27OSBtuMY t4d4F1N7oGu3PwzCoq1XmA== Received: from umbriel.devever.net ([127.0.0.1]) by localhost (umbriel.devever.net [127.0.0.1]) (amavisd-new, port 10026) with LMTP id T0hvurZ4UWeq; Tue, 20 Jun 2017 13:10:43 +0200 (CEST) Received: from andover.lhh.devever.net (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with SMTP id 2021A1D5D1; Tue, 20 Jun 2017 13:10:43 +0200 (CEST) Date: Tue, 20 Jun 2017 12:10:43 +0100 From: Hugo Landau To: "Salz, Rich" Cc: acme@ietf.org Message-ID: <20170620111042.GA13184@andover.lhh.devever.net> References: <5997299eae9a4ca7bbd8f3798c5db6cd@usma1ex-dag1mb1.msg.corp.akamai.com> <20170617150121.GA2175@andover.lhh.devever.net> <5e52c9cbec7843cd8ab2117ee06c24e7@usma1ex-dag1mb1.msg.corp.akamai.com> <20170618090219.GA28902@andover.lhh.devever.net> <20170619162231.GA20324@andover.lhh.devever.net> <9016cef38c404a5e85984763a9270449@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9016cef38c404a5e85984763a9270449@usma1ex-dag1mb1.msg.corp.akamai.com> User-Agent: Mutt/1.8.1 (2017-04-11) Archived-At: Subject: Re: [Acme] Before entering WGLC ... X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 11:10:48 -0000 > A CA MAY proceed with issuance if a CAA record is present whose value matches the account-uri parameter of the account making the request. > If no CAA records have such a match, then the CA MUST NOT proceed with issuance. This neglects to include the other criteria for validation of a CAA record, however; the wording here suggests this is the only aspect of a CAA record that needs to be validated. If you want to describe a sufficient condition, rather than a necessary one, it stands to reason you'd have to copy and paste large amounts of language from the CAA specification into the specification. Currently we have A CA MUST only consider a property with an "account-uri" parameter to authorize issuance where the URI specified is an URI that the CA recognises as identifying the account making a certificate issuance request. We could also negate it, which might actually be better - the above is slightly more susceptible to be confused for a statement of a sufficient condition: A CA MUST NOT consider a property with an "account-uri" parameter to authorize issuance unless the URI specified is an URI that the CA recognises as identifying the account making a certificate issuance request. This might be easier to read, though is actually slightly longer: Where a CAA property has an "account-uri" parameter, a CA MUST NOT consider that property to authorize issuance in the context of a given certificate issuance request unless the CA recognises the URI specified as identifying the account making that request. From nobody Tue Jun 20 05:10:53 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5CC12EA42 for ; Tue, 20 Jun 2017 05:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 556nxMgm3lCV for ; Tue, 20 Jun 2017 05:10:50 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 575D1129C71 for ; Tue, 20 Jun 2017 05:08:59 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5KC88hi031229; Tue, 20 Jun 2017 13:08:55 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=YtQU8h9Jg3ufV1jyR1MDfCJgax3TuaFoJ0DgYrnbNgA=; b=TVNZyMN13W+ArYWnvw+QesiO498yYT2SJ+r2HTy31w3nEPEnMpaF3ogIduvWIHPOWHkE RiZFP6pUbCEVL0exT5DAsZ12b4ZyBfGo+vqeR/vH99GJ+H1qlWu9mhcJxjlwvPwMe6jh jT1tNvN19sFGsNIv67mJfjKHePYJ3gZQvgCQiWGi4dHU0F/28srlpdWDhso7F6hasivI 4/Q1ykUNiiWfig+EZKbxSABPK03pBkbqhdkPXVWqc1JyldeNAujlQmyB+hqXP9h3hjeI WG1ClVH4OZMrRpW48S5pBjIdqmrK1Z1C4uosFi3Klw3knHjMsJQ5yRQ9w7D9rmBZccDj ZQ== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2b6gbq5rv9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Jun 2017 13:08:55 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5KC67gC020430; Tue, 20 Jun 2017 08:08:55 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2b4yruja27-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 20 Jun 2017 08:08:55 -0400 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.1263.5; Tue, 20 Jun 2017 08:08:54 -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.1263.000; Tue, 20 Jun 2017 08:08:54 -0400 From: "Salz, Rich" To: Hugo Landau CC: "acme@ietf.org" Thread-Topic: [Acme] Before entering WGLC ... Thread-Index: AdLmnPm9U5O+8VQ1RlutqFMR3rfl7gA/yJgAAAhbzoAAHWSlgAACj8WwABvAdYAAI1oSgAAIG+UgAB9LAIAABl6QcA== Date: Tue, 20 Jun 2017 12:08:53 +0000 Message-ID: References: <5997299eae9a4ca7bbd8f3798c5db6cd@usma1ex-dag1mb1.msg.corp.akamai.com> <20170617150121.GA2175@andover.lhh.devever.net> <5e52c9cbec7843cd8ab2117ee06c24e7@usma1ex-dag1mb1.msg.corp.akamai.com> <20170618090219.GA28902@andover.lhh.devever.net> <20170619162231.GA20324@andover.lhh.devever.net> <9016cef38c404a5e85984763a9270449@usma1ex-dag1mb1.msg.corp.akamai.com> <20170620111042.GA13184@andover.lhh.devever.net> In-Reply-To: <20170620111042.GA13184@andover.lhh.devever.net> 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.44.30] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-20_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706200217 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-20_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706200217 Archived-At: Subject: Re: [Acme] Before entering WGLC ... X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 12:10:52 -0000 > This might be easier to read, though is actually slightly longer: > Where a CAA property has an "account-uri" parameter, a CA MUST NOT > consider that property to authorize issuance in the context of a given > certificate issuance request unless the CA recognises the URI > specified as identifying the account making that request. I like this. Martin and Russ, your views? From nobody Tue Jun 20 14:42:58 2017 Return-Path: X-Original-To: acme@ietf.org Delivered-To: acme@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87328127137; Tue, 20 Jun 2017 14:42:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: acme@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149799497537.29695.10478655189209733956@ietfa.amsl.com> Date: Tue, 20 Jun 2017 14:42:55 -0700 Archived-At: Subject: [Acme] I-D Action: draft-ietf-acme-service-provider-00.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 21:42:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Automated Certificate Management Environment of the IETF. Title : ACME Identifiers and Challenges for VoIP Service Providers Authors : Mary Barnes Chris Wendt Filename : draft-ietf-acme-service-provider-00.txt Pages : 8 Date : 2017-06-20 Abstract: This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for VoIP service providers to support Secure Telephony Identity (STI). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-acme-service-provider/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-acme-service-provider-00 https://datatracker.ietf.org/doc/html/draft-ietf-acme-service-provider-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 20 15:07:16 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F20131650 for ; Tue, 20 Jun 2017 15:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 TXaY8jBiK6ZI for ; Tue, 20 Jun 2017 15:07:09 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D0B2127B52 for ; Tue, 20 Jun 2017 15:07:09 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5KM74lU028414; Tue, 20 Jun 2017 23:07:07 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=E8+xQ10tbxEaX7j0oZh7Jx0v1PqmbPz2vjOhAq0YOMg=; b=N8csiWNjrJ4l5MNDFGL6PCQODDLxMumdaiXTlkX8S4exzwwCu9+mH4vx1a+xV/Gr29Dt 3ITyzsQfzGOC85E8Ru+tVKG4yqmtUmDHE0hzPqo0LyV6R6GEip9vQlOyLkmWeoNBeGT7 QVJlXkqatC4qumIF+SuJvAqXOjvQBAU2pwm/f05Pkh8+4NveptaDr3b97pnYMpd4XUgN WX3tvdhGN7sjDaM+m3ERrQjiWYg5abLJYyWrSpWN1jDwK/qDZFfnxV1L3P65Ns7fg1M6 t9nPHELI/jgPXmndlKxANmYNIDVdY4abcaiSq/0rXuKjJiWzncBRvMAXn6SAr0JTZ0X5 EA== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050102.ppops.net-00190b01. with ESMTP id 2b79ad91a0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Jun 2017 23:07:06 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5KM5iTD026120; Tue, 20 Jun 2017 18:07:06 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.31]) by prod-mail-ppoint4.akamai.com with ESMTP id 2b4yrv0rg9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 20 Jun 2017 18:07:06 -0400 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 20 Jun 2017 17:07:05 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1263.000; Tue, 20 Jun 2017 17:07:05 -0500 From: "Dunning, John" To: Ilari Liusvaara , Richard Barnes CC: "Salz, Rich" , "acme@ietf.org" Thread-Topic: [Acme] Rolling keys and pending validations Thread-Index: AdLpJhpoh06PBTCkQemxb0Jtd47K7AALod+AAABWIYAAMPz4AA== Date: Tue, 20 Jun 2017 22:07:04 +0000 Message-ID: References: <0896b144e7e942b1ac68db9ead4c42bb@usma1ex-dag1mb1.msg.corp.akamai.com> <20170619184423.wtpj2qtq6awk3rju@LK-Perkele-VII> In-Reply-To: <20170619184423.wtpj2qtq6awk3rju@LK-Perkele-VII> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.113.15] Content-Type: text/plain; charset="utf-8" Content-ID: <8A73AD87D3610C4691EE01B41B4B0101@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-20_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706200382 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-20_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706200382 Archived-At: Subject: Re: [Acme] Rolling keys and pending validations X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 22:07:11 -0000 SSB3b3VsZCBhZHZvY2F0ZSBmb3IgdGhlIG5ldyBvbmUuICBJT1csIEkgd291bGQgKGV4cGVjdCB0 bykgaW50ZXJwcmV0IHRoZSBzZW1hbnRpY3MgYXMgYmVpbmcNCg0KMS4gVGhlIGNoYWxsZW5nZSB0 b2tlbiB3YXMgY3JlYXRlZCB3aXRoIHJlc3BlY3QgdG8gYW4gYWNjb3VudA0KMi4gQW4gYXR0cmli dXRlIG9mIHRoZSBhY2NvdW50IGlzIHRoZSBjcmVkZW50aWFsICh3aGljaGV2ZXIgY3JlZGVudGlh bCBpcyBjdXJyZW50KQ0KMy4gVGhlcmVmb3JlIHRoZSBjcmVkZW50aWFsIGF1dGhvcml6ZXMgYWNj ZXNzIHRvIGFueXRoaW5nIGFzc29jaWF0ZWQgd2l0aCB0aGUgYWNjb3VudC4NCg0KSWYgdGhlIGNv bmNlbnN1cyBoZXJlIGlzIHRoYXQgYSBzZXJ2ZXIgbmVlZHMgdG8gYXNzb2NpYXRlIHRoZSBjcmVk ZW50aWFsIHdoaWNoIHdhcyBpbiBmb3JjZSBhdCBjcmVhdGlvbiB0aW1lIHdpdGggYSBjaGFsbGVu Z2UgdG9rZW4sIGluIG90aGVyIHdvcmRzIHRoYXQgdGhlIHRva2VuIGlzIHRpZWQgdG8gdGhlIGNy ZWRlbnRpYWwgcmF0aGVyIHRoYW4gdGhlIGFjY291bnQsIEkgYmVsaWV2ZSBteSB1c2UgY2FzZSB3 b3VsZCBiZSBvayB3aXRoIHRoYXQsIGFzIGxvbmcgYXMgdGhlIGNoYWxsZW5nZSB0b2tlbnMgZG8g bm90IGdvIGludmFsaWQgYWZ0ZXIgdGhlIGNyZWRlbnRpYWwgY2hhbmdlLg0KDQpJIHdvdWxkIGV4 cGVjdCB0aGF0IGxhdHRlciBzZW1hbnRpY3Mgd291bGQgYmUgaGFpcmllciBmb3Igc2VydmVyIGlt cGxlbWVudG9ycywgYmVjYXVzZSB0aGV54oCZZCBuZWVkIHRvIGtlZXAgbXVsdGlwbGUgY3JlZGVu dGlhbHMgYWxpdmUgYW5kIGFzc29jaWF0ZWQgd2l0aCB0aGUgYWNjb3VudCBmb3IgdGhlIG1heGlt dW0gbGlmZXRpbWUgb2YgYW55IGV4dGFudCB0b2tlbnMuDQoNCg0KT24gNi8xOS8xNywgMjo0NCBQ TSwgIklsYXJpIExpdXN2YWFyYSIgPGlsYXJpbGl1c3ZhYXJhQHdlbGhvLmNvbT4gd3JvdGU6DQoN CiAgICBPbiBNb24sIEp1biAxOSwgMjAxNyBhdCAwMjozNDo0NVBNIC0wNDAwLCBSaWNoYXJkIEJh cm5lcyB3cm90ZToNCiAgICA+IFRoaXMgc2VlbXMgc2Vuc2libGU7IHJvbGxpbmcga2V5cyBzaG91 bGRuJ3QgaW52YWxpZGF0ZSB0aGluZ3MgaW4gdHJhbnNpdA0KICAgID4gYW55IG1vcmUgdGhhbiBj aGFuZ2luZyB5b3VyIEdtYWlsIHBhc3N3b3JkIHNob3VsZCBkZWxldGUgeW91ciBkcmFmdHMgZm9s ZGVyLg0KICAgID4gDQogICAgPiBJIHdvdWxkIGhhdmUgYSBsaXR0bGUgYml0IG9mIGEgaGFyZCB0 aW1lIGNhbGxpbmcgdGhpcyAicHVyZWx5IGVkaXRvcmlhbCIsDQogICAgPiBzaW5jZSBpdCBzcGVj aWZpZXMgc2VydmVyIGJlaGF2aW9yLiAgQnV0IGl0IHNlZW1zIGxpa2UgeW91J3JlIGp1c3QNCiAg ICA+IGNvZGlmeWluZyBhbiBleHBlY3RhdGlvbiB0aGF0IGF0IGxlYXN0IEkgYWxyZWFkeSBoYWQg KFRCSCwgSSB3b3VsZCBub3QgaGF2ZQ0KICAgID4gdGhvdWdodCB0byBidWlsZCBhIHNlcnZlciBv dGhlcndpc2UpLCBzbyBJIHdvdWxkIGJlIGluY2xpbmVkIHRvIGdvIGFoZWFkDQogICAgPiBhbmQg bWVyZ2UgaXQgaWYgYXQgbGVhc3Qgb25lIG9yIHR3byBvdGhlciBwZW9wbGUgY2hpbWUgaW4uDQog ICAgPiANCiAgICA+IEhlcmUncyBhIFBSOiAgaHR0cHM6Ly9naXRodWIuY29tL2lldGYtd2ctYWNt ZS9hY21lL3B1bGwvMzIzDQogICAgDQogICAgSWYgdGhlcmUgaXMgcGVuZGluZyB2YWxpZGF0aW9u IG92ZXIga2V5IGNoYW5nZSwgd2hpY2gga2V5IGhhc2ggc2hvdWxkDQogICAgdGhlIHZhbGlkYXRp b24gdXNlIHdoZW4gaXQgaXMgcmVzb2x2ZWQ/IFRoZSBvbGQgb25lPyBUaGUgbmV3IG9uZT8NCiAg ICANCiAgICANCiAgICAtSWxhcmkNCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KICAgIEFjbWUgbWFpbGluZyBsaXN0DQogICAgQWNtZUBp ZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWNtZQ0K ICAgIA0KDQo= From nobody Tue Jun 20 22:10:37 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3011B124BE8 for ; Tue, 20 Jun 2017 22:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wPm8pMBmUQW for ; Tue, 20 Jun 2017 22:10:34 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 356FD1243F3 for ; Tue, 20 Jun 2017 22:10:34 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id h22so6768536lfk.3 for ; Tue, 20 Jun 2017 22:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=d7d1IZjs+M68uSHME5G+10B6tbvTaXzo5C5mg3EKEaE=; b=kjqsa/DfuPKXgZPh0UljkFUrOiiYk6FoAZn/eGyshCVMSa8ROE+7QOlzMErMrKHNxR K6zNkFjGFyn21UoSVMnuuiUgwhHU8guTPhHUc8VaQDpgbGqYWjxnUjEtUylkuzrOgqtJ wYm99yijO5xaMJU6IY0Wj+f0aGXeOK7IjQGfa1irseUi4fv6vvzGIZQybW+2j0Uts2Nj dbyau2SOVcOQMt//O2kzdTTQI7ew4sEVyyyxf52naCUz5UdsJrPApYQU+pUYJOss3pw/ TU2sRVY5QmveUnTzcexJbrSwG7iC9GMZSc+ksi8rgrYc52bHlf1mkCPbBXbtB/CCe+OX DS5Q== 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=d7d1IZjs+M68uSHME5G+10B6tbvTaXzo5C5mg3EKEaE=; b=Ez38WyWsHNRsxNDOW8O8SKZLPEAvEXQkmVjQ7xeAn5seEJyXf8wbPlFkTE3yjzTrdB 6vTzILg9xOKZaAw/Q75YlLsb6vxxuLABRRoNTjW0+i4ec45vu+U+QJec5WJsUNAXzOMu ms1GmKYv22pibqyhZxVhj6986BRIiFk56s+/bVTh37/AgQsB6BXGYlkOg0izkcPsTaiC aBhjXu6wE1PIp1LHQLo2UjdmcZ3qDZTnSWavdl06u/7l9LU3t1KOwBHOh3aw7DS1yer0 /L2GNlZMsuMjPp1zr1QLUVTnBTmV1RMwKJ8jXUe0ZI0NIFjabG/YAx+0EEClbuSXCaZa d0IA== X-Gm-Message-State: AKS2vOymjQudlsVTSJab1WajsNMISEEYOo3VczMMicbs70L6W+8M6b85 yEzBkGljJ+dUAcQJF865a5oAiWHY78JJ X-Received: by 10.25.166.15 with SMTP id p15mr9340277lfe.43.1498021832515; Tue, 20 Jun 2017 22:10:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Tue, 20 Jun 2017 22:10:31 -0700 (PDT) In-Reply-To: References: <5997299eae9a4ca7bbd8f3798c5db6cd@usma1ex-dag1mb1.msg.corp.akamai.com> <20170617150121.GA2175@andover.lhh.devever.net> <5e52c9cbec7843cd8ab2117ee06c24e7@usma1ex-dag1mb1.msg.corp.akamai.com> <20170618090219.GA28902@andover.lhh.devever.net> <20170619162231.GA20324@andover.lhh.devever.net> <9016cef38c404a5e85984763a9270449@usma1ex-dag1mb1.msg.corp.akamai.com> <20170620111042.GA13184@andover.lhh.devever.net> From: Martin Thomson Date: Wed, 21 Jun 2017 15:10:31 +1000 Message-ID: To: "Salz, Rich" Cc: Hugo Landau , "acme@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Acme] Before entering WGLC ... X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 05:10:36 -0000 On 20 June 2017 at 22:08, Salz, Rich wrote: >> Where a CAA property has an "account-uri" parameter, a CA MUST NOT >> consider that property to authorize issuance in the context of a given >> certificate issuance request unless the CA recognises the URI >> specified as identifying the account making that request. > > I like this. Martin and Russ, your views? It's an improvement, certainly. For brevity I would say: "unless the account URI corresponds to the account making that request." There are many specification pitfalls here regarding how you might compare URIs, but this neatly avoids those and leaves the authority for that space (the CA) in the position where it performs the comparison. From nobody Wed Jun 21 04:55:35 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E8512945D for ; Wed, 21 Jun 2017 04:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 hzeB7fTJkPB6 for ; Wed, 21 Jun 2017 04:55:31 -0700 (PDT) Received: from office.denic.de (office.denic.de [81.91.160.182]) (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 19492127337 for ; Wed, 21 Jun 2017 04:55:27 -0700 (PDT) To: acme@ietf.org MIME-Version: 1.0 X-KeepSent: A01B96CE:B7B3FA27-C1258146:0041283E; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0.1FP6 Octobe4, 2013 From: Marcos Sanz Message-ID: Date: Wed, 21 Jun 2017 13:54:50 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 21.06.2017 13:54:51, Serialize complete at 21.06.2017 13:54:51 Content-Type: text/plain; charset="US-ASCII" Archived-At: Subject: [Acme] Fw: acme-06: Yet more editorial issues plus one real protocol thing X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 11:55:34 -0000 I've created PRs for all editorial comments and opened Issue 325 for the HTTP method usage: https://github.com/ietf-wg-acme/acme/issues/325 Again, I'd be thankful for a pointer if this topic was already dealt with. Best, Marcos ----- Weitergeleitet von Marcos Sanz/Denic am 21/06/2017 13:51 ----- Marcos Sanz/Denic wrote on 02/06/2017 12:35:46: > Von: Marcos Sanz/Denic > An: acme@ietf.org > Datum: 02/06/2017 12:35 > Betreff: acme-06: Yet more editorial issues plus one real protocol thing > > Dear all, > > please allow a couple of comments from a person who reads the draft for the first time: > > 1) Structural comment: It is a bit confusing that something like, for instance, chapter "7.3.4 Account Deactivation" is logically > ordered under "7.3 Account Creation". > Suggestion: Chapter 7.3 should be renamed from "Account Creation" to "Account Administration" and then there should be a new "7.3. > 1 Account Creation". > > 2) The challenge object in the example of section 7.1.4 is of type http. It is missing the mandatory fields "url" and "token". > > 3) Section 7.5.1 says > > "For example, if the client were to respond to the "http-01" challenge in the above authorization, it would send the following request: > POST /acme/authz/asdf/0" > > However the URI of the refered authorization was /acme/authz/1234/0. As a matter of fact, it looks to me like all six "authz/asdf" > occurrences in the draft should be "authz/1234" instead... > > 4) The example in section 8.2 > > GET .well-known/acme-challenge/evaGxfADs6pSRb2LAv9IZf17 > Host: example.com > > should be directed to the Host "example.org" which is the domain to be validated, not to "example.com" which is the acme server. > And then the body of the response > > HTTP/1.1 200 OK > LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9fm21mqTI > > looks strange to me. It should match the key authorization, which should start with the token "evaGxfADs6pSRb2LAv9IZf17", and not "Loq..." > > 5) The text in section 8.4 > > "For example, if the domain name being validated is "example.com", then the client would provision the following DNS record: > acme-challenge.example.com. 300 IN TXT "gfj9Xq...Rg85nM" > > would better use "example.org" for the same reasons explained above. > > 6) To make acme a real "REST application" and not just a REST-buzzword freerider, the PUT method should be used consistently for > the update of existing resources. For instance, where in 7.5.1 the client "updates back to the server" the details of an existing > resource (the challenge) via > > POST /acme/authz/asdf/0 HTTP/1.1 > > , it should use instead > > PUT /acme/authz/asdf/0 HTTP/1.1 > > Has the latter been discussed before by the working group? Sorry if so, then I'd be thankful for a pointer. > > Best, > Marcos From nobody Wed Jun 21 09:30:48 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21EBF12EB37 for ; Wed, 21 Jun 2017 09:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 ccfH5ReODNmQ for ; Wed, 21 Jun 2017 09:30:42 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::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 1576E1286B1 for ; Wed, 21 Jun 2017 09:30:42 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id y25so102727294wrd.2 for ; Wed, 21 Jun 2017 09:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZV52hhPezxOlvnQvl+sUiutp0LgfrW87EvwRgpwzf6U=; b=pY3FymcRUUIT+9NMlktwYn5h4zL7DQw2ijHLhpk9oU/bMK3IXB6iJOKw8N5osypWhh Ph3VPjf2KUWDf0rXWSfCR8PvUDTKfCzHw0KNcv9GtDg5IMCqLpt0Tc4RWCLz+KolVb3L BRJOLmTRPo5kW4bfV0Y0D7jh8p6Hqig7TmkLEKiREfnHRSgb38rKfgJTO49wcgqFIFFt Zc+cgZLCyff3EGqAqD+XekHa4zoni3z20AA7TPjN3MQdVmP33eRSgqgEVP/7vqKhKUmS 7Ja5kqjkc9MFfsozYksQ6RSSufE6bLRI4MnmspErpzB9aqiibyKWX0RZvaYGpGqZSAim BTMw== 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=ZV52hhPezxOlvnQvl+sUiutp0LgfrW87EvwRgpwzf6U=; b=NVfzJubue3oLapDz+vYurfsFMuij0qsXFoL6Evkxhh4edXIFeyLvn3epDgcx8ihTHL eu7YBfmDoUUv57HTVGWxZaMux8qEXvRzZskBw0qF2RZfuXceMSKCCYk6Alj14ZLvRvD8 jMou6isUZCcLaOLvfB6A7ZlSTzZsUBGDRfcYsQPlUdbBC4heTLdeoP9XEUEYvbrgt0GY qmA6ZWihDH4mqMd5SW239ceuFXdSSP8lzbtymmef7l0II9/xd4rDQPffuSkVIf3Ridwp xMQrdHviD5kWZcBhoGpL8HAWF6lgTKhFZUiURzJllXOIR+2aK4hl47nR5ox0pFvdMNUT H57A== X-Gm-Message-State: AKS2vOwOO/knxncnbTXOVoZ7CC2IDCL801s/dW/IBIYixWNfQXtG2GtN uY9y0nHCDP0MPD6tIQTrUlzXCrzK+u4N X-Received: by 10.223.142.143 with SMTP id q15mr20594319wrb.180.1498062640305; Wed, 21 Jun 2017 09:30:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.109.16 with HTTP; Wed, 21 Jun 2017 09:30:39 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Wed, 21 Jun 2017 12:30:39 -0400 Message-ID: To: Eric Rescorla Cc: Martin Thomson , "acme@ietf.org" Content-Type: multipart/alternative; boundary="f403045f517c87609305527ae353" Archived-At: Subject: Re: [Acme] v2 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 16:30:45 -0000 --f403045f517c87609305527ae353 Content-Type: text/plain; charset="UTF-8" OK, I'm not hearing any real enthusiasm for this idea (except from Daniel). So I'm going to close the PR. On Wed, Jun 14, 2017 at 6:39 PM, Richard Barnes wrote: > For some context: https://letsencrypt.org/2017/06/14/acme-v2-api.html > > To be clear about my opinion here: I'm not super enthusiastic about v2; I > think we can muddle through the transition just fine. But if people feel > strongly that it would help to have a clear version (there's not even a > "v1" notation right now), that would be OK with me. > > On Wed, Jun 14, 2017 at 4:49 AM, Eric Rescorla wrote: > >> I agree with MT here. We should just name it v1. That's what IETF change >> control means >> >> On Tue, Jun 13, 2017 at 5:54 PM, Martin Thomson > > wrote: >> >>> I don't see the distinction between what LE deploy and ACME as defined >>> by the IETF being any different to the distinction between whatever >>> any other CA currently deploy and the IETF spec. It's a thing that >>> exists, but I see no reason to accord the LE proprietary protocol any >>> special status other than by acknowledging provenance. >>> >>> This is the IETF version of ACME, and as such it needs no version >>> qualification. I doubt that there will be any confusion from this >>> being deployed alongside the proprietary LE protocol. >>> >>> On 13 June 2017 at 16:26, Richard Barnes wrote: >>> > (Everyone get your bike shed paint out....) >>> > >>> > In talking with a few folks around the community, I've heard people >>> refer to >>> > the IETF version of ACME as "v2", where implicitly "v1" is the initial >>> > version deployed by Let's Encrypt and its clients right now. >>> > >>> > How would people feel about reflecting this in the draft / RFC? I've >>> posted >>> > a PR with the changes this would entail: >>> > >>> > https://github.com/ietf-wg-acme/acme/pull/321 >>> > >>> > The only question this raises for me is what to do about v1. Given >>> that >>> > Let's Encrypt has evolved their interface some since the first >>> version, I'm >>> > not sure there's one consolidated spec out there for what they >>> currently >>> > have deployed. So while it would be nice to have a reference to v1 in >>> this >>> > document if we make it v2, I'm not inclined to worry about it too >>> much. I'm >>> > willing to leave it up to the LE folks if they want to submit a v1 >>> later for >>> > historical purposes. >>> > >>> > Any objections to merging the above PR? >>> > >>> > --Richard >>> > >>> > >>> > _______________________________________________ >>> > Acme mailing list >>> > Acme@ietf.org >>> > https://www.ietf.org/mailman/listinfo/acme >>> > >>> >>> _______________________________________________ >>> Acme mailing list >>> Acme@ietf.org >>> https://www.ietf.org/mailman/listinfo/acme >>> >> >> > --f403045f517c87609305527ae353 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, I'm not hearing any real enthusiasm for this idea = (except from Daniel).=C2=A0 So I'm going to close the PR.

On Wed, Jun 14, 2017 = at 6:39 PM, Richard Barnes <rlb@ipv.sx> wrote:

To = be clear about my opinion here: I'm not super enthusiastic about v2; I = think we can muddle through the transition just fine.=C2=A0 But if people f= eel strongly that it would help to have a clear version (there's not ev= en a "v1" notation right now), that would be OK with me.
<= br>
On Wed, Jun 14, 2017 at 4:49 AM, Eric Rescorl= a <e= kr@rtfm.com> wrote:
I agree with MT here. We should just name it v1. That's what = IETF change control means
=

On Tue, Jun 13, 2017 at 5:54 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
I don't see the distinction between what LE deploy and ACME = as defined
by the IETF being any different to the distinction between whatever
any other CA currently deploy and the IETF spec.=C2=A0 It's a thing tha= t
exists, but I see no reason to accord the LE proprietary protocol any
special status other than by acknowledging provenance.

This is the IETF version of ACME, and as such it needs no version
qualification.=C2=A0 I doubt that there will be any confusion from this
being deployed alongside the proprietary LE protocol.

On 13 June 2017 at 16:26, Richard Barnes <rlb@ipv.sx> wrote:
> (Everyone get your bike shed paint out....)
>
> In talking with a few folks around the community, I've heard peopl= e refer to
> the IETF version of ACME as "v2", where implicitly "v1&= quot; is the initial
> version deployed by Let's Encrypt and its clients right now.
>
> How would people feel about reflecting this in the draft / RFC?=C2=A0 = I've posted
> a PR with the changes this would entail:
>
> https://github.com/ietf-wg-acme/acme/pull/321=
>
> The only question this raises for me is what to do about v1.=C2=A0 Giv= en that
> Let's Encrypt has evolved their interface some since the first ver= sion, I'm
> not sure there's one consolidated spec out there for what they cur= rently
> have deployed.=C2=A0 So while it would be nice to have a reference to = v1 in this
> document if we make it v2, I'm not inclined to worry about it too = much.=C2=A0 I'm
> willing to leave it up to the LE folks if they want to submit a v1 lat= er for
> historical purposes.
>
> Any objections to merging the above PR?
>
> --Richard
>
>
> _______= ________________________________________
> Acme mailing list
> Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme



--f403045f517c87609305527ae353-- From nobody Wed Jun 21 09:36:39 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5035B128616 for ; Wed, 21 Jun 2017 09:36:37 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 c-m9Hz7icpWN for ; Wed, 21 Jun 2017 09:36:34 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::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 48C9712717E for ; Wed, 21 Jun 2017 09:36:34 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id 77so142155423wrb.1 for ; Wed, 21 Jun 2017 09:36:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+ihFZYHhsTTYn10fo5/2G+t6mf6i7LXUJqP7IQzpNxI=; b=1wSa9xguF123KuWKGH6A5la/FauKAsW5GYBWcBwnwEGPK6x6zpJMrcq2gLgglUO+cu 9WthuZHfGV7/DPE7CGzR6pWGKk2jQLzKurDcgGgsKvg6fbgp1BDY+Ls3nFItsyS9zpI/ XVqfzjM/fTWEKvpqz8DHYsCJ4NdUkSsquw4rxIW0AYWEYJp+icWSolob53KhK7QMEZnu cPF+DL5v1rxQlUeKbxbKgwWKyEDuJrAkHv3v6/MBfwseG3dyX/Oo/1ex0fk3MzwzXnhw 1K0UbhyE5JGTDRzwKjYGYTFlR4BE2ltWB8U1Hvf3I5gh7PqIb/w1TVyZQ+mxjXC0w01N jy9Q== 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=+ihFZYHhsTTYn10fo5/2G+t6mf6i7LXUJqP7IQzpNxI=; b=QmqPKHj/cCIwjOOCPGkI3Tw7c74j/BhBK0maR1ehB0yVf37EWV6xsIsyhpCaJ+IGgA w0puK7KG1JHouvxzHGI7xjYhoHJBhhoQWM5L/QlJmNcC2Qii30ygG8/ZXgfI6LzAxtd+ 0oC6gCrx5nynnKq0Sz1hW/R/6ce9Spq3OQ+gWuQjMhX1VuSKhbkSyCAjwfopLTReY9Or AkcT3PhLwsemxoLEVv4to+P0w9kzfrDuD9qHBnlgqri7UWjcjaziXvhvnipjg4FSdZOW Ew8XCDiRkSR4Q3l4zFBH+aLFXsS7o93SnIvwGX6K18seq91xkvWDqCjKPkHoj197NTEm FM3w== X-Gm-Message-State: AKS2vOxgSw0mIq5hFK7Irbhy5JuE+eEhWpUvprN0wt7Mt+bXnIj4THq7 CxNwDvRXlYpFZrvX8wlRUJcQphpBXl5Y X-Received: by 10.28.24.213 with SMTP id 204mr7628161wmy.15.1498062992679; Wed, 21 Jun 2017 09:36:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.109.16 with HTTP; Wed, 21 Jun 2017 09:36:32 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Wed, 21 Jun 2017 12:36:32 -0400 Message-ID: To: Marcos Sanz Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a11471528880a1905527af8b5" Archived-At: Subject: Re: [Acme] Fw: acme-06: Yet more editorial issues plus one real protocol thing X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 16:36:37 -0000 --001a11471528880a1905527af8b5 Content-Type: text/plain; charset="UTF-8" Thanks for the PRs. I merged them. I don't think that PUT is appropriate for really any requests that ACME uses. Quoth RFC 7231: """ The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload. """ None of the requests that ACME uses fully replace the state of the resource in question. In all cases, the client provides some additional information, which the server incorporates into the resource. --Richard On Wed, Jun 21, 2017 at 7:54 AM, Marcos Sanz wrote: > I've created PRs for all editorial comments and opened Issue 325 for the > HTTP method usage: > https://github.com/ietf-wg-acme/acme/issues/325 > > Again, I'd be thankful for a pointer if this topic was already dealt with. > > Best, > Marcos > > ----- Weitergeleitet von Marcos Sanz/Denic am 21/06/2017 13:51 ----- > > Marcos Sanz/Denic wrote on 02/06/2017 12:35:46: > > > Von: Marcos Sanz/Denic > > An: acme@ietf.org > > Datum: 02/06/2017 12:35 > > Betreff: acme-06: Yet more editorial issues plus one real protocol thing > > > > Dear all, > > > > please allow a couple of comments from a person who reads the draft for > the first time: > > > > 1) Structural comment: It is a bit confusing that something like, for > instance, chapter "7.3.4 Account Deactivation" is logically > > ordered under "7.3 Account Creation". > > Suggestion: Chapter 7.3 should be renamed from "Account Creation" to > "Account Administration" and then there should be a new "7.3. > > 1 Account Creation". > > > > 2) The challenge object in the example of section 7.1.4 is of type http. > It is missing the mandatory fields "url" and "token". > > > > 3) Section 7.5.1 says > > > > "For example, if the client were to respond to the "http-01" challenge > in the above authorization, it would send the following request: > > POST /acme/authz/asdf/0" > > > > However the URI of the refered authorization was /acme/authz/1234/0. As > a matter of fact, it looks to me like all six "authz/asdf" > > occurrences in the draft should be "authz/1234" instead... > > > > 4) The example in section 8.2 > > > > GET .well-known/acme-challenge/evaGxfADs6pSRb2LAv9IZf17 > > Host: example.com > > > > should be directed to the Host "example.org" which is the domain to be > validated, not to "example.com" which is the acme server. > > And then the body of the response > > > > HTTP/1.1 200 OK > > > LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0.9jg46WB3rR_AHD- > EBXdN7cBkH1WOu0tA3M9fm21mqTI > > > > looks strange to me. It should match the key authorization, which should > start with the token "evaGxfADs6pSRb2LAv9IZf17", and not "Loq..." > > > > 5) The text in section 8.4 > > > > "For example, if the domain name being validated is "example.com", then > the client would provision the following DNS record: > > acme-challenge.example.com. 300 IN TXT "gfj9Xq...Rg85nM" > > > > would better use "example.org" for the same reasons explained above. > > > > 6) To make acme a real "REST application" and not just a REST-buzzword > freerider, the PUT method should be used consistently for > > the update of existing resources. For instance, where in 7.5.1 the > client "updates back to the server" the details of an existing > > resource (the challenge) via > > > > POST /acme/authz/asdf/0 HTTP/1.1 > > > > , it should use instead > > > > PUT /acme/authz/asdf/0 HTTP/1.1 > > > > Has the latter been discussed before by the working group? Sorry if so, > then I'd be thankful for a pointer. > > > > Best, > > Marcos > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a11471528880a1905527af8b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the PRs.=C2=A0 I merged them.
I don't think that PUT is appropriate for really any reque= sts that ACME uses.=C2=A0 Quoth RFC 7231:

"&q= uot;"
=C2=A0=C2=A0 The PUT method requests that the state of the ta= rget resource be
=C2=A0=C2=A0 created or replaced with the state defined= by the representation
=C2=A0=C2=A0 enclosed in the request message payl= oad.
"""

None of the = requests that ACME uses fully replace the state of the resource in question= .=C2=A0 In all cases, the client provides some additional information, whic= h the server incorporates into the resource.

--Ric= hard


On Wed, Jun 21, 2017 at 7:54 AM, Marcos Sanz <sanz@denic.de<= /a>> wrote:
I've created PR= s for all editorial comments and opened Issue 325 for the
HTTP method usage:
https://github.com/ietf-wg-acme/acme/issues/325<= /a>

Again, I'd be thankful for a pointer if this topic was already dealt wi= th.

Best,
Marcos

----- Weitergeleitet von Marcos Sanz/Denic am 21/06/2017 13:51 -----

Marcos Sanz/Denic wrote on 02/06/2017 12:35:46:

> Von: Marcos Sanz/Denic
> An: acme@ietf.org
> Datum: 02/06/2017 12:35
> Betreff: acme-06: Yet more editorial issues plus one real protocol thi= ng
>
> Dear all,
>
> please allow a couple of comments from a person who reads the draft fo= r
the first time:
>
> 1) Structural comment: It is a bit confusing that something like, for<= br> instance, chapter "7.3.4 Account Deactivation" is logically
> ordered under "7.3 Account Creation".
> Suggestion: Chapter 7.3 should be renamed from "Account Creation&= quot; to
"Account Administration" and then there should be a new "7.3= .
> 1 Account Creation".
>
> 2) The challenge object in the example of section 7.1.4 is of type htt= p.
It is missing the mandatory fields "url" and "token". >
> 3) Section 7.5.1 says
>
> "For example, if the client were to respond to the "http-01&= quot; challenge
in the above authorization, it would send the following request:
>=C2=A0 =C2=A0 POST /acme/authz/asdf/0"
>
> However the URI of the refered authorization was /acme/authz/1234/0. A= s
a matter of fact, it looks to me like all six "authz/asdf"
> occurrences in the draft should be "authz/1234" instead... >
> 4) The example in section 8.2
>
> GET .well-known/acme-challenge/evaGxfADs6pSRb2LAv9IZf17
> Host: example.com
>
> should be directed to the Host "example.org" which is the domai= n to be
validated, not to "example.com" which is the acme server.
> And then the body of the response
>
> HTTP/1.1 200 OK
>
LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0.9jg46WB3rR_AHD-EBXdN7= cBkH1WOu0tA3M9fm21mqTI
>
> looks strange to me. It should match the key authorization, which shou= ld
start with the token "evaGxfADs6pSRb2LAv9IZf17", and not "Lo= q..."
>
> 5) The text in section 8.4
>
> "For example, if the domain name being validated is "example.com", then
the client would provision the following DNS record:
> acme-challenge.example.com. 300 IN TXT "gfj9Xq...Rg85= nM"
>
> would better use "example.org" for the same reasons explained a= bove.
>
> 6) To make acme a real "REST application" and not just a RES= T-buzzword
freerider, the PUT method should be used consistently for
> the update of existing resources. For instance, where in 7.5.1 the
client "updates back to the server" the details of an existing > resource (the challenge) via
>
> POST /acme/authz/asdf/0 HTTP/1.1
>
> , it should use instead
>
> PUT /acme/authz/asdf/0 HTTP/1.1
>
> Has the latter been discussed before by the working group? Sorry if so= ,
then I'd be thankful for a pointer.
>
> Best,
> Marcos

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

--001a11471528880a1905527af8b5-- From nobody Wed Jun 21 09:39:48 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA9112EBE6 for ; Wed, 21 Jun 2017 09:39:46 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 x007SDX12peX for ; Wed, 21 Jun 2017 09:39:44 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 A937F12EBD3 for ; Wed, 21 Jun 2017 09:39:43 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id r103so142260406wrb.0 for ; Wed, 21 Jun 2017 09:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=niG7/j1pcAF4Epxj1YxwvHzB16X0vp57Qem2dMHvNM8=; b=PM9jiN2HcihRwjegjuqDDc6sc2YR18oWKUdyxTbtf/7wR457ce2Jha3yfc1tYMCvif hK0KZTyTP+4iFRI5eRAqKXS+zTBAFpt//oIY6xKUSF04+DZGkzW7Hd4N4muZJ4DwHjMf Dkm1v9slwZFm/qa2JvM7RJNztRYiPDW9jDxye7jZ+HBZEalT7U5hg5H5LZk4XxJ59osO zzMN7S9D3EK54qXgHEopy1ExJdAp+DXZxRoOCrWG3wyI5c75AJ6wQrMYuzZ0WKpjKreW 8QdtiZFbdtEr8YRh01Y3qaIk18+sBnQrtzuSOFA7zAFgHCt3uRd+0wP5bFMNViunalbH y4Hw== 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=niG7/j1pcAF4Epxj1YxwvHzB16X0vp57Qem2dMHvNM8=; b=Qq09bkzdgojhpUiuadVOLD8IwtBkLN7lHRkzHApsQfxqIw+9RcCg/BtRb16n+96XDh EG4hMXT6gCytXI5kWK7esTNbZEGsPbOVWHMHZ/XwpnohTq89uDRgjKJ4239ve14Pwv3o pDSxRZKUlDVTWEfSvFq4qzue6EoG/9ANs6OCfBW8APBWUKbbq6AWJt/jlaK0Iw9osBg7 BYClCasDN80mkz5vLn6jpMtLu1hsJ/5aolZAXkIWZOPk6c+g0Ssh2f/JHkTGZGrW4wlW qZguXQfrXYHtU6ZorwGoOBKfP4EaHsLjDjkkYU1WjlEXj1cmUKmHxkN0aXsXVgfCTV2d Tx1A== X-Gm-Message-State: AKS2vOzQUDx3ut+zmSGgzhcaiixNJ/Y5iwIavxnje4NEh2oHEKKMlFF2 739JrMSexKz262T/V49qcwZEu0Lz9elU X-Received: by 10.223.142.143 with SMTP id q15mr20624535wrb.180.1498063182075; Wed, 21 Jun 2017 09:39:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.109.16 with HTTP; Wed, 21 Jun 2017 09:39:41 -0700 (PDT) In-Reply-To: <20170617145541.GA31569@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170613172347.GA12048@LK-Perkele-V2.elisa-laajakaista.fi> <20170614152204.GA17525@LK-Perkele-V2.elisa-laajakaista.fi> <20170617145541.GA31569@LK-Perkele-V2.elisa-laajakaista.fi> From: Richard Barnes Date: Wed, 21 Jun 2017 12:39:41 -0400 Message-ID: To: Ilari Liusvaara Cc: Logan Widick , ACME WG , Zach Shepherd Content-Type: multipart/alternative; boundary="f403045f517cd1a1ba05527b0339" Archived-At: Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 16:39:46 -0000 --f403045f517cd1a1ba05527b0339 Content-Type: text/plain; charset="UTF-8" I'm going to retract my earlier proposal that we address this issue. While the idea of better aligning the challenges is aesthetically appealing, there seems to be agreement that there's not a major security issue here. And the spec has already passed WGLC with the existing set of challenges. So I would propose that we close this issue and PR #312 ( https://github.com/ietf-wg-acme/acme/pull/312), which implements one solution. If there is a continued desire to do work here, a follow-on spec could define a harmonized set of challenges. Chairs: What say ye? --Richard On Sat, Jun 17, 2017 at 10:55 AM, Ilari Liusvaara wrote: > On Sat, Jun 17, 2017 at 08:47:23AM -0500, Logan Widick wrote: > > Would it be possible to add a section for how to follow this pattern in > the > > presence of space constraints? > > > > One possible way would be to divide H(H(kA)) and H(kA) into N pieces as > > needed to get through the system. Each request would include the "piece > > number" in some way so that the system can work even in the (probably > rare) > > event that pieces of either H(H(kA)) or H(kA) are identical. The ACME > > server would make N requests (one for each of the N pieces). If N=1, the > > piece number would be omitted and only 1 request would be made. In the > > event of failure, the problem document could indicate the failing pieces > in > > an array. > > The even you call "probably rare" is in fact extremely unlikely. Even > under deliberate manipulation trying to make it happen. > > In fact, if |kA| != |H(x)|, finding any such kA breaks the hash function > outright. > > > There are two places which have space constraints: > > - DNS QNAME: Eating challenge space in addition to what already needs > to be there is pretty harsh. Additionally, adding challenge there > would break delegated setups. > - TLS certificate SAN names: The DNS 63 byte limit for name component > may be relevant. Can be worked around by inserting a period in the > middle of the challenge / response. The DNS name limit is not > relevant: The postfixes are fixed, limiting the name to 85 bytes or > so. > > > The primary reason for having challenge is for the target to find the > response(s) to return. In case of HTTP or TLS-SNI, returning multiple > responses at once is highly problematic (demultiplexing requests > problem). Not so with DNS: It can easily return multiple responses at > once (up to around 18 without fallback, around 1000 with fallback to > TCP). > > And the reason for having the challenge and response be (statistically) > different is prevent careless servers from just copying the challlenge > to response and passing validation. TLS-SNI-01 has that problem (HTTP-01 > does not, due to the account thumbprint being added). > > > > That way, the same pattern works regardless of space constraints. > > > > As for key comparison, here are some ideas: > > 1. Put the key thumbprint (produced using the same hash function H > > specified in the challenge) in the revised key authorization structure in > > lieu of the key. Include the key ID as another field in the key > > authorization structure. > > > > 2. Require that only a given subset of JWK fields appears (like the > fields > > required for thumbprints). Include the key ID as another field in the key > > authorization structure. > > Doesn't that put the same information in two places (which is legendary > source of all sorts of problems)? > > Computing thumbprints and comparing those does not detect keys that are > different as the same, but can detect the same keys as different (due to > noncanonical representations. However, those are either illegal JWKs, or > just crazy, like RSA key with e > n). > > > > > > -Ilari > --f403045f517cd1a1ba05527b0339 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm going to retract my earlier proposal that we = address this issue.=C2=A0=C2=A0 While the idea of better aligning the chall= enges is aesthetically appealing, there seems to be agreement that there= 9;s not a major security issue here.=C2=A0 And the spec has already passed = WGLC with the existing set of challenges.

So I wou= ld propose that we close this issue and PR #312 (https://github.com/ietf-wg-acme/acme/pull/3= 12), which implements one solution.=C2=A0 If there is a continued desir= e to do work here, a follow-on spec could define a harmonized set of challe= nges.

Chairs: What say ye?

--Richard

On Sat, Jun 17, 2017 at 10:55 AM, Ilari Liusvaara <ilaril= iusvaara@welho.com> wrote:
= On Sat, Jun 17, 2017 at 08:47:23AM -0500, Logan Widick wro= te:
> Would it be possible to add a section for how to follow this pattern i= n the
> presence of space constraints?
>
> One possible way would be to divide H(H(kA)) and H(kA) into N pieces a= s
> needed to get through the system. Each request would include the "= ;piece
> number" in some way so that the system can work even in the (prob= ably rare)
> event that pieces of either H(H(kA)) or H(kA) are identical. The ACME<= br> > server would make N requests (one for each of the N pieces). If N=3D1,= the
> piece number would be omitted and only 1 request would be made. In the=
> event of failure, the problem document could indicate the failing piec= es in
> an array.

The even you call "probably rare" is in fact extremely unl= ikely. Even
under deliberate manipulation trying to make it happen.

In fact, if |kA| !=3D |H(x)|, finding any such kA breaks the hash function<= br> outright.


There are two places which have space constraints:

- DNS QNAME: Eating challenge space in addition to what already needs
=C2=A0 to be there is pretty harsh. Additionally, adding challenge there =C2=A0 would break delegated setups.
- TLS certificate SAN names: The DNS 63 byte limit for name component
=C2=A0 may be relevant. Can be worked around by inserting a period in the =C2=A0 middle of the challenge / response. The DNS name limit is not
=C2=A0 relevant: The postfixes are fixed, limiting the name to 85 bytes or<= br> =C2=A0 so.


The primary reason for having challenge is for the target to find the
response(s) to return. In case of HTTP or TLS-SNI, returning multiple
responses at once is highly problematic (demultiplexing requests
problem). Not so with DNS: It can easily return multiple responses at
once (up to around 18 without fallback, around 1000 with fallback to
TCP).

And the reason for having the challenge and response be (statistically)
different is prevent careless servers from just copying the challlenge
to response and passing validation. TLS-SNI-01 has that problem (HTTP-01 does not, due to the account thumbprint being added).


> That way, the same pattern works regardless of space constraints.
>
> As for key comparison, here are some ideas:
> 1. Put the key thumbprint (produced using the same hash function H
> specified in the challenge) in the revised key authorization structure= in
> lieu of the key. Include the key ID as another field in the key
> authorization structure.
>
> 2. Require that only a given subset of JWK fields appears (like the fi= elds
> required for thumbprints). Include the key ID as another field in the = key
> authorization structure.

Doesn't that put the same information in two places (which is le= gendary
source of all sorts of problems)?

Computing thumbprints and comparing those does not detect keys that are
different as the same, but can detect the same keys as different (due to noncanonical representations. However, those are either illegal JWKs, or just crazy, like RSA key with e > n).





-Ilari

--f403045f517cd1a1ba05527b0339-- From nobody Wed Jun 21 09:48:21 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B31912EBA8 for ; Wed, 21 Jun 2017 09:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 POFjTt4Jw6EP for ; Wed, 21 Jun 2017 09:48:18 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF8F12EBE6 for ; Wed, 21 Jun 2017 09:48:09 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5LGlSBB016554; Wed, 21 Jun 2017 17:48:05 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=IH1gtCBIFRI0idzEkMVVQWWn+a/3nCWx9RpnXPKQSCk=; b=nmM2bL+mRVJP6+o3bmAveiVmWuc0o9U1Ma3UhSHAP69VkV4xKC06Hvk60Ru6AMsbtoEm 0tQLItdtKtxpoeBzUIdJjyij0kLw3jKWAyrlRbfdl4dAj4UwVE6KEb+wQDh4clTVldFB E0sIzWsFjmeg5cS7NGKEbAPuZOTKyFVZq9xSun4ultbR2B8929LKdKJs7IVZ9Vhc2hXU Tjm8MJKHJnuiH1nM2n2OEAwoqiwWPI3jK17zKMzzqwrTsDGwpNvEwEf1Xdpi0bWsB0xb OqZJ8QFf2LY0rwvBQqk8FnU3Z4L2qFeG8D4RTHKnDUwttKsDLIWNqcEhwlLXZAwWyUlv fA== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050096.ppops.net-00190b01. with ESMTP id 2b7gcjcc2h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Jun 2017 17:48:05 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5LGkCfv008258; Wed, 21 Jun 2017 12:48:04 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2b4yrv2yk8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 21 Jun 2017 12:48:03 -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 Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 21 Jun 2017 12:48:02 -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.1263.000; Wed, 21 Jun 2017 12:48:02 -0400 From: "Salz, Rich" To: Richard Barnes , Ilari Liusvaara CC: Logan Widick , Zach Shepherd , ACME WG Thread-Topic: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token Thread-Index: AQHS5F9op2OuptJhoEedFvoCtKhxmqIjTfCAgAFPVYCAACD+AIAEnIqAgAATFwCABmZggP//vrMg Date: Wed, 21 Jun 2017 16:48:01 +0000 Message-ID: <2fe98134e902440ab0f5adabc182200c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170613172347.GA12048@LK-Perkele-V2.elisa-laajakaista.fi> <20170614152204.GA17525@LK-Perkele-V2.elisa-laajakaista.fi> <20170617145541.GA31569@LK-Perkele-V2.elisa-laajakaista.fi> 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.33.152] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-21_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706210283 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-21_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706210283 Archived-At: Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 16:48:20 -0000 DQo+SSdtIGdvaW5nIHRvIHJldHJhY3QgbXkgZWFybGllciBwcm9wb3NhbCB0aGF0IHdlIGFkZHJl c3MgdGhpcyBpc3N1ZS7CoMKgIFdoaWxlIHRoZSBpZGVhIG9mIGJldHRlciBhbGlnbmluZyB0aGUg Y2hhbGxlbmdlcyBpcyBhZXN0aGV0aWNhbGx5IGFwcGVhbGluZywgdGhlcmUgc2VlbXMgdG8gYmUg YWdyZWVtZW50IHRoYXQgdGhlcmUncyBub3QgYSBtYWpvciBzZWN1cml0eSBpc3N1ZSBoZXJlLsKg IEFuZCB0aGUgc3BlYyBoYXMgYWxyZWFkeSBwYXNzZWQgV0dMQyB3aXRoIHRoZSBleGlzdGluZyBz ZXQgb2YgY2hhbGxlbmdlcy4NCg0KPiBTbyBJIHdvdWxkIHByb3Bvc2UgdGhhdCB3ZSBjbG9zZSB0 aGlzIGlzc3VlIGFuZCBQUiAjMzEyIC4uLiBJZiB0aGVyZSBpcyBhIGNvbnRpbnVlZCBkZXNpcmUg dG8gZG8gd29yayBoZXJlLCBhIGZvbGxvdy1vbiBzcGVjIGNvdWxkIGRlZmluZSBhIGhhcm1vbml6 ZWQgc2V0IG9mIGNoYWxsZW5nZXMuDQoNCj4gQ2hhaXJzOiBXaGF0IHNheSB5ZT8NCg0KQWdyZWUg dG8gZGVmZXIgdGhpcyB0byBhIHBvc3NpYmxlIGZ1dHVyZSB2ZXJzaW9uLg0KDQpPciwgbW9yZSBz aW1wbHksIG5ldyBjaGFsbGVuZ2VzIGNvdWxkIGJlIGRlZmluZWQgLS0gIm5vdyB3aXRoIG1vcmUg ZW50cm9weSIgLS0gaWYgdGhlcmUgaXMgYSBjb25jZXJuLg0KIA0K From nobody Wed Jun 21 09:57:53 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D71512EBB9 for ; Wed, 21 Jun 2017 09:57:51 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=ipv-sx.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 S072etJe7Bli for ; Wed, 21 Jun 2017 09:57:47 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::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 4F889126DFF for ; Wed, 21 Jun 2017 09:57:41 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id y25so103708514wrd.2 for ; Wed, 21 Jun 2017 09:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+z2nWipfZhRoMfeOk/5/X9URIz5YbNbyjPRSLHig2aU=; b=HWnA6UMHnc6yFYbXl+hdODLPVtq0B2W+P4TQN5zbLzT1p5gz79tnJf+9YXOAgr1Pkt SQGbQI/9f6ns55OpVedI97oDOxW1Vkz/Pd6+qFIPhPSqa0urHOXmZqQ96JWUIvxA3/iQ p6S9O0NC5AUXS39qcafw+Ltn54trkqhSOy1dtGtexH9F8FjT2Te4lCiF7dfmw3newai6 JXqmODnboTlDZi96Amf39sSt3GejFTQAVimu939l8ap7KKitS0RaG8rvgiGwBbffswu+ MNGm+3BG6QhP330d1xE5H5Y5iwxCD412H2NIb1WHWVaST37YE6Qvm1REK5oNPtvWwAQE ISsQ== 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=+z2nWipfZhRoMfeOk/5/X9URIz5YbNbyjPRSLHig2aU=; b=Z8WO4FUU4kdNmI/bZ9oXZqzoS1o4PpxafG/IuhBskGj/H/nu2597M+xGvQVhThX0Oh 5HJmcQV5OcmVWUpTl7UetPCYxWqcflFmhTt0FBCQc49O22Fq+OY4cqgBPhDUv9Iiyv2D ZbGJnychww86EQnUzSSTRuRshz+UXcNIlngyfeIKQH9MlRE22eE1UiNTmLyUiKQdRk4n IXvjAilIcRmnBV3hHW2X2LNYPewxKdhLGitqcizpp+Y9bFkjLw6NfvGY4/vRBwq/ungz ZMcFkqt5GU4Z8nPLypQYPKkl3FJtfXaP2l6pXcbjQneOplwl2rvROfhRodWoIkZ3/iGC nbWw== X-Gm-Message-State: AKS2vOy3layvK565iDuv7w8ccg24Pqfgz0BkLG3W0PzXX0uxBA9co9Ie YmB6JaE52k2x/45dvxqG4dCh5Ftg3vlE X-Received: by 10.223.142.143 with SMTP id q15mr20678303wrb.180.1498064259725; Wed, 21 Jun 2017 09:57:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.109.16 with HTTP; Wed, 21 Jun 2017 09:57:38 -0700 (PDT) In-Reply-To: References: <0896b144e7e942b1ac68db9ead4c42bb@usma1ex-dag1mb1.msg.corp.akamai.com> <20170619184423.wtpj2qtq6awk3rju@LK-Perkele-VII> From: Richard Barnes Date: Wed, 21 Jun 2017 12:57:38 -0400 Message-ID: To: "Dunning, John" Cc: Ilari Liusvaara , "Salz, Rich" , "acme@ietf.org" Content-Type: multipart/alternative; boundary="f403045f517c0d440e05527b4421" Archived-At: Subject: Re: [Acme] Rolling keys and pending validations X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 16:57:51 -0000 --f403045f517c0d440e05527b4421 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It seems like the challenge update and validation process should follow natural patterns for checking the key. For the TLS-SNI and DNS challenges, the only time in the validation when the server checks the key is when the client responds with a keyAuthorization. Further processing is based on the verified keyAuthorization. So if the key change happens before the client responds, then the server will use the new key; if it happens after the response, then it will use the old key. For the HTTP challenge as written right now, there's an additional problem that the server does another key check after it gets a keyAuthorization in the validation query, rather than checking against the keyAuthorization in the challenge resource (updated post-response). If you have the following sequence of events, you'll have a problem: - Client provisions HTTP resource with old account key - Client sends response with keyAuthorization over old account key - Client changes key - Server sends validation HTTP request - Client response with keyAuthorization over the old account key - Server compares to new account key; fails. ISTM that the best way to fix this is simply to align the HTTP challenge to the other challenges, and have the server check the keyAuthorization in the response against the keyAuthorization in the challenge, rather than checking directly for the current account key. =3D=3D=3D This proposed solution framework will result in the old key being used sometimes. That's a little unfortunate (e.g., if you're rolling due to compromise), but the window of vulnerability is fairly small, and you can always revoke certificates or invalidate authorizations. I have updated the PR. Note that I have not updated the challenge type, since this seems like a minor change with small compatibility risk: https://github.com/ietf-wg-acme/acme/pull/323/files --Richard On Tue, Jun 20, 2017 at 6:07 PM, Dunning, John wrote: > I would advocate for the new one. IOW, I would (expect to) interpret the > semantics as being > > 1. The challenge token was created with respect to an account > 2. An attribute of the account is the credential (whichever credential is > current) > 3. Therefore the credential authorizes access to anything associated with > the account. > > If the concensus here is that a server needs to associate the credential > which was in force at creation time with a challenge token, in other word= s > that the token is tied to the credential rather than the account, I belie= ve > my use case would be ok with that, as long as the challenge tokens do not > go invalid after the credential change. > > I would expect that latter semantics would be hairier for server > implementors, because they=E2=80=99d need to keep multiple credentials al= ive and > associated with the account for the maximum lifetime of any extant tokens= . > > > On 6/19/17, 2:44 PM, "Ilari Liusvaara" wrote: > > On Mon, Jun 19, 2017 at 02:34:45PM -0400, Richard Barnes wrote: > > This seems sensible; rolling keys shouldn't invalidate things in > transit > > any more than changing your Gmail password should delete your draft= s > folder. > > > > I would have a little bit of a hard time calling this "purely > editorial", > > since it specifies server behavior. But it seems like you're just > > codifying an expectation that at least I already had (TBH, I would > not have > > thought to build a server otherwise), so I would be inclined to go > ahead > > and merge it if at least one or two other people chime in. > > > > Here's a PR: https://github.com/ietf-wg-acme/acme/pull/323 > > If there is pending validation over key change, which key hash should > the validation use when it is resolved? The old one? The new one? > > > -Ilari > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > > --f403045f517c0d440e05527b4421 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It seems like the challenge update and validation pro= cess should follow natural patterns for checking the key.=C2=A0
<= div>
For the TLS-SNI and DNS challenges, the only time in the= validation when the server checks the key is when the client responds with= a keyAuthorization.=C2=A0 Further processing is based on the verified keyA= uthorization.=C2=A0 So if the key change happens before the client responds= , then the server will use the new key; if it happens after the response, t= hen it will use the old key.

For the HTTP challeng= e as written right now, there's an additional problem that the server d= oes another key check after it gets a keyAuthorization in the validation qu= ery, rather than checking against the keyAuthorization in the challenge res= ource (updated post-response).=C2=A0 If you have the following sequence of = events, you'll have a problem:

- Client p= rovisions HTTP resource with old account key
- Client sends respo= nse with keyAuthorization over old account key
- Client changes k= ey
- Server sends validation HTTP request
- Client resp= onse with keyAuthorization over the old account key
- Server comp= ares to new account key; fails.

ISTM that the best= way to fix this is simply to align the HTTP challenge to the other challen= ges, and have the server check the keyAuthorization in the response against= the keyAuthorization in the challenge, rather than checking directly for t= he current account key.

=3D=3D=3D
This proposed solution framework will result in the old key be= ing used sometimes.=C2=A0 That's a little unfortunate (e.g., if you'= ;re rolling due to compromise), but the window of vulnerability is fairly s= mall, and you can always revoke certificates or invalidate authorizations.<= /div>

I have updated the PR.=C2=A0 Note that I have not = updated the challenge type, since this seems like a minor change with small= compatibility risk:


--Richard

=


On Tue, Jun 20, 2017 at 6:07 PM, Dunning, John <jrd@akamai.com> wrote:
I would advocate for the new = one.=C2=A0 IOW, I would (expect to) interpret the semantics as being

1. The challenge token was created with respect to an account
2. An attribute of the account is the credential (whichever credential is c= urrent)
3. Therefore the credential authorizes access to anything associated with t= he account.

If the concensus here is that a server needs to associate the credential wh= ich was in force at creation time with a challenge token, in other words th= at the token is tied to the credential rather than the account, I believe m= y use case would be ok with that, as long as the challenge tokens do not go= invalid after the credential change.

I would expect that latter semantics would be hairier for server implemento= rs, because they=E2=80=99d need to keep multiple credentials alive and asso= ciated with the account for the maximum lifetime of any extant tokens.


On 6/19/17, 2:44 PM, "Ilari Liusvaara" <ilariliusvaara@welho.com> wrote:

=C2=A0 =C2=A0 On Mon, Jun 19, 2017 at 02:34:45PM -0400, Richard Barnes wrot= e:
=C2=A0 =C2=A0 > This seems sensible; rolling keys shouldn't invalida= te things in transit
=C2=A0 =C2=A0 > any more than changing your Gmail password should delete= your drafts folder.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I would have a little bit of a hard time calling this &q= uot;purely editorial",
=C2=A0 =C2=A0 > since it specifies server behavior.=C2=A0 But it seems l= ike you're just
=C2=A0 =C2=A0 > codifying an expectation that at least I already had (TB= H, I would not have
=C2=A0 =C2=A0 > thought to build a server otherwise), so I would be incl= ined to go ahead
=C2=A0 =C2=A0 > and merge it if at least one or two other people chime i= n.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Here's a PR:=C2=A0 https://githu= b.com/ietf-wg-acme/acme/pull/323

=C2=A0 =C2=A0 If there is pending validation over key change, which key has= h should
=C2=A0 =C2=A0 the validation use when it is resolved? The old one? The new = one?


=C2=A0 =C2=A0 -Ilari

=C2=A0 =C2=A0 _________= ______________________________________
=C2=A0 =C2=A0 Acme mailing list
=C2=A0 =C2=A0 Acme@ietf.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/a= cme



--f403045f517c0d440e05527b4421-- From nobody Wed Jun 21 10:06:28 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C50126C25 for ; Wed, 21 Jun 2017 10:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 zYJ041vvapH2 for ; Wed, 21 Jun 2017 10:06:25 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (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 EBD64128B37 for ; Wed, 21 Jun 2017 10:06:24 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id e187so27186685pgc.1 for ; Wed, 21 Jun 2017 10:06:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=zxU6Dyw3mMVfh7ZJm2cyi1mWEVUK51TSigWomFRpLn4=; b=Y1SDC/PjllV0jclSrzH/oudZmBAobKHIS7A/b7YCyD4dIlX0OtXYMkQ0mBozZVINpd zj1+wmncmFu35TaCZgVS31mN7CaseUo62zFpfo2BAWulonf7j8WQZChBSepfeCQq7nGd auOzgl8WD/0EQ64SzaXI/ap7hidpT5YL5z0gCsIQXNIWJlDgUEP43UTCe0xqb4oSlUCv k2qNT3SvoX7wFxpcuVLeXVVvhVvjKl7fmBoPXXUKAWeNW4zapppoHCpwK2crpmdOB0du 6qNBRIhzFiF7TkEMqutwrEsCJVRZHt2x4P+BVrJB+MIyAkXw3S9GD/zX6nJ9VJabl8fl JRlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zxU6Dyw3mMVfh7ZJm2cyi1mWEVUK51TSigWomFRpLn4=; b=chwEy2z641f2hmAWUJCBE3wHcpgkggqtAB2BsBH7GBysmYm5RUSfJwGz3yBsKEVqxI dr+SMfInAT4ef8APnlpw5zLxnXJE1LVPouSJ4MoX7Keis5dXgQaal38wg21LpE+O4E26 2kOZVl1d0h5pdPk/tiwIodHHdOW62XtcPHFKW5+Bf5ZDNMeFxCEdaPsAI0GLOn7pR2LE 3cWBiUCk4peh0FPQGSwHBecKrBx4lNy0tEOZ0QtNKdpgk5DT+zH0YAGSsAKALO1IqKBZ BFDkxX804hnjBlI7alGrqu46rpbyGMh07myFwBUZA5wEbNWqReaEViNYrbJxaZP+mpFO 3YZQ== X-Gm-Message-State: AKS2vOztbffwNTMRRZekPLXZRUJ9bQvEkQw7Qv6GlD/bVjtSUHaO4DiA PVVKGzBJbmnjSG8xJYtTiB4rCeFt9A== X-Received: by 10.99.147.91 with SMTP id w27mr36968155pgm.24.1498064784451; Wed, 21 Jun 2017 10:06:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.169.13 with HTTP; Wed, 21 Jun 2017 10:05:44 -0700 (PDT) From: Kathleen Moriarty Date: Wed, 21 Jun 2017 13:05:44 -0400 Message-ID: To: IETF ACME Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Acme] Chairs X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 17:06:27 -0000 Hello, First, a big thank you to Ted for serving as an ACME chair, bringing the main draft close to the finish line! Your contribution to the work and management of ACME is much appreciated! Thank you to all who volunteered. Yoav Nir will be appointed the co-chair. For Prague, we'll continue with 3 chairs and then Ted will step down after Prague. -- Best regards, Kathleen From nobody Wed Jun 21 11:07:47 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6E21293DA for ; Wed, 21 Jun 2017 11:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lK8EIT8faVLj for ; Wed, 21 Jun 2017 11:07:40 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52FA3126E3A for ; Wed, 21 Jun 2017 11:07:40 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5LI7TTU019811; Wed, 21 Jun 2017 19:07:38 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=ZdOQ0WHy710pd2ZWE+JPd04Cd51/dZADK/QFD40Og7Y=; b=nXditcXbMz4auoekydHIfbae5C/TtH4bmzifhjmck7EbhiLMVvlIGi7++dYhbFUZl91Q MlnsetyfMosQz+q4eqnzqrukgSBOg64AHY4DIp2iPdRPxcmb3YCzAg4sj6Z9G7zVc+lw Suu62RLRCIPUouxQ+anqWa7hreyHoEGQ56IeZ+mPods4W3vP5mgSoYbU8IHFFO/+IsCs 5qjMRNlkgI+krlcShtLU8JAfRMuqD4N3aHpSvhCXX9jSwKUtUWqSOuCQaHXv7aZF0SKf c44Q/4lfqQqQeQFpvHU5bx9/u1zfQXWOwSaxVZCi5oMGhGy12ewp445oIvjsZK+nF6Uh jg== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2b7a3v7rn9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Jun 2017 19:07:38 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5LI664r006629; Wed, 21 Jun 2017 14:07:37 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2b4yrvfkqv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 21 Jun 2017 14:07:37 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 21 Jun 2017 14:07:36 -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.1263.000; Wed, 21 Jun 2017 14:07:36 -0400 From: "Salz, Rich" To: Richard Barnes , "Dunning, John" CC: Ilari Liusvaara , "acme@ietf.org" Thread-Topic: [Acme] Rolling keys and pending validations Thread-Index: AdLpJhpoh06PBTCkQemxb0Jtd47K7AAJiW6AAABWIYAAOV68AAAnfA4AAAX43KA= Date: Wed, 21 Jun 2017 18:07:35 +0000 Message-ID: <59398d0af56c46c2a95acafb95f3af54@usma1ex-dag1mb1.msg.corp.akamai.com> References: <0896b144e7e942b1ac68db9ead4c42bb@usma1ex-dag1mb1.msg.corp.akamai.com> <20170619184423.wtpj2qtq6awk3rju@LK-Perkele-VII> 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.33.152] Content-Type: multipart/alternative; boundary="_000_59398d0af56c46c2a95acafb95f3af54usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-21_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706210304 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-21_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706210304 Archived-At: Subject: Re: [Acme] Rolling keys and pending validations X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 18:07:42 -0000 --_000_59398d0af56c46c2a95acafb95f3af54usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U28gZmFyIHRoZSBvbmx5IOKAnG9iamVjdGlvbuKAnSBhYm91dCB0aGlzIGhhcyBiZWVuIHRoYXQg aXQgZGVmaW5lcyBzZXJ2ZXIgYmVoYXZpb3IgYW5kIGlzIHRoZXJlZm9yZSBub3Qgc3RyaWN0bHkg ZWRpdG9yaWFsLiAgQnV0IHRoYXQgY29tbWVudCBkaWRu4oCZdCBkaXNhZ3JlZSB3aXRoIHRoZSBh Y3R1YWwgY2hhbmdlLg0KDQpTbyBwbGVhc2UgZ28gYWhlYWQuICBJZiBhbnlvbmUgZGlzYWdyZWVz LCBzdGFydCBkaXNjdXNzaW9ucyBub3cuDQo= --_000_59398d0af56c46c2a95acafb95f3af54usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNvIGZhciB0aGUgb25seSDigJxvYmplY3Rpb27igJ0gYWJv dXQgdGhpcyBoYXMgYmVlbiB0aGF0IGl0IGRlZmluZXMgc2VydmVyIGJlaGF2aW9yIGFuZCBpcyB0 aGVyZWZvcmUgbm90IHN0cmljdGx5IGVkaXRvcmlhbC4mbmJzcDsgQnV0IHRoYXQgY29tbWVudCBk aWRu4oCZdCBkaXNhZ3JlZSB3aXRoIHRoZSBhY3R1YWwgY2hhbmdlLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5T byBwbGVhc2UgZ28gYWhlYWQuJm5ic3A7IElmIGFueW9uZSBkaXNhZ3JlZXMsIHN0YXJ0IGRpc2N1 c3Npb25zIG5vdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_59398d0af56c46c2a95acafb95f3af54usma1exdag1mb1msgcorpak_-- From nobody Wed Jun 21 12:00:53 2017 Return-Path: X-Original-To: acme@ietf.org Delivered-To: acme@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA8B12EC00; Wed, 21 Jun 2017 12:00:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: acme@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149807165247.15932.14866158682370663408@ietfa.amsl.com> Date: Wed, 21 Jun 2017 12:00:52 -0700 Archived-At: Subject: [Acme] I-D Action: draft-ietf-acme-acme-07.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 19:00:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Automated Certificate Management Environment of the IETF. Title : Automatic Certificate Management Environment (ACME) Authors : Richard Barnes Jacob Hoffman-Andrews James Kasten Filename : draft-ietf-acme-acme-07.txt Pages : 74 Date : 2017-06-21 Abstract: Certificates in PKI using X.509 (PKIX) are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certificate authorities in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. Today, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a certification authority (CA) and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-acme-acme-07 https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-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 Jun 21 12:20:55 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD6612943A for ; Wed, 21 Jun 2017 12:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 BANDzw1076DZ for ; Wed, 21 Jun 2017 12:20:51 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 66ABF1241FC for ; Wed, 21 Jun 2017 12:20:51 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id 16so4716467qkg.2 for ; Wed, 21 Jun 2017 12:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=gdE+FYIgUkrnW6QN+tle4G6Y+6z32ZZtAZyK0DAxHuU=; b=q1dS6fJd216P1y4Y0r1MLv7UWBgyZQ3JN6+jUr/i/CtpTvEX0ZDkukwTfJmXvgZaim RMehf2qKmTmL0z7KZy2uyKGY7eUQojKYj+G6fjUIut341pSmzSBk3s+kG09CaS3WOrrQ bjB0k8nNf1swn8IY6yzSDkWvMLTPSGihjwUCbKyDwc8vDixVWhENPurTuf9rSbTPUuuY rzWI/dv14EHew3qN/pDq6zG7rEoqu8F7HG7cTg4ty79Zb3aWrNGhtXzHq846Vtqh25TM qNWbX0jHNT+ABVjtdjPHyMejSJIKONWqHg67hnlFhmXGgnyp344gFFILeR/0Un6pk6gD xINA== 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=gdE+FYIgUkrnW6QN+tle4G6Y+6z32ZZtAZyK0DAxHuU=; b=laWkHA1ydkAig5ulzVPP+S1InJTHMJs+8ZEVkBMkoSrTwkHdv5aN/4Uqi5psZ+oz5J KCYHMCm9lHc+PxZBpoUe3tpccHcAcQdqQkGNjZ0VT3Koy2NLeEx5jLOGvO3RTf4PrTyx DlYSxZ0uCs8NXMqPQ5dnGfjL3umb985icuZmqd8IQu6IoATncjzS+mm8FE7WeBc/Sqad 71TUo5kWwaGoRW54/Xmq2HQmGrNu4E7EjF+e87fZoxXQA+AN4SO8UWEvJIQ3FCiiBmXV HTwNcrv7yt8MkCmSY8IhxVHkfnfghyNXGlQmbEuTzi97kr9OVS//pT3Nf/6W7Z7BTulg ZIiw== X-Gm-Message-State: AKS2vOwcz+/SI5TIkUCH79+qIj1TUEJ5QvwNjrmC1YlbuJNcmhyBSZBk zeSs4Otghlmy7I7wWb/vi8faPWgaTA== X-Received: by 10.55.22.71 with SMTP id g68mr43953740qkh.218.1498072850328; Wed, 21 Jun 2017 12:20:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.34.9 with HTTP; Wed, 21 Jun 2017 12:20:19 -0700 (PDT) In-Reply-To: <149807165247.15932.14866158682370663408@ietfa.amsl.com> References: <149807165247.15932.14866158682370663408@ietfa.amsl.com> From: Ted Hardie Date: Wed, 21 Jun 2017 12:20:19 -0700 Message-ID: To: "acme@ietf.org" , "Salz, Rich" , Yoav Nir Content-Type: multipart/alternative; boundary="001a114774161777af05527d44e1" Archived-At: Subject: [Acme] Fwd: I-D Action: draft-ietf-acme-acme-07.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 19:20:54 -0000 --001a114774161777af05527d44e1 Content-Type: text/plain; charset="UTF-8" Howdy, We'd like to start a short working group last call on the changes made in response to the previous last call. It will end June 28th, 2017, any time zone (to accommodate any changes needed before the draft deadline the following Monday). Please review carefully, but please respect the discussion which have already been held by focusing on new issues or new information about the issues that have been resolved. thanks, Ted, Rich, (and now) Yoav ---------- Forwarded message ---------- From: Date: Wed, Jun 21, 2017 at 12:00 PM Subject: [Acme] I-D Action: draft-ietf-acme-acme-07.txt To: i-d-announce@ietf.org Cc: acme@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Automated Certificate Management Environment of the IETF. Title : Automatic Certificate Management Environment (ACME) Authors : Richard Barnes Jacob Hoffman-Andrews James Kasten Filename : draft-ietf-acme-acme-07.txt Pages : 74 Date : 2017-06-21 Abstract: Certificates in PKI using X.509 (PKIX) are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certificate authorities in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. Today, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a certification authority (CA) and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-acme-acme-07 https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-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/ _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme --001a114774161777af05527d44e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

We'd like to s= tart a short working group last call on the changes made in response to the= previous last call.=C2=A0 It will end June 28th, 2017, any time zone (to a= ccommodate any changes needed before the draft deadline the following Monda= y).

Please review carefully, but please respect the discussion= which have already been held by focusing on new issues or new information = about the issues that have been resolved.

thanks,

Ted, Rich, (and now) Yoav


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Wed, Jun= 21, 2017 at 12:00 PM
Subject: [Acme] I-D Action: draft-ietf-acme-acme-0= 7.txt
To: i-d-announce@ietf.org=
Cc: acme@ietf.org


<= br> A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Automated Certificate Management Environme= nt of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Automatic Certificate Management Environment (ACME)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Rich= ard Barnes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Jacob Hoffman-Andrews
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 James Kasten
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-acme-acme-07.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 74
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-06-21

Abstract:
=C2=A0 =C2=A0Certificates in PKI using X.509 (PKIX) are used for a number o= f
=C2=A0 =C2=A0purposes, the most significant of which is the authentication = of
=C2=A0 =C2=A0domain names.=C2=A0 Thus, certificate authorities in the Web P= KI are
=C2=A0 =C2=A0trusted to verify that an applicant for a certificate legitima= tely
=C2=A0 =C2=A0represents the domain name(s) in the certificate.=C2=A0 Today,= this
=C2=A0 =C2=A0verification is done through a collection of ad hoc mechanisms= .=C2=A0 This
=C2=A0 =C2=A0document describes a protocol that a certification authority (= CA) and
=C2=A0 =C2=A0an applicant can use to automate the process of verification a= nd
=C2=A0 =C2=A0certificate issuance.=C2=A0 The protocol also provides facilit= ies for
=C2=A0 =C2=A0other certificate management functions, such as certificate =C2=A0 =C2=A0revocation.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ie= tf-acme-acme/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-= acme-07
https://datatracker.ietf.org/doc/h= tml/draft-ietf-acme-acme-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3D= draft-ietf-acme-acme-07


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

--001a114774161777af05527d44e1-- From nobody Thu Jun 22 02:00:40 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663D41274D0 for ; Thu, 22 Jun 2017 02:00:38 -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, RP_MATCHES_RCVD=-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 VErKSvUK0grY for ; Thu, 22 Jun 2017 02:00:31 -0700 (PDT) Received: from office.denic.de (office.denic.de [81.91.160.182]) (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 328B9127078 for ; Thu, 22 Jun 2017 02:00:30 -0700 (PDT) In-Reply-To: References: <149807165247.15932.14866158682370663408@ietfa.amsl.com> To: "acme@ietf.org" MIME-Version: 1.0 X-KeepSent: DC759F05:976AADD1-C1258147:002F7BCF; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0.1FP6 Octobe4, 2013 From: Marcos Sanz Message-ID: Date: Thu, 22 Jun 2017 10:59:50 +0200 X-MIMETrack: Serialize by Router on notes/Denic at 22.06.2017 10:59:50, Serialize complete at 22.06.2017 10:59:50 Content-Type: text/plain; charset="US-ASCII" Archived-At: Subject: [Acme] acme-07: Integrity of Authorizations X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 09:00:38 -0000 > We'd like to start a short working group last call on the changes made in response to the previous last call. It will end June > 28th, 2017, any time zone (to accommodate any changes needed before the draft deadline the following Monday). There is this sentence in the security considerations (10.2 Integrity of Authorizations) that strikes me as extremely misleading: "All of the challenges above have a binding between the account private key and the validation query made by the server, via the key authorization. The key authorization is signed by the account private key, reflects the corresponding public key, and is provided to the server in the validation response." The key authorization itself does NOT contain the signature of the account's key. It gets though signed by the account's key later on in the challenge response (not the validation response) over the ACME channel (not the validation channel). What about saying that in the chronological order of events: "The key authorization reflects the account public key, is provided to the server in the validation response over the validation channel and signed afterwards by the corresponding private key in the challenge response over the ACME channel" Best regards, Marcos From nobody Thu Jun 22 09:09:34 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FB412700F for ; Thu, 22 Jun 2017 09:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.702 X-Spam-Level: X-Spam-Status: No, score=-4.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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=nokia.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 jykzEYxIKlKv for ; Thu, 22 Jun 2017 09:09:30 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0108.outbound.protection.outlook.com [104.47.2.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1CF8126BF0 for ; Thu, 22 Jun 2017 09:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YAvpy53zMH/dtQAL25P2/eIs3VsjdtX321e3FxUuZqg=; b=ePAQqZZW7dDfy2IoGg0XCOAXkkP8HzJtDJ82yZ0s3VsTOsL+USNJskujWdWO/cGiIjKNpiwu0uSTMdnFFymlpjbnhMNxzl/DQMaC1Qs/TxkIWYqkeYZVF5mgOlMNR7UHaMU3soLrzKwVEIbCfz3mOe8XBJ2pXeemAyIL5tC2oOg= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB0800.eurprd07.prod.outlook.com (10.161.107.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Thu, 22 Jun 2017 16:09:27 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::3041:3f90:1f98:286]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::3041:3f90:1f98:286%13]) with mapi id 15.01.1199.012; Thu, 22 Jun 2017 16:09:26 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Martin Thomson , "acme@ietf.org" CC: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Thread-Topic: [Acme] I-D Action: draft-ietf-acme-star-00.txt Thread-Index: AQHS5prmrwORxiIJo02oe8sPKmjEO6IrUxWAgAF4G4CABFw0AA== Date: Thu, 22 Jun 2017 16:09:26 +0000 Message-ID: References: <149761557766.24143.14359431560325982499@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [81.134.152.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB0800; 7:hArcP64pFfxdJ6ecxoA9BZDUnOvuGkWoBqBoGkAPaZiIX8Ky9G+hZq6Zaz6AmjSDsuQmfrhvkB+CjHGQ1aleQSw02UaDQ6Ei7NS2V762lJjvaDboSJ6ZFTyfNisNmhBSi1M79f1SCHDnOw9yzQo4U91O77u6atnty11O/ZFEfeLTRwP0xw6jJ5n/2XQ0R7dVdro8/dOAkSYj/6R6QvvxAWrcHQiETVVVRcbagRDgjyOtcN5y/DRdT6XYH3ukwZzE1H02RaXYQMNUtSzx/pIq0I1T7hz08MtCWE3VMVLSbz89Z2CedLfjYBN+7Tvs168hSJdVp7SlmfNz/1oi3ku+kO3HGnjFqWfYF5CeneUatSFvZ43+a1BWuoBRjA+Ze4hGxU5nORdzcDKm82Xf5htH/gjXSIf9PsvmKSjl9IklQV5134yB1OAuhBC1fQS2p0fgQeODYlk4KWcSPbGZrWy3pavupqCPGo5Ov3fgQ5D2BH73hCd7DN4jnt5kF2D2OiO4GpmvNXhlQhWbyar0IKFQqdVzqsd2xp6zgIhjuAvX7zWDG/HoSTOc8LqNh1/dCqjCuQgAKsKT/iq9qfSa5XkYROtv82NDIhXUOpX+A5T3kWu+HJMRyP3FEeRQCTgc9TnKeJ7N/WA/hxlTqPoa3E3a/NlDSddfolOF53SD6SyEeQ8d/gOSsPlx+miGMkZfoRfzoctIv7dnu846/DO6RzbBC5IziYwfe45FJGiy170GUTcy8jA5TiSynQqnp19Qh2ims7DZjsQ+Gf2GEldHnscQd2qg4makLGVpQkj0tX22rvg= x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39450400003)(39840400002)(39850400002)(39860400002)(39400400002)(51444003)(24454002)(82746002)(25786009)(2501003)(5890100001)(14454004)(5250100002)(189998001)(36756003)(66066001)(3660700001)(3280700002)(478600001)(2906002)(8936002)(33656002)(2900100001)(102836003)(2950100002)(5660300001)(305945005)(86362001)(6116002)(3846002)(81166006)(7736002)(8676002)(6512007)(229853002)(4326008)(6486002)(83716003)(4001350100001)(6436002)(6506006)(6246003)(99286003)(107886003)(83506001)(230783001)(50986999)(76176999)(53936002)(54356999)(53546010)(38730400002)(39060400002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB0800; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-ms-office365-filtering-correlation-id: df9c1371-afc4-4892-a21b-08d4b9890df3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR07MB0800; x-ms-traffictypediagnostic: VI1PR07MB0800: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(131327999870524); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB0800; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB0800; x-forefront-prvs: 03468CBA43 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <6E380CA0C496564EB54C97AE08ACBFD5@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2017 16:09:26.0550 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB0800 Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 16:09:32 -0000 SGkgTWFydGluLA0KDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3Lg0KDQpPbiAxOS8wNi8yMDE3LCAy MzozNCwgIkFjbWUgb24gYmVoYWxmIG9mIE1hcnRpbiBUaG9tc29uIiA8YWNtZS1ib3VuY2VzQGll dGYub3JnIG9uIGJlaGFsZiBvZiBtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+IHdyb3RlOg0KPiAN Cj4gQSBmZXcgYnJpZWYgY29tbWVudHMgb24gdGhpcyBkcmFmdC4NCj4gDQo+IE9uIDE2IEp1bmUg MjAxNyBhdCAyMjoxOSwgIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KPiAgICAg VGhpcyBtZW1vIHByb3Bvc2VzIGFuIEFDTUUgZXh0ZW5zaW9uIHRvIGVuYWJsZSB0aGUgaXNzdWFu Y2Ugb2Ygc2hvcnQtDQo+ICAgICB0ZXJtIGFuZCBhdXRvbWF0aWNhbGx5IHJlbmV3ZWQgY2VydGlm aWNhdGVzLiAgVGhpcyBhbGxvd3MgYSBkb21haW4NCj4gICAgIG5hbWUgb3duZXIgdG8gZGVsZWdh dGUgdGhlIHVzZSBvZiBjZXJ0aWZpY2F0ZXMgdG8gYW5vdGhlciBwYXJ0eSwNCj4gICAgIHdoaWxl IHJldGFpbmluZyB0aGUgY2FwYWJpbGl0eSB0byBjYW5jZWwgdGhpcyBkZWxlZ2F0aW9uIGF0IGFu eSB0aW1lDQo+ICAgICB3aXRoIG5vIG5lZWQgdG8gcmVseSBvbiBjZXJ0aWZpY2F0ZSByZXZvY2F0 aW9uIG1lY2hhbmlzbXMuDQo+IA0KPiBJIGZvdW5kIHRoZSBpbnRyb2R1Y3Rpb24gb3Zlcmx5IHNw ZWNpZmljLiAgVGhlIGdlbmVyaWMgdXNlIGNhc2UgaXMgdG8NCj4gc2ltcGxpZnkgdGhlIGRlcGxv eW1lbnQgb2YgY2VydGlmaWNhdGVzIHRvIHVucHJpdmlsZWdlZCBub2Rlcy4gIFRoZQ0KPiB1bnBy aXZpbGVnZWQgbm9kZXMgdGhlbiBvbmx5IG5lZWQgdG8gYmUgY29uZmlndXJlZCB3aXRoIGEgVVJM IGZvcg0KPiB0aGVpciBjZXJ0aWZpY2F0ZXMuDQo+IA0KPiBUaGF0IHJlcXVpcmVzIGEgY291cGxl IG9mIHBhcmFncmFwaHMgb2YgZXhwb3NpdGlvbiBhdCBtb3N0LiAgVGhpcw0KPiBleHRlbmRzIHRv IFNlY3Rpb24gMiwgd2hpY2ggZGVzY3JpYmVzIGEgc3lzdGVtIGFyY2hpdGVjdHVyZSB0aGF0DQo+ IGltcGxpZXMgdGhlIGV4aXN0ZW5jZSBvZiBwcm90b2NvbCBlbGVtZW50cyB0aGF0IGFyZSBzaW1w bHkgbm90IGRlZmluZWQNCj4gaW4gdGhpcyBkb2N1bWVudC4NCj4gDQo+IFNlY3Rpb25zIDEgYW5k IDIgY291bGQgbXVjaCBtb3JlIGNsZWFybHkgZGVzY3JpYmUgd2hhdCAqdGhpcyogZG9jdW1lbnQN Cj4gcHJvdmlkZXMuICBJdCBwcm92aWRlcyBhbiBleHRlbnNpb24gdG8gQUNNRSB0aGF0IGFsbG93 cyBmb3IgdGhlDQo+IGNyZWF0aW9uIG9mIGEgY2VydGlmaWNhdGUgdGhhdCBhdXRvbWF0aWNhbGx5 IHJlbmV3cy4NCj4gDQo+IFRoZSBmb2N1cyBvbiB0aGUgQ0ROIGNhc2UgYWZmZWN0cyB0aGUgZW50 aXJlIGRvY3VtZW50LiAgVGhlIHBvaW50IGlzDQo+IHRoYXQgdGhlIGF1dGhvcml6ZWQgZW50aXR5 IGlzIGRlbGVnYXRpbmcgdGhlIGFiaWxpdHkgdG8gdXNlIGENCj4gY2VydGlmaWNhdGUgZm9yIGl0 cyBuYW1lIHRvIGFuIHVucHJpdmlsZWdlZCBub2RlLiAgRG9uJ3QgdXNlICJDRE4iLA0KPiAiY29u dGVudCBvd25lciIgb3IgYW55IG9mIHRoZXNlIGhpZ2hseSBzcGVjaWZpYyB0ZXJtcy4gIFVzZSBn ZW5lcmljDQo+IHRlcm1zOyBtYWtlIG5ldyB0ZXJtcyBpZiBuZWNlc3NhcnkuICBGV0lXLCB3aGls ZSBOREMgaXMgYSBjdXRlDQo+IHJldmVyc2FsLCAiY29uc3VtZXIiIHJlYWxseSBpc24ndCBhY2N1 cmF0ZS4NCg0KQWdyZWUsIHRoZXJlIGlzIHN0aWxsIGEgYml0IG9mIExVUksgYmFnZ2FnZSBhdHRh Y2hlZCAoZXNwZWNpYWxseSBoZXJlLA0KYnV0IGFsc28gaW4gYSBmZXcgb3RoZXIgcG9pbnRzKS4N Cg0KV2Ugd2lsbCBkbyBhbiBlZGl0b3JpYWwgcGFzcyB0byBzdHJlYW1saW5lIHRoZSBkb2N1bWVu dCBiZWZvcmUgLTAxDQphbmQgdGFrZSBpbiB0aGUgc3VnZ2VzdGlvbnMgYWJvdmUuDQoNCj4gZHJh ZnQtaWFiLXdlYi1wa2ktcHJvYmxlbXMgaGFzIGJlZW4gYWJhbmRvbmVkLiAgSXQncyBub3QgYSBn cmVhdCBpZGVhDQo+IHRvIGNpdGUgaXQuDQoNCk9LLCB3aWxsIGRyb3AgdGhlIHJlZmVyZW5jZSAt LSB0b28gYmFkLCB0aG91Z2guDQoNCj4gSW4gU2VjdGlvbiAzLjEuMSwgSSB0aGluayB0aGF0IHRo ZSByZXNvbHV0aW9uIG9mIHRoZXNlIGZpZWxkcywgYmVpbmcNCj4gaW4gZGF5cywgaXMgbm90IGNv bmR1Y2l2ZSB0byByZWR1Y2luZyBncmFudWxhcml0eS4gIChPciB3aWxsIHlvdQ0KPiBwZXJtaXQg NS43ZS0zIGFzIGEgdmFsdWU/KQ0KDQpTZWNvbmRzIGdyYW51bGFyaXR5IHRoZW4/ICAzMiBiaXQg c2hvdWxkIGJlIGVub3VnaCBmb3IgPjEwMCB5ZWFycyB3aGlsZQ0KYWxsb3dpbmcgYmFyeW9uLWxp a2UgbGlmZXRpbWVzIG9uIHRoZSBvdGhlciBlbmQgb2YgdGhlIHNjYWxlIDotKQ0KDQooUGVyc29u YWxseSwgSSdkIGF2b2lkIGFueSBzdHJpbmcgcmVwcmVzZW50YXRpb24sIGJ1dCB0aGF0J3MgbXkg dGFzdGUuKQ0KDQo+IFNlY3Rpb24gMy4xLjEgbmVlZHMgdG8gY2xlYXJseSBhcnRpY3VsYXRlIGhv dw0KPiAicmVjdXJyZW50LWNlcnRpZmljYXRlLXZhbGlkaXR5IiAoY291bGQgdGhpcyBiZSBhbnkg bW9yZSB2ZXJib3NlIGFuZA0KPiBoYXJkIHRvIHR5cGU/KSByZWxhdGVzIHRvICJleHBpcmVzIi4N Cg0KT0sNCg0KPiBQbGVhc2UgaW5jbHVkZSBhIGRlZmluaXRpb24gZm9yIHRoZSBuZXcgYXR0cmli dXRlcywgcmF0aGVyIHRoYW4ganVzdA0KPiBwcm92aWRpbmcgYW4gZXhhbXBsZSBhbmQgY29tbWVu dGluZyB0aGUgSlNPTi4NCg0KT0sNCg0KPiBJbiBTZWN0aW9uIDMuMS4yLCB5b3UgUkVBTExZLCBS RUFMTFkgbmVlZCB0byBhdXRoZW50aWNhdGUgdGhpcw0KPiByZXF1ZXN0LiAgDQoNClN1cmUuICBF dmVyeSBub24tUk8gb3BlcmF0aW9uIG5lZWRzIHRvIGJlIGF1dGhlbnRpY2F0ZWQuICBXZSBmb3Jn b3QgdG8NCmJlIGV4cGxpY2l0IGFib3V0IHRoYXQ7IHRoYW5rcyBmb3Igc3BvdHRpbmcgaXQuDQoN Cj4gTXkgc3VnZ2VzdGlvbiBpcyB0byBjaGFuZ2UgdGhpcyB0byBhIFBPU1QgcmVxdWVzdCB3aXRo IHsNCj4gInJlY3VycmVudCI6IGZhbHNlIH0uICAoSSdkIGhhdmUgc3VnZ2VzdGVkIFBVVCBvciBQ QVRDSCwgYnV0IEFDTUUncw0KPiByZWxpYW5jZSBvbiBKV1MgcGVydmVydHMgdGhhdCBpbiB3YXlz IHRoYXQgaXMgaW5jb21wYXRpYmxlIHdpdGggdGhvc2UNCj4gbWV0aG9kcy4pDQoNCkkgaGF2ZSBu byBzdHJvbmcgb3BpbmlvbiBhYm91dCB0aGUgc3ludGF4IG9mIHRoZSBvcmRlciB0ZXJtaW5hdGlv bi4NCkRFTEVURSBqdXN0IHNlZW1lZCB0aGUgbW9zdCBuYXR1cmFsIHRvIG1lIChjZXJ0YWlubHkg bW9yZQ0Kc3RyYWlnaHRmb3J3YXJkIHRoYW4gUE9TVGluZyAneyAicmVjdXJyZW50IjogZmFsc2Ug fScpLCBidXQgSSdtIHByb2JhYmx5DQptaXNzaW5nIHNvbWV0aGluZz8NCg0KPiBJbiBTZWN0aW9u IDMuMiwgdGhlIGRpc2N1c3Npb24gYWJvdXQgYSBQcm94eSBpcyBtaXNsZWFkaW5nLiAgVGhlIG9u bHkNCj4gcmVsZXZhbnQgYWN0b3IgaW4gdGhpcyBpcyBhbiBBQ01FIGNsaWVudC4gIFRoaXMgc2Vj dGlvbiBjb3VsZCBiZQ0KPiByZWR1Y2VkIHRvOg0KPiANCj4gQW4gQUNNRSBjbGllbnQgZGlzY292 ZXJzIHdoZXRoZXIgYSBzZXJ2ZXIgc3VwcG9ydHMgdGhpcyBleHRlbnNpb24gYnkNCj4gZXhhbWlu aW5nIGEgbmV3bHkgY3JlYXRlZCBvcmRlci4gIFRoZSAicmVjdXJyZW50IiBtZW1iZXIgd2lsbCBl eGlzdCBpZg0KPiB0aGUgc2VydmVyIHN1cHBvcnRzIGF1dG9tYXRpYyByZWN1cnJpbmcgY2VydGlm aWNhdGUgaXNzdWFuY2U7IHRoZQ0KPiAicmVjdXJyZW50IiBtZW1iZXIgd2lsbCBiZSB0cnVlIGlm IHRoZSBzZXJ2ZXIgYWNjZXB0cyB0aGUgcmVxdWVzdC4NCg0KWWVzLCBhZ3JlZWQuICBUaGlzIGlz IGFub3RoZXIgZXhhbXBsZSBvZiB0aGUgTFVSSyBjbGVhbi1vdXQgdGhhdCB3ZSBuZWVkDQp0byBm aW5pc2ggb2ZmLg0KDQo+IENhbiB0aGUgc2VydmVyIHNwZWNpZnkgYSBzaG9ydGVyIHZhbHVlIGZv ciAicmVjdXJyZW50LXRvdGFsLWxpZmV0aW1lIj8NCg0KWWVzLiAgQW5kIGlmIHRoZSBjbGllbnQg aXMgbm90IGhhcHB5IHdpdGggdGhlIGNob3NlbiB2YWx1ZSBJIGd1ZXNzIGl0DQp3aWxsIGp1c3Qg YWJhbmRvbiB0aGUgb3JkZXIgYW5kIGxldCBpdCBleHBpcmUgKGFzIHN1Z2dlc3RlZCBpbiAzLjIp Lg0KDQo+IEkgZG9uJ3QgdW5kZXJzdGFuZCBTZWN0aW9uIDMuMyBhdCBhbGwuICBJJ2QgcmVjb21t ZW5kIHJlbW92aW5nIHRoaXMNCj4gc2VjdGlvbi4gIFRoZSBETk8gd2lsbCBkZWNpZGUgd2hhdCBh dXRob3JpemF0aW9ucyBpdCByZXF1ZXN0cyBhbXBseQ0KPiB3aXRob3V0IHRoaXMgbGV2ZWwgb2Yg cHJvc2NyaXB0aW9uIGluIHN0YW5kYXJkcy4NCg0KWWFyb246IHRob3VnaHRzIG9uIHRoaXM/DQoN Cj4gSW4gU2VjdGlvbiAzLjQsIHRoZSB1c2Ugb2YgdGhlIEV4cGlyZXMgaGVhZGVyIGZpZWxkIGlz IGEgY29tbW9uDQo+IG1pc3Rha2UuICBUaGlzIGlzIGFuIEhUVFAgY2FjaGluZyBkaXJlY3RpdmUu ICBJdCBzaG91bGQgcHJvYmFibHkgYmUNCj4gc2hvcnRlciB0aGFuIHRoZSBleHBpcmF0aW9uIHRp bWUgb2YgdGhlIGNlcnRpZmljYXRlIChoYWxmIGluIGZhY3QpLA0KPiBidXQgbm90IGZvciB0aGUg cmVhc29ucyB0aGF0IHlvdSBtaWdodCB0aGluay4gIFRoZSBwdXJwb3NlIG9mIGENCj4gcmVjb21t ZW5kYXRpb24gb24gRXhwaXJlcyBpcyB0byBlbnN1cmUgdGhhdCB0aGUgY2VydGlmaWNhdGUgaXMg bm90DQo+IGNhY2hlZCBiZXlvbmQgdGhlIHBvaW50IHdoZXJlIGEgbmV3ZXIgY2VydGlmaWNhdGUg d2lsbCBiZSBpc3N1ZWQuICBZb3UNCj4gc2hvdWxkIHJlbW92ZSB0aGlzIHRleHQuDQoNCk9LDQoN Cj4gU2VjdGlvbiA1LjEgc2hvdWxkIGJlIHByb21vdGVkIHRvIFNlY3Rpb24gNQ0KDQpPSw0KDQo+ IERvbid0IG1lbnRpb24gdGltZS1zZW5zaXRpdmUgcG9saWN5IGFjdGlvbnMgYnkgdGhlIENBL0Ig Rm9ydW0uDQoNCk1ha2VzIHNlbnNlLg0KDQo+IENhbid0IHlvdSBzaW1wbHkgZW5zdXJlIHRoYXQg dGhlIENETiBjYW4ndCBtb2RpZnkgdGhlIENBQSByZWNvcmQ/DQoNClRoaXMgaXMgdGhlIG1pbmlt dW0gd2UgY291bGQgc2F5LiAgQXQgdGhpcyBwb2ludCwgSSB0aGluayB3ZSBhcmUgdHJ5aW5nDQp0 byBleHBsb3JlIGEgYml0IHdoYXQgb3RoZXIgbWl0aWdhdGlvbnMgY2FuIGJlIHB1dCBpbiBwbGFj ZS4NCg0KPiBPbmUgZnVydGhlciB0aG91Z2h0LiBBQ01FIHVzZXMgYW4gYWJzb2x1dGUgdGltZSBm b3IgZXhwaXJhdGlvbi4gVGhpcw0KPiB1c2VzIGEgcmVsYXRpdmUgdGltZS4gSSB0aGluayB0aGF0 IEkgcHJlZmVyIHRoZSBmb3JtZXIuIEkgcmVhbGl6ZSB0aGF0DQo+IGNvbnNpc3RlbmN5IG1pZ2h0 IGJlIGltcG9zc2libGUgaW4gdGhpcyBjYXNlLCBzaW5jZSB0aGUgcmVjdXJyZW50DQo+IGR1cmF0 aW9uIGlzIG5lY2Vzc2FyaWx5IHJlbGF0aXZlLCBidXQgSSB0aG91Z2ggaXQgd29ydGggcmFpc2lu Zy4NCg0KVGhpcyBpcyBhIGdvb2Qgb2JzZXJ2YXRpb24uICBNYXliZSBpbnN0ZWFkIG9mIG1pcnJv cmluZw0KInJlY3VycmVudC10b3RhbC1saWZldGltZSIsIHNlcnZlciBjb3VsZCBjb21lIGJhY2sg d2l0aCB0aGUgYWJzb2x1dGUNCnRpbWUgd2hlbiB0aGUgcmVuZXdhbCBlbmRzIG9uIGl0cyBzaWRl IChlLmcuLCAicmVjdXJyZW50LWV4cGlyYXRpb24iKS4NCg0KQ2hlZXJzLCB0aGFua3MNCg0K From nobody Fri Jun 23 06:33:51 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8C71294A1 for ; Fri, 23 Jun 2017 06:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 98BqqYIyTgXi for ; Fri, 23 Jun 2017 06:33:48 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::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 F275D126D45 for ; Fri, 23 Jun 2017 06:33:47 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id r126so5541772vkg.0 for ; Fri, 23 Jun 2017 06:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=icUFEkkWw3WATHLRBdEZSt5KD8CLJcLFeuLq/I92qQ0=; b=c435rQz7Pm4wStVcXEZgvlLqTW0E9jaTtJBuXJatGztAo0l8xe+IL4a7ItGjDU29zN kK9CqyWLa9k5EXtpMfIJz3ujpZG5vN7XWvAT+Ju8k+DvFCZyCNoYjzfGWyG5TkJuk3Pw sgzjTsEGUxvCsSkONvBYxH6QAhlgFm4AeycczM54dJ5CBMjU9HNQL/a5Y0fr5tF82CtO vHnLiW9tsw8sTPyjB1IjjXn/5UJG56y2QMkWPpccAZ2P0PBgo6Go1n9doUSvZ0mPPfq2 btZRVVH5mbsXShtSyA9k3jRx7zcvVqws7A9rjnsNtpNokGiRqYX8fsHadtiEyt7c5Sgh GBgA== 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=icUFEkkWw3WATHLRBdEZSt5KD8CLJcLFeuLq/I92qQ0=; b=mFKILxASB95/RC2GVoESYfZPRYHXQL57V9eeL3iu2MkTK3fSpPMFvV3QmM9+EhTMAG 6qJ7n6SpI+iS0nUfazhlB4mPxgBOz/eaMECmGxqK22b8NSMlI0TfynkWCmBtj4NVB1RX QtLcc/FfrZ6OWAQzrTvPwp6Rh9oFed+RqMUgNKRusER19j4xBxrQZFmU0oTwGs2NmkEs tefc0ZPyUVddL2VAxsH1KOUnUO0gNYkUV0X3xuLDmswJvTBQd4j3MmMZGZWQBQojynHL SURCRR65B4AMvErMLld5tNIOrC137yj/O5e3Er0AUh3Q0bGSopVBwKcJCMuEh2nQYh/y hNvA== X-Gm-Message-State: AKS2vOxLxLpDSP4Z4JeMdOp3e5z4wW44uKmHJdDAee8G3ZEontsEAU7c p6T8POxhrJtizk76i0wUwmV2zmT8GQ== X-Received: by 10.31.218.196 with SMTP id r187mr1105679vkg.96.1498224827061; Fri, 23 Jun 2017 06:33:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.76.29 with HTTP; Fri, 23 Jun 2017 06:33:46 -0700 (PDT) In-Reply-To: References: <149807165247.15932.14866158682370663408@ietfa.amsl.com> From: Rifaat Shekh-Yusef Date: Fri, 23 Jun 2017 09:33:46 -0400 Message-ID: To: Ted Hardie Cc: "acme@ietf.org" , "Salz, Rich" , Yoav Nir Content-Type: multipart/alternative; boundary="94eb2c07c5629c67f60552a0a680" Archived-At: Subject: Re: [Acme] Fwd: I-D Action: draft-ietf-acme-acme-07.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 13:33:50 -0000 --94eb2c07c5629c67f60552a0a680 Content-Type: text/plain; charset="UTF-8" I do not believe that I got an answer to my pre-authorization question here: https://www.ietf.org/mail-archive/web/acme/current/msg01991.html What would be the response of the server if the client sends the certificate issuance request after it sends the pre-authorization request but before it completes the pre-authorization process? Would the server reply with the same challenges it provided in the response to the pre-authorization request? Regards, Rifaat On Wed, Jun 21, 2017 at 3:20 PM, Ted Hardie wrote: > Howdy, > > We'd like to start a short working group last call on the changes made in > response to the previous last call. It will end June 28th, 2017, any time > zone (to accommodate any changes needed before the draft deadline the > following Monday). > > Please review carefully, but please respect the discussion which have > already been held by focusing on new issues or new information about the > issues that have been resolved. > > thanks, > > Ted, Rich, (and now) Yoav > > > > ---------- Forwarded message ---------- > From: > Date: Wed, Jun 21, 2017 at 12:00 PM > Subject: [Acme] I-D Action: draft-ietf-acme-acme-07.txt > To: i-d-announce@ietf.org > Cc: acme@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Automated Certificate Management > Environment of the IETF. > > Title : Automatic Certificate Management Environment > (ACME) > Authors : Richard Barnes > Jacob Hoffman-Andrews > James Kasten > Filename : draft-ietf-acme-acme-07.txt > Pages : 74 > Date : 2017-06-21 > > Abstract: > Certificates in PKI using X.509 (PKIX) are used for a number of > purposes, the most significant of which is the authentication of > domain names. Thus, certificate authorities in the Web PKI are > trusted to verify that an applicant for a certificate legitimately > represents the domain name(s) in the certificate. Today, this > verification is done through a collection of ad hoc mechanisms. This > document describes a protocol that a certification authority (CA) and > an applicant can use to automate the process of verification and > certificate issuance. The protocol also provides facilities for > other certificate management functions, such as certificate > revocation. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-acme-acme-07 > https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-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/ > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --94eb2c07c5629c67f60552a0a680 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I do not believe that I got an answer to my pre-authorizat= ion question here:

What would be the resp= onse of the server if the client sends the
certificate issuance r= equest after it sends the pre-authorization request but=C2=A0
bef= ore it completes the pre-authorization process?

<= div>Would the server reply with the same challenges it provided in the resp= onse to the pre-authorization request?

Regards,
=C2=A0Rifaat



On Wed, Jun 21, 2017 at 3:20 P= M, Ted Hardie <ted.ietf@gmail.com> wrote:
Howdy,

W= e'd like to start a short working group last call on the changes made i= n response to the previous last call.=C2=A0 It will end June 28th, 2017, an= y time zone (to accommodate any changes needed before the draft deadline th= e following Monday).

Please review carefully, but please respe= ct the discussion which have already been held by focusing on new issues or= new information about the issues that have been resolved.

tha= nks,

Ted, Rich, (and now) Yoav

=


---------- Forwarded= message ----------
From: <= internet-drafts@ietf.org>
Date: Wed, Jun 21, 2017 at 12:00= PM
Subject: [Acme] I-D Action: draft-ietf-acme-acme-07.txt
To: i-d-announce@ietf.org=
Cc: acme@ietf.or= g



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Automated Certificate Management Environme= nt of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Automatic Certificate Management Environment (ACME)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Rich= ard Barnes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Jacob Hoffman-Andrews
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 James Kasten
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-acme-acme-07.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 74
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-06-21

Abstract:
=C2=A0 =C2=A0Certificates in PKI using X.509 (PKIX) are used for a number o= f
=C2=A0 =C2=A0purposes, the most significant of which is the authentication = of
=C2=A0 =C2=A0domain names.=C2=A0 Thus, certificate authorities in the Web P= KI are
=C2=A0 =C2=A0trusted to verify that an applicant for a certificate legitima= tely
=C2=A0 =C2=A0represents the domain name(s) in the certificate.=C2=A0 Today,= this
=C2=A0 =C2=A0verification is done through a collection of ad hoc mechanisms= .=C2=A0 This
=C2=A0 =C2=A0document describes a protocol that a certification authority (= CA) and
=C2=A0 =C2=A0an applicant can use to automate the process of verification a= nd
=C2=A0 =C2=A0certificate issuance.=C2=A0 The protocol also provides facilit= ies for
=C2=A0 =C2=A0other certificate management functions, such as certificate =C2=A0 =C2=A0revocation.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ie= tf-acme-acme/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-= acme-07
https://datatracker.ietf.org/doc/h= tml/draft-ietf-acme-acme-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3D= draft-ietf-acme-acme-07


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme


--94eb2c07c5629c67f60552a0a680-- From nobody Fri Jun 23 09:24:46 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD9C1289B0 for ; Fri, 23 Jun 2017 09:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 UFaUTCxyyQG9 for ; Fri, 23 Jun 2017 09:24:43 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::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 C38D5127136 for ; Fri, 23 Jun 2017 09:24:42 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id c11so72378821wrc.3 for ; Fri, 23 Jun 2017 09:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=lIYX+KIAJKfv90zJl2bZ5rbCh3y7XTRSFQ5/VGBRRos=; b=DPBQMFrhHe8ZQkQdUMyD92YG08HA4Mr7SERhcXPCM5gGdCBrSK0XKJmiTk/ZKg3S88 +4rxehpHR5GfL8UnYrJH+sSeBatIZG5Vti9UdFuuLg7A6K8boQqBziABFdZyW8MM0Kzh AetrPvs2jyHXPfsZhuTA+z9iVG7Ah09SEt03NwvS9MbwOBu3RXJknBv7TnjInO28TaQg 25vVpzHqjlo1PhxXE+y5vQhUVTCCK30ytqyffOcXXZEiwASYfHBTXpGk50ZHsG5UUJE4 U31Sg7NNyGAAd+saW7JCVU1lqLjR6oTKpX+DtmzVUGqTaps+dZp8fZtvv9vwGOIekldp VzZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=lIYX+KIAJKfv90zJl2bZ5rbCh3y7XTRSFQ5/VGBRRos=; b=RrCg3VTfc81+49wRi2Y6+Bb/2jg+RUD5GvVIcDwYRdzLO4zz2j+XxEjYjbXKngiOdu HJqVNYNMnklfWCuuP88HyyTGnSw34KAqfeueE4raSw9QOh7RPcM7uoF9FDd++flWHauT H95ed+RdiWzx2VOePtPoxlAlYOCFsbAS4iEDdczk42iiW1Ep78njbpW81JJf/72BdkWE tYpYnAUizeq+PNOoxNXxbTJ69SquyrjDJFy5nlvG0RlDArRoIFvYIvdK7BTHX1Yx7pFu peU0qKXRlXgnFvLRrA79uAf+sylDbPkUnYeZ5xlBobuVkP/zO9y6HGjnJNL6kmkClxuM CyLA== X-Gm-Message-State: AKS2vOzPMe1h4ZBfn1orlEs7px1OAm5qBe/m730OQv/dSWj6N1ad5xZT /bErnMlWP1np4l8Cswc= X-Received: by 10.80.154.129 with SMTP id p1mr6757900edb.131.1498235081092; Fri, 23 Jun 2017 09:24:41 -0700 (PDT) Received: from [10.0.0.9] (bzq-79-183-25-61.red.bezeqint.net. [79.183.25.61]) by smtp.gmail.com with ESMTPSA id e18sm2910380edd.27.2017.06.23.09.24.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Jun 2017 09:24:40 -0700 (PDT) To: acme@ietf.org References: From: Yaron Sheffer Message-ID: <96097af0-1c43-d42d-dde2-f542deb920de@gmail.com> Date: Fri, 23 Jun 2017 19:24:39 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 16:24:45 -0000 Hi Martin, Thomas, > Hi Martin, > > Thanks for your review. > > On 19/06/2017, 23:34, "Acme on behalf of Martin Thomson" wrote: >> A few brief comments on this draft. >> [snip] >> I don't understand Section 3.3 at all. I'd recommend removing this >> section. The DNO will decide what authorizations it requests amply >> without this level of proscription in standards. > Yaron: thoughts on this? This is yet another LURK leftover, where we make assumptions about the capabilities of the NDC. Prescription makes sense in some particular cases, but I agree this should be folded into the security considerations (specifically Sec. 5.1) instead of the protocol's body. > >> In Section 3.4, the use of the Expires header field is a common >> mistake. This is an HTTP caching directive. It should probably be >> shorter than the expiration time of the certificate (half in fact), >> but not for the reasons that you might think. The purpose of a >> recommendation on Expires is to ensure that the certificate is not >> cached beyond the point where a newer certificate will be issued. You >> should remove this text. > OK Is there some other common header to denote that the value of a URL is only good for X time? [snip] > >> Don't mention time-sensitive policy actions by the CA/B Forum. > Makes sense. I disagree. CA/B forum decisions (unlike IETF standards) are mandatory for some parties to follow and so can be relied upon by the DNO. > >> Can't you simply ensure that the CDN can't modify the CAA record? > This is the minimum we could say. At this point, I think we are trying > to explore a bit what other mitigations can be put in place. Unfortunately this is insufficient, because in the case of CDN's, some of the authorization methods are subject to spoofing. From nobody Fri Jun 23 17:17:20 2017 Return-Path: X-Original-To: acme@ietf.org Delivered-To: acme@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5D812EB9B; Fri, 23 Jun 2017 17:07:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: Kathleen.Moriarty.ietf@gmail.com, acme@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826283823.7840.4378484758953583984.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:18 -0700 Archived-At: Subject: [Acme] acme - Requested session has been scheduled for IETF 99 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:18 -0000 Dear Stephanie McCammon, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. acme Session 1 (1:30:00) Friday, Morning Session I 0930-1130 Room Name: Athens/Barcelona size: 100 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Automated Certificate Management Environment Area Name: Security Area Session Requester: Stephanie McCammon Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: perc tls rtcweb sidr httpbis stir Second Priority: dprive tcpinc uta dispatch netvc cfrg ace Third Priority: maprg hrpc irtfopen opsec People who must be present: Eric Rescorla Rich Salz Stephen Farrell Kathleen Moriarty Martin Thomson Richard Barnes Ted Hardie Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Jun 24 17:52:13 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B93127866 for ; Sat, 24 Jun 2017 17:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 OvvZpGNlGaM8 for ; Sat, 24 Jun 2017 17:52:10 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 A2C0E12785F for ; Sat, 24 Jun 2017 17:52:09 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id l13so46078695lfl.1 for ; Sat, 24 Jun 2017 17:52:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yEgHaxPIOQMMc2cORb88gBjOnytevzTkG9xNDFJbm4s=; b=aS+hJG/SxG8idBEv47JSODS3PYEG5Sozh2ZvmCKQFDiUKs6pR/nPdtfa5xBcqStgfo BAlRfl+B+3R9iYjPw+b0nifRO/QlcljPtfch1TOGouHFzmFqC8koDtHTd4bTaVNR9j3d xzw7KE48zEcb3GnbNsIzWRuAF6klQK8TW4sVZ3gQ3PWrZBuBNctsn5q/AyBY5YFPeDhr u9Iz/sINkna/AJNxiuQZw28jKcSXPACIMBlu6AUj65GX+t+RKvfXdqQlD44n2nhxo1nG 73x/VdLKbXLfydlyvsAsRxcyzGQR9CE77bBrZ/cgBsxSOP6fjkPv9qyfNCf3rkXQ77hH sCvg== 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=yEgHaxPIOQMMc2cORb88gBjOnytevzTkG9xNDFJbm4s=; b=R5MuBEjGujdDUGlbPdViI6+NkM2ifT1Aa+yU0gT/AqFm1yRP5baOxn7oZfQQFKURmx 8uVpyCGI/mB6tI1lmStk3r+RBEO0odLpIew7R0qNvQz5O2ZkA5sSbJUTYacHAmHr3DjS qif01p6JaJ/NPIgSE16MlpElJRtfn+VB3hH8e/236KDfesuj+LEuqd4HVGrIzQhz/9Ud Q2MWwy6tUDmITgMeWUXzYM2sUELzwULAPj7NzSdfqloshRrWLUA2pvSabUc7zYcae5jN +3IaJz7Wvbs1eZPDuxzeSZ1yG92wXXJ3h5TN+txhktEzx16Yf/DBQ6RLglVkOnxPkq7K xLtw== X-Gm-Message-State: AKS2vOxrgt5z81QrOSZEUpXHFcS0u8WiP3KhKL8DoHrIM67pu6h6J57E r5VPrSKO8xgAlEIDitZwsbnEJl0kkg== X-Received: by 10.46.20.22 with SMTP id u22mr4512035ljd.113.1498351927826; Sat, 24 Jun 2017 17:52:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Sat, 24 Jun 2017 17:52:07 -0700 (PDT) In-Reply-To: <96097af0-1c43-d42d-dde2-f542deb920de@gmail.com> References: <96097af0-1c43-d42d-dde2-f542deb920de@gmail.com> From: Martin Thomson Date: Sun, 25 Jun 2017 10:52:07 +1000 Message-ID: To: Yaron Sheffer Cc: "acme@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2017 00:52:12 -0000 On 24 June 2017 at 02:24, Yaron Sheffer wrote: >>> Expires is to ensure that the certificate is not >>> cached beyond the point where a newer certificate will be issued. You >>> should remove this text. >> >> OK > > Is there some other common header to denote that the value of a URL is only > good for X time? Isn't enough to rely on the server echoing your parameters? (Another reason to use absolute values for the end of the recurring interval.) >>> Don't mention time-sensitive policy actions by the CA/B Forum. >> >> Makes sense. > > I disagree. CA/B forum decisions (unlike IETF standards) are mandatory for > some parties to follow and so can be relied upon by the DNO. This is a protocol. What CABF do with it is entirely up to them. They aren't the only ones creating policy that might affect someone using this protocol. >>> Can't you simply ensure that the CDN can't modify the CAA record? >> >> This is the minimum we could say. At this point, I think we are trying >> to explore a bit what other mitigations can be put in place. > > Unfortunately this is insufficient, because in the case of CDN's, some of > the authorization methods are subject to spoofing. If the CAA record exists, then spoofing won't result in the certificate being issued, so what is the problem? From nobody Sun Jun 25 16:08:09 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6E5127241 for ; Sun, 25 Jun 2017 16:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.457 X-Spam-Level: X-Spam-Status: No, score=-0.457 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 SCVsIouNXh6E for ; Sun, 25 Jun 2017 16:08:06 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 888D3127136 for ; Sun, 25 Jun 2017 16:08:06 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id r103so130670314wrb.0 for ; Sun, 25 Jun 2017 16:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=g1WqrUvzkLzuLtzD4HkMV+vziIHkBOQ+cxlDgBfUR34=; b=nXEkXnMJNf493hwAcbOajEXF2fq2uoHwTRpk6J9bkVkVoYNe35p5Xdmuc7fo1zJCCv DqMQe0/Mkc1Po04CI5mPbIw9c9pKJW11ikjRIfiBWlkCdhzxNc8l/WxJVSItEKjEa4Z1 +BrL+j3hTKZL25GvIJV3ZfpjK9JsQVBv9BGfilofarYox7+0oGbk8Esev1faehe/OKYA V+TA7J0m3HU5b5GVUzS1wBz4qUIWFEpZfFginJp36GJV0AOvIh0jcqxIFqG6btkGz1es ZcRGAeKJbAoy2covbWB3tPGpJ05NF9vwgj0t/tKrB2Z5NkfMbLaICp/Yu63ahayzyHaY XmCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=g1WqrUvzkLzuLtzD4HkMV+vziIHkBOQ+cxlDgBfUR34=; b=Lb6Q2UQw46sFSM02iRIifc7aIXXDty86Z7Gu2bFyKl/KhIyOb07IB5A77TOyq3/P/+ qQF70LqTQ94yhiAp9lzefEe5+gNmzrd3uNfdTKt9k9nm4+2BW64W4nb+bQtHDxc7hagR nE/2ra8Zm8BaqKFMSlKoPVtYC/Mx4Rn582CvtRJUMp+9QVEwxk9H7SAhUJLzT+iX3bDk CGuD+V12lxLHfoo5PvRdI3vf6ogDDtLCoNI5K2JIGJMwwWj9R1cfg14caqSwJQ+dzdWo n4xNFHhML//YjSRGbg8KYb5aLCdrn4khgNVc0p/vaHtz0AnmdLyego/ioOSTOsYvQtd8 JUKg== X-Gm-Message-State: AKS2vOzUa7iv5hutVXmsEnw2vIFSR5orogtbEvReD+n0Lms/5Za5jaP5 W/IkiSbhdmOGxsWGQuI= X-Received: by 10.28.137.206 with SMTP id l197mr10548608wmd.41.1498432084744; Sun, 25 Jun 2017 16:08:04 -0700 (PDT) Received: from [192.168.43.74] ([2.53.156.2]) by smtp.gmail.com with ESMTPSA id 89sm8710582wra.43.2017.06.25.16.08.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Jun 2017 16:08:04 -0700 (PDT) To: Martin Thomson Cc: "acme@ietf.org" References: <96097af0-1c43-d42d-dde2-f542deb920de@gmail.com> From: Yaron Sheffer Message-ID: Date: Sun, 25 Jun 2017 17:56:30 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2017 23:08:08 -0000 On 25/06/17 03:52, Martin Thomson wrote: > On 24 June 2017 at 02:24, Yaron Sheffer wrote: >>>> Expires is to ensure that the certificate is not >>>> cached beyond the point where a newer certificate will be issued. You >>>> should remove this text. >>> OK >> Is there some other common header to denote that the value of a URL is only >> good for X time? > Isn't enough to rely on the server echoing your parameters? (Another > reason to use absolute values for the end of the recurring interval.) I'm not following you. In Sec. 3.4 we're saying that the (periodically rolling) certificate is always available on the same URL, the "certificate endpoint". Since the content available at that URL changes from time to time, we wanted to indicate its end-of-validity with an HTTP header. If "Expires" is not the right header, is there a better way to do it? > >>>> Don't mention time-sensitive policy actions by the CA/B Forum. >>> Makes sense. >> I disagree. CA/B forum decisions (unlike IETF standards) are mandatory for >> some parties to follow and so can be relied upon by the DNO. > This is a protocol. What CABF do with it is entirely up to them. > They aren't the only ones creating policy that might affect someone > using this protocol. But people are not obligated to implement IETF protocols. OTOH some organizations *are* bound by CA/B Forum rules. And this section is predicated on the assumption at all "reasonable" CAs do honor CAA records, otherwise a rogue CDN employee can create a certificate for the domain on a non-ACME CA, if they only require a proof of ownership of the web server. > >>>> Can't you simply ensure that the CDN can't modify the CAA record? >>> This is the minimum we could say. At this point, I think we are trying >>> to explore a bit what other mitigations can be put in place. >> Unfortunately this is insufficient, because in the case of CDN's, some of >> the authorization methods are subject to spoofing. > If the CAA record exists, then spoofing won't result in the > certificate being issued, so what is the problem? Basic CAA, prior to Hugo's draft, only says which CA you are trusting. But that CA can still choose the spoofable http-01 authorization - spoofable if you are the CDN and so you control the web pages. From nobody Sun Jun 25 16:49:27 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F248D12714F for ; Sun, 25 Jun 2017 16:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 5vNHY2f1BLxQ for ; Sun, 25 Jun 2017 16:49:24 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 10880126D85 for ; Sun, 25 Jun 2017 16:49:24 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id b207so3986666lfg.2 for ; Sun, 25 Jun 2017 16:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+mpqhTOSyXt+W3u+WYkDPEgd9V30Dzf1+yaibq52CVY=; b=RO2IXuNGf11D/ZjM1qpxuxCK5zlPLdj6b5JpJXuTk4DlXZiiFRr0ZYjapva8h12vZ7 iPPuYal6KI20jDwrc9NjmWjGvoQA6Wst53ygnB6Skh4Q+lT9fdVOPJj9fyPu+QVSUFjn cVAXx0btfT81cgnp4Oon7B5iSmEABaBlem6p/1JeY1vLx1HniDoJfR3ESucRDGeWbXsQ 7zh8Vuvsf6z9OVI+fvtEUrHPxlaqA1daoTidpsrODdQlJdRKovWzq7vVJm63LasTqaYh AyzdoWAVPv43YKtiWn0cbnlLr6tbSmSvvGz7uBqzTzJfmkX1BLFvZZG+UvHly8kxdYYf kBDA== 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=+mpqhTOSyXt+W3u+WYkDPEgd9V30Dzf1+yaibq52CVY=; b=PAriExP8UKYIm58470Xfii5I8riv5ulB0yPF7bRZAiOgOYFBjfCo98zosRyUIeld/2 9I+0zBTcRlZlZ2JAwlYi2G6QPBIU/ZISKt65j4btPTgyaUgYR3OUDn50TN55l4g5lI00 En98efdmheTwWxheo85Fhv/sM16qRQm8jfAVBF0z6sFswWmvgwUPtOscyxP/Wak8CgBy OPE6Cn5porgV6884YEwPCowfbty2QlrpS/GuUZJG74gX/Hq+6FPXqY6C9VS9E2/yO8h3 LxjDw6PA+2rnZzudp3pPOEiFvqkqmzrvs30OKoEgVVa5XMB9DMN+20zhMRSwI+5xDDaQ v60w== X-Gm-Message-State: AKS2vOwLC6xhCH0L9LeW4nbkr8uJK6hzXsBVWAFKq+U+7xp/eoh+zj3E UVjv+zF8kkVMqsZKnsUNbDVI9n6/Gg== X-Received: by 10.25.166.15 with SMTP id p15mr5035173lfe.43.1498434562248; Sun, 25 Jun 2017 16:49:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Sun, 25 Jun 2017 16:49:21 -0700 (PDT) In-Reply-To: References: <96097af0-1c43-d42d-dde2-f542deb920de@gmail.com> From: Martin Thomson Date: Mon, 26 Jun 2017 11:49:21 +1200 Message-ID: To: Yaron Sheffer Cc: "acme@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-star-00.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2017 23:49:26 -0000 On 26 June 2017 at 02:56, Yaron Sheffer wrote: > I'm not following you. In Sec. 3.4 we're saying that the (periodically > rolling) certificate is always available on the same URL, the "certificate > endpoint". Since the content available at that URL changes from time to > time, we wanted to indicate its end-of-validity with an HTTP header. If > "Expires" is not the right header, is there a better way to do it? I was talking about using the order. The creation of the order and the representation that you receive at that point will include the time. And that's enough. That info can be conveyed along with the URL for the certificate to endpoints, if they care. > But people are not obligated to implement IETF protocols. OTOH some > organizations *are* bound by CA/B Forum rules. And this section is > predicated on the assumption at all "reasonable" CAs do honor CAA records, > otherwise a rogue CDN employee can create a certificate for the domain on a > non-ACME CA, if they only require a proof of ownership of the web server. Just say what the protocol does and avoid all that muck. You lose generality, currency, correctness, and it's just more work to talk about CABF stuff. The web isn't the only user of this stuff and I have started to see drafts lose sight of that. > Basic CAA, prior to Hugo's draft, only says which CA you are trusting. But > that CA can still choose the spoofable http-01 authorization - spoofable if > you are the CDN and so you control the web pages. My understanding is that in this model you *need* CAA with the extension. As you say CAA doesn't cut it. The text as it stands basically implies that, but it also says a bunch of other stuff, which obfuscates that important message. So say exactly that: MUST use CAA with the acme extension and that needs to be immutable so that the untrusted thingamy can't just rewrite the policy. That's all I was asking for. From nobody Mon Jun 26 07:15:39 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBEB512EA56 for ; Mon, 26 Jun 2017 07:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 E60Vk23WBbLk for ; Mon, 26 Jun 2017 07:15:34 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 71B38129C31 for ; Mon, 26 Jun 2017 07:15:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 5908D21951; Mon, 26 Jun 2017 17:15:31 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id MUFXxJq0xdP8; Mon, 26 Jun 2017 17:15:31 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id EBDD22313; Mon, 26 Jun 2017 17:15:26 +0300 (EEST) Date: Mon, 26 Jun 2017 17:15:26 +0300 From: Ilari Liusvaara To: Ted Hardie Cc: "acme@ietf.org" , "Salz, Rich" , Yoav Nir Message-ID: <20170626141526.js5lufvbl4gvxb6i@LK-Perkele-VII> References: <149807165247.15932.14866158682370663408@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] Fwd: I-D Action: draft-ietf-acme-acme-07.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 14:15:38 -0000 On Wed, Jun 21, 2017 at 12:20:19PM -0700, Ted Hardie wrote: > Howdy, > > We'd like to start a short working group last call on the changes made in > response to the previous last call. It will end June 28th, 2017, any time > zone (to accommodate any changes needed before the draft deadline the > following Monday). > > Please review carefully, but please respect the discussion which have > already been held by focusing on new issues or new information about the > issues that have been resolved. > > thanks, > > Ted, Rich, (and now) Yoav I was trying to write some code, and noticed a potential inconsistency: Section 7.5.1 has in example (responding to HTTP-01 challenge): "payload": base64url({ "type": "http-01", "keyAuthorization": "IlirfxKKXA...vb29HhjjLPSggwiE" }), ... Type field is present. But section 8.3 has: "payload": base64url({ "keyAuthorization": "evaGxfADs...62jcerQ" }), ... No type field. And section 8.4 has: "payload": base64url({ "keyAuthorization": "evaGxfADs...62jcerQ" }), ... No type field. And section 8.5: "payload": base64url({ "keyAuthorization": "evaGxfADs...62jcerQ" }), ...Ditto. Is the type supposed to be present (I presume yes)? -Ilari From nobody Mon Jun 26 12:36:04 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9AD412EB51 for ; Mon, 26 Jun 2017 12:36:02 -0700 (PDT) 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, 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 56TWtnE0T8Y1 for ; Mon, 26 Jun 2017 12:36:00 -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 2C10312EB07 for ; Mon, 26 Jun 2017 12:35:59 -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:References:Cc:To:Subject; bh=3qzFaSPtCAF14YfiTF6Wt3zvcRWm2ToYiKUjJXdsfoM=; b=jssG41+SQLNBTa2nWdZhXh1e/fX4yIrL8ftXR81etZdByoH3or8EKNUJkVN+baKLATtmFtwaDbIL+B2bxWcAV/NDkqRZ3C4kE5+AvbqvjTVpMl3EHpX8MOIZ75rHJLXXHBy/u3cqLDZ16Y4a6wfi+ywx2p+49hzrlTmSimVLgxY=; Received: ; Mon, 26 Jun 2017 12:35:57 -0700 To: "Dunning, John" , Ilari Liusvaara , Richard Barnes Cc: "Salz, Rich" , "acme@ietf.org" References: <0896b144e7e942b1ac68db9ead4c42bb@usma1ex-dag1mb1.msg.corp.akamai.com> <20170619184423.wtpj2qtq6awk3rju@LK-Perkele-VII> From: Jacob Hoffman-Andrews Message-ID: <53c76454-56ac-dde7-6cf8-94a6e39a89fc@eff.org> Date: Mon, 26 Jun 2017 12:35:57 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BC0F4D2DCDFE6298CC3604F1" Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] Rolling keys and pending validations X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 19:36:03 -0000 This is a multi-part message in MIME format. --------------BC0F4D2DCDFE6298CC3604F1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06/20/2017 03:07 PM, Dunning, John wrote: > I would advocate for the new one. IOW, I would (expect to) interpret t= he semantics as being > > 1. The challenge token was created with respect to an account > 2. An attribute of the account is the credential (whichever credential = is current) > 3. Therefore the credential authorizes access to anything associated wi= th the account. > > If the concensus here is that a server needs to associate the credentia= l which was in force at creation time with a challenge token, in other wo= rds that the token is tied to the credential rather than the account, I b= elieve my use case would be ok with that, as long as the challenge tokens= do not go invalid after the credential change. This seems different from the behavior I thought you were looking for, based on previous conversations. This may be a difference in interpretation of "challenge token" vs "key authorization." Every challenge has a random "token" field, but this is only a part of what gets provisioned to a web server for HTTP-01. For an HTTP-01 challenge, the ACME client calculates a "key authorization" as ".". The client then POSTs a signed request to the challenge URL, containing a "keyAuthorization" field containing this key authorization. The ACME server then requests "/.well-known/acme-validation/" from the validation domain, and expects "." (that is, the key authorization object) in response. I think a more customary way of talking would be to call this "key authorization" object that is provisioned on the validation domain a "challenge token." And in fact, in an earlier (pre-draft-01) version of the ACME spec, the "token" field of a challenge was provisioned on the validation domain and requested by the ACME server. However, some people on the list pointed out that this would encourage development of "naive" challenge solvers that would just echo the token part of the URL. So we wound up in this awkward state where what most people would consider a "challenge token" is, in ACME, considered a "key authorization." As I understand the situation we're trying to solve, it's something like this: 1. Monday: an ACME client operated by a hosting provider receives a request for a certificate for `www.example.com`. This ACME client requests an authorization object from the server, and receives one. The authorization object contains a challenge of type "HTTP-01": { "type": "http-01", "status": "pending", "uri": "https://ca.example.net/acme/challenge/l-2zFCdEQT3H5adBnO_WFuTAA3t4BV4hnF= qWwtlgnpo/8543", "token": "LC2eEY_9lRLgxUfCME6TMB4bS0wslm2PDLTC2-JU-YY", } The client's current account key has a thumbprint of "MKgAB8ljZpQv0hxuipA70L0SZkmXIUhbO61fR3vKvj8", so it calculates a key authorization by concatenating that with the challenge token field: "LC2eEY_9lRLgxUfCME6TMB4bS0wslm2PDLTC2-JU-YY.MKgAB8ljZpQv0hxuipA70L0SZkmX= IUhbO61fR3vKvj8". It then tells the owner of `example.com` to put a file containing that string at "/.well-known/acme-challenge/LC2eEY_9lRLgxUfCME6TMB4bS0wslm2PDLTC2-JU-YY"= =2E The owners of `www.example.com` say "Okay, but that will take a few days.= 2. Tuesday: The ACME client rotates its account key as part of regular maintenance. The new account key thumbprint is "bJcgrK6oTvjgvkuMOOkpdS8BdOotqf_z9T8zw-eFWOE". 3. Wednesday: `www.example.com` says "Okay, I've created a file at "/.well-known/acme-challenge/LC2eEY_9lRLgxUfCME6TMB4bS0wslm2PDLTC2-JU-YY"= , and it contains "LC2eEY_9lRLgxUfCME6TMB4bS0wslm2PDLTC2-JU-YY.MKgAB8ljZpQv0hxuipA70L0SZkmX= IUhbO61fR3vKvj8". The account key thumbprint in this file (the part after the ".") is out of date, because the ACME client rotated its account key. 3. Wednesday: The ACME client POSTs to the existing challenge URL with a key authorization based on its current account key: POST /acme/challenge/l-2zFCdEQT3H5adBnO_WFuTAA3t4BV4hnFqWwtlgnpo/8543 =2E.. note: JWK wrapping elided ... { "keyAuthorization": "LC2eEY_9lRLgxUfCME6TMB4bS0wslm2PDLTC2-JU-YY.bJcgrK6oTvjgvkuMOOkpdS8BdOot= qf_z9T8zw-eFWOE" } =2E.. Note: The key authorization in this POST contains the current account key thumbprint. If it contained the old account key thumbprint, the ACME server would reject it. 4. Wednesday: The ACME server accepts the challenge update, and makes a validation request to http://www.example.com/.well-known/acme-challenge/LC2eEY_9lRLgxUfCME6TMB4= bS0wslm2PDLTC2-JU-YY. It receives a response "LC2eEY_9lRLgxUfCME6TMB4bS0wslm2PDLTC2-JU-YY.MKgAB8ljZpQv0hxuipA70L0SZkmX= IUhbO61fR3vKvj8". However, the ACME server was expecting "LC2eEY_9lRLgxUfCME6TMB4bS0wslm2PDLTC2-JU-YY.bJcgrK6oTvjgvkuMOOkpdS8BdOot= qf_z9T8zw-eFWOE", because that's what was POSTed as part of the challenge update. So the validation request fails, and `www.example.com` has to start the whole issuance process all over again. There's one additional piece of context here: We assume that the hosting provider operating the ACME client doesn't yet control `www.example.com`. This can happen, for instance, when a hosting provider is trying to onboard a customer who already uses HTTPS. The hosting provider needs to have a valid certificate in place *before* the customer CNAMEs their domain name the the hosting provider. The "clarify impact of roll-over" PR (https://github.com/ietf-wg-acme/acme/pull/323/files) is a nice clarification, but doesn't actually address this use case. The issue here is what happens during the period between creation of a challenge and the ACME client requesting validation of that challenge, which in current implementations can be up to 7 days. There are two main approaches I see: A) We could change the spec to set the keyAuthorization field when a challenge is created, so that it would have the current account key thumbprint baked in. This would allow hosting providers to treat the key authorization more like an opaque string, and calculate it at challenge creation time rather than at challenge update time. B) We could encourage implementers to shorten the time between challenge creation and validation by doing delegation. That is, instead of giving `www.example.com` a token, and waiting for them to deploy it, the hosting provider could say "Please delegate issuance authority to us, either by redirecting all of /.well-known/acme-validation/* to our validation server, or by CNAMEing _acme-challenge.www.example.com to our validation server." The main problems with this: the owners of `www.example.com` may not be familiar enough with redirects (although CNAMEs should be easy); the owners of `www.example.com` may have a concurrently running ACME client of their own that needs to renew during the time window they would be serving a redirect or CNAME. --------------BC0F4D2DCDFE6298CC3604F1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 06/20/2017 03:07 PM, Dunning, John wrote:
I would advocate for the new one.  IOW, I would (expect to) interpret the semantics as being

1. The challenge token was created with respect to an account
2. An attribute of the account is the credential (whichever credential is current)
3. Therefore the credential authorizes access to anything associated with the account.

If the concensus here is that a server needs to associate the credential which was in force at creation time with a challenge token, in other words that the token is tied to the credential rather than the account, I believe my use case would be ok with that, as long as the challenge tokens do not go invalid after the credential change.
This seems different from the behavior I thought you were looking for, based on previous conversations. This may be a difference in interpretation of "challenge token" vs "key authorization." Every challenge has a random "token" field, but this is only a part of what gets provisioned to a web server for HTTP-01. For an HTTP-01 challenge, the ACME client calculates a "key authorization" as "<token>.<account key thumbprint>". The client then POSTs a signed request to the challenge URL, containing a "keyAuthorization" field containing this key authorization. The ACME server then requests "/.well-known/acme-validation/<token>" from the validation domain, and expects "<token>.<account key thumbprint>" (that is, the key authorization object) in response.

I think a more customary way of talking would be to call this "key authorization" object that is provisioned on the validation domain a "challenge token." And in fact, in an earlier (pre-draft-01) version of the ACME spec, the "token" field of a challenge was provisioned on the validation domain and requested by the ACME server. However, some people on the list pointed out that this would encourage development of "naive" challenge solvers that would just echo the token part of the URL. So we wound up in this awkward state where what most people would consider a "challenge token" is, in ACME, considered a "key authorization."

As I understand the situation we're trying to solve, it's something like this:

1. Monday: an ACME client operated by a hosting provider receives a request for a certificate for `www.example.com`. This ACME client requests an authorization object from the server, and receives one. The authorization object contains a challenge of type "HTTP-01":

{
  "type": "http-01",
  "status": "pending",
  "uri": "https://ca.example.net/acme/challenge/l-2zFCdEQT3H5adBnO_WFuTAA3t4BV4hnFqWwtlgnpo/8543",
  "token": "LC2eEY_9lRLgxUfCME6TMB4bS0wslm2PDLTC2-JU-YY",
}

The client's current account key has a thumbprint of "MKgAB8ljZpQv0hxuipA70L0SZkmXIUhbO61fR3vKvj8", so it calculates a key authorization by concatenating that with the challenge token field: "LC2eEY_9lRLgxUfCME6TMB4bS0wslm2PDLTC2-JU-YY.MKgAB8ljZpQv0hxuipA70L0SZkmXIUhbO61fR3vKvj8". It then tells the owner of `example.com` to put a file containing that string at "/.well-known/acme-challenge/LC2eEY_9lRLgxUfCME6TMB4bS0wslm2PDLTC2-JU-YY". The owners of `www.example.com` say "Okay, but that will take a few days.

2. Tuesday: The ACME client rotates its account key as part of regular maintenance. The new account key thumbprint is "bJcgrK6oTvjgvkuMOOkpdS8BdOotqf_z9T8zw-eFWOE".

3. Wednesday: `www.example.com` says "Okay, I've created a file at "/.well-known/acme-challenge/LC2eEY_9lRLgxUfCME6TMB4bS0wslm2PDLTC2-JU-YY", and it contains "LC2eEY_9lRLgxUfCME6TMB4bS0wslm2PDLTC2-JU-YY.MKgAB8ljZpQv0hxuipA70L0SZkmXIUhbO61fR3vKvj8". The account key thumbprint in this file (the part after the ".") is out of date, because the ACME client rotated its account key.

3. Wednesday: The ACME client POSTs to the existing challenge URL with a key authorization based on its current account key:

POST /acme/challenge/l-2zFCdEQT3H5adBnO_WFuTAA3t4BV4hnFqWwtlgnpo/8543

... note: JWK wrapping elided ...
{
  "keyAuthorization": "LC2eEY_9lRLgxUfCME6TMB4bS0wslm2PDLTC2-JU-YY.bJcgrK6oTvjgvkuMOOkpdS8BdOotqf_z9T8zw-eFWOE"
}
...

Note: The key authorization in this POST contains the current account key thumbprint. If it contained the old account key thumbprint, the ACME server would reject it.

4. Wednesday: The ACME server accepts the challenge update, and makes a validation request to http://www.example.com/.well-known/acme-challenge/LC2eEY_9lRLgxUfCME6TMB4bS0wslm2PDLTC2-JU-YY. It receives a response "LC2eEY_9lRLgxUfCME6TMB4bS0wslm2PDLTC2-JU-YY.MKgAB8ljZpQv0hxuipA70L0SZkmXIUhbO61fR3vKvj8". However, the ACME server was expecting "LC2eEY_9lRLgxUfCME6TMB4bS0wslm2PDLTC2-JU-YY.bJcgrK6oTvjgvkuMOOkpdS8BdOotqf_z9T8zw-eFWOE", because that's what was POSTed as part of the challenge update. So the validation request fails, and `www.example.com` has to start the whole issuance process all over again.


There's one additional piece of context here: We assume that the hosting provider operating the ACME client doesn't yet control `www.example.com`. This can happen, for instance, when a hosting provider is trying to onboard a customer who already uses HTTPS. The hosting provider needs to have a valid certificate in place *before* the customer CNAMEs their domain name the the hosting provider.

The "clarify impact of roll-over" PR (https://github.com/ietf-wg-acme/acme/pull/323/files) is a nice clarification, but doesn't actually address this use case. The issue here is what happens during the period between creation of a challenge and the ACME client requesting validation of that challenge, which in current implementations can be up to 7 days.

There are two main approaches I see:

A) We could change the spec to set the keyAuthorization field when a challenge is created, so that it would have the current account key thumbprint baked in. This would allow hosting providers to treat the key authorization more like an opaque string, and calculate it at challenge creation time rather than at challenge update time.

B) We could encourage implementers to shorten the time between challenge creation and validation by doing delegation. That is, instead of giving `www.example.com` a token, and waiting for them to deploy it, the hosting provider could say "Please delegate issuance authority to us, either by redirecting all of /.well-known/acme-validation/* to our validation server, or by CNAMEing _acme-challenge.www.example.com to our validation server." The main problems with this: the owners of `www.example.com` may not be familiar enough with redirects (although CNAMEs should be easy); the owners of `www.example.com` may have a concurrently running ACME client of their own that needs to renew during the time window they would be serving a redirect or CNAME.
--------------BC0F4D2DCDFE6298CC3604F1-- From nobody Mon Jun 26 12:52:45 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2EF120726 for ; Mon, 26 Jun 2017 12:52:43 -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, RCVD_IN_DNSWL_HI=-5, 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 hdlfFWvFHZ4B for ; Mon, 26 Jun 2017 12:52:42 -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 2B8721204DA for ; Mon, 26 Jun 2017 12:52:42 -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:Cc:To:Subject; bh=yR8lGTjZi7aSeSVfzBnzI55xGcYYh7qIlFxsrEE59zc=; b=5d/ApEpRUVFoVKikVAlVT4Tt/z+92hTe3RgCQ6yJQed2qIM/7U87CB0luTsd2ZDvXoJvB4khdR1oLymER3jO3dbH1+KfghgiahkhE8I0nVAvOBp1gHWZ/UayKIIIO+2cDDEFYAwYycqu4N0b4q6W+L/C4QZOlZXn1ecVpT7UVHM=; Received: ; Mon, 26 Jun 2017 12:52:40 -0700 To: Ilari Liusvaara , Ted Hardie Cc: "Salz, Rich" , "acme@ietf.org" , Yoav Nir References: <149807165247.15932.14866158682370663408@ietfa.amsl.com> <20170626141526.js5lufvbl4gvxb6i@LK-Perkele-VII> From: Jacob Hoffman-Andrews Message-ID: <641a8672-4d3b-1a88-5fb8-963064330bad@eff.org> Date: Mon, 26 Jun 2017 12:52:41 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170626141526.js5lufvbl4gvxb6i@LK-Perkele-VII> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] fields to include in challenge response X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 19:52:43 -0000 On 06/26/2017 07:15 AM, Ilari Liusvaara wrote: > I was trying to write some code, and noticed a potential inconsistency:= > > Section 7.5.1 has in example (responding to HTTP-01 challenge): > > "payload": base64url({ > "type": "http-01", > "keyAuthorization": "IlirfxKKXA...vb29HhjjLPSggwiE" > }), > > ... Type field is present. > > > But section 8.3 has: > > "payload": base64url({ > "keyAuthorization": "evaGxfADs...62jcerQ" > }), > > ... No type field. In general, ACME has "partial update" semantics on POSTs. So fields that aren't changing, or aren't permitted to be changed by the client, like "type", "status", "url" and "token", can be omitted. The spec says: > The server updates the authorization document by updating its representation of the challenge with the response fields provided by the client. > The server MUST ignore any fields in the response object that are not specified as response fields for this type of challenge. The server provides a 200 (OK) response with the updated challenge object as its bod= y. This is actually a bit confusing because we don't ever define "response fields", but they are defined by the individual challenge types. We should probably update the parts of those challenge definitions that define response fields to describe them that way. https://github.com/ietf-wg-acme/acme/issues/329 For DNS-01, HTTP-01, and TLS-SNI-02, the only response field is "keyAuthorization". For OOB-01, the only response field is "type". I suspect this was just to avoid having an empty payload, but I think an empty payload is fine, and this is confusingly different from the others, so we should change OOB-01 to just take an empty payload. https://github.com/ietf-wg-acme/acme/issues/328 So, of the examples you point out, the one in 7.5.1 should be updated to remove the "type" field: https://github.com/ietf-wg-acme/acme/pull/327. From nobody Mon Jun 26 14:11:15 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16DEB12EB74 for ; Mon, 26 Jun 2017 14:11:14 -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, RCVD_IN_DNSWL_HI=-5, 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 o1LSyE-D_DWX for ; Mon, 26 Jun 2017 14:11:12 -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 8AE5F12EB72 for ; Mon, 26 Jun 2017 14:11:12 -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=VRiKT6/SpKwY4AJinkjw6ggNOEuAzWMCEpAMVTzRniY=; b=U2mmB7j2jv38aAM4OtBbP08VSi4raVXcFcWILDqm47DGlAHmw7rSvjcnmlHwa4dSE1A5MS3WvcnvEofJjLuw706gKMsyDEveuk+PRKwhJURCMAruR0gkhuQumTqW55gPrIqB05+1Qiggo+PKeKImNylw+YUHHdj32fj/Eniy4N4=; Received: ; Mon, 26 Jun 2017 14:11:11 -0700 To: Rifaat Shekh-Yusef , acme@ietf.org References: From: Jacob Hoffman-Andrews Message-ID: Date: Mon, 26 Jun 2017 14:11:11 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] ACME v06 - Pre-Authorization X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 21:11:14 -0000 On 06/07/2017 05:50 AM, Rifaat Shekh-Yusef wrote: > What is the expected behavior of the server if the client sends the > certificate issuance request after it sends the pre-authorization > request but > before it completes the pre-authorization process? By "certificate issuance request," I assume you mean the "new-order" request? The server would create an order object with one or more authorizations objects that need to be fulfilled. Once those authorizations became valid, the server would issue the certificate. In other words, this is equivalent to the default flow without pre-authorization. > Also, since the pre-authorization process is expected to deal with > multiple > servers/endpoints requesting certificates, should this process be enhanced > to support bulk requests? I don't understand this question. Can you clarify? What sort of enhancement are you imagining? > Nits: Filed an issue: https://github.com/ietf-wg-acme/acme/issues/330 From nobody Mon Jun 26 14:59:49 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86249126BF0 for ; Mon, 26 Jun 2017 14:59:47 -0700 (PDT) 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, 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 es_0OS74gE4L for ; Mon, 26 Jun 2017 14:59: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 33013126B7F for ; Mon, 26 Jun 2017 14:59: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:References:To:Subject; bh=jObPmiCVJz4XHwHx3xY+kwYbHaturqvWQOmQ7bACUb8=; b=HzrdHXbqQ20ttNJUlViQRfGIndsU8IVppnxnxeOGcnV1kcJMEBnukfGSE9npJ1Nted7IzaQoFy3XUu3LIb+JVTEFFMSFx/IifYODmdvmsk8yh6Wwo+pDeF1YXK7xrAnYqAUq65hJv/rV+hy26wh+SkrAQ+AHQcDijvsK9JoPnto=; Received: ; Mon, 26 Jun 2017 14:59:43 -0700 To: Yaron Sheffer , acme@ietf.org References: <7526b3be-65ec-29b6-d657-3e19be06ea6a@gmail.com> From: Jacob Hoffman-Andrews Message-ID: <6f94a112-fc96-485c-cca6-556bf8cfad55@eff.org> Date: Mon, 26 Jun 2017 14:59:44 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <7526b3be-65ec-29b6-d657-3e19be06ea6a@gmail.com> Content-Type: multipart/alternative; boundary="------------283EE6030B5AFCA06347A695" Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] ACME -06: HTTPS authorization X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 21:59:47 -0000 This is a multi-part message in MIME format. --------------283EE6030B5AFCA06347A695 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 05/30/2017 08:32 AM, Yaron Sheffer wrote: > - The server only supports HTTPS, and perhaps port 80 is blocked by a > firewall. This situation applies to many REST endpoints. This is in general a bad configuration. Leaving port 80 open for the purposes of redirects is safe, and provides a better first-time users experience (repeat users may take advantage of an HSTS header, which I would assume to be present in such a config). And keep in mind that validation in ACME follows redirects. > - I am migrating from a non-ACME to an ACME cert, and so the server > has a perfectly valid HTTPS cert. Or migrating from one ACME CA to a > different one. This doesn't make it harder to server HTTP on port 80. > - I would like to ensure (using CAA records) that my CA is not subject > to a DNS cache corruption attack - a threat that the ACME Security > Considerations specifically mention. I think this is the most compelling reason to offer HTTPS authorization. In particular, I think it may make sense as a special requirement for "high risk" validations. That is, for certain validations, the ACME server may choose to require validation over HTTPS using a certificate that validates to a certain set of roots. However, requiring validation over HTTPS using a valid certificate would be too onerous for general-purpose certificates, because it would mean that server operators who lose their account key and all certificate private keys could not recover and issue a certificate without manual intervention. I think HTTPS-with-valid-certificate is an interesting topic for future implementation, but is complex enough that we shouldn't try to squeeze it into the current document. --------------283EE6030B5AFCA06347A695 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 05/30/2017 08:32 AM, Yaron Sheffer wrote:
- The server only supports HTTPS, and perhaps port 80 is blocked by a firewall. This situation applies to many REST endpoints.
This is in general a bad configuration. Leaving port 80 open for the purposes of redirects is safe, and provides a better first-time users experience (repeat users may take advantage of an HSTS header, which I would assume to be present in such a config). And keep in mind that validation in ACME follows redirects.

- I am migrating from a non-ACME to an ACME cert, and so the server has a perfectly valid HTTPS cert. Or migrating from one ACME CA to a different one.
This doesn't make it harder to server HTTP on port 80.
- I would like to ensure (using CAA records) that my CA is not subject to a DNS cache corruption attack - a threat that the ACME Security Considerations specifically mention.
I think this is the most compelling reason to offer HTTPS authorization. In particular, I think it may make sense as a special requirement for "high risk" validations. That is, for certain validations, the ACME server may choose to require validation over HTTPS using a certificate that validates to a certain set of roots.

However, requiring validation over HTTPS using a valid certificate would be too onerous for general-purpose certificates, because it would mean that server operators who lose their account key and all certificate private keys could not recover and issue a certificate without manual intervention.

I think HTTPS-with-valid-certificate is an interesting topic for future implementation, but is complex enough that we shouldn't try to squeeze it into the current document.
--------------283EE6030B5AFCA06347A695-- From nobody Mon Jun 26 15:14:36 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A545C12EB72 for ; Mon, 26 Jun 2017 15:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ONlIEvy2uJkb for ; Mon, 26 Jun 2017 15:14:33 -0700 (PDT) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 0DED712EB07 for ; Mon, 26 Jun 2017 15:14:33 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id f127so1798344pgc.2 for ; Mon, 26 Jun 2017 15:14:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=c897tF71YrgwljQwcTdF5ngcfots7u9aLqGm3zIr3AU=; b=iytCe1jvxTK2Mj10NnzTOzmFVt4NwBPlW+SJsm2AtKt0gP6KMh381pTa4kGH2shOyo U+slgpWj2a01Lq/2g2sa0VQr2cCkMls/leab1Y7LTB+R8QTyUMNuYZRR4BWnKrzocP2H WonLRFrv7F67UrGK/1LkNomp4wj60DIinBew4IPtElmLr1l47+DXgLY9WpqWm/zc41Xu 28tqe2Prn20xhRG1mt53rGvnzWkfDeLLrXpIO7V4dJyZrTHxIUdpgMuR2BsdgbTTLLob GgVP7Xp0GP0PDi6yl21HhCDmrFoxIILUVTfcE8+CCV0ctJwijQW2Hrd6LPlhOP20QPo1 /LRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=c897tF71YrgwljQwcTdF5ngcfots7u9aLqGm3zIr3AU=; b=OjDAMwXwgMSQwNL2sWmJRdZigoap3lT9R9oENeylxEIPrwsDRy3gKeOd3ycqYF2EBQ /rann0CvCTIldWxAUrgahmGtoVJ00OnqbO+EJUkk+b+KWdoQeK1aumuiYPohxQnLLKU7 7yTKzxH3d4EeJaCn+mhP401FuG5Hk4X2/SYaG1xbe6UW5HsImE28Rb3k7SBBp4GEe/Ot fROJ6XJ/TwLu/F2MHcmmmZ0R6nOGylf7dU/4+rRf0MSHTIrAuKQYRLRUx2wuZyh//iDB 4VN+sVFdfnRlFm2FEczyFNltFWTCdhV0sHY66bxrZfEQsAkKS+9JWvpEABIY/aYy+sgL yNvA== X-Gm-Message-State: AKS2vOyxPrvKBNv1HfW6UbzEOh2dUbsjBIpYm54FK1WJjTT3vFE8/nQ6 fuHrlgZFUuTz0MLHl7g= X-Received: by 10.84.231.15 with SMTP id f15mr2411968plk.131.1498515272394; Mon, 26 Jun 2017 15:14:32 -0700 (PDT) Received: from [172.28.160.124] ([65.204.229.81]) by smtp.gmail.com with ESMTPSA id d18sm2161495pgn.27.2017.06.26.15.14.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jun 2017 15:14:31 -0700 (PDT) To: Jacob Hoffman-Andrews , acme@ietf.org References: <7526b3be-65ec-29b6-d657-3e19be06ea6a@gmail.com> <6f94a112-fc96-485c-cca6-556bf8cfad55@eff.org> From: Yaron Sheffer Message-ID: <3a3e6830-9ef0-dac6-772c-7789873bbbe3@gmail.com> Date: Mon, 26 Jun 2017 15:14:31 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <6f94a112-fc96-485c-cca6-556bf8cfad55@eff.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Acme] ACME -06: HTTPS authorization X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 22:14:35 -0000 Hi Jacob, To your first point, I was talking specifically of REST endpoints, not of people accessing web servers from a browser. For such configurations I think you will agree that HTTPS-only is a valid setup. Thanks, Yaron On 26/06/17 14:59, Jacob Hoffman-Andrews wrote: > On 05/30/2017 08:32 AM, Yaron Sheffer wrote: >> - The server only supports HTTPS, and perhaps port 80 is blocked by a >> firewall. This situation applies to many REST endpoints. > This is in general a bad configuration. Leaving port 80 open for the > purposes of redirects is safe, and provides a better first-time users > experience (repeat users may take advantage of an HSTS header, which I > would assume to be present in such a config). And keep in mind that > validation in ACME follows redirects. > >> - I am migrating from a non-ACME to an ACME cert, and so the server >> has a perfectly valid HTTPS cert. Or migrating from one ACME CA to a >> different one. > This doesn't make it harder to server HTTP on port 80. >> - I would like to ensure (using CAA records) that my CA is not >> subject to a DNS cache corruption attack - a threat that the ACME >> Security Considerations specifically mention. > I think this is the most compelling reason to offer HTTPS > authorization. In particular, I think it may make sense as a special > requirement for "high risk" validations. That is, for certain > validations, the ACME server may choose to require validation over > HTTPS using a certificate that validates to a certain set of roots. > > However, requiring validation over HTTPS using a valid certificate > would be too onerous for general-purpose certificates, because it > would mean that server operators who lose their account key and all > certificate private keys could not recover and issue a certificate > without manual intervention. > > I think HTTPS-with-valid-certificate is an interesting topic for > future implementation, but is complex enough that we shouldn't try to > squeeze it into the current document. From nobody Tue Jun 27 05:15:09 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9882127868 for ; Tue, 27 Jun 2017 05:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 kGxa1_l0GQa6 for ; Tue, 27 Jun 2017 05:15:05 -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 3A17F120227 for ; Tue, 27 Jun 2017 05:15:05 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id 191so14801007vko.2 for ; Tue, 27 Jun 2017 05:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=loi138RAQvVE46b1x/DXnZAtbLvPVisEesCw44ZmNJ0=; b=tNE6YYEMDCaMJqXfKGQpdJMXugWubZ/F7QGY4sXV16KoY7pu5/MvPYL2gWlikyBjLr 2D9Gw7xTCQ4etAIuwvMvbHP/g4xhZfdzOnrbKcHOkTScJNzAvQ07ujj5aeSD3LJvaW6z P5Pvge3AwxTlZxc/wmNH5EG0OdVheaZWO+jexg2Ayb/ED03jtTri2V1MzzVJAV4YntiP iPdQlJBlKkjjiusIXR0WPMJ9Pby2AV8Xp8pmkZP0e/zrxB1vDXleuSZC/6yh3NDCMrvq 0eRy5I9WTlSOa/CP/b78VhHzRGEeYNjq+aFa2/0LRG21JmS5+KFrFmFtMors8HxRKbAM mJPQ== 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=loi138RAQvVE46b1x/DXnZAtbLvPVisEesCw44ZmNJ0=; b=a6x++9EAs/kqcDXIkBIfGATqLjm0opbZCM0g088Iaha1HYOR3YJwxwW7IQZ1vK4TCs 19P3bnJ3jIpktoWYpLQbrD5rMt3DKB049ZHzvCc1Ekm5jJ1J5aIfJJDYnr2vm3PwAyL3 TovzOPMvHu8imR6BytJsrvvOXA2ZkSkF/ISSQ6ihFDGCThJzHBj2J97QZVEtGt7MEIjX +58X+DkH3DisSc8JjQ3T9FpKVJqvJWs9hTnvFD6IUvWNSm0BEAH1LQEbcsgPFhh2Xky+ HCnW8Av+8MT1esiqZYw09j8/LSSFmag9tQ69/OMrMk5hrSlkBDb9DGdVEwJeDJDsQ+GT I8bg== X-Gm-Message-State: AKS2vOxXl5IWQp+JXPKiFV9zF8oWSPx8zAgvhrfly9ezZ+gDEeoCEepK LgCfUFHk+3UO1CC2lRwfEQAj4F83Jw== X-Received: by 10.31.157.2 with SMTP id g2mr2526631vke.60.1498565704413; Tue, 27 Jun 2017 05:15:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.76.29 with HTTP; Tue, 27 Jun 2017 05:15:04 -0700 (PDT) In-Reply-To: References: From: Rifaat Shekh-Yusef Date: Tue, 27 Jun 2017 08:15:04 -0400 Message-ID: To: Jacob Hoffman-Andrews Cc: acme@ietf.org Content-Type: multipart/alternative; boundary="001a11415dbe7bf7c10552f00476" Archived-At: Subject: Re: [Acme] ACME v06 - Pre-Authorization X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 12:15:08 -0000 --001a11415dbe7bf7c10552f00476 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 26, 2017 at 5:11 PM, Jacob Hoffman-Andrews wrote: > On 06/07/2017 05:50 AM, Rifaat Shekh-Yusef wrote: > > What is the expected behavior of the server if the client sends the > > certificate issuance request after it sends the pre-authorization > > request but > > before it completes the pre-authorization process? > By "certificate issuance request," I assume you mean the "new-order" > request? Yes > The server would create an order object with one or more > authorizations objects that need to be fulfilled. My point is that the pre-authorization request (i.e. new-authz) would have already created a pending authorization object with the challenges for the client. I am assuming that when the server responds to the new-order request, it would provide the same challenges provided in the new-authz request; correct? In any case, I think this should be clearly specified in the document. > Once those > authorizations became valid, the server would issue the certificate. In > other words, this is equivalent to the default flow without > pre-authorization. > > > Also, since the pre-authorization process is expected to deal with > > multiple > > servers/endpoints requesting certificates, should this process be > enhanced > > to support bulk requests? > I don't understand this question. Can you clarify? What sort of > enhancement are you imagining? > What I have in mind for this is that ACME client might be representing more than one entity when it is using the pre-authorization procedure, as specified in section 7.4.1. The use case I have in mind is to use this pre-authorization mechanism for a client to issue certificates for large number of *endpoints*. Instead of sending a new-authz request per endpoint, it might be useful to allow the client to send one request for a list of endpoints. Regards, Rifaat > > Nits: > Filed an issue: https://github.com/ietf-wg-acme/acme/issues/330 > --001a11415dbe7bf7c10552f00476 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jun 26, 2017 at 5:11 PM, Jacob Hoffman-Andrews <jsha@eff.org>= ; wrote:
On 06/07= /2017 05:50 AM, Rifaat Shekh-Yusef wrote:
> What is the expected behavior of the server if the client sends the > certificate issuance request after it sends the pre-authorization
> request but
> before it completes the pre-authorization process?
By "certificate issuance request," I assume you mean the &= quot;new-order"
request?

Yes
=C2=A0
The server would create an order object with one or= more
authorizations objects that need to be fulfilled.

My point is that the pre-authorization request (i.e. new-authz) wou= ld have already created=C2=A0
a pending authorization object with= the challenges for the client.

I am assuming that= when the server responds to the new-order request, it would provide the sa= me=C2=A0
challenges provided in the new-authz request; correct?
In any case, I think this should be clearly specified in the docum= ent.

=C2=A0
On= ce those
authorizations became valid, the server would issue the certificate. In
other words, this is equivalent to the default flow without
pre-authorization.

> Also, since the pre-authorization process is expected to deal with
> multiple
> servers/endpoints requesting certificates, should this process be enha= nced
> to support bulk requests?
I don't understand this question. Can you clarify? What sort of<= br> enhancement are you imagining?

What I h= ave in mind for this is that ACME client might be representing more than on= e entity=C2=A0
when it is using the pre-authorization procedure, = as specified in section 7.4.1.

The use case I have= in mind is to use this pre-authorization mechanism for a client to issue c= ertificates
for large number of endpoints.

<= /div>
Instead of sending a new-authz request per endpoint, it might be = useful to allow the client to send one=C2=A0
request for a list o= f endpoints.

Regards,
=C2=A0Rifaat
=


=C2=A0
> Nits:
Filed an issue: https://github.com/ietf-wg-acme/= acme/issues/330

--001a11415dbe7bf7c10552f00476-- From nobody Tue Jun 27 11:29:38 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DC21292FD for ; Tue, 27 Jun 2017 11:29:37 -0700 (PDT) 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, 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 XfLmxhwFKrGd for ; Tue, 27 Jun 2017 11:29:35 -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 D462B127137 for ; Tue, 27 Jun 2017 11:29:34 -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:References:Cc:To:Subject; bh=DnnGBTgem+pdzltIjEwG2RC4iWjG6Zq7qxHMQit1694=; b=wh+OumqjQVnZM84XCYuEEh2NmYiKImeVYCt0Gn5a/ChgRri1v18DbPkImBx02NKncrvf0XrKPJ6TVq0URldUPZ0VsSGXK0fG6Y7gc8I++y05u7zVWZ+DUSDx9hLj2yFDLS288Ufy+/9oi6FI7PYkJmvaul5qLnNJG6d4CLHDxw0=; Received: ; Tue, 27 Jun 2017 11:29:33 -0700 To: Rifaat Shekh-Yusef Cc: acme@ietf.org References: From: Jacob Hoffman-Andrews Message-ID: <5c4422a1-6fbf-f3cf-18d8-41d0901e99ae@eff.org> Date: Tue, 27 Jun 2017 11:29:34 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------97E85CCE49B7720461E54831" Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] ACME v06 - Pre-Authorization X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 18:29:37 -0000 This is a multi-part message in MIME format. --------------97E85CCE49B7720461E54831 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 06/27/2017 05:15 AM, Rifaat Shekh-Yusef wrote: > > > The server would create an order object with one or more > authorizations objects that need to be fulfilled. > > > My point is that the pre-authorization request (i.e. new-authz) would > have already created > a pending authorization object with the challenges for the client. The ACME server MAY reuse existing pending authorizations, or it may create new ones. You should not rely on the pending authorizations that result from a new-order request being the same as ones previously created by new-authz requests. > > What I have in mind for this is that ACME client might be representing > more than one entity > when it is using the pre-authorization procedure, as specified in > section 7.4.1. > > The use case I have in mind is to use this pre-authorization mechanism > for a client to issue certificates > for large number of *endpoints*. > > Instead of sending a new-authz request per endpoint, it might be > useful to allow the client to send one > request for a list of endpoints. I'm not clear what you mean by entity and endpoint in this question. Are you thinking of people, machines, companies, DNS names, IP addresses, or something else? --------------97E85CCE49B7720461E54831 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 06/27/2017 05:15 AM, Rifaat Shekh-Yusef wrote:
 
The server would create an order object with one or more
authorizations objects that need to be fulfilled.

My point is that the pre-authorization request (i.e. new-authz) would have already created 
a pending authorization object with the challenges for the client.
The ACME server MAY reuse existing pending authorizations, or it may create new ones. You should not rely on the pending authorizations that result from a new-order request being the same as ones previously created by new-authz requests.


What I have in mind for this is that ACME client might be representing more than one entity 
when it is using the pre-authorization procedure, as specified in section 7.4.1.

The use case I have in mind is to use this pre-authorization mechanism for a client to issue certificates
for large number of endpoints.

Instead of sending a new-authz request per endpoint, it might be useful to allow the client to send one 
request for a list of endpoints.
I'm not clear what you mean by entity and endpoint in this question. Are you thinking of people, machines, companies, DNS names, IP addresses, or something else?
--------------97E85CCE49B7720461E54831-- From nobody Tue Jun 27 12:05:33 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624B312EAFB for ; Tue, 27 Jun 2017 12:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 aAs1O4kPjIN6 for ; Tue, 27 Jun 2017 12:05:30 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 589231292F5 for ; Tue, 27 Jun 2017 12:05:30 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id w19so3553934uac.0 for ; Tue, 27 Jun 2017 12:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/JyosKBINl3Rf66wPkRHyp5YyTFiq8NYlDhcBpOK5Ik=; b=MhCyKqkuPV+jAo2Kry0D8jmjTVidLVr+sPPqPKmXoprdF4b3ubRkXnFZ03vZaAQB3s Tzcwet7JGbNFwIeF/s/G8xolCRk+FQc9ahgORKjzS/31+nI+N7aedRb4mj4jZ8aW6StK ZyvdioVcI9N2IezrkcazorDBi0b7GCxs9B4hD1UMfpx/Pja3nLyNIXV7G7R734uEXvsA XnrVrIAOez1p2Rj4TxV6xIDqnkVP2F96cUwWqTrhC8rH0kytoT3Vmds7WMPoy2VfakeJ iS1tqUSjFD6KhA0Bm9cXptH7hJkwREEl5iZpiyCLd1SfzdpgaBTCzjxMrLQJD/7HG4fE FGuQ== 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=/JyosKBINl3Rf66wPkRHyp5YyTFiq8NYlDhcBpOK5Ik=; b=Por+gezxZDDMI8bOzi43XubX9P4bXjMtaV4QluIMorqaTGDfn5pW2y3c2AU6klUygx V/IC8f/lepvRRO4XoMMUW9TZGj6Jhh+rGmxIATJW3f5JLSh8nWtbcdxcXSe6ME2/o1Ys s935LKzawpigwKwQ0g8X2LaU7B/fppSB1HnKxEA5COEmKGi8XCvro3ysvbCnKzMqQ/xr fkLNHV8Fkvn8qYfWHvn47AtgnGMXPNJ0cXASTV2ci1Z/Fw8oDOTmB9tOg+zJi7y1s/VG PsNgcdvz/eXXL4vCg19GrcHqOg1TDTsKDd2M7QcSOcLsqFFQGasIOAEFYnYLc7hC9UuL TmXg== X-Gm-Message-State: AKS2vOyd/dHZ9BdUhZMN6iuCQiWO+qj0fMBjk3LdG904I5KkqzcsuxqE Njn0SDIQeOy5koV6cd0NBrTnLy9D0A== X-Received: by 10.176.78.29 with SMTP id g29mr4101934uah.55.1498590329503; Tue, 27 Jun 2017 12:05:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.76.29 with HTTP; Tue, 27 Jun 2017 12:05:29 -0700 (PDT) In-Reply-To: <5c4422a1-6fbf-f3cf-18d8-41d0901e99ae@eff.org> References: <5c4422a1-6fbf-f3cf-18d8-41d0901e99ae@eff.org> From: Rifaat Shekh-Yusef Date: Tue, 27 Jun 2017 15:05:29 -0400 Message-ID: To: Jacob Hoffman-Andrews Cc: acme@ietf.org Content-Type: multipart/alternative; boundary="f40304378a6c4108b10552f5c0ba" Archived-At: Subject: Re: [Acme] ACME v06 - Pre-Authorization X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 19:05:32 -0000 --f40304378a6c4108b10552f5c0ba Content-Type: text/plain; charset="UTF-8" On Tue, Jun 27, 2017 at 2:29 PM, Jacob Hoffman-Andrews wrote: > On 06/27/2017 05:15 AM, Rifaat Shekh-Yusef wrote: > > > >> The server would create an order object with one or more >> authorizations objects that need to be fulfilled. > > > My point is that the pre-authorization request (i.e. new-authz) would have > already created > a pending authorization object with the challenges for the client. > > The ACME server MAY reuse existing pending authorizations, or it may > create new ones. You should not rely on the pending authorizations that > result from a new-order request being the same as ones previously created > by new-authz requests. > > Fair enough. What would be the response from the server when it reuses existing pending authorization? 200 OK with the existing challenge? Could that be spelled out in the document? > > What I have in mind for this is that ACME client might be representing > more than one entity > when it is using the pre-authorization procedure, as specified in section > 7.4.1. > > The use case I have in mind is to use this pre-authorization mechanism for > a client to issue certificates > for large number of *endpoints*. > > Instead of sending a new-authz request per endpoint, it might be useful to > allow the client to send one > request for a list of endpoints. > > I'm not clear what you mean by entity and endpoint in this question. Are > you thinking of people, machines, companies, DNS names, IP addresses, or > something else? > I am thinking of hard endpoints, like deskphones, mobile devices, etc. I am working on an ACME endpoint extension draft that I would like to discuss later that hopefully clarifies the use case and how I think it could fit into the ACME mechanism. Regards, Rifaat --f40304378a6c4108b10552f5c0ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 27, 2017 at 2:29 PM, Jacob Hoffman-Andrews <jsha@eff.org>= ; wrote:
=20 =20 =20
On 06/27/2017 05:15 AM, Rifaat Shekh-Yusef wrote:
=C2=A0
The server would create an order object with one or more
authorizations objects that need to be fulfilled.

My point is that the pre-authorization request (i.e. new-authz) would have already created=C2=A0
a pending authorization object with the challenges for the client.
 The ACME server MAY reuse existing pending authorizations, or it may create new ones. You should not rely on the pending authorizations that result from a new-order request being the same as ones previously created by new-authz requests.


Fair enough.
What would be the response from the server when it reuses existing pendin= g authorization? 200 OK with the existing challenge?
Could that b= e spelled out in the document?
=C2=A0

What I have in mind for this is that ACME client might be representing more than one entity=C2=A0
when it is using the pre-authorization procedure, as specified in section 7.4.1.

The use case I have in mind is to use this pre-authorization mechanism for a client to issue certificates
for large number of endpoints.

Instead of sending a new-authz request per endpoint, it might be useful to allow the client to send one=C2=A0
request for a list of endpoints.
 I'm not clear what you mean by entity and endpoint in this question= . Are you thinking of people, machines, companies, DNS names, IP addresses, or something else?

I am thinking of ha= rd endpoints, like deskphones, mobile devices, etc.
I am working on an ACME endpoint extension draft that I would like= to discuss later that hopefully clarifies the use case and how I think it = could fit into the ACME mechanism.

Regards,
=C2= =A0Rifaat

--f40304378a6c4108b10552f5c0ba-- From nobody Thu Jun 29 19:36:25 2017 Return-Path: X-Original-To: acme@ietf.org Delivered-To: acme@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DD4127876; Thu, 29 Jun 2017 19:36:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: acme@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149879018349.4670.12593787764613433094@ietfa.amsl.com> Date: Thu, 29 Jun 2017 19:36:23 -0700 Archived-At: Subject: [Acme] I-D Action: draft-ietf-acme-caa-02.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 02:36:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Automated Certificate Management Environment of the IETF. Title : CAA Record Extensions for Account URI and ACME Method Binding Author : Hugo Landau Filename : draft-ietf-acme-caa-02.txt Pages : 9 Date : 2017-06-29 Abstract: The CAA DNS record allows a domain to communicate issuance policy to CAs, but only allows a domain to define policy with CA-level granularity. However, the CAA specification also provides facilities for extension to admit more granular, CA-specific policy. This specification defines two such parameters, one allowing specific accounts of a CA to be identified by URI and one allowing specific methods of domain control validation as defined by the ACME protocol to be required. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-acme-caa/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-acme-caa-02 https://datatracker.ietf.org/doc/html/draft-ietf-acme-caa-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-caa-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 29 19:39:03 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276DD126DCA for ; Thu, 29 Jun 2017 19:39:01 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=devever.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKTB1rmuy2qs for ; Thu, 29 Jun 2017 19:38:59 -0700 (PDT) Received: from umbriel.devever.net (umbriel.devever.net [149.202.51.241]) (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 B505D126D85 for ; Thu, 29 Jun 2017 19:38:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 049171D61F for ; Fri, 30 Jun 2017 04:38:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=devever.net; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received; s=mimas; t=1498790337; x=1516979698; bh=tIEyU0eWUpDm72bB2qxGVqyaChrPHKG9Sh/Ae3PsI6o=; b= LwgEZE6YVAvP+8WMqPUhrT/yNBDKcgF7dIb/DSXB6ZpmHfiHmyJf+pIUTR3edLpD XSiiHoFVk3OD4qUJG/sHNZbZBJCBal70WhNKkeuo8+nM04iyB5EEZ8E9vG+Bl4xd jL3OeZAQekExdWj6WiJglRWhM7B4WyCLusz0n6lhrEJq6F0WG7AR0cCUsGRHIbJA Q0PHajlXkJT4Jp+qPKtlU/b8ZY37Lch7uFlA78vYN8WSpXWTIDX4YA1sVHaEEpEs Bii5feGUKMFiR2O84g9gzsP57mTx4+rkS1FIAul1WxzTX3j1DTUIQqCMBzu1oPIb kndijbZuiHurmAfz4WjSoQ== Received: from umbriel.devever.net ([127.0.0.1]) by localhost (umbriel.devever.net [127.0.0.1]) (amavisd-new, port 10026) with LMTP id z-F1o-PnLBjQ for ; Fri, 30 Jun 2017 04:38:57 +0200 (CEST) Received: from andover.lhh.devever.net (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with SMTP id BD3851D61E for ; Fri, 30 Jun 2017 04:38:57 +0200 (CEST) Date: Fri, 30 Jun 2017 03:38:57 +0100 From: Hugo Landau To: acme@ietf.org Message-ID: <20170630023857.GA7142@andover.lhh.devever.net> References: <149879018349.4670.12593787764613433094@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <149879018349.4670.12593787764613433094@ietfa.amsl.com> User-Agent: Mutt/1.8.1 (2017-04-11) Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-caa-02.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 02:39:01 -0000 Since there was no objection on the list, I've incorporated the more readable paragraph discussing the "account-uri" parameter. This is the only change. From nobody Fri Jun 30 07:30:58 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE6A12EC31 for ; Fri, 30 Jun 2017 07:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 gwer1wRJXAqF for ; Fri, 30 Jun 2017 07:30:55 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD39A120227 for ; Fri, 30 Jun 2017 07:30:54 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5UERhjK020087 for ; Fri, 30 Jun 2017 15:30:54 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=19eWxxihUr9JyjH9Lcvw/TF8bV6N+tF/DKoh5ciQ9V8=; b=hIgq/mRNT47TsM5vNszCzjDze+FUpdMr1k3+YE0C6rBN4+H04UfQ0Io0pj8CxrCPMHql oa+xBw5TdISRM06YMuJ7dv8m8GXX+dUooOEUDmQhUd/+GGCh86s5U3W/NbbYqrLuPj/i S4F92YU/0b+5BgVgsFv/MO7iosOk1C69eJRpBu+NRVhe5kMr07NUhu9NCzVHD9h+NXtB MrCjjaDLBle+7KasMO8NXHJZsxOspab5CPjOrvmgQQAzlcUWdv0fpsjgKzv9VEcW2NMQ 3PHLLbPjq1uF1g6U+hjIrhoAkH5zbf7fvqae2Kf/ah+2RMp3Lhe3p0bQqu6AyH2n8PMO 2Q== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2bcx3d7n0j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 30 Jun 2017 15:30:53 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5UEQ1K5023457 for ; Fri, 30 Jun 2017 10:30:53 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2b9kdv3uyp-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 30 Jun 2017 10:30:51 -0400 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.1263.5; Fri, 30 Jun 2017 10:30:40 -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.1263.000; Fri, 30 Jun 2017 10:30:40 -0400 From: "Salz, Rich" To: "acme@ietf.org" Thread-Topic: Consensus -- CAA draft to WGLC? Thread-Index: AdLgaixZ2HxcGKQGRUWoL8+FK3tFFwRQuZIA Date: Fri, 30 Jun 2017 14:30:39 +0000 Message-ID: References: <40e652477a2f47b0848330e64f72e8b2@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <40e652477a2f47b0848330e64f72e8b2@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.34.222] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-30_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706300229 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-30_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706300229 Archived-At: Subject: Re: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 14:30:57 -0000 Based on feedback here, Hugo just posted an updated draft, https://tools.ie= tf.org/html/draft-ietf-acme-caa-02 I would like to advance this to the IESG in a week. Please speak up if you= disagree. Also, still looking for a document shepherd (see https://www.ietf.org/ies= g/template/doc-writeup.html; an essay style writeup is fine). -- =20 Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz From nobody Fri Jun 30 09:51:21 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7E812EC52 for ; Fri, 30 Jun 2017 09:51:19 -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 gG71lQeoIs6X for ; Fri, 30 Jun 2017 09:51:18 -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 5407D12ECF0 for ; Fri, 30 Jun 2017 09:51:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BD4593003FE for ; Fri, 30 Jun 2017 12:51:16 -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 RUV7Z8dOCXo3 for ; Fri, 30 Jun 2017 12:51:15 -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 69564300278; Fri, 30 Jun 2017 12:51:15 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Fri, 30 Jun 2017 12:51:14 -0400 Cc: IETF ACME Content-Transfer-Encoding: quoted-printable Message-Id: References: <40e652477a2f47b0848330e64f72e8b2@usma1ex-dag1mb1.msg.corp.akamai.com> To: Rich Salz X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Acme] Consensus -- CAA draft to WGLC? X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 16:51:20 -0000 I do not see how the comments from Richard Barnes were handled. Russ > On Jun 30, 2017, at 10:30 AM, Salz, Rich wrote: >=20 > Based on feedback here, Hugo just posted an updated draft, = https://tools.ietf.org/html/draft-ietf-acme-caa-02 >=20 > I would like to advance this to the IESG in a week. Please speak up = if you disagree. >=20 > Also, still looking for a document shepherd (see = https://www.ietf.org/iesg/template/doc-writeup.html; an essay style = writeup is fine). >=20 > -- =20 > Senior Architect, Akamai Technologies > Member, OpenSSL Dev Team > IM: richsalz@jabber.at Twitter: RichSalz From nobody Fri Jun 30 09:54:51 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11ED7131101 for ; Fri, 30 Jun 2017 09:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffGXVH_fkvFS for ; Fri, 30 Jun 2017 09:54:45 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D22D130141 for ; Fri, 30 Jun 2017 09:54:45 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5UGqbDi015818; Fri, 30 Jun 2017 17:54:42 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=PBVcz5irs+rvZV8/aExYbjCoYvH+7nlNunnkyDwewZg=; b=R57w36Rljs3cb5dBpJFdKmFjy+Zms0vyueh+1UI+xETgooSAsITfNP0V2xlsdjilD6Or ZNnVNUYieqd6n/WMVpCJZTrsoFHPDmYgoO1NpyzBV1XewhSpOml84NGL+aulX2up3MrD 7fqKk+m1gJJBapweJGBHpApyONSnMi4RDro6ucL0UA7jRQdkQz1s8/SRMpbIqCzlEKQJ FPUonswSC7+BmjR3QL1MfvweI56WEanW6RRmZxq6ch+2kbySnZQ+DUCiTVzDQ4wkQFdB sw77w/4TSdEEqBFE0cHC4HYj+RHPk2tLWU+VFGEEqcAD/nY5wi6w/uxtD/JnJh5ly72+ fg== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2bdnerhak9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Jun 2017 17:54:41 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5UGp53o012798; Fri, 30 Jun 2017 12:54:40 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.31]) by prod-mail-ppoint4.akamai.com with ESMTP id 2b9kdv4t5g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 30 Jun 2017 12:54:40 -0400 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com (172.27.27.102) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 30 Jun 2017 11:54:39 -0500 Received: from USTX2EX-DAG1MB2.msg.corp.akamai.com ([172.27.6.132]) by ustx2ex-dag1mb2.msg.corp.akamai.com ([172.27.6.132]) with mapi id 15.00.1263.000; Fri, 30 Jun 2017 11:54:39 -0500 From: "Dunning, John" To: Jacob Hoffman-Andrews , Ilari Liusvaara , Richard Barnes CC: "Salz, Rich" , "acme@ietf.org" Thread-Topic: [Acme] Rolling keys and pending validations Thread-Index: AdLpJhpoh06PBTCkQemxb0Jtd47K7AALod+AAABWIYAAMPz4AAEw2kyAALsmqQA= Date: Fri, 30 Jun 2017 16:54:39 +0000 Message-ID: <30977E7E-FD36-4FB1-A7CF-1390095E1EB2@akamai.com> References: <0896b144e7e942b1ac68db9ead4c42bb@usma1ex-dag1mb1.msg.corp.akamai.com> <20170619184423.wtpj2qtq6awk3rju@LK-Perkele-VII> <53c76454-56ac-dde7-6cf8-94a6e39a89fc@eff.org> In-Reply-To: <53c76454-56ac-dde7-6cf8-94a6e39a89fc@eff.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.139] Content-Type: multipart/alternative; boundary="_000_30977E7EFD364FB1A7CF1390095E1EB2akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-30_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706300265 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-30_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706300265 Archived-At: Subject: Re: [Acme] Rolling keys and pending validations X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 16:54:49 -0000 --_000_30977E7EFD364FB1A7CF1390095E1EB2akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnkgYWJvdXQgdGhlIGRlbGF5ZWQgcmVzcG9uc2UuDQoNCkkgcHJvYmFibHkgd2FzIHVzaW5n IGltcHJlY2lzZSB0ZXJtaW5vbG9neSBpbiBteSBlYXJsaWVyIG1haWwgb24gdGhpcyB0b3BpYy4g IEJhc2VkIG9uIHJlLXJlYWRpbmcgYml0cyBvZiB0aGUgc3BlYywgSSBiZWxpZXZlIHlvdeKAmXJl IHJpZ2h0IGFib3V0IG15IGNvbmZ1c2lvbiBiZXR3ZWVuIGNoYWxsZW5nZSB0b2tlbiBhbmQga2V5 IGF1dGhvcml6YXRpb24uDQoNClZlcnkgaGlnaCBsZXZlbCwgdGhlIHVzZSBjYXNlIEnigJltIGFm dGVyIGlzIHRvIGFsbG93IGZvciBhIGNoYWxsZW5nZSDigJxwcm9jZXNz4oCdIHRvIHN0YXJ0IHBy aW9yIHRvIGEgY3JlZGVudGlhbCByb3RhdGlvbiwgYW5kIGZpbmlzaCBhZnRlcndhcmRzLCB3aXRo b3V0IG5lZWRpbmcgdG8gYmUgcmVzdGFydGVkLiAgU29ycnksIEnigJltIG1ha2luZyB1cCBtb3Jl IHRlcm1pbm9sb2d5IHRoZXJlIOKYuiAgSSBsaWtlZCBSaWNoYXJk4oCZcyBhbmFsb2d5IGVhcmxp ZXI6ICBJZiBJIHN0YXJ0IGEgZHJhZnQgaW4gZ21haWwsIHRoZW4gY2hhbmdlIG15IHBhc3N3b3Jk LCBJIGNhbiBjb250aW51ZSB3aXRoIHRoYXQgZHJhZnQgYWZ0ZXJ3YXJkcy4NCg0KQmFzZWQgb24g eW91ciBkZXNjcmlwdGlvbiBiZWxvdywgSSB0aGluayBkb29yIEEgbWFrZXMgbW9yZSBzZW5zZSB0 byBtZS4gIE15IHBhcmFwaHJhc2Ugb2YgaXQgaXMgdGhhdCBrZXkgYXV0aG9yaXphdGlvbnMgZ2V0 IGJvdW5kIGF0IGNyZWF0aW9uIHRpbWUsIGFuZCB0aHVzIGdldCDigJxncmFuZGZhdGhlcmVk4oCd IGluIGFmdGVyIGEgY3JlZGVudGlhbCByb3RhdGlvbi4NCg0KRG9vciBCIHdvdWxkIGJlIHByb2Js ZW1hdGljIGZvciBteSB1c2Vycy4gIEZvciByZWFzb25zIHdoaWNoIEkgZG9u4oCZdCByZWFsbHkg d2FudCB0byBlbGFib3JhdGUgdG9vIG11Y2gsIHRoZSByZWxhdGlvbnNoaXBzIGJldHdlZW4gbXkg Y3VzdG9tZXJzLCB0aGVpciBjdXN0b21lcnMsIGFuZCB0aGVpciBjdXN0b21lcnPigJkgaG9zdGlu ZyBwcm92aWRlcnMsIGlzIG9mdGVuIHRlbnVvdXMgYW5kIHByb2JsZW1hdGljLg0KDQpJIGhvcGUg dGhhdCBoZWxwcy4NCg0KSSB3aWxsIGJlIG9uIHZhY2F0aW9uIHRoZSBuZXh0IGNvdXBsZSBvZiB3 ZWVrcywgc28gZnVydGhlciByZXNwb25zZXMgb24gdGhpcyB0aHJlYWQgd2lsbCBhbHNvIGJlIGRl bGF5ZWQuDQoNClRoYW5rcyAuIC4gLg0KDQoNCkZyb206IEphY29iIEhvZmZtYW4tQW5kcmV3cyA8 anNoYUBlZmYub3JnPg0KRGF0ZTogTW9uZGF5LCBKdW5lIDI2LCAyMDE3IGF0IDM6MzUgUE0NClRv OiAiRHVubmluZywgSm9obiIgPGpyZEBha2FtYWkuY29tPiwgSWxhcmkgTGl1c3ZhYXJhIDxpbGFy aWxpdXN2YWFyYUB3ZWxoby5jb20+LCBSaWNoYXJkIEJhcm5lcyA8cmxiQGlwdi5zeD4NCkNjOiAi U2FseiwgUmljaCIgPHJzYWx6QGFrYW1haS5jb20+LCAiYWNtZUBpZXRmLm9yZyIgPGFjbWVAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0FjbWVdIFJvbGxpbmcga2V5cyBhbmQgcGVuZGluZyB2YWxp ZGF0aW9ucw0KDQpPbiAwNi8yMC8yMDE3IDAzOjA3IFBNLCBEdW5uaW5nLCBKb2huIHdyb3RlOg0K DQoNCkkgd291bGQgYWR2b2NhdGUgZm9yIHRoZSBuZXcgb25lLiAgSU9XLCBJIHdvdWxkIChleHBl Y3QgdG8pIGludGVycHJldCB0aGUgc2VtYW50aWNzIGFzIGJlaW5nDQoNCg0KDQoxLiBUaGUgY2hh bGxlbmdlIHRva2VuIHdhcyBjcmVhdGVkIHdpdGggcmVzcGVjdCB0byBhbiBhY2NvdW50DQoNCjIu IEFuIGF0dHJpYnV0ZSBvZiB0aGUgYWNjb3VudCBpcyB0aGUgY3JlZGVudGlhbCAod2hpY2hldmVy IGNyZWRlbnRpYWwgaXMgY3VycmVudCkNCg0KMy4gVGhlcmVmb3JlIHRoZSBjcmVkZW50aWFsIGF1 dGhvcml6ZXMgYWNjZXNzIHRvIGFueXRoaW5nIGFzc29jaWF0ZWQgd2l0aCB0aGUgYWNjb3VudC4N Cg0KDQoNCklmIHRoZSBjb25jZW5zdXMgaGVyZSBpcyB0aGF0IGEgc2VydmVyIG5lZWRzIHRvIGFz c29jaWF0ZSB0aGUgY3JlZGVudGlhbCB3aGljaCB3YXMgaW4gZm9yY2UgYXQgY3JlYXRpb24gdGlt ZSB3aXRoIGEgY2hhbGxlbmdlIHRva2VuLCBpbiBvdGhlciB3b3JkcyB0aGF0IHRoZSB0b2tlbiBp cyB0aWVkIHRvIHRoZSBjcmVkZW50aWFsIHJhdGhlciB0aGFuIHRoZSBhY2NvdW50LCBJIGJlbGll dmUgbXkgdXNlIGNhc2Ugd291bGQgYmUgb2sgd2l0aCB0aGF0LCBhcyBsb25nIGFzIHRoZSBjaGFs bGVuZ2UgdG9rZW5zIGRvIG5vdCBnbyBpbnZhbGlkIGFmdGVyIHRoZSBjcmVkZW50aWFsIGNoYW5n ZS4NClRoaXMgc2VlbXMgZGlmZmVyZW50IGZyb20gdGhlIGJlaGF2aW9yIEkgdGhvdWdodCB5b3Ug d2VyZSBsb29raW5nIGZvciwgYmFzZWQgb24gcHJldmlvdXMgY29udmVyc2F0aW9ucy4gVGhpcyBt YXkgYmUgYSBkaWZmZXJlbmNlIGluIGludGVycHJldGF0aW9uIG9mICJjaGFsbGVuZ2UgdG9rZW4i IHZzICJrZXkgYXV0aG9yaXphdGlvbi4iIEV2ZXJ5IGNoYWxsZW5nZSBoYXMgYSByYW5kb20gInRv a2VuIiBmaWVsZCwgYnV0IHRoaXMgaXMgb25seSBhIHBhcnQgb2Ygd2hhdCBnZXRzIHByb3Zpc2lv bmVkIHRvIGEgd2ViIHNlcnZlciBmb3IgSFRUUC0wMS4gRm9yIGFuIEhUVFAtMDEgY2hhbGxlbmdl LCB0aGUgQUNNRSBjbGllbnQgY2FsY3VsYXRlcyBhICJrZXkgYXV0aG9yaXphdGlvbiIgYXMgIjx0 b2tlbj4uPGFjY291bnQga2V5IHRodW1icHJpbnQ+Ii4gVGhlIGNsaWVudCB0aGVuIFBPU1RzIGEg c2lnbmVkIHJlcXVlc3QgdG8gdGhlIGNoYWxsZW5nZSBVUkwsIGNvbnRhaW5pbmcgYSAia2V5QXV0 aG9yaXphdGlvbiIgZmllbGQgY29udGFpbmluZyB0aGlzIGtleSBhdXRob3JpemF0aW9uLiBUaGUg QUNNRSBzZXJ2ZXIgdGhlbiByZXF1ZXN0cyAiLy53ZWxsLWtub3duL2FjbWUtdmFsaWRhdGlvbi88 dG9rZW4+IiBmcm9tIHRoZSB2YWxpZGF0aW9uIGRvbWFpbiwgYW5kIGV4cGVjdHMgIjx0b2tlbj4u PGFjY291bnQga2V5IHRodW1icHJpbnQ+IiAodGhhdCBpcywgdGhlIGtleSBhdXRob3JpemF0aW9u IG9iamVjdCkgaW4gcmVzcG9uc2UuDQoNCkkgdGhpbmsgYSBtb3JlIGN1c3RvbWFyeSB3YXkgb2Yg dGFsa2luZyB3b3VsZCBiZSB0byBjYWxsIHRoaXMgImtleSBhdXRob3JpemF0aW9uIiBvYmplY3Qg dGhhdCBpcyBwcm92aXNpb25lZCBvbiB0aGUgdmFsaWRhdGlvbiBkb21haW4gYSAiY2hhbGxlbmdl IHRva2VuLiIgQW5kIGluIGZhY3QsIGluIGFuIGVhcmxpZXIgKHByZS1kcmFmdC0wMSkgdmVyc2lv biBvZiB0aGUgQUNNRSBzcGVjLCB0aGUgInRva2VuIiBmaWVsZCBvZiBhIGNoYWxsZW5nZSB3YXMg cHJvdmlzaW9uZWQgb24gdGhlIHZhbGlkYXRpb24gZG9tYWluIGFuZCByZXF1ZXN0ZWQgYnkgdGhl IEFDTUUgc2VydmVyLiBIb3dldmVyLCBzb21lIHBlb3BsZSBvbiB0aGUgbGlzdCBwb2ludGVkIG91 dCB0aGF0IHRoaXMgd291bGQgZW5jb3VyYWdlIGRldmVsb3BtZW50IG9mICJuYWl2ZSIgY2hhbGxl bmdlIHNvbHZlcnMgdGhhdCB3b3VsZCBqdXN0IGVjaG8gdGhlIHRva2VuIHBhcnQgb2YgdGhlIFVS TC4gU28gd2Ugd291bmQgdXAgaW4gdGhpcyBhd2t3YXJkIHN0YXRlIHdoZXJlIHdoYXQgbW9zdCBw ZW9wbGUgd291bGQgY29uc2lkZXIgYSAiY2hhbGxlbmdlIHRva2VuIiBpcywgaW4gQUNNRSwgY29u c2lkZXJlZCBhICJrZXkgYXV0aG9yaXphdGlvbi4iDQoNCkFzIEkgdW5kZXJzdGFuZCB0aGUgc2l0 dWF0aW9uIHdlJ3JlIHRyeWluZyB0byBzb2x2ZSwgaXQncyBzb21ldGhpbmcgbGlrZSB0aGlzOg0K DQoxLiBNb25kYXk6IGFuIEFDTUUgY2xpZW50IG9wZXJhdGVkIGJ5IGEgaG9zdGluZyBwcm92aWRl ciByZWNlaXZlcyBhIHJlcXVlc3QgZm9yIGEgY2VydGlmaWNhdGUgZm9yIGB3d3cuZXhhbXBsZS5j b208aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3 dy5leGFtcGxlLmNvbSZkPUR3TURhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj1nWHdyci1M dEU5LVd0ek1Ga3VQVlZRJm09S2Y3MXRhOEl2eUhybVJCTHlvZnRXeGp6U3NpQWM0dEFON09kYW5M UW9kcyZzPUJXZFlVRUtyd3RqOUNKQ09feFBIbHVMbm9SV3NnSHpQQ3VObDRLbjg4b1kmZT0+YC4g VGhpcyBBQ01FIGNsaWVudCByZXF1ZXN0cyBhbiBhdXRob3JpemF0aW9uIG9iamVjdCBmcm9tIHRo ZSBzZXJ2ZXIsIGFuZCByZWNlaXZlcyBvbmUuIFRoZSBhdXRob3JpemF0aW9uIG9iamVjdCBjb250 YWlucyBhIGNoYWxsZW5nZSBvZiB0eXBlICJIVFRQLTAxIjoNCg0Kew0KICAidHlwZSI6ICJodHRw LTAxIiwNCiAgInN0YXR1cyI6ICJwZW5kaW5nIiwNCiAgInVyaSI6ICJodHRwczovL2NhLmV4YW1w bGUubmV0L2FjbWUvY2hhbGxlbmdlL2wtMnpGQ2RFUVQzSDVhZEJuT19XRnVUQUEzdDRCVjRobkZx V3d0bGducG8vODU0MyI8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLTNBX19jYS5leGFtcGxlLm5ldF9hY21lX2NoYWxsZW5nZV9sLTJEMnpGQ2RFUVQzSDVh ZEJuTy01RldGdVRBQTN0NEJWNGhuRnFXd3RsZ25wb184NTQzJmQ9RHdNRGFRJmM9OTZaYlpaY2FN RjR3MEY0anBONkxaZyZyPWdYd3JyLUx0RTktV3R6TUZrdVBWVlEmbT1LZjcxdGE4SXZ5SHJtUkJM eW9mdFd4anpTc2lBYzR0QU43T2RhbkxRb2RzJnM9bnpkV293MEd5ZjA4aWRYOXBrc3MyMjVfMVZp SmRObEUxdVk3b2htaG5hVSZlPT4sDQogICJ0b2tlbiI6ICJMQzJlRVlfOWxSTGd4VWZDTUU2VE1C NGJTMHdzbG0yUERMVEMyLUpVLVlZIiwNCn0NCg0KVGhlIGNsaWVudCdzIGN1cnJlbnQgYWNjb3Vu dCBrZXkgaGFzIGEgdGh1bWJwcmludCBvZiAiTUtnQUI4bGpacFF2MGh4dWlwQTcwTDBTWmttWElV aGJPNjFmUjN2S3ZqOCIsIHNvIGl0IGNhbGN1bGF0ZXMgYSBrZXkgYXV0aG9yaXphdGlvbiBieSBj b25jYXRlbmF0aW5nIHRoYXQgd2l0aCB0aGUgY2hhbGxlbmdlIHRva2VuIGZpZWxkOiAiTEMyZUVZ XzlsUkxneFVmQ01FNlRNQjRiUzB3c2xtMlBETFRDMi1KVS1ZWS5NS2dBQjhsalpwUXYwaHh1aXBB NzBMMFNaa21YSVVoYk82MWZSM3ZLdmo4Ii4gSXQgdGhlbiB0ZWxscyB0aGUgb3duZXIgb2YgYGV4 YW1wbGUuY29tYCB0byBwdXQgYSBmaWxlIGNvbnRhaW5pbmcgdGhhdCBzdHJpbmcgYXQgIi8ud2Vs bC1rbm93bi9hY21lLWNoYWxsZW5nZS9MQzJlRVlfOWxSTGd4VWZDTUU2VE1CNGJTMHdzbG0yUERM VEMyLUpVLVlZIi4gVGhlIG93bmVycyBvZiBgd3d3LmV4YW1wbGUuY29tPGh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193d3cuZXhhbXBsZS5jb20mZD1E d01EYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9Z1h3cnItTHRFOS1XdHpNRmt1UFZWUSZt PUtmNzF0YThJdnlIcm1SQkx5b2Z0V3hqelNzaUFjNHRBTjdPZGFuTFFvZHMmcz1CV2RZVUVLcnd0 ajlDSkNPX3hQSGx1TG5vUldzZ0h6UEN1Tmw0S244OG9ZJmU9PmAgc2F5ICJPa2F5LCBidXQgdGhh dCB3aWxsIHRha2UgYSBmZXcgZGF5cy4NCg0KMi4gVHVlc2RheTogVGhlIEFDTUUgY2xpZW50IHJv dGF0ZXMgaXRzIGFjY291bnQga2V5IGFzIHBhcnQgb2YgcmVndWxhciBtYWludGVuYW5jZS4gVGhl IG5ldyBhY2NvdW50IGtleSB0aHVtYnByaW50IGlzICJiSmNncks2b1R2amd2a3VNT09rcGRTOEJk T290cWZfejlUOHp3LWVGV09FIi4NCg0KMy4gV2VkbmVzZGF5OiBgd3d3LmV4YW1wbGUuY29tPGh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193d3cuZXhh bXBsZS5jb20mZD1Ed01EYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9Z1h3cnItTHRFOS1X dHpNRmt1UFZWUSZtPUtmNzF0YThJdnlIcm1SQkx5b2Z0V3hqelNzaUFjNHRBTjdPZGFuTFFvZHMm cz1CV2RZVUVLcnd0ajlDSkNPX3hQSGx1TG5vUldzZ0h6UEN1Tmw0S244OG9ZJmU9PmAgc2F5cyAi T2theSwgSSd2ZSBjcmVhdGVkIGEgZmlsZSBhdCAiLy53ZWxsLWtub3duL2FjbWUtY2hhbGxlbmdl L0xDMmVFWV85bFJMZ3hVZkNNRTZUTUI0YlMwd3NsbTJQRExUQzItSlUtWVkiLCBhbmQgaXQgY29u dGFpbnMgIkxDMmVFWV85bFJMZ3hVZkNNRTZUTUI0YlMwd3NsbTJQRExUQzItSlUtWVkuTUtnQUI4 bGpacFF2MGh4dWlwQTcwTDBTWmttWElVaGJPNjFmUjN2S3ZqOCIuIFRoZSBhY2NvdW50IGtleSB0 aHVtYnByaW50IGluIHRoaXMgZmlsZSAodGhlIHBhcnQgYWZ0ZXIgdGhlICIuIikgaXMgb3V0IG9m IGRhdGUsIGJlY2F1c2UgdGhlIEFDTUUgY2xpZW50IHJvdGF0ZWQgaXRzIGFjY291bnQga2V5Lg0K DQozLiBXZWRuZXNkYXk6IFRoZSBBQ01FIGNsaWVudCBQT1NUcyB0byB0aGUgZXhpc3RpbmcgY2hh bGxlbmdlIFVSTCB3aXRoIGEga2V5IGF1dGhvcml6YXRpb24gYmFzZWQgb24gaXRzIGN1cnJlbnQg YWNjb3VudCBrZXk6DQoNClBPU1QgL2FjbWUvY2hhbGxlbmdlL2wtMnpGQ2RFUVQzSDVhZEJuT19X RnVUQUEzdDRCVjRobkZxV3d0bGducG8vODU0Mw0KDQouLi4gbm90ZTogSldLIHdyYXBwaW5nIGVs aWRlZCAuLi4NCnsNCiAgImtleUF1dGhvcml6YXRpb24iOiAiTEMyZUVZXzlsUkxneFVmQ01FNlRN QjRiUzB3c2xtMlBETFRDMi1KVS1ZWS5iSmNncks2b1R2amd2a3VNT09rcGRTOEJkT290cWZfejlU OHp3LWVGV09FIg0KfQ0KLi4uDQoNCk5vdGU6IFRoZSBrZXkgYXV0aG9yaXphdGlvbiBpbiB0aGlz IFBPU1QgY29udGFpbnMgdGhlIGN1cnJlbnQgYWNjb3VudCBrZXkgdGh1bWJwcmludC4gSWYgaXQg Y29udGFpbmVkIHRoZSBvbGQgYWNjb3VudCBrZXkgdGh1bWJwcmludCwgdGhlIEFDTUUgc2VydmVy IHdvdWxkIHJlamVjdCBpdC4NCg0KNC4gV2VkbmVzZGF5OiBUaGUgQUNNRSBzZXJ2ZXIgYWNjZXB0 cyB0aGUgY2hhbGxlbmdlIHVwZGF0ZSwgYW5kIG1ha2VzIGEgdmFsaWRhdGlvbiByZXF1ZXN0IHRv IGh0dHA6Ly93d3cuZXhhbXBsZS5jb20vLndlbGwta25vd24vYWNtZS1jaGFsbGVuZ2UvTEMyZUVZ XzlsUkxneFVmQ01FNlRNQjRiUzB3c2xtMlBETFRDMi1KVS1ZWTxodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fd3d3LmV4YW1wbGUuY29tXy53ZWxsLTJE a25vd25fYWNtZS0yRGNoYWxsZW5nZV9MQzJlRVktNUY5bFJMZ3hVZkNNRTZUTUI0YlMwd3NsbTJQ RExUQzItMkRKVS0yRFlZJmQ9RHdNRGFRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPWdYd3Jy LUx0RTktV3R6TUZrdVBWVlEmbT1LZjcxdGE4SXZ5SHJtUkJMeW9mdFd4anpTc2lBYzR0QU43T2Rh bkxRb2RzJnM9emtfaHlmWm5paDZXeXBnTkNXWmdoVkJoZlNKdGFLdXk2VjE4anFoSVJzSSZlPT4u IEl0IHJlY2VpdmVzIGEgcmVzcG9uc2UgIkxDMmVFWV85bFJMZ3hVZkNNRTZUTUI0YlMwd3NsbTJQ RExUQzItSlUtWVkuTUtnQUI4bGpacFF2MGh4dWlwQTcwTDBTWmttWElVaGJPNjFmUjN2S3ZqOCIu IEhvd2V2ZXIsIHRoZSBBQ01FIHNlcnZlciB3YXMgZXhwZWN0aW5nICJMQzJlRVlfOWxSTGd4VWZD TUU2VE1CNGJTMHdzbG0yUERMVEMyLUpVLVlZLmJKY2dySzZvVHZqZ3ZrdU1PT2twZFM4QmRPb3Rx Zl96OVQ4enctZUZXT0UiLCBiZWNhdXNlIHRoYXQncyB3aGF0IHdhcyBQT1NUZWQgYXMgcGFydCBv ZiB0aGUgY2hhbGxlbmdlIHVwZGF0ZS4gU28gdGhlIHZhbGlkYXRpb24gcmVxdWVzdCBmYWlscywg YW5kIGB3d3cuZXhhbXBsZS5jb208aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHAtM0FfX3d3dy5leGFtcGxlLmNvbSZkPUR3TURhUSZjPTk2WmJaWmNhTUY0dzBG NGpwTjZMWmcmcj1nWHdyci1MdEU5LVd0ek1Ga3VQVlZRJm09S2Y3MXRhOEl2eUhybVJCTHlvZnRX eGp6U3NpQWM0dEFON09kYW5MUW9kcyZzPUJXZFlVRUtyd3RqOUNKQ09feFBIbHVMbm9SV3NnSHpQ Q3VObDRLbjg4b1kmZT0+YCBoYXMgdG8gc3RhcnQgdGhlIHdob2xlIGlzc3VhbmNlIHByb2Nlc3Mg YWxsIG92ZXIgYWdhaW4uDQoNCg0KVGhlcmUncyBvbmUgYWRkaXRpb25hbCBwaWVjZSBvZiBjb250 ZXh0IGhlcmU6IFdlIGFzc3VtZSB0aGF0IHRoZSBob3N0aW5nIHByb3ZpZGVyIG9wZXJhdGluZyB0 aGUgQUNNRSBjbGllbnQgZG9lc24ndCB5ZXQgY29udHJvbCBgd3d3LmV4YW1wbGUuY29tPGh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193d3cuZXhhbXBs ZS5jb20mZD1Ed01EYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9Z1h3cnItTHRFOS1XdHpN Rmt1UFZWUSZtPUtmNzF0YThJdnlIcm1SQkx5b2Z0V3hqelNzaUFjNHRBTjdPZGFuTFFvZHMmcz1C V2RZVUVLcnd0ajlDSkNPX3hQSGx1TG5vUldzZ0h6UEN1Tmw0S244OG9ZJmU9PmAuIFRoaXMgY2Fu IGhhcHBlbiwgZm9yIGluc3RhbmNlLCB3aGVuIGEgaG9zdGluZyBwcm92aWRlciBpcyB0cnlpbmcg dG8gb25ib2FyZCBhIGN1c3RvbWVyIHdobyBhbHJlYWR5IHVzZXMgSFRUUFMuIFRoZSBob3N0aW5n IHByb3ZpZGVyIG5lZWRzIHRvIGhhdmUgYSB2YWxpZCBjZXJ0aWZpY2F0ZSBpbiBwbGFjZSAqYmVm b3JlKiB0aGUgY3VzdG9tZXIgQ05BTUVzIHRoZWlyIGRvbWFpbiBuYW1lIHRoZSB0aGUgaG9zdGlu ZyBwcm92aWRlci4NCg0KVGhlICJjbGFyaWZ5IGltcGFjdCBvZiByb2xsLW92ZXIiIFBSIChodHRw czovL2dpdGh1Yi5jb20vaWV0Zi13Zy1hY21lL2FjbWUvcHVsbC8zMjMvZmlsZXM8aHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19naXRodWIuY29tX2ll dGYtMkR3Zy0yRGFjbWVfYWNtZV9wdWxsXzMyM19maWxlcyZkPUR3TURhUSZjPTk2WmJaWmNhTUY0 dzBGNGpwTjZMWmcmcj1nWHdyci1MdEU5LVd0ek1Ga3VQVlZRJm09S2Y3MXRhOEl2eUhybVJCTHlv ZnRXeGp6U3NpQWM0dEFON09kYW5MUW9kcyZzPXNzUXZnMDdZandDNDdYUHluVG5ycFFNV3djT3Br QklIRnZtdmdXN2EwN28mZT0+KSBpcyBhIG5pY2UgY2xhcmlmaWNhdGlvbiwgYnV0IGRvZXNuJ3Qg YWN0dWFsbHkgYWRkcmVzcyB0aGlzIHVzZSBjYXNlLiBUaGUgaXNzdWUgaGVyZSBpcyB3aGF0IGhh cHBlbnMgZHVyaW5nIHRoZSBwZXJpb2QgYmV0d2VlbiBjcmVhdGlvbiBvZiBhIGNoYWxsZW5nZSBh bmQgdGhlIEFDTUUgY2xpZW50IHJlcXVlc3RpbmcgdmFsaWRhdGlvbiBvZiB0aGF0IGNoYWxsZW5n ZSwgd2hpY2ggaW4gY3VycmVudCBpbXBsZW1lbnRhdGlvbnMgY2FuIGJlIHVwIHRvIDcgZGF5cy4N Cg0KVGhlcmUgYXJlIHR3byBtYWluIGFwcHJvYWNoZXMgSSBzZWU6DQoNCkEpIFdlIGNvdWxkIGNo YW5nZSB0aGUgc3BlYyB0byBzZXQgdGhlIGtleUF1dGhvcml6YXRpb24gZmllbGQgd2hlbiBhIGNo YWxsZW5nZSBpcyBjcmVhdGVkLCBzbyB0aGF0IGl0IHdvdWxkIGhhdmUgdGhlIGN1cnJlbnQgYWNj b3VudCBrZXkgdGh1bWJwcmludCBiYWtlZCBpbi4gVGhpcyB3b3VsZCBhbGxvdyBob3N0aW5nIHBy b3ZpZGVycyB0byB0cmVhdCB0aGUga2V5IGF1dGhvcml6YXRpb24gbW9yZSBsaWtlIGFuIG9wYXF1 ZSBzdHJpbmcsIGFuZCBjYWxjdWxhdGUgaXQgYXQgY2hhbGxlbmdlIGNyZWF0aW9uIHRpbWUgcmF0 aGVyIHRoYW4gYXQgY2hhbGxlbmdlIHVwZGF0ZSB0aW1lLg0KDQpCKSBXZSBjb3VsZCBlbmNvdXJh Z2UgaW1wbGVtZW50ZXJzIHRvIHNob3J0ZW4gdGhlIHRpbWUgYmV0d2VlbiBjaGFsbGVuZ2UgY3Jl YXRpb24gYW5kIHZhbGlkYXRpb24gYnkgZG9pbmcgZGVsZWdhdGlvbi4gVGhhdCBpcywgaW5zdGVh ZCBvZiBnaXZpbmcgYHd3dy5leGFtcGxlLmNvbTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fd3d3LmV4YW1wbGUuY29tJmQ9RHdNRGFRJmM9OTZaYlpa Y2FNRjR3MEY0anBONkxaZyZyPWdYd3JyLUx0RTktV3R6TUZrdVBWVlEmbT1LZjcxdGE4SXZ5SHJt UkJMeW9mdFd4anpTc2lBYzR0QU43T2RhbkxRb2RzJnM9QldkWVVFS3J3dGo5Q0pDT194UEhsdUxu b1JXc2dIelBDdU5sNEtuODhvWSZlPT5gIGEgdG9rZW4sIGFuZCB3YWl0aW5nIGZvciB0aGVtIHRv IGRlcGxveSBpdCwgdGhlIGhvc3RpbmcgcHJvdmlkZXIgY291bGQgc2F5ICJQbGVhc2UgZGVsZWdh dGUgaXNzdWFuY2UgYXV0aG9yaXR5IHRvIHVzLCBlaXRoZXIgYnkgcmVkaXJlY3RpbmcgYWxsIG9m IC8ud2VsbC1rbm93bi9hY21lLXZhbGlkYXRpb24vKiB0byBvdXIgdmFsaWRhdGlvbiBzZXJ2ZXIs IG9yIGJ5IENOQU1FaW5nIF9hY21lLWNoYWxsZW5nZS53d3cuZXhhbXBsZS5jb20gdG8gb3VyIHZh bGlkYXRpb24gc2VydmVyLiIgVGhlIG1haW4gcHJvYmxlbXMgd2l0aCB0aGlzOiB0aGUgb3duZXJz IG9mIGB3d3cuZXhhbXBsZS5jb208aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHAtM0FfX3d3dy5leGFtcGxlLmNvbSZkPUR3TURhUSZjPTk2WmJaWmNhTUY0dzBG NGpwTjZMWmcmcj1nWHdyci1MdEU5LVd0ek1Ga3VQVlZRJm09S2Y3MXRhOEl2eUhybVJCTHlvZnRX eGp6U3NpQWM0dEFON09kYW5MUW9kcyZzPUJXZFlVRUtyd3RqOUNKQ09feFBIbHVMbm9SV3NnSHpQ Q3VObDRLbjg4b1kmZT0+YCBtYXkgbm90IGJlIGZhbWlsaWFyIGVub3VnaCB3aXRoIHJlZGlyZWN0 cyAoYWx0aG91Z2ggQ05BTUVzIHNob3VsZCBiZSBlYXN5KTsgdGhlIG93bmVycyBvZiBgd3d3LmV4 YW1wbGUuY29tPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw LTNBX193d3cuZXhhbXBsZS5jb20mZD1Ed01EYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9 Z1h3cnItTHRFOS1XdHpNRmt1UFZWUSZtPUtmNzF0YThJdnlIcm1SQkx5b2Z0V3hqelNzaUFjNHRB TjdPZGFuTFFvZHMmcz1CV2RZVUVLcnd0ajlDSkNPX3hQSGx1TG5vUldzZ0h6UEN1Tmw0S244OG9Z JmU9PmAgbWF5IGhhdmUgYSBjb25jdXJyZW50bHkgcnVubmluZyBBQ01FIGNsaWVudCBvZiB0aGVp ciBvd24gdGhhdCBuZWVkcyB0byByZW5ldyBkdXJpbmcgdGhlIHRpbWUgd2luZG93IHRoZXkgd291 bGQgYmUgc2VydmluZyBhIHJlZGlyZWN0IG9yIENOQU1FLg0KDQo= --_000_30977E7EFD364FB1A7CF1390095E1EB2akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <1A0436D30EC3FA49AF773721AC2F2D6D@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiQXBwbGUgQ29sb3IgRW1vamkiOw0KCXBhbm9zZS0xOjAgMCAw IDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVk Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJ Zm9udC1mYW1pbHk6Q291cmllcjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0 eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0 ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlNvcnJ5IGFib3V0IHRoZSBkZWxheWVkIHJl c3BvbnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkkgcHJvYmFibHkgd2FzIHVzaW5nIGlt cHJlY2lzZSB0ZXJtaW5vbG9neSBpbiBteSBlYXJsaWVyIG1haWwgb24gdGhpcyB0b3BpYy4mbmJz cDsgQmFzZWQgb24gcmUtcmVhZGluZyBiaXRzIG9mIHRoZSBzcGVjLCBJIGJlbGlldmUgeW914oCZ cmUgcmlnaHQgYWJvdXQgbXkgY29uZnVzaW9uIGJldHdlZW4gY2hhbGxlbmdlIHRva2VuIGFuZA0K IGtleSBhdXRob3JpemF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlZlcnkgaGlnaCBs ZXZlbCwgdGhlIHVzZSBjYXNlIEnigJltIGFmdGVyIGlzIHRvIGFsbG93IGZvciBhIGNoYWxsZW5n ZSDigJxwcm9jZXNz4oCdIHRvIHN0YXJ0IHByaW9yIHRvIGEgY3JlZGVudGlhbCByb3RhdGlvbiwg YW5kIGZpbmlzaCBhZnRlcndhcmRzLCB3aXRob3V0IG5lZWRpbmcgdG8gYmUgcmVzdGFydGVkLiZu YnNwOyBTb3JyeSwgSeKAmW0NCiBtYWtpbmcgdXAgbW9yZSB0ZXJtaW5vbG9neSB0aGVyZSA8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXBwbGUg Q29sb3IgRW1vamkmcXVvdDsiPuKYujwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsgSSBsaWtlZCBSaWNoYXJk4oCZcyBhbmFsb2d5 IGVhcmxpZXI6Jm5ic3A7IElmIEkgc3RhcnQgYSBkcmFmdCBpbiBnbWFpbCwgdGhlbiBjaGFuZ2Ug bXkgcGFzc3dvcmQsIEkNCiBjYW4gY29udGludWUgd2l0aCB0aGF0IGRyYWZ0IGFmdGVyd2FyZHMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+QmFzZWQgb24geW91ciBkZXNjcmlwdGlvbiBiZWxv dywgSSB0aGluayBkb29yIEEgbWFrZXMgbW9yZSBzZW5zZSB0byBtZS4mbmJzcDsgTXkgcGFyYXBo cmFzZSBvZiBpdCBpcyB0aGF0IGtleSBhdXRob3JpemF0aW9ucyBnZXQgYm91bmQgYXQgY3JlYXRp b24gdGltZSwgYW5kIHRodXMgZ2V0IOKAnGdyYW5kZmF0aGVyZWTigJ0gaW4gYWZ0ZXINCiBhIGNy ZWRlbnRpYWwgcm90YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+RG9vciBCIHdvdWxk IGJlIHByb2JsZW1hdGljIGZvciBteSB1c2Vycy4mbmJzcDsgRm9yIHJlYXNvbnMgd2hpY2ggSSBk b27igJl0IHJlYWxseSB3YW50IHRvIGVsYWJvcmF0ZSB0b28gbXVjaCwgdGhlIHJlbGF0aW9uc2hp cHMgYmV0d2VlbiBteSBjdXN0b21lcnMsIHRoZWlyIGN1c3RvbWVycywgYW5kIHRoZWlyIGN1c3Rv bWVyc+KAmSBob3N0aW5nDQogcHJvdmlkZXJzLCBpcyBvZnRlbiB0ZW51b3VzIGFuZCBwcm9ibGVt YXRpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5JIGhvcGUgdGhhdCBoZWxwcy4mbmJzcDsN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkkgd2lsbCBiZSBvbiB2YWNhdGlvbiB0aGUgbmV4 dCBjb3VwbGUgb2Ygd2Vla3MsIHNvIGZ1cnRoZXIgcmVzcG9uc2VzIG9uIHRoaXMgdGhyZWFkIHdp bGwgYWxzbyBiZSBkZWxheWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmki PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlRoYW5rcyAuIC4g LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+DQo8 L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkphY29iIEhv ZmZtYW4tQW5kcmV3cyAmbHQ7anNoYUBlZmYub3JnJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25k YXksIEp1bmUgMjYsIDIwMTcgYXQgMzozNSBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7RHVubmlu ZywgSm9obiZxdW90OyAmbHQ7anJkQGFrYW1haS5jb20mZ3Q7LCBJbGFyaSBMaXVzdmFhcmEgJmx0 O2lsYXJpbGl1c3ZhYXJhQHdlbGhvLmNvbSZndDssIFJpY2hhcmQgQmFybmVzICZsdDtybGJAaXB2 LnN4Jmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7U2FseiwgUmljaCZxdW90OyAmbHQ7cnNhbHpA YWthbWFpLmNvbSZndDssICZxdW90O2FjbWVAaWV0Zi5vcmcmcXVvdDsgJmx0O2FjbWVAaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbQWNtZV0gUm9sbGluZyBrZXlzIGFuZCBw ZW5kaW5nIHZhbGlkYXRpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIDA2LzIwLzIwMTcgMDM6MDcgUE0sIER1bm5pbmcsIEpvaG4gd3Jv dGU6PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+SSB3b3VsZCBhZHZvY2F0ZSBm b3IgdGhlIG5ldyBvbmUuJm5ic3A7IElPVywgSSB3b3VsZCAoZXhwZWN0IHRvKSBpbnRlcnByZXQg dGhlIHNlbWFudGljcyBhcyBiZWluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+DQo8cHJlPjEuIFRoZSBjaGFsbGVuZ2UgdG9rZW4gd2FzIGNyZWF0ZWQgd2l0 aCByZXNwZWN0IHRvIGFuIGFjY291bnQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4yLiBBbiBhdHRy aWJ1dGUgb2YgdGhlIGFjY291bnQgaXMgdGhlIGNyZWRlbnRpYWwgKHdoaWNoZXZlciBjcmVkZW50 aWFsIGlzIGN1cnJlbnQpPG86cD48L286cD48L3ByZT4NCjxwcmU+My4gVGhlcmVmb3JlIHRoZSBj cmVkZW50aWFsIGF1dGhvcml6ZXMgYWNjZXNzIHRvIGFueXRoaW5nIGFzc29jaWF0ZWQgd2l0aCB0 aGUgYWNjb3VudC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPHByZT5JZiB0aGUgY29uY2Vuc3VzIGhlcmUgaXMgdGhhdCBhIHNlcnZlciBuZWVkcyB0byBh c3NvY2lhdGUgdGhlIGNyZWRlbnRpYWwgd2hpY2ggd2FzIGluIGZvcmNlIGF0IGNyZWF0aW9uIHRp bWUgd2l0aCBhIGNoYWxsZW5nZSB0b2tlbiwgaW4gb3RoZXIgd29yZHMgdGhhdCB0aGUgdG9rZW4g aXMgdGllZCB0byB0aGUgY3JlZGVudGlhbCByYXRoZXIgdGhhbiB0aGUgYWNjb3VudCwgSSBiZWxp ZXZlIG15IHVzZSBjYXNlIHdvdWxkIGJlIG9rIHdpdGggdGhhdCwgYXMgbG9uZyBhcyB0aGUgY2hh bGxlbmdlIHRva2VucyBkbyBub3QgZ28gaW52YWxpZCBhZnRlciB0aGUgY3JlZGVudGlhbCBjaGFu Z2UuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoaXMgc2VlbXMgZGlmZmVyZW50IGZyb20gdGhlIGJlaGF2aW9yIEkgdGhvdWdodCB5b3Ugd2Vy ZSBsb29raW5nIGZvciwgYmFzZWQgb24gcHJldmlvdXMgY29udmVyc2F0aW9ucy4gVGhpcyBtYXkg YmUgYSBkaWZmZXJlbmNlIGluIGludGVycHJldGF0aW9uIG9mICZxdW90O2NoYWxsZW5nZSB0b2tl biZxdW90OyB2cyAmcXVvdDtrZXkgYXV0aG9yaXphdGlvbi4mcXVvdDsgRXZlcnkgY2hhbGxlbmdl IGhhcyBhIHJhbmRvbSAmcXVvdDt0b2tlbiZxdW90OyBmaWVsZCwNCiBidXQgdGhpcyBpcyBvbmx5 IGEgcGFydCBvZiB3aGF0IGdldHMgcHJvdmlzaW9uZWQgdG8gYSB3ZWIgc2VydmVyIGZvciBIVFRQ LTAxLiBGb3IgYW4gSFRUUC0wMSBjaGFsbGVuZ2UsIHRoZSBBQ01FIGNsaWVudCBjYWxjdWxhdGVz IGEgJnF1b3Q7a2V5IGF1dGhvcml6YXRpb24mcXVvdDsgYXMgJnF1b3Q7Jmx0O3Rva2VuJmd0Oy4m bHQ7YWNjb3VudCBrZXkgdGh1bWJwcmludCZndDsmcXVvdDsuIFRoZSBjbGllbnQgdGhlbiBQT1NU cyBhIHNpZ25lZCByZXF1ZXN0IHRvIHRoZSBjaGFsbGVuZ2UgVVJMLCBjb250YWluaW5nDQogYSAm cXVvdDtrZXlBdXRob3JpemF0aW9uJnF1b3Q7IGZpZWxkIGNvbnRhaW5pbmcgdGhpcyBrZXkgYXV0 aG9yaXphdGlvbi4gVGhlIEFDTUUgc2VydmVyIHRoZW4gcmVxdWVzdHMgJnF1b3Q7Ly53ZWxsLWtu b3duL2FjbWUtdmFsaWRhdGlvbi8mbHQ7dG9rZW4mZ3Q7JnF1b3Q7IGZyb20gdGhlIHZhbGlkYXRp b24gZG9tYWluLCBhbmQgZXhwZWN0cyAmcXVvdDsmbHQ7dG9rZW4mZ3Q7LiZsdDthY2NvdW50IGtl eSB0aHVtYnByaW50Jmd0OyZxdW90OyAodGhhdCBpcywgdGhlIGtleSBhdXRob3JpemF0aW9uIG9i amVjdCkgaW4gcmVzcG9uc2UuPGJyPg0KPGJyPg0KSSB0aGluayBhIG1vcmUgY3VzdG9tYXJ5IHdh eSBvZiB0YWxraW5nIHdvdWxkIGJlIHRvIGNhbGwgdGhpcyAmcXVvdDtrZXkgYXV0aG9yaXphdGlv biZxdW90OyBvYmplY3QgdGhhdCBpcyBwcm92aXNpb25lZCBvbiB0aGUgdmFsaWRhdGlvbiBkb21h aW4gYSAmcXVvdDtjaGFsbGVuZ2UgdG9rZW4uJnF1b3Q7IEFuZCBpbiBmYWN0LCBpbiBhbiBlYXJs aWVyIChwcmUtZHJhZnQtMDEpIHZlcnNpb24gb2YgdGhlIEFDTUUgc3BlYywgdGhlICZxdW90O3Rv a2VuJnF1b3Q7IGZpZWxkIG9mIGEgY2hhbGxlbmdlIHdhcw0KIHByb3Zpc2lvbmVkIG9uIHRoZSB2 YWxpZGF0aW9uIGRvbWFpbiBhbmQgcmVxdWVzdGVkIGJ5IHRoZSBBQ01FIHNlcnZlci4gSG93ZXZl ciwgc29tZSBwZW9wbGUgb24gdGhlIGxpc3QgcG9pbnRlZCBvdXQgdGhhdCB0aGlzIHdvdWxkIGVu Y291cmFnZSBkZXZlbG9wbWVudCBvZiAmcXVvdDtuYWl2ZSZxdW90OyBjaGFsbGVuZ2Ugc29sdmVy cyB0aGF0IHdvdWxkIGp1c3QgZWNobyB0aGUgdG9rZW4gcGFydCBvZiB0aGUgVVJMLiBTbyB3ZSB3 b3VuZCB1cCBpbiB0aGlzIGF3a3dhcmQNCiBzdGF0ZSB3aGVyZSB3aGF0IG1vc3QgcGVvcGxlIHdv dWxkIGNvbnNpZGVyIGEgJnF1b3Q7Y2hhbGxlbmdlIHRva2VuJnF1b3Q7IGlzLCBpbiBBQ01FLCBj b25zaWRlcmVkIGEgJnF1b3Q7a2V5IGF1dGhvcml6YXRpb24uJnF1b3Q7PGJyPg0KPGJyPg0KQXMg SSB1bmRlcnN0YW5kIHRoZSBzaXR1YXRpb24gd2UncmUgdHJ5aW5nIHRvIHNvbHZlLCBpdCdzIHNv bWV0aGluZyBsaWtlIHRoaXM6PGJyPg0KPGJyPg0KMS4gTW9uZGF5OiBhbiBBQ01FIGNsaWVudCBv cGVyYXRlZCBieSBhIGhvc3RpbmcgcHJvdmlkZXIgcmVjZWl2ZXMgYSByZXF1ZXN0IGZvciBhIGNl cnRpZmljYXRlIGZvciBgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHAtM0FfX3d3dy5leGFtcGxlLmNvbSZhbXA7ZD1Ed01EYVEmYW1wO2M9OTZa YlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1nWHdyci1MdEU5LVd0ek1Ga3VQVlZRJmFtcDttPUtm NzF0YThJdnlIcm1SQkx5b2Z0V3hqelNzaUFjNHRBTjdPZGFuTFFvZHMmYW1wO3M9QldkWVVFS3J3 dGo5Q0pDT194UEhsdUxub1JXc2dIelBDdU5sNEtuODhvWSZhbXA7ZT0iPnd3dy5leGFtcGxlLmNv bTwvYT5gLg0KIFRoaXMgQUNNRSBjbGllbnQgcmVxdWVzdHMgYW4gYXV0aG9yaXphdGlvbiBvYmpl Y3QgZnJvbSB0aGUgc2VydmVyLCBhbmQgcmVjZWl2ZXMgb25lLiBUaGUgYXV0aG9yaXphdGlvbiBv YmplY3QgY29udGFpbnMgYSBjaGFsbGVuZ2Ugb2YgdHlwZSAmcXVvdDtIVFRQLTAxJnF1b3Q7Ojxi cj4NCjxicj4NCns8YnI+DQombmJzcDsgJnF1b3Q7dHlwZSZxdW90OzogJnF1b3Q7aHR0cC0wMSZx dW90Oyw8YnI+DQombmJzcDsgJnF1b3Q7c3RhdHVzJnF1b3Q7OiAmcXVvdDtwZW5kaW5nJnF1b3Q7 LDxicj4NCiZuYnNwOyAmcXVvdDt1cmkmcXVvdDs6IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fY2EuZXhhbXBsZS5uZXRfYWNtZV9j aGFsbGVuZ2VfbC0yRDJ6RkNkRVFUM0g1YWRCbk8tNUZXRnVUQUEzdDRCVjRobkZxV3d0bGducG9f ODU0MyZhbXA7ZD1Ed01EYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1nWHdy ci1MdEU5LVd0ek1Ga3VQVlZRJmFtcDttPUtmNzF0YThJdnlIcm1SQkx5b2Z0V3hqelNzaUFjNHRB TjdPZGFuTFFvZHMmYW1wO3M9bnpkV293MEd5ZjA4aWRYOXBrc3MyMjVfMVZpSmRObEUxdVk3b2ht aG5hVSZhbXA7ZT0iPg0KJnF1b3Q7aHR0cHM6Ly9jYS5leGFtcGxlLm5ldC9hY21lL2NoYWxsZW5n ZS9sLTJ6RkNkRVFUM0g1YWRCbk9fV0Z1VEFBM3Q0QlY0aG5GcVd3dGxnbnBvLzg1NDMmcXVvdDs8 L2E+LDxicj4NCiZuYnNwOyAmcXVvdDt0b2tlbiZxdW90OzogJnF1b3Q7TEMyZUVZXzlsUkxneFVm Q01FNlRNQjRiUzB3c2xtMlBETFRDMi1KVS1ZWSZxdW90Oyw8YnI+DQp9PGJyPg0KPGJyPg0KVGhl IGNsaWVudCdzIGN1cnJlbnQgYWNjb3VudCBrZXkgaGFzIGEgdGh1bWJwcmludCBvZiAmcXVvdDs8 c3BhbiBzdHlsZT0iY29sb3I6I0NDMzNDQyI+TUtnQUI4bGpacFF2MGh4dWlwQTcwTDBTWmttWElV aGJPNjFmUjN2S3ZqODwvc3Bhbj4mcXVvdDssIHNvIGl0IGNhbGN1bGF0ZXMgYSBrZXkgYXV0aG9y aXphdGlvbiBieSBjb25jYXRlbmF0aW5nIHRoYXQgd2l0aCB0aGUgY2hhbGxlbmdlIHRva2VuIGZp ZWxkOiAmcXVvdDtMQzJlRVlfOWxSTGd4VWZDTUU2VE1CNGJTMHdzbG0yUERMVEMyLUpVLVlZLjxz cGFuIHN0eWxlPSJjb2xvcjojQ0MzM0NDIj5NS2dBQjhsalpwUXYwaHh1aXBBNzBMMFNaa21YSVVo Yk82MWZSM3ZLdmo4PC9zcGFuPiZxdW90Oy4NCiBJdCB0aGVuIHRlbGxzIHRoZSBvd25lciBvZiBg ZXhhbXBsZS5jb21gIHRvIHB1dCBhIGZpbGUgY29udGFpbmluZyB0aGF0IHN0cmluZyBhdCAmcXVv dDsvLndlbGwta25vd24vYWNtZS1jaGFsbGVuZ2UvTEMyZUVZXzlsUkxneFVmQ01FNlRNQjRiUzB3 c2xtMlBETFRDMi1KVS1ZWSZxdW90Oy4gVGhlIG93bmVycyBvZiBgPGEgaHJlZj0iaHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy5leGFtcGxlLmNv bSZhbXA7ZD1Ed01EYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1nWHdyci1M dEU5LVd0ek1Ga3VQVlZRJmFtcDttPUtmNzF0YThJdnlIcm1SQkx5b2Z0V3hqelNzaUFjNHRBTjdP ZGFuTFFvZHMmYW1wO3M9QldkWVVFS3J3dGo5Q0pDT194UEhsdUxub1JXc2dIelBDdU5sNEtuODhv WSZhbXA7ZT0iPnd3dy5leGFtcGxlLmNvbTwvYT5gDQogc2F5ICZxdW90O09rYXksIGJ1dCB0aGF0 IHdpbGwgdGFrZSBhIGZldyBkYXlzLjxicj4NCjxicj4NCjIuIFR1ZXNkYXk6IFRoZSBBQ01FIGNs aWVudCByb3RhdGVzIGl0cyBhY2NvdW50IGtleSBhcyBwYXJ0IG9mIHJlZ3VsYXIgbWFpbnRlbmFu Y2UuIFRoZSBuZXcgYWNjb3VudCBrZXkgdGh1bWJwcmludCBpcyAmcXVvdDs8c3BhbiBzdHlsZT0i Y29sb3I6I0NDMDAwMCI+YkpjZ3JLNm9Udmpndmt1TU9Pa3BkUzhCZE9vdHFmX3o5VDh6dy1lRldP RTwvc3Bhbj4mcXVvdDsuPGJyPg0KPGJyPg0KMy4gV2VkbmVzZGF5OiBgPGEgaHJlZj0iaHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy5leGFtcGxl LmNvbSZhbXA7ZD1Ed01EYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1nWHdy ci1MdEU5LVd0ek1Ga3VQVlZRJmFtcDttPUtmNzF0YThJdnlIcm1SQkx5b2Z0V3hqelNzaUFjNHRB TjdPZGFuTFFvZHMmYW1wO3M9QldkWVVFS3J3dGo5Q0pDT194UEhsdUxub1JXc2dIelBDdU5sNEtu ODhvWSZhbXA7ZT0iPnd3dy5leGFtcGxlLmNvbTwvYT5gDQogc2F5cyAmcXVvdDtPa2F5LCBJJ3Zl IGNyZWF0ZWQgYSBmaWxlIGF0ICZxdW90Oy8ud2VsbC1rbm93bi9hY21lLWNoYWxsZW5nZS9MQzJl RVlfOWxSTGd4VWZDTUU2VE1CNGJTMHdzbG0yUERMVEMyLUpVLVlZJnF1b3Q7LCBhbmQgaXQgY29u dGFpbnMgJnF1b3Q7TEMyZUVZXzlsUkxneFVmQ01FNlRNQjRiUzB3c2xtMlBETFRDMi1KVS1ZWS48 c3BhbiBzdHlsZT0iY29sb3I6I0NDMzNDQyI+TUtnQUI4bGpacFF2MGh4dWlwQTcwTDBTWmttWElV aGJPNjFmUjN2S3ZqODwvc3Bhbj4mcXVvdDsuIFRoZQ0KIGFjY291bnQga2V5IHRodW1icHJpbnQg aW4gdGhpcyBmaWxlICh0aGUgcGFydCBhZnRlciB0aGUgJnF1b3Q7LiZxdW90OykgaXMgb3V0IG9m IGRhdGUsIGJlY2F1c2UgdGhlIEFDTUUgY2xpZW50IHJvdGF0ZWQgaXRzIGFjY291bnQga2V5Ljxi cj4NCjxicj4NCjMuIFdlZG5lc2RheTogVGhlIEFDTUUgY2xpZW50IFBPU1RzIHRvIHRoZSBleGlz dGluZyBjaGFsbGVuZ2UgVVJMIHdpdGggYSBrZXkgYXV0aG9yaXphdGlvbiBiYXNlZCBvbiBpdHMg Y3VycmVudCBhY2NvdW50IGtleTo8YnI+DQo8YnI+DQpQT1NUIC9hY21lL2NoYWxsZW5nZS9sLTJ6 RkNkRVFUM0g1YWRCbk9fV0Z1VEFBM3Q0QlY0aG5GcVd3dGxnbnBvLzg1NDM8YnI+DQo8YnI+DQou Li4gbm90ZTogSldLIHdyYXBwaW5nIGVsaWRlZCAuLi48YnI+DQp7PGJyPg0KJm5ic3A7ICZxdW90 O2tleUF1dGhvcml6YXRpb24mcXVvdDs6ICZxdW90O0xDMmVFWV85bFJMZ3hVZkNNRTZUTUI0YlMw d3NsbTJQRExUQzItSlUtWVkuPHNwYW4gc3R5bGU9ImNvbG9yOiNDQzAwMDAiPmJKY2dySzZvVHZq Z3ZrdU1PT2twZFM4QmRPb3RxZl96OVQ4enctZUZXT0U8L3NwYW4+JnF1b3Q7PGJyPg0KfTxicj4N Ci4uLjxicj4NCjxicj4NCk5vdGU6IFRoZSBrZXkgYXV0aG9yaXphdGlvbiBpbiB0aGlzIFBPU1Qg Y29udGFpbnMgdGhlIGN1cnJlbnQgYWNjb3VudCBrZXkgdGh1bWJwcmludC4gSWYgaXQgY29udGFp bmVkIHRoZSBvbGQgYWNjb3VudCBrZXkgdGh1bWJwcmludCwgdGhlIEFDTUUgc2VydmVyIHdvdWxk IHJlamVjdCBpdC48YnI+DQo8YnI+DQo0LiBXZWRuZXNkYXk6IFRoZSBBQ01FIHNlcnZlciBhY2Nl cHRzIHRoZSBjaGFsbGVuZ2UgdXBkYXRlLCBhbmQgbWFrZXMgYSB2YWxpZGF0aW9uIHJlcXVlc3Qg dG8NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwLTNBX193d3cuZXhhbXBsZS5jb21fLndlbGwtMkRrbm93bl9hY21lLTJEY2hhbGxlbmdlX0xD MmVFWS01RjlsUkxneFVmQ01FNlRNQjRiUzB3c2xtMlBETFRDMi0yREpVLTJEWVkmYW1wO2Q9RHdN RGFRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9Z1h3cnItTHRFOS1XdHpNRmt1 UFZWUSZhbXA7bT1LZjcxdGE4SXZ5SHJtUkJMeW9mdFd4anpTc2lBYzR0QU43T2RhbkxRb2RzJmFt cDtzPXprX2h5ZlpuaWg2V3lwZ05DV1pnaFZCaGZTSnRhS3V5NlYxOGpxaElSc0kmYW1wO2U9Ij4N Cmh0dHA6Ly93d3cuZXhhbXBsZS5jb20vLndlbGwta25vd24vYWNtZS1jaGFsbGVuZ2UvTEMyZUVZ XzlsUkxneFVmQ01FNlRNQjRiUzB3c2xtMlBETFRDMi1KVS1ZWTwvYT4uIEl0IHJlY2VpdmVzIGEg cmVzcG9uc2UgJnF1b3Q7TEMyZUVZXzlsUkxneFVmQ01FNlRNQjRiUzB3c2xtMlBETFRDMi1KVS1Z WS48c3BhbiBzdHlsZT0iY29sb3I6I0NDMzNDQyI+TUtnQUI4bGpacFF2MGh4dWlwQTcwTDBTWmtt WElVaGJPNjFmUjN2S3ZqODwvc3Bhbj4mcXVvdDsuIEhvd2V2ZXIsDQogdGhlIEFDTUUgc2VydmVy IHdhcyBleHBlY3RpbmcgJnF1b3Q7TEMyZUVZXzlsUkxneFVmQ01FNlRNQjRiUzB3c2xtMlBETFRD Mi1KVS1ZWS48c3BhbiBzdHlsZT0iY29sb3I6I0NDMDAwMCI+YkpjZ3JLNm9Udmpndmt1TU9Pa3Bk UzhCZE9vdHFmX3o5VDh6dy1lRldPRTwvc3Bhbj4mcXVvdDssIGJlY2F1c2UgdGhhdCdzIHdoYXQg d2FzIFBPU1RlZCBhcyBwYXJ0IG9mIHRoZSBjaGFsbGVuZ2UgdXBkYXRlLiBTbyB0aGUgdmFsaWRh dGlvbiByZXF1ZXN0IGZhaWxzLCBhbmQNCiBgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy5leGFtcGxlLmNvbSZhbXA7ZD1Ed01E YVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1nWHdyci1MdEU5LVd0ek1Ga3VQ VlZRJmFtcDttPUtmNzF0YThJdnlIcm1SQkx5b2Z0V3hqelNzaUFjNHRBTjdPZGFuTFFvZHMmYW1w O3M9QldkWVVFS3J3dGo5Q0pDT194UEhsdUxub1JXc2dIelBDdU5sNEtuODhvWSZhbXA7ZT0iPnd3 dy5leGFtcGxlLmNvbTwvYT5gIGhhcw0KIHRvIHN0YXJ0IHRoZSB3aG9sZSBpc3N1YW5jZSBwcm9j ZXNzIGFsbCBvdmVyIGFnYWluLjxicj4NCjxicj4NCjxicj4NClRoZXJlJ3Mgb25lIGFkZGl0aW9u YWwgcGllY2Ugb2YgY29udGV4dCBoZXJlOiBXZSBhc3N1bWUgdGhhdCB0aGUgaG9zdGluZyBwcm92 aWRlciBvcGVyYXRpbmcgdGhlIEFDTUUgY2xpZW50IGRvZXNuJ3QgeWV0IGNvbnRyb2wgYDxhIGhy ZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193 d3cuZXhhbXBsZS5jb20mYW1wO2Q9RHdNRGFRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcm YW1wO3I9Z1h3cnItTHRFOS1XdHpNRmt1UFZWUSZhbXA7bT1LZjcxdGE4SXZ5SHJtUkJMeW9mdFd4 anpTc2lBYzR0QU43T2RhbkxRb2RzJmFtcDtzPUJXZFlVRUtyd3RqOUNKQ09feFBIbHVMbm9SV3Nn SHpQQ3VObDRLbjg4b1kmYW1wO2U9Ij53d3cuZXhhbXBsZS5jb208L2E+YC4NCiBUaGlzIGNhbiBo YXBwZW4sIGZvciBpbnN0YW5jZSwgd2hlbiBhIGhvc3RpbmcgcHJvdmlkZXIgaXMgdHJ5aW5nIHRv IG9uYm9hcmQgYSBjdXN0b21lciB3aG8gYWxyZWFkeSB1c2VzIEhUVFBTLiBUaGUgaG9zdGluZyBw cm92aWRlciBuZWVkcyB0byBoYXZlIGEgdmFsaWQgY2VydGlmaWNhdGUgaW4gcGxhY2UgKmJlZm9y ZSogdGhlIGN1c3RvbWVyIENOQU1FcyB0aGVpciBkb21haW4gbmFtZSB0aGUgdGhlIGhvc3Rpbmcg cHJvdmlkZXIuPGJyPg0KPGJyPg0KVGhlICZxdW90O2NsYXJpZnkgaW1wYWN0IG9mIHJvbGwtb3Zl ciZxdW90OyBQUiAoPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX19naXRodWIuY29tX2lldGYtMkR3Zy0yRGFjbWVfYWNtZV9wdWxsXzMy M19maWxlcyZhbXA7ZD1Ed01EYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1n WHdyci1MdEU5LVd0ek1Ga3VQVlZRJmFtcDttPUtmNzF0YThJdnlIcm1SQkx5b2Z0V3hqelNzaUFj NHRBTjdPZGFuTFFvZHMmYW1wO3M9c3NRdmcwN1lqd0M0N1hQeW5UbnJwUU1Xd2NPcGtCSUhGdm12 Z1c3YTA3byZhbXA7ZT0iPmh0dHBzOi8vZ2l0aHViLmNvbS9pZXRmLXdnLWFjbWUvYWNtZS9wdWxs LzMyMy9maWxlczwvYT4pDQogaXMgYSBuaWNlIGNsYXJpZmljYXRpb24sIGJ1dCBkb2Vzbid0IGFj dHVhbGx5IGFkZHJlc3MgdGhpcyB1c2UgY2FzZS4gVGhlIGlzc3VlIGhlcmUgaXMgd2hhdCBoYXBw ZW5zIGR1cmluZyB0aGUgcGVyaW9kIGJldHdlZW4gY3JlYXRpb24gb2YgYSBjaGFsbGVuZ2UgYW5k IHRoZSBBQ01FIGNsaWVudCByZXF1ZXN0aW5nIHZhbGlkYXRpb24gb2YgdGhhdCBjaGFsbGVuZ2Us IHdoaWNoIGluIGN1cnJlbnQgaW1wbGVtZW50YXRpb25zIGNhbiBiZSB1cCB0bw0KIDcgZGF5cy48 YnI+DQo8YnI+DQpUaGVyZSBhcmUgdHdvIG1haW4gYXBwcm9hY2hlcyBJIHNlZTo8YnI+DQo8YnI+ DQpBKSBXZSBjb3VsZCBjaGFuZ2UgdGhlIHNwZWMgdG8gc2V0IHRoZSBrZXlBdXRob3JpemF0aW9u IGZpZWxkIHdoZW4gYSBjaGFsbGVuZ2UgaXMgY3JlYXRlZCwgc28gdGhhdCBpdCB3b3VsZCBoYXZl IHRoZSBjdXJyZW50IGFjY291bnQga2V5IHRodW1icHJpbnQgYmFrZWQgaW4uIFRoaXMgd291bGQg YWxsb3cgaG9zdGluZyBwcm92aWRlcnMgdG8gdHJlYXQgdGhlIGtleSBhdXRob3JpemF0aW9uIG1v cmUgbGlrZSBhbiBvcGFxdWUgc3RyaW5nLCBhbmQgY2FsY3VsYXRlDQogaXQgYXQgY2hhbGxlbmdl IGNyZWF0aW9uIHRpbWUgcmF0aGVyIHRoYW4gYXQgY2hhbGxlbmdlIHVwZGF0ZSB0aW1lLjxicj4N Cjxicj4NCkIpIFdlIGNvdWxkIGVuY291cmFnZSBpbXBsZW1lbnRlcnMgdG8gc2hvcnRlbiB0aGUg dGltZSBiZXR3ZWVuIGNoYWxsZW5nZSBjcmVhdGlvbiBhbmQgdmFsaWRhdGlvbiBieSBkb2luZyBk ZWxlZ2F0aW9uLiBUaGF0IGlzLCBpbnN0ZWFkIG9mIGdpdmluZyBgPGEgaHJlZj0iaHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3d3dy5leGFtcGxlLmNv bSZhbXA7ZD1Ed01EYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1nWHdyci1M dEU5LVd0ek1Ga3VQVlZRJmFtcDttPUtmNzF0YThJdnlIcm1SQkx5b2Z0V3hqelNzaUFjNHRBTjdP ZGFuTFFvZHMmYW1wO3M9QldkWVVFS3J3dGo5Q0pDT194UEhsdUxub1JXc2dIelBDdU5sNEtuODhv WSZhbXA7ZT0iPnd3dy5leGFtcGxlLmNvbTwvYT5gDQogYSB0b2tlbiwgYW5kIHdhaXRpbmcgZm9y IHRoZW0gdG8gZGVwbG95IGl0LCB0aGUgaG9zdGluZyBwcm92aWRlciBjb3VsZCBzYXkgJnF1b3Q7 UGxlYXNlIGRlbGVnYXRlIGlzc3VhbmNlIGF1dGhvcml0eSB0byB1cywgZWl0aGVyIGJ5IHJlZGly ZWN0aW5nIGFsbCBvZiAvLndlbGwta25vd24vYWNtZS12YWxpZGF0aW9uLyogdG8gb3VyIHZhbGlk YXRpb24gc2VydmVyLCBvciBieSBDTkFNRWluZyBfYWNtZS1jaGFsbGVuZ2Uud3d3LmV4YW1wbGUu Y29tIHRvIG91cg0KIHZhbGlkYXRpb24gc2VydmVyLiZxdW90OyBUaGUgbWFpbiBwcm9ibGVtcyB3 aXRoIHRoaXM6IHRoZSBvd25lcnMgb2YgYDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193d3cuZXhhbXBsZS5jb20mYW1wO2Q9RHdNRGFR JmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9Z1h3cnItTHRFOS1XdHpNRmt1UFZW USZhbXA7bT1LZjcxdGE4SXZ5SHJtUkJMeW9mdFd4anpTc2lBYzR0QU43T2RhbkxRb2RzJmFtcDtz PUJXZFlVRUtyd3RqOUNKQ09feFBIbHVMbm9SV3NnSHpQQ3VObDRLbjg4b1kmYW1wO2U9Ij53d3cu ZXhhbXBsZS5jb208L2E+YA0KIG1heSBub3QgYmUgZmFtaWxpYXIgZW5vdWdoIHdpdGggcmVkaXJl Y3RzIChhbHRob3VnaCBDTkFNRXMgc2hvdWxkIGJlIGVhc3kpOyB0aGUgb3duZXJzIG9mIGA8YSBo cmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9f d3d3LmV4YW1wbGUuY29tJmFtcDtkPUR3TURhUSZhbXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpn JmFtcDtyPWdYd3JyLUx0RTktV3R6TUZrdVBWVlEmYW1wO209S2Y3MXRhOEl2eUhybVJCTHlvZnRX eGp6U3NpQWM0dEFON09kYW5MUW9kcyZhbXA7cz1CV2RZVUVLcnd0ajlDSkNPX3hQSGx1TG5vUldz Z0h6UEN1Tmw0S244OG9ZJmFtcDtlPSI+d3d3LmV4YW1wbGUuY29tPC9hPmANCiBtYXkgaGF2ZSBh IGNvbmN1cnJlbnRseSBydW5uaW5nIEFDTUUgY2xpZW50IG9mIHRoZWlyIG93biB0aGF0IG5lZWRz IHRvIHJlbmV3IGR1cmluZyB0aGUgdGltZSB3aW5kb3cgdGhleSB3b3VsZCBiZSBzZXJ2aW5nIGEg cmVkaXJlY3Qgb3IgQ05BTUUuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_30977E7EFD364FB1A7CF1390095E1EB2akamaicom_--