From nobody Mon Oct 2 14:04: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 5F02B132125 for ; Mon, 2 Oct 2017 14:04:41 -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 8x6_sT5IbX4H for ; Mon, 2 Oct 2017 14:04:39 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 06DA513320B for ; Mon, 2 Oct 2017 14:04:39 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id u12so3500401pfl.4 for ; Mon, 02 Oct 2017 14:04:39 -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:content-transfer-encoding; bh=N5/tbT7VFZEkIrwBzHJhaS74XhOufTk/VjdcVoV8czE=; b=oKtOuBZCeSvpoWhqcmKABqjOsakRR5PG3jy6pPQ0gDAlrMiuF7cTmSe2cUewcty52K LFY4j6LvWKFb+uPYtVN2/i6HKO9oItCcDMpeZJb9wyC0CLbTLY4v7q/AkjuxMsnqoGZS zNjiIY5fspObeDZx0Rzys2bM+pf004PLrBGPNLHWKpcRYnK0wHiPBxmSn7QOnvGkd1Z7 OBJCskKpKUGpnZJoFrpekhMEjJEFcmF7WGVB2qHyIEoW17C7HIkdan5ctuCEICJQ9nt0 B0Tj1OCw8YJFlhvqTuzpwhP+z98d8NifvYJuo4cK7sdj3d8+qwnZ21x+Wr4W1f8Lckv4 EcFw== 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:content-transfer-encoding; bh=N5/tbT7VFZEkIrwBzHJhaS74XhOufTk/VjdcVoV8czE=; b=Rfoq4L5CnrHUwl3f2ILA5XEHvtQ03kCTOsDjeh54zSYjfZshHiGIa76EowwIWzwpUZ 38luVkX6kbi8dzNyS76dh2WRVv3MOj1Gc0CvQM2Jw+4sllNbdV2F0imHM/9wUTG2kUh6 NEaq6ydf1t7UIwj2bdGlr7xwBGP9cAgr2/mfqmhL+1eLKeIpyqrIMZgh6MB80UQFIxPa +NkQjaNnAkMdh076oFaxQHz52kjeFp2O5P4DKily959ixPDRFAA4e3c1FqfLHPZzJfeU lgGLzYxj+yjX3zbbSamlIIgVybWgTDNkoy5h0AzB1eZsR51hHTdJihsg5Uu9y1JqFK0I xrIw== X-Gm-Message-State: AHPjjUhYc0CmTDPzsJYFFuqwTsyy1yTZDe6bZ6K+Rrfd17tYmKsz2ekd ut2iAznd6/sRxNLPGyuIH+Kx7O77ubO0EymG5yQ= X-Google-Smtp-Source: AOwi7QDrbyKoCwHQyVZRgRzIrAOAY04xR4RIKKsm5igQGHtlB0lrM+th8rzd3ZaPPMy0FGs5A413U5qxkodI6UQPg7M= X-Received: by 10.98.102.82 with SMTP id a79mr15861840pfc.109.1506978278528; Mon, 02 Oct 2017 14:04:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.151.233 with HTTP; Mon, 2 Oct 2017 14:03:57 -0700 (PDT) In-Reply-To: <0619953C-C4D0-4846-82ED-C814073F6DFC@gmail.com> References: <0619953C-C4D0-4846-82ED-C814073F6DFC@gmail.com> From: Kathleen Moriarty Date: Mon, 2 Oct 2017 17:03:57 -0400 Message-ID: To: Clint Wilson Cc: Mary Barnes , IETF ACME Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Acme] AD review of draft-ietf-acme-acme 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, 02 Oct 2017 21:04:41 -0000 Hello, Is there any chance we'll get through this review so I can start last call this week? In order to have it on the last telechat before Singapore, we'd need to have an update ready for me to start last call. Thanks to those who gave feedback on my DV cert questions. Thanks, Kathleen On Fri, Sep 22, 2017 at 6:03 PM, Kathleen Moriarty wrote: > Thanks for the input and the offline message, Mary. An offline process i= s > needed from what I can tell to use ACME for anything considered a higher > assurance than a DV cert, is that right? If so, I think it's important t= o > make that clear with a simple sentence. > > Thank you, > Kathleen > > Sent from my iPhone > > On Sep 22, 2017, at 5:33 PM, Clint Wilson wrot= e: > > An additional 1/2 cent from me; we intend to use ACME primarily, if not > solely, with non-DV certs. > > > On Fri, Sep 22, 2017, 2:51 PM Mary Barnes > wrote: >> >> Just to throw in my 1/2 cent. We are using ACME for non-DV certificates >> in the ATIS/SIP Forum SHAKEN framework as detailed in ATIS-1000080: >> https://www.sipforum.org/download/joint-atissip-forum-standard-signature= -based-handling-asserted-information-using-tokens-shaken-governance-model-c= ertificate-management-atis-1000080/?wpdmdl=3D3360 >> >> Regards, >> Mary. >> >> On Fri, Sep 22, 2017 at 3:14 PM, Kathleen Moriarty >> wrote: >>> >>> Hello, >>> >>> Thank you to the editors and WG for your efforts on >>> draft-ietf-acme-acme, it's a well written and easy to understand >>> draft. I do have a few comments, that need to be address by the >>> editors and SHEPHERD. >>> >>> Please review the idnits. There are a few warnings that should be >>> correctable and can be addressed, but more importantly, it calls out >>> several downrefs that are not in the shepherd writeup. These need to >>> be in the writeup and then also mentioned in the IETF last call >>> announcement (I'll make sure the latter happens). >>> >>> Here's my mostly editorial comments: >>> >>> Introduction: >>> It reads very well, but it would be helpful to those unfamiliar with >>> the work to explicitly state that ACME is about DV certificates. The >>> first sentence of the last paragraph seems like the best place to add >>> this in. >>> Current text: >>> This document describes an extensible framework for automating the >>> issuance and domain validation procedure, thereby allowing servers >>> and infrastructural software to obtain certificates without user >>> interaction. >>> Proposed: >>> This document describes an extensible framework for automating the >>> issuance and domain validation procedure for DV certificates, >>> thereby allowing servers >>> and infrastructural software to obtain certificates without user >>> interaction. >>> >>> I do like how the introduction is framed as it=E2=80=99s clear the leve= l of >>> security provided by the certificates issued via ACME. Thanks for >>> that. >>> >>> The introduction should also make it clear that ACME can be used for >>> other services using DV certificates, not just HTTP. This is >>> mentioned in the Terminology section, but I think a clear sentence >>> upfront would be helpful. >>> >>> Section 2: Nit/suggestion: Change the tense to read as a published RFC >>> in the last paragraph, last sentence (take it or leave it). >>> Current: >>> Such close integration of ACME with HTTPS >>> servers would allow the immediate and automated deployment of >>> certificates as they are issued, sparing the human administrator fro= m >>> much of the time-consuming work described in the previous section. >>> Proposed: >>> Such close integration of ACME with HTTPS >>> servers allows the immediate and automated deployment of >>> certificates as they are issued, sparing the human administrator fro= m >>> much of the time-consuming work described in the previous section. >>> >>> IANA Section: >>> Everything looks good except that RFC5226 has been obsoleted, so the >>> new reference is RFC8126 and =E2=80=9Cspecification required=E2=80=9D >>> https://tools.ietf.org/html/rfc8126#section-4.6 still means the same >>> thing, so using that is fine. >>> >>> Security considerations: >>> I think it would be good to mention here that they are DV certs so the >>> reader understands from he introduction and this section the level of >>> cert issued through ACME and doesn=E2=80=99t assume a higher level of >>> assurance. >>> >>> s/ACME is a protocol for managing certificates/ACME is a protocol for >>> managing DV certificates/ >>> >>> 10.1 - I know this is obvious to the people in the WG, but a reference >>> to RFC7525 to properly configure TLS 1.2 should be included to protect >>> against the mentioned attacks. If you want to also reference TLS 1.3 >>> and specify no 0-RTT that would be good too. It=E2=80=99d be great to = see >>> this get widely deployed, so there may be a number of newcomers >>> reading this to make their lives easier with cert >>> issuance/maintenance. >>> >>> 10.2 - what if the server that the account verifier has an account on >>> (client for ACME) is compromised and is used to request new >>> certificates or perform other actions? I think this is one of the >>> larger risks, so mentioning this is possible and hardening measures >>> should be taken to prevent compromise would be prudent. Hardening >>> measures or appropriate security controls should be broadly understood >>> terms (I think) so that you wouldn=E2=80=99t need to list out things li= ke >>> turing off unnecessary services. >>> >>> 10.5 - I would think you=E2=80=99d see requests for new phishing domain= s >>> rather than known ones through this process. What would you look for >>> there as that=E2=80=99s a complex problem - it would be hard to know al= l legit >>> names to know if one was a play off of the original. This happened >>> with equifax - they provided a site name with a typo and a =E2=80=98whi= te hat=E2=80=99 >>> attacker had set up a site that looked just like theirs at that site. >>> But it was announced by equifax. Tough problem as automating a check >>> on the DNS registration may not detect something unusual, but maybe >>> recommending this check could help? RDP lessens what needs to be >>> shared from whois though, although I don=E2=80=99t think that=E2=80=99s= widely >>> deployed. >>> >>> -- >>> >>> Best regards, >>> Kathleen >>> >>> _______________________________________________ >>> 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 --=20 Best regards, Kathleen From nobody Mon Oct 2 15:40: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 450BF134224 for ; Mon, 2 Oct 2017 15:40:37 -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 ue6b07ojFDvW for ; Mon, 2 Oct 2017 15:40:34 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 5E15A13422F for ; Mon, 2 Oct 2017 15:40:34 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id u67so6797146qkg.6 for ; Mon, 02 Oct 2017 15:40: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=uTstxgFWvDssQQgrO7TWj2ABZs+e3x7Yw3OISgM4QxE=; b=jLNpQYrUiCHVXZE5sul6yHgdwZ1h1jMwU2ty8iswh3uOsU8Qb05Ujafh/uCoqTrgNY gv7BDRYIm7/epDHIbTXVvQdNgBSGKRCyABiozzEfdcf6fTYCiHC7091V7w6l8Tb58ZBA CB6MoGtlkt5oX/Awg1TXI7/Rj5TtcZgcVG278XjLaEECyfYZV12iVjrOfOPWPsNWhHTs vbWFA9A7mcNenEx4U1WAEfRw22M6sujadX+st9WWHZ56dVfkAQrL92he79PlhhyMAbmm dsIlE8FS4s3Ya9M5ULhZ+KQAZL3egUtM/ykUdoH+QyRclvGJZ+tQxW/aHziItaxDpMAj lKLQ== 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=uTstxgFWvDssQQgrO7TWj2ABZs+e3x7Yw3OISgM4QxE=; b=Nr/D+o+TvWAKTRP8ZKibgXqtGX35gA3dlmeOBHrR6bGvSN8n/uUqDtY+H3qC0XCHut kA19OF5UNRHe1SWdfv4PsHsZJR9IK7kAkkH2TfeDsfTprH6OqyxdKRo10atrZh80AJ49 XOHBATyrRVhLWOz+0IaawI7oiEWAoDnZK0La/UyYH90M4UtKw2yufK9ZaJosisjqB1KM gEEfvPGfL8G2XaGY0F+V1zCqvrUMsFcuXBM0JB4AtVHyDXJEtHoUxvk9hcwh1PGrBMLp zi/7vMsQI2ipOVd+cnhZTkW3343dFdDf1gbvbUQQGZI+owGP3YE7k33Thmzj7x7K9HZD aVtQ== X-Gm-Message-State: AMCzsaX2gb5ZhTTtXM7myAinpR3jB32fAnFkdnLzQEAWknHPSgZVbi0r lg/AHtstdEHxtJ4pagLNs9EhvThWb49St3NnckM= X-Google-Smtp-Source: AOwi7QAUrsZzTDZ4+W6i4JKH5Iapn3GpEIo+6SZQY3POulmZzsMg6lJ6AmncSZq667Di0mWSEGU3O8ayQ2Qr126QYe0= X-Received: by 10.55.114.195 with SMTP id n186mr3761577qkc.319.1506984033476; Mon, 02 Oct 2017 15:40:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.32.202 with HTTP; Mon, 2 Oct 2017 15:40:32 -0700 (PDT) In-Reply-To: <0619953C-C4D0-4846-82ED-C814073F6DFC@gmail.com> References: <0619953C-C4D0-4846-82ED-C814073F6DFC@gmail.com> From: Mary Barnes Date: Mon, 2 Oct 2017 17:40:32 -0500 Message-ID: To: Kathleen Moriarty Cc: Clint Wilson , IETF ACME Content-Type: multipart/alternative; boundary="001a114fe984ff6c56055a980fcf" Archived-At: Subject: Re: [Acme] AD review of draft-ietf-acme-acme 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, 02 Oct 2017 22:40:37 -0000 --001a114fe984ff6c56055a980fcf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It's not so much an offline process as it is an out-of-band process from ACME for the ACME client to get the Service Provider code token that it uses for the challenge. But, perhaps what you're asking for is a statement in the intro that talks about DV certificates being most common? The primary difference between how we use ACME is the identifier validation, where for SHAKEN it's the Service Provider Code token. Regards, Mary. On Fri, Sep 22, 2017 at 5:03 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Thanks for the input and the offline message, Mary. An offline process i= s > needed from what I can tell to use ACME for anything considered a higher > assurance than a DV cert, is that right? If so, I think it's important t= o > make that clear with a simple sentence. > > Thank you, > Kathleen > > Sent from my iPhone > > On Sep 22, 2017, at 5:33 PM, Clint Wilson > wrote: > > An additional 1/2 cent from me; we intend to use ACME primarily, if not > solely, with non-DV certs. > > On Fri, Sep 22, 2017, 2:51 PM Mary Barnes > wrote: > >> Just to throw in my 1/2 cent. We are using ACME for non-DV certificates >> in the ATIS/SIP Forum SHAKEN framework as detailed in ATIS-1000080: >> https://www.sipforum.org/download/joint-atissip-forum- >> standard-signature-based-handling-asserted-information- >> using-tokens-shaken-governance-model-certificate- >> management-atis-1000080/?wpdmdl=3D3360 >> >> Regards, >> Mary. >> >> On Fri, Sep 22, 2017 at 3:14 PM, Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> wrote: >> >>> Hello, >>> >>> Thank you to the editors and WG for your efforts on >>> draft-ietf-acme-acme, it's a well written and easy to understand >>> draft. I do have a few comments, that need to be address by the >>> editors and SHEPHERD. >>> >>> Please review the idnits. There are a few warnings that should be >>> correctable and can be addressed, but more importantly, it calls out >>> several downrefs that are not in the shepherd writeup. These need to >>> be in the writeup and then also mentioned in the IETF last call >>> announcement (I'll make sure the latter happens). >>> >>> Here's my mostly editorial comments: >>> >>> Introduction: >>> It reads very well, but it would be helpful to those unfamiliar with >>> the work to explicitly state that ACME is about DV certificates. The >>> first sentence of the last paragraph seems like the best place to add >>> this in. >>> Current text: >>> This document describes an extensible framework for automating the >>> issuance and domain validation procedure, thereby allowing servers >>> and infrastructural software to obtain certificates without user >>> interaction. >>> Proposed: >>> This document describes an extensible framework for automating the >>> issuance and domain validation procedure for DV certificates, >>> thereby allowing servers >>> and infrastructural software to obtain certificates without user >>> interaction. >>> >>> I do like how the introduction is framed as it=E2=80=99s clear the leve= l of >>> security provided by the certificates issued via ACME. Thanks for >>> that. >>> >>> The introduction should also make it clear that ACME can be used for >>> other services using DV certificates, not just HTTP. This is >>> mentioned in the Terminology section, but I think a clear sentence >>> upfront would be helpful. >>> >>> Section 2: Nit/suggestion: Change the tense to read as a published RFC >>> in the last paragraph, last sentence (take it or leave it). >>> Current: >>> Such close integration of ACME with HTTPS >>> servers would allow the immediate and automated deployment of >>> certificates as they are issued, sparing the human administrator fro= m >>> much of the time-consuming work described in the previous section. >>> Proposed: >>> Such close integration of ACME with HTTPS >>> servers allows the immediate and automated deployment of >>> certificates as they are issued, sparing the human administrator fro= m >>> much of the time-consuming work described in the previous section. >>> >>> IANA Section: >>> Everything looks good except that RFC5226 has been obsoleted, so the >>> new reference is RFC8126 and =E2=80=9Cspecification required=E2=80=9D >>> https://tools.ietf.org/html/rfc8126#section-4.6 still means the same >>> thing, so using that is fine. >>> >>> Security considerations: >>> I think it would be good to mention here that they are DV certs so the >>> reader understands from he introduction and this section the level of >>> cert issued through ACME and doesn=E2=80=99t assume a higher level of >>> assurance. >>> >>> s/ACME is a protocol for managing certificates/ACME is a protocol for >>> managing DV certificates/ >>> >>> 10.1 - I know this is obvious to the people in the WG, but a reference >>> to RFC7525 to properly configure TLS 1.2 should be included to protect >>> against the mentioned attacks. If you want to also reference TLS 1.3 >>> and specify no 0-RTT that would be good too. It=E2=80=99d be great to = see >>> this get widely deployed, so there may be a number of newcomers >>> reading this to make their lives easier with cert >>> issuance/maintenance. >>> >>> 10.2 - what if the server that the account verifier has an account on >>> (client for ACME) is compromised and is used to request new >>> certificates or perform other actions? I think this is one of the >>> larger risks, so mentioning this is possible and hardening measures >>> should be taken to prevent compromise would be prudent. Hardening >>> measures or appropriate security controls should be broadly understood >>> terms (I think) so that you wouldn=E2=80=99t need to list out things li= ke >>> turing off unnecessary services. >>> >>> 10.5 - I would think you=E2=80=99d see requests for new phishing domain= s >>> rather than known ones through this process. What would you look for >>> there as that=E2=80=99s a complex problem - it would be hard to know al= l legit >>> names to know if one was a play off of the original. This happened >>> with equifax - they provided a site name with a typo and a =E2=80=98whi= te hat=E2=80=99 >>> attacker had set up a site that looked just like theirs at that site. >>> But it was announced by equifax. Tough problem as automating a check >>> on the DNS registration may not detect something unusual, but maybe >>> recommending this check could help? RDP lessens what needs to be >>> shared from whois though, although I don=E2=80=99t think that=E2=80=99s= widely >>> deployed. >>> >>> -- >>> >>> Best regards, >>> Kathleen >>> >>> _______________________________________________ >>> 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 >> > --001a114fe984ff6c56055a980fcf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's not so much an offline process as it is an out-of= -band process from ACME=C2=A0 for the ACME client to get the Service Provid= er code token that it uses for the challenge.=C2=A0 But, perhaps what you&#= 39;re asking for is a statement in the intro that talks about DV certificat= es being most common?=C2=A0 =C2=A0 =C2=A0The primary difference between how= we use ACME is the identifier validation, where for SHAKEN it's the Se= rvice Provider Code token.=C2=A0=C2=A0

Regards,
Mary.=C2=A0

On Fri, Sep 22, 2017 at 5:03 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
Thanks for the input and the offline = message, Mary.=C2=A0 An offline process is needed from what I can tell to u= se ACME for anything considered a higher assurance than a DV cert, is that = right?=C2=A0 If so, I think it's important to make that clear with a si= mple sentence.
Thank you,
Kathleen=C2=A0
Sent from my iPhone

On Sep 22, 2017,= at 5:33 PM, Clint Wilson <clint.t.wilson@gmail.com> wrote:

An additional 1/2 cent from me; we= intend to use ACME primarily, if not solely, with non-DV certs.


On Fri, Sep 22, 2017, 2:51 = PM Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
Just to throw in my 1/2 cent.=C2=A0 We are = using ACME for non-DV certificates in the ATIS/SIP Forum SHAKEN framework a= s detailed in ATIS-1000080: =C2=A0https://www.sipforum.org/download/= joint-atissip-forum-standard-signature-based-handling-asserted-in= formation-using-tokens-shaken-governance-model-certificate-m= anagement-atis-1000080/?wpdmdl=3D3360

Regar= ds,
Mary.

On Fri, Sep 22, 2017 at 3:14 PM, Kathle= en Moriarty <kathleen.moriarty.ietf@gmail.com><= /span> wrote:
Hello,

Thank you to the editors and WG for your efforts on
draft-ietf-acme-acme, it's a well written and easy to understand
draft.=C2=A0 I do have a few comments, that need to be address by the
editors and SHEPHERD.

Please review the idnits.=C2=A0 There are a few warnings that should be
correctable and can be addressed, but more importantly, it calls out
several downrefs that are not in the shepherd writeup.=C2=A0 These need to<= br> be in the writeup and then also mentioned in the IETF last call
announcement (I'll make sure the latter happens).

Here's my mostly editorial comments:

Introduction:
It reads very well, but it would be helpful to those unfamiliar with
the work to explicitly state that ACME is about DV certificates.=C2=A0 The<= br> first sentence of the last paragraph seems like the best place to add
this in.
Current text:
=C2=A0 =C2=A0This document describes an extensible framework for automating= the
=C2=A0 =C2=A0issuance and domain validation procedure, thereby allowing ser= vers
=C2=A0 =C2=A0and infrastructural software to obtain certificates without us= er
=C2=A0 =C2=A0interaction.
Proposed:
=C2=A0 =C2=A0This document describes an extensible framework for automating= the
=C2=A0 =C2=A0issuance and domain validation procedure for DV certificates,<= br> thereby allowing servers
=C2=A0 =C2=A0and infrastructural software to obtain certificates without us= er
=C2=A0 =C2=A0interaction.

I do like how the introduction is framed as it=E2=80=99s clear the level of=
security provided by the certificates issued via ACME.=C2=A0 Thanks for
that.

The introduction should also make it clear that ACME can be used for
other services using DV certificates, not just HTTP.=C2=A0 This is
mentioned in the Terminology section, but I think a clear sentence
upfront would be helpful.

Section 2: Nit/suggestion: Change the tense to read as a published RFC
in the last paragraph, last sentence (take it or leave it).
Current:
=C2=A0 =C2=A0Such close integration of ACME with HTTPS
=C2=A0 =C2=A0servers would allow the immediate and automated deployment of<= br> =C2=A0 =C2=A0certificates as they are issued, sparing the human administrat= or from
=C2=A0 =C2=A0much of the time-consuming work described in the previous sect= ion.
Proposed:
=C2=A0 =C2=A0Such close integration of ACME with HTTPS
=C2=A0 =C2=A0servers allows the immediate and automated deployment of
=C2=A0 =C2=A0certificates as they are issued, sparing the human administrat= or from
=C2=A0 =C2=A0much of the time-consuming work described in the previous sect= ion.

IANA Section:
Everything looks good except that RFC5226 has been obsoleted, so the
new reference is RFC8126 and =E2=80=9Cspecification required=E2=80=9D
https://tools.ietf.org/html/rfc8126#section-4.6<= /a> still means the same
thing, so using that is fine.

Security considerations:
I think it would be good to mention here that they are DV certs so the
reader understands from he introduction and this section the level of
cert issued through ACME and doesn=E2=80=99t assume a higher level of
assurance.

s/ACME is a protocol for managing certificates/ACME is a protocol for
managing DV certificates/

10.1 - I know this is obvious to the people in the WG, but a reference
to RFC7525 to properly configure TLS 1.2 should be included to protect
against the mentioned attacks.=C2=A0 If you want to also reference TLS 1.3<= br> and specify no 0-RTT that would be good too.=C2=A0 It=E2=80=99d be great to= see
this get widely deployed, so there may be a number of newcomers
reading this to make their lives easier with cert
issuance/maintenance.

10.2 - what if the server that the account verifier has an account on
(client for ACME) is compromised and is used to request new
certificates or perform other actions?=C2=A0 I think this is one of the
larger risks, so mentioning this is possible and hardening measures
should be taken to prevent compromise would be prudent.=C2=A0 Hardening
measures or appropriate security controls should be broadly understood
terms (I think) so that you wouldn=E2=80=99t need to list out things like turing off unnecessary services.

10.5 - I would think you=E2=80=99d see requests for new phishing domains rather than known ones through this process.=C2=A0 What would you look for<= br> there as that=E2=80=99s a complex problem - it would be hard to know all le= git
names to know if one was a play off of the original.=C2=A0 This happened with equifax - they provided a site name with a typo and a =E2=80=98white h= at=E2=80=99
attacker had set up a site that looked just like theirs at that site.
But it was announced by equifax.=C2=A0 Tough problem as automating a check<= br> on the DNS registration may not detect something unusual, but maybe
recommending this check could help?=C2=A0 RDP lessens what needs to be
shared from whois though, although I don=E2=80=99t think that=E2=80=99s wid= ely
deployed.

--

Best regards,
Kathleen

_______________________________________________
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

--001a114fe984ff6c56055a980fcf-- From nobody Tue Oct 3 07:17: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 B7B23134CE4 for ; Tue, 3 Oct 2017 07:17:02 -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 8sAoGQNiVJzu for ; Tue, 3 Oct 2017 07:16:54 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 564B2134D18 for ; Tue, 3 Oct 2017 07:15:19 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id h66so7734257ioh.11 for ; Tue, 03 Oct 2017 07:15:19 -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=anOvGSgUzbeKLVq+7EutdE/17nXwF7rmNg+QBw75gtw=; b=PjydltmF71UvFVsfRElrmEQl76aXt8FZqCaiXSbJR81RA22At/71Q9S3kwUH4g7yV7 u9MdJo9RdJedDlNfQokdEwZfSJLnY2QxftvnVTZTj4l1fpYgzpTNgEjkjidh+44JFUab 7D2ooruFvlBiBRSeGjfP46NPtzWwuiuSgz4GY= 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=anOvGSgUzbeKLVq+7EutdE/17nXwF7rmNg+QBw75gtw=; b=gYPUXcIxAGSr3jSenbkgw/dL/BUmuVH3nqqid10WWKjEvOH61xFIS53+whf8veuFv3 U8y82+t9rmqiQHvqrRWVyLNpYhj37dRh1rvUG8Xt1j/rdfLwZk80a2WsNKPdM6OxzunB 2QJ3MqZBcv5MtzUQq8JiYSCgoT50nAV0B12IATsiaP53S35+yaUYWQuJqrXCv2YgaN4c GRtP+bkSsM/safof+kNBSzLdYcJ0qm7qBLn63aZIQQr6U66JqwTWfA1VmGI9bYkXsu+8 l2PN0n4ofTvRxcSlpEepQBRsUZXd2/H2BF542XM/kT4b4fYgX+KjjfFiBhCjGgCbkiqL TdPQ== X-Gm-Message-State: AMCzsaX/rWVOzm9CWRUqzsJl2bMnlqn2udXA/e4gIcqJCn4HE2P0p8mT cqIENpDH7lKHJPa81H4T5xxDmfYdgjQ9RRadVSiI8FuNAzk= X-Google-Smtp-Source: AOwi7QAZ7VH2vTUpAoIN6XQsb0Ez4NRIEOkJZYNDHxYBQvYESd/Tm4wHV9b+8g3kYj0kadkqYNmnuDaEZRGHoLiDdbY= X-Received: by 10.107.131.234 with SMTP id n103mr27830952ioi.236.1507040118502; Tue, 03 Oct 2017 07:15:18 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.137.231 with HTTP; Tue, 3 Oct 2017 07:15:17 -0700 (PDT) In-Reply-To: References: <0619953C-C4D0-4846-82ED-C814073F6DFC@gmail.com> From: Daniel McCarney Date: Tue, 3 Oct 2017 10:15:17 -0400 Message-ID: To: Kathleen Moriarty Cc: Clint Wilson , Mary Barnes , IETF ACME Content-Type: multipart/alternative; boundary="001a113ec866ed3456055aa51e0e" Archived-At: Subject: Re: [Acme] AD review of draft-ietf-acme-acme 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, 03 Oct 2017 14:17:03 -0000 --001a113ec866ed3456055aa51e0e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > > Is there any chance we'll get through this review so I can start last > call this week? I think it is premature to start last-call. There are *no* full implementations of the current draft (as far as I am aware) and experience from attempting a complete implementation has highlighted a problem[0] that will require protocol adjustment. [0] - https://mailarchive.ietf.org/arch/msg/acme/DIjJEB06J5cFyuOlGPVcY2I51v= g On Mon, Oct 2, 2017 at 5:03 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hello, > > Is there any chance we'll get through this review so I can start last > call this week? In order to have it on the last telechat before > Singapore, we'd need to have an update ready for me to start last > call. Thanks to those who gave feedback on my DV cert questions. > > Thanks, > Kathleen > > On Fri, Sep 22, 2017 at 6:03 PM, Kathleen Moriarty > wrote: > > Thanks for the input and the offline message, Mary. An offline process > is > > needed from what I can tell to use ACME for anything considered a highe= r > > assurance than a DV cert, is that right? If so, I think it's important > to > > make that clear with a simple sentence. > > > > Thank you, > > Kathleen > > > > Sent from my iPhone > > > > On Sep 22, 2017, at 5:33 PM, Clint Wilson > wrote: > > > > An additional 1/2 cent from me; we intend to use ACME primarily, if not > > solely, with non-DV certs. > > > > > > On Fri, Sep 22, 2017, 2:51 PM Mary Barnes > > wrote: > >> > >> Just to throw in my 1/2 cent. We are using ACME for non-DV certificat= es > >> in the ATIS/SIP Forum SHAKEN framework as detailed in ATIS-1000080: > >> https://www.sipforum.org/download/joint-atissip-forum- > standard-signature-based-handling-asserted-information- > using-tokens-shaken-governance-model-certificate-management-atis-1000080/= ? > wpdmdl=3D3360 > >> > >> Regards, > >> Mary. > >> > >> On Fri, Sep 22, 2017 at 3:14 PM, Kathleen Moriarty > >> wrote: > >>> > >>> Hello, > >>> > >>> Thank you to the editors and WG for your efforts on > >>> draft-ietf-acme-acme, it's a well written and easy to understand > >>> draft. I do have a few comments, that need to be address by the > >>> editors and SHEPHERD. > >>> > >>> Please review the idnits. There are a few warnings that should be > >>> correctable and can be addressed, but more importantly, it calls out > >>> several downrefs that are not in the shepherd writeup. These need to > >>> be in the writeup and then also mentioned in the IETF last call > >>> announcement (I'll make sure the latter happens). > >>> > >>> Here's my mostly editorial comments: > >>> > >>> Introduction: > >>> It reads very well, but it would be helpful to those unfamiliar with > >>> the work to explicitly state that ACME is about DV certificates. The > >>> first sentence of the last paragraph seems like the best place to add > >>> this in. > >>> Current text: > >>> This document describes an extensible framework for automating the > >>> issuance and domain validation procedure, thereby allowing servers > >>> and infrastructural software to obtain certificates without user > >>> interaction. > >>> Proposed: > >>> This document describes an extensible framework for automating the > >>> issuance and domain validation procedure for DV certificates, > >>> thereby allowing servers > >>> and infrastructural software to obtain certificates without user > >>> interaction. > >>> > >>> I do like how the introduction is framed as it=E2=80=99s clear the le= vel of > >>> security provided by the certificates issued via ACME. Thanks for > >>> that. > >>> > >>> The introduction should also make it clear that ACME can be used for > >>> other services using DV certificates, not just HTTP. This is > >>> mentioned in the Terminology section, but I think a clear sentence > >>> upfront would be helpful. > >>> > >>> Section 2: Nit/suggestion: Change the tense to read as a published RF= C > >>> in the last paragraph, last sentence (take it or leave it). > >>> Current: > >>> Such close integration of ACME with HTTPS > >>> servers would allow the immediate and automated deployment of > >>> certificates as they are issued, sparing the human administrator > from > >>> much of the time-consuming work described in the previous section. > >>> Proposed: > >>> Such close integration of ACME with HTTPS > >>> servers allows the immediate and automated deployment of > >>> certificates as they are issued, sparing the human administrator > from > >>> much of the time-consuming work described in the previous section. > >>> > >>> IANA Section: > >>> Everything looks good except that RFC5226 has been obsoleted, so the > >>> new reference is RFC8126 and =E2=80=9Cspecification required=E2=80=9D > >>> https://tools.ietf.org/html/rfc8126#section-4.6 still means the same > >>> thing, so using that is fine. > >>> > >>> Security considerations: > >>> I think it would be good to mention here that they are DV certs so th= e > >>> reader understands from he introduction and this section the level of > >>> cert issued through ACME and doesn=E2=80=99t assume a higher level of > >>> assurance. > >>> > >>> s/ACME is a protocol for managing certificates/ACME is a protocol for > >>> managing DV certificates/ > >>> > >>> 10.1 - I know this is obvious to the people in the WG, but a referenc= e > >>> to RFC7525 to properly configure TLS 1.2 should be included to protec= t > >>> against the mentioned attacks. If you want to also reference TLS 1.3 > >>> and specify no 0-RTT that would be good too. It=E2=80=99d be great t= o see > >>> this get widely deployed, so there may be a number of newcomers > >>> reading this to make their lives easier with cert > >>> issuance/maintenance. > >>> > >>> 10.2 - what if the server that the account verifier has an account on > >>> (client for ACME) is compromised and is used to request new > >>> certificates or perform other actions? I think this is one of the > >>> larger risks, so mentioning this is possible and hardening measures > >>> should be taken to prevent compromise would be prudent. Hardening > >>> measures or appropriate security controls should be broadly understoo= d > >>> terms (I think) so that you wouldn=E2=80=99t need to list out things = like > >>> turing off unnecessary services. > >>> > >>> 10.5 - I would think you=E2=80=99d see requests for new phishing doma= ins > >>> rather than known ones through this process. What would you look for > >>> there as that=E2=80=99s a complex problem - it would be hard to know = all legit > >>> names to know if one was a play off of the original. This happened > >>> with equifax - they provided a site name with a typo and a =E2=80=98w= hite hat=E2=80=99 > >>> attacker had set up a site that looked just like theirs at that site. > >>> But it was announced by equifax. Tough problem as automating a check > >>> on the DNS registration may not detect something unusual, but maybe > >>> recommending this check could help? RDP lessens what needs to be > >>> shared from whois though, although I don=E2=80=99t think that=E2=80= =99s widely > >>> deployed. > >>> > >>> -- > >>> > >>> Best regards, > >>> Kathleen > >>> > >>> _______________________________________________ > >>> 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 > > > > -- > > Best regards, > Kathleen > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a113ec866ed3456055aa51e0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Is there any chance= we'll get through this review so I can start last
call this week?

I think = it is premature to start last-call.=C2=A0

There ar= e *no* full implementations of the current draft (as far as I am aware) and= experience from attempting a complete implementation has highlighted a pro= blem[0] that will require protocol adjustment.

[0] -=C2=A0ht= tps://mailarchive.ietf.org/arch/msg/acme/DIjJEB06J5cFyuOlGPVcY2I51vg

On Mon, = Oct 2, 2017 at 5:03 PM, Kathleen Moriarty <kathleen.moriart= y.ietf@gmail.com> wrote:
He= llo,

Is there any chance we'll get through this review so I can start last call this week?=C2=A0 In order to have it on the last telechat before
Singapore, we'd need to have an update ready for me to start last
call.=C2=A0 Thanks to those who gave feedback on my DV cert questions.

Thanks,
Kathleen

On Fri, Sep 22, 2017 at 6:03 PM, Kathleen Moriarty
<kathleen.moriarty.ietf@gmail.com> wrote: > Thanks for the input and the offline message, Mary.=C2=A0 An offline p= rocess is
> needed from what I can tell to use ACME for anything considered a high= er
> assurance than a DV cert, is that right?=C2=A0 If so, I think it's= important to
> make that clear with a simple sentence.
>
> Thank you,
> Kathleen
>
> Sent from my iPhone
>
> On Sep 22, 2017, at 5:33 PM, Clint Wilson <clint.t.wilson@gmail.com> wrote:
>
> An additional 1/2 cent from me; we intend to use ACME primarily, if no= t
> solely, with non-DV certs.
>
>
> On Fri, Sep 22, 2017, 2:51 PM Mary Barnes <mary.ietf.barnes@gmail.com>
> wrote:
>>
>> Just to throw in my 1/2 cent.=C2=A0 We are using ACME for non-DV c= ertificates
>> in the ATIS/SIP Forum SHAKEN framework as detailed in ATIS-1000080= :
>> https://www.sipforum.org/download/joint-= atissip-forum-standard-signature-based-handling-asserted-informat= ion-using-tokens-shaken-governance-model-certificate-managem= ent-atis-1000080/?wpdmdl=3D3360
>>
>> Regards,
>> Mary.
>>
>> On Fri, Sep 22, 2017 at 3:14 PM, Kathleen Moriarty
>> <kathleen.m= oriarty.ietf@gmail.com> wrote:
>>>
>>> Hello,
>>>
>>> Thank you to the editors and WG for your efforts on
>>> draft-ietf-acme-acme, it's a well written and easy to unde= rstand
>>> draft.=C2=A0 I do have a few comments, that need to be address= by the
>>> editors and SHEPHERD.
>>>
>>> Please review the idnits.=C2=A0 There are a few warnings that = should be
>>> correctable and can be addressed, but more importantly, it cal= ls out
>>> several downrefs that are not in the shepherd writeup.=C2=A0 T= hese need to
>>> be in the writeup and then also mentioned in the IETF last cal= l
>>> announcement (I'll make sure the latter happens).
>>>
>>> Here's my mostly editorial comments:
>>>
>>> Introduction:
>>> It reads very well, but it would be helpful to those unfamilia= r with
>>> the work to explicitly state that ACME is about DV certificate= s.=C2=A0 The
>>> first sentence of the last paragraph seems like the best place= to add
>>> this in.
>>> Current text:
>>>=C2=A0 =C2=A0 This document describes an extensible framework f= or automating the
>>>=C2=A0 =C2=A0 issuance and domain validation procedure, thereby= allowing servers
>>>=C2=A0 =C2=A0 and infrastructural software to obtain certificat= es without user
>>>=C2=A0 =C2=A0 interaction.
>>> Proposed:
>>>=C2=A0 =C2=A0 This document describes an extensible framework f= or automating the
>>>=C2=A0 =C2=A0 issuance and domain validation procedure for DV c= ertificates,
>>> thereby allowing servers
>>>=C2=A0 =C2=A0 and infrastructural software to obtain certificat= es without user
>>>=C2=A0 =C2=A0 interaction.
>>>
>>> I do like how the introduction is framed as it=E2=80=99s clear= the level of
>>> security provided by the certificates issued via ACME.=C2=A0 T= hanks for
>>> that.
>>>
>>> The introduction should also make it clear that ACME can be us= ed for
>>> other services using DV certificates, not just HTTP.=C2=A0 Thi= s is
>>> mentioned in the Terminology section, but I think a clear sent= ence
>>> upfront would be helpful.
>>>
>>> Section 2: Nit/suggestion: Change the tense to read as a publi= shed RFC
>>> in the last paragraph, last sentence (take it or leave it). >>> Current:
>>>=C2=A0 =C2=A0 Such close integration of ACME with HTTPS
>>>=C2=A0 =C2=A0 servers would allow the immediate and automated d= eployment of
>>>=C2=A0 =C2=A0 certificates as they are issued, sparing the huma= n administrator from
>>>=C2=A0 =C2=A0 much of the time-consuming work described in the = previous section.
>>> Proposed:
>>>=C2=A0 =C2=A0 Such close integration of ACME with HTTPS
>>>=C2=A0 =C2=A0 servers allows the immediate and automated deploy= ment of
>>>=C2=A0 =C2=A0 certificates as they are issued, sparing the huma= n administrator from
>>>=C2=A0 =C2=A0 much of the time-consuming work described in the = previous section.
>>>
>>> IANA Section:
>>> Everything looks good except that RFC5226 has been obsoleted, = so the
>>> new reference is RFC8126 and =E2=80=9Cspecification required= =E2=80=9D
>>> https://tools.ietf.org/html/rfc8126= #section-4.6 still means the same
>>> thing, so using that is fine.
>>>
>>> Security considerations:
>>> I think it would be good to mention here that they are DV cert= s so the
>>> reader understands from he introduction and this section the l= evel of
>>> cert issued through ACME and doesn=E2=80=99t assume a higher l= evel of
>>> assurance.
>>>
>>> s/ACME is a protocol for managing certificates/ACME is a proto= col for
>>> managing DV certificates/
>>>
>>> 10.1 - I know this is obvious to the people in the WG, but a r= eference
>>> to RFC7525 to properly configure TLS 1.2 should be included to= protect
>>> against the mentioned attacks.=C2=A0 If you want to also refer= ence TLS 1.3
>>> and specify no 0-RTT that would be good too.=C2=A0 It=E2=80=99= d be great to see
>>> this get widely deployed, so there may be a number of newcomer= s
>>> reading this to make their lives easier with cert
>>> issuance/maintenance.
>>>
>>> 10.2 - what if the server that the account verifier has an acc= ount on
>>> (client for ACME) is compromised and is used to request new >>> certificates or perform other actions?=C2=A0 I think this is o= ne of the
>>> larger risks, so mentioning this is possible and hardening mea= sures
>>> should be taken to prevent compromise would be prudent.=C2=A0 = Hardening
>>> measures or appropriate security controls should be broadly un= derstood
>>> terms (I think) so that you wouldn=E2=80=99t need to list out = things like
>>> turing off unnecessary services.
>>>
>>> 10.5 - I would think you=E2=80=99d see requests for new phishi= ng domains
>>> rather than known ones through this process.=C2=A0 What would = you look for
>>> there as that=E2=80=99s a complex problem - it would be hard t= o know all legit
>>> names to know if one was a play off of the original.=C2=A0 Thi= s happened
>>> with equifax - they provided a site name with a typo and a =E2= =80=98white hat=E2=80=99
>>> attacker had set up a site that looked just like theirs at tha= t site.
>>> But it was announced by equifax.=C2=A0 Tough problem as automa= ting a check
>>> on the DNS registration may not detect something unusual, but = maybe
>>> recommending this check could help?=C2=A0 RDP lessens what nee= ds to be
>>> shared from whois though, although I don=E2=80=99t think that= =E2=80=99s widely
>>> deployed.
>>>
>>> --
>>>
>>> Best regards,
>>> Kathleen
>>>
>>> _______________________________________________
>>> Acme mailing list
>>> Acme@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ac= me
>>
>>
>> _______________________________________________
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme



--

Best regards,
Kathleen

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

--001a113ec866ed3456055aa51e0e-- From nobody Thu Oct 19 09:45:41 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 95962132D54 for ; Thu, 19 Oct 2017 09:45:39 -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 Km9CReYPzfWl for ; Thu, 19 Oct 2017 09:45:37 -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 75861132CE7 for ; Thu, 19 Oct 2017 09:45:36 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id u5so8983816wrc.5 for ; Thu, 19 Oct 2017 09:45:36 -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=ky5qHk71xu2bcydpLs8bzffzFS0x4UAhxEhFIunBxPQ=; b=ZcCJZwWQm7cN0l2GHlK0Auv1fKdMEbi6SaXRzQkGkCmkvJJc3Q7zeHfYcxezdh3S6z bBtqN/qaePksHHqkK6LNh71asNCjKgpeLbPAe8V2qKYspPIN7cLksCuCusDDDTjZjP9u VLFHMvRfEIlN1a8xfEX58poM0FmtLRadMUr7LkvZBd000POiJJWTkO5NhWB5WTFaFbUz /eCd3d+TQWPqm+1EfDZRGhZ0FQesZAejF/Q1+yBtlGKdsvAL1T3XMJWFaKQ/Xmvtd098 bBl3TQc8qQbnsOMdAG2QEH+tsInWjO1sCfT4qa+zzbZT/TfhePdEOav+ZYW//YErmjyd Z5TA== 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=ky5qHk71xu2bcydpLs8bzffzFS0x4UAhxEhFIunBxPQ=; b=jcbXbUc2zejpmfA/pQNjMzVGdCGHMmBuUBfGQGP+PNMHjipx8DG7BPC2vWV2REKjbP /2GIoSCbTApgGKLrVmgICpaK3CMxbcIUJa041g2AnN0bjeR0bueZoJ9uW3JlliyeVqz4 qo3LAV3nYHZPDKAyo0XpUAvwurW+aiZsjQClxvpqjuCF4AVRSmP4f7M6dQBXlkkpLQ5Y NdfTQdMBTtPwyqra/YFqWAU1sA69+lNK7N2OUX6TM77PZ6tDCqy5rRaNHH0Rlogv7u1Z KABBlYygE9xvvmKYFPPTveywu3WBstbD1aOkVhX7ajnnAFzfg7zTePUwwLK5rHSaqk2R 4JIQ== X-Gm-Message-State: AMCzsaU8jlIGI/U+OGL4kCRpdOJ4CtUmhSSPl7XwH+HXkz92eusqB5Sg LxlnggISxE2uH3dfjd3gak484aElB9/0ES2vVz2Fsg== X-Google-Smtp-Source: ABhQp+SI0xsMnaZ2VsJlNdn1ZQJQQv77lds6UQTEPBDHK0vq103TdFhYf3gyRawkxa9VmWR1hbTrpM3vd2lbxncPAeo= X-Received: by 10.223.136.170 with SMTP id f39mr1972617wrf.162.1508431534786; Thu, 19 Oct 2017 09:45:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.184.210 with HTTP; Thu, 19 Oct 2017 09:45:34 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Thu, 19 Oct 2017 12:45:34 -0400 Message-ID: To: Kathleen Moriarty Cc: IETF ACME Content-Type: multipart/alternative; boundary="001a11460aacccd235055be915ad" Archived-At: Subject: Re: [Acme] AD review of draft-ietf-acme-acme 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, 19 Oct 2017 16:45:39 -0000 --001a11460aacccd235055be915ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Kathleen, Thanks for the review. Some responses inline. I've started a PR to respond to these comments here: https://github.com/ietf-wg-acme/acme/pull/345 I agree with Daniel that we should hold off on IETF LC until we've addressed the issues around proactive issuance / caching of CSRs. That may require a re-WGLC, but once that's closed, it should be safe to send to IETF LC. On Fri, Sep 22, 2017 at 4:14 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hello, > > Thank you to the editors and WG for your efforts on > draft-ietf-acme-acme, it's a well written and easy to understand > draft. I do have a few comments, that need to be address by the > editors and SHEPHERD. > > Please review the idnits. There are a few warnings that should be > correctable and can be addressed, but more importantly, it calls out > several downrefs that are not in the shepherd writeup. These need to > be in the writeup and then also mentioned in the IETF last call > announcement (I'll make sure the latter happens). > > Here's my mostly editorial comments: > > Introduction: > It reads very well, but it would be helpful to those unfamiliar with > the work to explicitly state that ACME is about DV certificates. The > first sentence of the last paragraph seems like the best place to add > this in. > Current text: > This document describes an extensible framework for automating the > issuance and domain validation procedure, thereby allowing servers > and infrastructural software to obtain certificates without user > interaction. > Proposed: > This document describes an extensible framework for automating the > issuance and domain validation procedure for DV certificates, > thereby allowing servers > and infrastructural software to obtain certificates without user > interaction. > As others have pointed out, ACME is not just about DV. PR has some clarification on this point. > I do like how the introduction is framed as it=E2=80=99s clear the level = of > security provided by the certificates issued via ACME. Thanks for > that. > > The introduction should also make it clear that ACME can be used for > other services using DV certificates, not just HTTP. This is > mentioned in the Terminology section, but I think a clear sentence > upfront would be helpful. > > Section 2: Nit/suggestion: Change the tense to read as a published RFC > in the last paragraph, last sentence (take it or leave it). > Current: > Such close integration of ACME with HTTPS > servers would allow the immediate and automated deployment of > certificates as they are issued, sparing the human administrator from > much of the time-consuming work described in the previous section. > Proposed: > Such close integration of ACME with HTTPS > servers allows the immediate and automated deployment of > certificates as they are issued, sparing the human administrator from > much of the time-consuming work described in the previous section. > Done. > IANA Section: > Everything looks good except that RFC5226 has been obsoleted, so the > new reference is RFC8126 and =E2=80=9Cspecification required=E2=80=9D > https://tools.ietf.org/html/rfc8126#section-4.6 still means the same > thing, so using that is fine. > Updated reference. > Security considerations: > I think it would be good to mention here that they are DV certs so the > reader understands from he introduction and this section the level of > cert issued through ACME and doesn=E2=80=99t assume a higher level of > assurance. > > s/ACME is a protocol for managing certificates/ACME is a protocol for > managing DV certificates/ > Given the discussion about DV, I don't think this change is appropriate. > 10.1 - I know this is obvious to the people in the WG, but a reference > to RFC7525 to properly configure TLS 1.2 should be included to protect > against the mentioned attacks. If you want to also reference TLS 1.3 > and specify no 0-RTT that would be good too. It=E2=80=99d be great to se= e > this get widely deployed, so there may be a number of newcomers > reading this to make their lives easier with cert > issuance/maintenance. > I don't see how TLS configuration plays into the security considerations for ACME. How you use the certificates you get from ACME is your business, and indeed, several of the envisioned applications have nothing to do with TLS (e.g., the email and STIR use cases). That said, I have added some language to suggest that ACME servers should follow the advice in RFC 7525. 0xRTT should be safe here, because there are anti-replay protections at the application layer. > 10.2 - what if the server that the account verifier has an account on > (client for ACME) is compromised and is used to request new > certificates or perform other actions? I think this is one of the > larger risks, so mentioning this is possible and hardening measures > should be taken to prevent compromise would be prudent. Hardening > measures or appropriate security controls should be broadly understood > terms (I think) so that you wouldn=E2=80=99t need to list out things like > turing off unnecessary services. > Added a brief note. > 10.5 - I would think you=E2=80=99d see requests for new phishing domains > rather than known ones through this process. What would you look for > there as that=E2=80=99s a complex problem - it would be hard to know all = legit > names to know if one was a play off of the original. This happened > with equifax - they provided a site name with a typo and a =E2=80=98white= hat=E2=80=99 > attacker had set up a site that looked just like theirs at that site. > But it was announced by equifax. Tough problem as automating a check > on the DNS registration may not detect something unusual, but maybe > recommending this check could help? RDP lessens what needs to be > shared from whois though, although I don=E2=80=99t think that=E2=80=99s w= idely > deployed. > This is a policy question, not one for the issuance protocol. --Richard > > -- > > Best regards, > Kathleen > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a11460aacccd235055be915ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Kathleen,

Thanks for the review.= =C2=A0 Some responses inline.=C2=A0 I've started a PR to respond to the= se comments here:

https= ://github.com/ietf-wg-acme/acme/pull/345

I agree with Daniel that we should h= old off on IETF LC until we've addressed the issues around proactive is= suance / caching of CSRs.=C2=A0 That may require a re-WGLC, but once that&#= 39;s closed, it should be safe to send to IETF LC.


On Fri, Sep 22, 2017 at 4:14 PM, Kath= leen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
Hello,

Thank you to the editors and WG for your efforts on
draft-ietf-acme-acme, it's a well written and easy to understand
draft.=C2=A0 I do have a few comments, that need to be address by the
editors and SHEPHERD.

Please review the idnits.=C2=A0 There are a few warnings that should be
correctable and can be addressed, but more importantly, it calls out
several downrefs that are not in the shepherd writeup.=C2=A0 These need to<= br> be in the writeup and then also mentioned in the IETF last call
announcement (I'll make sure the latter happens).

Here's my mostly editorial comments:

Introduction:
It reads very well, but it would be helpful to those unfamiliar with
the work to explicitly state that ACME is about DV certificates.=C2=A0 The<= br> first sentence of the last paragraph seems like the best place to add
this in.
Current text:
=C2=A0 =C2=A0This document describes an extensible framework for automating= the
=C2=A0 =C2=A0issuance and domain validation procedure, thereby allowing ser= vers
=C2=A0 =C2=A0and infrastructural software to obtain certificates without us= er
=C2=A0 =C2=A0interaction.
Proposed:
=C2=A0 =C2=A0This document describes an extensible framework for automating= the
=C2=A0 =C2=A0issuance and domain validation procedure for DV certificates,<= br> thereby allowing servers
=C2=A0 =C2=A0and infrastructural software to obtain certificates without us= er
=C2=A0 =C2=A0interaction.

As others hav= e pointed out, ACME is not just about DV.=C2=A0 PR has some clarification o= n this point.

=C2=A0
I do like how the introduction is framed as it=E2=80=99s clear the level of=
security provided by the certificates issued via ACME.=C2=A0 Thanks for
that.

The introduction should also make it clear that ACME can be used for
other services using DV certificates, not just HTTP.=C2=A0 This is
mentioned in the Terminology section, but I think a clear sentence
upfront would be helpful.

Section 2: Nit/suggestion: Change the tense to read as a published RFC
in the last paragraph, last sentence (take it or leave it).
Current:
=C2=A0 =C2=A0Such close integration of ACME with HTTPS
=C2=A0 =C2=A0servers would allow the immediate and automated deployment of<= br> =C2=A0 =C2=A0certificates as they are issued, sparing the human administrat= or from
=C2=A0 =C2=A0much of the time-consuming work described in the previous sect= ion.
Proposed:
=C2=A0 =C2=A0Such close integration of ACME with HTTPS
=C2=A0 =C2=A0servers allows the immediate and automated deployment of
=C2=A0 =C2=A0certificates as they are issued, sparing the human administrat= or from
=C2=A0 =C2=A0much of the time-consuming work described in the previous sect= ion.

Done.

=C2= =A0
IANA Section:
Everything looks good except that RFC5226 has been obsoleted, so the
new reference is RFC8126 and =E2=80=9Cspecification required=E2=80=9D
https://tools.ietf.org/html/rfc8126#section-4.6<= /a> still means the same
thing, so using that is fine.


Security considerations:
I think it would be good to mention here that they are DV certs so the
reader understands from he introduction and this section the level of
cert issued through ACME and doesn=E2=80=99t assume a higher level of
assurance.

s/ACME is a protocol for managing certificates/ACME is a protocol for
managing DV certificates/


10.1 - I know this is obvious to the people in the WG, but a reference
to RFC7525 to properly configure TLS 1.2 should be included to protect
against the mentioned attacks.=C2=A0 If you want to also reference TLS 1.3<= br> and specify no 0-RTT that would be good too.=C2=A0 It=E2=80=99d be great to= see
this get widely deployed, so there may be a number of newcomers
reading this to make their lives easier with cert
issuance/maintenance.



10.2 - what if the server that the account verifier has an account on
(client for ACME) is compromised and is used to request new
certificates or perform other actions?=C2=A0 I think this is one of the
larger risks, so mentioning this is possible and hardening measures
should be taken to prevent compromise would be prudent.=C2=A0 Hardening
measures or appropriate security controls should be broadly understood
terms (I think) so that you wouldn=E2=80=99t need to list out things like turing off unnecessary services.


10.5 - I would think you=E2=80=99d see requests for new phishing domains rather than known ones through this process.=C2=A0 What would you look for<= br> there as that=E2=80=99s a complex problem - it would be hard to know all le= git
names to know if one was a play off of the original.=C2=A0 This happened with equifax - they provided a site name with a typo and a =E2=80=98white h= at=E2=80=99
attacker had set up a site that looked just like theirs at that site.
But it was announced by equifax.=C2=A0 Tough problem as automating a check<= br> on the DNS registration may not detect something unusual, but maybe
recommending this check could help?=C2=A0 RDP lessens what needs to be
shared from whois though, although I don=E2=80=99t think that=E2=80=99s wid= ely
deployed.



--001a11460aacccd235055be915ad-- From nobody Thu Oct 19 10:04: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 B3630132E24 for ; Thu, 19 Oct 2017 10:04:47 -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 mWEAsPaxBrWI for ; Thu, 19 Oct 2017 10:04:45 -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 65C3C132320 for ; Thu, 19 Oct 2017 10:04:45 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id u40so3157167wrf.10 for ; Thu, 19 Oct 2017 10:04:45 -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=p71KH/XtMIF1je5LuAxdsjM3N+EkCljJNW5Cvsqs8Rk=; b=Ck+K5B4r6GPO5mddBQ93dt5eCC5X/YkAG0LcdgxChiTkP/Q1l9sTnm5YEKk83/arOi hqV3PwyknNe84vheHIJFy3oEOF2QObjwSR3iCbrZL9Zi2JXsVjYF5/Sjpniufh88Yrdr ncRIVwwY6+Z86dLn5FioMJBNMIf6onXpTg/l/QbqUATG6+jlkZ9XVnRQQscSXN7EKBtI 25pwAk3CFk6oTInj93VpScSarqG0lZO8ReIZy2bfa33qOY4oDAEBGQBx8hoRf+u+1nPa y1SxQxWOMLEgKM9Me46BU4hOrX0S+vje8/gwkl3cSKeqClClvkIDwd361iwkkD2PgzUm U0fw== 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=p71KH/XtMIF1je5LuAxdsjM3N+EkCljJNW5Cvsqs8Rk=; b=kxCB9JCiSTyADZs9KeWUG50g2uugku5X2ZB4AjfOBKYsBtu43omK9d5nprfDIXO3zs kfakak2gyf5HZA/91gruN6TbQCimvDJqJaIVGUZ8w4FnTWxE89zwUGPpIqw1V15cfSoA VNfax4WTMgcyH4xAl2cik2MTf9YdGIcdZiS7jkMj/4r5tHHP1XPe0AmqCt4rxuBqHwxy 975yjM2xl0NMyDcKLpfXJ520qXX+yTkLpDPNGbrz4Y6C1vDcG6xjI6f8rYPcXifXyLU2 4A2su6hEVZTIvdzFKsiNSx1l6Xa6YcAK2yCWMY7FTYpI3Md1HQ2nak38xvYU0eDp2Akd Eyyg== X-Gm-Message-State: AMCzsaVlOnaCBxM0IFiDa7rOA8+IKh2wvZbsa4YjGjEUKoK5wn1bdTq7 bXNnGcQvM5l73Y9qwAAVmHUXHbK9rBm2pS0fQPErgnGLOiE= X-Google-Smtp-Source: ABhQp+Sxc0/+D6s5ltD43To98w6QbhwnxCeW21+2n8E7HmFRrIT3UO245gaj8CX+0dj1Q95LzblLU0FztFbyJkATFaE= X-Received: by 10.223.136.170 with SMTP id f39mr2013811wrf.162.1508432683718; Thu, 19 Oct 2017 10:04:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.184.210 with HTTP; Thu, 19 Oct 2017 10:04:43 -0700 (PDT) From: Richard Barnes Date: Thu, 19 Oct 2017 13:04:43 -0400 Message-ID: To: "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a11460aac47eea8055be95aa6" Archived-At: Subject: [Acme] Another round of ACME PRs 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, 19 Oct 2017 17:04:48 -0000 --001a11460aac47eea8055be95aa6 Content-Type: text/plain; charset="UTF-8" [[ An ACME editor emerges from hibernation... ]] Hey all, I've spent a few minutes today processing pull requests. I've merged several that I didn't think merited WG discussion, but I'm reflecting them here for visibility (including a couple that Jacob approved as well): TYPOS: #327 - Remove "type" field in challenge response example #334 - Fix a typo: intial -> initial #341 - Fix "mime-complaint" typo in Section 9.1 #343 - Fixed some typos MINOR FIXES: #331 - Clarification of integrity of authorizations in the threat model #339 - Provide `Location` header on key-change conflict. #344 - Leading slash for Well-Known URI I also posted a new PR just now responding to Kathleen's AD review, which should land as soon as it gets reviewed. https://github.com/ietf-wg-acme/acme/pull/345 That leaves the following non-trivial PRs for us to sort out before we hand this off to the IESG for good: #342 - Remove proactive issuance & csr-first new-order. #332 - Generalize the validation methods registry I'm working with Daniel on #342, and we should have a proposal ready for the WG shortly. I'll revive the thread on #332 momentarily. --Richard --001a11460aac47eea8055be95aa6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[[ An ACME editor emerges from hibernation... ]]

Hey all,

I've spent a few= minutes today processing pull requests.=C2=A0 I've merged several that= I didn't think merited WG discussion, but I'm reflecting them here= for visibility (including a couple that Jacob approved as well):

TYPOS:
#327 - Remove "type" field in challenge= response example
#334 - Fix a typo: intial -> initial
#341 - Fix = "mime-complaint" typo in Section 9.1
#343 - Fixed some typos
MINOR FIXES:
#331 - Clarification of integrity of authorizations i= n the threat model
#339 - Provide `Location` header on key-change confli= ct.
#344 - Leading slash for Well-Known URI

I also posted a new PR just now responding to Kathleen's AD review, wh= ich should land as soon as it gets reviewed.


That leaves the fo= llowing non-trivial PRs for us to sort out before we hand this off to the I= ESG for good:

#342 - Remove proactive issuance &am= p; csr-first new-order.
#332 - Generalize the validation methods registr= y

I'm working with Daniel on #342, and we shou= ld have a proposal ready for the WG shortly.=C2=A0 I'll revive the thre= ad on #332 momentarily.

--Richard
--001a11460aac47eea8055be95aa6-- From nobody Thu Oct 19 10:24: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 AD602134237 for ; Thu, 19 Oct 2017 10:24:14 -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=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 t6ZqtCWClrRs for ; Thu, 19 Oct 2017 10:24:13 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 92452134226 for ; Thu, 19 Oct 2017 10:24:12 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id k4so17818064wmc.1 for ; Thu, 19 Oct 2017 10:24:12 -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=BHgF4fCZugbyor4JYOGpnvCfPcm2pD0bnIP85KGC4/U=; b=qprr110Q1P1NWsyNO49ZPY9TNbpWGkP3woOwW//oD2+x3OsZPveGAEdE699j9UtQ4t zw7x8hHnVFikDWhmECoRf1kmUNIPL/wCRMioNt4x53iSdZM6QCljjhcnH01+kdH+pEgH 3ka5pM97uKsAkTS5sQXbSBeTwNUmvDjKL8HJY6806QxzYGUix2ti9Ui8SYHV5ojlmmAd mTVRPudP3HvPaS9YQhisve64bVh0/kIaeBAsqTFr0J5/R6uhw+eFVQMAQ6sRMfg1y7aD U5Mp3Mvftu27jDJhBiZoeFiJFryOL5gkcftiFMONJdMX8IcxNklGZXSaDf3MgzcH8Oh2 KKrA== 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=BHgF4fCZugbyor4JYOGpnvCfPcm2pD0bnIP85KGC4/U=; b=EH9sOtd64vWBD0s4irf1ZNsPpl+HYaipHpnDSXapUX/74dTwDz3H0eeWb2QxO5Vbdm hGNmvkE0SrS0qqbU/vVWuGDGbkCn0VwM8wu7uPeo6MZp/UBPHKPoFjhWl9S92xXl5NE0 1csRNoQWs/Fz5T1ayN9FryJmP1ojj5DPZNkysNGaffz2eP48WzBwlDTguU5/zVLTgqAl jamvurlSYuK8tq5HLktKiUCNrTGVswGbKR32w41LYKqUf8n+/zauzt61axo2ly/iNByC zl9RMcW8QhEcVed61ujqTFkzOsIYS99OzxrTb+O0CGFrZxdVY7xKIEgnvj83aD2aJ5wF Ptdg== X-Gm-Message-State: AMCzsaWNrFaMOeLWh1ZM3Y2MLkmu/61JcreAg3FaxDddTC68NtgAenO0 iR0zroIE0mGtWaPFYbuY/L5vrrVxPcBB+QmpLLKs7w== X-Google-Smtp-Source: ABhQp+RBaH4fq8GnIMT7pI/+3I8V2gZUsZz2dCYI2T+E5hh6zFc+2CeUBk9TcSLgT0+WwkCs1NGpeuBkAShw4IgAIJY= X-Received: by 10.28.37.195 with SMTP id l186mr2472126wml.144.1508433851050; Thu, 19 Oct 2017 10:24:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.184.210 with HTTP; Thu, 19 Oct 2017 10:24:10 -0700 (PDT) In-Reply-To: <20170708084427.GA18015@andover.lhh.devever.net> References: <8baacb86ea9b455291fab177ce85b5ce@usma1ex-dag1mb1.msg.corp.akamai.com> <20170706100702.GA14472@andover.lhh.devever.net> <20170707133313.GA15228@andover.lhh.devever.net> <94eda8437c13496c8a5c32a0d294bb8b@usma1ex-dag1mb1.msg.corp.akamai.com> <20170708084427.GA18015@andover.lhh.devever.net> From: Richard Barnes Date: Thu, 19 Oct 2017 13:24:10 -0400 Message-ID: To: Hugo Landau Cc: "Salz, Rich" , "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a114e3700dc070a055be99fad" 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: Thu, 19 Oct 2017 17:24:14 -0000 --001a114e3700dc070a055be99fad Content-Type: text/plain; charset="UTF-8" Picking this up after a long gap... On Sat, Jul 8, 2017 at 4:44 AM, Hugo Landau wrote: > > > https://github.com/ietf-wg-acme/acme/pull/332 > Alright, if the ACME spec wants to genericise its validation methods > registry, I'm okay with the validation-methods change as-is. > > Questions: > > 1. Should we drop "non-acme", since any non-ACME method can have its own > identifier listed? I think probably. > Yes, I agree. > 2. An ACME validation method, such as http-01, can only be used in the > context of using ACME. Conversely, should non-ACME validation methods > only be usable in non-ACME contexts? > I mean, in principle, you could use the ACME methods with something else, as long as you defined what public key / nonce to use. But it would be non-trivial. > > For example, suppose someone registered a "cabf-dv-http" validation > method generically referring to CABF-compliant HTTP-based DV. > If someone wants to use ACME, they can list http-01 specifically, > so I think ACME CAs should ignore method specifiers like this. > These method names would be applicable solely to non-ACME CAs. > > (This is sort of implied already by the subtext that an act of > validation has exactly one validation method name applicable to it, > but we could be clearer about this.) > This raises a good point with regard to the ACME PR. These labels should identify *specific* validation mechanisms, so that there's no overlap. So you wouldn't want a general label for any CABF-compliant validation technique; you would want them for specific, interoperably-specified techniques. I've added some notes to the ACME PR to try to clarify this. > With regard to ACME-CAA PR#2: Is a "vendor" validation method, rather > than a prefix, really that useful? > It seems like something we're likely to need at some point, given that there's still some diversity in validation methods. But if you're uncomfortable, I think we can drop it from the CAA PR and handle it later if it's needed. > RFC6648 deprecates prefixes like "x-", but thinks that vendor-specific > prefixes like domain names are still OK. So we could amend the ACME > specification allowing challenge method names of the form > "foo@example.com", say (this is inspired by SSH capability names). This > would have utility for vendors both in and outside of the context of > ACME-CAA. > I think you still run into the "x-" problem here. What happens when " foo@example.com" gets popular enough that "example.com" and "example.net" also start using it? --Richard > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a114e3700dc070a055be99fad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Picking this up after a long gap...

On Sat, Jul 8, 2017 at 4:44 AM, Hugo= Landau <hlandau@devever.net> wrote:
> > https://github.com/ietf-wg-acme/acme/pull/332
Alright, if the ACME spec wants to genericise its validation methods
registry, I'm okay with the validation-methods change as-is.

Questions:

1. Should we drop "non-acme", since any non-ACME method can have = its own
=C2=A0 =C2=A0identifier listed? I think probably.

=
Yes, I agree.

=C2=A0
2. An ACME validation method, such as http-01, can only be used in the
=C2=A0 =C2=A0context of using ACME. Conversely, should non-ACME validation = methods
=C2=A0 =C2=A0only be usable in non-ACME contexts?

=
I mean, in principle, you could use the ACME methods with someth= ing else, as long as you defined what public key / nonce to use.=C2=A0 But = it would be non-trivial.

=C2=A0

=C2=A0 =C2=A0For example, suppose someone registered a "cabf-dv-http&q= uot; validation
=C2=A0 =C2=A0method generically referring to CABF-compliant HTTP-based DV.<= br> =C2=A0 =C2=A0If someone wants to use ACME, they can list http-01 specifical= ly,
=C2=A0 =C2=A0so I think ACME CAs should ignore method specifiers like this.=
=C2=A0 =C2=A0These method names would be applicable solely to non-ACME CAs.=

=C2=A0 =C2=A0(This is sort of implied already by the subtext that an act of=
=C2=A0 =C2=A0validation has exactly one validation method name applicable t= o it,
=C2=A0 =C2=A0but we could be clearer about this.)

=
This raises a good point with regard to the ACME PR.=C2=A0 These= labels should identify *specific* validation mechanisms, so that there'= ;s no overlap.=C2=A0 So you wouldn't want a general label for any CABF-= compliant validation technique; you would want them for specific, interoper= ably-specified techniques.=C2=A0 I've added some notes to the ACME PR t= o try to clarify this.

=C2=A0
With regard to ACME-CAA PR#2: Is a "vendor" validation method, ra= ther
than a prefix, really that useful?

It s= eems like something we're likely to need at some point, given that ther= e's still some diversity in validation methods.=C2=A0 But if you're= uncomfortable, I think we can drop it from the CAA PR and handle it later = if it's needed.

=C2=A0
RFC6648 deprecates prefixes like "x-", but thinks that vendor-spe= cific
prefixes like domain names are still OK. So we could amend the ACME
specification allowing challenge method names of the form
"foo@example.com", say (th= is is inspired by SSH capability names). This
would have utility for vendors both in and outside of the context of
ACME-CAA.

I think you still run into th= e "x-" problem here.=C2=A0 What happens when "foo@example.com" gets popular enough that &qu= ot;example.com" and "example.net" also start using it?

--Richard


=C2= =A0

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

--001a114e3700dc070a055be99fad-- From nobody Thu Oct 19 10:59: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 F381E13430C for ; Thu, 19 Oct 2017 10:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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] 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 k7iaZEvKVkPu for ; Thu, 19 Oct 2017 10:59:24 -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 952BC1321CB for ; Thu, 19 Oct 2017 10:59:24 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id p138so11222226itp.2 for ; Thu, 19 Oct 2017 10:59: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=/YKWot2hX0/sQ8mlBN55C4UxPP9wl5syaBtyP6RYMv4=; b=eXJReU2enRi5q0TKxmr7f3tos2SBhKAm3xWX+xk+FC5wKye/H0c+tA8Dey1EQf7rVT ECCjk4YIiP2RvpVMQ+u3DV4lTDka4EBCJ+qMo8K+73jHOK4nsUIWYTv319s1noxTiI9S mbqbF/aK//SDVFtm+h1lyTTKfZcbw37YdD1aY6L8ogNeBQKzrxXE8j7v9rHePZ+sY03q 2X4kvJ8/WlKMkeV6fjLwpeb579pDDH6412lHYuKV/MgEYMyCOowKtFJZL1LRfksuvJF/ VtVMzN5lyRktA50EMH0litVORK3NMhldPv5Wfrw5mvE7OeLNuCXrguUDSNKKjfiJDhsW tqbQ== 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=/YKWot2hX0/sQ8mlBN55C4UxPP9wl5syaBtyP6RYMv4=; b=ZRQl53PfMs4wphkImxF6+4Cp4eXrt8B2Gq8cXDIrKGIhC8Aev3YRnMajvjwnjkr3nU 1TJO3YsRvvVaf70Pc9dfqHumOwDMKAijloP6COQpzvxjj2zBSGUMB6FNdkHmUr0Cb8UB S018DnmrXIsZUHR4ospdMuO5PW/hCbMTieFIBx80V2R6BKLI7XsCZ1WhTZycnm6aQMWh gT4ppZaOTZpPZvLGzezGBnRmqOcQ7WiX4WLKyp4Z42PVrMMTDQDk2oa5ufCQavnhiG86 0QIgiQWOXTEZzedY8gjxNvmWLn2sGhkY84Zs5zDAnKfmjcZVYMFnLuAiwkU++zqXp+UP dPpg== X-Gm-Message-State: AMCzsaUDOj9tI0caRxw8SMqjG/CuKtE87r771cLjOWaeYOBehpB82Uwc 6pK4a5bOMfVevYVZ36dzKQ7LRlXzVr/C2KKxCYSM7g== X-Google-Smtp-Source: ABhQp+RUXwuOPHKPoMF+TrLTnWzDbQ89DNB/ZTdLoMBfJuOSAIRTCgVdMvyBpkBraWadC6EV83FVUegJHZzfFE0SepY= X-Received: by 10.36.46.4 with SMTP id i4mr3546561ita.145.1508435963504; Thu, 19 Oct 2017 10:59:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.153.151 with HTTP; Thu, 19 Oct 2017 10:59:22 -0700 (PDT) From: Logan Widick Date: Thu, 19 Oct 2017 12:59:22 -0500 Message-ID: To: ACME WG Content-Type: multipart/alternative; boundary="001a114aa374c56e4d055bea1d5f" Archived-At: Subject: [Acme] Allowable mailto contacts 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, 19 Oct 2017 17:59:26 -0000 --001a114aa374c56e4d055bea1d5f Content-Type: text/plain; charset="UTF-8" All, What portions of the "mailto" URI scheme (RFC 6068) must an ACME server be able to accept as contacts? The examples I saw in the draft depict one-item "to" productions with no headers (e.g. "mailto:usera@example.com"), but I couldn't find further details on what is allowed and what is not. Would ACME servers need to accept multi-item "to" productions (e.g. "mailto: usera@example.com,userb@example.com")? What headers from RFC 5322 would ACME servers need to be able to accept? For example, would an ACME server need to accept the following: "mailto:usera@example.com?to=userb@example.com" "mailto:usera@example.com?cc=userb@example.com" "mailto:usera@example.com?bcc=userb@example.com" "mailto:usera@example.com?subject=Hello%20World" "mailto:usera@example.com?keywords=hello,world,acme" Sincerely, Logan Widick --001a114aa374c56e4d055bea1d5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,=C2=A0

What portions of the "m= ailto" URI scheme (RFC 6068) must an ACME server be able to accept as = contacts? The examples I saw in the draft depict one-item "to" pr= oductions with no headers (e.g. "mailto:usera@example.com"), but I couldn't find further detail= s on what is allowed and what is not.=C2=A0

Would = ACME servers need to accept multi-item "to" productions (e.g. &qu= ot;mailto:usera@example.com,userb@example.com")?=C2=A0

What headers from RFC 5322 would ACME servers need to be a= ble to accept? For example, would an ACME server need to accept the followi= ng:
"mailto:usera@example.com?subject=3DHello%20World"
"mailt= o:usera@example.com?keywords=3Dhel= lo,world,acme"

Sincerely,=C2=A0

Logan Widick
--001a114aa374c56e4d055bea1d5f-- From nobody Thu Oct 19 11:21: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 A2349132F7C for ; Thu, 19 Oct 2017 11:21: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, 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 6soQv_Mchnau for ; Thu, 19 Oct 2017 11:21: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 9ED12132F3F for ; Thu, 19 Oct 2017 11:21:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 2EE1F1D846; Thu, 19 Oct 2017 20:21:26 +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=1508437286; x=1526626647; bh=B0o8MzYiK/wZdkA8HQLAZ59OZPWqROqujAkqlKOG08U=; b= FUjxg8OVr/Pe08A9jyEgss0Ui6jA3TfbCAQezg9Bh/QyDj8qzvTThRAVww4wsFiD ERPwBFUFD6Do7+r25J1d2tvAQ7bZD1DBfRgjUCNPVrkho7AYuacP0D4FU/iDc5dx rxnye8mofO8b8XkYmndNJNCaoXm9Ne+yqoy3L5g0Bt94H7WxrlOA/1j5Mr0SobMq GFOL5zhlC47u8QM6UyvAkt3AklrW8jRYB4nh56r2AYViGfLH0coB4BDl57BbIIia tsW3nijGEH69cCMSleFA8oybwV7DNncjHfuL+b+VmvGTFx9gmV/9NdCUjmsL/3bd 68nrnGIH9bqM/cob5lw3Cw== 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 nNRz7wogRfu0; Thu, 19 Oct 2017 20:21:26 +0200 (CEST) Received: from axminster (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with SMTP id E49451D845; Thu, 19 Oct 2017 20:21:25 +0200 (CEST) Date: Thu, 19 Oct 2017 19:21:25 +0100 From: Hugo Landau To: Richard Barnes Cc: acme@ietf.org Message-ID: <20171019182125.GA3624@axminster> References: <20170706100702.GA14472@andover.lhh.devever.net> <20170707133313.GA15228@andover.lhh.devever.net> <94eda8437c13496c8a5c32a0d294bb8b@usma1ex-dag1mb1.msg.corp.akamai.com> <20170708084427.GA18015@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.9.1 (2017-09-22) 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: Thu, 19 Oct 2017 18:21:31 -0000 > > With regard to ACME-CAA PR#2: Is a "vendor" validation method, rather > > than a prefix, really that useful? > > > > It seems like something we're likely to need at some point, given that > there's still some diversity in validation methods. But if you're > uncomfortable, I think we can drop it from the CAA PR and handle it later > if it's needed. Sounds good to me. > > RFC6648 deprecates prefixes like "x-", but thinks that vendor-specific > > prefixes like domain names are still OK. So we could amend the ACME > > specification allowing challenge method names of the form > > "foo@example.com", say (this is inspired by SSH capability names). This > > would have utility for vendors both in and outside of the context of > > ACME-CAA. > > > > I think you still run into the "x-" problem here. What happens when " > foo@example.com" gets popular enough that "example.com" and "example.net" > also start using it? Then example.com is immortalised in history as a pioneer of that de facto standard - there's no issue here, is there? SSH uses foo@example.com-type identifiers for extensions, but there's no implication that only example.com will implement those extensions, on the contrary. Nor is the XML namespace "http://www.w3.org/1999/xhtml" is intended to only be used by the W3C. It would be very helpful if you could base comments on the current I-D: https://tools.ietf.org/html/draft-ietf-acme-caa-03 i.e., what diffs would you propose against this I-D? Yours, Hugo Landau From nobody Thu Oct 19 13:20: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 8A893132D4B for ; Thu, 19 Oct 2017 13:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.102 X-Spam-Level: X-Spam-Status: No, score=-5.102 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 EdsHCkdOxIIB for ; Thu, 19 Oct 2017 13:20:03 -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 BB44A1320C9 for ; Thu, 19 Oct 2017 13:20:02 -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=uKLDJOLk6V06vK/DJgFFMyFs8BUjupXWgOcHkm/b8iY=; b=PfgkzQQpZMYNyBZkekqaoJ8qUJs12F8aJbWXei4wl+7efXrxn2895N4IO7IPTsHMmYd7v72qFSsfpFQZkZhK5xxxo3/Nl3ooqLZQbW2vRf6m3loiyLrW/lRwKUqjfDfDkbAwgMVs/hiT4j0a9X1MSetpIFkR5j/5dGmPzVuWJVU=; Received: ; Thu, 19 Oct 2017 13:19:59 -0700 To: acme@ietf.org References: From: Jacob Hoffman-Andrews Message-ID: <9003208a-3a86-bb87-b36d-7b40ade93a11@eff.org> Date: Thu, 19 Oct 2017 13:20:02 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] Allowable mailto contacts 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, 19 Oct 2017 20:20:09 -0000 On 10/19/2017 10:59 AM, Logan Widick wrote: > What portions of the "mailto" URI scheme (RFC 6068) must an ACME server > be able to accept as contacts? Good question. I think we'd like to specify the narrowest subset possible, i.e. "mailto:usera@example.com". What would that look like in the language of RFC 6068? From nobody Thu Oct 19 13:53: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 7BC801320C9 for ; Thu, 19 Oct 2017 13:53:03 -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 PFHLz4ifLJXu for ; Thu, 19 Oct 2017 13:53:01 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 81F8C133011 for ; Thu, 19 Oct 2017 13:53:01 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id n137so11250257iod.6 for ; Thu, 19 Oct 2017 13:53:01 -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=asOjmE7JvD0eNpTMzp1Pv4WVku2dLdkrgmL1ZuAOO4k=; b=g6bcCX834sDPWyvbSRBvPpqLiwTxk3i7MuTYxPxR/ZyjAK2yrc73vFdQy6ZY5+LJR9 paBFMdZhJIdfCC0Bwu+DijCJNLucfEoOAvvlmDaICFreCnkt829Y6V4XkcFYQSn4bfqn PXwaJHvJ1GyK7gzbIpe/yrNqt5JuL00C8C3TRbGoyLMor5seR6M37NFL8MxvRlHpndGU lTZ1TemNoqBnHHsTvoRU6cXTyGA+UmOEsU6A72RqTMhfJGHw1ia33+zM0AbADYOPLxEz TtHg5tHp6qx+LjMDMNz5FuD3zueg6JDsvmnYmOkTmKk5XaxNUCnx3gTfTFzy1fCxeQoJ u5Rw== 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=asOjmE7JvD0eNpTMzp1Pv4WVku2dLdkrgmL1ZuAOO4k=; b=Aki901Ch0OlUMMM2vnKY6+CphZtQw7e5x7A4Q4R5ibMFRwGt0xsw4SLWCZa6meeHiR +vUF6KxiMleJEzmK0AycDO859dyd1d2fv0iRAHIHQtIhAAofh78ejiX0CFs4wyNiYZT+ MFeZzDC/3HbgdsE17qiUoD7Mv6oLofS7m9XHEZbtNxcrUaPBdLru4OW4MqlarUSf9zKx gz5v//5bcUZ9+OEgYo/eOpI3K7/JPCxTZgGFaH0AVgIPNgDoQ6GKxGr/7wQb/7v55hLQ BrfcpwYzgmaBvxiyNcIojJEv8oMlv/4w7NiVH8Cnm0WvwzA3F1A5mJX02aW18M2LfCgv pwRw== X-Gm-Message-State: AMCzsaXBff+SIGOe+G6cIubVlHIpDGCgKW9a0Mde1H/PFMcax6MZ51gN 1AreKsoUgw1eIycxCCpIo/+fVm9p6FJstdMosSI= X-Google-Smtp-Source: ABhQp+Rf6ypqQez8K+5hT/n1wJ+jrrhEjOitMkJDAS6KUQt/kKnHmlJfSc3J7nNJyGTcHbfDvuBBQM+loDrkiqdX5uQ= X-Received: by 10.107.84.3 with SMTP id i3mr3571518iob.148.1508446380571; Thu, 19 Oct 2017 13:53:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.153.151 with HTTP; Thu, 19 Oct 2017 13:52:59 -0700 (PDT) Received: by 10.2.153.151 with HTTP; Thu, 19 Oct 2017 13:52:59 -0700 (PDT) In-Reply-To: <9003208a-3a86-bb87-b36d-7b40ade93a11@eff.org> References: <9003208a-3a86-bb87-b36d-7b40ade93a11@eff.org> From: Logan Widick Date: Thu, 19 Oct 2017 15:52:59 -0500 Message-ID: To: Jacob Hoffman-Andrews Cc: ACME WG Content-Type: multipart/alternative; boundary="94eb2c1b7600ad41e8055bec8af7" Archived-At: Subject: Re: [Acme] Allowable mailto contacts 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, 19 Oct 2017 20:53:03 -0000 --94eb2c1b7600ad41e8055bec8af7 Content-Type: text/plain; charset="UTF-8" I was not involved with RFC 6068 in any way. However, from my understanding of the RFC, that subset ("mailto:usera@example.com") might (roughly) look something like: 1. No hfields (that appears to be the RFC 6068 term for the query string and its parameters) are allowed (The spec doesn't appear to have a fragment) 2. Only one e-mail address per mailto contact Or at least that is how I would understand the constraints. Sincerely, Logan Widick On Oct 19, 2017 3:20 PM, "Jacob Hoffman-Andrews" wrote: On 10/19/2017 10:59 AM, Logan Widick wrote: > What portions of the "mailto" URI scheme (RFC 6068) must an ACME server > be able to accept as contacts? Good question. I think we'd like to specify the narrowest subset possible, i.e. "mailto:usera@example.com". What would that look like in the language of RFC 6068? _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme --94eb2c1b7600ad41e8055bec8af7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was not involved with RFC 6068 in any way. However= , from my understanding of the RFC, that subset ("mailto:usera@example.com") might (roughly) look s= omething like:
1. No hfields (that appears to be the= RFC 6068 term for the query string and its parameters) are allowed (The sp= ec doesn't appear to have a fragment)
2. Only on= e e-mail address per mailto contact

Or at least that is how I would understand the constraints.=C2= =A0

Sincerely,

Logan Widick

On Oct 19, 2017 3:20 = PM, "Jacob Hoffman-Andrews" <j= sha@eff.org> wrote:
On 10/19/2017 10:59 AM, Logan Widick wrote:
> What portions of the "mailto" URI scheme (RFC 6068) must an = ACME server
> be able to accept as contacts?

Good question. I think we'd like to specify the narrowest subset<= br> possible, i.e. "mailto:usera@exam= ple.com". What would that look like in
the language of RFC 6068?

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

--94eb2c1b7600ad41e8055bec8af7-- From nobody Thu Oct 19 14:24:20 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 DC16C1342D6 for ; Thu, 19 Oct 2017 14:24:15 -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 0QBXV_d_0D3z for ; Thu, 19 Oct 2017 14:24:14 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 E06E6134315 for ; Thu, 19 Oct 2017 14:24:13 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id k62so9637632wrc.9 for ; Thu, 19 Oct 2017 14:24:13 -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=PefiPlr3cBVwg3R7y7FNTIWIGMCHY3sgHg+N54nWItc=; b=tM2q0HzZ3MS28KRHT2s6jm7VHneufTwJJhCES8VusLgAVJDA23gifNMpXoABr2UmI6 YhpbY8ce4dil51PMsv1GAU1B7os1BPlrNMs8b8LqH1epMU9OS46rWarojOZDlI0TOE0r kUfFdViLlYY9wccKJd8PNrJy59RdUsG40L+9ePEYDYCVA7nbSgtFEdewldo1C50unxf4 as//tplI0FQWVs4rfJcjEBwOJMlgtTm6yU2up67vvfgP827ppY5MSpYyRWUZvL1U5WvF Sv4M7SBP8K5NWCLyVaC0M5G+52XH+Y+PU9E1Jbv0mJuFJFSgAdu0uwh/dBQDUSoqXtLI Mz2A== 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=PefiPlr3cBVwg3R7y7FNTIWIGMCHY3sgHg+N54nWItc=; b=tAjTDZhBEWwXAdVl2Y5No039DyqO/VOv6eacCmFRSSAxDQ3H0eHtDkZw7jTmsveJn8 EJeu4TA4Jb4B/p4YN0BWQ2gVDuhjqaflhfVMdi69Vn1ErVagMmNPmsSRL5sjH2Sp43V0 BBtjRqvDPhBKf5IWO6J1kmpEitZxZBqt+qJbNQg0vF3ZPgyN4P9y1M9mewfeaZUqmHEU OVvmgHqXd3jmc6tK8SWvJFMtXXg7IxxTgkigEooe7sX2uhrUUe4IyrROTLZ/6/Ft5ZgE mxONlfnyNtGvlsNzxufZV9n9NaSh0hJSq9S8fsakTzb/iAgl8UiLJo4rfICxPiAcpEB3 vA3Q== X-Gm-Message-State: AMCzsaW7Ydg6qtb7dWdOIKNKtKQe+Dd3AMnxBTnV5DkE946/RXa5PE6c 958izrZN6NciR9tE/JjXiSRWOvXiJa4l2ZPQ79Qlapq7 X-Google-Smtp-Source: ABhQp+S58ocs43+6xu/BgZI5VGKmLC0AcCIzbOaTSXyc3LPspQN3s3v0HnqgPW/FuM/l3p1vdvAEDJAqUuawtLuoFlw= X-Received: by 10.223.169.239 with SMTP id b102mr2616324wrd.171.1508448252243; Thu, 19 Oct 2017 14:24:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.184.210 with HTTP; Thu, 19 Oct 2017 14:24:11 -0700 (PDT) In-Reply-To: <20171019182125.GA3624@axminster> References: <20170706100702.GA14472@andover.lhh.devever.net> <20170707133313.GA15228@andover.lhh.devever.net> <94eda8437c13496c8a5c32a0d294bb8b@usma1ex-dag1mb1.msg.corp.akamai.com> <20170708084427.GA18015@andover.lhh.devever.net> <20171019182125.GA3624@axminster> From: Richard Barnes Date: Thu, 19 Oct 2017 17:24:11 -0400 Message-ID: To: Hugo Landau Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a114621ee3cc91d055becfa64" 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: Thu, 19 Oct 2017 21:24:16 -0000 --001a114621ee3cc91d055becfa64 Content-Type: text/plain; charset="UTF-8" On Thu, Oct 19, 2017 at 2:21 PM, Hugo Landau wrote: > > > With regard to ACME-CAA PR#2: Is a "vendor" validation method, rather > > > than a prefix, really that useful? > > > > > > > It seems like something we're likely to need at some point, given that > > there's still some diversity in validation methods. But if you're > > uncomfortable, I think we can drop it from the CAA PR and handle it later > > if it's needed. > Sounds good to me. > > > > RFC6648 deprecates prefixes like "x-", but thinks that vendor-specific > > > prefixes like domain names are still OK. So we could amend the ACME > > > specification allowing challenge method names of the form > > > "foo@example.com", say (this is inspired by SSH capability names). > This > > > would have utility for vendors both in and outside of the context of > > > ACME-CAA. > > > > > > > I think you still run into the "x-" problem here. What happens when " > > foo@example.com" gets popular enough that "example.com" and "example.net > " > > also start using it? > Then example.com is immortalised in history as a pioneer of that de > facto standard - there's no issue here, is there? SSH uses > foo@example.com-type identifiers for extensions, but there's no > implication that only example.com will implement those extensions, on > the contrary. Nor is the XML namespace "http://www.w3.org/1999/xhtml" is > intended to only be used by the W3C. > > It would be very helpful if you could base comments on the current I-D: > https://tools.ietf.org/html/draft-ietf-acme-caa-03 > i.e., what diffs would you propose against this I-D? > Oh, sorry, I hadn't realized you had updated the draft in the meantime. I think for purposes of this discussion, what's in the draft now is fine. I'll close my PR. --Richard --001a114621ee3cc91d055becfa64 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Oct 19, 2017 at 2:21 PM, Hugo Landau <hlandau@devever.net> wrote:
>= > With regard to ACME-CAA PR#2: Is a "vendor" validation meth= od, rather
> > than a prefix, really that useful?
> >
>
> It seems like something we're likely to need at some point, given = that
> there's still some diversity in validation methods.=C2=A0 But if y= ou're
> uncomfortable, I think we can drop it from the CAA PR and handle it la= ter
> if it's needed.
Sounds good to me.

> > RFC6648 deprecates prefixes like "x-", but thinks that = vendor-specific
> > prefixes like domain names are still OK. So we could amend the AC= ME
> > specification allowing challenge method names of the form
> > "foo@example.com"= ;, say (this is inspired by SSH capability names). This
> > would have utility for vendors both in and outside of the context= of
> > ACME-CAA.
> >
>
> I think you still run into the "x-" problem here.=C2=A0 What= happens when "
> foo@example.com" gets popu= lar enough that "example.com" and "example.net"
> also start using it?
Then example.com is immortalised in history as a pioneer of that de
facto standard - there's no issue here, is there? SSH uses
foo@example.com-type identifiers for extensions, but there's no
implication that only example.com will implement those extensions, on
the contrary. Nor is the XML namespace "http://www.w3.org/1999/xhtm= l" is
intended to only be used by the W3C.

It would be very helpful if you could base comments on the current I-D:
=C2=A0 https://tools.ietf.org/html/draft-ie= tf-acme-caa-03
i.e., what diffs would you propose against this I-D?
<= br>
Oh, sorry, I hadn't realized you had updated the draft in= the meantime.=C2=A0 I think for purposes of this discussion, what's in= the draft now is fine.=C2=A0 I'll close my PR.

--Richard
=C2=A0

--001a114621ee3cc91d055becfa64-- From nobody Thu Oct 19 14:30: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 A8BCB132A1A for ; Thu, 19 Oct 2017 14:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Hqix7dkfHefB for ; Thu, 19 Oct 2017 14:30:35 -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 92A3F132CE7 for ; Thu, 19 Oct 2017 14:30:35 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id g90so9648923wrd.6 for ; Thu, 19 Oct 2017 14:30:35 -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=phXM+1SLPnjUGtRs19plSdkmSRDGr8fatEeuE2p1vzs=; b=Zroen3zFKanYJB1baoi6P8JKPjtAbsOw0W7tLPi3Z3P7I9Hgq/xhrg7w9ydpvriucX /IYWY8w9ePWuCbhJHnCqZwq73Q8cvWI/+qQgI35KnO84n1OKJVU72i+bYpiV39oN6fFe de/r4kuSGVFOm8611CjXfOpIrx7JDiVT8Xry0cH5eA7K2ewHYt+uy/341v4r6Xpzf1+J 66th67Xr3lGoc3/PbvZSaj15weOmhp7IjkoA/T00L2YGdL1apS9W/HAIPirASOZjgFUf 1cz+I7Xm/GYpC7WhK1rtLmdmHmbPPR0GcrRGWgImYF6J9e0gTjwecoiLzoXRtIr9+5mk LMdA== 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=phXM+1SLPnjUGtRs19plSdkmSRDGr8fatEeuE2p1vzs=; b=X32PyMXlZcFThCG3bhbQnUfKB6/PrILUtG3O9M4dJgefuOJcCSjXi+ewtw8jSWFLtR QQtuCBCHAx+PbI/wfhlssd1fpnOsjW39sbDDbX5sjYmKXZxXnNr9eXUy2AM2k8o5++Te eWkDPdzkj+GJT57S7Zt643NY64QDevYrnmYHVoSTPIOJeIpheL6c3NAoOEMeXegjRDTY Rxsrzms5M/KrBRuQBfzAgtTIgyVtmq5UOz8osl7zZTnM+tXgiHObZnXCslZPls30qvQ2 bQ8MDSBCETCH2NL2pgqxF7qW06MghCZRvSFTVdY7e8aBG5J7QB86bJ5l+3g9ZD4WmuR0 gpSg== X-Gm-Message-State: AMCzsaVlZinv+pe8zVdQ5Xee3wtmqlrmK8S5klyEC1it6ROm0krGBEpc xl/BKTbiRnYzk2Phc2ECwa3hClfRBQ3bw6aQi2QLueGRaMQ= X-Google-Smtp-Source: ABhQp+Qzz7xR6AKsu+Wua5TZqP9fMT4NNlUdKCHypFnew7F3plCT6YxZMRzzFjU6Qzj7883uXLmBcRNW9odc9NJcvLI= X-Received: by 10.223.134.68 with SMTP id 4mr2910381wrw.67.1508448634000; Thu, 19 Oct 2017 14:30:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.184.210 with HTTP; Thu, 19 Oct 2017 14:30:33 -0700 (PDT) In-Reply-To: References: <9003208a-3a86-bb87-b36d-7b40ade93a11@eff.org> From: Richard Barnes Date: Thu, 19 Oct 2017 17:30:33 -0400 Message-ID: To: Logan Widick Cc: Jacob Hoffman-Andrews , ACME WG Content-Type: multipart/alternative; boundary="001a1149243afe0500055bed104d" Archived-At: Subject: Re: [Acme] Allowable mailto contacts 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, 19 Oct 2017 21:30:37 -0000 --001a1149243afe0500055bed104d Content-Type: text/plain; charset="UTF-8" Good catch, Logan. Suggested fix: https://github.com/ietf-wg-acme/acme/pull/346 On Thu, Oct 19, 2017 at 4:52 PM, Logan Widick wrote: > I was not involved with RFC 6068 in any way. However, from my > understanding of the RFC, that subset ("mailto:usera@example.com") might > (roughly) look something like: > 1. No hfields (that appears to be the RFC 6068 term for the query string > and its parameters) are allowed (The spec doesn't appear to have a fragment) > 2. Only one e-mail address per mailto contact > > Or at least that is how I would understand the constraints. > > Sincerely, > > Logan Widick > > > On Oct 19, 2017 3:20 PM, "Jacob Hoffman-Andrews" wrote: > > On 10/19/2017 10:59 AM, Logan Widick wrote: > > What portions of the "mailto" URI scheme (RFC 6068) must an ACME server > > be able to accept as contacts? > > Good question. I think we'd like to specify the narrowest subset > possible, i.e. "mailto:usera@example.com". What would that look like in > the language of RFC 6068? > > _______________________________________________ > 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 > > --001a1149243afe0500055bed104d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good catch, Logan.=C2=A0 Suggested fix:

On Thu, Oct 19, 2017 at 4:52 PM,= Logan Widick <logan.widick@gmail.com> wrote:
I was not involved with RFC= 6068 in any way. However, from my understanding of the RFC, that subset (&= quot;mailto:usera@ex= ample.com") might (roughly) look something like:
1. No hfields (that appears to be the RFC 6068 term for the query str= ing and its parameters) are allowed (The spec doesn't appear to have a = fragment)
2. Only one e-mail address per mailto cont= act

Or at least that is = how I would understand the constraints.=C2=A0

Sincerely,

Logan Widick


On Oct 19, 2017 3:20 PM, "= ;Jacob Hoffman-Andrews" <jsha@eff.org> wrote:
On 10/19/2017 10:59 AM, Logan Widick wrote:
> What portions of the "mailto" URI scheme (RFC 6068) must an = ACME server
> be able to accept as contacts?

Good question. I think we'd like to specify the narrowest subset<= br> possible, i.e. "mailto:usera@example.com". What would that look like in
the language of RFC 6068?

_______________________________________________
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


--001a1149243afe0500055bed104d-- From nobody Fri Oct 20 04:01: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 2A70D133064 for ; Fri, 20 Oct 2017 04:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 (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 Pvz72iGRLvT2 for ; Fri, 20 Oct 2017 04:01:31 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 59BC313306B for ; Fri, 20 Oct 2017 04:01:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1508497290; d=isode.com; s=june2016; i=@isode.com; bh=E0n5pb4L/TRkPDkrm1mrkVNCpaxpK5dSebNk5tPaO1k=; 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=bgkrvlQ/565r1unjCubrNxww4aY8hbsB9bm+UgzcJ3BQJ2d3YpuSoarq3zU69d71oKdjcQ N+dg+810LmmyoEkGjcrGm/RK3b63vYILAA69uah9pDjFXfGFbMtAnQFXghQDwlU8ZJmEqT xYqetJYJ6fS/gWEo9iChImNX8PtnFb4=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 20 Oct 2017 12:01:30 +0100 To: Logan Widick , Jacob Hoffman-Andrews Cc: ACME WG References: <9003208a-3a86-bb87-b36d-7b40ade93a11@eff.org> From: Alexey Melnikov Message-ID: <6d2de098-29f5-54ac-d103-5770f897ab65@isode.com> Date: Fri, 20 Oct 2017 12:01:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------5A6EE0F56B64C16AD035B72C" Content-Language: en-US Archived-At: Subject: Re: [Acme] Allowable mailto contacts 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, 20 Oct 2017 11:01:37 -0000 --------------5A6EE0F56B64C16AD035B72C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, On 19/10/2017 21:52, Logan Widick wrote: > I was not involved with RFC 6068 in any way. However, from my > understanding of the RFC, that subset ("mailto:usera@example.com > ") might (roughly) look something like: > 1. No hfields (that appears to be the RFC 6068 term for the query > string and its parameters) are allowed (The spec doesn't appear to > have a fragment) > 2. Only one e-mail address per mailto contact I think these 2 restrictions are very sensible. Best Regards, Alexey > Or at least that is how I would understand the constraints. > > Sincerely, > > Logan Widick > > On Oct 19, 2017 3:20 PM, "Jacob Hoffman-Andrews" > wrote: > > On 10/19/2017 10:59 AM, Logan Widick wrote: > > What portions of the "mailto" URI scheme (RFC 6068) must an ACME > server > > be able to accept as contacts? > > Good question. I think we'd like to specify the narrowest subset > possible, i.e. "mailto:usera@example.com > ". What would that look like in > the language of RFC 6068? > --------------5A6EE0F56B64C16AD035B72C Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi,

On 19/10/2017 21:52, Logan Widick wrote:
I was not involved with RFC 6068 in any way. However, from my understanding of the RFC, that subset ("mailto:usera= @example.com") might (roughly) look something like:
1. No hfields (that appears to be the RFC 6068 term for the query string and its parameters) are allowed (The spec doesn't appear to have a fragment)
2. Only one e-mail address per mailto contact
I think these 2 restrictions are very sensible.

Best Regards,
Alexey
Or at least that is how I would understand the constraints.=C2=A0

Sincerely,

Logan Widick

On Oct 19, 2017 3:20 PM, "Jacob Hoffman-Andrews" <jsha@eff.org> wrote:
On 10/19/2017 10:59 AM, Logan Widick wrote:
> What portions of the "mailto" URI scheme (RFC 6068) must an ACME server
> be able to accept as contacts?

Good question. I think we'd like to specify the narrowest subset
possible, i.e. "mailto:usera@example.com". What would that look like in
the language of RFC 6068?

--------------5A6EE0F56B64C16AD035B72C-- From nobody Fri Oct 20 13:36: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 EE7F0132F2E for ; Fri, 20 Oct 2017 13:36:14 -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 IaLLes7wvwfW for ; Fri, 20 Oct 2017 13:36:12 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 791B0126BF3 for ; Fri, 20 Oct 2017 13:36:12 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id e89so14489267ioi.11 for ; Fri, 20 Oct 2017 13:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:reply-to:from:date:message-id:subject:to; bh=fTObuuNsNZ9arzVg5DtIRpm/5alhqa2L1tzEussByH8=; b=T+ZrejsxKZKAxDAhiLKZg+9SvNV9RL1MQ1SJfzAffPgbGZsVPrUVr0Hw5PzgI+tYzM 31aOGyErDIm8F0u0xF/wolkP/OGCbOVC0SwXOgjOkQtfF6jqQSCOBfq0PhTXLFN5lnTe lWQLUIdQ3QpkPihspRR9m3sfje3HfspbHOBxs= 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:from:date:message-id :subject:to; bh=fTObuuNsNZ9arzVg5DtIRpm/5alhqa2L1tzEussByH8=; b=mWEvVsOb6Fm2SATXJdaIwiNpbosIM5JxZCcaTH3Bum8AdR/cXQ6+m9mAzte/FiW1SH SaSpMU1yaAbSRubhLJM7tVDQleb6pIeGKyGMoIOixJo/XvA4c9Vokwwd/+xU+oNIz7Jr TR+68IaEI5vmn1f+gyf9WLw9c4adf58ustAlL/akXsjuPnFyw3pgU5pzhGVy7Wd5eDwB O86FeEUKK5+hK40dx3x7P/9jNb8rZld9klaI0vw78nQGlfszTYP4hkEidetfeghhDqRv 4zshVPFzKz7z2iBeloJ6LYVDN6WFLR81jEQ+QAVTJY+zjus+IdQGRI6AyP6M1QS9S6fS fgog== X-Gm-Message-State: AMCzsaXvXf3kVLSW4LLsP7u9Gkj4mR7vPwWhk3Ti1cYKZ36txdU8LNYF CgTHuu83PW1rT4OinvntssuEknwCm0E4J5tEg34URg82u+A= X-Google-Smtp-Source: ABhQp+SD/PE6R8KNYc1Ti96Mh1fm1w6oAeLwStt5CoPe67X9WAVHmYloQ5RPUkIEtazoIkWDwPIPVu/XN9WkJHJEuaE= X-Received: by 10.107.37.143 with SMTP id l137mr7919156iol.104.1508531771315; Fri, 20 Oct 2017 13:36:11 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.88.21 with HTTP; Fri, 20 Oct 2017 13:36:10 -0700 (PDT) From: Daniel McCarney Date: Fri, 20 Oct 2017 16:36:10 -0400 Message-ID: To: IETF ACME Content-Type: multipart/alternative; boundary="001a11402b185cb4d9055c006c29" Archived-At: Subject: [Acme] Survey of draft-07 implementations 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, 20 Oct 2017 20:36:15 -0000 --001a11402b185cb4d9055c006c29 Content-Type: text/plain; charset="UTF-8" Hi folks, As the WG approaches last-call on ACME draft-07[0] I wanted to get a sense of which portions of the spec have been implemented and which haven't. In particular I'd like to hear if anyone has implemented: * External Account Binding (Section 7.3.5) * Pre-Authorization for Order based issuance (Section 7.4.1) * The Out-of-Band Challenge type (Section 8.6) Let's Encrypt has made good progress on draft-07 server implementation but has no plans to implement the above three features. It would be nice to hear someone has running code for these protions of spec. Ignoring the above three items Let's Encrypt has implemented the core portions of draft-07 in Pebble[1]. It's presently using the pro-active issuance method described in draft-07. It does not support key change or revocation but is ready to be used by clients. There is an integration test client[2] based on Certbot's ACME python module and ACME4j has an experimental branch[3] capable of issuing certificates from Pebble. Let's Encrypt has also made significant progress implementing draft-07 in Boulder[4], the production Let's Encrypt CA software, but it is not yet ready for use by clients. This implementation does include key change and revocation but does **not** use pro-active issuance. I began a separate thread[5] for the order finalization approach that we have started to implement for Boulder. Pebble will be updated to use this issuance approach in place of pro-active issuance shortly. Are there any other servers or clients out there that are speaking draft-07 ACME and using order based issuance? - Daniel / cpu [0]: https://tools.ietf.org/html/draft-ietf-acme-acme-07 [1]: https://github.com/letsencrypt/pebble [2]: https://github.com/letsencrypt/boulder/blob/e2cc6fbe682dd5d49da32c2357838b0cc831f10f/test/chisel2.py [3]: https://github.com/shred/acme4j/tree/draft [4]: https://github.com/letsencrypt/boulder [5]: https://mailarchive.ietf.org/arch/msg/acme/DIjJEB06J5cFyuOlGPVcY2I51vg --001a11402b185cb4d9055c006c29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

As the WG approach= es last-call on ACME draft-07[0] I wanted to get a sense of which portions = of the spec have been implemented and which haven't.

In particular I'd like to hear if anyone has implemented:
<= div>* External Account Binding (Section 7.3.5)
* Pre-Authorizatio= n for Order based issuance (Section 7.4.1)
* The Out-of-Band Chal= lenge type (Section 8.6)

Let's Encrypt has mad= e good progress on draft-07 server implementation but has no plans to imple= ment the above three features. It would be nice to hear someone has running= code for these protions of spec.

Ignoring the abo= ve three items Let's Encrypt has implemented the core portions of draft= -07 in Pebble[1]. It's presently using the pro-active issuance method d= escribed in draft-07. It does not support key change or revocation but is r= eady to be used by clients. There is an integration test client[2] based on= Certbot's ACME python module and ACME4j has an experimental branch[3] = capable of issuing certificates from Pebble.

Let&#= 39;s Encrypt has also made significant progress implementing draft-07 in Bo= ulder[4], the production Let's Encrypt CA software, but it is not yet r= eady for use by clients. This implementation does include key change and re= vocation but does **not** use pro-active issuance. I began a separate threa= d[5] for the order finalization approach that we have started to implement = for Boulder. Pebble will be updated to use this issuance approach in place = of pro-active issuance shortly.

Are there any othe= r servers or clients out there that are speaking draft-07 ACME and using or= der based issuance?

- Daniel / cpu
--001a11402b185cb4d9055c006c29-- From nobody Fri Oct 20 17:32:49 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 CC0211345BE; Fri, 20 Oct 2017 17:24:33 -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.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150854547383.20809.5570109540407602650.idtracker@ietfa.amsl.com> Date: Fri, 20 Oct 2017 17:24:33 -0700 Archived-At: Subject: [Acme] acme - Requested session has been scheduled for IETF 100 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, 21 Oct 2017 00:24:34 -0000 Dear Yoav Nir, 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) Thursday, Afternoon Session II 1550-1750 Room Name: Sophia size: 200 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Automated Certificate Management Environment Area Name: Security Area Session Requester: Yoav Nir Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 70 Conflicts to Avoid: First Priority: tls curdle cfrg ipsecme i2nsf People who must be present: Rich Salz Kathleen Moriarty Yoav Nir Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Oct 20 23:56: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 8EC951329B5 for ; Fri, 20 Oct 2017 23:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MT8uc2f3on5a for ; Fri, 20 Oct 2017 23:56:25 -0700 (PDT) Received: from mr10.infostorm.no (mr10.infostorm.no [217.18.206.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC7C913213D for ; Fri, 20 Oct 2017 23:56:23 -0700 (PDT) Received: from Buyp-gvk-ex01.intra.buypass.no (unknown [146.192.247.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mr10.infostorm.no (Postfix) with ESMTP id C39361375F8; Sat, 21 Oct 2017 08:56:20 +0200 (CEST) Received: from BUYP-GVK-EX01.intra.buypass.no (10.11.2.9) by Buyp-gvk-ex01.intra.buypass.no (10.11.2.9) with Microsoft SMTP Server (TLS) id 15.0.995.29; Sat, 21 Oct 2017 08:56:20 +0200 Received: from BUYP-GVK-EX01.intra.buypass.no ([10.11.2.241]) by Buyp-gvk-ex01.intra.buypass.no ([10.11.2.241]) with mapi id 15.00.0995.032; Sat, 21 Oct 2017 08:56:20 +0200 From: Mads Egil Henriksveen To: "cpu@letsencrypt.org" , IETF ACME Thread-Topic: [Acme] Survey of draft-07 implementations Thread-Index: AQHTSeMY8JEM4uMmCU+DxV9S1jVWXaLtzDXw Date: Sat, 21 Oct 2017 06:56:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.11.51.27] Content-Type: multipart/alternative; boundary="_000_e81bedc777c340f58c1f43205129a6f2Buypgvkex01intrabuypass_" MIME-Version: 1.0 X-mr10-MailScanner-Information: Please contact the ISP for more information X-mr10-MailScanner-ID: C39361375F8.AEA10 X-mr10-MailScanner: Found to be clean X-mr10-MailScanner-From: mads.henriksveen@buypass.no Archived-At: Subject: Re: [Acme] Survey of draft-07 implementations 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, 21 Oct 2017 06:56:28 -0000 --_000_e81bedc777c340f58c1f43205129a6f2Buypgvkex01intrabuypass_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCg0KQnV5cGFzcyBoYXMgaW1wbGVtZW50ZWQgYW4gQUNNRSBzZXJ2ZXIgYmFzZWQgb24gQUNN RSBkcmFmdC0wNyB3aGljaCB1c2Ugb3JkZXIgYmFzZWQgaXNzdWFuY2UsIHRoaXMgdmVyc2lvbiBp cyBjdXJyZW50bHkgYXZhaWxhYmxlIGluIGEgdGVzdCBlbnZpcm9ubWVudCBvbmx5LiBXZSBhcmUg YWxzbyBydW5uaW5nIGEgY29uc3RyYWluZWQgcGlsb3QgaW4gb3VyIHByb2R1Y3Rpb24gZW52aXJv bm1lbnQgKHN1cHBvcnRpbmcgQ2VydEJvdCkgYW5kIHRoaXMgd2lsbCBiZSB1cGdyYWRlZCB0byB0 aGUgQUNNRSBkcmFmdC0wNyB2ZXJzaW9uIHNob3J0bHkuDQoNCldlIGhhdmUgaW5jbHVkZWQgc3Vw cG9ydCBmb3IgUHJlLUF1dGhvcml6YXRpb24sIGJ1dCB3ZSBhcmUgbm90IHVzaW5nIG5laXRoZXIg RXh0ZXJuYWwgQWNjb3VudCBCaW5kaW5nIG5vciB0aGUgT3V0LW9mLUJhbmQgQ2hhbGxlbmdlIGlu IG91ciBjdXJyZW50IHZlcnNpb24uIEhvd2V2ZXIsIHdlIGFyZSBjb25zaWRlcmluZyB0byB1c2Ug dGhlIE91dC1vZi1CYW5kIENoYWxsZW5nZSB0eXBlIGFuZCBwb3NzaWJseSBhbHNvIEV4dGVybmFs IEFjY291bnQgQmluZGluZyBpbiBhIG5leHQgcGhhc2Ugd2hlcmUgdGhlIGlkZWEgaXMgdG8gZXhw bG9pdCBob3cgdGhlIEFDTUUgcHJvdG9jb2wgbWF5IGJlIHVzZWQgdG8gc3VwcG9ydCBpc3N1YW5j ZSBhbmQgYWRtaW5pc3RyYXRpb24gb2Ygb3RoZXIgdHlwZXMgb2YgVExTIGNlcnRpZmljYXRlcyB0 aGFuIERWLg0KDQpSZWdhcmRzDQpNYWRzDQoNCkZyb206IEFjbWUgW21haWx0bzphY21lLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYW5pZWwgTWNDYXJuZXkNClNlbnQ6IGZyZWRhZyAy MC4gb2t0b2JlciAyMDE3IDIyOjM2DQpUbzogSUVURiBBQ01FIDxhY21lQGlldGYub3JnPg0KU3Vi amVjdDogW0FjbWVdIFN1cnZleSBvZiBkcmFmdC0wNyBpbXBsZW1lbnRhdGlvbnMNCg0KSGkgZm9s a3MsDQoNCkFzIHRoZSBXRyBhcHByb2FjaGVzIGxhc3QtY2FsbCBvbiBBQ01FIGRyYWZ0LTA3WzBd IEkgd2FudGVkIHRvIGdldCBhIHNlbnNlIG9mIHdoaWNoIHBvcnRpb25zIG9mIHRoZSBzcGVjIGhh dmUgYmVlbiBpbXBsZW1lbnRlZCBhbmQgd2hpY2ggaGF2ZW4ndC4NCg0KSW4gcGFydGljdWxhciBJ J2QgbGlrZSB0byBoZWFyIGlmIGFueW9uZSBoYXMgaW1wbGVtZW50ZWQ6DQoqIEV4dGVybmFsIEFj Y291bnQgQmluZGluZyAoU2VjdGlvbiA3LjMuNSkNCiogUHJlLUF1dGhvcml6YXRpb24gZm9yIE9y ZGVyIGJhc2VkIGlzc3VhbmNlIChTZWN0aW9uIDcuNC4xKQ0KKiBUaGUgT3V0LW9mLUJhbmQgQ2hh bGxlbmdlIHR5cGUgKFNlY3Rpb24gOC42KQ0KDQpMZXQncyBFbmNyeXB0IGhhcyBtYWRlIGdvb2Qg cHJvZ3Jlc3Mgb24gZHJhZnQtMDcgc2VydmVyIGltcGxlbWVudGF0aW9uIGJ1dCBoYXMgbm8gcGxh bnMgdG8gaW1wbGVtZW50IHRoZSBhYm92ZSB0aHJlZSBmZWF0dXJlcy4gSXQgd291bGQgYmUgbmlj ZSB0byBoZWFyIHNvbWVvbmUgaGFzIHJ1bm5pbmcgY29kZSBmb3IgdGhlc2UgcHJvdGlvbnMgb2Yg c3BlYy4NCg0KSWdub3JpbmcgdGhlIGFib3ZlIHRocmVlIGl0ZW1zIExldCdzIEVuY3J5cHQgaGFz IGltcGxlbWVudGVkIHRoZSBjb3JlIHBvcnRpb25zIG9mIGRyYWZ0LTA3IGluIFBlYmJsZVsxXS4g SXQncyBwcmVzZW50bHkgdXNpbmcgdGhlIHByby1hY3RpdmUgaXNzdWFuY2UgbWV0aG9kIGRlc2Ny aWJlZCBpbiBkcmFmdC0wNy4gSXQgZG9lcyBub3Qgc3VwcG9ydCBrZXkgY2hhbmdlIG9yIHJldm9j YXRpb24gYnV0IGlzIHJlYWR5IHRvIGJlIHVzZWQgYnkgY2xpZW50cy4gVGhlcmUgaXMgYW4gaW50 ZWdyYXRpb24gdGVzdCBjbGllbnRbMl0gYmFzZWQgb24gQ2VydGJvdCdzIEFDTUUgcHl0aG9uIG1v ZHVsZSBhbmQgQUNNRTRqIGhhcyBhbiBleHBlcmltZW50YWwgYnJhbmNoWzNdIGNhcGFibGUgb2Yg aXNzdWluZyBjZXJ0aWZpY2F0ZXMgZnJvbSBQZWJibGUuDQoNCkxldCdzIEVuY3J5cHQgaGFzIGFs c28gbWFkZSBzaWduaWZpY2FudCBwcm9ncmVzcyBpbXBsZW1lbnRpbmcgZHJhZnQtMDcgaW4gQm91 bGRlcls0XSwgdGhlIHByb2R1Y3Rpb24gTGV0J3MgRW5jcnlwdCBDQSBzb2Z0d2FyZSwgYnV0IGl0 IGlzIG5vdCB5ZXQgcmVhZHkgZm9yIHVzZSBieSBjbGllbnRzLiBUaGlzIGltcGxlbWVudGF0aW9u IGRvZXMgaW5jbHVkZSBrZXkgY2hhbmdlIGFuZCByZXZvY2F0aW9uIGJ1dCBkb2VzICoqbm90Kiog dXNlIHByby1hY3RpdmUgaXNzdWFuY2UuIEkgYmVnYW4gYSBzZXBhcmF0ZSB0aHJlYWRbNV0gZm9y IHRoZSBvcmRlciBmaW5hbGl6YXRpb24gYXBwcm9hY2ggdGhhdCB3ZSBoYXZlIHN0YXJ0ZWQgdG8g aW1wbGVtZW50IGZvciBCb3VsZGVyLiBQZWJibGUgd2lsbCBiZSB1cGRhdGVkIHRvIHVzZSB0aGlz IGlzc3VhbmNlIGFwcHJvYWNoIGluIHBsYWNlIG9mIHByby1hY3RpdmUgaXNzdWFuY2Ugc2hvcnRs eS4NCg0KQXJlIHRoZXJlIGFueSBvdGhlciBzZXJ2ZXJzIG9yIGNsaWVudHMgb3V0IHRoZXJlIHRo YXQgYXJlIHNwZWFraW5nIGRyYWZ0LTA3IEFDTUUgYW5kIHVzaW5nIG9yZGVyIGJhc2VkIGlzc3Vh bmNlPw0KDQotIERhbmllbCAvIGNwdQ0KDQpbMF06IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWFjbWUtYWNtZS0wNw0KWzFdOiBodHRwczovL2dpdGh1Yi5jb20vbGV0c2Vu Y3J5cHQvcGViYmxlDQpbMl06IGh0dHBzOi8vZ2l0aHViLmNvbS9sZXRzZW5jcnlwdC9ib3VsZGVy L2Jsb2IvZTJjYzZmYmU2ODJkZDVkNDlkYTMyYzIzNTc4MzhiMGNjODMxZjEwZi90ZXN0L2NoaXNl bDIucHkNClszXTogaHR0cHM6Ly9naXRodWIuY29tL3NocmVkL2FjbWU0ai90cmVlL2RyYWZ0DQpb NF06IGh0dHBzOi8vZ2l0aHViLmNvbS9sZXRzZW5jcnlwdC9ib3VsZGVyDQpbNV06IGh0dHBzOi8v bWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvYWNtZS9ESWpKRUIwNko1Y0Z5dU9sR1BWY1ky STUxdmcNCg== --_000_e81bedc777c340f58c1f43205129a6f2Buypgvkex01intrabuypass_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44 NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iTk8tQk9LIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkJ1eXBhc3MgaGFz IGltcGxlbWVudGVkIGFuIEFDTUUgc2VydmVyIGJhc2VkIG9uIEFDTUUgZHJhZnQtMDcgd2hpY2gg dXNlIG9yZGVyIGJhc2VkIGlzc3VhbmNlLCB0aGlzIHZlcnNpb24gaXMgY3VycmVudGx5DQogYXZh aWxhYmxlIGluIGEgdGVzdCBlbnZpcm9ubWVudCBvbmx5LiBXZSBhcmUgYWxzbyBydW5uaW5nIGEg Y29uc3RyYWluZWQgcGlsb3QgaW4gb3VyIHByb2R1Y3Rpb24gZW52aXJvbm1lbnQgKHN1cHBvcnRp bmcgQ2VydEJvdCkgYW5kIHRoaXMgd2lsbCBiZSB1cGdyYWRlZCB0byB0aGUgQUNNRSBkcmFmdC0w NyB2ZXJzaW9uIHNob3J0bHkuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+V2UgaGF2ZSBpbmNsdWRlZCBzdXBwb3J0IGZv ciBQcmUtQXV0aG9yaXphdGlvbiwgYnV0IHdlIGFyZSBub3QgdXNpbmcgbmVpdGhlciBFeHRlcm5h bCBBY2NvdW50IEJpbmRpbmcgbm9yIHRoZSBPdXQtb2YtQmFuZA0KIENoYWxsZW5nZSBpbiBvdXIg Y3VycmVudCB2ZXJzaW9uLiBIb3dldmVyLCB3ZSBhcmUgY29uc2lkZXJpbmcgdG8gdXNlIHRoZSBP dXQtb2YtQmFuZCBDaGFsbGVuZ2UgdHlwZSBhbmQgcG9zc2libHkgYWxzbyBFeHRlcm5hbCBBY2Nv dW50IEJpbmRpbmcgaW4gYSBuZXh0IHBoYXNlIHdoZXJlIHRoZSBpZGVhIGlzIHRvIGV4cGxvaXQg aG93IHRoZSBBQ01FIHByb3RvY29sIG1heSBiZSB1c2VkIHRvIHN1cHBvcnQgaXNzdWFuY2UgYW5k IGFkbWluaXN0cmF0aW9uDQogb2Ygb3RoZXIgdHlwZXMgb2YgVExTIGNlcnRpZmljYXRlcyB0aGFu IERWLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+TWFkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBY21lIFttYWls dG86YWNtZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5EYW5pZWwgTWND YXJuZXk8YnI+DQo8Yj5TZW50OjwvYj4gZnJlZGFnIDIwLiBva3RvYmVyIDIwMTcgMjI6MzY8YnI+ DQo8Yj5Ubzo8L2I+IElFVEYgQUNNRSAmbHQ7YWNtZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gW0FjbWVdIFN1cnZleSBvZiBkcmFmdC0wNyBpbXBsZW1lbnRhdGlvbnM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSBmb2xrcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QXMgdGhlIFdHIGFwcHJvYWNoZXMgbGFzdC1jYWxsIG9uIEFDTUUgZHJh ZnQtMDdbMF0gSSB3YW50ZWQgdG8gZ2V0IGEgc2Vuc2Ugb2Ygd2hpY2ggcG9ydGlvbnMgb2YgdGhl IHNwZWMgaGF2ZSBiZWVuIGltcGxlbWVudGVkIGFuZCB3aGljaCBoYXZlbid0LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBwYXJ0aWN1bGFy IEknZCBsaWtlIHRvIGhlYXIgaWYgYW55b25lIGhhcyBpbXBsZW1lbnRlZDo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogRXh0ZXJuYWwgQWNjb3Vu dCBCaW5kaW5nIChTZWN0aW9uIDcuMy41KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+KiBQcmUtQXV0aG9yaXphdGlvbiBmb3IgT3JkZXIgYmFzZWQg aXNzdWFuY2UgKFNlY3Rpb24gNy40LjEpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4qIFRoZSBPdXQtb2YtQmFuZCBDaGFsbGVuZ2UgdHlwZSAoU2Vj dGlvbiA4LjYpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkxldCdzIEVuY3J5cHQgaGFzIG1hZGUgZ29vZCBwcm9ncmVzcyBvbiBkcmFmdC0wNyBz ZXJ2ZXIgaW1wbGVtZW50YXRpb24gYnV0IGhhcyBubyBwbGFucyB0byBpbXBsZW1lbnQgdGhlIGFi b3ZlIHRocmVlIGZlYXR1cmVzLiBJdCB3b3VsZCBiZSBuaWNlIHRvIGhlYXIgc29tZW9uZSBoYXMg cnVubmluZyBjb2RlIGZvciB0aGVzZSBwcm90aW9ucyBvZiBzcGVjLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZ25vcmluZyB0aGUgYWJvdmUg dGhyZWUgaXRlbXMgTGV0J3MgRW5jcnlwdCBoYXMgaW1wbGVtZW50ZWQgdGhlIGNvcmUgcG9ydGlv bnMgb2YgZHJhZnQtMDcgaW4gUGViYmxlWzFdLiBJdCdzIHByZXNlbnRseSB1c2luZyB0aGUgcHJv LWFjdGl2ZSBpc3N1YW5jZSBtZXRob2QgZGVzY3JpYmVkIGluIGRyYWZ0LTA3LiBJdCBkb2VzIG5v dCBzdXBwb3J0IGtleSBjaGFuZ2Ugb3IgcmV2b2NhdGlvbiBidXQgaXMgcmVhZHkNCiB0byBiZSB1 c2VkIGJ5IGNsaWVudHMuIFRoZXJlIGlzIGFuIGludGVncmF0aW9uIHRlc3QgY2xpZW50WzJdIGJh c2VkIG9uIENlcnRib3QncyBBQ01FIHB5dGhvbiBtb2R1bGUgYW5kIEFDTUU0aiBoYXMgYW4gZXhw ZXJpbWVudGFsIGJyYW5jaFszXSBjYXBhYmxlIG9mIGlzc3VpbmcgY2VydGlmaWNhdGVzIGZyb20g UGViYmxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5MZXQncyBFbmNyeXB0IGhhcyBhbHNvIG1hZGUgc2lnbmlmaWNhbnQgcHJvZ3Jlc3MgaW1w bGVtZW50aW5nIGRyYWZ0LTA3IGluIEJvdWxkZXJbNF0sIHRoZSBwcm9kdWN0aW9uIExldCdzIEVu Y3J5cHQgQ0Egc29mdHdhcmUsIGJ1dCBpdCBpcyBub3QgeWV0IHJlYWR5IGZvciB1c2UgYnkgY2xp ZW50cy4gVGhpcyBpbXBsZW1lbnRhdGlvbiBkb2VzIGluY2x1ZGUga2V5IGNoYW5nZSBhbmQgcmV2 b2NhdGlvbiBidXQgZG9lcw0KICoqbm90KiogdXNlIHByby1hY3RpdmUgaXNzdWFuY2UuIEkgYmVn YW4gYSBzZXBhcmF0ZSB0aHJlYWRbNV0gZm9yIHRoZSBvcmRlciBmaW5hbGl6YXRpb24gYXBwcm9h Y2ggdGhhdCB3ZSBoYXZlIHN0YXJ0ZWQgdG8gaW1wbGVtZW50IGZvciBCb3VsZGVyLiBQZWJibGUg d2lsbCBiZSB1cGRhdGVkIHRvIHVzZSB0aGlzIGlzc3VhbmNlIGFwcHJvYWNoIGluIHBsYWNlIG9m IHByby1hY3RpdmUgaXNzdWFuY2Ugc2hvcnRseS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXJlIHRoZXJlIGFueSBvdGhlciBzZXJ2ZXJzIG9y IGNsaWVudHMgb3V0IHRoZXJlIHRoYXQgYXJlIHNwZWFraW5nIGRyYWZ0LTA3IEFDTUUgYW5kIHVz aW5nIG9yZGVyIGJhc2VkIGlzc3VhbmNlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIERhbmllbCAvIGNwdTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bMF06IDxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFjbWUtYWNtZS0wNyI+DQpodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hY21lLWFjbWUtMDc8L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bMV06IDxhIGhyZWY9Imh0 dHBzOi8vZ2l0aHViLmNvbS9sZXRzZW5jcnlwdC9wZWJibGUiPmh0dHBzOi8vZ2l0aHViLmNvbS9s ZXRzZW5jcnlwdC9wZWJibGU8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5bMl06IDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9sZXRzZW5j cnlwdC9ib3VsZGVyL2Jsb2IvZTJjYzZmYmU2ODJkZDVkNDlkYTMyYzIzNTc4MzhiMGNjODMxZjEw Zi90ZXN0L2NoaXNlbDIucHkiPg0KaHR0cHM6Ly9naXRodWIuY29tL2xldHNlbmNyeXB0L2JvdWxk ZXIvYmxvYi9lMmNjNmZiZTY4MmRkNWQ0OWRhMzJjMjM1NzgzOGIwY2M4MzFmMTBmL3Rlc3QvY2hp c2VsMi5weTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlszXTogPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3NocmVkL2FjbWU0ai90cmVl L2RyYWZ0Ij5odHRwczovL2dpdGh1Yi5jb20vc2hyZWQvYWNtZTRqL3RyZWUvZHJhZnQ8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bNF06IDxh IGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9sZXRzZW5jcnlwdC9ib3VsZGVyIj5odHRwczovL2dp dGh1Yi5jb20vbGV0c2VuY3J5cHQvYm91bGRlcjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPls1XTogPGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJj aGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9hY21lL0RJakpFQjA2SjVjRnl1T2xHUFZjWTJJNTF2ZyI+ DQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2FjbWUvRElqSkVCMDZKNWNG eXVPbEdQVmNZMkk1MXZnPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_e81bedc777c340f58c1f43205129a6f2Buypgvkex01intrabuypass_-- From nobody Sat Oct 21 13:15: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 0D174132D18 for ; Sat, 21 Oct 2017 13:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[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 yfcJech-F6RM for ; Sat, 21 Oct 2017 13:15:40 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 0348813292E for ; Sat, 21 Oct 2017 13:15:39 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id z50so22132158qtj.4 for ; Sat, 21 Oct 2017 13:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=vcIab3H19uf1VdQu4ZbQN5GiwYXmMurhN0n+WFJfX3Q=; b=BRemg9d3JpYpspe4zVExMAt4MmKKWlrwt9ftDXYu/Fo9iS3yKC5cecvMJCp0cc022w DKUUN9LoDGu4UZ3ulfvz0CVyh1FAWLSkCyzOVdTUGfsIkbvoAF0qBtrSzTdAnGldh9zC A8q5+wZJLBAiMzyhorWVTmXWslblr8jRvzcLhnDLvA5C/xNCVZ14SJz0PP88lESudaQW vLWgpesnJkGsaTUKW4DgKq+lBAxgxZlUIVVffWmEaJsIQjlpK5Eg25ATMdPtxulOmBt+ w/+XpKN5znmgO+Z9FAdiqM2ew+cd8cUzETPQTWORlOoehh9mGGvJ0IsTTdaQRYAOAbr7 XkMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=vcIab3H19uf1VdQu4ZbQN5GiwYXmMurhN0n+WFJfX3Q=; b=k4efHINxzmXDPQrw0jkjOovG+bmowJDNYCyr9AoqZ9zKP+VCgrEpyYUFTYJ9u8d4te 8Gzi61RV7y/4PiDfHCpvUgx+NetV3FsPfGRmnkUJ743f8OzGx0SHebajR7f4NbWi20T7 m2WsfWCKUsXZbH1pcPBq9YptQemGjV/iCb7BbLXM6Ws1C+3+g5su13GLvsIPo4Fw3ouC xNXAvtXRQL/yRzG8COfL9yK7VH57cRSdp+anhm1UBXan0t48809yDxJ5tZEfwlhfxoNI +gY60k3wSczR7Ic2Oy56e9BuwMeaAy5pU8Zv+pxPyRKHgO7wjmIJIjTvCIOSzFlYK7ex NWqQ== X-Gm-Message-State: AMCzsaUbil6Utah2C5TdKK7axAI7cr2uEIi5sJfGMIcqTy1QdrSg0rC+ VGzJmeF4UCZNb4PUUklpMntxldlXzvA+Xpjmy2s3iw== X-Google-Smtp-Source: ABhQp+QqI8K+Qx+CDYzuA8bg00qmEV+dnF/2qL4OnYWRpP3vNsjl6sPcmQpcxSH4UUmYV4034wRauc4UyzKnTipHbH0= X-Received: by 10.200.24.231 with SMTP id o36mr12674021qtk.91.1508616938721; Sat, 21 Oct 2017 13:15:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Clint Wilson Date: Sat, 21 Oct 2017 20:15:27 +0000 Message-ID: To: Mads Egil Henriksveen , "cpu@letsencrypt.org" , IETF ACME Content-Type: multipart/alternative; boundary="001a114fefa0bc1998055c144030" Archived-At: Subject: Re: [Acme] Survey of draft-07 implementations 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, 21 Oct 2017 20:15:42 -0000 --001a114fefa0bc1998055c144030 Content-Type: text/plain; charset="UTF-8" Hi team! DigiCert has implemented a proof of concept ACME server using ACME draft-07. We utilize External Account Binding, but not Out-of-Band Challenges nor Pre-Authorization, though both are of potential interest to us in the future. We currently handle both of those by way of the External Account Binding, which provides the full context of a customer account, and therefore has the support of Pre-Authorization functions and our Support/Validation teams to assist with Out-of-Band Challenges. Our interest in ACME would be the potential complete automation of those steps, but given the available workaround, we opted to not focus on supporting that yet. Cheers! -Clint On Sat, Oct 21, 2017 at 12:56 AM Mads Egil Henriksveen < Mads.Henriksveen@buypass.no> wrote: > Hi > > > > Buypass has implemented an ACME server based on ACME draft-07 which use > order based issuance, this version is currently available in a test > environment only. We are also running a constrained pilot in our production > environment (supporting CertBot) and this will be upgraded to the ACME > draft-07 version shortly. > > > > We have included support for Pre-Authorization, but we are not using > neither External Account Binding nor the Out-of-Band Challenge in our > current version. However, we are considering to use the Out-of-Band > Challenge type and possibly also External Account Binding in a next phase > where the idea is to exploit how the ACME protocol may be used to support > issuance and administration of other types of TLS certificates than DV. > > > > Regards > > Mads > > > > *From:* Acme [mailto:acme-bounces@ietf.org] *On Behalf Of *Daniel McCarney > *Sent:* fredag 20. oktober 2017 22:36 > *To:* IETF ACME > *Subject:* [Acme] Survey of draft-07 implementations > > > > Hi folks, > > > > As the WG approaches last-call on ACME draft-07[0] I wanted to get a sense > of which portions of the spec have been implemented and which haven't. > > > > In particular I'd like to hear if anyone has implemented: > > * External Account Binding (Section 7.3.5) > > * Pre-Authorization for Order based issuance (Section 7.4.1) > > * The Out-of-Band Challenge type (Section 8.6) > > > > Let's Encrypt has made good progress on draft-07 server implementation but > has no plans to implement the above three features. It would be nice to > hear someone has running code for these protions of spec. > > > > Ignoring the above three items Let's Encrypt has implemented the core > portions of draft-07 in Pebble[1]. It's presently using the pro-active > issuance method described in draft-07. It does not support key change or > revocation but is ready to be used by clients. There is an integration test > client[2] based on Certbot's ACME python module and ACME4j has an > experimental branch[3] capable of issuing certificates from Pebble. > > > > Let's Encrypt has also made significant progress implementing draft-07 in > Boulder[4], the production Let's Encrypt CA software, but it is not yet > ready for use by clients. This implementation does include key change and > revocation but does **not** use pro-active issuance. I began a separate > thread[5] for the order finalization approach that we have started to > implement for Boulder. Pebble will be updated to use this issuance approach > in place of pro-active issuance shortly. > > > > Are there any other servers or clients out there that are speaking > draft-07 ACME and using order based issuance? > > > > - Daniel / cpu > > > > [0]: https://tools.ietf.org/html/draft-ietf-acme-acme-07 > > [1]: https://github.com/letsencrypt/pebble > > [2]: > https://github.com/letsencrypt/boulder/blob/e2cc6fbe682dd5d49da32c2357838b0cc831f10f/test/chisel2.py > > [3]: https://github.com/shred/acme4j/tree/draft > > [4]: https://github.com/letsencrypt/boulder > > [5]: > https://mailarchive.ietf.org/arch/msg/acme/DIjJEB06J5cFyuOlGPVcY2I51vg > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a114fefa0bc1998055c144030 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi team!

DigiCert has implemented a pro= of of concept ACME server using ACME draft-07. We utilize External Account = Binding, but not Out-of-Band Challenges nor=C2=A0Pre-Authorization, though = both are of potential interest to us in the future. We currently handle bot= h of those by way of the External Account Binding, which provides the full = context of a customer account, and therefore has the support of Pre-Authori= zation functions and our Support/Validation teams to assist with Out-of-Ban= d Challenges. Our interest in ACME would be the potential complete automati= on of those steps, but given the available workaround, we opted to not focu= s on supporting that yet.

Cheers!
-Clint=


= On Sat, Oct 21, 2017 at 12:56 AM Mads Egil Henriksveen <Mads.Henriksveen@buypass.no> wrote:

Hi

=C2=A0

Buypass has implemente= d an ACME server based on ACME draft-07 which use order based issuance, thi= s version is currently available in a test environment only. We are also running a constrained pi= lot in our production environment (supporting CertBot) and this will be upg= raded to the ACME draft-07 version shortly.

=C2=A0

We have included suppo= rt for Pre-Authorization, but we are not using neither External Account Bin= ding nor the Out-of-Band Challenge in our current version. However, we are considering to use the O= ut-of-Band Challenge type and possibly also External Account Binding in a n= ext phase where the idea is to exploit how the ACME protocol may be used to= support issuance and administration of other types of TLS certificates than DV.

=C2=A0

Regards<= /span>

Mads

=C2=A0

From: = Acme [mailto:acm= e-bounces@ietf.org] On Behalf Of Daniel McCarney
Sent: fredag 20. oktober 2017 22:36
To: IETF ACME <acme@ietf.org>
Subject: [Acme] Survey of draft-07 implementations

=C2=A0

Hi folks,

=C2=A0

As the WG approaches last-call on ACME draft-07[0] I= wanted to get a sense of which portions of the spec have been implemented = and which haven't.

=C2=A0

In particular I'd like to hear if anyone has imp= lemented:

* External Account Binding (Section 7.3.5)=

* Pre-Authorization for Order based issuance (Sectio= n 7.4.1)

* The Out-of-Band Challenge type (Section 8.6)

=C2=A0

Let's Encrypt has made good progress on draft-07= server implementation but has no plans to implement the above three featur= es. It would be nice to hear someone has running code for these protions of= spec.

=C2=A0

Ignoring the above three items Let's Encrypt has= implemented the core portions of draft-07 in Pebble[1]. It's presently= using the pro-active issuance method described in draft-07. It does not su= pport key change or revocation but is ready to be used by clients. There is an integration test client[2] based on Cer= tbot's ACME python module and ACME4j has an experimental branch[3] capa= ble of issuing certificates from Pebble.

=C2=A0

Let's Encrypt has also made significant progress= implementing draft-07 in Boulder[4], the production Let's Encrypt CA s= oftware, but it is not yet ready for use by clients. This implementation do= es include key change and revocation but does **not** use pro-active issuance. I began a separate thread[5] for the orde= r finalization approach that we have started to implement for Boulder. Pebb= le will be updated to use this issuance approach in place of pro-active iss= uance shortly.

=C2=A0

Are there any other servers or clients out there tha= t are speaking draft-07 ACME and using order based issuance?<= /p>

=C2=A0

- Daniel / cpu

=C2=A0

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
--001a114fefa0bc1998055c144030-- From nobody Tue Oct 24 06:53: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 40D4B13F665 for ; Tue, 24 Oct 2017 06:53: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=unavailable 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 RWDmVIU4zfXe for ; Tue, 24 Oct 2017 06:53:19 -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 E8A3A13F49A for ; Tue, 24 Oct 2017 06:45:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id B37611C1A6; Tue, 24 Oct 2017 15:45:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=devever.net; h= content-language:content-transfer-encoding:content-type :content-type:in-reply-to:mime-version:user-agent:date:date :message-id:from:from:references:subject:subject:received :received; s=mimas; t=1508852702; x=1527042063; bh=7Ub4JAvivIeb5 BKE2qY4/wdSP9mhiRVwFv69q/GT4hQ=; b=FwYLdjIpEnVw2aN488+Cad+LYg1sk 5OrvF4MYErFt93xsgsaTuuqclCxq5cmzjVGTU7U5Jdhtbxu9DcXokM7S7MyOPTKA F0T4RBAjHRuwvTbstnzgLrKjZacmn930i4M7foglfKvWYtvaBEqL4SKZog3hrV8J Ov9IMsVrL7Qg2WYkWzzYjfAkNbXdLkPMn407UHxo0kBmLlpAiBRrnumg36hDEoZL u7j3xgBauWBJ+H7MFHaCTXR0Jzxmbgh1zTjtjU8Gkb+JrT7nofTz4V9uCYIKNetR lPLEUX70xywaO7EfnubLdM/Vnf7WX9KA9pft2Cw8nJSGS5xYEawtY8YbA== 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 lc-eAkeodUUv; Tue, 24 Oct 2017 15:45:02 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTPSA id 7E5FC1C027; Tue, 24 Oct 2017 15:45:02 +0200 (CEST) To: cpu@letsencrypt.org, acme@ietf.org References: From: Hugo Landau Message-ID: <71f3e975-7cee-18cf-2635-80eb13adff12@devever.net> Date: Tue, 24 Oct 2017 14:45:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR 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, 24 Oct 2017 13:53:20 -0000 My thoughts: - Requiring an explicit action against the order after the fulfilment of authorizations to cause issuance seems fine to me. - I think moving the submission of the CSR to the end of this process is a mistake. The ACME protocol should permit CAs to implement policy as far as is reasonably practicable with regard to the workflows around which the protocol is organised. Providing the CSR up-front allows the CA to predicate order processing on aspects of that CSR, both with regard to the present protocol and any future extensions, both now and in the future in ways that we can and cannot foresee. I don't think it's appropriate to defer giving critical information to the CA until the last minute due to a resource utilisation concern which LE has already proven capable of dealing with, especially when the whole point of the order flow in the first place was to provide more flexibility for CAs to institute policy. A possible compromise would be to require the CSR to be submitted both on new-order and on finalization, but that's quite clumsy. From nobody Tue Oct 24 07:17: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 45FF613F6C9 for ; Tue, 24 Oct 2017 07:17:45 -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 IvwO4uM8Es1F for ; Tue, 24 Oct 2017 07:17:38 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47CF113F3D1 for ; Tue, 24 Oct 2017 07:17:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id A60A753734; Tue, 24 Oct 2017 17:17:36 +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 W3p4UZU5qLbh; Tue, 24 Oct 2017 17:17:36 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id ED92521C; Tue, 24 Oct 2017 17:17:32 +0300 (EEST) Date: Tue, 24 Oct 2017 17:17:32 +0300 From: Ilari Liusvaara To: Hugo Landau Cc: cpu@letsencrypt.org, acme@ietf.org Message-ID: <20171024141732.ufjysx5f73pyc5f4@LK-Perkele-VII> References: <71f3e975-7cee-18cf-2635-80eb13adff12@devever.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <71f3e975-7cee-18cf-2635-80eb13adff12@devever.net> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR 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, 24 Oct 2017 14:17:45 -0000 On Tue, Oct 24, 2017 at 02:45:01PM +0100, Hugo Landau wrote: > > The ACME protocol should permit CAs to implement policy as far as is > reasonably practicable with regard to the workflows around which the > protocol is organised. Providing the CSR up-front allows the CA to > predicate order processing on aspects of that CSR, both with regard to > the present protocol and any future extensions, both now and in the > future in ways that we can and cannot foresee. I don't think it's > appropriate to defer giving critical information to the CA until the > last minute due to a resource utilisation concern which LE has already > proven capable of dealing with, especially when the whole point of the > order flow in the first place was to provide more flexibility for CAs to > institute policy. Example: Suppose that CAA-PKP got added (restrict issuance on SPKI key). Implementing that without knowing the public key at validation time is annoying. As to why one would want something like that, it would allow limiting trust on certficiate management system without deploying something as dangerous as HPKP. -Ilari From nobody Tue Oct 24 09:43: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 BD5B5139672 for ; Tue, 24 Oct 2017 09:42:59 -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, 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=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 XmMURQJ8Ll6L for ; Tue, 24 Oct 2017 09:42: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 8E67E1394EB for ; Tue, 24 Oct 2017 09:42: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 v9OGY1lu021419 for ; Tue, 24 Oct 2017 17:42:57 +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=M+93jdIXoqQAxxFR1ymQhlyPoxxAR0pliiMk8UMamLA=; b=he8kvBJuEGmIc2BmuW/9AkThEUAqx+Agx28VV+pc8YevGWaIEJW4DkI/ENVNgnK7jVmg SOlgipUtMK3fif7twA9Q1ugJzpPIZ/l9aHjvboJx6XqalIswnQhqBYiscblHGewxgmFK hXESKOPFAh6RzjoutdvT29X21BYcdL4c/RME+rRqfEwUU9CexbKZ6tU+WvvJ5PR4hPYQ 67r73nTDSbfDc9FseVwWzUbX4pClR/cE2IvJfZ77e0WF6npczNxNGKrgq/OCOzxQG+5B ISeHr7TFc/vAvJWIWbjUBMYnaadmjmdeni+NWP6mGc0klAphT6j/xYNJAekzZ0hHdvJx QQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050095.ppops.net-00190b01. with ESMTP id 2dqws2aq1w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 24 Oct 2017 17:42:56 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v9OGfQpR028217 for ; Tue, 24 Oct 2017 12:42:55 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dr1ju9gbf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 24 Oct 2017 12:42:55 -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, 24 Oct 2017 12:42: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, 24 Oct 2017 12:42:54 -0400 From: "Salz, Rich" To: "acme@ietf.org" Thread-Topic: Agenda topics Thread-Index: AQHTTOcjOMUeLZzSd0KeAvVloUQFsA== Date: Tue, 24 Oct 2017 16:42:54 +0000 Message-ID: <63DFE1DD-BD31-4479-8201-F687159D2CF5@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.119] Content-Type: multipart/alternative; boundary="_000_63DFE1DDBD3144798201F687159D2CF5akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-24_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-1707230000 definitions=main-1710240229 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-24_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-1707230000 definitions=main-1710240228 Archived-At: Subject: [Acme] Agenda topics 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, 24 Oct 2017 16:43:00 -0000 --_000_63DFE1DDBD3144798201F687159D2CF5akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhc3N1bWUgd2XigJlsbCBkbyBhIGJsb2NrIG9mIHRpbWUgb24gdGhlIGNvcmUgZHJhZnQgY2hh bmdlcywgYW5kIHdoYXQgd2Ugc2hvdWxkIGRvIGFib3V0IHJlLWVudGVyIFdHTEMgb3Igb3RoZXIg b3B0aW9ucy4NCg0KQW5kIHRoZW4gSSB0aGluayBtdWNoIG9mIG91ciB0aW1lIHdpbGwgYmUgb24g U1RJUiBjZXJ0aWZpY2F0ZSBzdHVmZi4NCg0KQnV0IEkgY291bGQgYmUgdG90YWxseSB3cm9uZy4g IERvIHlvdSBoYXZlIHRoaW5ncyB5b3Ugd2FudCB0byB0YWxrIGFib3V0PyAgRWl0aGVyIGxvY2Fs bHkgb3IgcmVtb3RlbHk/ICBXZSBoYXZlIHR3byBob3VycyBXZWRuZXNkYXkgaW4gc2Vjb25kIHNl c3Npb24uDQoNClBsZWFzZSBwb3N0IQ0K --_000_63DFE1DDBD3144798201F687159D2CF5akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29t cG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1z dHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxi b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGFzc3VtZSB3ZeKAmWxsIGRvIGEgYmxv Y2sgb2YgdGltZSBvbiB0aGUgY29yZSBkcmFmdCBjaGFuZ2VzLCBhbmQgd2hhdCB3ZSBzaG91bGQg ZG8gYWJvdXQgcmUtZW50ZXIgV0dMQyBvciBvdGhlciBvcHRpb25zLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QW5kIHRoZW4gSSB0aGluayBtdWNoIG9mIG91ciB0 aW1lIHdpbGwgYmUgb24gU1RJUiBjZXJ0aWZpY2F0ZSBzdHVmZi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkJ1dCBJIGNvdWxkIGJlIHRvdGFsbHkgd3JvbmcuJm5i c3A7IERvIHlvdSBoYXZlIHRoaW5ncyB5b3Ugd2FudCB0byB0YWxrIGFib3V0PyZuYnNwOyBFaXRo ZXIgbG9jYWxseSBvciByZW1vdGVseT8mbmJzcDsgV2UgaGF2ZSB0d28gaG91cnMgV2VkbmVzZGF5 IGluIHNlY29uZCBzZXNzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+UGxlYXNlIHBvc3QhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_63DFE1DDBD3144798201F687159D2CF5akamaicom_-- From nobody Tue Oct 24 09:49: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 79A4D13F3CC for ; Tue, 24 Oct 2017 09:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfjFenfMQQ08 for ; Tue, 24 Oct 2017 09:49: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 514E4139432 for ; Tue, 24 Oct 2017 09:49:12 -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=URPAR20iC2UUeyaQfLBXGAVq35748IBbXtwx4TTftAo=; b=yIegfk+14QR4eUdXh5ah5CNa1AnpQTcscj3PoH7oCoYnJJ8tUexoZFpAg+HCs7k95ralTzUssd8i6ChCaMORnBVNFND4lV5aWJu7ourH/LgXLXKNTD7v2CGYTd4HmZ8KjOT2OimE7yzCM7fVro4TwsbcJMqX/XwnIO7+g7tok5o=; Received: ; Tue, 24 Oct 2017 09:49:08 -0700 To: "Salz, Rich" , "acme@ietf.org" References: <63DFE1DD-BD31-4479-8201-F687159D2CF5@akamai.com> From: Jacob Hoffman-Andrews Message-ID: <0067a7f0-0d8a-8599-d7d2-3bd86bcbecd5@eff.org> Date: Tue, 24 Oct 2017 09:49:11 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <63DFE1DD-BD31-4479-8201-F687159D2CF5@akamai.com> Content-Type: multipart/alternative; boundary="------------D9E82A27B0CD9361FB8EAF9D" Content-Language: en-US Archived-At: Subject: Re: [Acme] Agenda topic - nonces 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, 24 Oct 2017 16:49:15 -0000 This is a multi-part message in MIME format. --------------D9E82A27B0CD9361FB8EAF9D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit I'd like to talk about making nonces optional for the server. Specifically, we introduced nonces because the main implementer (Let's Encrypt) was using a third party to terminate TLS. However, we've found that in practice nonces make load balancing between clusters more difficult, and we're considering removing the third-party TLS termination in order to be able to remove nonces. On 10/24/2017 09:42 AM, Salz, Rich wrote: > > I assume we’ll do a block of time on the core draft changes, and what > we should do about re-enter WGLC or other options. > >   > > And then I think much of our time will be on STIR certificate stuff. > >   > > But I could be totally wrong.  Do you have things you want to talk > about?  Either locally or remotely?  We have two hours Wednesday in > second session. > >   > > Please post! > > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme --------------D9E82A27B0CD9361FB8EAF9D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I'd like to talk about making nonces optional for the server. Specifically, we introduced nonces because the main implementer (Let's Encrypt) was using a third party to terminate TLS. However, we've found that in practice nonces make load balancing between clusters more difficult, and we're considering removing the third-party TLS termination in order to be able to remove nonces.

On 10/24/2017 09:42 AM, Salz, Rich wrote:

I assume we’ll do a block of time on the core draft changes, and what we should do about re-enter WGLC or other options.

 

And then I think much of our time will be on STIR certificate stuff.

 

But I could be totally wrong.  Do you have things you want to talk about?  Either locally or remotely?  We have two hours Wednesday in second session.

 

Please post!



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

--------------D9E82A27B0CD9361FB8EAF9D-- From nobody Tue Oct 24 18:55:49 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 DA9F713AAC7; Tue, 24 Oct 2017 18:55:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dale Worley To: Cc: draft-ietf-acme-acme.all@ietf.org, acme@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150889654086.4766.516378051615267766@ietfa.amsl.com> Date: Tue, 24 Oct 2017 18:55:40 -0700 Archived-At: Subject: [Acme] Genart telechat review of draft-ietf-acme-acme-07 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, 25 Oct 2017 01:55:41 -0000 Reviewer: Dale Worley Review result: On the Right Track I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-acme-acme-07 Reviewer: Dale R. Worley Review Date: 2017-10-24 IETF LC End Date: 2017-09-14 IESG Telechat date: 2017-10-26 Summary: This draft is on the right track but has open issues, described in the review. My general impression is that this is a sound piece of work, and apparently one that satisfies a serious practical need. But this draft has a large number of open issues, and really needs a careful, thorough clean-up pass. And until that's done, it's not clear what genuine problems might be lurking. I haven't put in the time I would have liked to, so some of the issues I've detected might prove to be nonexistent. A lot of these issues are simply English usage. The structure of the exposition needs to be improved, including pulling the specialized vocabulary into a glossary, providing overviews of processes whose multiple details are discussed, etc. Some issues are technical slips, like missing required fields in HTTP messages. Some seem to be more substantial technical issues -- What is the versioning and extensibility system? What are the requirements on POST operations that effectively carry no more information than that the operation happens? And one question -- the terms of service agreement -- seems to brush into legal territory. The number and variety of these minor problems suggests that the whole work needs to be thought through more carefully before being frozen. Within that context, I will not attempt to sort these items into categories or rate them on importance, but just list them in order by parts of the text that they relate to. And note that a number of these items are mentioned relative to only one of several places in the text they apply to. ---------------------------------------------------------------------- There's a lot of talk about accounts, but no overview of the lifecycle of an account. Compare to the presentation of the overview of the lifecycle of a certificate request. There should be blanket policies on whether and where non-standard fields can be included by both client and server. Also, there ought to be versioning of Acme itself. 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. I'm no expert here, but it seems to me that "the authentication of domain names" is not correct -- only actors can be authenticated. I think the accurate phrasing is "the authentication of servers (TLS, HTTPS, etc.) which act on behalf of domain names". (This would be a minor matter in the body, especially if this elision was universally used in the field, but an abstract should require little context.) Ditto for the first paragraph of section 1. DISCLAIMER: This is a work in progress draft of ACME and has not yet had a thorough security analysis. I assume that this is going to be removed once this document is published as an RFC. If the RFC hadn't had a thorough security analysis, there would be no value in publishing it as an RFC. However there is no attached statement indicating when this statement is to be removed. What is actually going on here? Table of Contents 6.4. Replay protection 6.4.2. "nonce" (Nonce) JWS header parameter 6.5. Rate limits These section titles aren't capitalized the same way as the other section titles. 1. Introduction Existing Web PKI certificate authorities tend to run on a set of ad hoc protocols for certificate issuance and identity verification. s/run on/use/? a typical user experience is something like: I think you want to broaden this to "a typical protocol is". That doesn't change things much, because the user is one endpoint of the protocol. But you don't want to de-emphasize what the CA does, either. (I reflexively think of this as a protocol problem, whereas the authors probably reflexively think of this as a user experience problem.) * Put a CA-provided challenge at a DNS location corresponding to the target domain. What does "corresponding to" mean? I think you want "in a DNS record for the target domain". * Receive CA challenge at a (hopefully) administrator-controlled email address corresponding to the domain and then respond to it on the CA's web page. s/CA challenge/CA-provided challenge/ for parallelism. s/corresponding to the domain/within the domain/? It seems that there should be an item between the third and fourth items: o The CA makes the newly issued certificate accessible to the user (via the CA's web site? via e-mail?) -- This document describes an extensible framework for automating the issuance and domain validation procedure, thereby allowing servers and infrastructural software to obtain certificates without user interaction. Use of this protocol should radically simplify the deployment of HTTPS and the practicality of PKIX authentication for other protocols based on Transport Layer Security (TLS) [RFC5246]. I think you need some background on why this matters. In the naive default model, someone wants to set up a web server and needs to obtain a certificate. Yes, this will require 1 to 3 hours, but it's a one-time cost over the life of the web site. And I doubt that getting one's self plugged into the Acme system of a CA will take *less* time. Your model seems to be an operator that wants to set up many servers that are authenticatable to many different identities, with each identity being initially vouched for by the same operator. But this suggests that the multiple identities are third parties that are in some way subordinate or derived identities to the operator's identity, either "departments" within one entity, or customers of a vendor. In particular, how does Acme work relative to the case where a service provider claims it is setting up a web site for a third party? [ruminations deleted] I think you need to underline that this only handles the DV case, and not the OV and EV cases. On the first reading, I overlooked the bit about "automating the issuance and domain validation procedure", and immediately started wondering how Acme prevents a service provider from generating bogus web servers for third parties, and thinking it doesn't. But I reflexively think of certificates in terms of OV rather than DV. I suspect many readers also make this assumption. 2. Deployment Model and Operator Experience The guiding use case for ACME is obtaining certificates for websites (HTTPS [RFC2818]). You probably want to emphasize "obtaining domain validation-type certificates ". Prior to ACME, when deploying an HTTPS server, an operator typically This is the first use of "operator", so you probably want to say "the server operator". o The ACME client prompts the operator for the intended domain name(s) that the web server is to stand for. Probably want to say "The operator's ACME client" to make it clear that the client is working for/controlled by/attached to/located at the operator. o In the background, the ACME client contacts the CA and requests that it issue a certificate for the intended domain name(s). It seems that all of the remaining steps are "in the background", as they can run to completion without operator intervention. So I think you want to emphasize "In the background" as an assertion about the remaining steps as a group. o The CA verifies that the client controls the requested domain name(s). "here a miracle happens" -- I think you want to flesh this out or provide a reference to the previous discussion, and especially emphasize that the Internet operations are carried out by the Acme client. E.g., "The ACME client proves to the CA that the operator controls the domain by one of the above-described methods." But maybe I'm being too fussy about the words "controls the requested domain name(s)". o Once the CA is satisfied, the certificate is issued There's no point using the passive when the subject has already been used in the sentence: "Once the CA is satisfied, it issues the certificate". In this way, it would be nearly as easy to deploy with a CA-issued certificate as with a self-signed certificate. As someone who detests setting up yet another account for yet another web site, I would like you to modify this to, "once the operator has an ACME relationship with one or more CAs, it would be nearly ...". [Check how much work the operator needs to get his ACME client connected to a CA. If this is easy, emphasize it in the intro, as it's a major virtue of ACME!] 3. Terminology The two main roles in ACME are "client" and "server". The ACME client uses the protocol to ... An ACME client is represented by an "account key pair". The client uses the private key ... These two paragraphs contain two sentences of terminology definition and two paragraphs of setting up the structure of the ACME client/server system. That's not a bad thing, but it's more than simply "Terminology". Conversely, there's a lot of terminology in this draft that isn't defined here. Probably foremost is "operator", but there should also be some explanation of the use of "response" when that is used to describe an HTTP *request*. One approach would be to move most of these two paragraphs into the beginning of section 4, and then expanding section 3 to include various terms that might not be familiar to people not fully involved in certificate-issuance procedures. The server uses the public key to verify the authenticity and integrity of messages from the client. What information is given to the server by authenticating the request using the public key? One possibility is that the server only needs to know that two requests came from "the same" Acme client, in which case all it needs to check is that both were signed by the same key. But if the key conveys identity information to the server, how is that managed? That should be described (or referenced) at the very beginning of the protocol description, as that is the first action of the Acme protocol, setting up the client and connecting it to the CA. In many ways, ACME functions much like a traditional CA, I think you mean, "In many ways, an ACME server functions ...". ACME allows a client to request certificate management actions using a set of JavaScript Object Notation (JSON) messages carried over HTTPS. In many ways, ACME functions much like a traditional CA, in which a user creates an account, requests a certificate, and proves control of the domains in that certificate in order for the CA to sign the requested certificate. The first sentence of this paragraph should go after the part about setting up the client/server relationship. The second sentence is actually overview for all of section 4 and should stay at the beginning of the section. The server then validates the challenges to check that the client has accomplished them. You may want to say "validates the responses to the challenges". (I'm from an environment where the phrase "challenge/response" is used a lot.) the server will issue the requested certificate and make it available to the client. If the Acme protocol can actually carry the certificate to the client, you probably want to make that clear in this sentence. "and send it to the client"? Order Signature -------> Required <------- Authorizations I assume that messages from the server are also signed. (How is the client to authenticate that it is talking to the server it thinks it's talking to?) I'd say, "the server's signatures also ought to be shown", but at this level of detail, I probably prefer that the signatures not be shown, as they seem to cause me visual clutter. This chart seems to leave out a lot of steps. Perhaps: Order -------> <------- Required Authorizations [Perform response actions.] Response Notification -------> [Verify response actions.] <------- Certificate 6.2. Request Authentication * "jwk" (JSON Web Key, only for requests to new-account and revoke-cert resources) For new-account requests, and for revoke-cert requests authenticated by certificate key, there MUST be a "jwk" field. These two requirements don't appear to be the same. If the client sends a JWS signed with an algorithm that the server does not support, then the server MUST return an error with status code 400 (Bad Request) and type "urn:ietf:params:acme:error:badSignatureAlgorithm". This is hard to understand until the type field is introduced below. (The type field doesn't seem to be a standard feature of JWS.) Easier wold be If the client sends a JWS signed with an algorithm that the server does not support, then the server MUST return an error document with status code 400 (Bad Request) and "urn:ietf:params:acme:error:badSignatureAlgorithm" in the "type" field. 6.3. Request URL Integrity As noted in Section 6.2 above, all ACME request objects carry a "url" header parameter in their protected header. Actually, section 6.2 calls it a "field". You should use consistent terminology, particularly given that in the context of HTTP, the term "header" has a special meaning. (What is the general usage in JWS discussions?) Except for the directory resource, all ACME resources are addressed with URLs provided to the client by the server. For these resources, the client MUST set the "url" header parameter to the exact string provided by the server (rather than performing any re-encoding on the URL). The server SHOULD perform the corresponding string equality check, configuring each resource with the URL string provided to clients and having the resource check that requests have the same string in their "url" header parameter. This is awkwardly phrased. Perhaps: Except for the directory resource, all ACME resources are addressed with URLs provided to the client by the server. When addressing these resources, the client MUST set the "url" header parameter to the exact string provided by the server (rather than performing any re-encoding on the URL). Conversely, the server MUST provide clients with the URLs by which the resources can be addressed through the server, and it SHOULD verify that the "url" header parameter the client provides when accessing a resource is the same string as the server provides clients for that resource. 6.3.1. "url" (URL) JWS header parameter Perhaps the last two paragraphs of section 6.3 should be moved into this section. This text is not as exact as I'd like. What does "to which this JWS object is directed" mean? Do you mean "The request that contains this object is not valid unless the HTTP request URL is exactly the same string as the value of this header parameter." And the phrase "be a string representing the URL" is extremely dangerous. Remember that a URL *is* a string, and if you mess with character encodings or the like, you get a *different* URL, albeit one that some process might consider "equivalent" to the original URL for some purposes. I'm not up to date on HTTP, but there are some complications regarding what the "request URI" of a request is; it's not always just the value of the "request-URI" field of the request-line. There's probably a set terminology for this concept; it would be wise to align with it. 6.4. Replay protection In order to protect ACME resources from any possible replay attacks, Could this be shortened to "In order to protect ACME resources from replay attacks, ..."? Every JWS sent by an ACME client MUST include, in its protected header, It's vague here what "JWS" means as an unqualified noun. I suspect, "JWS object", but some other uses suggest that there is a larger JWS construct within which the "object" is the "payload". In any case, the terminology should be brought into alignment with the JWS standard(s). It's not clear why the nonces are provided in the Replay-Nonce header rather than being provided in the JWS response. Compare when the client sends the nonce, when it is provide inside the JWS object. Indeed, this seems to be a layering violation -- the nonce is sent by the server in a header, but sent by the client in the JWS. It would be cleaner to send the nonce in both directions in a header, or send it in both directions in the JWS. Perhaps the standard JWS practice is to do it this way -- but the existence of section 6.4.1 suggests otherwise. It might be worth noting that it is acceptable for the server to "expire" unused nonces by not accepting nonces that were provided in responses too far in the past. (Assuming you want to allow it.) Since a client is required to retry requests that are rejected due to nonce failure, and that retry is expected to be done promptly, this behavior does not cause protocol failure. As written, this section suggests that a server MUST NOT reject a request as long as the nonce is valid, regardless of how long ago the nonce was issued. 6.4.1. Replay-Nonce This section reads very awkwardly. I think the intention is to provide a specification of the Reply-Nonce header field that stands alone. But it is a specification only in regard to the syntax of the field, not the semantics. OTOH, the first sentence of the section seems to be trying to describe the semantics of the field, which is confusing since it is nowhere near complete. If you want to say "generally, this field is to provide nonces that clients can use to uniquely identify requests" you want to be careful to qualify it with some statement that the exact usage is described in other specifications. Wording this correctly could get awkward. The phrase "unique to each message" isn't clear with regard to scope. Is it like SIP Call-Ids, which are unique over all space and time? Or just unique over the history of the server? The language is not as clear as I'd like about where it appears. Better to say "The server provides this header field in responses to carry a server-generated nonce to the client..." and "The Replay-Nonce header field MUST only be carried in HTTP response messages." 6.4.2. "nonce" (Nonce) JWS header parameter Again, this section hints at but does not specify the semantics of the datum. 6.5. Rate limits Creation of resources can be rate limited to ensure fair usage and prevent abuse. Once the rate limit is exceeded, the server MUST respond with an error with the type "urn:ietf:params:acme:error:rateLimited". Additionally, the server SHOULD send a "Retry-After" header indicating when the current request may succeed again. If multiple rate limits are in place, that is the time where all rate limits allow access again for the current request with exactly the same parameters. This is written as of rate limiting is some sort of global correctness property -- which can't be reduced to any property observable by either client or server. The first sentence doesn't even state that it's the *server* that can limit rates! Better is to clarify the intentions and roles of the various actors: A server MAY limit the rate at which it accepts various requests from various clients, e.g., to ensure fair usage and prevent abuse. If a server desires to postpone submission of a particular request, it MUST respond with an error with the type "urn:ietf:params:acme:error:rateLimited". Additionally, the server SHOULD [I can't see a reason why this isn't MUST] include a "Retry-After" header indicating the time interval after which all limitations the server is currently applying to this request will permit processing of this request. Different requests (even if from the same client) may be subject to different rate limits; the Retry-After value gives no information about other requests. -- In addition to the human readable "detail" field of the error response, the server MAY send one or multiple tokens in the "Link" header pointing to documentation about the specific hit rate limits using the "urn:ietf:params:acme:documentation" relation. What does "token" mean here? From context, I think you mean "link-value" (after RFC 5988), or better, "URI". Also, the value "urn:ietf:params:acme:documentation" doesn't seem to be placed in the IANA registry described in section 9.6. 6.6. Errors this document defines the following standard tokens for use in the "type" field (within the "urn:ietf:params:acme:error:" namespace): This isn't correct terminology. The namespace of these URNs is "ietf". Part of the problem is that there isn't a standardized term for the parts of a URN that are separated by colons, despite that almost all URN namespaces use colons as major separators. I think this version is both correct and readable: ... this document defines the following standard URIs for use in the "type" field (where each listed token is appended to "urn:ietf:params:acme:error:" to make the URI): +-----------------------+-------------------------------------------+ | Token | Description | +-----------------------+-------------------------------------------+ | badCSR | The CSR is unacceptable (e.g., due to a | | | short key) | -- This list is not exhaustive. The server MAY return errors whose "type" field is set to a URI other than those defined above. Servers MUST NOT use the ACME URN [RFC3553] namespace for errors other than the standard types. "namespace" isn't really correct here, but I think "sub-namespace" is. Clients SHOULD display the "detail" field of all errors. s/display/display to the user/ 7.1. Resources Each function is listed in a directory along with its corresponding URL, so clients only need to be configured with the directory URL. s/a directory/the directory resource/ The "up" link relation from "cert" to the CA chain is not shown in the figure. The "index" link relation isn't shown at all, though that couldn't be shown easily. You might want to note that in some way in the paragraph before the figure. | Submit an order | POST new-order | 201 -> order | When I first read this, I was unclear what an "order" is. It turns out that it is a request for a certificate. E.g., o Order resources, representing an account's requests to issue certificates (Section 7.1.3) You might want to either move toward the nomenclature "request a certificate" or more heavily emphasize "order" in the text. If you enlarge section 2 to cover all the specialized terminology, putting an entry in it for "order" would be helpful. There are quite a number of example request responses that do not contain the "index" link header. The figure does not show the key-change resource. 7.1.1. Directory whose fields names are drawn from the following table s/fields names/field names/ +-------------+--------------------+ | Field | URL in value | +-------------+--------------------+ | new-nonce | New nonce | | | | | new-account | New account | | | | | new-order | New order | | | | | new-authz | New authorization | | | | | revoke-cert | Revoke certificate | | | | | key-change | Key change | +-------------+--------------------+ In this table, one of the "URL in value" items is a predicate (verb-object), which makes sense; one is a noun phrase naming an action; and four are noun phrases (which are objects of an implied "get" or "obtain"). I suggest rephrasing the items into predicates directly telling what the URL does, e.g., "request new nonce", "change key". There is no constraint on the actual URL of the directory except that "actual" is probably superfluous here. The following metadata items are defined, all of which are OPTIONAL: It would probably be wise to allow servers to include non-standard metadata items. HTTP/1.1 200 OK Content-Type: application/json This should be preceded by something like "An example response to a directory GET is:". I suggest providing some sort of direct description of each example, and it would help to show requests and responses together. (But perhaps the RFC Editor thinks that unlabeled examples are OK if the context makes their purpose clear enough.) 7.1.2. Account Objects contact (optional, array of string): An array of URLs that the server can use to contact the client for issues related to this account. For example, the server may wish to notify the client about server-initiated revocation or certificate expiration. Strictly, you want "URIs" here, as tel:, sip:, and mailto: URIs are not URLs [RFC 6068]. 7.1.2.1. Orders List How long does an order URL remain valid? The particular URLs in the example suggests that the order URLs are valid only as long as the set of orders doesn't change. A larger question is whether order objects are ever purged from the orders list? Indeed, these questions can be generalized -- Can the server ever purge resources, invalidating the URLs that pointed to them? What sort of assurances can the client rely on? 7.1.3. Order Objects For final orders, the authorizations that were completed. What is a "final" order? The term "final" is used in a number of places, with possibly slightly different meanings, and needs to be properly defined. 7.1.4. Authorization Objects status (required, string): The status of this authorization. Possible values are: "pending", "processing", "valid", "invalid" and "revoked". It might be worth spelling out here what these states mean, as this is the definition of this field of the authorization object. If this field is absent, then the CA MUST consider this authorization valid for all orders until the authorization expires. There doesn't seem to be an "expired" status, so how can an authorization expire? For final authorizations it contains the challenges that were successfully completed. What is a "final" authorization? Section 8 describes a set of challenges for domain name validation. Section 8 is about challenges generally; really the challenges for domain name validation are sections 8.4 to 8.6. Perhaps they should be grouped into a subsection and this sentence should point to that? 7.3. Account Creation If the server wishes to present the client with terms under which the ACME service is to be used, it MUST indicate the URL where such terms can be accessed in the "terms-of-service" subfield of the "meta" field in the directory object, and the server MUST reject new-account requests that do not have the "terms-of-service-agreed" set to "true". Clients SHOULD NOT automatically agree to terms by default. Rather, they SHOULD require some user interaction for agreement to terms. I note that there seems to be no recording of when the account was created, i.e., *when* the terms of service was agreed to. Since the content behind the terms of service URL can change unpredictably, noting that the terms of service were agreed to is meaningless unless there is some fixation of the time of agreement. an error of type "invalidContact". The wording of the text is inconsistent (or just unclear) whether error types are give as full URNs or just the last component. 7.3.4. Changes of Terms of Service The problem document returned with the error MUST also include an "instance" field, indicating a URL that the client should direct a human user to visit in order for instructions on how to agree to the terms. This seems inconsistent with section 7.3, as the client can agree to the terms of service when creating an account within Acme, but changes in terms seem to require going out-of-band to agree to the new terms of service. Given that this could become a legal matter, it seems like a lot of care and thought should be put in on this. Ideally, a good lawyer should be consulted on this. HTTP/1.1 403 Forbidden Replay-Nonce: IXVHDyxIRGcTE0VSblhPzw Link: ;rel="terms-of-service" Content-Type: application/problem+json Content-Language: en The various examples don't seem to be indented consistently. Although I expect the RFC Editor will clean that up. 7.3.5. External Account Binding This can be used to an ACME account with an existing account in a non-ACME system, such as a CA customer database. There's a word missing after "This can be used to". The server MAY require a value to be present for the "external- account-binding" field. It would help the reader recover the context by starting this with, "In an account creation request,". To enable ACME account binding, a CA needs to provision the ACME client with a MAC key and a key identifier. You might want to annotate this, "by some means outside the scope of this document", or "presumably as part of establishing the external account". And I would use "provide" rather than "provision" -- "provision" suggests to me that there is a specific provisioning process that will be defined. What is a "MAC key"? I think you mean that any account binding must be represented by a key pair for the external account, and the private key of that pair is the "MAC key". OTOH, this may be inconveniently heavy-weight for real-world use -- I would expect the CA to simply provide a secret associated with the external account. (Or is that what a "MAC key" is?) The ACME client then computes a binding JWS to indicate the external account's approval of the ACME account key. This isn't quite correct. Perhaps The ACME client then computes a binding JWS to indicate that that the client, the owner of the external account, approves of the ACME account key. Or is that "the client, on behalf of the owner of the external account"? -- MUST reflect value of the "external-account-binding" field s/reflect value/reflect the value/ 7.3.6. Account Key Roll-over The client then encapsulates the key-change object in a JWS, signed with the requested new account key (i.e., the key matching the "newKey" value). The outer JWS MUST meet the normal requirements for an ACME JWS (see Section 6.2). The inner JWS MUST meet the normal requirements, with the following exceptions: Some detail is being left out. I think that the JWS described in the first of these paragraphs becomes the "inner JWS" of the next paragraph. But exactly how that nesting is to be performed doesn't seem to be described. 3. Check that the JWS protected header of the inner JWS has a "jwk" field. Is the generation of the "jwk" field specified in the text anywhere? 7.4. Applying for Certificate Issuance then the server MUST proactively issue the requested certificate and provide a URL for it in the "certificate" field of the order. I'm not sure that "proactively" has a specific meaning. I think you can just s/proactively issue/issue/ and capture the desired meaning -- the server doesn't have to issue a certificate instantly, but it cannot delay. The status of the order will indicate what action the client should take: This list is part of the definition of the order object, and should be put in section 7.1.3. 7.4.1. Pre-Authorization In some cases, a CA running an ACME server might have a completely external, non-ACME process for authorizing a client to issue for an identifier. I'm not sure that "client" is a proper subject for "issue". Perhaps you mean "for authorizing a client to be issued certificate(s) for an identifier". 7.4.2. Downloading the Certificate A certificate resource represents a single, immutable certificate. If the client wishes to obtain a renewed certificate, the client initiates a new order process to request one. Though I think you want to add what you really mean, namely that the new certificate will be fetched from a different URL. 7.5. Identifier Authorization The server may declare that an authorization is only valid for a specific order by setting the "scope" field of the authorization to the URL for that order. "scope" isn't shown in the figure in section 7.1. 7.5.1. Responding to Challenges The server is said to "finalize" the authorization when it has Despite the existence of a section titled "Terminology", very little of the terminology created for this document is listed there. 8. Identifier Validation Challenges Each challenge must describe: This isn't right; a challenge doesn't describe anything. But the descriptions of the challenge types include various information, etc. status (required, string): The status of this authorization. Possible values are: "pending", "valid", and "invalid". I think you mean "the status of this challenge". But you might mean "the status of the authorization containing this challenge". validated (optional, string): The time at which this challenge was completed by the server I'm not sure in what sense you mean "completed by", since it's the client that does the completing. I think you mean "the time at which the server recognized that the challenge was completed". The server can limit the size of this object by limiting the number of times it will retry a challenge. Rather, "the number of times it will permit the client to retry a challenge". Actually, the semantics of this field probably depends on the pattern of the actions by which the challenge is satisfied, and so may be dependent on the challenge type. If the server sets a challenge's "status" to "invalid", it SHOULD also include the "error" field to help the client diagnose why the challenge failed. Presumably, 'the "errors" field'. Also, section 8.2, "The server MUST add an entry to the "errors" field in the challenge after each failed validation query.", suggests that the server MUST include the "errors" field, not just SHOULD include. 8.1. Key Authorizations A key authorization is a string that expresses a domain holder's authorization for a specified key to satisfy a specified challenge, by concatenating the token for the challenge with a key fingerprint, separated by a "." character: key-authz = token || '.' || base64url(JWK_Thumbprint(accountKey)) In what way does a key authorization indicate something about a "domain holder"? The k.a. includes the token (presumably from the challenge object) and a computation based on an account's (private) key, so it includes information from the account holder. Or do you mean that "in the challenge, a token will be sent by the server that only the domain holder will be able to receive, and as part of the account holder's response to the challenge, it composes a key authorization string"? Really, I doubt that this is understandable without first explaining the general model of challenge/response that the challenge types defined here use, and that model doesn't seem to be described anywhere. I think it would be very helpful if that model was presented first, before the specific challenge types that use that model. Alternatively, you could just describe this as an abstract operation on strings, key-authz(token, accountKey) = token || '.' || base64url(JWK_Thumbprint(accountKey)) and leave defining its semantics to where key-authz() is used. The "JWK_Thumbprint" step indicates the computation specified in [RFC7638], using the SHA-256 digest [FIPS180-4]. As noted in JWA [RFC7518] any prepended zero octets in the JWK object MUST be stripped before doing the computation. The second sentence seems to be unclear. Is the "JWK object" the output of "JWK_Thumbprint(accountKey)"? If so, why isn't it called "the JWK_Thumbprint object"? And the significance of "prepended zero octets" is unclear; RFC 7518 does not include the word "prepend", so presumably does not specify any prepending. I suspect you mean that some stage of the processing of RFC 7518 is modified by stripping initial zero octets from some string, but such octets wouldn't be described as "prepended". 8.2. Retrying Challenges Clients can explicitly request a retry by re-sending their response to a challenge in a new POST request (with a new nonce, etc.). Again, this makes sense only under the assumption that satisfying a challenge has certain data-flow patterns, in that (apparently) the client must send a "response" and then -- well, it's not entirely clear what "a retry" is. You really need to lay out this pattern -- and the names you use for the actions within it -- before you specify the details of how clients and servers can perform it. In order to avoid denial-of-service attacks via client-initiated retries, servers SHOULD rate-limit such requests. There are two uses of "request" in the preceding sentence -- which of them is being rate-limited? 8.3. HTTP Challenge With HTTP validation, the client in an ACME transaction proves its control over a domain name by proving that for that domain name it can provision resources to be returned by an HTTP server. Better, "by proving that it can provision resources that are returned by an HTTP server accessible using a URL whose host is that domain name". type (required, string): The string "http-01" You don't actually say that these two fields are part of HTTP challenge objects. It MUST NOT contain any characters outside the base64url alphabet, including padding characters ("="). This could be read two ways; are the padding characters part of "the base64url alphabet", or are they part of "characters outside the base64url alphabet"? Perhaps: It MUST NOT contain any characters that are outside the base64url alphabet, or padding characters ("="). or It MUST NOT contain any characters that are outside the base64url alphabet (including padding characters ("=")). Maybe better would be "It must contain only characters in the base64url alphabet including/excluding padding characters("=")." Actually, this is just ugly to specify using English, because it's really hard to say it without using two negatives in one sentence, and making clear what the scope of each negative is. I think the best approach is to rely on the fact that RFC 7515 section 2 clearly defines that "=" is *not* in the base64url alphabet: It MUST NOT contain any characters that are not in the base64url alphabet. If someone complains this is unclear, add separate sentence saying that following RFC 7515 section 2, "=" is not in the base64url alphabet. The value of the resource MUST be the ASCII representation of the key authorization. Given that the key authorization is an ASCII string, it's not clear what its "ASCII representation" is. The client's response to this challenge indicates its agreement to this challenge by sending the server the key authorization covering the challenge's token and the client's account key. I think you mean, "The client responds to this challenge by POSTing an update to the challenge object, adding a "keyAuthorization" field containing the key authorization derived from the challenge's token and the client's account key." 1. Construct a URL by populating the URL template [RFC6570] "http://{domain}/.well-known/acme-challenge/{token}", where: * the domain field is set to the domain name being verified; and * the token field is set to the token in the challenge. What do the "*" mean? 8.5. DNS Challenge The record provisioned to the DNS is the base64url encoding of this digest. This doesn't make sense, as a DNS record is not a string per se. However, the next two sentences make clear what the DNS record should be. _acme-challenge.example.org. 300 IN TXT "gfj9Xq...Rg85nM" It's not clear where "gfj9Xq...Rg85nM" came from, as it's supposed to be a SHA-256 digest. Though the previous paragraph doesn't specify how the digest is to be represented; in parallel to earlier discussion, lower-case hexadecimal seems to be assumed. 8.6. Out-of-Band Challenge the client indicates this by sending a simple acknowledgment response to the server. The text doesn't describe what a "simple acknowledgements response" is. However, the other challenge types involve what seem to be parallel acknowledgment responses that are required to contain copies of token values, though in none of these cases does the POST carry any actual information other than the fact that the POST was made to the particular URL. What is the reason for this inconsistency? For that matter, why does the payload of the response for this challenge contain a "type" field? Perhaps there is something I don't understand about these POSTs which seem to convey no information other than triggering the server to take some action with regard to the target resource. 9.1. MIME Type: application/pem-certificate-chain The "Media Types" registry should be updated with the following additional value: IMO it's better to phrase this, "The following entry should be added to the "Media Types" registry:". I like to use "update" only for operations that modify existing entries. File should contain one or more certificates encoded as PEM according to RFC 7468 [RFC7468]. "should contain"? I think you want to say "File contains". Actually, "File must consist of ...". "encoded as PEM" seems to be undefined by RFC 7468. Perhaps "encoded using PEM textual encoding according to RFC 7468" is meant. 9.6. URN Sub-namespace for ACME (urn:ietf:params:acme) I don't see how this specifies that this registry is connected with the the registry (ACME Error Types, section 9.7.3) which provides the final component of "urn:ietf:params:acme:*" URNs. I suspect you want the "Repository" datum in this section to state that it points to the registry created per section 9.7.3. 9.7. New Registries Is there a registry for fields in authorization objects? 9.7.4. Resource Types Are there entries for "new-nonce" and "new-authz"? [END] From nobody Wed Oct 25 01:41: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 1BFD913ADBD for ; Wed, 25 Oct 2017 01:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.006 X-Spam-Level: * X-Spam-Status: No, score=1.006 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] 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 BZ8DI0rsnw03 for ; Wed, 25 Oct 2017 01:41:05 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 6583B139680 for ; Wed, 25 Oct 2017 01:41:02 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id r196so321876wmf.2 for ; Wed, 25 Oct 2017 01:41:02 -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=kFMniRx7VoEPakEIEY6U00j9z29qR/7BOaTFp+ovYuA=; b=T0rN+U3uNTdcWMMvO89iNxhyv7vcDVwD/RpPnK98yRMvku+kKUEvwFXe+aKCSwXKVg zcfSukFH0snkbvnNQpG2N+NWUQ4HlN3VbcGs+9ltoXQpuSUmGgai/iqx3tQGZDeS/DiC V1eyWHUEelGd0LlUpNUsfM9vW+fKQXS+H8/8oef08rfyStK1leZG9aYt/PqKWAvj1TgE LaCfrn1w/LSAL/GqKyguMAtkYbDSTyA3Dl7RP6rbDVaiIvMvfCZrG5HcYcW6I+9Jbxwm aTyr++YhSXXInusE+L6FulcOuhTndcZrSso+8h/mZ6mbZsB/YBxbtL4xknfekfe/uEA1 olew== 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=kFMniRx7VoEPakEIEY6U00j9z29qR/7BOaTFp+ovYuA=; b=ew9WYzVoAweE+4GdrEUOwbN/zPGAy7zMqmZ91/IyrGFM/hcUKr0il2cw6Q5uTItlhC rNiOu2JuxVwysaUWDPA1TTqO/hg4V1dEw32fgA6sRtV3iP7zQ0pm1Stzcj6iCXGZbTIM 69IOcNCpjSMgHADLZBX98OFYJ3f58OvLjluaVGnVKb+sfz4vTuNz/5IteDllPaEwS2jN +KMv9wW4YrHIZOZExfjVPuNKpju7KthEfTVpQeB0jexBxMAn2D1OdwKG8fyG/xDfFdUJ zJYkqx5LF0qOqREPCrii/h4z3ZAfeov85xpyTT1kD//vU+KRNuCHC4UVTNX1es5E6dOu F1ng== X-Gm-Message-State: AMCzsaV/dDE4BaG4ZcjQQES3kptDcw1/PArg6rVmEvxFcjL33XlgQoQZ iKcUVU4hlyNsr29q2rWbNzvELdfsR7PwEA6pw98= X-Google-Smtp-Source: ABhQp+Sg8PJaGSWSKdNBj/EXI50wly+DVNkdWwUd+Apn6N1FUFm+Tv09P8X2J5qDuYcgkcw0oTL8MnWUlRdmN3un5WI= X-Received: by 10.28.19.130 with SMTP id 124mr938914wmt.108.1508920860313; Wed, 25 Oct 2017 01:41:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.107.212 with HTTP; Wed, 25 Oct 2017 01:40:39 -0700 (PDT) From: Prasheel Soni Date: Wed, 25 Oct 2017 14:10:39 +0530 Message-ID: To: Acme@ietf.org Content-Type: multipart/alternative; boundary="001a11469c62df8d2a055c5b0309" Archived-At: Subject: [Acme] 'new-order' Implementation in node.js 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, 25 Oct 2017 08:41:07 -0000 --001a11469c62df8d2a055c5b0309 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Devs, I recently tried to implement the 'new-order' process in Node.JS and came across several confusions which are required to be cleared before we can move on: 1. Are authorization resources created only when a new-order request comes to the server or they are stored in the database and returned when a new-order request id encountered? 2. If the resources are created in runtime, then how do I proceed? Should I first create challenge resources in challenges table and then create authorization resources or vice-versa? 3. Is it defined or mentioned somewhere that how many authorizations should be sent to a client in response to a new-order request? 4. Is it defined or mentioned somewhere that how many challenges should be there in an authorization and what should be their types? 5. Do we consider an authorization as valid when the client validates even one of the challenges sent to him? I have just started to study ACME and thought to implement it. Any help on any of these questions will be really appreciable and helpful. Thanks in advance!! Regards *Prasheel* =E2=80=8C --001a11469c62df8d2a055c5b0309 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=3D""Hi Devs,

<= div>I recently tried to implement the 'new-order' process in Node.J= S and came across several confusions which are required to be cleared befor= e we can move on:

1. Are authorization resources c= reated only when a new-order request comes to the server or they are stored= in the database and returned when a new-order request id encountered?

2.=C2=A0 If the resources are created in runtime, then= how do I proceed? Should I first create challenge resources in challenges = table and then create authorization resources or vice-versa?

=
3. Is it defined or mentioned somewhere that how many authorizat= ions should be sent to a client in response to a new-order request?

4. Is it defined or mentioned somewhere that how many cha= llenges should be there in an authorization and what should be their types?=

5. Do we consider an authorization as valid when = the client validates even one of the challenges sent to him?

=
I have just started to study ACME and thought to implement it. A= ny help on any of these questions will be really appreciable and helpful.= =C2=A0

Thanks in advance!!

Regards
<= div dir=3D"ltr">
Prasheel



=E2=80=8C --001a11469c62df8d2a055c5b0309-- From nobody Wed Oct 25 03:00: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 19A2013AE04 for ; Wed, 25 Oct 2017 03:00:17 -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=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 q2DnjJWBwxnV for ; Wed, 25 Oct 2017 03:00:15 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::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 B47F213B13C for ; Wed, 25 Oct 2017 03:00:13 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id u138so759349wmu.4 for ; Wed, 25 Oct 2017 03:00:13 -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=2educA+fKTEzE4N67j0/3cJFQ+scmO0Pn8MssdQChhw=; b=gfp55BjkiWJ3vVO9/n3YatZ4ZA+xDPyjy0Mj6euIBWwVqGW6ODhQLfRltBto1pwh28 AbNZ9p0bxfhJEJsp/MgfKLXgGzhc8ihkhet9cUySQL7rNUzYL0OU/DeqNeUzp4DKR70P iAk6/QTy42wAviCmOb3CWPBCXejAozbqoYAKAcQz8LA9Y2gGiBoPjTYRDZiB+6lCGhY1 InlaeZYUR4+MWkYvOcsJhVmvG+ukwm+vJ1hm5CsVdriKJeQy06H8JyBH4g1Y8pjJ5Kmx NQ/RpR6arRWRHa7o30gQpD+O0CVD0Xu/W9bltb/vmO5GQTDITO5RdtcUCm6Cp2ZsGPqB QzEg== 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=2educA+fKTEzE4N67j0/3cJFQ+scmO0Pn8MssdQChhw=; b=dJ36lPpDymkSBFyvJAoXvUEwIxCtwQKj+PuQVg5+DIMURI3IN3i0ri0afP+anQGsAK 3eRxbzEuRygewlROHZvRgDpdSURoWqYLdAy/crBx73Ju2IMZ4aDzViz32c8fNvonlHXk AQje5Cfahw1uTG7SJ7VouSOv/fwT3wM3U21ANX4vzA09+iV5ivYwNH0A8q9GYZ9ZG0cg 15wOrBCrdVoW7gQQhvvWcJmUviq9uWgp5FpC3TVmTi9IvNhpjmmEuqX/ldPniylus3hl Y9EQw3z/NRodHKB/cYA/sgasoEJ6RobzXkfS7sHIo8zdpGFZpaP35ngap8mnxi8aMG38 wAGg== X-Gm-Message-State: AMCzsaXuMI9YtRZQjaWlqeATMwOIqyF+M5E1I4hOEYY5LD7zpTIyPOjF amM8qsuY02kzDwvgJYLRftflNu+984WvfslIxXqz8Q== X-Google-Smtp-Source: ABhQp+RoYxIF2F/lCmdejDQABA00sVCyaiO+/dGxTX4H+eKlWCTgUzvncw7eEupe3ZruePRvUXYXKLQmWClQps6Ry6g= X-Received: by 10.28.69.91 with SMTP id s88mr1207363wma.19.1508925612050; Wed, 25 Oct 2017 03:00:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Wed, 25 Oct 2017 03:00:11 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Wed, 25 Oct 2017 06:00:11 -0400 Message-ID: To: Prasheel Soni Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0723a619613d055c5c1fd9" Archived-At: Subject: Re: [Acme] 'new-order' Implementation in node.js 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, 25 Oct 2017 10:00:17 -0000 --94eb2c0723a619613d055c5c1fd9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 25, 2017 at 4:40 AM, Prasheel Soni wrote: > Hi Devs, > > I recently tried to implement the 'new-order' process in Node.JS and came > across several confusions which are required to be cleared before we can > move on: > Hi Prasheel, In case it's helpful, here's my node.js implementation of an earlier draft of ACME: https://github.com/bifurcation/rocket-skates You can also look at the Go implementation that Let's Encrypt is working on= : https://github.com/letsencrypt/pebble > 1. Are authorization resources created only when a new-order request come= s > to the server or they are stored in the database and returned when a > new-order request id encountered? > You're going to want to store them in a database either way. If you're going to support new-order, you should be prepared to create authorizations in response to a new-order request. > 2. If the resources are created in runtime, then how do I proceed? Shoul= d > I first create challenge resources in challenges table and then create > authorization resources or vice-versa? > That's up to your internal architecture. You should ensure that each challenge is associated to a a unique authorization. > 3. Is it defined or mentioned somewhere that how many authorizations > should be sent to a client in response to a new-order request? > That's up to the server's policy. Typically, there would be one authorization per identifier in the CSR. > 4. Is it defined or mentioned somewhere that how many challenges should b= e > there in an authorization and what should be their types? > That's up to the server's policy. Typically, the server offers whatever challenges it considers to be sufficient to prove authorization. > 5. Do we consider an authorization as valid when the client validates eve= n > one of the challenges sent to him? > Yes. "... a server should consider any one of the challenges sufficient to make the authorization valid" https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html#rfc.section.7= .1.4 > I have just started to study ACME and thought to implement it. Any help o= n > any of these questions will be really appreciable and helpful. > Good luck! --Richard > > Thanks in advance!! > > Regards > *Prasheel* > > > > =E2=80=8C > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --94eb2c0723a619613d055c5c1fd9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Oct 25, 2017 at 4:40 AM, Prasheel Soni <prasheelsoni11@= gmail.com> wrote:
3D""Hi Dev= s,

I recently tried to implement the 'new-order'= process in Node.JS and came across several confusions which are required t= o be cleared before we can move on:

=
Hi Prasheel,

In case it's helpful, here&#= 39;s my node.js implementation of an earlier draft of ACME:

<= /div>

You c= an also look at the Go implementation that Let's Encrypt is working on:=


=C2= =A0
1. Are authorization resources created only when a new-order request = comes to the server or they are stored in the database and returned when a = new-order request id encountered?

You're going to want to store them in a database either way.=C2=A0 I= f you're going to support new-order, you should be prepared to create a= uthorizations in response to a new-order request.

<= div>=C2=A0
2.=C2=A0 If the resources are created in runtime, then how do= I proceed? Should I first create challenge resources in challenges table a= nd then create authorization resources or vice-versa?

That's up to your internal architecture.=C2=A0 Y= ou should ensure that each challenge is associated to a a unique authorizat= ion.

=C2=A0
3. Is it defined or mentioned so= mewhere that how many authorizations should be sent to a client in response= to a new-order request?

That&#= 39;s up to the server's policy.=C2=A0 Typically, there would be one aut= horization per identifier in the CSR.

=C2=A0
4. Is it defined or mentioned somewhere that how many challenges should be= there in an authorization and what should be their types?

That's up to the server's policy.=C2=A0= Typically, the server offers whatever challenges it considers to be suffic= ient to prove authorization.

=C2=A0
5. Do we= consider an authorization as valid when the client validates even one of t= he challenges sent to him?

Yes.= =C2=A0 "... a server should consider any one of the challenges suffici= ent to make the authorization valid"

=C2=A0


= I have just started to study ACME and thought to implement it. Any help on = any of these questions will be really appreciable and helpful.=C2=A0
<= /div>

Good luck!
--Richard
<= div>

=C2=A0

Thanks in advance= !!

Regards
Prasheel<= /font>



=E2=80=8C

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


--94eb2c0723a619613d055c5c1fd9-- From nobody Wed Oct 25 03:04: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 9F96F13ADBD for ; Wed, 25 Oct 2017 03:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 liw-von1YlcS for ; Wed, 25 Oct 2017 03:04:06 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 4F944139680 for ; Wed, 25 Oct 2017 03:04:06 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id r196so804471wmf.2 for ; Wed, 25 Oct 2017 03:04:06 -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=CFW+ya0mcY6dYi6pvag+UMc24/WWcVDxCpYUCjkBCuU=; b=Ua2E50BudqceqTJhlo7E8jcwnV11imGIrzOLRiWhI20Nr11uAJZCAD8XPxLsPNPFJt xQ/AzQ2pw8UA9r/Mdi0i+bKY5b2A2XJBiDBLAoQYLy5ZXe/QYwxNx9aI4Yueh6izZs3E zTGmxNd/6o63A6rwai9NVZcwcnwA6T9Yuqou8XROf3K0CwVS44+kGH00wBpYgjaUZjZq 56ilWS6Mqzv6FdxvlWBRyL1TMOkp0JRNLH3aU5W12nk/enyzzLPdeWNO1MbhmICIY1et q6Pz5HPr2Va1AU9lnqUAsVT2n3M8yCJNLuMmiWfEqWWfvzslwzobTzUNgB+ks0wa80To +4HA== 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=CFW+ya0mcY6dYi6pvag+UMc24/WWcVDxCpYUCjkBCuU=; b=fH2gMj6/MRZltfr+ZmILqKMS1/3I53P5pNgadjF9u9VF9nH9DPnQ5Gx9CB3dp1skyc 3xHhO8Vs61XYRAX+pYRImMw6A8wFpmcQOy6vbLUuxdXhvOZCRsK/508Se7u0GoROZ1pw 3EBpxPnZwca0IQ/slPGKwW4NJb0jAZVcUMwoBzGG0Xcuqb88wbv13DsY/RCwHZDV8YgT T/Jo0eniM+1rIao+L+b52jVHPGUcdShrQNDGkli9hs+5gjY5R/ICyT+3mOqdNbfTLe4w Uuh1MqH22tBqvc6ahVsUKa5NwoBrjHVxJEhC9FAkqvMWdz3jTf7oGAra/tgTilAmtOjg YfLg== X-Gm-Message-State: AMCzsaUHvRS4GhER4EWKpYGOlMfLW+BUYZRq48FbK3o8zC2D6qc/UGsd K2XUsGjuPVuBnv+A10VfwJgOUnger9SgYY9oj/U= X-Google-Smtp-Source: ABhQp+R373ZJJV/BUVXW8LU9mHPYN0R1WEjlUIOJsJAcPNF54H25cQkNfyqL1Gg5w1DTKGChRW9X/lAlwL3On9Rlk68= X-Received: by 10.28.239.2 with SMTP id n2mr1120296wmh.140.1508925844688; Wed, 25 Oct 2017 03:04:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.107.212 with HTTP; Wed, 25 Oct 2017 03:04:03 -0700 (PDT) Received: by 10.28.107.212 with HTTP; Wed, 25 Oct 2017 03:04:03 -0700 (PDT) In-Reply-To: References: From: Prasheel Soni Date: Wed, 25 Oct 2017 15:34:03 +0530 Message-ID: To: Richard Barnes Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="089e082fffc4f715a9055c5c2c91" Archived-At: Subject: Re: [Acme] 'new-order' Implementation in node.js 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, 25 Oct 2017 10:04:14 -0000 --089e082fffc4f715a9055c5c2c91 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the quick response Richard. This will help me a lot in the implementation. On 25-Oct-2017 3:30 PM, "Richard Barnes" wrote: > > > On Wed, Oct 25, 2017 at 4:40 AM, Prasheel Soni > wrote: > >> Hi Devs, >> >> I recently tried to implement the 'new-order' process in Node.JS and cam= e >> across several confusions which are required to be cleared before we can >> move on: >> > > Hi Prasheel, > > In case it's helpful, here's my node.js implementation of an earlier draf= t > of ACME: > > https://github.com/bifurcation/rocket-skates > > You can also look at the Go implementation that Let's Encrypt is working > on: > > https://github.com/letsencrypt/pebble > > > >> 1. Are authorization resources created only when a new-order request >> comes to the server or they are stored in the database and returned when= a >> new-order request id encountered? >> > > You're going to want to store them in a database either way. If you're > going to support new-order, you should be prepared to create authorizatio= ns > in response to a new-order request. > > > >> 2. If the resources are created in runtime, then how do I proceed? >> Should I first create challenge resources in challenges table and then >> create authorization resources or vice-versa? >> > > That's up to your internal architecture. You should ensure that each > challenge is associated to a a unique authorization. > > > >> 3. Is it defined or mentioned somewhere that how many authorizations >> should be sent to a client in response to a new-order request? >> > > That's up to the server's policy. Typically, there would be one > authorization per identifier in the CSR. > > > >> 4. Is it defined or mentioned somewhere that how many challenges should >> be there in an authorization and what should be their types? >> > > That's up to the server's policy. Typically, the server offers whatever > challenges it considers to be sufficient to prove authorization. > > > >> 5. Do we consider an authorization as valid when the client validates >> even one of the challenges sent to him? >> > > Yes. "... a server should consider any one of the challenges sufficient > to make the authorization valid" > > https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme. > html#rfc.section.7.1.4 > > > >> I have just started to study ACME and thought to implement it. Any help >> on any of these questions will be really appreciable and helpful. >> > > Good luck! > --Richard > > > > >> >> Thanks in advance!! >> >> Regards >> *Prasheel* >> >> >> >> =E2=80=8C >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> >> > --089e082fffc4f715a9055c5c2c91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the quick response Richard. This will help me = a lot in the implementation.=C2=A0

On 25-Oct-2017 3:30 PM, "Richard Barnes" &= lt;rlb@ipv.sx> wrote:


On Wed, Oct 25, 2017 at 4:40 AM, Prasheel Soni &= lt;prasheelso= ni11@gmail.com> wrote:
3D""Hi Devs,

I recently tried to impleme= nt the 'new-order' process in Node.JS and came across several confu= sions which are required to be cleared before we can move on:

Hi Prasheel,

In cas= e it's helpful, here's my node.js implementation of an earlier draf= t of ACME:


You can also look at the Go imp= lementation that Let's Encrypt is working on:


=C2=A0=
1. Are authorization resources created only when a new-order request com= es to the server or they are stored in the database and returned when a new= -order request id encountered?

= You're going to want to store them in a database either way.=C2=A0 If y= ou're going to support new-order, you should be prepared to create auth= orizations in response to a new-order request.

=C2=A0
2.=C2=A0 If the resources are created in runtime, then how do I p= roceed? Should I first create challenge resources in challenges table and t= hen create authorization resources or vice-versa?
<= div>
That's up to your internal architecture.=C2=A0 You s= hould ensure that each challenge is associated to a a unique authorization.=

=C2=A0
3. Is it defined or mentioned somewh= ere that how many authorizations should be sent to a client in response to = a new-order request?

That's= up to the server's policy.=C2=A0 Typically, there would be one authori= zation per identifier in the CSR.

=C2=A0
=
4. = Is it defined or mentioned somewhere that how many challenges should be the= re in an authorization and what should be their types?

That's up to the server's policy.=C2=A0 Typ= ically, the server offers whatever challenges it considers to be sufficient= to prove authorization.

=C2=A0
5. Do we con= sider an authorization as valid when the client validates even one of the c= hallenges sent to him?

Yes.=C2= =A0 "... a server should consider any one of the challenges sufficient= to make the authorization valid"

=C2=A0


I have just started to study ACME and thought to i= mplement it. Any help on any of these questions will be really appreciable = and helpful.=C2=A0

Good luck!
--Richard


=C2=A0

Thanks in advance!!

Regards
= Prasheel



=E2=80=8C

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


--089e082fffc4f715a9055c5c2c91-- From nobody Wed Oct 25 13:18: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 10BBC139F5C for ; Wed, 25 Oct 2017 13:18:23 -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 VaBTmYIwcaZn for ; Wed, 25 Oct 2017 13:18:21 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 DF1931398C7 for ; Wed, 25 Oct 2017 13:18:20 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id y15so2606316ita.4 for ; Wed, 25 Oct 2017 13:18:20 -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=ZH+q4QhFt2qJ1LD/NyCFMiDvfqfBJyD6XilwZfOaRlM=; b=HT3DunmodAdfXMelsaZMU0quTH0/h3UvAvNdHySj3iv5eQ8N16cnb6KQ3qIKRfDtje pZft0++IXO6lGIeak3ulHD1IiHwcTUgprxa9wmXSki44s7RwQJ3XwekM7scegXWEaC/8 L8GMD1wJZy9PZgDHfktY5Cb1lovlIVUAeZcmSXhoSQFwhXcnnL/P+ORU90PzQ1EJ1HvC ofIjwH0rd/pL0JFzMfr+8Q+EWY7E5WIRTML6SxvJrX93bIMqozuV6fkoSfaHxdWPzUIn lHLBnhICQn31CjJdbFpju+bHDdkaoXOjzGVMr6s6OKwRvcoNV4hJi0FslfNBXXUY92N4 Bfqw== 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=ZH+q4QhFt2qJ1LD/NyCFMiDvfqfBJyD6XilwZfOaRlM=; b=Vg2+Ot8oloxe7yw133WdUgi9LjKjeUMTcOn+SoZEzwExuokxmProMTuwq4PyVe2Gjv lTN/+8r9mOZFapPFyLMlgMCPqN9M+pUwmrOmpmUghgWPCAz1lpjd8HTO686R8TKdkdOS cvrpj4R2LHxabnbUxgrM27rf9ufHUwnKoKRvYqYmUscmPdYQcXmcKCqNVmrFOkwKPnSD qU+45CgaUjrJ7AwwRtDo/DqiCwmYv6vR+OHywhWQ1kARfGjW4eQkbD9WyD3I6Af+TfZl 7m9qYMDb5tgq5GIJoYVUT+9I1A/T+umv+Ho4TKdVRjQmZ8ZBPACznHMAklGz0S6qB6Nr Sgjg== X-Gm-Message-State: AMCzsaWoM1pkdV3ug4YuoNHBRHI1KvLrn3z8Q5g4xZArSkcLMT4N6ri5 bBnfY3ihZkYnEeRpzDmsviiTmKBfKlXaNWNmd2k= X-Google-Smtp-Source: ABhQp+T9Dbh7lsnXV/japRQZ0sGYDhWo+rtn+DfvfSQZZaXxbGNPmzw1wi9P+ZOArEHTujIUQOofcWjrlT8NfTadlsQ= X-Received: by 10.36.46.4 with SMTP id i4mr3899592ita.145.1508962699909; Wed, 25 Oct 2017 13:18:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.153.151 with HTTP; Wed, 25 Oct 2017 13:18:19 -0700 (PDT) From: Logan Widick Date: Wed, 25 Oct 2017 15:18:19 -0500 Message-ID: To: ACME WG Content-Type: multipart/alternative; boundary="001a114aa374b5212a055c64c1d3" Archived-At: Subject: [Acme] Allowable "tel" contacts; publishing allowed contact schemes and their ACME-specific restrictions 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, 25 Oct 2017 20:18:23 -0000 --001a114aa374b5212a055c64c1d3 Content-Type: text/plain; charset="UTF-8" This is related to my previous "Allowable mailto contacts" thread earlier this month. However, this is about a different type of contact, so I decided to start a new thread. Although ACME servers don't have to include support for "tel" (RFC 3966) contacts, "tel" contacts appear in multiple examples in the ACME specification. Thus, some may try to include "tel" contact support in their ACME server implementations. Although the example "tel" contacts in the ACME specification seem to indicate a simple, narrow subset (the "global-number" with zero "par" instances), the "tel" specification has many more possible productions. For example, both "global-number" and "local-number" may have "par" instances (like ";name1=value1;name2=value2") after the phone numbers. Assuming I understand the "local-number" specification correctly, a "local-number" could potentially contain a pound sign ("#") for reasons related to DTMF. If I understand the current and past URI specifications correctly, this could be problematic. Specifically, a URI parser may put the parts of the "local-number" after a "#" in the fragment. If someone wanted to implement "tel" contact support for an ACME server, what subset of "tel" would be required? Would both "global-number" and "local-number" instances be allowed? What restrictions would apply to "global-number" and "local-number" instances? Which types of "par" instances would be allowed? Extension? ISDN-subaddress? Others? On a more general note, I think that as ACME becomes more widely used, the subject of what subsets of what contact URI schemes would be allowed under ACME (as opposed to what schemes are supported by a specific ACME server, which was a separate issue already discussed in March on the mailing list under "Allowing clients to understand the account creation functionality supported by a server") may come up more often. Would it be a good idea to request the creation of an "ACME Contact Schemes Registry" like in the ASCII art figures below? +--------+-----------+-----------+-------------------------- -------------------+ | Scheme | Status | Reference | ACME Restrictions | +--------+-----------+-----------+-------------------------- -------------------+ | mailto | Mandatory | RFC 6068 | Exactly one "addr-spec" in the "to" portion | | | | | No "hfields" are allowed | | | | | [Source: "Allowable mailto contacts" thread]| +--------+-----------+-----------+-------------------------- -------------------+ | tel | Optional | RFC 3966 | [insert restrictions picked in this thread] | +--------+-----------+-----------+-------------------------- -------------------+ Figure 1: A possible "ACME Contact Schemes Registry" table. In this version, the ACME restrictions on the original contact scheme specifications are stated in the table, and the original contact scheme specification is listed as the "Reference". These relationships are depicted graphically in Figure 2 (below). +-----------------------+ +--------------------+ | RFC 6068 (mailto RFC) | | RFC 3966 (tel RFC) | +-----------------------+ +--------------------+ Figure 2: RFC relationships for Figure 1 +--------+-----------+---------------------------+ | Scheme | Status | Reference | +--------+-----------+---------------------------+ | mailto | Mandatory | RFC XXXX | | | | (ACME RFC) | | | | | +--------+-----------+---------------------------+ | tel | Optional | RFC YYYY | | | | (Some RFC after RFC XXXX) | +--------+-----------+---------------------------+ Figure 3: Another possible "ACME Contact Schemes Registry" table. In this version, the "Reference" RFCs discuss the ACME-specific restrictions for the contact schemes, and refer to the original specifications for the contact schemes. These relationships are depicted graphically in Figure 4 (below). +-----------------------------+ | ACME restrictions on mailto | +----------+------------------+ ^ | | Contains | +----------+----------+ +--------------+ | RFC XXXX (ACME RFC) | References | RFC 6068 | + +----------------> + (mailto RFC) | | | | | +----------+----------+ +--------------+ ^ | | References | +----------+-------------------+ +-----------+ | RFC YYYY | References | RFC 3966 | + (An RFC after RFC XXXX) +----------------> + (tel RFC) | | | | | +----------+-------------------+ +-----------+ ^ | | Contained in | +----------+------------------+ | ACME Restrictions on tel | +-----------------------------+ Figure 4: RFC relationships for Figure 3 version of "ACME Contact Schemes Registry" --001a114aa374b5212a055c64c1d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is related to my = previous "Allowable mailto contacts" thread earlier this month. H= owever, this is about a different type of contact, so I decided to start a = new thread.

Although ACME servers don't have to include support = for "tel" (RFC 3966) contacts, "tel" contacts appear in= multiple examples in the ACME specification. Thus, some may try to include= "tel" contact support in their ACME server implementations.
<= br>Although the example "tel" contacts in the ACME specification = seem to indicate a simple, narrow subset (the "global-number" wit= h zero "par" instances), the "tel" specification has ma= ny more possible productions. For example, both "global-number" a= nd "local-number" may have "par" instances (like "= ;name1=3Dvalue1;name2=3Dvalue2") after the phone numbers.

Assum= ing I understand the "local-number" specification correctly, a &q= uot;local-number" could potentially contain a pound sign ("#"= ;) for reasons related to DTMF. If I understand the current and past URI sp= ecifications correctly, this could be problematic. Specifically, a URI pars= er may put the parts of the "local-number" after a "#" = in the fragment.=C2=A0

If someone wanted to implement "tel"= ; contact support for an ACME server, what subset of "tel" would = be required? Would both "global-number" and "local-number&qu= ot; instances be allowed? What restrictions would apply to "global-num= ber" and "local-number" instances? Which types of "par&= quot; instances would be allowed? Extension? ISDN-subaddress? Others?
On a more general note, I think that as ACME becomes more widely used, th= e subject of what subsets of what contact URI schemes would be allowed unde= r ACME (as opposed to what schemes are supported by a specific ACME server,= which was a separate issue already discussed in March on the mailing list = under "Allowing clients to understand the account creation functionali= ty supported by a server") may come up more often. Would it be a good = idea to request the creation of an "ACME Contact Schemes Registry"= ; like in the ASCII art figures below?=C2=A0




+--------+-= ----------+-----------+------------------------------------------= ---+
| Scheme | Status =C2=A0 =C2=A0| Reference | ACME Restrictions=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
+--------+-----------+-----------+-----------= ----------------------------------+
| mailto | Mandatory | RFC 6068= =C2=A0| Exactly one "addr-spec" in the "to" portion |<= br>| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | No "hfields" are allowed=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ||=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| [Source: "Allowable mailto contacts" thread]|
+--------+-= ----------+-----------+------------------------------------------= ---+
| tel =C2=A0 =C2=A0| Optional =C2=A0| RFC 3966 =C2=A0| [insert rest= rictions picked in this thread] |
+--------+-----------+-----------= +---------------------------------------------+
<= font face=3D"monospace, monospace">
Figure 1: A possible "ACME Contact Schemes Registry&= quot; table.=C2=A0In= this version, the ACME restrictions=C2=A0on the original contact scheme specifications are sta= ted in the table,=C2=A0and the original contact scheme specification is listed as the "Ref= erence". These relationships are depicted graphically in Figure 2 (bel= ow).=C2=A0 =C2=A0

=



+-----------------------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 +------------------= --+
| RFC 6068 (mailto= RFC) |=C2=A0 =C2=A0 =C2=A0 =C2=A0 | RFC 3966 (tel RFC) |=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
+-----------------------+=C2=A0 =C2=A0 =C2=A0= =C2=A0 +--------------------+

Fig= ure 2: RFC relationships for Figure 1



<= /div>

+--------+-----------+-------------------= --------+
| Scheme | Status =C2=A0 =C2=A0| Reference=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+--------+-----------+------= ---------------------+
| mailto | Mandatory | RFC XXXX=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0
| =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | (ACME RFC)=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+--------+--------= ---+---------------------------+
| tel =C2=A0 =C2=A0| Optional =C2= =A0| RFC YYYY=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= |
|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| (Some RFC after RFC = XXXX) |=C2=A0
+--------+-----------+---------------------------+

<= div>Figure 3: Another possible "AC= ME Contact Schemes Registry" table.=C2=A0In this version, the "Reference" RFCs d= iscuss=C2=A0the ACME= -specific restrictions for the contact schemes,=C2=A0and refer to the original specifications f= or the contact schemes. These relationships are depicted graphically in Fig= ure 4 (below).=C2=A0
<= br>

<= div>

+-----------------------------+
| ACME restrictions on mailto |
+----------+------------------+<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0^
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Contains
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
+---------= -+----------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= +--------------+
| RF= C XXXX (ACME RFC) |=C2=A0 =C2=A0 References=C2=A0 =C2=A0 | RFC 6068=C2=A0 = =C2=A0 =C2=A0|
+=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+----= ------------> +=C2=A0(mailto RFC)=C2=A0|=C2=A0
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+----------+----------+= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0+------= --------+
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| References
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+----------+-------------------+=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------+
| RFC YYYY=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 R= eferences=C2=A0 =C2=A0 | RFC 3966=C2=A0=C2=A0|
+=C2=A0(An RFC after RFC XXXX)=C2=A0 =C2=A0 =C2= =A0 +----------------> +=C2=A0(tel RFC)=C2=A0|=C2=A0
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|
+----------+-------------------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0+-----------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Contained in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= |
+----------+--------= ----------+
| ACM= E Restrictions on tel=C2=A0 =C2=A0 |
+-----------------------------+
=
Figure 4: RFC relationships for Figure 3 version of &quo= t;ACME Contact Schemes Registry"
--001a114aa374b5212a055c64c1d3-- From nobody Wed Oct 25 23:30: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 C458B13AB66 for ; Wed, 25 Oct 2017 23:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_IMAGE_ONLY_32=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 64P7h_mzdgVA for ; Wed, 25 Oct 2017 23:30:25 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c: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 0341F13A0AA for ; Wed, 25 Oct 2017 23:30:25 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id y83so663574wmc.4 for ; Wed, 25 Oct 2017 23:30: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=fMGH3r3Bg0a+kg6sPdAIxToeD/EetcAoGYS2u2Ka9bs=; b=kxcFJsHIdyofb0vbvC0ks1AIdawzVwdD7tZ3ajE9isWUoAb4+FIE5ylm+nI6keuS3s eQDnTjof4N1P+ZrzJhjwMPW4ylyo3yFmBrsiZIXvJoVhbO50HejPdD5tXgRhUJQobQ3F nah5Ly2eMtZYLPUlk1DG6vCmKFgUm8ne6QRM4iedB4ef3Oz/cNE9LpGNsW8sYzGyM8uF pLbj42578QG4ATWViU6qEbVu83RxwBZetEOgyYGmLr1OzlTkHC0xqBeHOGezIA4PD9r9 2TaW8VGrliWVX0LMPNGhOaQlpc1LCv8H7yrLvHL/lS+WTOkmwkJcLVr4cQpfLAj9Wptu lMUw== 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=fMGH3r3Bg0a+kg6sPdAIxToeD/EetcAoGYS2u2Ka9bs=; b=KdTTgFEuWd8LHYY7nI6m0E1CHDIbeMvr1e5yAFd0hf0ly+skY7Te7zBAwtTAq//qlI +5WGlgCokKeT6mTwXMIDHklHGs9SrbEFKSmRDLY6/9/PCZ3FKY6GwAkeSy2M26eZNwp6 VImAQIO0ppeSYaKummIWHs8/xd3v0cWjQOo4RK90bDP5ltB3WfkzMuJGoaSGqzK5ki/6 c0DtNkZ04a2/eTqcawz+qPcqdBu6R28zO3tQdkAmCTR/FVAhOgmqsMg7EX4XGQyDtpnr mktFLK8Eu9cZ/s49FplAScKuoj1YnV/8S1NIz4xdObX1rMpLy39qSchoIkNhI+/8hgx9 wztw== X-Gm-Message-State: AMCzsaXrfrgJIyNvO8iM7af81X54tWbOZnXgrDMoD+Sp21Ct0OiqabKo ZTYpVGADZgyBDtKW9ePG7P/H7LofmVMy3ACkxE8zXQ== X-Google-Smtp-Source: ABhQp+S3XPFEO5YdbokM9MAVrtIrjplTU0RKUI4QdThh/iZNntNQCoSq6Zv/BnWyttac+vU9QJQePgASfwvUvESHHvI= X-Received: by 10.28.239.2 with SMTP id n2mr493580wmh.140.1508999423201; Wed, 25 Oct 2017 23:30:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.107.212 with HTTP; Wed, 25 Oct 2017 23:30:02 -0700 (PDT) From: Prasheel Soni Date: Thu, 26 Oct 2017 12:00:02 +0530 Message-ID: To: "acme@ietf.org" Content-Type: multipart/alternative; boundary="089e082fffc496160a055c6d4eb3" Archived-At: Subject: [Acme] [QUESTION] Implementation of 'new-order' 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, 26 Oct 2017 06:30:27 -0000 --089e082fffc496160a055c6d4eb3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Devs, I am facing an issue while implementing the ACME. I am trying to create new-order endpoint which should provide the order object with the list of authorizations in response. So, I need to create the record in authorization entity and further in challenges entity. I have set the primary key(id) of authorization and challenges to autoIncrement. I am facing the issue that for creating an order I need to first insert a record in order entity leaving the authorizations field data empty. Then further I need to create a record in authorization entity which will provide me with the id (primary key) and this id is required to create authorization's URL. so should I remove authorization id (PK) from autoincrement and generate it randomly? Thanks in advance!! Regards *Prasheel* =E2=80=8C --089e082fffc496160a055c6d4eb3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=3D""

Hi Devs,

I am facing an issue while implementing the ACME. I am trying = to create new-order endpoint which should provide the order object with the= list of authorizations in response.

So, I need to create the record in authorization entity and further in cha= llenges entity.

I have set the primar= y key(id) of authorization and challenges to autoIncrement.

I am facing the issue that for creating an order I n= eed to first insert a record in order entity leaving the authorizations fie= ld data empty. Then further I need to create a=C2=A0record in authorization= entity which will provide me with the id (primary key) and this id is requ= ired to create authorization's URL.

so should I remove authorization id (PK) from autoincrement and generate= it randomly?

Thanks in advance!!
<= br>
Regards
=
Prasheel

=

=E2=80=8C
--089e082fffc496160a055c6d4eb3-- From nobody Fri Oct 27 14:53:01 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 4DF3713F5E1 for ; Fri, 27 Oct 2017 14:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.972 X-Spam-Level: X-Spam-Status: No, score=-3.972 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] 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 6EPwo5iibe2F for ; Fri, 27 Oct 2017 14:52:59 -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 F299013F5E0 for ; Fri, 27 Oct 2017 14:52:58 -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=o560Q6xSoKPtwBlHhkLeQl5k8eVkqXQHQKWC29UbQJ4=; b=an53Jjrd0yk0w0+xJhk1mgfKeOhLYERfMsCXXD5WyFEnPNCKU3hVzmENeuqC/hqp9JyS2urDkoVJYyYrRRHT29htV1kFAqoMLh131nElc9+5ILvlKhTrLAKT6M+ZYVxXMHdftUfYitKKPgaFSRTZ0m+Q1hmk0JKDGaG6llCAyog=; Received: ; Fri, 27 Oct 2017 14:52:54 -0700 To: Prasheel Soni , "acme@ietf.org" References: From: Jacob Hoffman-Andrews Message-ID: Date: Fri, 27 Oct 2017 14:52:56 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DB8D873778563F5785C7D09A" Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] [QUESTION] Implementation of 'new-order' 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, 27 Oct 2017 21:53:00 -0000 This is a multi-part message in MIME format. --------------DB8D873778563F5785C7D09A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 10/25/2017 11:30 PM, Prasheel Soni wrote: > I have set the primary key(id) of authorization and challenges to > autoIncrement. > > I am facing the issue that for creating an order I need to first > insert a record in order entity leaving the authorizations field data > empty. Then further I need to create a record in authorization entity > which will provide me with the id (primary key) and this id is > required to create authorization's URL. > > so should I remove authorization id (PK) from autoincrement and > generate it randomly? The approach we are taking in Boulder is to treat the relationship between orders and authorizations as a many-to-many relationship. Each order can contain many authorizations, and each authorization can be contained in many orders. We represent this as a relationship table that has one column for order id, and one column for authorization id, created after both the order and the authorizations. --------------DB8D873778563F5785C7D09A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 10/25/2017 11:30 PM, Prasheel Soni wrote:
I have set the primary key(id) of authorization and challenges to autoIncrement.

I am facing the issue that for creating an order I need to first insert a record in order entity leaving the authorizations field data empty. Then further I need to create a record in authorization entity which will provide me with the id (primary key) and this id is required to create authorization's URL.

so should I remove authorization id (PK) from autoincrement and generate it randomly?
The approach we are taking in Boulder is to treat the relationship between orders and authorizations as a many-to-many relationship. Each order can contain many authorizations, and each authorization can be contained in many orders. We represent this as a relationship table that has one column for order id, and one column for authorization id, created after both the order and the authorizations.
--------------DB8D873778563F5785C7D09A-- From nobody Fri Oct 27 22:52: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 BEFB613F7B7 for ; Fri, 27 Oct 2017 22:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 4Mqi1r8Vz7zf for ; Fri, 27 Oct 2017 22:52:11 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 94DBB13F7B5 for ; Fri, 27 Oct 2017 22:52:11 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id 131so6561100wms.0 for ; Fri, 27 Oct 2017 22:52:11 -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=ek99874Yx54la7zkRrKz/uiaj4MtmskzVkznNHm0mCA=; b=EaEaGTud9/DC33cp44KCFtKkAwoEB5OcVrjD43H5+KsPfpnsnYD4kcSLvGkqqUFYBJ srnSfofya5rAVDtegGmDjXA+a4bkPyqG2RQAcU29DGznlqBvc6C3W7znegqop/uuYlFN FCksqqFy964GKQXBvKZElWEVUmsXG8//1411CiQw0d3git++KBX/Tws+etIgoyNsbyqH y2OG6xuZGRVhzICJOatpiBkx5k0EIRjXLWRqUNsSGX39R33FyK7cgHumGYPvHN2DimJ4 w4fFxfG6kNxxA3usRqWbVYR3Sxot1JDucB92p/Fbre7jB0yuW7TyhjZWKHi3I6kovLP6 EP8Q== 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=ek99874Yx54la7zkRrKz/uiaj4MtmskzVkznNHm0mCA=; b=eK655nM8WVVcexEyPEvMQezV+wJDJ9o2FC8NkjlIDMW6CyTzHlvfsttWgEzYuvviO0 2FilO+j32p5FFUQUc8rM3/VGqdkNZZi8Y9V79npM0qjbE4RiAFu1Cz6w8+zPP4z3S9W8 22WaPu0UloxetOMCxaECA0k6twpFvcyn2Tib5gtfk+LOnln2woDUFsGa39kWcz5cBEFB beivXh1PSJQzxC5FwOOIpzPkynyzu2JlZEHGWFssAhyfVzz1G5cMxH+Zg08s9jPInEUN ed5VxUPRZIHIquEwoN4YCCenL4xZE0O1jyTSSd5CsNmsR+jeDYUH8GwKL87voOca3gYB S3Xg== X-Gm-Message-State: AMCzsaV8lSE4xYIqVHRdGEV883T8p4Xf1ACr0PiK15++NxzFxD0ksy/a fK3GrQ0cUfbRbKqr6mYk3J4FGTlsX0MmvuyumRk= X-Google-Smtp-Source: ABhQp+SoonZowc0NqBcz0a35QMN6vHZNSmKHtq+V2mX6GBYqgA9+r6bKOMdrd3W4h7Q9zGEm/G8P9NRV+L/sLxTWAbg= X-Received: by 10.28.61.213 with SMTP id k204mr1880681wma.110.1509169929999; Fri, 27 Oct 2017 22:52:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.107.212 with HTTP; Fri, 27 Oct 2017 22:51:49 -0700 (PDT) In-Reply-To: References: From: Prasheel Soni Date: Sat, 28 Oct 2017 11:21:49 +0530 Message-ID: To: Jacob Hoffman-Andrews Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a114b30fe955b40055c950122" Archived-At: Subject: Re: [Acme] [QUESTION] Implementation of 'new-order' 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, 28 Oct 2017 05:52:14 -0000 --001a114b30fe955b40055c950122 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, Jacob. I was wondering about the process flow and the schema that you followed in Boulder. I tried to go through the code on GitHub but I'm not that good at go lang, so I wasn't able to figure out much. It would be a great help if you can do that. Thanks again =E2=80=8C *Prasheel Soni* Enterprise Software Engineer HotWax Systems Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010 Cell phone: +91 94259 64489 On Sat, Oct 28, 2017 at 3:22 AM, Jacob Hoffman-Andrews wrote= : > On 10/25/2017 11:30 PM, Prasheel Soni wrote: > > I have set the primary key(id) of authorization and challenges to > autoIncrement. > > I am facing the issue that for creating an order I need to first insert a > record in order entity leaving the authorizations field data empty. Then > further I need to create a record in authorization entity which will > provide me with the id (primary key) and this id is required to create > authorization's URL. > > so should I remove authorization id (PK) from autoincrement and generate > it randomly? > > The approach we are taking in Boulder is to treat the relationship betwee= n > orders and authorizations as a many-to-many relationship. Each order can > contain many authorizations, and each authorization can be contained in > many orders. We represent this as a relationship table that has one colum= n > for order id, and one column for authorization id, created after both the > order and the authorizations. > --001a114b30fe955b40055c950122 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=3D""
Thanks, Jacob.
I= was wondering about the process flow and the schema that you followed in B= oulder. I tried to go through the code on GitHub but I'm not that good = at go lang, so I wasn't able to figure out much. It would be a great he= lp if you can do that.

Thanks again=C2=A0

<= br>=E2=80=8C

<= div class=3D"gmail_signature" data-smartmail=3D"gmail_signature">
Prasheel Soni
Enterprise Software Engineer
=
Plot no. 80, Scheme no. 78, Vija= y Nagar, Indore, M.P. India 452010
Cell phone: +91 94259 64489

On Sat, Oct 28, 2017 at 3:22 AM, Jacob Hoffm= an-Andrews <jsha@eff.org> wrote:
On 10/25/2017 11:30 PM, Prasheel Soni wrote:
I have set the primary key(id) of authorization and challenges to autoIncrement.

I am facing the issue that for creating an order I need to first insert a record in order entity leaving the authorizations field data empty. Then further I need to create a=C2=A0record in authorization entity which will provide me with the id (primary key) and this id is required to create authorization's URL.

so should I remove authorization id (PK) from autoincrement and generate it randomly?
The approach we are taking in Boulder is to treat the relationship between orders and authorizations as a many-to-many relationship. Each order can contain many authorizations, and each authorization can be contained in many orders. We represent this as a relationship table that has one column for order id, and one column for authorization id, created after both the order and the authorizations.

--001a114b30fe955b40055c950122-- From nobody Sat Oct 28 03:25:44 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 C739A13F766 for ; Sat, 28 Oct 2017 03:25:42 -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 1KE8a3eIMgPr for ; Sat, 28 Oct 2017 03:25:40 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AD8513F542 for ; Sat, 28 Oct 2017 03:25:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 722E75DE5C for ; Sat, 28 Oct 2017 13:25:37 +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-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id rB513mYLAXkQ for ; Sat, 28 Oct 2017 13:25:37 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 0126B21C for ; Sat, 28 Oct 2017 13:25:35 +0300 (EEST) Date: Sat, 28 Oct 2017 13:25:35 +0300 From: Ilari Liusvaara To: acme@ietf.org Message-ID: <20171028102535.sdjd2gtspmy3b547@LK-Perkele-VII> References: <71f3e975-7cee-18cf-2635-80eb13adff12@devever.net> <20171024141732.ufjysx5f73pyc5f4@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20171024141732.ufjysx5f73pyc5f4@LK-Perkele-VII> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR 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, 28 Oct 2017 10:25:43 -0000 On Tue, Oct 24, 2017 at 05:17:32PM +0300, Ilari Liusvaara wrote: > On Tue, Oct 24, 2017 at 02:45:01PM +0100, Hugo Landau wrote: > > > > The ACME protocol should permit CAs to implement policy as far as is > > reasonably practicable with regard to the workflows around which the > > protocol is organised. Providing the CSR up-front allows the CA to > > predicate order processing on aspects of that CSR, both with regard to > > the present protocol and any future extensions, both now and in the > > future in ways that we can and cannot foresee. I don't think it's > > appropriate to defer giving critical information to the CA until the > > last minute due to a resource utilisation concern which LE has already > > proven capable of dealing with, especially when the whole point of the > > order flow in the first place was to provide more flexibility for CAs to > > institute policy. > > Example: Suppose that CAA-PKP got added (restrict issuance on SPKI > key). Implementing that without knowing the public key at validation > time is annoying. > > As to why one would want something like that, it would allow limiting > trust on certficiate management system without deploying something as > dangerous as HPKP. > Specifically, this would be a top-level CAA property that is satisfied by certificate request having SubjectPublicKeyInfo matching at least one of the listed hashes. The contents of property consist of one or more hash=hasval pairs, where hash is a hash function (unknown ones are ignored) and hashval is base64-encoded hash of the SPKI. There is no max-age, as the restriction is not sticky and thus can be replaced quickly if needed. It can be signed using DNSSEC as usual. Example: foo.example.net IN CAA 128 pin "sha256=AIPH49+A9F1e650YMzRPJG9OkBA0F24Mwa5ru5ZmsCo=,sha256=FmbTUrJD2lBK8H501MKenwkFg+639r/x6eZp22qUd/I=" This property is satisfied only by requests containing SubjectPublicKeyInfo key with either SHA-256 hash of 0083c7e3df80f45d5eeb9d1833344f246f4e901034176e0cc1ae6bbb9666b02a or 1666d352b243da504af07e74d4c29e9f090583eeb7f6bff1e9e669db6a9477f2. The usecase is as follows: Suppose certificate management system runs with the least authority. If it gets compromised, the attacker can not aquire the private keys. However, he can abuse its authority to solve challenges for his own keypairs. The end result is attacker getting maliscous certificates he controls the private key for. The account keypair does not help, since it can be abused too. However, if the public keys one can get certificates are restricted, the attacker can not aquire useful certificates, as he can not specify his own keypairs for the certifciate, nor get the private key for any of the whitelisted keypairs. Similar attacks could be also mounted on some other least-authority components of the whole system, components that could be at even higher risk of compromise. The current solution to this usecase is the HPKP. However, HPKP is known to be difficult to deploy, quite of a footgun and worst of all is being deprecated. Expect-CT will not even begin to solve it. A partial solution would be to use CAA to restrict issuance to CAs that either do not support automation, or support "vanity CAAs" with corresponding restrictions. -Ilari From nobody Sat Oct 28 09:33:06 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 6175413FBAF; Sat, 28 Oct 2017 09:33: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.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150920838537.2709.10159050598393694926@ietfa.amsl.com> Date: Sat, 28 Oct 2017 09:33:05 -0700 Archived-At: Subject: [Acme] I-D Action: draft-ietf-acme-email-tls-01.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: Sat, 28 Oct 2017 16:33: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 WG of the IETF. Title : Extensions to Automatic Certificate Management Environment for email TLS Author : Alexey Melnikov Filename : draft-ietf-acme-email-tls-01.txt Pages : 7 Date : 2017-10-28 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-01 https://datatracker.ietf.org/doc/html/draft-ietf-acme-email-tls-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-email-tls-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 29 11:03:01 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 6D77113F400; Sun, 29 Oct 2017 11:02:59 -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.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150930017939.11200.10967750996278552667@ietfa.amsl.com> Date: Sun, 29 Oct 2017 11:02:59 -0700 Archived-At: Subject: [Acme] I-D Action: draft-ietf-acme-email-smime-01.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: Sun, 29 Oct 2017 18:02:59 -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 WG 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-01.txt Pages : 4 Date : 2017-10-29 Abstract: This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for use by email users 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-01 https://datatracker.ietf.org/doc/html/draft-ietf-acme-email-smime-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-email-smime-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 29 12:20: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 DC85B13F55A for ; Sun, 29 Oct 2017 12:20:51 -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 1rpg_2RzV9Um for ; Sun, 29 Oct 2017 12:20:50 -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 2DE1613FB33 for ; Sun, 29 Oct 2017 12:20:50 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id p96so10501409wrb.7 for ; Sun, 29 Oct 2017 12:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=J4WkkXC51NDNFSayRgfqOnpc7kyvE7GnDFeT0f+HQbk=; b=vBl7uXrJM1WsFZUWvtW7Gye36sXjuzWvNfQBQO4pf8qvRwLITGvvpbOf8TMr37QqUF nKwvRmTmF7GiAyo5y8pAYyp06u1q+7a47923KFKJOALkK+Fvxd5kjP2pAg5ToQ2mGR8c NeGB18VzhKQJWnQKWhG+kCzK8utapvRDdPDb3VOYLpOJABiJqvcfEBpFxOQyHf4pB+k5 3yCyu1drnXkSuIRGiOOOT25O3jZFJWIlOtB/JZDcgy2jC/Rw61KzTtX0zk2xAxJzpBvD manEVjhGN5m4AresHpxHt99td1M5c++MlJvOr3IXITG/+cGJ5lQ2J+AOgvwoE3zuF59I 0+9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=J4WkkXC51NDNFSayRgfqOnpc7kyvE7GnDFeT0f+HQbk=; b=dO7FxdMNhZhFqGBNWmqt5AVFC3fxGevYo2v9SR+2s8WmdwlFHxaZbVjiI+pSYqMlB9 zGmfkib8GgaT2meU2o4/sLcaxsrMaxQqhSVUrgnaTgZtK+D//u10v+pa4o9rWYdN3+IZ 5hai8O+yz/W2+jSOaQRFaTYArvBo6Kj1wXY72E122GOhMiO0W5l1ASw94q1YQrpmMVS4 JxJmKUlao/URib32AOFMORf79I3WMKvhp1FEmEHUoyiGY/imVMj/1FYIFuC50rPieCP4 B/biwvHv3H+MCdot5YSRBSqtTWNCuDre7M2lS1IJwPOK5+5fK0upev7TCVp4NgVSPNA3 mA1w== X-Gm-Message-State: AMCzsaU2D6UimZTfyb4yb2worcnCm0eyVD+dmF1Hkty3Cj4nddLb+7TW RZ5A6yHN8YR1fwbmfosZF2/wKVWF X-Google-Smtp-Source: ABhQp+QmujFmspL9bmPhKTGA8nVDhrSYcKpS+TguNVJLTWeKCclR7AuoHcGzKa7z3n11tdTq5KFELQ== X-Received: by 10.223.150.204 with SMTP id u70mr5345457wrb.115.1509304848576; Sun, 29 Oct 2017 12:20:48 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id k9sm14583580wrk.88.2017.10.29.12.20.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Oct 2017 12:20:47 -0700 (PDT) From: Yoav Nir Content-Type: multipart/signed; boundary="Apple-Mail=_C510A8F5-C4EE-4194-B0DB-AA24BA0A4A26"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Message-Id: <6B9CA7C8-E0BF-41A1-9511-F63FFE87A6ED@gmail.com> Date: Sun, 29 Oct 2017 21:20:45 +0200 To: IETF ACME X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: [Acme] Draft Agenda Uploaded 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, 29 Oct 2017 19:20:52 -0000 --Apple-Mail=_C510A8F5-C4EE-4194-B0DB-AA24BA0A4A26 Content-Type: multipart/alternative; boundary="Apple-Mail=_E7BFDD53-D2FA-4D40-9BD6-3C0635B83413" --Apple-Mail=_E7BFDD53-D2FA-4D40-9BD6-3C0635B83413 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 https://datatracker.ietf.org/meeting/100/materials/agenda-100-acme/ = If anything=E2=80=99s missing, please let us know really soon. Thanks Rich and Yoav --Apple-Mail=_E7BFDD53-D2FA-4D40-9BD6-3C0635B83413 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 https://datatracker.ietf.org/meeting/100/materials/agenda-100-a= cme/

If = anything=E2=80=99s missing, please let us know really soon.

Thanks

Rich and = Yoav
= --Apple-Mail=_E7BFDD53-D2FA-4D40-9BD6-3C0635B83413-- --Apple-Mail=_C510A8F5-C4EE-4194-B0DB-AA24BA0A4A26 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----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAln2Kg0ACgkQuEkLFQpY zJkF+Af/VDwtDAWXZRHLv4TGhl7+74iaF2+IVx3L+whf75olBjrjIqS5Or5Ocd9C xvIjHOdiqFnC3FXO7ptocFtUTJgLNt9GFeJzXRY7l7B6iUhRrj1igWGFpAiBMphO IZU7Lj2D82UQtI65+aNTU1j+Qogtv7T8+xy0ImSVrPROgwDH8jOocFS7TuKIl62k A4fHJg7dEWMF4ku8RvVRXG+JQEgNzeun899902xc4ENG8l/gAE99pgWqOPi0JTAh QoTFuXtIfYAZ9+8PeeBEmx3bKRTqnIwduwWhZCu7hFKd4bZsigjf6klOecgrxzpB yngjnaEklGhVP4ePMXb8AhCLL5V0hQ== =pA0Q -----END PGP SIGNATURE----- --Apple-Mail=_C510A8F5-C4EE-4194-B0DB-AA24BA0A4A26-- From nobody Sun Oct 29 13:06: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 05D7F13FBC7 for ; Sun, 29 Oct 2017 13:06:04 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 3hI16aiILam3 for ; Sun, 29 Oct 2017 13:06:02 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::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 4948B13FBC4 for ; Sun, 29 Oct 2017 13:06:01 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id b192so9632896pga.2 for ; Sun, 29 Oct 2017 13:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TrLHxhG4FkMZQiLkXEp87THldMPw4YX/kT6ByjQDF9w=; b=MEBIxxb0cJuKIC/CWlKYpRw7gFB4HWhTehDbV6D5t1tA/muCLGcX3CI+6rVzf0wLek CJhpDrHnTiy2z0S0TsHSGLgL9TDlvIZY92veMgcoVuGnYjcrFGhynMVITceewRn3zH6D ke6T87QLFDxBO4y5inaF8bInco5/TKRhXcTyg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TrLHxhG4FkMZQiLkXEp87THldMPw4YX/kT6ByjQDF9w=; b=ZtWFaQtV+D+S2bTVrVTEhgCSvp/Kn6MC6Xx0WVtkJywDYp7tzqM8twSUUs40czCbRz UIL9bNcaLLErBORM6tkYZ6p2sT8tybtabjWBn8SJVQdnIYt8GFbjyWZUAXQMc9J+q7MF 1ijdATgjAGmUuEmNhza6yREUSMW9iidsPaqC5AAJWcpz5rR081OiQf2bVGVQzf10b5Lr FaGyuGp9mr9+QIm7j5n7aDpApZsMcrKTO1XetrvWAgjlnbgEOek/qZaQRwVkEEJjvaeh 66WEyp7T632SP/oa2j4vw6oiL7s7C0q9AsB3DfqfTFnyMMu7iliS0tJ+FcUvfEsSTdqF mVdA== X-Gm-Message-State: AMCzsaU1LZlyhRrzBkJ+61n59lma1QjXmW+UuhUkT76IshUgPvcFxO5W oB1LCgGhbajQQ2JwJgjXrSSLxQ== X-Google-Smtp-Source: ABhQp+SnzkqNIIybMNoNgFo82QRf0MVdGSuKjHoLd8TMH5c9u75l0pCPEZWBLsQyShuLwsJrq7hQgw== X-Received: by 10.99.127.89 with SMTP id p25mr5791711pgn.196.1509307560702; Sun, 29 Oct 2017 13:06:00 -0700 (PDT) Received: from ?IPv6:2602:306:cc83:12c0:81c8:ff61:674a:46b7? ([2602:306:cc83:12c0:81c8:ff61:674a:46b7]) by smtp.gmail.com with ESMTPSA id z7sm18859828pgp.36.2017.10.29.13.05.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Oct 2017 13:06:00 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Roland Bracewell Shoemaker In-Reply-To: <6B9CA7C8-E0BF-41A1-9511-F63FFE87A6ED@gmail.com> Date: Sun, 29 Oct 2017 13:05:54 -0700 Cc: IETF ACME Content-Transfer-Encoding: quoted-printable Message-Id: References: <6B9CA7C8-E0BF-41A1-9511-F63FFE87A6ED@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Acme] Draft Agenda Uploaded 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, 29 Oct 2017 20:06:04 -0000 If possible I=E2=80=99d like to give a quick overview of the IP = validation draft, the only feedback I=E2=80=99ve received on the last = version was editorial unless there is any further thoughts on the = technical aspects I=E2=80=99d be interested in seeing if there is = consensus for moving this towards LC. Given it=E2=80=99s a pretty simple = document this shouldn=E2=80=99t take much time. > On Oct 29, 2017, at 12:20 PM, Yoav Nir wrote: >=20 > https://datatracker.ietf.org/meeting/100/materials/agenda-100-acme/ >=20 > If anything=E2=80=99s missing, please let us know really soon. >=20 > Thanks >=20 > Rich and Yoav > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme From nobody Sun Oct 29 13:17: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 D95E813FBE1 for ; Sun, 29 Oct 2017 13:17:23 -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 hlosIvLZ8F0w for ; Sun, 29 Oct 2017 13:17:22 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c: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 42DAA13FBDD for ; Sun, 29 Oct 2017 13:17:22 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id r196so12020316wmf.2 for ; Sun, 29 Oct 2017 13:17:22 -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=dzeB0Nq2BB4FdYKa/jVcwX5rWDZf7yMbYs8WEkbKVo0=; b=XiM8rJTjrKUodQ5nn7o75PKEuAKjF5xoIMxHVpY9BDSXMfH1dKUj/90aRMAOf0TORH CzZzwqGhO9X9r8Je/Rp8TPcXinlqZzCArG4if1wbNOgzeRR870tR100qh8wnLd/3W2ps MEGoGdl/l37AaYAkHSVR4Z8w3LCA+LLW1ZdBR6XR9BIx5HrutzJsVOc9ERrwCUQHb/v5 7xTgzNwrOWUrckix2JPVr63aga2196OCVGzNms/YtA9OKpQADzKqrbA25PDOM5O/951Y exNNn4dcqBHPHrE1yhEnHY9wlB4sXI1ca8olamKOc8dW9uenoPKl5DBSIA9uHZPVVf/b JJEQ== 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=dzeB0Nq2BB4FdYKa/jVcwX5rWDZf7yMbYs8WEkbKVo0=; b=PkO6KplmYCxBE1q6YxpKd4b2j7V/dOeyRFG27EDaA/+B+e8Ge+tDWaXchjbbGmOZOq jTp4AXZObwYOkbjzi/sQ0KVelEpKfDdEyCVFppsfD929PbYl+WW3qEMWb2Q1JjR9MZC1 23klwa5olCDSZjXgDOZAPBMdKOmHzGaxXmyuuyGvHOF4nh68QGTO/PVDZ709ybZNJYDc NeB6sPKYIuCZt6tz06UZ/J7TKaNlao4b9T96pIa7RJjPeBRWu/DIFu8yIP5Bey/0+wBl qjvdbF8ZglC3cNIPinE/KklpIX3vuDOI5qiyyGhBarpTSDHo+Io91/DBnDhBie6taGAw rj5Q== X-Gm-Message-State: AMCzsaXB1zYfcHqgdyV2a8yRF+Wh7HDUWg4JRqjYKSz1b09dEF0AJp0J ZVmownPFJuMzQkFgVh6R8Twge1e5 X-Google-Smtp-Source: ABhQp+RyMF/xfWI9Yxwsl+0OCbnYt3lmD6nWq6loAIA+oNUJ8hPBcvuEWZDQIASgpQYO265B1n2U3g== X-Received: by 10.28.55.78 with SMTP id e75mr1825143wma.112.1509308240761; Sun, 29 Oct 2017 13:17:20 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id q3sm12077316wrd.78.2017.10.29.13.17.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Oct 2017 13:17:20 -0700 (PDT) From: Yoav Nir Message-Id: <25B381ED-E9BB-41DC-AEE9-30C328DEA2AD@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_520861D4-B699-4C2B-8442-EE35517C0B78"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Date: Sun, 29 Oct 2017 22:17:17 +0200 In-Reply-To: Cc: IETF ACME To: Roland Bracewell Shoemaker References: <6B9CA7C8-E0BF-41A1-9511-F63FFE87A6ED@gmail.com> X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [Acme] Draft Agenda Uploaded 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, 29 Oct 2017 20:17:24 -0000 --Apple-Mail=_520861D4-B699-4C2B-8442-EE35517C0B78 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 OK. I=E2=80=99ll add that to the final agenda. Yoav > On 29 Oct 2017, at 22:05, Roland Bracewell Shoemaker = wrote: >=20 > If possible I=E2=80=99d like to give a quick overview of the IP = validation draft, the only feedback I=E2=80=99ve received on the last = version was editorial unless there is any further thoughts on the = technical aspects I=E2=80=99d be interested in seeing if there is = consensus for moving this towards LC. Given it=E2=80=99s a pretty simple = document this shouldn=E2=80=99t take much time. >=20 >> On Oct 29, 2017, at 12:20 PM, Yoav Nir wrote: >>=20 >> https://datatracker.ietf.org/meeting/100/materials/agenda-100-acme/ >>=20 >> If anything=E2=80=99s missing, please let us know really soon. >>=20 >> Thanks >>=20 >> Rich and Yoav >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >=20 --Apple-Mail=_520861D4-B699-4C2B-8442-EE35517C0B78 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----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAln2N00ACgkQuEkLFQpY zJkyNgf/YypwR06ZJI1XQQQkZjo6dZ/MuCEWtv2KvUXwruWw3SpMvWv9nrEMvKFj LbSBYdeGxAHaV0AurIAURBK39A3fwGvSs3IH7+zb4voNFAnLZjsUrvMEP/CpvUUJ WWW5y5H1JG/Yb833AB1FhxA6FZXxZMdQCnSiG3qCg0mdBGGO2ngCOwqU3QniAdHt Cl/LzJRg1cA6v7XKMIeR/RV+Pg09/JJM0AIuf4C9odeAU7KVopC4+i6QRVeM6uLr sMSvbX8JsesvyuT8GDa34jrr593baDWH8r5XBlQlKZUleF3uGA32QXqYaLybRvGJ oOl2tiYWrF0hyBWyMK1J8+PDxVki/A== =eKuo -----END PGP SIGNATURE----- --Apple-Mail=_520861D4-B699-4C2B-8442-EE35517C0B78-- From nobody Mon Oct 30 07:13: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 1470C138BD8 for ; Mon, 30 Oct 2017 07:13:37 -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 nrVGCQ_ykfBF for ; Mon, 30 Oct 2017 07:13:35 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 ED36813B18D for ; Mon, 30 Oct 2017 07:13:34 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id n137so27481949iod.6 for ; Mon, 30 Oct 2017 07:13:34 -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=2AZA0N7GWAJ9KZAQzw+L41Qj51HwArVF2q4TpbJ/XmM=; b=L6j05spcHrXa3uFRLEBHrCHfKV+skHBGAl3FirWYfgRHpLspiJ8cbrg4Tuh2xpuE6F Y9X+VyFy8n8nuRtZo392bwvbzfJt1pkUEG7bcxPe0QPnYAzJqk08NlosoU+d9xlZfOpE gEJFRXiDA50yYH2j9fKEaczeEIefHzGjMWOXs= 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=2AZA0N7GWAJ9KZAQzw+L41Qj51HwArVF2q4TpbJ/XmM=; b=onDGN5TnydGji8R9Czfut6QSNNvJhvTcbh8MaXhOCdIJVLDcBWHGlPIP1Sib1Hi25/ 0XWwOqhfEQBDF+IFi77S2TJ/lq86uktmPpg7j+KAfcW2BPaZw5t6aoRT3eMo5JaXf/ai J7EB8gAKrnD+i5U3mCTIhFvuCiR/s+MKJqRrN+I7rsbGnPibPFCda8Kztu8uz30yXvIR Hf78pw9stgNg/DYH2COWNGFFOt5aBpi+YoyYJbqrtsKAJ3W9j6FXb1mdV0cfhXHk4+3j +2CQAWoqty0eSqaFGmhrj9bzBYBq2W8uWRUwmfxdBg+79Fz5o1YeAq6VvUgJ6G1+uab7 mhtQ== X-Gm-Message-State: AMCzsaVDQ4cWFOVsVEerpBQbgOJh2Dr564CE3345X4E5EakSdkWOEZCY ++6XqjTdiEgvuNrLm9mQ5NrGyz+ysjTp3Lbnn18YnUQrxsQ= X-Google-Smtp-Source: ABhQp+TZB/Ci/9FrdSeQ4vkOwv/Xjr1tya/BQwCsLpX3f+oSXOT7IP++NvHUoD/AnxFcCHB+sHEczxfoCHbkgbWFqaY= X-Received: by 10.36.215.67 with SMTP id y64mr6266397itg.145.1509372814224; Mon, 30 Oct 2017 07:13:34 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.88.21 with HTTP; Mon, 30 Oct 2017 07:13:33 -0700 (PDT) In-Reply-To: <71f3e975-7cee-18cf-2635-80eb13adff12@devever.net> References: <71f3e975-7cee-18cf-2635-80eb13adff12@devever.net> From: Daniel McCarney Date: Mon, 30 Oct 2017 10:13:33 -0400 Message-ID: To: Hugo Landau Cc: IETF ACME Content-Type: multipart/alternative; boundary="94eb2c0b05a46d0b6f055cc43e03" Archived-At: Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR 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, 30 Oct 2017 14:13:37 -0000 --94eb2c0b05a46d0b6f055cc43e03 Content-Type: text/plain; charset="UTF-8" Hi Hugo, Providing the CSR up-front allows the CA to predicate order processing on > aspects of that CSR, both with regard to the present protocol and any > future extensions, both now and in the future in ways that we can and > cannot foresee. I don't think it's appropriate to defer giving critical > information to the CA until the last minute due to a resource utilisation > concern which LE has already proven capable of dealing with The open-ended policy accommodations you mention sound nice in theory but at the start of this thread I offered concrete cases that suffer as a result of this decision and I would like to see concrete use-cases used as counter argument. Are there any CAs that have expressed interest in policy decisions based on the CSR? If so, can they please explain in concrete terms how they would *not* be able to do so with the CSR submitted at finalization time? This thread was specifically started because the LE implementation showed that the current design would pose considerable problems with resource utilization. I don't think it's appropriate to assume that in contradiction to that direct experience it will be a problem LE is capable of dealing with without more concrete suggestions as to how. - cpu On Tue, Oct 24, 2017 at 9:45 AM, Hugo Landau wrote: > My thoughts: > > - Requiring an explicit action against the order after the fulfilment of > authorizations to cause issuance seems fine to me. > > - I think moving the submission of the CSR to the end of this process is > a mistake. > > The ACME protocol should permit CAs to implement policy as far as is > reasonably practicable with regard to the workflows around which the > protocol is organised. Providing the CSR up-front allows the CA to > predicate order processing on aspects of that CSR, both with regard to > the present protocol and any future extensions, both now and in the > future in ways that we can and cannot foresee. I don't think it's > appropriate to defer giving critical information to the CA until the > last minute due to a resource utilisation concern which LE has already > proven capable of dealing with, especially when the whole point of the > order flow in the first place was to provide more flexibility for CAs to > institute policy. > > A possible compromise would be to require the CSR to be submitted both > on new-order and on finalization, but that's quite clumsy. > > --94eb2c0b05a46d0b6f055cc43e03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Hugo,

Providing the CSR up-front allows = the CA to=C2=A0predicate order proc= essing on aspects of that CSR, both with regard to=C2=A0the present protocol and any future extensions, both = now and in the=C2=A0future in ways = that we can and cannot foresee. I don't think it's=C2=A0appropriate to defer giving critical informati= on to the CA until the=C2=A0last mi= nute due to a resource utilisation concern which LE has already=C2=A0proven capable of dealing with

The open-ended policy accommodations you mention sound ni= ce in theory but at the start of this thread I offered concrete cases that = suffer as a result of this decision and I would like to see concrete use-ca= ses used as counter argument. Are there any CAs that have expressed interes= t in policy decisions based on the CSR? If so, can they please explain in c= oncrete terms how they would *not* be able to do so with the CSR submitted = at finalization time?

This thread was specifically started because t= he LE implementation showed that the current design would pose considerable= problems with resource utilization. I don't think it's appropriate= to assume that in contradiction to that direct experience it will be a pro= blem LE is capable of dealing with without more concrete suggestions as to = how.

- cpu


On Tue, Oct 24, 2017 at 9:45 AM, Hugo= Landau <hlandau@devever.net> wrote:
My thoughts:

- Requiring an explicit action against the order after the fulfilment of authorizations to cause issuance seems fine to me.

- I think moving the submission of the CSR to the end of this process is a mistake.

The ACME protocol should permit CAs to implement policy as far as is
reasonably practicable with regard to the workflows around which the
protocol is organised. Providing the CSR up-front allows the CA to
predicate order processing on aspects of that CSR, both with regard to
the present protocol and any future extensions, both now and in the
future in ways that we can and cannot foresee. I don't think it's appropriate to defer giving critical information to the CA until the
last minute due to a resource utilisation concern which LE has already
proven capable of dealing with, especially when the whole point of the
order flow in the first place was to provide more flexibility for CAs to institute policy.

A possible compromise would be to require the CSR to be submitted both
on new-order and on finalization, but that's quite clumsy.


--94eb2c0b05a46d0b6f055cc43e03-- From nobody Mon Oct 30 07:16: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 20E4F13B13B for ; Mon, 30 Oct 2017 07:16:00 -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, 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 2Lk0_68ZfZQW for ; Mon, 30 Oct 2017 07:15:57 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8655C13B18D for ; Mon, 30 Oct 2017 07:15:57 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id 97so27455801iok.7 for ; Mon, 30 Oct 2017 07:15:57 -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=Cu4LbqTFiZzhCVxOC/49Am4Qy5IFXkuN7NOOb32ZYng=; b=NisDzRgXLnKSi2w9lD3cOwyDdvUgnrszeEV71MkOVIj38UZvQ0+8NVzBw0ZliXvCbw EYq2q1njCfMA2Ilp7Cr1Ca+Ilo1/ezzzdpwZJ9lCHniS5kURgGfXUA3fzn5wVF78JVd+ frC31v9wo1til0bUzOIYTkU2GSq2zH8vQ/a9w= 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=Cu4LbqTFiZzhCVxOC/49Am4Qy5IFXkuN7NOOb32ZYng=; b=EgZMiUFEv+70c5y20hmxKylc3SEHpN/68VgantxezlBZWevqXzAlwZEaNU773fowIB IvuAcl15hSVD9ZfKOJVDq+kI6gQCOy7iwfzVPdtJp1D/vCdBTDplNxvZTDosQBrzKvyR kyflH5ID10078PfU4MeVl2UVh2uA/eKf94dokJ674VwrGHrFUJ+v/6F6irdFkhOgYtrS 1p2KyA3iMrkMdd3cq8uCDnfNVmGzPcFZqBFO/lx+QrNakzfBhj44Y/I2batuLvrvzR3d LNWisBSrjPog9otbRXtsTsJrPGjbpMg9vSIqGTVC9ouJqLffriEuKm5NDv5GrTfkkBDc bkoQ== X-Gm-Message-State: AMCzsaUMipG8hskU1wG8wSMg6EvnbzTWArOmqaFxYpWNZGpGhLmpeOQ8 3ZhRGfd43yeHvQ10NXH5plYg9FILhXgbDxp3Qc3uPw== X-Google-Smtp-Source: ABhQp+Skt8EKC7lcdwGGAAe0rPz1S0X4Xld/zKzsoZeyxlrv0y+KgMQzA0vwi6YusEE6Fe9rM7259iVhoDchgEKebJs= X-Received: by 10.36.124.197 with SMTP id a188mr5965883itd.53.1509372956918; Mon, 30 Oct 2017 07:15:56 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.88.21 with HTTP; Mon, 30 Oct 2017 07:15:56 -0700 (PDT) In-Reply-To: <20171024141732.ufjysx5f73pyc5f4@LK-Perkele-VII> References: <71f3e975-7cee-18cf-2635-80eb13adff12@devever.net> <20171024141732.ufjysx5f73pyc5f4@LK-Perkele-VII> From: Daniel McCarney Date: Mon, 30 Oct 2017 10:15:56 -0400 Message-ID: To: Ilari Liusvaara Cc: Hugo Landau , IETF ACME Content-Type: multipart/alternative; boundary="001a114a95ecee59c8055cc44679" Archived-At: Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR 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, 30 Oct 2017 14:16:00 -0000 --001a114a95ecee59c8055cc44679 Content-Type: text/plain; charset="UTF-8" > Example: Suppose that CAA-PKP got added (restrict issuance on SPKI key). Implementing that without knowing the public key at validation time is annoying. Can you expand on "annoying"? It seems completely possible to reject the order finalization message based on a CAA-PKP property. In-fact, we already have to be rechecking CAA for authorizations validated more than 8 hours ago at the time of issuance so there must be code in place to check CAA at finalization and clients must be prepared for their order to be rejected at finalization based on CAA already. I don't see how this is any more annoying. - cpu On Tue, Oct 24, 2017 at 10:17 AM, Ilari Liusvaara wrote: > On Tue, Oct 24, 2017 at 02:45:01PM +0100, Hugo Landau wrote: > > > > The ACME protocol should permit CAs to implement policy as far as is > > reasonably practicable with regard to the workflows around which the > > protocol is organised. Providing the CSR up-front allows the CA to > > predicate order processing on aspects of that CSR, both with regard to > > the present protocol and any future extensions, both now and in the > > future in ways that we can and cannot foresee. I don't think it's > > appropriate to defer giving critical information to the CA until the > > last minute due to a resource utilisation concern which LE has already > > proven capable of dealing with, especially when the whole point of the > > order flow in the first place was to provide more flexibility for CAs to > > institute policy. > > Example: Suppose that CAA-PKP got added (restrict issuance on SPKI > key). Implementing that without knowing the public key at validation > time is annoying. > > As to why one would want something like that, it would allow limiting > trust on certficiate management system without deploying something as > dangerous as HPKP. > > > > -Ilari > --001a114a95ecee59c8055cc44679 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0Example: Suppos= e that CAA-PKP got added (restrict issuance on SPKI=C2=A0key). Implementing that without knowing the public ke= y at validation=C2=A0time is annoyi= ng.

Can you expand on "annoying"?

It seems complete= ly possible to reject the order finalization message based on a CAA-PKP pro= perty. In-fact, we already have to be rechecking CAA for authorizations val= idated more than 8 hours ago at the time of issuance so there must be code = in place to check CAA at finalization and clients must be prepared for thei= r order to be rejected at finalization based on CAA already.

I don&= #39;t see how this is any more annoying.

- cpu=C2= =A0

On Tue, Oct 24, 2017 at 10:17 AM, Ilari Liusvaara &l= t;ilariliusva= ara@welho.com> wrote:
On Tue, Oct 24, 2017 at 02:45:01PM +0100, Hugo Landau wrote: >
> The ACME protocol should permit CAs to implement policy as far as is > reasonably practicable with regard to the workflows around which the > protocol is organised. Providing the CSR up-front allows the CA to
> predicate order processing on aspects of that CSR, both with regard to=
> the present protocol and any future extensions, both now and in the > future in ways that we can and cannot foresee. I don't think it= 9;s
> appropriate to defer giving critical information to the CA until the > last minute due to a resource utilisation concern which LE has already=
> proven capable of dealing with, especially when the whole point of the=
> order flow in the first place was to provide more flexibility for CAs = to
> institute policy.

Example: Suppose that CAA-PKP got added (restrict issuance on SPKI key). Implementing that without knowing the public key at validation
time is annoying.

As to why one would want something like that, it would allow limiting
trust on certficiate management system without deploying something as
dangerous as HPKP.



-Ilari

--001a114a95ecee59c8055cc44679-- From nobody Mon Oct 30 12:33:52 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 0E51B13F572 for ; Mon, 30 Oct 2017 12:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 bS2Jf-JRgd_O for ; Mon, 30 Oct 2017 12:33:48 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c: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 660D913F3C3 for ; Mon, 30 Oct 2017 12:33:48 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id s66so17952781wmf.5 for ; Mon, 30 Oct 2017 12:33:48 -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=RaFJ3WFeFdpRWsj7Cln1oWQ71k+vRYyoxkLlgNcyp2U=; b=cfLXCU62cDs1XUFxMTxYoachODn9W4YUJ92z/zbm34aTZ4zFt/X3RsDxOwkxdXrNJ/ /4282VUYJ2/P81GToG9F/Pn150Gf4mAzw4MTlpQGa8skSI/237hXuMzBtnwvzXSjJ2N4 ISTx2GuQ4G/CbWvcYM84QBBYhhlZvNyaua/wWBXUcx9jOCK7jHUjkgDz7WkkcTOqFB02 DgArrJ7HiBj54m0VyxHIPQhSLJ9u08t1PJQgNXXhLTPZPyWqD+dE0ewvyRC6hOWvWI6v +V3/GYy5O7Q6F1hV6aNCvPYei14nlbUriq39WAunkzK1ok3AHETC/xZvDbzQH09ofWmb KFhA== 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=RaFJ3WFeFdpRWsj7Cln1oWQ71k+vRYyoxkLlgNcyp2U=; b=LeupMsU1vkxfYVi8m9nvJ5Wz+7QPLP3LtApmw3onYBURJZHn8QqBrAroZ1/k2bZEss arY8EKeOa3Veynby7456uay+QO6tWcL+Jd4SG2Ew6DTX5lzDy2DGW+W2YfYkPLeDL9ry Yz5DFmDaQhakQuGStnxOFk8L9gCPBwjjD8Ze4uiR47myhGFRCHUnSKAY5u7ZOnxeLKgm Edcf57I1ZW1z+JTJjaVbTLjbSt/YbWgDTZs70lboiLm1Yz2PrXG9+hC6/THf8GYOwdD7 Qh+l5zyYD30OL+mgGnBp2rjPBS/gqbMiQVPacMfQFnn9jKN1Za8C+vEwglLnu113ALDF ORpA== X-Gm-Message-State: AMCzsaUxdN/DpzcjqwvX3NVrAtRzIaGmzgxSwQ6CrFKpwHSD9rZLnBVp 7kJF9eSNiwjTzJejwlZ0lkD+KFmkuRzsnCXXMqY+vw== X-Google-Smtp-Source: ABhQp+RjCrUW7roWuGSNwuk0jBO2syzZm91ZLMBUZRGile085bJ1cSFMb7EMTHMinOyiuGRqOKakOy/4MY4AdcsNxAc= X-Received: by 10.28.192.25 with SMTP id q25mr4472365wmf.98.1509392026813; Mon, 30 Oct 2017 12:33:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Mon, 30 Oct 2017 12:33:46 -0700 (PDT) In-Reply-To: References: <71f3e975-7cee-18cf-2635-80eb13adff12@devever.net> <20171024141732.ufjysx5f73pyc5f4@LK-Perkele-VII> From: Richard Barnes Date: Mon, 30 Oct 2017 15:33:46 -0400 Message-ID: To: Daniel McCarney Cc: Ilari Liusvaara , IETF ACME , Hugo Landau Content-Type: multipart/alternative; boundary="089e082fa15c95de90055cc8b73f" Archived-At: Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR 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, 30 Oct 2017 19:33:51 -0000 --089e082fa15c95de90055cc8b73f Content-Type: text/plain; charset="UTF-8" On Mon, Oct 30, 2017 at 10:15 AM, Daniel McCarney wrote: > > Example: Suppose that CAA-PKP got added (restrict issuance on SPKI key). > Implementing that without knowing the public key at validation time is > annoying. > > Can you expand on "annoying"? > > It seems completely possible to reject the order finalization message > based on a CAA-PKP property. > Wouldn't it be a lot better not to do the validations at all if you can tell at new-order time that you're not going to be willing to issue? > In-fact, we already have to be rechecking CAA for authorizations validated > more than 8 hours ago at the time of issuance so there must be code in > place to check CAA at finalization and clients must be prepared for their > order to be rejected at finalization based on CAA already. > > I don't see how this is any more annoying. > > - cpu > > On Tue, Oct 24, 2017 at 10:17 AM, Ilari Liusvaara < > ilariliusvaara@welho.com> wrote: > >> On Tue, Oct 24, 2017 at 02:45:01PM +0100, Hugo Landau wrote: >> > >> > The ACME protocol should permit CAs to implement policy as far as is >> > reasonably practicable with regard to the workflows around which the >> > protocol is organised. Providing the CSR up-front allows the CA to >> > predicate order processing on aspects of that CSR, both with regard to >> > the present protocol and any future extensions, both now and in the >> > future in ways that we can and cannot foresee. I don't think it's >> > appropriate to defer giving critical information to the CA until the >> > last minute due to a resource utilisation concern which LE has already >> > proven capable of dealing with, especially when the whole point of the >> > order flow in the first place was to provide more flexibility for CAs to >> > institute policy. >> >> Example: Suppose that CAA-PKP got added (restrict issuance on SPKI >> key). Implementing that without knowing the public key at validation >> time is annoying. >> >> As to why one would want something like that, it would allow limiting >> trust on certficiate management system without deploying something as >> dangerous as HPKP. >> >> >> >> -Ilari >> > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --089e082fa15c95de90055cc8b73f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Oct 30, 2017 at 10:15 AM, Daniel McCarney <= ;cpu@letsencrypt.o= rg> wrote:
>=C2=A0Example: Suppo= se that CAA-PKP got added (restrict issuance on SPKI=C2=A0key). Implementing that without knowing the public k= ey at validation=C2=A0time i= s annoying.

Can you expand on "annoying"?

It seems = completely possible to reject the order finalization message based on a CAA= -PKP property.

Wouldn't i= t be a lot better not to do the validations at all if you can tell at new-o= rder time that you're not going to be willing to issue?
<= br>
=C2=A0
<= span style=3D"font-size:12.8px">In-fact, we already have to be rechecking C= AA for authorizations validated more than 8 hours ago at the time of issuan= ce so there must be code in place to check CAA at finalization and clients = must be prepared for their order to be rejected at finalization based on CA= A already.

I don't see how this is any more annoying.
- cpu=C2=A0

On Tue,= Oct 24, 2017 at 10:17 AM, Ilari Liusvaara <ilariliusvaara@welho.co= m> wrote:
On Tue, Oct= 24, 2017 at 02:45:01PM +0100, Hugo Landau wrote:
>
> The ACME protocol should permit CAs to implement policy as far as is > reasonably practicable with regard to the workflows around which the > protocol is organised. Providing the CSR up-front allows the CA to
> predicate order processing on aspects of that CSR, both with regard to=
> the present protocol and any future extensions, both now and in the > future in ways that we can and cannot foresee. I don't think it= 9;s
> appropriate to defer giving critical information to the CA until the > last minute due to a resource utilisation concern which LE has already=
> proven capable of dealing with, especially when the whole point of the=
> order flow in the first place was to provide more flexibility for CAs = to
> institute policy.

Example: Suppose that CAA-PKP got added (restrict issuance on SPKI key). Implementing that without knowing the public key at validation
time is annoying.

As to why one would want something like that, it would allow limiting
trust on certficiate management system without deploying something as
dangerous as HPKP.



-Ilari


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


--089e082fa15c95de90055cc8b73f-- From nobody Mon Oct 30 12:48: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 2B64113FAF8 for ; Mon, 30 Oct 2017 12:48:13 -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 WezOKr7v_g3M for ; Mon, 30 Oct 2017 12:48:10 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 5068313FAF3 for ; Mon, 30 Oct 2017 12:48:06 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id 101so29881374ioj.3 for ; Mon, 30 Oct 2017 12:48:06 -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=9HLB+N/RokIm7j3/vHwUIPKvEB4+j9AB5pjHDgd8e8Y=; b=J840KGQHj3/Sr60Q+Sa1H/dGuaKJlfvWiDr9qqAGhuzAgnrTDw90vfQMYhA0aezGng ZE7YLp2ZnnClhD3ZudlSLNJNemCdO/Va/2i5uHnDGcA8+wv8eSC7z14bEBk6UoHNoj+d UsUgUUj0PoOt0eYgQ9kZvM+ZyXoXm4Qr4+z5Y= 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=9HLB+N/RokIm7j3/vHwUIPKvEB4+j9AB5pjHDgd8e8Y=; b=eTHIulnzjVTnJAk5GNW7vzpOcgmhkmcqa+tbqBY2DWRGsyVKYWdqZh+Mzoin/t+0lf aLJhYZ380ZC5wb02AfAOthJHYqrH3Gk6SUhzm8OAhVZegHIoJwbeqvZopm52ImMhf5ib Fiei4mAuYloMjJSGpcKp7Ho2PG3JJmm9N80/ZAzQJ2oEiGY8dscYM5uFeVNPGwwQP7F+ NsyjOb3b1fXTZaIiq9iJC2Cu5f/EfhId2VWG6kXS9r3I2pXn4dGiq9mRhMqP+MPoHRMg 91OwVVjRfrWOzAo08HPK3puP8bmfl1NT0qD1DzXR4oWCT8wztKjM6/Gc+BuCSaf76paP 5r9Q== X-Gm-Message-State: AMCzsaUtt2A/yGzUpeVyDL3U1FOmTF6iuOHOjdqpqJ/mGr17aRtpFxKH +5qR/gqyZARg6ZXMFY09eE/jxVGyBTeOr4MQaQOZyg== X-Google-Smtp-Source: ABhQp+TzWddTTbRB+NKPYhzg9qsmonybfMjzThKP8DT9AHQfeacf8fOkH7i7+f6UBapxKqLVCBA2gogGhZ/DjtaZ/2E= X-Received: by 10.107.167.83 with SMTP id q80mr12111610ioe.89.1509392885624; Mon, 30 Oct 2017 12:48:05 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.88.21 with HTTP; Mon, 30 Oct 2017 12:48:04 -0700 (PDT) In-Reply-To: References: <71f3e975-7cee-18cf-2635-80eb13adff12@devever.net> <20171024141732.ufjysx5f73pyc5f4@LK-Perkele-VII> From: Daniel McCarney Date: Mon, 30 Oct 2017 15:48:04 -0400 Message-ID: To: Richard Barnes Cc: Ilari Liusvaara , IETF ACME , Hugo Landau Content-Type: multipart/alternative; boundary="001a11429d88c65da2055cc8ea61" Archived-At: Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR 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, 30 Oct 2017 19:48:13 -0000 --001a11429d88c65da2055cc8ea61 Content-Type: text/plain; charset="UTF-8" > > Wouldn't it be a lot better not to do the validations at all if you can > tell at new-order time that you're not going to be willing to issue? Yes, that would be better in this one capacity. However I don't think it comes close to justify the scaling issues associated with accepting the CSR up-front, and as mentioned, there are other reasons why validations may occur for an order that the CA isn't willing to issue at the time of finalization. There also isn't a CAA-PKP so we're bikeshedding about impact on features that are both unspecified & unimplemented. - Daniel / cpu On Mon, Oct 30, 2017 at 3:33 PM, Richard Barnes wrote: > > > On Mon, Oct 30, 2017 at 10:15 AM, Daniel McCarney > wrote: > >> > Example: Suppose that CAA-PKP got added (restrict issuance on SPKI key). >> Implementing that without knowing the public key at validation time is >> annoying. >> >> Can you expand on "annoying"? >> >> It seems completely possible to reject the order finalization message >> based on a CAA-PKP property. >> > > Wouldn't it be a lot better not to do the validations at all if you can > tell at new-order time that you're not going to be willing to issue? > > > >> In-fact, we already have to be rechecking CAA for authorizations >> validated more than 8 hours ago at the time of issuance so there must be >> code in place to check CAA at finalization and clients must be prepared for >> their order to be rejected at finalization based on CAA already. >> >> I don't see how this is any more annoying. >> >> - cpu >> >> On Tue, Oct 24, 2017 at 10:17 AM, Ilari Liusvaara < >> ilariliusvaara@welho.com> wrote: >> >>> On Tue, Oct 24, 2017 at 02:45:01PM +0100, Hugo Landau wrote: >>> > >>> > The ACME protocol should permit CAs to implement policy as far as is >>> > reasonably practicable with regard to the workflows around which the >>> > protocol is organised. Providing the CSR up-front allows the CA to >>> > predicate order processing on aspects of that CSR, both with regard to >>> > the present protocol and any future extensions, both now and in the >>> > future in ways that we can and cannot foresee. I don't think it's >>> > appropriate to defer giving critical information to the CA until the >>> > last minute due to a resource utilisation concern which LE has already >>> > proven capable of dealing with, especially when the whole point of the >>> > order flow in the first place was to provide more flexibility for CAs >>> to >>> > institute policy. >>> >>> Example: Suppose that CAA-PKP got added (restrict issuance on SPKI >>> key). Implementing that without knowing the public key at validation >>> time is annoying. >>> >>> As to why one would want something like that, it would allow limiting >>> trust on certficiate management system without deploying something as >>> dangerous as HPKP. >>> >>> >>> >>> -Ilari >>> >> >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> >> > --001a11429d88c65da2055cc8ea61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Wouldn't it be a lot better not to do the vali= dations at all if you can tell at new-order time that you're not going = to be willing to issue?

Yes, that would be bett= er in this one capacity. However I don't think it comes close to justif= y the scaling issues associated with accepting the CSR up-front, and as men= tioned, there are other reasons why validations may occur for an order that= the CA isn't willing to issue at the time of finalization.

Ther= e also isn't a CAA-PKP so we're bikeshedding about impact on featur= es that are both unspecified & unimplemented.=C2=A0

- Daniel / c= pu

On Mon, = Oct 30, 2017 at 3:33 PM, Richard Barnes <rlb@ipv.sx> wrote:

=
On Mon, Oct 30, 2017 at 10:= 15 AM, Daniel McCarney <cpu@letsencrypt.org> wrote:
>=C2=A0Example: Suppose that CAA-PKP got added (restrict issuan= ce on SPKI=C2=A0key). Implementing = that without knowing the public key at validation=C2=A0time is annoying.

Can you expand on "= ;annoying"?

It seems completely possible to reject the order fi= nalization message based on a CAA-PKP property.
<= div>
Wouldn't it be a lot better not to do the val= idations at all if you can tell at new-order time that you're not going= to be willing to issue?

=C2=A0
In-fact, we already have to be rechecking CAA for authorizati= ons validated more than 8 hours ago at the time of issuance so there must b= e code in place to check CAA at finalization and clients must be prepared f= or their order to be rejected at finalization based on CAA already.
I don't see how this is any more annoying.

- c= pu=C2=A0

On Tue, Oct 24, 2017 at 10:17 AM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Tue, Oct 24, 2017 at 02:45:01PM +0100, Hugo Landau wrote: >
> The ACME protocol should permit CAs to implement policy as far as is > reasonably practicable with regard to the workflows around which the > protocol is organised. Providing the CSR up-front allows the CA to
> predicate order processing on aspects of that CSR, both with regard to=
> the present protocol and any future extensions, both now and in the > future in ways that we can and cannot foresee. I don't think it= 9;s
> appropriate to defer giving critical information to the CA until the > last minute due to a resource utilisation concern which LE has already=
> proven capable of dealing with, especially when the whole point of the=
> order flow in the first place was to provide more flexibility for CAs = to
> institute policy.

Example: Suppose that CAA-PKP got added (restrict issuance on SPKI key). Implementing that without knowing the public key at validation
time is annoying.

As to why one would want something like that, it would allow limiting
trust on certficiate management system without deploying something as
dangerous as HPKP.



-Ilari


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



--001a11429d88c65da2055cc8ea61-- From nobody Mon Oct 30 12:50: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 D5F1313FAE1; Mon, 30 Oct 2017 12:50:47 -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.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150939304784.7924.17374920221495624186@ietfa.amsl.com> Date: Mon, 30 Oct 2017 12:50:47 -0700 Archived-At: Subject: [Acme] I-D Action: draft-ietf-acme-acme-08.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, 30 Oct 2017 19:50:48 -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 WG of the IETF. Title : Automatic Certificate Management Environment (ACME) Authors : Richard Barnes Jacob Hoffman-Andrews James Kasten Filename : draft-ietf-acme-acme-08.txt Pages : 75 Date : 2017-10-30 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 30 12:52: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 C33BF13FB23 for ; Mon, 30 Oct 2017 12:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Hk8uUiemigaW for ; Mon, 30 Oct 2017 12:52:27 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 AA83613FB14 for ; Mon, 30 Oct 2017 12:51:45 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id p75so18175049wmg.3 for ; Mon, 30 Oct 2017 12:51:45 -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=eiVMOAZDyfg1/TCJRXQ8XqEvtFjOowKo01+F4DPqk/o=; b=kED+ND+/XMLWizBuELZd6rbI/9Wh0dNriX1xTrUFqCk8+cmMLUMBycdOIsrMAjbTTA vq8RsTBBY8aIl1cSAzVBWr+VkQ32oTElo8QPHeZyeSoLidRgXe6s5RMUTfoND2dhhAT3 jcGgsPn16H8oyZ9h+2Eh/p08OYGwenfy+s9lw1KKiE7vVgas3cC5Y8U/F2GC0EEL1Fha rlIzJTf8HEtAk/PqN9d7og6czCe8drYmrzzqJCa7YxHu95nHI3DmvOEPurPARrLeZVfw TIXtnxLV1hXl+mgtjclYrriTxr/ACcx29AujvmI8qEMl252uM9Dy3G4QrpknS8Md/qLb qT5A== 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=eiVMOAZDyfg1/TCJRXQ8XqEvtFjOowKo01+F4DPqk/o=; b=bjwq2RxmHmEUolt75d5RSvLaAZbrgmrcmY7X++VOaZX/R3SBZMPT1Q5KYfZ0Fl9603 exb6lzL/9q/hlZfT639X1sCmzzN6iLhfvZaF7FWJ3KPDJ2pMrP72ZcwtzOQNu75U/CvD g+cpCIj28WzdW55tnTHdlHcaOyr8fQWn4FyHPpr3em3oPaQ2UCr+hRnqBfBpujPc8Uhu qyTdi4UUpFRNB4bMR86bgBvC6CDWp7v3JMBcW8gHmzFPv9tG8ft3Ct61p7UsLMeZaLQp S7kfzsa38sUhCV+ruLeRLqtdrSBxxDBxptHO1d9t62WBJ2HBhyZhv5o739/7BB++Bt7n czDQ== X-Gm-Message-State: AMCzsaXIuxkfB1gmwIfL8QADeo6JlwvGG4ei1BWqkVil/vNaR+9wBg3U YzVvBDIBims646f5gIItX4eqe4yGwvACq+6MLgkjjQ== X-Google-Smtp-Source: ABhQp+T3SUwaUnXEFztaqXQi+MTIVDUqodkDPMLOVyYJtnz8GmYsbCNfnqdPeGiquYHKAObvapp6GkRTRCn+E+BDhdo= X-Received: by 10.28.69.91 with SMTP id s88mr4676775wma.19.1509393104032; Mon, 30 Oct 2017 12:51:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Mon, 30 Oct 2017 12:51:43 -0700 (PDT) In-Reply-To: <150939304784.7924.17374920221495624186@ietfa.amsl.com> References: <150939304784.7924.17374920221495624186@ietfa.amsl.com> From: Richard Barnes Date: Mon, 30 Oct 2017 15:51:43 -0400 Message-ID: To: internet-drafts@ietf.org Cc: i-d-announce@ietf.org, "acme@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0723a6cae3c0055cc8f739" Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-acme-08.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, 30 Oct 2017 19:52:31 -0000 --94eb2c0723a6cae3c0055cc8f739 Content-Type: text/plain; charset="UTF-8" This just rolls up all of the PRs that we've landed since -07. Shouldn't be any surprises. On Mon, Oct 30, 2017 at 3:50 PM, wrote: > > 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 WG of the IETF. > > Title : Automatic Certificate Management Environment > (ACME) > Authors : Richard Barnes > Jacob Hoffman-Andrews > James Kasten > Filename : draft-ietf-acme-acme-08.txt > Pages : 75 > Date : 2017-10-30 > > 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-08 > https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-08 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --94eb2c0723a6cae3c0055cc8f739 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This just rolls up all of the PRs that we've landed si= nce -07.=C2=A0 Shouldn't be any surprises.

On Mon, Oct 30, 2017 at 3:50 PM, <internet-drafts@ietf.org> wrote:

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 WG 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-08.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 75
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-10-30

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-08
https://datatracker.ietf.org/doc/h= tml/draft-ietf-acme-acme-08

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


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

--94eb2c0723a6cae3c0055cc8f739-- From nobody Mon Oct 30 14:01:07 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 C4D3D13FA1C for ; Mon, 30 Oct 2017 14:01:05 -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 xBu3eUs4TqkP for ; Mon, 30 Oct 2017 14:01:03 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::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 587CD13F871 for ; Mon, 30 Oct 2017 14:01:03 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id x7so11992556pfa.1 for ; Mon, 30 Oct 2017 14:01:03 -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:content-transfer-encoding; bh=xP9zbcYJBgmZwREH5E65nuvUxQOYEelnLWX27Bi0Gfc=; b=qiMOUKfzBJVgmh6ZOUf/SxzOuXIDfMTYtSYo6roVljjv0wEkhxMb4r/hBI66RPWTEM C2ahiuzQiPV3swWyX/oi3eIKm05lKe+CRzt0NMVxpdg1eTFEIAehnp/JEAZk8V+Bl8hw jwjud9UPSrtRVxYje72NxrIkDtmQy+6lV8CejzR6AyYMHF1MmDUIgXCgvG0Tom0mfTiw B+Jlm7JhYh82Ud+Al973DLTCLDUNe3ZCpzOyTfYLB5n3uCRBvQDFjDHKuiVbRF0YVHfP TtD6vHqkb4F7jeA5kTTcdsg5XohTP1dLoVxFl/WPou8RCL5pBiC95/3ZpRjipRZ/8xai Wmsw== 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:content-transfer-encoding; bh=xP9zbcYJBgmZwREH5E65nuvUxQOYEelnLWX27Bi0Gfc=; b=Ea0UeZO3FT+a8Fw5PkXet3akR2r8kliqPpAwiIve+mpxb8YtqyQNDsPv0rYhEztUu0 zC4Fi8twXsa2Q8dirUucheGCT3PYmISfPpW1d3YMeCVOFYwj32xo6wp0XK5WgrTYQWf+ sYe1/573AdmhEcLoS0mw9VSK+O5famWf8HcZgpM9P+FBTnwzBlIrzYW9txvWh0Ts/XR5 KiolTyz/tH4UOwDAj72Oa4dxAvkRkWWOyjgoHS69M+nS6+k+dtzohwFQ72zqs9QOBc7z m5yuMMpDipL3rtXJzr9PlXZqySLykbwQcTZnXuirTtMEO81ouz0eXTNQtc3R6zqsX75N FGTw== X-Gm-Message-State: AMCzsaWFpuS4IVQeMnHsAmGRLoD7BbkRJT63KPdxP/WjRgSK6b2VLwxK DeOz7G4xew4Ea7tW+GGshvaudqs7P/uhAqk0FUo= X-Google-Smtp-Source: ABhQp+SarzmGX+8LOYtWARJ1hYxNAMDMf3ogfNh1bxxx8eCqdlXzg0yNitvdLjfAx1sCQwCGfLcXTZ+xK5Xej9cbwng= X-Received: by 10.101.91.193 with SMTP id o1mr8686581pgr.75.1509397262828; Mon, 30 Oct 2017 14:01:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.194 with HTTP; Mon, 30 Oct 2017 14:00:22 -0700 (PDT) In-Reply-To: References: From: Kathleen Moriarty Date: Mon, 30 Oct 2017 17:00:22 -0400 Message-ID: To: Richard Barnes Cc: IETF ACME Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Acme] AD review of draft-ietf-acme-acme 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, 30 Oct 2017 21:01:06 -0000 Hi Richard, Thanks for posting the diff, I reviewed the changes and they look good, but I have a couple of questions. FYI - I had started looking at the PR, but something came up, sorry for the delay and this was a good reminder. On Thu, Oct 19, 2017 at 12:45 PM, Richard Barnes wrote: > Hi Kathleen, > > Thanks for the review. Some responses inline. I've started a PR to resp= ond > to these comments here: > > https://github.com/ietf-wg-acme/acme/pull/345 > > I agree with Daniel that we should hold off on IETF LC until we've addres= sed > the issues around proactive issuance / caching of CSRs. That may require= a > re-WGLC, but once that's closed, it should be safe to send to IETF LC. > > > On Fri, Sep 22, 2017 at 4:14 PM, Kathleen Moriarty > wrote: >> >> Hello, >> >> Thank you to the editors and WG for your efforts on >> draft-ietf-acme-acme, it's a well written and easy to understand >> draft. I do have a few comments, that need to be address by the >> editors and SHEPHERD. >> >> Please review the idnits. There are a few warnings that should be >> correctable and can be addressed, but more importantly, it calls out >> several downrefs that are not in the shepherd writeup. These need to >> be in the writeup and then also mentioned in the IETF last call >> announcement (I'll make sure the latter happens). >> >> Here's my mostly editorial comments: >> >> Introduction: >> It reads very well, but it would be helpful to those unfamiliar with >> the work to explicitly state that ACME is about DV certificates. The >> first sentence of the last paragraph seems like the best place to add >> this in. >> Current text: >> This document describes an extensible framework for automating the >> issuance and domain validation procedure, thereby allowing servers >> and infrastructural software to obtain certificates without user >> interaction. >> Proposed: >> This document describes an extensible framework for automating the >> issuance and domain validation procedure for DV certificates, >> thereby allowing servers >> and infrastructural software to obtain certificates without user >> interaction. > > > As others have pointed out, ACME is not just about DV. PR has some > clarification on this point. I see the text on uses in other PKI contexts in the introduction, but don't see anything on the certificate types and out-of-band processes (as is the case for the STIR use case Mary mentioned). Maybe I'm missing it, can you tell me where to look? > > >> >> I do like how the introduction is framed as it=E2=80=99s clear the level= of >> security provided by the certificates issued via ACME. Thanks for >> that. >> >> The introduction should also make it clear that ACME can be used for >> other services using DV certificates, not just HTTP. This is >> mentioned in the Terminology section, but I think a clear sentence >> upfront would be helpful. >> >> Section 2: Nit/suggestion: Change the tense to read as a published RFC >> in the last paragraph, last sentence (take it or leave it). >> Current: >> Such close integration of ACME with HTTPS >> servers would allow the immediate and automated deployment of >> certificates as they are issued, sparing the human administrator from >> much of the time-consuming work described in the previous section. >> Proposed: >> Such close integration of ACME with HTTPS >> servers allows the immediate and automated deployment of >> certificates as they are issued, sparing the human administrator from >> much of the time-consuming work described in the previous section. > > > Done. > > >> >> IANA Section: >> Everything looks good except that RFC5226 has been obsoleted, so the >> new reference is RFC8126 and =E2=80=9Cspecification required=E2=80=9D >> https://tools.ietf.org/html/rfc8126#section-4.6 still means the same >> thing, so using that is fine. > > > Updated reference. > > >> >> Security considerations: >> I think it would be good to mention here that they are DV certs so the >> reader understands from he introduction and this section the level of >> cert issued through ACME and doesn=E2=80=99t assume a higher level of >> assurance. >> >> s/ACME is a protocol for managing certificates/ACME is a protocol for >> managing DV certificates/ > > > Given the discussion about DV, I don't think this change is appropriate. > > >> >> 10.1 - I know this is obvious to the people in the WG, but a reference >> to RFC7525 to properly configure TLS 1.2 should be included to protect >> against the mentioned attacks. If you want to also reference TLS 1.3 >> and specify no 0-RTT that would be good too. It=E2=80=99d be great to s= ee >> this get widely deployed, so there may be a number of newcomers >> reading this to make their lives easier with cert >> issuance/maintenance. > > > I don't see how TLS configuration plays into the security considerations = for > ACME. How you use the certificates you get from ACME is your business, a= nd > indeed, several of the envisioned applications have nothing to do with TL= S > (e.g., the email and STIR use cases). > > That said, I have added some language to suggest that ACME servers should > follow the advice in RFC 7525. 0xRTT should be safe here, because there = are > anti-replay protections at the application layer. Can you add a pointer in your text about the provided anti-replay protections in the application layer? Thanks, Kathleen > > >> >> 10.2 - what if the server that the account verifier has an account on >> (client for ACME) is compromised and is used to request new >> certificates or perform other actions? I think this is one of the >> larger risks, so mentioning this is possible and hardening measures >> should be taken to prevent compromise would be prudent. Hardening >> measures or appropriate security controls should be broadly understood >> terms (I think) so that you wouldn=E2=80=99t need to list out things lik= e >> turing off unnecessary services. > > > Added a brief note. > > >> >> 10.5 - I would think you=E2=80=99d see requests for new phishing domains >> rather than known ones through this process. What would you look for >> there as that=E2=80=99s a complex problem - it would be hard to know all= legit >> names to know if one was a play off of the original. This happened >> with equifax - they provided a site name with a typo and a =E2=80=98whit= e hat=E2=80=99 >> attacker had set up a site that looked just like theirs at that site. >> But it was announced by equifax. Tough problem as automating a check >> on the DNS registration may not detect something unusual, but maybe >> recommending this check could help? RDP lessens what needs to be >> shared from whois though, although I don=E2=80=99t think that=E2=80=99s = widely >> deployed. > > > This is a policy question, not one for the issuance protocol. > > --Richard > > >> >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme > > --=20 Best regards, Kathleen From nobody Mon Oct 30 15:27: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 B7FD413F58B for ; Mon, 30 Oct 2017 15:27:30 -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 KJiOM_44wb76 for ; Mon, 30 Oct 2017 15:27:28 -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 0E9C013FC35 for ; Mon, 30 Oct 2017 15:27:28 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id w105so14181439wrc.0 for ; Mon, 30 Oct 2017 15:27:27 -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=whaKEjuxr08KzX7Qhbfedf/sS3dflU6AtK5csiBW6IU=; b=x1vaFZsbMT6dDvN7bBDGWsQfOEYq77MwMaDPf4xhXVALnxm6isZD0gStYvdK0IqNQ+ seuxzMlHAWePfHr0l7AkThZsYIWA7tOubTczRgirnIE5o1rXG1vyRT+fTdPzbrkBCo4R zWnJH5ZxkqGq/T0N/iGCrNP8Cd/s4X0iN9i5+4UVAJq9xFWo8y3fz3LzTiq3m+obqtzc XYpyhYDWs1FS/kfqiffVRZnmscMFur+2wfmXsHK54+E0fj20LH0fgQBWmeWHoucXpuf8 Ko4H8zlJIMy3ulBq8dhKwyyUXjL5SQRG9rh5D1n6aPAmBmqMs9aOrZ1VEgOoANUt1IOX PSQA== 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=whaKEjuxr08KzX7Qhbfedf/sS3dflU6AtK5csiBW6IU=; b=pyry+JKyEdI/rNHh+BMqgAQidxQG0AtQQQzS31aWrYiC31X/7UZ5KIi/TgoRvkyQ4N bHKqQSTdfxXolyXeynBIjiWTNypcHVXecmcuwOJ29OWh2SIpaEv+kaN3UxR630oGSGcl QXNDtXnofc5+w4MXCAVa8w5wjzthUQaj66BGSkZNumfoR/AnSv5RnpAAO9gB5wA9go94 CNaNL4bxPCiIM+v4DRhqsSDcgvT58jYz9lk7iPVR/QG3aoGEwG2Py7l3sjSzXPPS6lS1 OasFPCeyEoKRWSd/xtIhG2WCe9bVman8PdOK6DVoMxCJkFH5+mYnhSI/mAmGGe1AIJsr s2gQ== X-Gm-Message-State: AMCzsaV3PzUFNvoAD3wupCuqEUi4UOrb9nabBRfNAtJIHVhikSUrN5t/ 96YdwY9Sva1KiJyT6qrltH1unIr5Q+9fM/m3k96kXQ== X-Google-Smtp-Source: ABhQp+Q77XHhBvBgbpXovkITFphr9c925lzdrigfxcuiwrAhG7qObC4b8m5K0XLtX2wkx1NGKT+PLSmD4PKwRTc9dEw= X-Received: by 10.223.160.132 with SMTP id m4mr8709258wrm.45.1509402446374; Mon, 30 Oct 2017 15:27:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Mon, 30 Oct 2017 15:27:25 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Mon, 30 Oct 2017 18:27:25 -0400 Message-ID: To: Kathleen Moriarty Cc: IETF ACME Content-Type: multipart/alternative; boundary="001a114b4738a3bd85055ccb247b" Archived-At: Subject: Re: [Acme] AD review of draft-ietf-acme-acme 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, 30 Oct 2017 22:27:31 -0000 --001a114b4738a3bd85055ccb247b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 30, 2017 at 5:00 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hi Richard, > > Thanks for posting the diff, I reviewed the changes and they look > good, but I have a couple of questions. FYI - I had started looking > at the PR, but something came up, sorry for the delay and this was a > good reminder. > > On Thu, Oct 19, 2017 at 12:45 PM, Richard Barnes wrote: > > Hi Kathleen, > > > > Thanks for the review. Some responses inline. I've started a PR to > respond > > to these comments here: > > > > https://github.com/ietf-wg-acme/acme/pull/345 > > > > I agree with Daniel that we should hold off on IETF LC until we've > addressed > > the issues around proactive issuance / caching of CSRs. That may > require a > > re-WGLC, but once that's closed, it should be safe to send to IETF LC. > > > > > > On Fri, Sep 22, 2017 at 4:14 PM, Kathleen Moriarty > > wrote: > >> > >> Hello, > >> > >> Thank you to the editors and WG for your efforts on > >> draft-ietf-acme-acme, it's a well written and easy to understand > >> draft. I do have a few comments, that need to be address by the > >> editors and SHEPHERD. > >> > >> Please review the idnits. There are a few warnings that should be > >> correctable and can be addressed, but more importantly, it calls out > >> several downrefs that are not in the shepherd writeup. These need to > >> be in the writeup and then also mentioned in the IETF last call > >> announcement (I'll make sure the latter happens). > >> > >> Here's my mostly editorial comments: > >> > >> Introduction: > >> It reads very well, but it would be helpful to those unfamiliar with > >> the work to explicitly state that ACME is about DV certificates. The > >> first sentence of the last paragraph seems like the best place to add > >> this in. > >> Current text: > >> This document describes an extensible framework for automating the > >> issuance and domain validation procedure, thereby allowing servers > >> and infrastructural software to obtain certificates without user > >> interaction. > >> Proposed: > >> This document describes an extensible framework for automating the > >> issuance and domain validation procedure for DV certificates, > >> thereby allowing servers > >> and infrastructural software to obtain certificates without user > >> interaction. > > > > > > As others have pointed out, ACME is not just about DV. PR has some > > clarification on this point. > > I see the text on uses in other PKI contexts in the introduction, but > don't see anything on the certificate types and out-of-band processes > (as is the case for the STIR use case Mary mentioned). Maybe I'm > missing it, can you tell me where to look? > I don't think you're missing anything. What do you mean by "certificate types and out-of-band processes"? How is that different from "other PKI contexts"? > > > > > >> > >> I do like how the introduction is framed as it=E2=80=99s clear the lev= el of > >> security provided by the certificates issued via ACME. Thanks for > >> that. > >> > >> The introduction should also make it clear that ACME can be used for > >> other services using DV certificates, not just HTTP. This is > >> mentioned in the Terminology section, but I think a clear sentence > >> upfront would be helpful. > >> > >> Section 2: Nit/suggestion: Change the tense to read as a published RFC > >> in the last paragraph, last sentence (take it or leave it). > >> Current: > >> Such close integration of ACME with HTTPS > >> servers would allow the immediate and automated deployment of > >> certificates as they are issued, sparing the human administrator fr= om > >> much of the time-consuming work described in the previous section. > >> Proposed: > >> Such close integration of ACME with HTTPS > >> servers allows the immediate and automated deployment of > >> certificates as they are issued, sparing the human administrator fr= om > >> much of the time-consuming work described in the previous section. > > > > > > Done. > > > > > >> > >> IANA Section: > >> Everything looks good except that RFC5226 has been obsoleted, so the > >> new reference is RFC8126 and =E2=80=9Cspecification required=E2=80=9D > >> https://tools.ietf.org/html/rfc8126#section-4.6 still means the same > >> thing, so using that is fine. > > > > > > Updated reference. > > > > > >> > >> Security considerations: > >> I think it would be good to mention here that they are DV certs so the > >> reader understands from he introduction and this section the level of > >> cert issued through ACME and doesn=E2=80=99t assume a higher level of > >> assurance. > >> > >> s/ACME is a protocol for managing certificates/ACME is a protocol for > >> managing DV certificates/ > > > > > > Given the discussion about DV, I don't think this change is appropriate= . > > > > > >> > >> 10.1 - I know this is obvious to the people in the WG, but a reference > >> to RFC7525 to properly configure TLS 1.2 should be included to protect > >> against the mentioned attacks. If you want to also reference TLS 1.3 > >> and specify no 0-RTT that would be good too. It=E2=80=99d be great to= see > >> this get widely deployed, so there may be a number of newcomers > >> reading this to make their lives easier with cert > >> issuance/maintenance. > > > > > > I don't see how TLS configuration plays into the security consideration= s > for > > ACME. How you use the certificates you get from ACME is your business, > and > > indeed, several of the envisioned applications have nothing to do with > TLS > > (e.g., the email and STIR use cases). > > > > That said, I have added some language to suggest that ACME servers shou= ld > > follow the advice in RFC 7525. 0xRTT should be safe here, because ther= e > are > > anti-replay protections at the application layer. > > Can you add a pointer in your text about the provided anti-replay > protections in the application layer? > Draft PR here: https://github.com/ietf-wg-acme/acme/pull/348 --Richard > > Thanks, > Kathleen > > > > > > >> > >> 10.2 - what if the server that the account verifier has an account on > >> (client for ACME) is compromised and is used to request new > >> certificates or perform other actions? I think this is one of the > >> larger risks, so mentioning this is possible and hardening measures > >> should be taken to prevent compromise would be prudent. Hardening > >> measures or appropriate security controls should be broadly understood > >> terms (I think) so that you wouldn=E2=80=99t need to list out things l= ike > >> turing off unnecessary services. > > > > > > Added a brief note. > > > > > >> > >> 10.5 - I would think you=E2=80=99d see requests for new phishing domai= ns > >> rather than known ones through this process. What would you look for > >> there as that=E2=80=99s a complex problem - it would be hard to know a= ll legit > >> names to know if one was a play off of the original. This happened > >> with equifax - they provided a site name with a typo and a =E2=80=98wh= ite hat=E2=80=99 > >> attacker had set up a site that looked just like theirs at that site. > >> But it was announced by equifax. Tough problem as automating a check > >> on the DNS registration may not detect something unusual, but maybe > >> recommending this check could help? RDP lessens what needs to be > >> shared from whois though, although I don=E2=80=99t think that=E2=80=99= s widely > >> deployed. > > > > > > This is a policy question, not one for the issuance protocol. > > > > --Richard > > > > > >> > >> > >> -- > >> > >> Best regards, > >> Kathleen > >> > >> _______________________________________________ > >> Acme mailing list > >> Acme@ietf.org > >> https://www.ietf.org/mailman/listinfo/acme > > > > > > > > -- > > Best regards, > Kathleen > --001a114b4738a3bd85055ccb247b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Oct 30, 2017 at 5:00 PM, Kathleen Moriarty &l= t;kat= hleen.moriarty.ietf@gmail.com> wrote:
Hi Richard,

Thanks for posting the diff, I reviewed the changes and they look
good, but I have a couple of questions.=C2=A0 FYI - I had started looking at the PR, but something came up, sorry for the delay and this was a
good reminder.

On Thu, Oct 19, 2017 at 12:45 PM, Richard Barnes <rlb@ipv.sx> wrote:<= br>
> Hi Kathleen,
>
> Thanks for the review.=C2=A0 Some responses inline.=C2=A0 I've sta= rted a PR to respond
> to these comments here:
>
> https://github.com/ietf-wg-acme/acme/pull/345=
>
> I agree with Daniel that we should hold off on IETF LC until we've= addressed
> the issues around proactive issuance / caching of CSRs.=C2=A0 That may= require a
> re-WGLC, but once that's closed, it should be safe to send to IETF= LC.
>
>
> On Fri, Sep 22, 2017 at 4:14 PM, Kathleen Moriarty
> <kathleen.moria= rty.ietf@gmail.com> wrote:
>>
>> Hello,
>>
>> Thank you to the editors and WG for your efforts on
>> draft-ietf-acme-acme, it's a well written and easy to understa= nd
>> draft.=C2=A0 I do have a few comments, that need to be address by = the
>> editors and SHEPHERD.
>>
>> Please review the idnits.=C2=A0 There are a few warnings that shou= ld be
>> correctable and can be addressed, but more importantly, it calls o= ut
>> several downrefs that are not in the shepherd writeup.=C2=A0 These= need to
>> be in the writeup and then also mentioned in the IETF last call >> announcement (I'll make sure the latter happens).
>>
>> Here's my mostly editorial comments:
>>
>> Introduction:
>> It reads very well, but it would be helpful to those unfamiliar wi= th
>> the work to explicitly state that ACME is about DV certificates.= =C2=A0 The
>> first sentence of the last paragraph seems like the best place to = add
>> this in.
>> Current text:
>>=C2=A0 =C2=A0 This document describes an extensible framework for a= utomating the
>>=C2=A0 =C2=A0 issuance and domain validation procedure, thereby all= owing servers
>>=C2=A0 =C2=A0 and infrastructural software to obtain certificates w= ithout user
>>=C2=A0 =C2=A0 interaction.
>> Proposed:
>>=C2=A0 =C2=A0 This document describes an extensible framework for a= utomating the
>>=C2=A0 =C2=A0 issuance and domain validation procedure for DV certi= ficates,
>> thereby allowing servers
>>=C2=A0 =C2=A0 and infrastructural software to obtain certificates w= ithout user
>>=C2=A0 =C2=A0 interaction.
>
>
> As others have pointed out, ACME is not just about DV.=C2=A0 PR has so= me
> clarification on this point.

I see the text on uses in other PKI contexts in the introductio= n, but
don't see anything on the certificate types and out-of-band processes (as is the case for the STIR use case Mary mentioned).=C2=A0 Maybe I'm<= br> missing it, can you tell me where to look?
=

I don't think you're m= issing anything.=C2=A0 What do you mean by "certificate types and out-= of-band processes"?=C2=A0 How is that different from "other PKI c= ontexts"?

=C2=A0
>
>
>>
>> I do like how the introduction is framed as it=E2=80=99s clear the= level of
>> security provided by the certificates issued via ACME.=C2=A0 Thank= s for
>> that.
>>
>> The introduction should also make it clear that ACME can be used f= or
>> other services using DV certificates, not just HTTP.=C2=A0 This is=
>> mentioned in the Terminology section, but I think a clear sentence=
>> upfront would be helpful.
>>
>> Section 2: Nit/suggestion: Change the tense to read as a published= RFC
>> in the last paragraph, last sentence (take it or leave it).
>> Current:
>>=C2=A0 =C2=A0 Such close integration of ACME with HTTPS
>>=C2=A0 =C2=A0 servers would allow the immediate and automated deplo= yment of
>>=C2=A0 =C2=A0 certificates as they are issued, sparing the human ad= ministrator from
>>=C2=A0 =C2=A0 much of the time-consuming work described in the prev= ious section.
>> Proposed:
>>=C2=A0 =C2=A0 Such close integration of ACME with HTTPS
>>=C2=A0 =C2=A0 servers allows the immediate and automated deployment= of
>>=C2=A0 =C2=A0 certificates as they are issued, sparing the human ad= ministrator from
>>=C2=A0 =C2=A0 much of the time-consuming work described in the prev= ious section.
>
>
> Done.
>
>
>>
>> IANA Section:
>> Everything looks good except that RFC5226 has been obsoleted, so t= he
>> new reference is RFC8126 and =E2=80=9Cspecification required=E2=80= =9D
>> https://tools.ietf.org/html/rfc8126#sec= tion-4.6 still means the same
>> thing, so using that is fine.
>
>
> Updated reference.
>
>
>>
>> Security considerations:
>> I think it would be good to mention here that they are DV certs so= the
>> reader understands from he introduction and this section the level= of
>> cert issued through ACME and doesn=E2=80=99t assume a higher level= of
>> assurance.
>>
>> s/ACME is a protocol for managing certificates/ACME is a protocol = for
>> managing DV certificates/
>
>
> Given the discussion about DV, I don't think this change is approp= riate.
>
>
>>
>> 10.1 - I know this is obvious to the people in the WG, but a refer= ence
>> to RFC7525 to properly configure TLS 1.2 should be included to pro= tect
>> against the mentioned attacks.=C2=A0 If you want to also reference= TLS 1.3
>> and specify no 0-RTT that would be good too.=C2=A0 It=E2=80=99d be= great to see
>> this get widely deployed, so there may be a number of newcomers >> reading this to make their lives easier with cert
>> issuance/maintenance.
>
>
> I don't see how TLS configuration plays into the security consider= ations for
> ACME.=C2=A0 How you use the certificates you get from ACME is your bus= iness, and
> indeed, several of the envisioned applications have nothing to do with= TLS
> (e.g., the email and STIR use cases).
>
> That said, I have added some language to suggest that ACME servers sho= uld
> follow the advice in RFC 7525.=C2=A0 0xRTT should be safe here, becaus= e there are
> anti-replay protections at the application layer.

Can you add a pointer in your text about the provided anti-repl= ay
protections in the application layer?

D= raft PR here:


--Richard

=C2=A0=

Thanks,
Kathleen

>
>
>>
>> 10.2 - what if the server that the account verifier has an account= on
>> (client for ACME) is compromised and is used to request new
>> certificates or perform other actions?=C2=A0 I think this is one o= f the
>> larger risks, so mentioning this is possible and hardening measure= s
>> should be taken to prevent compromise would be prudent.=C2=A0 Hard= ening
>> measures or appropriate security controls should be broadly unders= tood
>> terms (I think) so that you wouldn=E2=80=99t need to list out thin= gs like
>> turing off unnecessary services.
>
>
> Added a brief note.
>
>
>>
>> 10.5 - I would think you=E2=80=99d see requests for new phishing d= omains
>> rather than known ones through this process.=C2=A0 What would you = look for
>> there as that=E2=80=99s a complex problem - it would be hard to kn= ow all legit
>> names to know if one was a play off of the original.=C2=A0 This ha= ppened
>> with equifax - they provided a site name with a typo and a =E2=80= =98white hat=E2=80=99
>> attacker had set up a site that looked just like theirs at that si= te.
>> But it was announced by equifax.=C2=A0 Tough problem as automating= a check
>> on the DNS registration may not detect something unusual, but mayb= e
>> recommending this check could help?=C2=A0 RDP lessens what needs t= o be
>> shared from whois though, although I don=E2=80=99t think that=E2= =80=99s widely
>> deployed.
>
>
> This is a policy question, not one for the issuance protocol.
>
> --Richard
>
>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
>> _______________________________________________
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>
>



--

Best regards,
Kathleen

--001a114b4738a3bd85055ccb247b-- From nobody Mon Oct 30 15:38:12 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 243C0C250; Mon, 30 Oct 2017 15:38:10 -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.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150940309012.28222.11848892523684138848@ietfa.amsl.com> Date: Mon, 30 Oct 2017 15:38:10 -0700 Archived-At: Subject: [Acme] I-D Action: draft-ietf-acme-service-provider-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: Mon, 30 Oct 2017 22:38:10 -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 WG of the IETF. Title : ACME Identifiers and Challenges for VoIP Service Providers Authors : Mary Barnes Chris Wendt Filename : draft-ietf-acme-service-provider-02.txt Pages : 9 Date : 2017-10-30 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-02 https://datatracker.ietf.org/doc/html/draft-ietf-acme-service-provider-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-service-provider-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 Mon Oct 30 16:51:29 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 34CA6CD3A; Mon, 30 Oct 2017 16:51:21 -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.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150940748118.28306.16044830864521249687@ietfa.amsl.com> Date: Mon, 30 Oct 2017 16:51:21 -0700 Archived-At: Subject: [Acme] I-D Action: draft-ietf-acme-telephone-01.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, 30 Oct 2017 23:51:21 -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 WG of the IETF. Title : ACME Identifiers and Challenges for Telephone Numbers Authors : Jon Peterson Richard Barnes Filename : draft-ietf-acme-telephone-01.txt Pages : 8 Date : 2017-10-30 Abstract: This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificate for telephonoe numbers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-acme-telephone/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-acme-telephone-01 https://datatracker.ietf.org/doc/html/draft-ietf-acme-telephone-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-telephone-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 30 18:38: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 9C4D413FB60 for ; Mon, 30 Oct 2017 18:38:10 -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 tWo_FREZIPNY for ; Mon, 30 Oct 2017 18:38:08 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::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 D92F613FC37 for ; Mon, 30 Oct 2017 18:38:05 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id l24so13235878pgu.11 for ; Mon, 30 Oct 2017 18:38: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:content-transfer-encoding; bh=oo/X9bNfx5DVkFz7a52NYUHBwQOVAvPNkqiN7UMVefM=; b=SQ5r0TW++sW5uc+UPLDs4Ty+4ExhYztRTFUUgpxMwLWYe5DoPZgq0pOYdA3GC1hHaQ A/sNAnORzRmAVR1+Pt0EiRvNq23PD2Ebbmvj2sZU1WVwD/tdxAd8Iv5BAr5070dTiYYC vkHbflIEe5iE1upaREJjmTDHk3uocAaDgZUVkMdW0LyQ1rXct5MVSvs1Cm2FIt0gRdq3 VePx/ccE2rUaHh3XVMkyfoocAgXBTU3T/t4giBbFF76KRGlQvPmiVHYeyDqHGpW6ymc1 JhCm1Haj0TPUnm0ur8a5kyQxSh//gESMD0om2qXgW9pRaG/mVLmeyPrBL2s2kAPTlYgC 6mTg== 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:content-transfer-encoding; bh=oo/X9bNfx5DVkFz7a52NYUHBwQOVAvPNkqiN7UMVefM=; b=L6HVygzTw9tDh25alDRTWs0QEil7wSyzyVpdLSdiLzrlppqDCipsQSIt+9LAnHOETj X4VMIylG80ks4MCuHfoQehbql4rtHR5jeqqHW0QAiVkxEPCtcEWwYOYnclWQTwkL7+9Y 8+RhhsCio/ddu13Y2+jtTwkvCXvjTfIt4q00eMIPmIR2K4BPOHFuI+ZEgNDyup5O4CV6 9X9kI1tQsDw1G6QBn+In0DgIqosGv70RcWUatXK7CldCXu+gxtzNNo7UwoIS4PpuygIT CAdL89M9tZ3wJbOU359YKHR/YNn6Ne/GsHF1sFFcpxZ/l2an3mPo49ZEVfZx+Lwbotyh HzCA== X-Gm-Message-State: AMCzsaXalcFXfWBA9gcs17PVzm5sKMRvR2HiHLrVEVZbKnMlt/nLzA48 vVKXBU5Swp2na4lvTVeNYyUL8EBUCchqj1B+cWs= X-Google-Smtp-Source: ABhQp+RotlAxKznD49MAFFvvBw7WGV+I4gqHlBZRi2zFS7HszzCEtZsSmWn8wmVn2d2a+AIyJzjU0Dmd6PU01AOq5Cs= X-Received: by 10.99.113.92 with SMTP id b28mr306544pgn.42.1509413885276; Mon, 30 Oct 2017 18:38:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.194 with HTTP; Mon, 30 Oct 2017 18:37:24 -0700 (PDT) In-Reply-To: References: From: Kathleen Moriarty Date: Mon, 30 Oct 2017 21:37:24 -0400 Message-ID: To: Richard Barnes Cc: IETF ACME Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Acme] AD review of draft-ietf-acme-acme 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, 31 Oct 2017 01:38:11 -0000 Hi Richard, On Mon, Oct 30, 2017 at 6:27 PM, Richard Barnes wrote: > > > On Mon, Oct 30, 2017 at 5:00 PM, Kathleen Moriarty > wrote: >> >> Hi Richard, >> >> Thanks for posting the diff, I reviewed the changes and they look >> good, but I have a couple of questions. FYI - I had started looking >> at the PR, but something came up, sorry for the delay and this was a >> good reminder. >> >> On Thu, Oct 19, 2017 at 12:45 PM, Richard Barnes wrote: >> > Hi Kathleen, >> > >> > Thanks for the review. Some responses inline. I've started a PR to >> > respond >> > to these comments here: >> > >> > https://github.com/ietf-wg-acme/acme/pull/345 >> > >> > I agree with Daniel that we should hold off on IETF LC until we've >> > addressed >> > the issues around proactive issuance / caching of CSRs. That may >> > require a >> > re-WGLC, but once that's closed, it should be safe to send to IETF LC. >> > >> > >> > On Fri, Sep 22, 2017 at 4:14 PM, Kathleen Moriarty >> > wrote: >> >> >> >> Hello, >> >> >> >> Thank you to the editors and WG for your efforts on >> >> draft-ietf-acme-acme, it's a well written and easy to understand >> >> draft. I do have a few comments, that need to be address by the >> >> editors and SHEPHERD. >> >> >> >> Please review the idnits. There are a few warnings that should be >> >> correctable and can be addressed, but more importantly, it calls out >> >> several downrefs that are not in the shepherd writeup. These need to >> >> be in the writeup and then also mentioned in the IETF last call >> >> announcement (I'll make sure the latter happens). >> >> >> >> Here's my mostly editorial comments: >> >> >> >> Introduction: >> >> It reads very well, but it would be helpful to those unfamiliar with >> >> the work to explicitly state that ACME is about DV certificates. The >> >> first sentence of the last paragraph seems like the best place to add >> >> this in. >> >> Current text: >> >> This document describes an extensible framework for automating the >> >> issuance and domain validation procedure, thereby allowing servers >> >> and infrastructural software to obtain certificates without user >> >> interaction. >> >> Proposed: >> >> This document describes an extensible framework for automating the >> >> issuance and domain validation procedure for DV certificates, >> >> thereby allowing servers >> >> and infrastructural software to obtain certificates without user >> >> interaction. >> > >> > >> > As others have pointed out, ACME is not just about DV. PR has some >> > clarification on this point. >> >> I see the text on uses in other PKI contexts in the introduction, but >> don't see anything on the certificate types and out-of-band processes >> (as is the case for the STIR use case Mary mentioned). Maybe I'm >> missing it, can you tell me where to look? > > > I don't think you're missing anything. What do you mean by "certificate > types and out-of-band processes"? How is that different from "other PKI > contexts"? I think by PKI-context, you mean the application of use, is that right? I am separating out the type of certificate (DV, EV, etc.) as you have done in the second paragraph of the introduction. When reading the rest of the document, there isn't text that says what type of certificate ACME produces without any additional processes (out-of-band authentication/validation). If you think about administrators who operate servers (whatever the protocol) or even those who may wish to incorporate ACME into a new application, they will may have to figure out what level ACME provides as a default and also know that there can be additional processes added to obtain certificates types at a higher assurance level using ACME. Since the text already does a nice job of explaining the certificate types, this should be an easy follow up that I think will be very helpful to people outside of the IETF or who look at this in the future. Maybe something like the following: Strictly following the automation enabled by ACME, DV certificates are issued. Additional processes can be provided by the CA to increase the level of validation on an end entity to issue certificates at a higher assurance level, for instance an EV certificate. Does that help? Thinking about this in former roles and having been to some conferences lately, I think being explicit about this will help those trying to evaluate and deploy ACME. They may look for providers who meet the assurance levels they need knowing there are options and understanding the baseline provided by this spec. Thanks, Kathleen > > >> >> > >> > >> >> >> >> I do like how the introduction is framed as it=E2=80=99s clear the le= vel of >> >> security provided by the certificates issued via ACME. Thanks for >> >> that. >> >> >> >> The introduction should also make it clear that ACME can be used for >> >> other services using DV certificates, not just HTTP. This is >> >> mentioned in the Terminology section, but I think a clear sentence >> >> upfront would be helpful. >> >> >> >> Section 2: Nit/suggestion: Change the tense to read as a published RF= C >> >> in the last paragraph, last sentence (take it or leave it). >> >> Current: >> >> Such close integration of ACME with HTTPS >> >> servers would allow the immediate and automated deployment of >> >> certificates as they are issued, sparing the human administrator >> >> from >> >> much of the time-consuming work described in the previous section. >> >> Proposed: >> >> Such close integration of ACME with HTTPS >> >> servers allows the immediate and automated deployment of >> >> certificates as they are issued, sparing the human administrator >> >> from >> >> much of the time-consuming work described in the previous section. >> > >> > >> > Done. >> > >> > >> >> >> >> IANA Section: >> >> Everything looks good except that RFC5226 has been obsoleted, so the >> >> new reference is RFC8126 and =E2=80=9Cspecification required=E2=80=9D >> >> https://tools.ietf.org/html/rfc8126#section-4.6 still means the same >> >> thing, so using that is fine. >> > >> > >> > Updated reference. >> > >> > >> >> >> >> Security considerations: >> >> I think it would be good to mention here that they are DV certs so th= e >> >> reader understands from he introduction and this section the level of >> >> cert issued through ACME and doesn=E2=80=99t assume a higher level of >> >> assurance. >> >> >> >> s/ACME is a protocol for managing certificates/ACME is a protocol for >> >> managing DV certificates/ >> > >> > >> > Given the discussion about DV, I don't think this change is appropriat= e. >> > >> > >> >> >> >> 10.1 - I know this is obvious to the people in the WG, but a referenc= e >> >> to RFC7525 to properly configure TLS 1.2 should be included to protec= t >> >> against the mentioned attacks. If you want to also reference TLS 1.3 >> >> and specify no 0-RTT that would be good too. It=E2=80=99d be great t= o see >> >> this get widely deployed, so there may be a number of newcomers >> >> reading this to make their lives easier with cert >> >> issuance/maintenance. >> > >> > >> > I don't see how TLS configuration plays into the security consideratio= ns >> > for >> > ACME. How you use the certificates you get from ACME is your business= , >> > and >> > indeed, several of the envisioned applications have nothing to do with >> > TLS >> > (e.g., the email and STIR use cases). >> > >> > That said, I have added some language to suggest that ACME servers >> > should >> > follow the advice in RFC 7525. 0xRTT should be safe here, because the= re >> > are >> > anti-replay protections at the application layer. >> >> Can you add a pointer in your text about the provided anti-replay >> protections in the application layer? > > > Draft PR here: > > https://github.com/ietf-wg-acme/acme/pull/348 > > --Richard > > >> >> >> Thanks, >> Kathleen >> >> > >> > >> >> >> >> 10.2 - what if the server that the account verifier has an account on >> >> (client for ACME) is compromised and is used to request new >> >> certificates or perform other actions? I think this is one of the >> >> larger risks, so mentioning this is possible and hardening measures >> >> should be taken to prevent compromise would be prudent. Hardening >> >> measures or appropriate security controls should be broadly understoo= d >> >> terms (I think) so that you wouldn=E2=80=99t need to list out things = like >> >> turing off unnecessary services. >> > >> > >> > Added a brief note. >> > >> > >> >> >> >> 10.5 - I would think you=E2=80=99d see requests for new phishing doma= ins >> >> rather than known ones through this process. What would you look for >> >> there as that=E2=80=99s a complex problem - it would be hard to know = all legit >> >> names to know if one was a play off of the original. This happened >> >> with equifax - they provided a site name with a typo and a =E2=80=98w= hite hat=E2=80=99 >> >> attacker had set up a site that looked just like theirs at that site. >> >> But it was announced by equifax. Tough problem as automating a check >> >> on the DNS registration may not detect something unusual, but maybe >> >> recommending this check could help? RDP lessens what needs to be >> >> shared from whois though, although I don=E2=80=99t think that=E2=80= =99s widely >> >> deployed. >> > >> > >> > This is a policy question, not one for the issuance protocol. >> > >> > --Richard >> > >> > >> >> >> >> >> >> -- >> >> >> >> Best regards, >> >> Kathleen >> >> >> >> _______________________________________________ >> >> Acme mailing list >> >> Acme@ietf.org >> >> https://www.ietf.org/mailman/listinfo/acme >> > >> > >> >> >> >> -- >> >> Best regards, >> Kathleen > > --=20 Best regards, Kathleen From nobody Tue Oct 31 11:13: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 C240913FA3A for ; Tue, 31 Oct 2017 11:13:01 -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 9GkWasZ_ePFn for ; Tue, 31 Oct 2017 11:13:00 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 3AB3513FA36 for ; Tue, 31 Oct 2017 11:13:00 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id x82so21596564qkb.12 for ; Tue, 31 Oct 2017 11:13:00 -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:cc; bh=ujSvWXmUoMpbnt06PcwoG62fMj6TInHXtyaJ187axiA=; b=itVam2x8iIiwcpQ++Gcry/B6Bz8WtHYwQf9QV8LB3rX1NHaMbsFiVPPLJWsbQXzQyV 2dxYDJTSq41VeMqj8Dcncr5BcXHHn6hF3k9taxb9xy+INS1y6NuAvo4H0RnZWgDH/zTo NyL9xBI3ajBsXaJy+PBVRiLSPPuFqnbTr2RVdCPXFNzjjL2eRrn5ocbZz29DEUvXiPBK qPAnTgbxXDNtnrefDwWMPuMhSLYI4XHnQxugog7TdT5ntOusjRRS4kz4xx7fsKAzKy/K YeuDvNRs/WJjwebyBirRUHfUdUpHSk+HzOAP0wqoZSBXvQYegDn+Mg+ouEMXfX8BQWmE Wuzg== 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:cc; bh=ujSvWXmUoMpbnt06PcwoG62fMj6TInHXtyaJ187axiA=; b=i0phsGZmrFr4C76ATtwUIcoLNOVANsnL1C/31UGYf/LTnpmmhV93kd7UBGphnfTj5F VXXgteojusFMZOx+oEViZ7IgFsFg+W62meF2JYqeFVMwtyjS0IRBVCmzgpHvT5lkF/62 82ngD8GL6Q7XkqvR1q9u7NwFxqFTv2Vxf5xC1dV6xponO81Np/UygpBnWTvG7UBNxdRM /wZ+ThX5be8VgAMOS7ermbsSCcqCQxbK7xmi+9/PSCyZ/MRhQ0sUu5k0VZNZjI4uJlKX KZmYzcVWGd3xVLwW8Cgsx3APIrbO8MgemiUpB3A1eRGMiRE1uc3l2vRGtz23rKMzdpLJ oFpQ== X-Gm-Message-State: AMCzsaXe1nwQf+t+Wu1mV2HsdxjCZufkAIaYO+cKskhNCg2J5qkT5ZJU Bo+J8XGw7b2aqfp84imytcvXzDufaxQzBndnLWEMag== X-Google-Smtp-Source: ABhQp+TndJ8kkThSDM5zkMMLyB6UX6g2EqylH0Ds/38c3gyNPSz9DTJqYag+8MKx8bVd/O2Esg4S1OlmoEkXlMCclaE= X-Received: by 10.55.15.42 with SMTP id z42mr4137854qkg.181.1509473578840; Tue, 31 Oct 2017 11:12:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.36.163 with HTTP; Tue, 31 Oct 2017 11:12:58 -0700 (PDT) From: Mary Barnes Date: Tue, 31 Oct 2017 14:12:58 -0400 Message-ID: To: ACME WG Cc: Jon Peterson , Chris Wendt Content-Type: multipart/alternative; boundary="001a1147624276f777055cdbb4a1" Archived-At: Subject: [Acme] Revised and new ACME drafts for VoIP Service Providers 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, 31 Oct 2017 18:13:02 -0000 --001a1147624276f777055cdbb4a1 Content-Type: text/plain; charset="UTF-8" Hi all, I have submitted a few drafts related to the VoIP Service provider challenges. Per the discussions at IETF-99, it was suggested that we consider a generic token mechanism. I have put together an individual draft proposal for that: https://datatracker.ietf.org/doc/draft-barnes-acme-token-challenge/ I also submitted an individual draft showing how that could be used for VoIP Service Providers: https://datatracker.ietf.org/doc/draft-barnes-acme-service-provider-code/ I also made minor changes to the current WG document to address the comment with regards to token lifetimes: https://datatracker.ietf.org/doc/draft-ietf-acme-service-provider/ If we decide to define a generic mechanism, the WG version would be updated along the lines of that 2nd individual draft. Note that in parallel, Jon had put together a proposal for a generic mechanism: https://datatracker.ietf.org/doc/draft-peterson-acme-authority-token/ It's slightly different than my proposal (a little broader), but there are commonalities. I think the focus of discussion in Singapore should be on the proposals for the generic mechanism. Regards, Mary. --001a1147624276f777055cdbb4a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I have submitted a few drafts r= elated to the VoIP Service provider challenges.=C2=A0 Per the discussions a= t IETF-99, it was suggested that we consider a generic token mechanism.=C2= =A0 I have put together an individual draft proposal for that:

I also submitted an individual draft showing h= ow that could be used for VoIP Service Providers:=C2=A0

I also made minor changes to the curren= t WG document to address the comment with regards to token lifetimes:
=

If we decide to define a generic mechanis= m, the WG version would be updated along the lines of that 2nd individual d= raft.=C2=A0=C2=A0

Note that in parallel, Jon had p= ut together a proposal for a generic mechanism:

It's slightly different than my proposal (a little br= oader), but there are commonalities.=C2=A0 I think the focus of discussion = in Singapore should be on the proposals for the generic mechanism.=C2=A0=C2= =A0

Regards,
Mary.=C2=A0=C2=A0
 --001a1147624276f777055cdbb4a1-- From nobody Tue Oct 31 12:51: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 81BA113A302 for ; Tue, 31 Oct 2017 12:51:57 -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=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 7AO9bPZ9e6Ye for ; Tue, 31 Oct 2017 12:51:54 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 F36EB133047 for ; Tue, 31 Oct 2017 12:51:53 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id y83so1079748wmc.4 for ; Tue, 31 Oct 2017 12:51:53 -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=6NjNGm57RZHrkEv04h+n+x6eUIk9pCw/WGzDjiNEb2Q=; b=V+u2G5fxRPNvV8x2TX9UXLliNHgS1vxYXVegJcC3pSe7kww4NRId8r6fYDhEThFno0 np44tllodYRKez8rsQXDZTO6mMFsuIaRjjJ34BZ102j9M8RC6XdJPlfb/uyKxFyRduLW B/xShHrvpKNbSU1NP/zYljkK9Tvt2DMKUAZqpauDwVA5evk1IvShma73HVnpbJpSY/bA YHTovqsUGOgBarwfiG6pdHYZlTy88S/GCHys/XIMXW5xliutGr8BQU6v4sBTSyqqtOzV HA9hWvGfMQTDdTS+AiMJME7iBTidyBX5yiZgTT7SWN7Mj4HolGVlNvE0VdO/zM7r/t/+ 4NOQ== 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=6NjNGm57RZHrkEv04h+n+x6eUIk9pCw/WGzDjiNEb2Q=; b=mAsGdEP4N71rkPVpJlFXj0DERhRPwistKwfL5lb6Em2zfRlGM7AOmONuG5CsgYdoO9 HRmlBG+Oe9ewCYELOvqlAbE+oxicxbxIiK7BDGmXO9bQ54QRREoIHUtNTnE4KPwv9ON4 fcEb44Qc003XYnW4+CIFfgkZh7OCvcNJ5x/VKqDr+0abAdlfjElp6uTQ2CeYjWZ/6SMi 3MR/aJwe50/3oEvNP2vf5hiLTd/bwnpnvfHVCNc2Nm2WYPHTVvmhqXaPeLUklH29MYQw SJlbZxQxMC8heT3zI0ziACNXoziWPww46rVo1N9dmf4/aWd+tJUk+eezVV7vM28q42fb XzAQ== X-Gm-Message-State: AMCzsaVmJBKnoe2KGfNWpZ/WfMXx07VUT1abpXsp0KksGU/AllfhIK07 bjiCO4oSmYhpFDBlaYe4tnGyQ9qrLp6Lg1LnBJHuEg== X-Google-Smtp-Source: ABhQp+RlWGd3TOON0fKXQnHLCLZt3HL/DWa6Mg6WdtrzzvxMULHMvH+3g+ItKCWDoDNDrMQiqXHgcRYSYZ1N0i8zLxg= X-Received: by 10.28.21.10 with SMTP id 10mr131174wmv.41.1509479512175; Tue, 31 Oct 2017 12:51:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Tue, 31 Oct 2017 12:51:51 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Tue, 31 Oct 2017 15:51:51 -0400 Message-ID: To: Kathleen Moriarty Cc: IETF ACME Content-Type: multipart/alternative; boundary="001a1145a9321e899d055cdd16a0" Archived-At: Subject: Re: [Acme] AD review of draft-ietf-acme-acme 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, 31 Oct 2017 19:51:57 -0000 --001a1145a9321e899d055cdd16a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 30, 2017 at 9:37 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hi Richard, > > On Mon, Oct 30, 2017 at 6:27 PM, Richard Barnes wrote: > > > > > > On Mon, Oct 30, 2017 at 5:00 PM, Kathleen Moriarty > > wrote: > >> > >> Hi Richard, > >> > >> Thanks for posting the diff, I reviewed the changes and they look > >> good, but I have a couple of questions. FYI - I had started looking > >> at the PR, but something came up, sorry for the delay and this was a > >> good reminder. > >> > >> On Thu, Oct 19, 2017 at 12:45 PM, Richard Barnes wrote: > >> > Hi Kathleen, > >> > > >> > Thanks for the review. Some responses inline. I've started a PR to > >> > respond > >> > to these comments here: > >> > > >> > https://github.com/ietf-wg-acme/acme/pull/345 > >> > > >> > I agree with Daniel that we should hold off on IETF LC until we've > >> > addressed > >> > the issues around proactive issuance / caching of CSRs. That may > >> > require a > >> > re-WGLC, but once that's closed, it should be safe to send to IETF L= C. > >> > > >> > > >> > On Fri, Sep 22, 2017 at 4:14 PM, Kathleen Moriarty > >> > wrote: > >> >> > >> >> Hello, > >> >> > >> >> Thank you to the editors and WG for your efforts on > >> >> draft-ietf-acme-acme, it's a well written and easy to understand > >> >> draft. I do have a few comments, that need to be address by the > >> >> editors and SHEPHERD. > >> >> > >> >> Please review the idnits. There are a few warnings that should be > >> >> correctable and can be addressed, but more importantly, it calls ou= t > >> >> several downrefs that are not in the shepherd writeup. These need = to > >> >> be in the writeup and then also mentioned in the IETF last call > >> >> announcement (I'll make sure the latter happens). > >> >> > >> >> Here's my mostly editorial comments: > >> >> > >> >> Introduction: > >> >> It reads very well, but it would be helpful to those unfamiliar wit= h > >> >> the work to explicitly state that ACME is about DV certificates. T= he > >> >> first sentence of the last paragraph seems like the best place to a= dd > >> >> this in. > >> >> Current text: > >> >> This document describes an extensible framework for automating t= he > >> >> issuance and domain validation procedure, thereby allowing serve= rs > >> >> and infrastructural software to obtain certificates without user > >> >> interaction. > >> >> Proposed: > >> >> This document describes an extensible framework for automating t= he > >> >> issuance and domain validation procedure for DV certificates, > >> >> thereby allowing servers > >> >> and infrastructural software to obtain certificates without user > >> >> interaction. > >> > > >> > > >> > As others have pointed out, ACME is not just about DV. PR has some > >> > clarification on this point. > >> > >> I see the text on uses in other PKI contexts in the introduction, but > >> don't see anything on the certificate types and out-of-band processes > >> (as is the case for the STIR use case Mary mentioned). Maybe I'm > >> missing it, can you tell me where to look? > > > > > > I don't think you're missing anything. What do you mean by "certificat= e > > types and out-of-band processes"? How is that different from "other PK= I > > contexts"? > > I think by PKI-context, you mean the application of use, is that > right? I am separating out the type of certificate (DV, EV, etc.) as > you have done in the second paragraph of the introduction. When > reading the rest of the document, there isn't text that says what type > of certificate ACME produces without any additional processes > (out-of-band authentication/validation). If you think about > administrators who operate servers (whatever the protocol) or even > those who may wish to incorporate ACME into a new application, they > will may have to figure out what level ACME provides as a default and > also know that there can be additional processes added to obtain > certificates types at a higher assurance level using ACME. Since the > text already does a nice job of explaining the certificate types, this > should be an easy follow up that I think will be very helpful to > people outside of the IETF or who look at this in the future. > > Maybe something like the following: > > Strictly following the automation enabled by ACME, DV certificates > are issued. > Additional processes can be provided by the CA to increase the level o= f > validation on an end entity to issue certificates at a higher > assurance level, > for instance an EV certificate. STIR > example Mary mentioned in this thread.> > > Does that help? Thinking about this in former roles and having been > to some conferences lately, I think being explicit about this will > help those trying to evaluate and deploy ACME. They may look for > providers who meet the assurance levels they need knowing there are > options and understanding the baseline provided by this spec. > It's wrong to frame this as being about assurance levels -- you seem to be presuming that manual processes can give higher assurance than automated ones, a fact which I think has been repeatedly proven false in the web PKI. But I'm fine clarifying that certain things (like EV validation) have not yet been audited: +ACME can also be used to automate some aspects of certificate management even +where non-automated processes are still needed. For example, the external +account binding feature (see {{external-account-binding}}) can be used to +associate authorizations with an account that were not validated through the +ACME authorization process. This allows ACME to address issuance scenarios that +cannot yet be fully automated, such as the issuance of Extended Validation +certificates. Updated PR: https://github.com/ietf-wg-acme/acme/pull/348 --Richard > > Thanks, > Kathleen > > > > > > > >> > >> > > >> > > >> >> > >> >> I do like how the introduction is framed as it=E2=80=99s clear the = level of > >> >> security provided by the certificates issued via ACME. Thanks for > >> >> that. > >> >> > >> >> The introduction should also make it clear that ACME can be used fo= r > >> >> other services using DV certificates, not just HTTP. This is > >> >> mentioned in the Terminology section, but I think a clear sentence > >> >> upfront would be helpful. > >> >> > >> >> Section 2: Nit/suggestion: Change the tense to read as a published > RFC > >> >> in the last paragraph, last sentence (take it or leave it). > >> >> Current: > >> >> Such close integration of ACME with HTTPS > >> >> servers would allow the immediate and automated deployment of > >> >> certificates as they are issued, sparing the human administrator > >> >> from > >> >> much of the time-consuming work described in the previous sectio= n. > >> >> Proposed: > >> >> Such close integration of ACME with HTTPS > >> >> servers allows the immediate and automated deployment of > >> >> certificates as they are issued, sparing the human administrator > >> >> from > >> >> much of the time-consuming work described in the previous sectio= n. > >> > > >> > > >> > Done. > >> > > >> > > >> >> > >> >> IANA Section: > >> >> Everything looks good except that RFC5226 has been obsoleted, so th= e > >> >> new reference is RFC8126 and =E2=80=9Cspecification required=E2=80= =9D > >> >> https://tools.ietf.org/html/rfc8126#section-4.6 still means the sam= e > >> >> thing, so using that is fine. > >> > > >> > > >> > Updated reference. > >> > > >> > > >> >> > >> >> Security considerations: > >> >> I think it would be good to mention here that they are DV certs so > the > >> >> reader understands from he introduction and this section the level = of > >> >> cert issued through ACME and doesn=E2=80=99t assume a higher level = of > >> >> assurance. > >> >> > >> >> s/ACME is a protocol for managing certificates/ACME is a protocol f= or > >> >> managing DV certificates/ > >> > > >> > > >> > Given the discussion about DV, I don't think this change is > appropriate. > >> > > >> > > >> >> > >> >> 10.1 - I know this is obvious to the people in the WG, but a > reference > >> >> to RFC7525 to properly configure TLS 1.2 should be included to > protect > >> >> against the mentioned attacks. If you want to also reference TLS 1= .3 > >> >> and specify no 0-RTT that would be good too. It=E2=80=99d be great= to see > >> >> this get widely deployed, so there may be a number of newcomers > >> >> reading this to make their lives easier with cert > >> >> issuance/maintenance. > >> > > >> > > >> > I don't see how TLS configuration plays into the security > considerations > >> > for > >> > ACME. How you use the certificates you get from ACME is your > business, > >> > and > >> > indeed, several of the envisioned applications have nothing to do wi= th > >> > TLS > >> > (e.g., the email and STIR use cases). > >> > > >> > That said, I have added some language to suggest that ACME servers > >> > should > >> > follow the advice in RFC 7525. 0xRTT should be safe here, because > there > >> > are > >> > anti-replay protections at the application layer. > >> > >> Can you add a pointer in your text about the provided anti-replay > >> protections in the application layer? > > > > > > Draft PR here: > > > > https://github.com/ietf-wg-acme/acme/pull/348 > > > > --Richard > > > > > >> > >> > >> Thanks, > >> Kathleen > >> > >> > > >> > > >> >> > >> >> 10.2 - what if the server that the account verifier has an account = on > >> >> (client for ACME) is compromised and is used to request new > >> >> certificates or perform other actions? I think this is one of the > >> >> larger risks, so mentioning this is possible and hardening measures > >> >> should be taken to prevent compromise would be prudent. Hardening > >> >> measures or appropriate security controls should be broadly > understood > >> >> terms (I think) so that you wouldn=E2=80=99t need to list out thing= s like > >> >> turing off unnecessary services. > >> > > >> > > >> > Added a brief note. > >> > > >> > > >> >> > >> >> 10.5 - I would think you=E2=80=99d see requests for new phishing do= mains > >> >> rather than known ones through this process. What would you look f= or > >> >> there as that=E2=80=99s a complex problem - it would be hard to kno= w all > legit > >> >> names to know if one was a play off of the original. This happened > >> >> with equifax - they provided a site name with a typo and a =E2=80= =98white > hat=E2=80=99 > >> >> attacker had set up a site that looked just like theirs at that sit= e. > >> >> But it was announced by equifax. Tough problem as automating a che= ck > >> >> on the DNS registration may not detect something unusual, but maybe > >> >> recommending this check could help? RDP lessens what needs to be > >> >> shared from whois though, although I don=E2=80=99t think that=E2=80= =99s widely > >> >> deployed. > >> > > >> > > >> > This is a policy question, not one for the issuance protocol. > >> > > >> > --Richard > >> > > >> > > >> >> > >> >> > >> >> -- > >> >> > >> >> Best regards, > >> >> Kathleen > >> >> > >> >> _______________________________________________ > >> >> Acme mailing list > >> >> Acme@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/acme > >> > > >> > > >> > >> > >> > >> -- > >> > >> Best regards, > >> Kathleen > > > > > > > > -- > > Best regards, > Kathleen > --001a1145a9321e899d055cdd16a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Oct 30, 2017 at 9:37 PM, Kathleen Moriarty &l= t;kat= hleen.moriarty.ietf@gmail.com> wrote:
Hi Richard,

On Mon, Oct 30, 2017 at 6:27 PM, Richard Barnes <rlb@ipv.sx> wrote: >
>
> On Mon, Oct 30, 2017 at 5:00 PM, Kathleen Moriarty
> <kathleen.moria= rty.ietf@gmail.com> wrote:
>>
>> Hi Richard,
>>
>> Thanks for posting the diff, I reviewed the changes and they look<= br> >> good, but I have a couple of questions.=C2=A0 FYI - I had started = looking
>> at the PR, but something came up, sorry for the delay and this was= a
>> good reminder.
>>
>> On Thu, Oct 19, 2017 at 12:45 PM, Richard Barnes <rlb@ipv.sx>= ; wrote:
>> > Hi Kathleen,
>> >
>> > Thanks for the review.=C2=A0 Some responses inline.=C2=A0 I&#= 39;ve started a PR to
>> > respond
>> > to these comments here:
>> >
>> > https://github.com/ietf-wg-acme/acme= /pull/345
>> >
>> > I agree with Daniel that we should hold off on IETF LC until = we've
>> > addressed
>> > the issues around proactive issuance / caching of CSRs.=C2=A0= That may
>> > require a
>> > re-WGLC, but once that's closed, it should be safe to sen= d to IETF LC.
>> >
>> >
>> > On Fri, Sep 22, 2017 at 4:14 PM, Kathleen Moriarty
>> > <kathl= een.moriarty.ietf@gmail.com> wrote:
>> >>
>> >> Hello,
>> >>
>> >> Thank you to the editors and WG for your efforts on
>> >> draft-ietf-acme-acme, it's a well written and easy to= understand
>> >> draft.=C2=A0 I do have a few comments, that need to be ad= dress by the
>> >> editors and SHEPHERD.
>> >>
>> >> Please review the idnits.=C2=A0 There are a few warnings = that should be
>> >> correctable and can be addressed, but more importantly, i= t calls out
>> >> several downrefs that are not in the shepherd writeup.=C2= =A0 These need to
>> >> be in the writeup and then also mentioned in the IETF las= t call
>> >> announcement (I'll make sure the latter happens).
>> >>
>> >> Here's my mostly editorial comments:
>> >>
>> >> Introduction:
>> >> It reads very well, but it would be helpful to those unfa= miliar with
>> >> the work to explicitly state that ACME is about DV certif= icates.=C2=A0 The
>> >> first sentence of the last paragraph seems like the best = place to add
>> >> this in.
>> >> Current text:
>> >>=C2=A0 =C2=A0 This document describes an extensible framew= ork for automating the
>> >>=C2=A0 =C2=A0 issuance and domain validation procedure, th= ereby allowing servers
>> >>=C2=A0 =C2=A0 and infrastructural software to obtain certi= ficates without user
>> >>=C2=A0 =C2=A0 interaction.
>> >> Proposed:
>> >>=C2=A0 =C2=A0 This document describes an extensible framew= ork for automating the
>> >>=C2=A0 =C2=A0 issuance and domain validation procedure for= DV certificates,
>> >> thereby allowing servers
>> >>=C2=A0 =C2=A0 and infrastructural software to obtain certi= ficates without user
>> >>=C2=A0 =C2=A0 interaction.
>> >
>> >
>> > As others have pointed out, ACME is not just about DV.=C2=A0 = PR has some
>> > clarification on this point.
>>
>> I see the text on uses in other PKI contexts in the introduction, = but
>> don't see anything on the certificate types and out-of-band pr= ocesses
>> (as is the case for the STIR use case Mary mentioned).=C2=A0 Maybe= I'm
>> missing it, can you tell me where to look?
>
>
> I don't think you're missing anything.=C2=A0 What do you mean = by "certificate
> types and out-of-band processes"?=C2=A0 How is that different fro= m "other PKI
> contexts"?

I think by PKI-context, you mean the application of use, is tha= t
right?=C2=A0 I am separating out the type of certificate (DV, EV, etc.) as<= br> you have done in the second paragraph of the introduction.=C2=A0 When
reading the rest of the document, there isn't text that says what type<= br> of certificate ACME produces without any additional processes
(out-of-band authentication/validation).=C2=A0 If you think about
administrators who operate servers (whatever the protocol) or even
those who may wish to incorporate ACME into a new application, they
will may have to figure out what level ACME provides as a default and
also know that there can be additional processes added to obtain
certificates types at a higher assurance level using ACME.=C2=A0 Since the<= br> text already does a nice job of explaining the certificate types, this
should be an easy follow up that I think will be very helpful to
people outside of the IETF or who look at this in the future.

Maybe something like the following:

=C2=A0 =C2=A0Strictly following the automation enabled by ACME, DV certific= ates
are issued.
=C2=A0 =C2=A0Additional processes can be provided by the CA to increase the= level of
=C2=A0 =C2=A0validation on an end entity to issue certificates at a higher<= br> assurance level,
=C2=A0 =C2=A0for instance an EV certificate.=C2=A0 <Then maybe provide a= reference to the STIR
=C2=A0 =C2=A0example Mary mentioned in this thread.>

Does that help?=C2=A0 Thinking about this in former roles and having been to some conferences lately, I think being explicit about this will
help those trying to evaluate and deploy ACME.=C2=A0 They may look for
providers who meet the assurance levels they need knowing there are
options and understanding the baseline provided by this spec.


It's wrong to frame this as being= about assurance levels -- you seem to be presuming that manual processes c= an give higher assurance than automated ones, a fact which I think has been= repeatedly proven false in the web PKI.=C2=A0

But I'm fine clarifying that certain things (like EV validation) have= not yet been audited:

+ACME can also be used to automate som= e aspects of certificate management even
+where non-automated processes = are still needed.=C2=A0 For example, the external
+account binding featu= re (see {{external-account-binding}}) can be used to
+associate authoriz= ations with an account that were not validated through the
+ACME authori= zation process.=C2=A0 This allows ACME to address issuance scenarios that+cannot yet be fully automated, such as the issuance of Extended Validati= on
+certificates.


--Richard


=C2=A0

Thanks,
Kathleen


>
>
>>
>> >
>> >
>> >>
>> >> I do like how the introduction is framed as it=E2=80=99s = clear the level of
>> >> security provided by the certificates issued via ACME.=C2= =A0 Thanks for
>> >> that.
>> >>
>> >> The introduction should also make it clear that ACME can = be used for
>> >> other services using DV certificates, not just HTTP.=C2= =A0 This is
>> >> mentioned in the Terminology section, but I think a clear= sentence
>> >> upfront would be helpful.
>> >>
>> >> Section 2: Nit/suggestion: Change the tense to read as a = published RFC
>> >> in the last paragraph, last sentence (take it or leave it= ).
>> >> Current:
>> >>=C2=A0 =C2=A0 Such close integration of ACME with HTTPS >> >>=C2=A0 =C2=A0 servers would allow the immediate and automa= ted deployment of
>> >>=C2=A0 =C2=A0 certificates as they are issued, sparing the= human administrator
>> >> from
>> >>=C2=A0 =C2=A0 much of the time-consuming work described in= the previous section.
>> >> Proposed:
>> >>=C2=A0 =C2=A0 Such close integration of ACME with HTTPS >> >>=C2=A0 =C2=A0 servers allows the immediate and automated d= eployment of
>> >>=C2=A0 =C2=A0 certificates as they are issued, sparing the= human administrator
>> >> from
>> >>=C2=A0 =C2=A0 much of the time-consuming work described in= the previous section.
>> >
>> >
>> > Done.
>> >
>> >
>> >>
>> >> IANA Section:
>> >> Everything looks good except that RFC5226 has been obsole= ted, so the
>> >> new reference is RFC8126 and =E2=80=9Cspecification requi= red=E2=80=9D
>> >> https://tools.ietf.org/html/rf= c8126#section-4.6 still means the same
>> >> thing, so using that is fine.
>> >
>> >
>> > Updated reference.
>> >
>> >
>> >>
>> >> Security considerations:
>> >> I think it would be good to mention here that they are DV= certs so the
>> >> reader understands from he introduction and this section = the level of
>> >> cert issued through ACME and doesn=E2=80=99t assume a hig= her level of
>> >> assurance.
>> >>
>> >> s/ACME is a protocol for managing certificates/ACME is a = protocol for
>> >> managing DV certificates/
>> >
>> >
>> > Given the discussion about DV, I don't think this change = is appropriate.
>> >
>> >
>> >>
>> >> 10.1 - I know this is obvious to the people in the WG, bu= t a reference
>> >> to RFC7525 to properly configure TLS 1.2 should be includ= ed to protect
>> >> against the mentioned attacks.=C2=A0 If you want to also = reference TLS 1.3
>> >> and specify no 0-RTT that would be good too.=C2=A0 It=E2= =80=99d be great to see
>> >> this get widely deployed, so there may be a number of new= comers
>> >> reading this to make their lives easier with cert
>> >> issuance/maintenance.
>> >
>> >
>> > I don't see how TLS configuration plays into the security= considerations
>> > for
>> > ACME.=C2=A0 How you use the certificates you get from ACME is= your business,
>> > and
>> > indeed, several of the envisioned applications have nothing t= o do with
>> > TLS
>> > (e.g., the email and STIR use cases).
>> >
>> > That said, I have added some language to suggest that ACME se= rvers
>> > should
>> > follow the advice in RFC 7525.=C2=A0 0xRTT should be safe her= e, because there
>> > are
>> > anti-replay protections at the application layer.
>>
>> Can you add a pointer in your text about the provided anti-replay<= br> >> protections in the application layer?
>
>
> Draft PR here:
>
> https://github.com/ietf-wg-acme/acme/pull/348=
>
> --Richard
>
>
>>
>>
>> Thanks,
>> Kathleen
>>
>> >
>> >
>> >>
>> >> 10.2 - what if the server that the account verifier has a= n account on
>> >> (client for ACME) is compromised and is used to request n= ew
>> >> certificates or perform other actions?=C2=A0 I think this= is one of the
>> >> larger risks, so mentioning this is possible and hardenin= g measures
>> >> should be taken to prevent compromise would be prudent.= =C2=A0 Hardening
>> >> measures or appropriate security controls should be broad= ly understood
>> >> terms (I think) so that you wouldn=E2=80=99t need to list= out things like
>> >> turing off unnecessary services.
>> >
>> >
>> > Added a brief note.
>> >
>> >
>> >>
>> >> 10.5 - I would think you=E2=80=99d see requests for new p= hishing domains
>> >> rather than known ones through this process.=C2=A0 What w= ould you look for
>> >> there as that=E2=80=99s a complex problem - it would be h= ard to know all legit
>> >> names to know if one was a play off of the original.=C2= =A0 This happened
>> >> with equifax - they provided a site name with a typo and = a =E2=80=98white hat=E2=80=99
>> >> attacker had set up a site that looked just like theirs a= t that site.
>> >> But it was announced by equifax.=C2=A0 Tough problem as a= utomating a check
>> >> on the DNS registration may not detect something unusual,= but maybe
>> >> recommending this check could help?=C2=A0 RDP lessens wha= t needs to be
>> >> shared from whois though, although I don=E2=80=99t think = that=E2=80=99s widely
>> >> deployed.
>> >
>> >
>> > This is a policy question, not one for the issuance protocol.=
>> >
>> > --Richard
>> >
>> >
>> >>
>> >>
>> >> --
>> >>
>> >> Best regards,
>> >> Kathleen
>> >>
>> >> _______________________________________________
>> >> Acme mailing list
>> >> Acme@ietf.org
>> >> https://www.ietf.org/mailman/listin= fo/acme
>> >
>> >
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>
>



--

Best regards,
Kathleen

--001a1145a9321e899d055cdd16a0-- From nobody Tue Oct 31 13:40: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 E87DA13F6D9 for ; Tue, 31 Oct 2017 13:40:15 -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 8SMkBAi2osnl for ; Tue, 31 Oct 2017 13:40:12 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002: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 D7A99139478 for ; Tue, 31 Oct 2017 13:40:11 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id q126so218766ywq.10 for ; Tue, 31 Oct 2017 13:40:11 -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=gZqH0WCj9dkPIEMlhWBtwVCITdPIjnZIyrRwontkyGM=; b=KtnKqIZaX+GOHSlPQq+8DIvuINImgu+NNBkFIwvqufZ2pcEWXbZ7l5X/KgLrHpOKTP 3UIO1+Mb56rqq++JVSYFGF2JyrznYkxBRWfsyMnBY5ggdK8pg8HMwrKSjjNmQMMCzSML SL3cdlf0OYLrqXFTHTYvwc3LaGgX9E2JolVTrch6tMaHlZcUW5AprurKV+7oeK3bqyvy PlsmW41HbHJpVBcH/GkEWs5gMYxFHpkrMPozu70aN5LFDOd7pQbW8ix3r8WAhyvwTM5C RFtUeGM9l+t9VYuGT53Oo+/jmuLc7WvT46jvjXZ6cHHPccm2ZPdrLBsQLBtSh9Yc0Ipo FzTA== 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=gZqH0WCj9dkPIEMlhWBtwVCITdPIjnZIyrRwontkyGM=; b=S35EjrMJP9/RFdi5i3IsuyMQPywFTxPI4OK7qUh5f9LuN+w4AfyATLURc3k+V5U3Jm PItql+NO2/Eldj2o8UWmr6D6qK7I/u/uL+etlHsknohCTZ65IvbTDi75WLkqlQujDOdJ N38qEozeUPqevW0AMsAxMcNx3CCFYaNAuQY/wUQg4zbw6LHhwg48InXkDykioOWDha7G P78BhEDSuGZQ/tD0YWH/ocDhM7kEpzql1AFA0jexpWqsfNtvApMUNWnhV9gOYbneLpS4 OyqArmIeTNk3U3BmcxFu37B97tV5pn2bMI371kCmxyf7T0X2f3QuQv6FMpcw2pkU2SM3 sbQQ== X-Gm-Message-State: AMCzsaU4N0Wxdvr8Tm8ZAQIJOdYOqnkHkPt8+BF/EDCaewFnaOfcbI3h U5e9GXHZ05pltb9cg8oitAcnFTSNMlqILmnsIRzFwD5n X-Google-Smtp-Source: ABhQp+Tu2QvmSF+b+UT/tfViGjwObY33l6mbpYuXqxYFe7V+Zm+kE0y9CvU02iwHSLlMT6omlxg3V+ZJTDAK3cqnToA= X-Received: by 10.129.108.3 with SMTP id h3mr2089573ywc.327.1509482411071; Tue, 31 Oct 2017 13:40:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Tue, 31 Oct 2017 13:39:30 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 31 Oct 2017 13:39:30 -0700 Message-ID: To: Richard Barnes Cc: Kathleen Moriarty , IETF ACME Content-Type: multipart/alternative; boundary="001a114d9a28e840e0055cddc2de" Archived-At: Subject: Re: [Acme] AD review of draft-ietf-acme-acme 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, 31 Oct 2017 20:40:16 -0000 --001a114d9a28e840e0055cddc2de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 31, 2017 at 12:51 PM, Richard Barnes wrote: > > > On Mon, Oct 30, 2017 at 9:37 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> Hi Richard, >> >> On Mon, Oct 30, 2017 at 6:27 PM, Richard Barnes wrote: >> > >> > >> > On Mon, Oct 30, 2017 at 5:00 PM, Kathleen Moriarty >> > wrote: >> >> >> >> Hi Richard, >> >> >> >> Thanks for posting the diff, I reviewed the changes and they look >> >> good, but I have a couple of questions. FYI - I had started looking >> >> at the PR, but something came up, sorry for the delay and this was a >> >> good reminder. >> >> >> >> On Thu, Oct 19, 2017 at 12:45 PM, Richard Barnes wrote: >> >> > Hi Kathleen, >> >> > >> >> > Thanks for the review. Some responses inline. I've started a PR t= o >> >> > respond >> >> > to these comments here: >> >> > >> >> > https://github.com/ietf-wg-acme/acme/pull/345 >> >> > >> >> > I agree with Daniel that we should hold off on IETF LC until we've >> >> > addressed >> >> > the issues around proactive issuance / caching of CSRs. That may >> >> > require a >> >> > re-WGLC, but once that's closed, it should be safe to send to IETF >> LC. >> >> > >> >> > >> >> > On Fri, Sep 22, 2017 at 4:14 PM, Kathleen Moriarty >> >> > wrote: >> >> >> >> >> >> Hello, >> >> >> >> >> >> Thank you to the editors and WG for your efforts on >> >> >> draft-ietf-acme-acme, it's a well written and easy to understand >> >> >> draft. I do have a few comments, that need to be address by the >> >> >> editors and SHEPHERD. >> >> >> >> >> >> Please review the idnits. There are a few warnings that should be >> >> >> correctable and can be addressed, but more importantly, it calls o= ut >> >> >> several downrefs that are not in the shepherd writeup. These need >> to >> >> >> be in the writeup and then also mentioned in the IETF last call >> >> >> announcement (I'll make sure the latter happens). >> >> >> >> >> >> Here's my mostly editorial comments: >> >> >> >> >> >> Introduction: >> >> >> It reads very well, but it would be helpful to those unfamiliar wi= th >> >> >> the work to explicitly state that ACME is about DV certificates. >> The >> >> >> first sentence of the last paragraph seems like the best place to >> add >> >> >> this in. >> >> >> Current text: >> >> >> This document describes an extensible framework for automating >> the >> >> >> issuance and domain validation procedure, thereby allowing >> servers >> >> >> and infrastructural software to obtain certificates without use= r >> >> >> interaction. >> >> >> Proposed: >> >> >> This document describes an extensible framework for automating >> the >> >> >> issuance and domain validation procedure for DV certificates, >> >> >> thereby allowing servers >> >> >> and infrastructural software to obtain certificates without use= r >> >> >> interaction. >> >> > >> >> > >> >> > As others have pointed out, ACME is not just about DV. PR has some >> >> > clarification on this point. >> >> >> >> I see the text on uses in other PKI contexts in the introduction, but >> >> don't see anything on the certificate types and out-of-band processes >> >> (as is the case for the STIR use case Mary mentioned). Maybe I'm >> >> missing it, can you tell me where to look? >> > >> > >> > I don't think you're missing anything. What do you mean by "certifica= te >> > types and out-of-band processes"? How is that different from "other P= KI >> > contexts"? >> >> I think by PKI-context, you mean the application of use, is that >> right? I am separating out the type of certificate (DV, EV, etc.) as >> you have done in the second paragraph of the introduction. When >> reading the rest of the document, there isn't text that says what type >> of certificate ACME produces without any additional processes >> (out-of-band authentication/validation). If you think about >> administrators who operate servers (whatever the protocol) or even >> those who may wish to incorporate ACME into a new application, they >> will may have to figure out what level ACME provides as a default and >> also know that there can be additional processes added to obtain >> certificates types at a higher assurance level using ACME. Since the >> text already does a nice job of explaining the certificate types, this >> should be an easy follow up that I think will be very helpful to >> people outside of the IETF or who look at this in the future. >> >> Maybe something like the following: >> >> Strictly following the automation enabled by ACME, DV certificates >> are issued. >> Additional processes can be provided by the CA to increase the level = of >> validation on an end entity to issue certificates at a higher >> assurance level, >> for instance an EV certificate. > the STIR >> example Mary mentioned in this thread.> >> >> Does that help? Thinking about this in former roles and having been >> to some conferences lately, I think being explicit about this will >> help those trying to evaluate and deploy ACME. They may look for >> providers who meet the assurance levels they need knowing there are >> options and understanding the baseline provided by this spec. >> > > > It's wrong to frame this as being about assurance levels -- you seem to b= e > presuming that manual processes can give higher assurance than automated > ones, a fact which I think has been repeatedly proven false in the web > PKI. > > But I'm fine clarifying that certain things (like EV validation) have not > yet been audited: > You mean "automated", right? > > +ACME can also be used to automate some aspects of certificate management > even > +where non-automated processes are still needed. For example, the extern= al > +account binding feature (see {{external-account-binding}}) can be used t= o > +associate authorizations with an account that were not validated through > the > +ACME authorization process. This allows ACME to address issuance > scenarios that > +cannot yet be fully automated, such as the issuance of Extended Validati= on > +certificates. > > Updated PR: https://github.com/ietf-wg-acme/acme/pull/348 > > --Richard > > > > >> >> Thanks, >> Kathleen >> >> >> > >> > >> >> >> >> > >> >> > >> >> >> >> >> >> I do like how the introduction is framed as it=E2=80=99s clear the= level of >> >> >> security provided by the certificates issued via ACME. Thanks for >> >> >> that. >> >> >> >> >> >> The introduction should also make it clear that ACME can be used f= or >> >> >> other services using DV certificates, not just HTTP. This is >> >> >> mentioned in the Terminology section, but I think a clear sentence >> >> >> upfront would be helpful. >> >> >> >> >> >> Section 2: Nit/suggestion: Change the tense to read as a published >> RFC >> >> >> in the last paragraph, last sentence (take it or leave it). >> >> >> Current: >> >> >> Such close integration of ACME with HTTPS >> >> >> servers would allow the immediate and automated deployment of >> >> >> certificates as they are issued, sparing the human administrato= r >> >> >> from >> >> >> much of the time-consuming work described in the previous >> section. >> >> >> Proposed: >> >> >> Such close integration of ACME with HTTPS >> >> >> servers allows the immediate and automated deployment of >> >> >> certificates as they are issued, sparing the human administrato= r >> >> >> from >> >> >> much of the time-consuming work described in the previous >> section. >> >> > >> >> > >> >> > Done. >> >> > >> >> > >> >> >> >> >> >> IANA Section: >> >> >> Everything looks good except that RFC5226 has been obsoleted, so t= he >> >> >> new reference is RFC8126 and =E2=80=9Cspecification required=E2=80= =9D >> >> >> https://tools.ietf.org/html/rfc8126#section-4.6 still means the >> same >> >> >> thing, so using that is fine. >> >> > >> >> > >> >> > Updated reference. >> >> > >> >> > >> >> >> >> >> >> Security considerations: >> >> >> I think it would be good to mention here that they are DV certs so >> the >> >> >> reader understands from he introduction and this section the level >> of >> >> >> cert issued through ACME and doesn=E2=80=99t assume a higher level= of >> >> >> assurance. >> >> >> >> >> >> s/ACME is a protocol for managing certificates/ACME is a protocol >> for >> >> >> managing DV certificates/ >> >> > >> >> > >> >> > Given the discussion about DV, I don't think this change is >> appropriate. >> >> > >> >> > >> >> >> >> >> >> 10.1 - I know this is obvious to the people in the WG, but a >> reference >> >> >> to RFC7525 to properly configure TLS 1.2 should be included to >> protect >> >> >> against the mentioned attacks. If you want to also reference TLS >> 1.3 >> >> >> and specify no 0-RTT that would be good too. It=E2=80=99d be grea= t to see >> >> >> this get widely deployed, so there may be a number of newcomers >> >> >> reading this to make their lives easier with cert >> >> >> issuance/maintenance. >> >> > >> >> > >> >> > I don't see how TLS configuration plays into the security >> considerations >> >> > for >> >> > ACME. How you use the certificates you get from ACME is your >> business, >> >> > and >> >> > indeed, several of the envisioned applications have nothing to do >> with >> >> > TLS >> >> > (e.g., the email and STIR use cases). >> >> > >> >> > That said, I have added some language to suggest that ACME servers >> >> > should >> >> > follow the advice in RFC 7525. 0xRTT should be safe here, because >> there >> >> > are >> >> > anti-replay protections at the application layer. >> >> >> >> Can you add a pointer in your text about the provided anti-replay >> >> protections in the application layer? >> > >> > >> > Draft PR here: >> > >> > https://github.com/ietf-wg-acme/acme/pull/348 >> > >> > --Richard >> > >> > >> >> >> >> >> >> Thanks, >> >> Kathleen >> >> >> >> > >> >> > >> >> >> >> >> >> 10.2 - what if the server that the account verifier has an account >> on >> >> >> (client for ACME) is compromised and is used to request new >> >> >> certificates or perform other actions? I think this is one of the >> >> >> larger risks, so mentioning this is possible and hardening measure= s >> >> >> should be taken to prevent compromise would be prudent. Hardening >> >> >> measures or appropriate security controls should be broadly >> understood >> >> >> terms (I think) so that you wouldn=E2=80=99t need to list out thin= gs like >> >> >> turing off unnecessary services. >> >> > >> >> > >> >> > Added a brief note. >> >> > >> >> > >> >> >> >> >> >> 10.5 - I would think you=E2=80=99d see requests for new phishing d= omains >> >> >> rather than known ones through this process. What would you look >> for >> >> >> there as that=E2=80=99s a complex problem - it would be hard to kn= ow all >> legit >> >> >> names to know if one was a play off of the original. This happene= d >> >> >> with equifax - they provided a site name with a typo and a =E2=80= =98white >> hat=E2=80=99 >> >> >> attacker had set up a site that looked just like theirs at that >> site. >> >> >> But it was announced by equifax. Tough problem as automating a >> check >> >> >> on the DNS registration may not detect something unusual, but mayb= e >> >> >> recommending this check could help? RDP lessens what needs to be >> >> >> shared from whois though, although I don=E2=80=99t think that=E2= =80=99s widely >> >> >> deployed. >> >> > >> >> > >> >> > This is a policy question, not one for the issuance protocol. >> >> > >> >> > --Richard >> >> > >> >> > >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> >> Best regards, >> >> >> Kathleen >> >> >> >> >> >> _______________________________________________ >> >> >> Acme mailing list >> >> >> Acme@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/acme >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> >> >> Best regards, >> >> Kathleen >> > >> > >> >> >> >> -- >> >> Best regards, >> Kathleen >> > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --001a114d9a28e840e0055cddc2de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Oct 31, 2017 at 12:51 PM, Richard Barnes <= rlb@ipv.sx> w= rote:


On Mon, = Oct 30, 2017 at 9:37 PM, Kathleen Moriarty <kathleen.moriar= ty.ietf@gmail.com> wrote:
Hi Richard,

On Mon, Oct 30, 2017 at 6:27 PM, Richard Barnes <rlb@ipv.sx> wrote: >
>
> On Mon, Oct 30, 2017 at 5:00 PM, Kathleen Moriarty
> <kathleen.moriarty.ietf@gmail.com> wrote:
>>
>> Hi Richard,
>>
>> Thanks for posting the diff, I reviewed the changes and they look<= br> >> good, but I have a couple of questions.=C2=A0 FYI - I had started = looking
>> at the PR, but something came up, sorry for the delay and this was= a
>> good reminder.
>>
>> On Thu, Oct 19, 2017 at 12:45 PM, Richard Barnes <rlb@ipv.sx>= ; wrote:
>> > Hi Kathleen,
>> >
>> > Thanks for the review.=C2=A0 Some responses inline.=C2=A0 I&#= 39;ve started a PR to
>> > respond
>> > to these comments here:
>> >
>> > https://github.com/ietf-wg-acme/acme= /pull/345
>> >
>> > I agree with Daniel that we should hold off on IETF LC until = we've
>> > addressed
>> > the issues around proactive issuance / caching of CSRs.=C2=A0= That may
>> > require a
>> > re-WGLC, but once that's closed, it should be safe to sen= d to IETF LC.
>> >
>> >
>> > On Fri, Sep 22, 2017 at 4:14 PM, Kathleen Moriarty
>> > <kathleen.moriarty.ietf@gmail.com> wrote:
>> >>
>> >> Hello,
>> >>
>> >> Thank you to the editors and WG for your efforts on
>> >> draft-ietf-acme-acme, it's a well written and easy to= understand
>> >> draft.=C2=A0 I do have a few comments, that need to be ad= dress by the
>> >> editors and SHEPHERD.
>> >>
>> >> Please review the idnits.=C2=A0 There are a few warnings = that should be
>> >> correctable and can be addressed, but more importantly, i= t calls out
>> >> several downrefs that are not in the shepherd writeup.=C2= =A0 These need to
>> >> be in the writeup and then also mentioned in the IETF las= t call
>> >> announcement (I'll make sure the latter happens).
>> >>
>> >> Here's my mostly editorial comments:
>> >>
>> >> Introduction:
>> >> It reads very well, but it would be helpful to those unfa= miliar with
>> >> the work to explicitly state that ACME is about DV certif= icates.=C2=A0 The
>> >> first sentence of the last paragraph seems like the best = place to add
>> >> this in.
>> >> Current text:
>> >>=C2=A0 =C2=A0 This document describes an extensible framew= ork for automating the
>> >>=C2=A0 =C2=A0 issuance and domain validation procedure, th= ereby allowing servers
>> >>=C2=A0 =C2=A0 and infrastructural software to obtain certi= ficates without user
>> >>=C2=A0 =C2=A0 interaction.
>> >> Proposed:
>> >>=C2=A0 =C2=A0 This document describes an extensible framew= ork for automating the
>> >>=C2=A0 =C2=A0 issuance and domain validation procedure for= DV certificates,
>> >> thereby allowing servers
>> >>=C2=A0 =C2=A0 and infrastructural software to obtain certi= ficates without user
>> >>=C2=A0 =C2=A0 interaction.
>> >
>> >
>> > As others have pointed out, ACME is not just about DV.=C2=A0 = PR has some
>> > clarification on this point.
>>
>> I see the text on uses in other PKI contexts in the introduction, = but
>> don't see anything on the certificate types and out-of-band pr= ocesses
>> (as is the case for the STIR use case Mary mentioned).=C2=A0 Maybe= I'm
>> missing it, can you tell me where to look?
>
>
> I don't think you're missing anything.=C2=A0 What do you mean = by "certificate
> types and out-of-band processes"?=C2=A0 How is that different fro= m "other PKI
> contexts"?

I think by PKI-context, you mean the application of use, is tha= t
right?=C2=A0 I am separating out the type of certificate (DV, EV, etc.) as<= br> you have done in the second paragraph of the introduction.=C2=A0 When
reading the rest of the document, there isn't text that says what type<= br> of certificate ACME produces without any additional processes
(out-of-band authentication/validation).=C2=A0 If you think about
administrators who operate servers (whatever the protocol) or even
those who may wish to incorporate ACME into a new application, they
will may have to figure out what level ACME provides as a default and
also know that there can be additional processes added to obtain
certificates types at a higher assurance level using ACME.=C2=A0 Since the<= br> text already does a nice job of explaining the certificate types, this
should be an easy follow up that I think will be very helpful to
people outside of the IETF or who look at this in the future.

Maybe something like the following:

=C2=A0 =C2=A0Strictly following the automation enabled by ACME, DV certific= ates
are issued.
=C2=A0 =C2=A0Additional processes can be provided by the CA to increase the= level of
=C2=A0 =C2=A0validation on an end entity to issue certificates at a higher<= br> assurance level,
=C2=A0 =C2=A0for instance an EV certificate.=C2=A0 <Then maybe provide a= reference to the STIR
=C2=A0 =C2=A0example Mary mentioned in this thread.>

Does that help?=C2=A0 Thinking about this in former roles and having been to some conferences lately, I think being explicit about this will
help those trying to evaluate and deploy ACME.=C2=A0 They may look for
providers who meet the assurance levels they need knowing there are
options and understanding the baseline provided by this spec.


It's wrong to frame t= his as being about assurance levels -- you seem to be presuming that manual= processes can give higher assurance than automated ones, a fact which I th= ink has been repeatedly proven false in the web PKI.=C2=A0
<= br>
But I'm fine clarifying that certain things (like EV vali= dation) have not yet been audited:

You mean "automated", right?

=
=C2=A0

+ACME can also be used= to automate some aspects of certificate management even
+where non-auto= mated processes are still needed.=C2=A0 For example, the external
+accou= nt binding feature (see {{external-account-binding}}) can be used to
+as= sociate authorizations with an account that were not validated through the<= br>+ACME authorization process.=C2=A0 This allows ACME to address issuance = scenarios that
+cannot yet be fully automated, such as the issuance of E= xtended Validation
+certificates.


--Richard


=
=C2=A0

Thanks,
Kathleen


>
>
>>
>> >
>> >
>> >>
>> >> I do like how the introduction is framed as it=E2=80=99s = clear the level of
>> >> security provided by the certificates issued via ACME.=C2= =A0 Thanks for
>> >> that.
>> >>
>> >> The introduction should also make it clear that ACME can = be used for
>> >> other services using DV certificates, not just HTTP.=C2= =A0 This is
>> >> mentioned in the Terminology section, but I think a clear= sentence
>> >> upfront would be helpful.
>> >>
>> >> Section 2: Nit/suggestion: Change the tense to read as a = published RFC
>> >> in the last paragraph, last sentence (take it or leave it= ).
>> >> Current:
>> >>=C2=A0 =C2=A0 Such close integration of ACME with HTTPS >> >>=C2=A0 =C2=A0 servers would allow the immediate and automa= ted deployment of
>> >>=C2=A0 =C2=A0 certificates as they are issued, sparing the= human administrator
>> >> from
>> >>=C2=A0 =C2=A0 much of the time-consuming work described in= the previous section.
>> >> Proposed:
>> >>=C2=A0 =C2=A0 Such close integration of ACME with HTTPS >> >>=C2=A0 =C2=A0 servers allows the immediate and automated d= eployment of
>> >>=C2=A0 =C2=A0 certificates as they are issued, sparing the= human administrator
>> >> from
>> >>=C2=A0 =C2=A0 much of the time-consuming work described in= the previous section.
>> >
>> >
>> > Done.
>> >
>> >
>> >>
>> >> IANA Section:
>> >> Everything looks good except that RFC5226 has been obsole= ted, so the
>> >> new reference is RFC8126 and =E2=80=9Cspecification requi= red=E2=80=9D
>> >> https://tools.ietf.org/html/rf= c8126#section-4.6 still means the same
>> >> thing, so using that is fine.
>> >
>> >
>> > Updated reference.
>> >
>> >
>> >>
>> >> Security considerations:
>> >> I think it would be good to mention here that they are DV= certs so the
>> >> reader understands from he introduction and this section = the level of
>> >> cert issued through ACME and doesn=E2=80=99t assume a hig= her level of
>> >> assurance.
>> >>
>> >> s/ACME is a protocol for managing certificates/ACME is a = protocol for
>> >> managing DV certificates/
>> >
>> >
>> > Given the discussion about DV, I don't think this change = is appropriate.
>> >
>> >
>> >>
>> >> 10.1 - I know this is obvious to the people in the WG, bu= t a reference
>> >> to RFC7525 to properly configure TLS 1.2 should be includ= ed to protect
>> >> against the mentioned attacks.=C2=A0 If you want to also = reference TLS 1.3
>> >> and specify no 0-RTT that would be good too.=C2=A0 It=E2= =80=99d be great to see
>> >> this get widely deployed, so there may be a number of new= comers
>> >> reading this to make their lives easier with cert
>> >> issuance/maintenance.
>> >
>> >
>> > I don't see how TLS configuration plays into the security= considerations
>> > for
>> > ACME.=C2=A0 How you use the certificates you get from ACME is= your business,
>> > and
>> > indeed, several of the envisioned applications have nothing t= o do with
>> > TLS
>> > (e.g., the email and STIR use cases).
>> >
>> > That said, I have added some language to suggest that ACME se= rvers
>> > should
>> > follow the advice in RFC 7525.=C2=A0 0xRTT should be safe her= e, because there
>> > are
>> > anti-replay protections at the application layer.
>>
>> Can you add a pointer in your text about the provided anti-replay<= br> >> protections in the application layer?
>
>
> Draft PR here:
>
> https://github.com/ietf-wg-acme/acme/pull/348=
>
> --Richard
>
>
>>
>>
>> Thanks,
>> Kathleen
>>
>> >
>> >
>> >>
>> >> 10.2 - what if the server that the account verifier has a= n account on
>> >> (client for ACME) is compromised and is used to request n= ew
>> >> certificates or perform other actions?=C2=A0 I think this= is one of the
>> >> larger risks, so mentioning this is possible and hardenin= g measures
>> >> should be taken to prevent compromise would be prudent.= =C2=A0 Hardening
>> >> measures or appropriate security controls should be broad= ly understood
>> >> terms (I think) so that you wouldn=E2=80=99t need to list= out things like
>> >> turing off unnecessary services.
>> >
>> >
>> > Added a brief note.
>> >
>> >
>> >>
>> >> 10.5 - I would think you=E2=80=99d see requests for new p= hishing domains
>> >> rather than known ones through this process.=C2=A0 What w= ould you look for
>> >> there as that=E2=80=99s a complex problem - it would be h= ard to know all legit
>> >> names to know if one was a play off of the original.=C2= =A0 This happened
>> >> with equifax - they provided a site name with a typo and = a =E2=80=98white hat=E2=80=99
>> >> attacker had set up a site that looked just like theirs a= t that site.
>> >> But it was announced by equifax.=C2=A0 Tough problem as a= utomating a check
>> >> on the DNS registration may not detect something unusual,= but maybe
>> >> recommending this check could help?=C2=A0 RDP lessens wha= t needs to be
>> >> shared from whois though, although I don=E2=80=99t think = that=E2=80=99s widely
>> >> deployed.
>> >
>> >
>> > This is a policy question, not one for the issuance protocol.=
>> >
>> > --Richard
>> >
>> >
>> >>
>> >>
>> >> --
>> >>
>> >> Best regards,
>> >> Kathleen
>> >>
>> >> _______________________________________________
>> >> Acme mailing list
>> >> Acme@i= etf.org
>> >> https://www.ietf.org/mailman/listin= fo/acme
>> >
>> >
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>
>



--

Best regards,
Kathleen


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


--001a114d9a28e840e0055cddc2de-- From nobody Tue Oct 31 16:10: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 DF10813F7E1 for ; Tue, 31 Oct 2017 16:10:01 -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 X8flJKuaf7tX for ; Tue, 31 Oct 2017 16:09:58 -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 5E89513F43E for ; Tue, 31 Oct 2017 16:09:58 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id l1so495876wrc.3 for ; Tue, 31 Oct 2017 16:09:58 -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=wPXhJqZj4Mwe9opYBnLtLvroCBvIYT3De/sg86Kmwtw=; b=wAuE6hntELjnUc/RvAICkBsRCZRhxu8O5Xrf38TzPPIp+OlSZqtC5fc2SGi59PJS+v q3trCeM6MPdcA3Qa79+V5K0h+E1/tJHNouiVsiIthu9iBB67mY0trbRDFreAMtWz49q2 vg0Q7jrCKOd+xuQwj0C/kXxSbDVLqCJOwpR05WkaOKs865S3gO0NCf2AlK7eF0jJoE2z UBzfegAE/XtAiFvIBws/L1zmoxrTILvJ/BI9NlyxRper+1nawCc3Z88bX3hubyJsspW/ jL6Bf4s3WRiuJ0DVg8JuH0oJeVLy/89Lfq5kMqkHozgRBN02HLb26FTnFzRwi36IgzRQ cEdg== 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=wPXhJqZj4Mwe9opYBnLtLvroCBvIYT3De/sg86Kmwtw=; b=oskZ/hDL0uf8NMu7JNK6/yIONKM6/jl21O711JTJvb4lKH3KKf3pJ7GJS8yBcJiAJi 77P2J07lwIHGNCW28EORrI9bCwevFOtHbbqLAiNGGJJ/NcJOo9ffnoOQXw8z33Yv3sJ+ LVG5Di62arXAjdftlqqpkGDr0a+T8L0A/GZEk1AZpAlXTk9Jb1ICQKGVJIVaGjXP1jRa UdsJbenHHW3laawQcKMqkQGsqksrYdmkixNBO2OMr3F8DQyZErNqEdfxzwvWp50r9/9j nFLN2nxaE69abfHMcExdkZsbhccUDfBZHFwdzgU5bB18bNkg1/o72phDJCE1JxDtUswl f5DA== X-Gm-Message-State: AMCzsaUR97t/i199OxCyioMlzOys8tzB4240xXdqaJP1wc9w4plkEbc+ qnE8Cx23KGNy/gQSK9VgiQAsZ8ppeUoueSQ2OKBhlg7+ X-Google-Smtp-Source: ABhQp+SuBgd6quT33RJtOiwFt6pwphXtutbdBcVdC8T0i2v83vT6rCTEm9h8a5xvoGLNOAGMhDAnW2sEtnTwbzay3as= X-Received: by 10.223.152.16 with SMTP id v16mr2974041wrb.108.1509491396638; Tue, 31 Oct 2017 16:09:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Tue, 31 Oct 2017 16:09:55 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Tue, 31 Oct 2017 19:09:55 -0400 Message-ID: To: Eric Rescorla Cc: Kathleen Moriarty , IETF ACME Content-Type: multipart/alternative; boundary="f403045d55a67d0de4055cdfda41" Archived-At: Subject: Re: [Acme] AD review of draft-ietf-acme-acme 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, 31 Oct 2017 23:10:02 -0000 --f403045d55a67d0de4055cdfda41 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 31, 2017 at 4:39 PM, Eric Rescorla wrote: > > > On Tue, Oct 31, 2017 at 12:51 PM, Richard Barnes wrote: > >> >> >> On Mon, Oct 30, 2017 at 9:37 PM, Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> wrote: >> >>> Hi Richard, >>> >>> On Mon, Oct 30, 2017 at 6:27 PM, Richard Barnes wrote: >>> > >>> > >>> > On Mon, Oct 30, 2017 at 5:00 PM, Kathleen Moriarty >>> > wrote: >>> >> >>> >> Hi Richard, >>> >> >>> >> Thanks for posting the diff, I reviewed the changes and they look >>> >> good, but I have a couple of questions. FYI - I had started looking >>> >> at the PR, but something came up, sorry for the delay and this was a >>> >> good reminder. >>> >> >>> >> On Thu, Oct 19, 2017 at 12:45 PM, Richard Barnes wrote: >>> >> > Hi Kathleen, >>> >> > >>> >> > Thanks for the review. Some responses inline. I've started a PR = to >>> >> > respond >>> >> > to these comments here: >>> >> > >>> >> > https://github.com/ietf-wg-acme/acme/pull/345 >>> >> > >>> >> > I agree with Daniel that we should hold off on IETF LC until we've >>> >> > addressed >>> >> > the issues around proactive issuance / caching of CSRs. That may >>> >> > require a >>> >> > re-WGLC, but once that's closed, it should be safe to send to IETF >>> LC. >>> >> > >>> >> > >>> >> > On Fri, Sep 22, 2017 at 4:14 PM, Kathleen Moriarty >>> >> > wrote: >>> >> >> >>> >> >> Hello, >>> >> >> >>> >> >> Thank you to the editors and WG for your efforts on >>> >> >> draft-ietf-acme-acme, it's a well written and easy to understand >>> >> >> draft. I do have a few comments, that need to be address by the >>> >> >> editors and SHEPHERD. >>> >> >> >>> >> >> Please review the idnits. There are a few warnings that should b= e >>> >> >> correctable and can be addressed, but more importantly, it calls >>> out >>> >> >> several downrefs that are not in the shepherd writeup. These nee= d >>> to >>> >> >> be in the writeup and then also mentioned in the IETF last call >>> >> >> announcement (I'll make sure the latter happens). >>> >> >> >>> >> >> Here's my mostly editorial comments: >>> >> >> >>> >> >> Introduction: >>> >> >> It reads very well, but it would be helpful to those unfamiliar >>> with >>> >> >> the work to explicitly state that ACME is about DV certificates. >>> The >>> >> >> first sentence of the last paragraph seems like the best place to >>> add >>> >> >> this in. >>> >> >> Current text: >>> >> >> This document describes an extensible framework for automating >>> the >>> >> >> issuance and domain validation procedure, thereby allowing >>> servers >>> >> >> and infrastructural software to obtain certificates without us= er >>> >> >> interaction. >>> >> >> Proposed: >>> >> >> This document describes an extensible framework for automating >>> the >>> >> >> issuance and domain validation procedure for DV certificates, >>> >> >> thereby allowing servers >>> >> >> and infrastructural software to obtain certificates without us= er >>> >> >> interaction. >>> >> > >>> >> > >>> >> > As others have pointed out, ACME is not just about DV. PR has som= e >>> >> > clarification on this point. >>> >> >>> >> I see the text on uses in other PKI contexts in the introduction, bu= t >>> >> don't see anything on the certificate types and out-of-band processe= s >>> >> (as is the case for the STIR use case Mary mentioned). Maybe I'm >>> >> missing it, can you tell me where to look? >>> > >>> > >>> > I don't think you're missing anything. What do you mean by >>> "certificate >>> > types and out-of-band processes"? How is that different from "other >>> PKI >>> > contexts"? >>> >>> I think by PKI-context, you mean the application of use, is that >>> right? I am separating out the type of certificate (DV, EV, etc.) as >>> you have done in the second paragraph of the introduction. When >>> reading the rest of the document, there isn't text that says what type >>> of certificate ACME produces without any additional processes >>> (out-of-band authentication/validation). If you think about >>> administrators who operate servers (whatever the protocol) or even >>> those who may wish to incorporate ACME into a new application, they >>> will may have to figure out what level ACME provides as a default and >>> also know that there can be additional processes added to obtain >>> certificates types at a higher assurance level using ACME. Since the >>> text already does a nice job of explaining the certificate types, this >>> should be an easy follow up that I think will be very helpful to >>> people outside of the IETF or who look at this in the future. >>> >>> Maybe something like the following: >>> >>> Strictly following the automation enabled by ACME, DV certificates >>> are issued. >>> Additional processes can be provided by the CA to increase the level >>> of >>> validation on an end entity to issue certificates at a higher >>> assurance level, >>> for instance an EV certificate. >> the STIR >>> example Mary mentioned in this thread.> >>> >>> Does that help? Thinking about this in former roles and having been >>> to some conferences lately, I think being explicit about this will >>> help those trying to evaluate and deploy ACME. They may look for >>> providers who meet the assurance levels they need knowing there are >>> options and understanding the baseline provided by this spec. >>> >> >> >> It's wrong to frame this as being about assurance levels -- you seem to >> be presuming that manual processes can give higher assurance than automa= ted >> ones, a fact which I think has been repeatedly proven false in the web >> PKI. >> >> But I'm fine clarifying that certain things (like EV validation) have no= t >> yet been audited: >> > > You mean "automated", right? > Yep. PR is correct. > > > >> >> +ACME can also be used to automate some aspects of certificate managemen= t >> even >> +where non-automated processes are still needed. For example, the >> external >> +account binding feature (see {{external-account-binding}}) can be used = to >> +associate authorizations with an account that were not validated throug= h >> the >> +ACME authorization process. This allows ACME to address issuance >> scenarios that >> +cannot yet be fully automated, such as the issuance of Extended >> Validation >> +certificates. >> >> Updated PR: https://github.com/ietf-wg-acme/acme/pull/348 >> >> --Richard >> >> >> >> >>> >>> Thanks, >>> Kathleen >>> >>> >>> > >>> > >>> >> >>> >> > >>> >> > >>> >> >> >>> >> >> I do like how the introduction is framed as it=E2=80=99s clear th= e level of >>> >> >> security provided by the certificates issued via ACME. Thanks fo= r >>> >> >> that. >>> >> >> >>> >> >> The introduction should also make it clear that ACME can be used >>> for >>> >> >> other services using DV certificates, not just HTTP. This is >>> >> >> mentioned in the Terminology section, but I think a clear sentenc= e >>> >> >> upfront would be helpful. >>> >> >> >>> >> >> Section 2: Nit/suggestion: Change the tense to read as a publishe= d >>> RFC >>> >> >> in the last paragraph, last sentence (take it or leave it). >>> >> >> Current: >>> >> >> Such close integration of ACME with HTTPS >>> >> >> servers would allow the immediate and automated deployment of >>> >> >> certificates as they are issued, sparing the human administrat= or >>> >> >> from >>> >> >> much of the time-consuming work described in the previous >>> section. >>> >> >> Proposed: >>> >> >> Such close integration of ACME with HTTPS >>> >> >> servers allows the immediate and automated deployment of >>> >> >> certificates as they are issued, sparing the human administrat= or >>> >> >> from >>> >> >> much of the time-consuming work described in the previous >>> section. >>> >> > >>> >> > >>> >> > Done. >>> >> > >>> >> > >>> >> >> >>> >> >> IANA Section: >>> >> >> Everything looks good except that RFC5226 has been obsoleted, so >>> the >>> >> >> new reference is RFC8126 and =E2=80=9Cspecification required=E2= =80=9D >>> >> >> https://tools.ietf.org/html/rfc8126#section-4.6 still means the >>> same >>> >> >> thing, so using that is fine. >>> >> > >>> >> > >>> >> > Updated reference. >>> >> > >>> >> > >>> >> >> >>> >> >> Security considerations: >>> >> >> I think it would be good to mention here that they are DV certs s= o >>> the >>> >> >> reader understands from he introduction and this section the leve= l >>> of >>> >> >> cert issued through ACME and doesn=E2=80=99t assume a higher leve= l of >>> >> >> assurance. >>> >> >> >>> >> >> s/ACME is a protocol for managing certificates/ACME is a protocol >>> for >>> >> >> managing DV certificates/ >>> >> > >>> >> > >>> >> > Given the discussion about DV, I don't think this change is >>> appropriate. >>> >> > >>> >> > >>> >> >> >>> >> >> 10.1 - I know this is obvious to the people in the WG, but a >>> reference >>> >> >> to RFC7525 to properly configure TLS 1.2 should be included to >>> protect >>> >> >> against the mentioned attacks. If you want to also reference TLS >>> 1.3 >>> >> >> and specify no 0-RTT that would be good too. It=E2=80=99d be gre= at to see >>> >> >> this get widely deployed, so there may be a number of newcomers >>> >> >> reading this to make their lives easier with cert >>> >> >> issuance/maintenance. >>> >> > >>> >> > >>> >> > I don't see how TLS configuration plays into the security >>> considerations >>> >> > for >>> >> > ACME. How you use the certificates you get from ACME is your >>> business, >>> >> > and >>> >> > indeed, several of the envisioned applications have nothing to do >>> with >>> >> > TLS >>> >> > (e.g., the email and STIR use cases). >>> >> > >>> >> > That said, I have added some language to suggest that ACME servers >>> >> > should >>> >> > follow the advice in RFC 7525. 0xRTT should be safe here, because >>> there >>> >> > are >>> >> > anti-replay protections at the application layer. >>> >> >>> >> Can you add a pointer in your text about the provided anti-replay >>> >> protections in the application layer? >>> > >>> > >>> > Draft PR here: >>> > >>> > https://github.com/ietf-wg-acme/acme/pull/348 >>> > >>> > --Richard >>> > >>> > >>> >> >>> >> >>> >> Thanks, >>> >> Kathleen >>> >> >>> >> > >>> >> > >>> >> >> >>> >> >> 10.2 - what if the server that the account verifier has an accoun= t >>> on >>> >> >> (client for ACME) is compromised and is used to request new >>> >> >> certificates or perform other actions? I think this is one of th= e >>> >> >> larger risks, so mentioning this is possible and hardening measur= es >>> >> >> should be taken to prevent compromise would be prudent. Hardenin= g >>> >> >> measures or appropriate security controls should be broadly >>> understood >>> >> >> terms (I think) so that you wouldn=E2=80=99t need to list out thi= ngs like >>> >> >> turing off unnecessary services. >>> >> > >>> >> > >>> >> > Added a brief note. >>> >> > >>> >> > >>> >> >> >>> >> >> 10.5 - I would think you=E2=80=99d see requests for new phishing = domains >>> >> >> rather than known ones through this process. What would you look >>> for >>> >> >> there as that=E2=80=99s a complex problem - it would be hard to k= now all >>> legit >>> >> >> names to know if one was a play off of the original. This happen= ed >>> >> >> with equifax - they provided a site name with a typo and a =E2=80= =98white >>> hat=E2=80=99 >>> >> >> attacker had set up a site that looked just like theirs at that >>> site. >>> >> >> But it was announced by equifax. Tough problem as automating a >>> check >>> >> >> on the DNS registration may not detect something unusual, but may= be >>> >> >> recommending this check could help? RDP lessens what needs to be >>> >> >> shared from whois though, although I don=E2=80=99t think that=E2= =80=99s widely >>> >> >> deployed. >>> >> > >>> >> > >>> >> > This is a policy question, not one for the issuance protocol. >>> >> > >>> >> > --Richard >>> >> > >>> >> > >>> >> >> >>> >> >> >>> >> >> -- >>> >> >> >>> >> >> Best regards, >>> >> >> Kathleen >>> >> >> >>> >> >> _______________________________________________ >>> >> >> Acme mailing list >>> >> >> Acme@ietf.org >>> >> >> https://www.ietf.org/mailman/listinfo/acme >>> >> > >>> >> > >>> >> >>> >> >>> >> >>> >> -- >>> >> >>> >> Best regards, >>> >> Kathleen >>> > >>> > >>> >>> >>> >>> -- >>> >>> Best regards, >>> Kathleen >>> >> >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> >> > --f403045d55a67d0de4055cdfda41 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Oct 31, 2017 at 4:39 PM, Eric Rescorla <ekr@rtfm.com>= wrote:


On T= ue, Oct 31, 2017 at 12:51 PM, Richard Barnes <rlb@ipv.sx> wrote:


On Mon, Oct 30, 2017 at 9:37 PM, Kathleen Moriarty = <k= athleen.moriarty.ietf@gmail.com> wrote:
Hi Richard,
On Mon, Oct 30, 2017 at 6:27 PM, Richard Barnes <rlb@ipv.sx> wrote: >
>
> On Mon, Oct 30, 2017 at 5:00 PM, Kathleen Moriarty
> <kathleen.moriarty.ietf@gmail.com> wrote:
>>
>> Hi Richard,
>>
>> Thanks for posting the diff, I reviewed the changes and they look<= br> >> good, but I have a couple of questions.=C2=A0 FYI - I had started = looking
>> at the PR, but something came up, sorry for the delay and this was= a
>> good reminder.
>>
>> On Thu, Oct 19, 2017 at 12:45 PM, Richard Barnes <rlb@ipv.sx>= ; wrote:
>> > Hi Kathleen,
>> >
>> > Thanks for the review.=C2=A0 Some responses inline.=C2=A0 I&#= 39;ve started a PR to
>> > respond
>> > to these comments here:
>> >
>> > https://github.com/ietf-wg-acme/acme= /pull/345
>> >
>> > I agree with Daniel that we should hold off on IETF LC until = we've
>> > addressed
>> > the issues around proactive issuance / caching of CSRs.=C2=A0= That may
>> > require a
>> > re-WGLC, but once that's closed, it should be safe to sen= d to IETF LC.
>> >
>> >
>> > On Fri, Sep 22, 2017 at 4:14 PM, Kathleen Moriarty
>> > <kathleen.moriarty.ietf@gmail.com> wrote:
>> >>
>> >> Hello,
>> >>
>> >> Thank you to the editors and WG for your efforts on
>> >> draft-ietf-acme-acme, it's a well written and easy to= understand
>> >> draft.=C2=A0 I do have a few comments, that need to be ad= dress by the
>> >> editors and SHEPHERD.
>> >>
>> >> Please review the idnits.=C2=A0 There are a few warnings = that should be
>> >> correctable and can be addressed, but more importantly, i= t calls out
>> >> several downrefs that are not in the shepherd writeup.=C2= =A0 These need to
>> >> be in the writeup and then also mentioned in the IETF las= t call
>> >> announcement (I'll make sure the latter happens).
>> >>
>> >> Here's my mostly editorial comments:
>> >>
>> >> Introduction:
>> >> It reads very well, but it would be helpful to those unfa= miliar with
>> >> the work to explicitly state that ACME is about DV certif= icates.=C2=A0 The
>> >> first sentence of the last paragraph seems like the best = place to add
>> >> this in.
>> >> Current text:
>> >>=C2=A0 =C2=A0 This document describes an extensible framew= ork for automating the
>> >>=C2=A0 =C2=A0 issuance and domain validation procedure, th= ereby allowing servers
>> >>=C2=A0 =C2=A0 and infrastructural software to obtain certi= ficates without user
>> >>=C2=A0 =C2=A0 interaction.
>> >> Proposed:
>> >>=C2=A0 =C2=A0 This document describes an extensible framew= ork for automating the
>> >>=C2=A0 =C2=A0 issuance and domain validation procedure for= DV certificates,
>> >> thereby allowing servers
>> >>=C2=A0 =C2=A0 and infrastructural software to obtain certi= ficates without user
>> >>=C2=A0 =C2=A0 interaction.
>> >
>> >
>> > As others have pointed out, ACME is not just about DV.=C2=A0 = PR has some
>> > clarification on this point.
>>
>> I see the text on uses in other PKI contexts in the introduction, = but
>> don't see anything on the certificate types and out-of-band pr= ocesses
>> (as is the case for the STIR use case Mary mentioned).=C2=A0 Maybe= I'm
>> missing it, can you tell me where to look?
>
>
> I don't think you're missing anything.=C2=A0 What do you mean = by "certificate
> types and out-of-band processes"?=C2=A0 How is that different fro= m "other PKI
> contexts"?

I think by PKI-context, you mean the application of use, is tha= t
right?=C2=A0 I am separating out the type of certificate (DV, EV, etc.) as<= br> you have done in the second paragraph of the introduction.=C2=A0 When
reading the rest of the document, there isn't text that says what type<= br> of certificate ACME produces without any additional processes
(out-of-band authentication/validation).=C2=A0 If you think about
administrators who operate servers (whatever the protocol) or even
those who may wish to incorporate ACME into a new application, they
will may have to figure out what level ACME provides as a default and
also know that there can be additional processes added to obtain
certificates types at a higher assurance level using ACME.=C2=A0 Since the<= br> text already does a nice job of explaining the certificate types, this
should be an easy follow up that I think will be very helpful to
people outside of the IETF or who look at this in the future.

Maybe something like the following:

=C2=A0 =C2=A0Strictly following the automation enabled by ACME, DV certific= ates
are issued.
=C2=A0 =C2=A0Additional processes can be provided by the CA to increase the= level of
=C2=A0 =C2=A0validation on an end entity to issue certificates at a higher<= br> assurance level,
=C2=A0 =C2=A0for instance an EV certificate.=C2=A0 <Then maybe provide a= reference to the STIR
=C2=A0 =C2=A0example Mary mentioned in this thread.>

Does that help?=C2=A0 Thinking about this in former roles and having been to some conferences lately, I think being explicit about this will
help those trying to evaluate and deploy ACME.=C2=A0 They may look for
providers who meet the assurance levels they need knowing there are
options and understanding the baseline provided by this spec.


It's wrong to frame t= his as being about assurance levels -- you seem to be presuming that manual= processes can give higher assurance than automated ones, a fact which I th= ink has been repeatedly proven false in the web PKI.=C2=A0
<= br>
But I'm fine clarifying that certain things (like EV vali= dation) have not yet been audited:

You mean "automated", right?

Yep.=C2=A0 PR is correct.
=C2=A0
=

=C2=A0

+ACME c= an also be used to automate some aspects of certificate management even
= +where non-automated processes are still needed.=C2=A0 For example, the ext= ernal
+account binding feature (see {{external-account-binding}}) can be= used to
+associate authorizations with an account that were not validat= ed through the
+ACME authorization process.=C2=A0 This allows ACME to ad= dress issuance scenarios that
+cannot yet be fully automated, such as th= e issuance of Extended Validation
+certificates.

Updated PR: https://github.com/ietf-wg-acme/acme/pull/348

--Richa= rd


=C2=A0

Thanks,
Kathleen


>
>
>>
>> >
>> >
>> >>
>> >> I do like how the introduction is framed as it=E2=80=99s = clear the level of
>> >> security provided by the certificates issued via ACME.=C2= =A0 Thanks for
>> >> that.
>> >>
>> >> The introduction should also make it clear that ACME can = be used for
>> >> other services using DV certificates, not just HTTP.=C2= =A0 This is
>> >> mentioned in the Terminology section, but I think a clear= sentence
>> >> upfront would be helpful.
>> >>
>> >> Section 2: Nit/suggestion: Change the tense to read as a = published RFC
>> >> in the last paragraph, last sentence (take it or leave it= ).
>> >> Current:
>> >>=C2=A0 =C2=A0 Such close integration of ACME with HTTPS >> >>=C2=A0 =C2=A0 servers would allow the immediate and automa= ted deployment of
>> >>=C2=A0 =C2=A0 certificates as they are issued, sparing the= human administrator
>> >> from
>> >>=C2=A0 =C2=A0 much of the time-consuming work described in= the previous section.
>> >> Proposed:
>> >>=C2=A0 =C2=A0 Such close integration of ACME with HTTPS >> >>=C2=A0 =C2=A0 servers allows the immediate and automated d= eployment of
>> >>=C2=A0 =C2=A0 certificates as they are issued, sparing the= human administrator
>> >> from
>> >>=C2=A0 =C2=A0 much of the time-consuming work described in= the previous section.
>> >
>> >
>> > Done.
>> >
>> >
>> >>
>> >> IANA Section:
>> >> Everything looks good except that RFC5226 has been obsole= ted, so the
>> >> new reference is RFC8126 and =E2=80=9Cspecification requi= red=E2=80=9D
>> >> https://tools.ietf.org/html/rf= c8126#section-4.6 still means the same
>> >> thing, so using that is fine.
>> >
>> >
>> > Updated reference.
>> >
>> >
>> >>
>> >> Security considerations:
>> >> I think it would be good to mention here that they are DV= certs so the
>> >> reader understands from he introduction and this section = the level of
>> >> cert issued through ACME and doesn=E2=80=99t assume a hig= her level of
>> >> assurance.
>> >>
>> >> s/ACME is a protocol for managing certificates/ACME is a = protocol for
>> >> managing DV certificates/
>> >
>> >
>> > Given the discussion about DV, I don't think this change = is appropriate.
>> >
>> >
>> >>
>> >> 10.1 - I know this is obvious to the people in the WG, bu= t a reference
>> >> to RFC7525 to properly configure TLS 1.2 should be includ= ed to protect
>> >> against the mentioned attacks.=C2=A0 If you want to also = reference TLS 1.3
>> >> and specify no 0-RTT that would be good too.=C2=A0 It=E2= =80=99d be great to see
>> >> this get widely deployed, so there may be a number of new= comers
>> >> reading this to make their lives easier with cert
>> >> issuance/maintenance.
>> >
>> >
>> > I don't see how TLS configuration plays into the security= considerations
>> > for
>> > ACME.=C2=A0 How you use the certificates you get from ACME is= your business,
>> > and
>> > indeed, several of the envisioned applications have nothing t= o do with
>> > TLS
>> > (e.g., the email and STIR use cases).
>> >
>> > That said, I have added some language to suggest that ACME se= rvers
>> > should
>> > follow the advice in RFC 7525.=C2=A0 0xRTT should be safe her= e, because there
>> > are
>> > anti-replay protections at the application layer.
>>
>> Can you add a pointer in your text about the provided anti-replay<= br> >> protections in the application layer?
>
>
> Draft PR here:
>
> https://github.com/ietf-wg-acme/acme/pull/348=
>
> --Richard
>
>
>>
>>
>> Thanks,
>> Kathleen
>>
>> >
>> >
>> >>
>> >> 10.2 - what if the server that the account verifier has a= n account on
>> >> (client for ACME) is compromised and is used to request n= ew
>> >> certificates or perform other actions?=C2=A0 I think this= is one of the
>> >> larger risks, so mentioning this is possible and hardenin= g measures
>> >> should be taken to prevent compromise would be prudent.= =C2=A0 Hardening
>> >> measures or appropriate security controls should be broad= ly understood
>> >> terms (I think) so that you wouldn=E2=80=99t need to list= out things like
>> >> turing off unnecessary services.
>> >
>> >
>> > Added a brief note.
>> >
>> >
>> >>
>> >> 10.5 - I would think you=E2=80=99d see requests for new p= hishing domains
>> >> rather than known ones through this process.=C2=A0 What w= ould you look for
>> >> there as that=E2=80=99s a complex problem - it would be h= ard to know all legit
>> >> names to know if one was a play off of the original.=C2= =A0 This happened
>> >> with equifax - they provided a site name with a typo and = a =E2=80=98white hat=E2=80=99
>> >> attacker had set up a site that looked just like theirs a= t that site.
>> >> But it was announced by equifax.=C2=A0 Tough problem as a= utomating a check
>> >> on the DNS registration may not detect something unusual,= but maybe
>> >> recommending this check could help?=C2=A0 RDP lessens wha= t needs to be
>> >> shared from whois though, although I don=E2=80=99t think = that=E2=80=99s widely
>> >> deployed.
>> >
>> >
>> > This is a policy question, not one for the issuance protocol.=
>> >
>> > --Richard
>> >
>> >
>> >>
>> >>
>> >> --
>> >>
>> >> Best regards,
>> >> Kathleen
>> >>
>> >> _______________________________________________
>> >> Acme mailing list
>> >> Acme@i= etf.org
>> >> https://www.ietf.org/mailman/listin= fo/acme
>> >
>> >
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>
>



--

Best regards,
Kathleen


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



--f403045d55a67d0de4055cdfda41--