From nobody Fri Dec 1 04:06: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 D98BF128CD5 for ; Fri, 1 Dec 2017 04:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hemio.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 109cwJIUrmn0 for ; Fri, 1 Dec 2017 04:06:17 -0800 (PST) Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E580126579 for ; Fri, 1 Dec 2017 04:06:17 -0800 (PST) Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id 5D218A6 for ; Fri, 1 Dec 2017 13:06:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hemio.de; s=20170414; t=1512129975; bh=awAtocqwV4IMq18wgFFf41OOudf3C8jzScVlTCEIPjQ=; h=To:From:Subject:Date:From; b=OQq9j+oCCzAJ5zXFh4gVSXJbWqIlzoWPCSAbo2fWwRN2UisKDqQrXNN8YP2mG5C7J yBtNxOlCuDgL7uFLz+TXuPoXAGa8rtxvDt4dUAg+enPt7Te/iVu1TRWpI3SOo6OELb PDozmgkdaUPOV8sjPKOOwnLFtw1N7i6Qplp2KfouJRcYYJ6LSS5s+u21fRAj3MKDyI ByQ895lwKY6DxAfcqDmyCLMfsAD4Jwn52Sz1JW5ssDNNTKvv0YOaaa2JuENf+1zfOA SK5kSTGpl4Qc3Q66puFuU1oxqo5g0bGoflkTbKCYSR+c4a1JxOE3heds21ArF5Q7Li /LkNwS4l9dC+A== To: ACME WG From: Sophie Herold Message-ID: <1c740fe6-1594-44d3-69a7-a9f2170e6446@hemio.de> Date: Fri, 1 Dec 2017 13:06:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Acme] Camel vs. kebab-case 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, 01 Dec 2017 12:06:19 -0000 Hi, while updating my client implementation I noted that there seems to be an arbitrary mix in object key naming conventions: camelCase - newKey - keyAuthorization - notBefore - notAfter kebab-case - (all directory fields) - terms-of-service-agreed - only-return-existing - external-account-binding In my opinion this makes the mapping of JSON objects to implementation language objects/types unnecessarily complicated. I don't know if it is to late to do something about that. Best, Sophie From nobody Fri Dec 1 04:55: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 6841D128ACA for ; Fri, 1 Dec 2017 04:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=kastel-se.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 AvTUXX8FkXbJ for ; Fri, 1 Dec 2017 04:55:48 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 EC52C1205F1 for ; Fri, 1 Dec 2017 04:55:47 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id d4so12836306qtj.5 for ; Fri, 01 Dec 2017 04:55:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kastel-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ACf4uSnkjajpmmJ7G6mUxIwRu3GpRuEIZ8z8qdOL40E=; b=HwmLIU8QEjzxYc94VZ46lXbD4AN4DuCKYU2SknnhtQn5wcn0fjS0EIL/a6tfnN/5g3 dSKUhd//MYsO1APGU5efbKBrzo0LdoaP8Q4YFJpBUQry2MmSK3QPw4EIhlKIbJ6Dctu2 KnymeesyTQ2mWGLj1iokmQ3BENLOYP4PPWV2LFM/2J44PJsneBee76sUkJHs5rkMkypD VmW3eo+Efh8lyT4LlmQZrb3eS7P1KEZxGuRZUnNm6oFfza1l3NEeaiIxf3g/p/8QB0Pl pEknmmhL9QWpVZhpaY9cfk320c6SeYTy5T+7WHmchrL4PZ+E4eUUHFyXFa8PPAWjlR7h QWcg== 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=ACf4uSnkjajpmmJ7G6mUxIwRu3GpRuEIZ8z8qdOL40E=; b=dwtBFSVUNyb5F4LNe2seOjPJQLYTI+moD6nKsewM93wWSr+gNWkYsjczoNm3TFnY/J T5kh4Ab/P6Vx7BqMZbHutnaKu1Pk3YSyHeP6k5ocNxM8IG6/Wcf3B6tkFAKqfhU7Pyo6 Oz4GKyQ6zG9RtOzR3i4SRK3P2QAbxWYrXpFu/EyqfbqWNKYSQzhiwWPTp8J3DK92bAjc lUAMcOtaP+8HpA5izzy9kd53h3xHGqY+Q65sTqYUiY3N7CiTjHWxCKqTaygSM1c1e76z ssS9mu3yhyiaGjwhIfyW00B4HdSVlIHZNxrgSBM3w/UB21KkvpxOuimusOYNLb97xStE SZdA== X-Gm-Message-State: AKGB3mLQk61Z1XZIKSrBji1Fwsy382NjV0+CkPsSq+ERiqgv4QJhfvm1 D2egt9EtDTaXeLK9bWkSznc1GuIbFfDFYK2QVBwmIg== X-Google-Smtp-Source: AGs4zMblJZz4zM1LJdY6DhnRwTB0tvbAKNJWeVk2qKleRM7tWKp7GzSjXXwQrYCQkY7Xlb6SJ/678hmq7bbGN3JVDwM= X-Received: by 10.200.8.56 with SMTP id u53mr8596095qth.85.1512132946915; Fri, 01 Dec 2017 04:55:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.209.29 with HTTP; Fri, 1 Dec 2017 04:55:46 -0800 (PST) In-Reply-To: <20171130150759.f92dc9a717e92296bf7356a1@andrewayer.name> References: <0F612577-86CE-4E86-B95C-01C0FF82BDA7@akamai.com> <6c002b3f-8018-45f8-64dd-1bbb2d2918d2@eff.org> <20171130150759.f92dc9a717e92296bf7356a1@andrewayer.name> From: =?UTF-8?Q?Robert_K=C3=A4stel?= Date: Fri, 1 Dec 2017 13:55:46 +0100 Message-ID: To: Andrew Ayer Cc: Jacob Hoffman-Andrews , "Salz, Rich" , IETF ACME , cpu@letsencrypt.org, Clint Wilson Content-Type: multipart/alternative; boundary="001a1144de922786cd055f46e37e" Archived-At: Subject: Re: [Acme] Removing OOB Challenge Type 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, 01 Dec 2017 12:55:50 -0000 --001a1144de922786cd055f46e37e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We at Telia Company are working on an ACME server implementation that is going to integrate with an existing CA system using external account binding. We're planning on using the OOB challenge type to signify pre-authorized domains (in the existing CA system) as already validated challenges in the ACME response, as described in section 7.4.1 Pre-authorization [0]. This is planned for the first release of the ACME service. Another use for it we're planning is to support validating EV and OV certificates using an OOB href/URL. [0] https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html#rfc.section.7= .4.1 regards, Robert K=C3=A4stel On Fri, Dec 1, 2017 at 12:07 AM, Andrew Ayer wrote: > No objections here. > > Regards, > Andrew > > On Thu, 30 Nov 2017 10:22:56 -0800 > Jacob Hoffman-Andrews wrote: > > > I agree with this change. It's a good plan to not try and pre-specify > > things like OOB that aren't on anyone's roadmap, because that leaves > > the space open for a better specification once someone wants to > > implement it. > > > > On 11/30/2017 09:39 AM, Clint Wilson wrote: > > > > > > I agree with the reasoning and decision to remove this. > > > While I think it's possible for this challenge type to become useful > > > in the future, I don't have any justification for keeping it in in > > > the meantime. As Daniel notes, it's straightforward to add it back > > > if needed. > > > > > > > > > On Thu, Nov 30, 2017, 10:25 AM Daniel McCarney > > > wrote: > > > > > > > Daniel, please do not merge this until we determine WG > > > >consensus > > > > > > Of course :-) I don't have any merge privileges! > > > > > > On Thu, Nov 30, 2017 at 11:42 AM, Salz, Rich > > > wrote: > > > > > > Does anyone disagree with Daniel=E2=80=99s reasoning? If so,= please > > > speak up before next Friday. > > > > > > > > > > > > Daniel, please do not merge this until we determine WG > > > consensus. > > > > > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a1144de922786cd055f46e37e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We at Telia Company are working on an ACME server implemen= tation that is going to integrate with an existing CA system using external= account binding.
We're planning on using the OOB challenge type to= signify pre-authorized domains (in the existing CA system) as already vali= dated challenges in the ACME response, as described in section 7.4.1 Pre-au= thorization [0]. This is planned for the first release of the ACME service.=

Another use for it we're planning is to suppo= rt validating EV and OV certificates using an OOB href/URL.

<= /div>

regards,
Robert K=C3=A4stel

On Fri, Dec 1, 2017 at 12:07 AM, Andrew Ayer <agw= a@andrewayer.name> wrote:
N= o objections here.

Regards,
Andrew

On Thu, 30 Nov 2017 10:22:56 -0800
Jacob Hoffman-Andrews <jsha@eff.org&= gt; wrote:

> I agree with this change. It's a good plan to not try and pre-spec= ify
> things like OOB that aren't on anyone's roadmap, because that = leaves
> the space open for a better specification once someone wants to
> implement it.
>
> On 11/30/2017 09:39 AM, Clint Wilson wrote:
> >
> > I agree with the reasoning and decision to remove this.
> > While I think it's possible for this challenge type to become= useful
> > in the future, I don't have any justification for keeping it = in in
> > the meantime. As Daniel notes, it's straightforward to add it= back
> > if needed.
> >
> >
> > On Thu, Nov 30, 2017, 10:25 AM Daniel McCarney <cpu@letsencrypt.org
> > <mailto:cpu@letsencrypt.org>> wrote:
> >
> >=C2=A0 =C2=A0 =C2=A0>=C2=A0Daniel, please do not merge this unt= il we determine WG
> >=C2=A0 =C2=A0 =C2=A0>consensus
> >
> >=C2=A0 =C2=A0 =C2=A0Of course :-) I don't have any merge privi= leges!
> >
> >=C2=A0 =C2=A0 =C2=A0On Thu, Nov 30, 2017 at 11:42 AM, Salz, Rich &= lt;rsalz@akamai.com
> >=C2=A0 =C2=A0 =C2=A0<mailto:rsalz@akamai.com>> wrote:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Does anyone disagree with Daniel= =E2=80=99s reasoning?=C2=A0 If so, please
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0speak up before next Friday.
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Daniel, please do not merge this= until we determine WG
> > consensus.
> >
> >
> >=C2=A0 =C2=A0 =C2=A0_________________________________________= ______
> >=C2=A0 =C2=A0 =C2=A0Acme mailing list
> >=C2=A0 =C2=A0 =C2=A0Acme@i= etf.org <mailto:Acme@ietf.org&g= t;
> >=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/acme
> >
> >
> >
> > _______________________________________________
> > Acme mailing list
> > Acme@ietf.org
> > https://www.ietf.org/mailman/listinfo/acme<= /a>
>

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

--001a1144de922786cd055f46e37e-- From nobody Fri Dec 1 05:42: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 41BB712706D for ; Fri, 1 Dec 2017 05:42:37 -0800 (PST) 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 WDQ3Irfe6Mc8 for ; Fri, 1 Dec 2017 05:42:35 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D846126DFF for ; Fri, 1 Dec 2017 05:42:35 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id 81so11268833iof.3 for ; Fri, 01 Dec 2017 05:42:35 -0800 (PST) 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=PgzndBbOC76Kg19b4fBTyuevrPZOYjIPpHoHOftPLEQ=; b=ALcIGnn1VEbuC+iS8PFeSWvRGa9QkuSYIhQ3PFdrytENFogXq/lnxk67h9zbfPp80G 1k32YItVOtTXMOSPGaHDKLmY8Ysn/0E8HDi0liD0OhGrZ57T9WPVuKaM4Z1KTlCs05CV gPHX7jsSW5Wgll5JCFE0F5JLPDOdKGHOfIGCDPFoHDhCaj3xfzNEHBgfyqxstrK8o0il O4/lr/fg5BKICsE4yIyNFX3IcNNZ8mWaYCGau8PPd1apgi7gT1s4vSQOcEO1Ca0EfBuF o7rmc7s1RrLgl5oQv2eJIbzgNhDHqlg7fG09Gg8/mh6xgCA1mra6oqu/YKlaZclA8pJI PW/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PgzndBbOC76Kg19b4fBTyuevrPZOYjIPpHoHOftPLEQ=; b=KiL9HWEhIXdLI6GyHTSmsRTDEbHevlhQMlDvGx1V91c+JjleMlkehAU/8dFFW4EYxb ZshGunQStuJ9arTILwhrhRDMWK8airI3En1ONB/1ymjJPhdxNEoNopc5Z5yAlr5V5qAS T/wtJi+dy8wrQnsQq6zJ0ZxuEZL8uNHmDpSGjMjuC9ItVCavZgYsY4KaegVgvEGBhnvi dJnS73MPZD1Vyh2rJ+8EvXS/KFRWxkObnb4r2mDArciJG3XFg3wgIHzV6bR8KYBI6hW1 M1mzAXP771XBRRkqmkSeiPfVIZiGky2vDVD6syvQFBq5CNzzs7ncHvOpp7NGclGqrNLp yxiA== X-Gm-Message-State: AJaThX4KW7B21L5Ke1pg/kIuJAtp/Lgm/HOHyihxUiC25pvtf6PImF61 zS8eFeq0IVEks1UwBPMk0J6dJxDCTeYFIEAdMa11H0x0 X-Google-Smtp-Source: AGs4zMbMSJnleJfHKUypIBQp9/ps+zUjALtr9Dk2pUms5x5nmE1jM7iLOBAlBtRESZjEcTWL/zSlGHBBSq+jfYx6iBY= X-Received: by 10.107.178.145 with SMTP id b139mr12473882iof.52.1512135754481; Fri, 01 Dec 2017 05:42:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.81.8 with HTTP; Fri, 1 Dec 2017 05:42:33 -0800 (PST) In-Reply-To: <1c740fe6-1594-44d3-69a7-a9f2170e6446@hemio.de> References: <1c740fe6-1594-44d3-69a7-a9f2170e6446@hemio.de> From: Richard Barnes Date: Fri, 1 Dec 2017 08:42:33 -0500 Message-ID: To: Sophie Herold Cc: ACME WG Content-Type: multipart/alternative; boundary="001a114ca1627f976e055f478a67" Archived-At: Subject: Re: [Acme] Camel vs. kebab-case 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, 01 Dec 2017 13:42:37 -0000 --001a114ca1627f976e055f478a67 Content-Type: text/plain; charset="UTF-8" Good observation. I would be OK moving everything to camelCase [1], since it seems like that's a more natural fit for programming language bindings. This also seems like a less disruptive change than some other things we've been doing lately (finalization). At best, it's a string change; at worst, some variable renaming. Want to submit a PR? [1] I had not heard "kebab-case" before! It seems like there should be extra "-" characters on the ends, like "--new-order--" :) On Fri, Dec 1, 2017 at 7:06 AM, Sophie Herold wrote: > Hi, > > while updating my client implementation I noted that there seems to be > an arbitrary mix in object key naming conventions: > > camelCase > > - newKey > - keyAuthorization > - notBefore > - notAfter > > kebab-case > > - (all directory fields) > - terms-of-service-agreed > - only-return-existing > - external-account-binding > > In my opinion this makes the mapping of JSON objects to implementation > language objects/types unnecessarily complicated. I don't know if it is > to late to do something about that. > > Best, > Sophie > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a114ca1627f976e055f478a67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good observation.=C2=A0 I would be OK moving everythi= ng to camelCase [1], since it seems like that's a more natural fit for = programming language bindings.

This also seems lik= e a less disruptive change than some other things we've been doing late= ly (finalization).=C2=A0 At best, it's a string change; at worst, some = variable renaming.

Want to submit a PR?

[1] I had not heard "kebab-case" before!= =C2=A0 It seems like there should be extra "-" characters on the = ends, like "--new-order--" :)


On Fri, Dec 1, 2017 at 7:06 AM, S= ophie Herold <sophie_herold@hemio.de> wrote:
Hi,

while updating my client implementation I noted that there seems to be
an arbitrary mix in object key naming conventions:

camelCase

- newKey
- keyAuthorization
- notBefore
- notAfter

kebab-case

- (all directory fields)
- terms-of-service-agreed
- only-return-existing
- external-account-binding

In my opinion this makes the mapping of JSON objects to implementation
language objects/types unnecessarily complicated. I don't know if it is=
to late to do something about that.

Best,
Sophie

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

--001a114ca1627f976e055f478a67-- From nobody Fri Dec 1 05:54: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 A7037128990 for ; Fri, 1 Dec 2017 05:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.689 X-Spam-Level: X-Spam-Status: No, score=-4.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAFy9SmqBvaQ for ; Fri, 1 Dec 2017 05:53:56 -0800 (PST) Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2395912708C for ; Fri, 1 Dec 2017 05:53:55 -0800 (PST) Received: from mail.zoho.com by mx.zohomail.com with SMTP id 15121364331921022.8723450285913; Fri, 1 Dec 2017 05:53:53 -0800 (PST) Date: Fri, 01 Dec 2017 14:53:53 +0100 From: Matthias Merkel To: Message-Id: <160125ade25.db5555526773.39714603402561017@moritz30.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_16561_951290150.1512136433191" X-Priority: Normal User-Agent: Zoho Mail X-Mailer: Zoho Mail Archived-At: Subject: [Acme] Idea about automated OV validation X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 13:53:58 -0000 ------=_Part_16561_951290150.1512136433191 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit I had the following idea about automating verification and issuance of OV SSL certificates: Couldn't a CA in theory use the D&B API to check the company name, address and phone number and then place an automatic call? That's basically what most CAs do anyways so is there any reason why they couldn't do it? That would also be a way for Let's Encrypt to issue OV certificates and code signing certificates. ------=_Part_16561_951290150.1512136433191 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit
I had the following idea about automating verification and issuance of OV SSL certificates: Couldn't a CA in theory use the D&B API to check the company name, address and phone number and then place an automatic call? That's basically what most CAs do anyways so is there any reason why they couldn't do it? That would also be a way for Let's Encrypt to issue OV certificates and code signing certificates.


------=_Part_16561_951290150.1512136433191-- From nobody Fri Dec 1 05:58: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 97E5512708C for ; Fri, 1 Dec 2017 05:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 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, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 y3BDbOBFfvCo for ; Fri, 1 Dec 2017 05:58:00 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003: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 091D3126DFE for ; Fri, 1 Dec 2017 05:58:00 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id r63so7183975oia.6 for ; Fri, 01 Dec 2017 05:58:00 -0800 (PST) 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=SFhoLgFZzTh4hHYVjBaoWYYjG9DXDSJEZQE9xW0Bu14=; b=jhBX12OmqxGHep3Vo+vkBe/4XPj4mxDgg62N05a4JBbsNbO+xY9Xo+Ob1E7lb0jpyf JpMCoVSW12ma3JzlD98vUKoERLx98Yw94AFbJLN9cWfgnBDpNZ3XpCI8JTG4aAUTVD+6 /DcUbPdIf8FiaZ3CO6nZKvGe2hDqnFL12iyMM8QBNl273yNl4SeOhT1vI6OTpv3WrKCf mVS1ouT5H2CWuNEksQnaboO0cWDHse2Q2Sr1rVnwgHmU9/Mv4A2I0wOLsVGNU/ln1oPC V/FNp3GRGHHqNa/iliEdcuUKV6r6G6AZ+8j77VF8uq2PF03D2RsJ3esQgqB1m5DC4Z60 PxYQ== 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=SFhoLgFZzTh4hHYVjBaoWYYjG9DXDSJEZQE9xW0Bu14=; b=q6Pe1Cy9jVfZ9WSyZrZUh4OOumc/P1ihJ9Rw6dc+Pa0Cz/G/SncxVG1YKYcbpDe6nO PipmE6T0c9IrS22fdX25CJIPSK/Ky3evxMRRs2OSD5S56A04ZI3v2Sh2sKVgGzyA/CKC FmoNHVEZ056Cs5HRT2i2DQAHvvkY7TGkRmUXmlYqvQ3X108NSR1DIX5YXpzv5Katj7Zd kychdE4ziXRnkEGFQICNXaDumEnW2YyOUE3ThaZYNqHyTuTVk53dYMj7DH1OPA+G9U0t yAbfZdDMZN8Ff0ZQWpb9l2f443Ux8yFdWQeCiqThMHnrpdmWwxQo/nS1ZF5p4y2wLNcv 3MuQ== X-Gm-Message-State: AJaThX6UIDktsLt7TOcFeUzycabimGVBTeBbJgUoAI4I2YCLAEsh7rvx zbFcJ6ALENPsDsYzZgQarIQ/9eqIL06Z0DSxCJwE0Q== X-Google-Smtp-Source: AGs4zMaxDR8Ks8YW73Lfj2J4YEXz7Hr6D1n2PSwh4p+4Mf+s1ev8dKT93nJcopb/wZ4G1Kummvto9GiP3vhqp52jy3M= X-Received: by 10.202.189.5 with SMTP id n5mr7329370oif.312.1512136679409; Fri, 01 Dec 2017 05:57:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.29.210 with HTTP; Fri, 1 Dec 2017 05:57:18 -0800 (PST) In-Reply-To: <160125ade25.db5555526773.39714603402561017@moritz30.de> References: <160125ade25.db5555526773.39714603402561017@moritz30.de> From: =?UTF-8?Q?Philipp_Junghann=C3=9F?= Date: Fri, 1 Dec 2017 14:57:18 +0100 Message-ID: To: Matthias Merkel Cc: IETF ACME Content-Type: multipart/alternative; boundary="001a113d6cd4a0ce15055f47c186" Archived-At: Subject: Re: [Acme] Idea about automated OV validation X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 13:58:01 -0000 --001a113d6cd4a0ce15055f47c186 Content-Type: text/plain; charset="UTF-8" if that's what other CAs do that's not a bad Idea although there's of course the question whether there are some other manual checks needed. but cheap to almost free OVs/code signing certs would be great although that sadly doesnt make it easier for normal people without a company to get IVs or code signing certs, but the Idea is certainly not bad. 2017-12-01 14:53 GMT+01:00 Matthias Merkel : > I had the following idea about automating verification and issuance of OV > SSL certificates: Couldn't a CA in theory use the D&B API to check the > company name, address and phone number and then place an automatic call? > That's basically what most CAs do anyways so is there any reason why they > couldn't do it? That would also be a way for Let's Encrypt to issue OV > certificates and code signing certificates. > > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --001a113d6cd4a0ce15055f47c186 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
if that's what other CAs do that's not a bad Idea = although there's of course the question whether there are some other ma= nual checks needed.

but cheap to almost free OVs/code si= gning certs would be great although that sadly doesnt make it easier for no= rmal people without a company to get IVs or code signing certs, but the Ide= a is certainly not bad.

2017-12-01 14:53 GMT+01:00 Matthias Merkel <moritz30@= moritz30.de>:
<= div style=3D"font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif"= >I had the following idea about automating verification and issuance of OV = SSL certificates: Couldn't a CA in theory use the D&B API to check = the company name, address and phone number and then place an automatic call= ? That's basically what most CAs do anyways so is there any reason why = they couldn't do it? That would also be a way for Let's Encrypt to = issue OV certificates and code signing certificates.

=


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


--001a113d6cd4a0ce15055f47c186-- From nobody Fri Dec 1 06:21: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 3F01E12708C for ; Fri, 1 Dec 2017 06:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.99 X-Spam-Level: X-Spam-Status: No, score=-6.99 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, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sebbe.eu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wN-Gb40UCd7I for ; Fri, 1 Dec 2017 06:21:02 -0800 (PST) Received: from dns2.sebbe.eu (dns2.sebbe.eu [IPv6:2001:470:dff1:1:10::2]) (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 2E69B127078 for ; Fri, 1 Dec 2017 06:21:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sebbe.eu; s=root; h=Content-Type:MIME-Version:Subject:References:In-Reply-To: Message-ID:To:From:Date; bh=bpyfv7ZAwgMiAoR3/BktoDIu94k8MsIttMDMNrakeNo=; b=g Cllr7Xt2pb2TdK7VN2fBRa05flIdvWJuWTfoD7coNKYLIqJg/1LCwECm/62lC9ct+LZ0p2SOj55Rx L+R8p8VA7I3JRyaL4zXQLRrk+8zDKqNeaLOUzOP3jkBvM5yyoY8w80KzIVy9PCZ7fzNcWrwtESwQK RlohZAOYvETxPMuk=; Received: from localhost ([127.0.0.1] helo=linuxlite-desktop) by linuxlite-desktop with esmtp (Exim 4.86_2) (envelope-from ) id 1eKmBX-0001d7-4o for acme@ietf.org; Fri, 01 Dec 2017 15:20:59 +0100 Received: from [192.168.4.100] (helo=DESKTOPA8GMOTG) by linuxlite-desktop with esmtpa (Exim 4.86_2) (envelope-from ) id 1eKmBW-0001d3-Kj for acme@ietf.org; Fri, 01 Dec 2017 15:20:58 +0100 Date: Fri, 1 Dec 2017 15:21:00 +0100 From: "Sebastian Nielsen" To: Message-ID: <007301d36aaf$9c82b870$d5882950$@sebbe.eu> In-Reply-To: References: <160125ade25.db5555526773.39714603402561017@moritz30.de> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_0_1508587152.1512138059069" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGCmMvL2qPqXv+OfGNry1UEdBY7JwG0W6/0o8KKGsA= Archived-At: Subject: Re: [Acme] Idea about automated OV validation X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 14:21:05 -0000 ------=_Part_0_1508587152.1512138059069 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0074_01D36AB7.FE472070" Content-Language: sv This is a multipart message in MIME format. ------=_NextPart_000_0074_01D36AB7.FE472070 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Also could be done by having a interface where you scan your passport = with a NFC compatible reader (both mobile phone and desktop NFC reader = could be supported) and the government-signed data is uploaded. =20 So automated validation for private IV certs could be done too (IV =3D = Individual certs). So free code signing and IV validated certs. =20 https://community.letsencrypt.org/t/iv-certificates-both-server-and-code-= via-automated-nfc-passport-id-validation/44838 =20 Fr=C3=A5n: Acme [mailto:acme-bounces@ietf.org] F=C3=B6r Philipp = Junghann=C3=9F Skickat: den 1 december 2017 14:57 Till: Matthias Merkel Kopia: IETF ACME =C3=84mne: Re: [Acme] Idea about automated OV validation =20 if that's what other CAs do that's not a bad Idea although there's of = course the question whether there are some other manual checks needed. =20 but cheap to almost free OVs/code signing certs would be great although = that sadly doesnt make it easier for normal people without a company to = get IVs or code signing certs, but the Idea is certainly not bad. =20 2017-12-01 14:53 GMT+01:00 Matthias Merkel >: I had the following idea about automating verification and issuance of = OV SSL certificates: Couldn't a CA in theory use the D&B API to check = the company name, address and phone number and then place an automatic = call? That's basically what most CAs do anyways so is there any reason = why they couldn't do it? That would also be a way for Let's Encrypt to = issue OV certificates and code signing certificates. =20 =20 _______________________________________________ Acme mailing list Acme@ietf.org =20 https://www.ietf.org/mailman/listinfo/acme =20 ------=_NextPart_000_0074_01D36AB7.FE472070 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Also could be done by having a = interface where you scan your passport with a NFC compatible reader = (both mobile phone and desktop NFC reader could be supported) and the = government-signed data is uploaded.

 

So = automated validation for private IV certs could be done too (IV =3D = Individual certs). So free code signing and IV validated = certs.

 

https://community.letsencrypt.org/t/= iv-certificates-both-server-and-code-via-automated-nfc-passport-id-valida= tion/44838

 

Fr=C3=A5n: Acme [mailto:acme-bounces@ietf.org] = F=C3=B6r Philipp Junghann=C3=9F
Skickat: den 1 december = 2017 14:57
Till: Matthias Merkel = <moritz30@moritz30.de>
Kopia: IETF ACME = <acme@ietf.org>
=C3=84mne: Re: [Acme] Idea about = automated OV validation

 

if = that's what other CAs do that's not a bad Idea although there's of = course the question whether there are some other manual checks = needed.

 

but cheap to almost free OVs/code signing certs would = be great although that sadly doesnt make it easier for normal people = without a company to get IVs or code signing certs, but the Idea is = certainly not bad.

 

2017-12-01 14:53 GMT+01:00 Matthias Merkel <moritz30@moritz30.de>:

I had the = following idea about automating verification and issuance of OV SSL = certificates: Couldn't a CA in theory use the D&B API to check the = company name, address and phone number and then place an automatic call? = That's basically what most CAs do anyways so is there any reason why = they couldn't do it? That would also be a way for Let's Encrypt to issue = OV certificates and code signing certificates.

 

 


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

 

------=_NextPart_000_0074_01D36AB7.FE472070-- ------=_Part_0_1508587152.1512138059069 Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCAMIIF RTCCBC2gAwIBAgIIY1z1sUcn5kYwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAklUMQ8wDQYD VQQIDAZNaWxhbm8xDzANBgNVBAcMBk1pbGFubzEjMCEGA1UECgwaQWN0YWxpcyBTLnAuQS4vMDMz NTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIENBIEcxMB4X DTE3MTExMTAzMzM0OFoXDTE4MTExMTAzMzM0OFowHTEbMBkGA1UEAwwSc2ViYXN0aWFuQHNlYmJl LmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmT1KZ1G4QWcvDCHONMbBynyMsN4A F+8IXSCqu2rpPith70w/KqdILvVDP2denK2tIATLkUPQ7SG2lYzhm1874LDq4Rh2M/dB83sAblGW n1qIFSuYnMFe3jO5XCoN0je0iv/3ASGCQcymhPeeFefGsqpr5btDLKwdZcfZrjqBDLD5hjeqX+f1 Zo5xkPKK0kj9wlBgWzn72IZwZvs0l+bdjVS1bmZFe0+i9R/sgUlNs1/JlfVsXYgPD6ncq7bJCcYN +jFNqR/bQ2sV3rKZXcltiIYROSGnJQ2SOGv/lVQ0wD8OVYqyUuOqMvJBR4sqauclLVRfGKZ1tufR 9qVaQmPsYQIDAQABo4ICITCCAh0wSwYIKwYBBQUHAQEEPzA9MDsGCCsGAQUFBzAChi9odHRwOi8v Y2FjZXJ0LmFjdGFsaXMuaXQvY2VydHMvYWN0YWxpcy1hdXRjbGlnMTAdBgNVHQ4EFgQUzHTxBzTo 9ekiseKvYUaxJVzkzSgwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBR+YPz4bKc9Pdeuk6F5Ao+z dCk79TBHBgNVHSAEQDA+MDwGBiuBHwEYATAyMDAGCCsGAQUFBwIBFiRodHRwczovL3d3dy5hY3Rh bGlzLml0L2FyZWEtZG93bmxvYWQwgegGA1UdHwSB4DCB3TCBm6CBmKCBlYaBkmxkYXA6Ly9sZGFw MDUuYWN0YWxpcy5pdC9jbiUzZEFjdGFsaXMlMjBDbGllbnQlMjBBdXRoZW50aWNhdGlvbiUyMENB JTIwRzEsbyUzZEFjdGFsaXMlMjBTLnAuQS4vMDMzNTg1MjA5NjcsYyUzZElUP2NlcnRpZmljYXRl UmV2b2NhdGlvbkxpc3Q7YmluYXJ5MD2gO6A5hjdodHRwOi8vY3JsMDUuYWN0YWxpcy5pdC9SZXBv c2l0b3J5L0FVVEhDTC1HMS9nZXRMYXN0Q1JMMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0RBBYwFIESc2ViYXN0aWFuQHNlYmJlLmV1MA0GCSqGSIb3 DQEBCwUAA4IBAQCyqAPE4i4dsEsMY/Ukxs+ZILWn6t3LXZm8WBsFV4IAZxaS/GW1VhyxJpFbubdN dfaHxxd4ragdfRyjLw+67sz3Av8U0y/jpEjcKWnAzh5Jitd7obF3qzQUaU0r+JVJ4o3gVzEWTmOS ZLUEiFpMtk5rB0BiNaFh0y6RgK7dt7o7VCWle7+pQG2sMrD6cBl9DOLwY1Wqqjj7crzIm2ST7Cfu O/IUy9mFxm4mECcqpehqTA5NKtS3GXGHy1XpU1WhF4BVHakYt3oNZYw9pnzSLLPuEgf72zpbrgN2 j7QfYH0N0eZ4NBi/dBCJ+MXKobPo8OKmRb999p0pTj7cYacRyeI4MIIGRzCCBC+gAwIBAgIILNSK 07EeD4kwDQYJKoZIhvcNAQELBQAwazELMAkGA1UEBhMCSVQxDjAMBgNVBAcMBU1pbGFuMSMwIQYD VQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEnMCUGA1UEAwweQWN0YWxpcyBBdXRoZW50 aWNhdGlvbiBSb290IENBMB4XDTE1MDUxNDA3MTQxNVoXDTMwMDUxNDA3MTQxNVowgYIxCzAJBgNV BAYTAklUMQ8wDQYDVQQIDAZNaWxhbm8xDzANBgNVBAcMBk1pbGFubzEjMCEGA1UECgwaQWN0YWxp cyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIENBIEcxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwPzBiVbZiOL0BGW/zQk1 qygpMP4MyvcnqxwR7oY9XeT1bES2DFczlZfeiIqNLanbkyqTxydXZ+kxoS9071qWsZ6zS+pxSqXL s+RTvndEaWx5hdHZcKNWGzhy5FiO4GZvGlFInFEiaY+dOEpjjWvSeXpvcDpnYw6M9AXuHo4JhjC3 P/OK//5QFXnztTa4iU66RpLteOTgCtiRCwZNKx8EFeqqfTpYvfEb4H91E7n+Y61jm0d2E8fJ2wGT aSSwjc8nTI2ApXujoczukb2kHqwaGP3q5UuedWcnRZc65XUhK/Z6K32KvrQuNP32F/5MxkvEDnJp Unnt9iMExvEzn31zDQIDAQABo4IB1TCCAdEwQQYIKwYBBQUHAQEENTAzMDEGCCsGAQUFBzABhiVo dHRwOi8vb2NzcDA1LmFjdGFsaXMuaXQvVkEvQVVUSC1ST09UMB0GA1UdDgQWBBR+YPz4bKc9Pdeu k6F5Ao+zdCk79TAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFFLYiDrIn3hm7YnzezhwlMkC AjbQMEUGA1UdIAQ+MDwwOgYEVR0gADAyMDAGCCsGAQUFBwIBFiRodHRwczovL3d3dy5hY3RhbGlz Lml0L2FyZWEtZG93bmxvYWQwgeMGA1UdHwSB2zCB2DCBlqCBk6CBkIaBjWxkYXA6Ly9sZGFwMDUu YWN0YWxpcy5pdC9jbiUzZEFjdGFsaXMlMjBBdXRoZW50aWNhdGlvbiUyMFJvb3QlMjBDQSxvJTNk QWN0YWxpcyUyMFMucC5BLiUyZjAzMzU4NTIwOTY3LGMlM2RJVD9jZXJ0aWZpY2F0ZVJldm9jYXRp b25MaXN0O2JpbmFyeTA9oDugOYY3aHR0cDovL2NybDA1LmFjdGFsaXMuaXQvUmVwb3NpdG9yeS9B VVRILVJPT1QvZ2V0TGFzdENSTDAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQELBQADggIBAE2T ztUkvkEbShZYc19lifLZej5YjLzLxA/lWxZnssFLpDPySfzMmndz3F06S51ltwDe+blTwcpdzUl3 M2alKH3bOr855ku9Rr6uedya+HGQUT0OhqDo2K2CAE9nBcfANxifjfT8XzCoC3ctf9ux3og1WuE8 WTcLZKgCMuNRBmJte9C4Ug0w3iXqPzq8KuRRobNKqddPjk3EiK+QA+EFCCka1xOLh/7cPGTJMNta 1/0u5oLiXaOAHeALt/nqeZ2kZ+lizK8oTv4in5avIf3ela3oL6vrwpTca7TZxTX90e805dZQN4qR VPdPbrBlWtNozH7SdLeLrcoN8l2EXO6190GAJYdynTc2E6EyrLVGcDKUX91VmCSRrqEppZ7W05Tb WRLi6+wPjAzmTq2XSmKfajq7juTKgkkw7FFJByixa0NdSZosdQb3VkLqG8EOYOamZLqH+v7ua0+u lg7FOviFbeZ7YR9eRO81O8FC1uLgutlyGD2+GLjgQnsvneDsbNAWfkory+qqAxvVzX5PSaQp2pJ5 2AaIH1MN1i2/geRSP83TRMrFkwuIMzDhXxKFQvpspNc19vcTryzjtwP4xq0WNS4YWPS4U+9mW+U0 Cgnsgx9fMiJNbLflf5qSb53j3AGHnjK/qJzPa39wFTXLXB648F3w1Qf9R7eZeTRJfCQY/fJUAAAx ggLJMIICxQIBATCBjzCBgjELMAkGA1UEBhMCSVQxDzANBgNVBAgMBk1pbGFubzEPMA0GA1UEBwwG TWlsYW5vMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoGA1UEAwwjQWN0 YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzECCGNc9bFHJ+ZGMA0GCWCGSAFlAwQCAQUA oIIBCjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEyMDExNDIw NTlaMC8GCSqGSIb3DQEJBDEiBCA4IpceVVCUmUnhc5EiQolaIOIbkCJWyK+BsmwDjsmCuDCBngYJ KoZIhvcNAQkPMYGQMIGNMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAPBgkqhkiG9n0HQgoCAgCAMA0GCyqDCIyaSz0BAQEE MA0GCyqDCIyaSz0BAQEDMA0GCyqDCIyaSz0BAQECMAoGCCqDGoyaRAEEMA0GCSqGSIb3DQEBAQUA BIIBAHC8SEQeYt4587qpHmteDG9D1fexQiZ6bPYwsRnUg3ZC4BeyYOC4EhCRXN4uAz3OheEjoQt3 oyTzHvI2ocx54fa28ptK55ld/ODx9KVRcHhGJxMm3uoqPD0lPV4/R9ApOijWqe0DGrr094pcAmOh tCE5BhxzkbqNBpUo58B3YSSNPdEZ4GtsRq3kOnePEF5qPaXZVAUiNRaVWpa6LpkQXudgQMnDjCQ2 i2/gHBc6zMLJhdsesmJE1sfiwaX0H2/nNmIi/xBeGif64ez0nxHtNb5IvcqQhyw2zuoNDuI3zZoj vsyV12ZyPAunAKASV1FKB1H+10vYt6/G3creqLMh9/MAAAAAAAA= ------=_Part_0_1508587152.1512138059069-- From nobody Fri Dec 1 06:31:10 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 F2B73129329 for ; Fri, 1 Dec 2017 06:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 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, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 O8SkprIgp6iK for ; Fri, 1 Dec 2017 06:31:03 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62568126BF0 for ; Fri, 1 Dec 2017 06:31:03 -0800 (PST) Received: by mail-oi0-x231.google.com with SMTP id t78so7250161oie.8 for ; Fri, 01 Dec 2017 06:31:03 -0800 (PST) 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=Q5bKHgdrmkI0k3pMB4ZcMvMUppL9Op64ghk7E9zFxGU=; b=Jjiv16+N+hQDCoSCsD1TqgDLdWvl9sJfX4CTltS9p7BydtpYBV2j2ek/llo4I4I49L mkR6og4PmK+kgW4RW4nGQVGMlBZlPdgsFQnG6YiPIRpVT5HPKfCXKRMDbL8w89NYO/CI RsYYF73+6JsFMGysWJtP5rqMNUgV+JXgBzVQFZZmYlS//3QRcLT4CwPHEeHGszDUq2Jm njnDABG2aWVZlsc+YNEH0nJ1AHgZIKKjeDZDIkq+s6ltqJMjyTC9qt8yvppCxsRE7q7k MxeTseo5cuWEzeugb4cp8qPJ/SJXtwzZmpezF4rjlhak8D1JYcioYLG0ysAMNeq6ZUil vd4g== 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=Q5bKHgdrmkI0k3pMB4ZcMvMUppL9Op64ghk7E9zFxGU=; b=iDQrYQ9gY6pJ7Eoq7sOkKE1tyQ5w3lfi+yWFLjYhqBO0nVUhYE5Xkt4aYsxIO3fA2D jwpjHv0ms2BiPNwnMDn047zVOl/JFtsBw2nHG5q5qpbxInc5iL8C9tg2LRp6i4I9tsAF RGSrqe0zuVYYXs0ti3drrbBI3xLNYqetwBH/ewFfQW9sGYUKi962G1S53DPy6r0ETPUH r5mq1DJPVxcUS9pwufjPcEpQMVOeMogPpMNaaaU76wdjjOhyHZRV8kMO2AX3z0VsJlR1 yDLKe9X3EOt8cDWZjYwc1awLuLFKLmz0mW+lGVW4PVHYhJUmJjOis80d3C7HIy41DUbY Kcaw== X-Gm-Message-State: AJaThX6mINtvYixOJbK+wghjLYT3QJ/6kYM5GSMg36XvYTK/G5PGzX6E XRwWZ//alnewL01x1A1mWgwHiJDJxbX7Zp359GKggw== X-Google-Smtp-Source: AGs4zMYnEQtUTML3bow8lkqroc6TMdUQqSH7QQE7Gfa9Q1pa+CEAUClc4zzYhgqwC2KkTRSoMJYbToil63TjmX80bAQ= X-Received: by 10.202.117.13 with SMTP id q13mr7050631oic.52.1512138662665; Fri, 01 Dec 2017 06:31:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.29.210 with HTTP; Fri, 1 Dec 2017 06:30:22 -0800 (PST) In-Reply-To: <007301d36aaf$9c82b870$d5882950$@sebbe.eu> References: <160125ade25.db5555526773.39714603402561017@moritz30.de> <007301d36aaf$9c82b870$d5882950$@sebbe.eu> From: =?UTF-8?Q?Philipp_Junghann=C3=9F?= Date: Fri, 1 Dec 2017 15:30:22 +0100 Message-ID: To: Sebastian Nielsen Cc: IETF ACME Content-Type: multipart/alternative; boundary="001a1134fb3ed6e1ee055f48370d" Archived-At: Subject: Re: [Acme] Idea about automated OV validation X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 14:31:09 -0000 --001a1134fb3ed6e1ee055f48370d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable well true passports/ID cards are intresting although there's alayes the problem about the access structure and so on. German ID cards for example can only be read with a certificate from a "permission certificate authority", which are most probably selected by the gov and I wouldnt expect those permission certs to come cheap, they also require documentation about how the company handles privacy and so on and so on, add some more countries with their own respective systems into the mix and we have pure chaos. I doubt a non-profit CA like LE could do that well. 2017-12-01 15:21 GMT+01:00 Sebastian Nielsen : > Also could be done by having a interface where you scan your passport wit= h > a NFC compatible reader (both mobile phone and desktop NFC reader could b= e > supported) and the government-signed data is uploaded. > > > > So automated validation for private IV certs could be done too (IV =3D > Individual certs). So free code signing and IV validated certs. > > > > https://community.letsencrypt.org/t/iv-certificates-both- > server-and-code-via-automated-nfc-passport-id-validation/44838 > > > > *Fr=C3=A5n:* Acme [mailto:acme-bounces@ietf.org] *F=C3=B6r *Philipp Jungh= ann=C3=9F > *Skickat:* den 1 december 2017 14:57 > *Till:* Matthias Merkel > *Kopia:* IETF ACME > *=C3=84mne:* Re: [Acme] Idea about automated OV validation > > > > if that's what other CAs do that's not a bad Idea although there's of > course the question whether there are some other manual checks needed. > > > > but cheap to almost free OVs/code signing certs would be great although > that sadly doesnt make it easier for normal people without a company to g= et > IVs or code signing certs, but the Idea is certainly not bad. > > > > 2017-12-01 14:53 GMT+01:00 Matthias Merkel : > > I had the following idea about automating verification and issuance of OV > SSL certificates: Couldn't a CA in theory use the D&B API to check the > company name, address and phone number and then place an automatic call? > That's basically what most CAs do anyways so is there any reason why they > couldn't do it? That would also be a way for Let's Encrypt to issue OV > certificates and code signing certificates. > > > > > > > _______________________________________________ > 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 > > --001a1134fb3ed6e1ee055f48370d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
well true passports/ID cards are intresting although there= 's alayes the problem about the access structure and so on. German ID c= ards for example can only be read with a certificate from a "permissio= n certificate authority", which are most probably selected by the gov = and I wouldnt expect those permission certs to come cheap, they also requir= e documentation about how the company handles privacy and so on and so on, = add some more countries with their own respective systems into the mix and = we have pure chaos. I doubt a non-profit CA like LE could do that well.

2017-12-01 15:2= 1 GMT+01:00 Sebastian Nielsen <sebastian@sebbe.eu>:
=

Also could be done by having a interface where you scan your passport w= ith a NFC compatible reader (both mobile phone and desktop NFC reader could= be supported) and the government-signed data is uploaded.

=C2=A0

So automated validation for private IV certs could be= done too (IV =3D Individual certs). So free code signing and IV validated = certs.

=C2=A0

https://community.letsencrypt.org/t/iv-certificates-bo= th-server-and-code-via-automated-nfc-passport-id-validation/= 44838

=C2=A0=

Fr=C3=A5n: Acme [mailto:acme-bounces@ietf.org] F=C3=B6r <= /b>Philipp Junghann=C3=9F
Skickat: den 1 december 2017 14:57
<= b>Till: Matthias Merkel <mor= itz30@moritz30.de>
Kopia: IETF ACME <acme@ietf.org>
=C3=84mne: Re: [Acme] Idea a= bout automated OV validation

=C2=A0

if tha= t's what other CAs do that's not a bad Idea although there's of= course the question whether there are some other manual checks needed.<= /u>

=C2=A0

but cheap to almost free OVs/code signing certs wo= uld be great although that sadly doesnt make it easier for normal people wi= thout a company to get IVs or code signing certs, but the Idea is certainly= not bad.

= =C2=A0

2017-12-01 14:53 GMT+01:00 Mat= thias Merkel <moritz30@moritz30.de>:

I had the following idea about auto= mating verification and issuance of OV SSL certificates: Couldn't a CA = in theory use the D&B API to check the company name, address and phone = number and then place an automatic call? That's basically what most CAs= do anyways so is there any reason why they couldn't do it? That would = also be a way for Let's Encrypt to issue OV certificates and code signi= ng certificates.

=C2= =A0

=C2=A0

<= /div>


____________= ___________________________________
Acme mailing list
Acme@ie= tf.org
https://www.ietf.org/mailman/listinfo/acme=

=C2=A0


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


--001a1134fb3ed6e1ee055f48370d-- From nobody Fri Dec 1 07:01: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 D6C7C126C3D for ; Fri, 1 Dec 2017 07:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.99 X-Spam-Level: X-Spam-Status: No, score=-6.99 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, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sebbe.eu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5bEPddbjqjJ for ; Fri, 1 Dec 2017 07:01:12 -0800 (PST) Received: from dns2.sebbe.eu (dns2.sebbe.eu [IPv6:2001:470:dff1:1:10::2]) (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 E6BC8120713 for ; Fri, 1 Dec 2017 07:01:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sebbe.eu; s=root; h=Content-Type:MIME-Version:Subject:Message-ID:To:From:Date; bh=/38GxbiWkiiY4eFaWsbHn4gG0ne9aVry1k6KKkCSk9o=; b=PDZDEWyx6f9V1GIv/AZh95S4Uj CJo5Ks694qW8SguNRX9HnLpbqrM48Fg1d6K830PV20tBd8Rivm1lQ9MlThLIy4tLHzn8ejjqhgvk6 cBBVQdGFD6q3hgyWa7sYigMv6tcZ7HSUUVJVWc2wKm4Ta+E0kt9wa99vq1gl507DD94g=; Received: from localhost ([127.0.0.1] helo=linuxlite-desktop) by linuxlite-desktop with esmtp (Exim 4.86_2) (envelope-from ) id 1eKmoO-0001iu-Ij for acme@ietf.org; Fri, 01 Dec 2017 16:01:08 +0100 Received: from [192.168.2.2] by linuxlite-desktop with esmtpa (Exim 4.86_2) (envelope-from ) id 1eKmoN-0001iq-QQ for acme@ietf.org; Fri, 01 Dec 2017 16:01:08 +0100 Date: Fri, 01 Dec 2017 16:01:05 +0100 From: Sebastian Nielsen To: acme@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_4_1100691100.1512140468519" SavedFromEmail: sebastian@sebbe.eu Importance: normal Archived-At: Subject: Re: [Acme] Idea about automated OV validation X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 15:01:14 -0000 ------=_Part_4_1100691100.1512140468519 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_341600897222580" ----_com.samsung.android.email_341600897222580 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 T24gSUNBTy1hcHByb3ZlZCBwYXNzcG9ydHMvSUQtY2FyZHMsIGRhdGEgbXVzdCBiZSBvcGVuIGZv ciByZWFkIHdpdGggcGFydHMgb2YgTVJaIGFzIHBhc3N3b3JkLCBhcyByZWx5aW5nIHBhcnRpZXMg c2hvdWxkIG5vdCBuZWVkIHRvIGFzayBhIGNvdW50cnkgZm9yIHBlcm1pc3Npb24gdG8gcmVhZCBk YXRhIHZpc2libGUgb24gdGhlIHByaW50ZWQgcGFnZXMgb2YgcGFzc3BvcnQvSUQsIGJ1dCBwZXJt aXNzaW9uIGZyb20gcGFzc3BvcnQvSUQgaG9sZGVyIGlzIHJlcXVpcmVkLgpGaW5nZXJwcmludCBv ciBpcmlzIGRhdGEgaXMgaG93ZXZlciBsb2NrZWQgYW5kIHJlcXVpcmVzIGEgY2VydGlmaWNhdGUg KyBwcml2YXRlIGtleSwgYW5kIHJlcXVpcmVzIGNvdW50cnkgcGVybWlzc2lvbi4KRmFjZSBkYXRh IGRvZXMgaG93ZXZlciBub3QgcmVxdWlyZSB0aGlzLCBmYWNlIGRhdGEgbXVzdCBiZSBpbmNsdWRl ZCBpbiB0aGUgb3BlbiBkYXRhLgpTbyBpdCBjb3VsZCBiZSBsaW1pdGVkIHRvIElDQU8tYXBwcm92 ZWQgcGFzc3BvcnRzL0lELWNhcmRzLsKgClRoZXJlIGlzIGEgSUNBTy1zdGFuZGFyZCBpbiBkZXZl bG9wbWVudCB3aGVyZSB0aGUgcGFzc3BvcnQgY2FuIGJlICJsb2NrZWQiIHdpdGggYSBQSU4tY29k ZS9wYXNzd29yZCAtIHRvIHByZXZlbnQgc3B1cmlvdXMgcmVhZHMgd2l0aG91dCBwYXNzcG9ydCBo b2xkZXIgcGVybWlzc2lvbiwgYXMgdGhlIE1SWi1hdXRoZW50aWNhdGlvbiBkYXRhIHVzZWQgdG8g dW5sb2NrIGlzIGVhc2lseSBwcmVkaWN0ZWQgb24gc29tZSBwYXNzcG9ydHMsIGJ1dCB0aGVuIHRo aXMgUElOLWNvZGUvcGFzc3dvcmQgTVVTVCBiZSBzdXBwbGllZCB0byB0aGUgaG9sZGVyIGF0IGlz c3VlLgpTdGF0aWMgYW5kIGR5bmFtaWMgZGF0YSBhdXRoZW50aWNhdGlvbiBjYW4gYmUgZG9uZSBi eSBhbnlvbmUgcG9zZXNzaW5nIHRoZSBJQ0FPIHJvb3RzIGZvciBlYWNoIGNvdW50cnksIHdoaWNo IGNhbiBiZSBmcmVlbHkgZG93bmxvYWRlZCBieSBhbnlvbmUuVGhpcyB2YWxpZGF0ZXMgdGhlIHBh c3Nwb3J0IGhhc24ndCBiZWVuIG1vZGlmaWVkIG9yIGNvcGllZCwgYW5kIGhhcyBiZWVuIGlzc3Vl ZCBieSBhIGFwcHJvdmVkIGdvdmVybm1lbnQuCi0tLS0tLS0tIE9yaWdpbmFsbWVkZGVsYW5kZSAt LS0tLS0tLUZyw6VuOiBQaGlsaXBwIEp1bmdoYW5uw58gPHRlYW1oeWRybzU1NTU1QGdtYWlsLmNv bT4gRGF0dW06IDIwMTctMTItMDEgIDE1OjMwICAoR01UKzAxOjAwKSBUaWxsOiBTZWJhc3RpYW4g TmllbHNlbiA8c2ViYXN0aWFuQHNlYmJlLmV1PiBLb3BpYTogSUVURiBBQ01FIDxhY21lQGlldGYu b3JnPiBSdWJyaWs6IFJlOiBbQWNtZV0gSWRlYSBhYm91dCBhdXRvbWF0ZWQgT1YgdmFsaWRhdGlv biAKd2VsbCB0cnVlIHBhc3Nwb3J0cy9JRCBjYXJkcyBhcmUgaW50cmVzdGluZyBhbHRob3VnaCB0 aGVyZSdzIGFsYXllcyB0aGUgcHJvYmxlbSBhYm91dCB0aGUgYWNjZXNzIHN0cnVjdHVyZSBhbmQg c28gb24uIEdlcm1hbiBJRCBjYXJkcyBmb3IgZXhhbXBsZSBjYW4gb25seSBiZSByZWFkIHdpdGgg YSBjZXJ0aWZpY2F0ZSBmcm9tIGEgInBlcm1pc3Npb24gY2VydGlmaWNhdGUgYXV0aG9yaXR5Iiwg d2hpY2ggYXJlIG1vc3QgcHJvYmFibHkgc2VsZWN0ZWQgYnkgdGhlIGdvdiBhbmQgSSB3b3VsZG50 IGV4cGVjdCB0aG9zZSBwZXJtaXNzaW9uIGNlcnRzIHRvIGNvbWUgY2hlYXAsIHRoZXkgYWxzbyBy ZXF1aXJlIGRvY3VtZW50YXRpb24gYWJvdXQgaG93IHRoZSBjb21wYW55IGhhbmRsZXMgcHJpdmFj eSBhbmQgc28gb24gYW5kIHNvIG9uLCBhZGQgc29tZSBtb3JlIGNvdW50cmllcyB3aXRoIHRoZWly IG93biByZXNwZWN0aXZlIHN5c3RlbXMgaW50byB0aGUgbWl4IGFuZCB3ZSBoYXZlIHB1cmUgY2hh b3MuIEkgZG91YnQgYSBub24tcHJvZml0IENBIGxpa2UgTEUgY291bGQgZG8gdGhhdCB3ZWxsLgoy MDE3LTEyLTAxIDE1OjIxIEdNVCswMTowMCBTZWJhc3RpYW4gTmllbHNlbiA8c2ViYXN0aWFuQHNl YmJlLmV1PjoKQWxzbyBjb3VsZCBiZSBkb25lIGJ5IGhhdmluZyBhIGludGVyZmFjZSB3aGVyZSB5 b3Ugc2NhbiB5b3VyIHBhc3Nwb3J0IHdpdGggYSBORkMgY29tcGF0aWJsZSByZWFkZXIgKGJvdGgg bW9iaWxlIHBob25lIGFuZCBkZXNrdG9wIE5GQyByZWFkZXIgY291bGQgYmUgc3VwcG9ydGVkKSBh bmQgdGhlIGdvdmVybm1lbnQtc2lnbmVkIGRhdGEgaXMgdXBsb2FkZWQuwqBTbyBhdXRvbWF0ZWQg dmFsaWRhdGlvbiBmb3IgcHJpdmF0ZSBJViBjZXJ0cyBjb3VsZCBiZSBkb25lIHRvbyAoSVYgPSBJ bmRpdmlkdWFsIGNlcnRzKS4gU28gZnJlZSBjb2RlIHNpZ25pbmcgYW5kIElWIHZhbGlkYXRlZCBj ZXJ0cy7CoGh0dHBzOi8vY29tbXVuaXR5LmxldHNlbmNyeXB0Lm9yZy90L2l2LWNlcnRpZmljYXRl cy1ib3RoLXNlcnZlci1hbmQtY29kZS12aWEtYXV0b21hdGVkLW5mYy1wYXNzcG9ydC1pZC12YWxp ZGF0aW9uLzQ0ODM4wqBGcsOlbjogQWNtZSBbbWFpbHRvOmFjbWUtYm91bmNlc0BpZXRmLm9yZ10g RsO2ciBQaGlsaXBwIEp1bmdoYW5uw58KU2tpY2thdDogZGVuIDEgZGVjZW1iZXIgMjAxNyAxNDo1 NwpUaWxsOiBNYXR0aGlhcyBNZXJrZWwgPG1vcml0ejMwQG1vcml0ejMwLmRlPgpLb3BpYTogSUVU RiBBQ01FIDxhY21lQGlldGYub3JnPgrDhG1uZTogUmU6IFtBY21lXSBJZGVhIGFib3V0IGF1dG9t YXRlZCBPViB2YWxpZGF0aW9uwqBpZiB0aGF0J3Mgd2hhdCBvdGhlciBDQXMgZG8gdGhhdCdzIG5v dCBhIGJhZCBJZGVhIGFsdGhvdWdoIHRoZXJlJ3Mgb2YgY291cnNlIHRoZSBxdWVzdGlvbiB3aGV0 aGVyIHRoZXJlIGFyZSBzb21lIG90aGVyIG1hbnVhbCBjaGVja3MgbmVlZGVkLsKgYnV0IGNoZWFw IHRvIGFsbW9zdCBmcmVlIE9Wcy9jb2RlIHNpZ25pbmcgY2VydHMgd291bGQgYmUgZ3JlYXQgYWx0 aG91Z2ggdGhhdCBzYWRseSBkb2VzbnQgbWFrZSBpdCBlYXNpZXIgZm9yIG5vcm1hbCBwZW9wbGUg d2l0aG91dCBhIGNvbXBhbnkgdG8gZ2V0IElWcyBvciBjb2RlIHNpZ25pbmcgY2VydHMsIGJ1dCB0 aGUgSWRlYSBpcyBjZXJ0YWlubHkgbm90IGJhZC7CoDIwMTctMTItMDEgMTQ6NTMgR01UKzAxOjAw IE1hdHRoaWFzIE1lcmtlbCA8bW9yaXR6MzBAbW9yaXR6MzAuZGU+OkkgaGFkIHRoZSBmb2xsb3dp bmcgaWRlYSBhYm91dCBhdXRvbWF0aW5nIHZlcmlmaWNhdGlvbiBhbmQgaXNzdWFuY2Ugb2YgT1Yg U1NMIGNlcnRpZmljYXRlczogQ291bGRuJ3QgYSBDQSBpbiB0aGVvcnkgdXNlIHRoZSBEJkIgQVBJ IHRvIGNoZWNrIHRoZSBjb21wYW55IG5hbWUsIGFkZHJlc3MgYW5kIHBob25lIG51bWJlciBhbmQg dGhlbiBwbGFjZSBhbiBhdXRvbWF0aWMgY2FsbD8gVGhhdCdzIGJhc2ljYWxseSB3aGF0IG1vc3Qg Q0FzIGRvIGFueXdheXMgc28gaXMgdGhlcmUgYW55IHJlYXNvbiB3aHkgdGhleSBjb3VsZG4ndCBk byBpdD8gVGhhdCB3b3VsZCBhbHNvIGJlIGEgd2F5IGZvciBMZXQncyBFbmNyeXB0IHRvIGlzc3Vl IE9WIGNlcnRpZmljYXRlcyBhbmQgY29kZSBzaWduaW5nIGNlcnRpZmljYXRlcy7CoMKgCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkFjbWUgbWFpbGluZyBs aXN0CkFjbWVAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9h Y21lwqAKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkFj bWUgbWFpbGluZyBsaXN0CgpBY21lQGlldGYub3JnCgpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2FjbWUKCgoKCg== ----_com.samsung.android.email_341600897222580 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT5PbiBJQ0FPLWFwcHJvdmVkIHBhc3Nw b3J0cy9JRC1jYXJkcywgZGF0YSBtdXN0IGJlIG9wZW4gZm9yIHJlYWQgd2l0aCBwYXJ0cyBvZiBN UlogYXMgcGFzc3dvcmQsIGFzIHJlbHlpbmcgcGFydGllcyBzaG91bGQgbm90IG5lZWQgdG8gYXNr IGEgY291bnRyeSBmb3IgcGVybWlzc2lvbiB0byByZWFkIGRhdGEgdmlzaWJsZSBvbiB0aGUgcHJp bnRlZCBwYWdlcyBvZiBwYXNzcG9ydC9JRCwgYnV0IHBlcm1pc3Npb24gZnJvbSBwYXNzcG9ydC9J RCBob2xkZXIgaXMgcmVxdWlyZWQuPGRpdj48YnI+PC9kaXY+PGRpdj5GaW5nZXJwcmludCBvciBp cmlzIGRhdGEgaXMgaG93ZXZlciBsb2NrZWQgYW5kIHJlcXVpcmVzIGEgY2VydGlmaWNhdGUgKyBw cml2YXRlIGtleSwgYW5kIHJlcXVpcmVzIGNvdW50cnkgcGVybWlzc2lvbi48L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2PkZhY2UgZGF0YSBkb2VzIGhvd2V2ZXIgbm90IHJlcXVpcmUgdGhpcywgZmFj ZSBkYXRhIG11c3QgYmUgaW5jbHVkZWQgaW4gdGhlIG9wZW4gZGF0YS48ZGl2IGRpcj0iYXV0byI+ PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5TbyBpdCBjb3VsZCBiZSBsaW1pdGVkIHRvIElDQU8t YXBwcm92ZWQgcGFzc3BvcnRzL0lELWNhcmRzLiZuYnNwOzwvZGl2PjxkaXYgZGlyPSJhdXRvIj48 YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPlRoZXJlIGlzIGEgSUNBTy1zdGFuZGFyZCBpbiBkZXZl bG9wbWVudCB3aGVyZSB0aGUgcGFzc3BvcnQgY2FuIGJlICJsb2NrZWQiIHdpdGggYSBQSU4tY29k ZS9wYXNzd29yZCAtIHRvIHByZXZlbnQgc3B1cmlvdXMgcmVhZHMgd2l0aG91dCBwYXNzcG9ydCBo b2xkZXIgcGVybWlzc2lvbiwgYXMgdGhlIE1SWi1hdXRoZW50aWNhdGlvbiBkYXRhIHVzZWQgdG8g dW5sb2NrIGlzIGVhc2lseSBwcmVkaWN0ZWQgb24gc29tZSBwYXNzcG9ydHMsIGJ1dCB0aGVuIHRo aXMgUElOLWNvZGUvcGFzc3dvcmQgTVVTVCBiZSBzdXBwbGllZCB0byB0aGUgaG9sZGVyIGF0IGlz c3VlLjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPlN0YXRp YyBhbmQgZHluYW1pYyBkYXRhIGF1dGhlbnRpY2F0aW9uIGNhbiBiZSBkb25lIGJ5IGFueW9uZSBw b3Nlc3NpbmcgdGhlIElDQU8gcm9vdHMgZm9yIGVhY2ggY291bnRyeSwgd2hpY2ggY2FuIGJlIGZy ZWVseSBkb3dubG9hZGVkIGJ5IGFueW9uZS48L2Rpdj48ZGl2IGRpcj0iYXV0byI+VGhpcyB2YWxp ZGF0ZXMgdGhlIHBhc3Nwb3J0IGhhc24ndCBiZWVuIG1vZGlmaWVkIG9yIGNvcGllZCwgYW5kIGhh cyBiZWVuIGlzc3VlZCBieSBhIGFwcHJvdmVkIGdvdmVybm1lbnQuPC9kaXY+PC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1zaXplOjEwMCU7Y29sb3I6IzAwMDAwMCI+PCEtLSBv cmlnaW5hbE1lc3NhZ2UgLS0+PGRpdj4tLS0tLS0tLSBPcmlnaW5hbG1lZGRlbGFuZGUgLS0tLS0t LS08L2Rpdj48ZGl2PkZyw6VuOiBQaGlsaXBwIEp1bmdoYW5uw58gJmx0O3RlYW1oeWRybzU1NTU1 QGdtYWlsLmNvbSZndDsgPC9kaXY+PGRpdj5EYXR1bTogMjAxNy0xMi0wMSAgMTU6MzAgIChHTVQr MDE6MDApIDwvZGl2PjxkaXY+VGlsbDogU2ViYXN0aWFuIE5pZWxzZW4gJmx0O3NlYmFzdGlhbkBz ZWJiZS5ldSZndDsgPC9kaXY+PGRpdj5Lb3BpYTogSUVURiBBQ01FICZsdDthY21lQGlldGYub3Jn Jmd0OyA8L2Rpdj48ZGl2PlJ1YnJpazogUmU6IFtBY21lXSBJZGVhIGFib3V0IGF1dG9tYXRlZCBP ViB2YWxpZGF0aW9uIDwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvZGl2PjxkaXYgZGlyPSJsdHIiPndl bGwgdHJ1ZSBwYXNzcG9ydHMvSUQgY2FyZHMgYXJlIGludHJlc3RpbmcgYWx0aG91Z2ggdGhlcmUn cyBhbGF5ZXMgdGhlIHByb2JsZW0gYWJvdXQgdGhlIGFjY2VzcyBzdHJ1Y3R1cmUgYW5kIHNvIG9u LiBHZXJtYW4gSUQgY2FyZHMgZm9yIGV4YW1wbGUgY2FuIG9ubHkgYmUgcmVhZCB3aXRoIGEgY2Vy dGlmaWNhdGUgZnJvbSBhICJwZXJtaXNzaW9uIGNlcnRpZmljYXRlIGF1dGhvcml0eSIsIHdoaWNo IGFyZSBtb3N0IHByb2JhYmx5IHNlbGVjdGVkIGJ5IHRoZSBnb3YgYW5kIEkgd291bGRudCBleHBl Y3QgdGhvc2UgcGVybWlzc2lvbiBjZXJ0cyB0byBjb21lIGNoZWFwLCB0aGV5IGFsc28gcmVxdWly ZSBkb2N1bWVudGF0aW9uIGFib3V0IGhvdyB0aGUgY29tcGFueSBoYW5kbGVzIHByaXZhY3kgYW5k IHNvIG9uIGFuZCBzbyBvbiwgYWRkIHNvbWUgbW9yZSBjb3VudHJpZXMgd2l0aCB0aGVpciBvd24g cmVzcGVjdGl2ZSBzeXN0ZW1zIGludG8gdGhlIG1peCBhbmQgd2UgaGF2ZSBwdXJlIGNoYW9zLiBJ IGRvdWJ0IGEgbm9uLXByb2ZpdCBDQSBsaWtlIExFIGNvdWxkIGRvIHRoYXQgd2VsbC48L2Rpdj48 ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4yMDE3 LTEyLTAxIDE1OjIxIEdNVCswMTowMCBTZWJhc3RpYW4gTmllbHNlbiA8c3BhbiBkaXI9Imx0ciI+ Jmx0OzxhIGhyZWY9Im1haWx0bzpzZWJhc3RpYW5Ac2ViYmUuZXUiIHRhcmdldD0iX2JsYW5rIj5z ZWJhc3RpYW5Ac2ViYmUuZXU8L2E+Jmd0Ozwvc3Bhbj46PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJn bWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2Nj IHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPjxkaXYgbGFuZz0iU1YiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPjxkaXYgY2xhc3M9Im1fLTQ0ODY3MTI1NjI3ODg5NjYwNjdXb3JkU2VjdGlvbjEi PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuPkFsc28gY291bGQgYmUgZG9uZSBieSBoYXZpbmcg YSBpbnRlcmZhY2Ugd2hlcmUgeW91IHNjYW4geW91ciBwYXNzcG9ydCB3aXRoIGEgTkZDIGNvbXBh dGlibGUgcmVhZGVyIChib3RoIG1vYmlsZSBwaG9uZSBhbmQgZGVza3RvcCBORkMgcmVhZGVyIGNv dWxkIGJlIHN1cHBvcnRlZCkgYW5kIHRoZSBnb3Zlcm5tZW50LXNpZ25lZCBkYXRhIGlzIHVwbG9h ZGVkLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bhbj48 dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4+ U28gYXV0b21hdGVkIHZhbGlkYXRpb24gZm9yIHByaXZhdGUgSVYgY2VydHMgY291bGQgYmUgZG9u ZSB0b28gKElWID0gSW5kaXZpZHVhbCBjZXJ0cykuIFNvIGZyZWUgY29kZSBzaWduaW5nIGFuZCBJ ViB2YWxpZGF0ZWQgY2VydHMuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3Bhbj48YSBocmVmPSJodHRwczovL2NvbW11bml0eS5sZXRzZW5jcnlwdCI+aHR0 cHM6Ly9jb21tdW5pdHkubGV0c2VuY3J5cHQ8L2E+Ljx3YnI+b3JnL3QvaXYtY2VydGlmaWNhdGVz LWJvdGgtPHdicj5zZXJ2ZXItYW5kLWNvZGUtdmlhLWF1dG9tYXRlZC08d2JyPm5mYy1wYXNzcG9y dC1pZC12YWxpZGF0aW9uLzx3YnI+NDQ4Mzg8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+PHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPkZyw6VuOjwvYj4gQWNtZSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0 bzphY21lLWJvdW5jZXNAaWV0Zi5vcmciPmFjbWUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIDxiPkbD tnIgPC9iPlBoaWxpcHAgSnVuZ2hhbm7Dnzxicj48Yj5Ta2lja2F0OjwvYj4gZGVuIDEgZGVjZW1i ZXIgMjAxNyAxNDo1Nzxicj48Yj5UaWxsOjwvYj4gTWF0dGhpYXMgTWVya2VsICZsdDs8YSBocmVm PSJtYWlsdG86bW9yaXR6MzBAbW9yaXR6MzAuZGUiPm1vcml0ejMwQG1vcml0ejMwLmRlPC9hPiZn dDs8YnI+PGI+S29waWE6PC9iPiBJRVRGIEFDTUUgJmx0OzxhIGhyZWY9Im1haWx0bzphY21lQGll dGYub3JnIj5hY21lQGlldGYub3JnPC9hPiZndDs8YnI+PGI+w4RtbmU6PC9iPiBSZTogW0FjbWVd IElkZWEgYWJvdXQgYXV0b21hdGVkIE9WIHZhbGlkYXRpb248dT48L3U+PHU+PC91PjwvcD48ZGl2 PjxkaXYgY2xhc3M9Img1Ij48cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91 PjwvcD48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPmlmIHRoYXQncyB3aGF0IG90aGVyIENBcyBk byB0aGF0J3Mgbm90IGEgYmFkIElkZWEgYWx0aG91Z2ggdGhlcmUncyBvZiBjb3Vyc2UgdGhlIHF1 ZXN0aW9uIHdoZXRoZXIgdGhlcmUgYXJlIHNvbWUgb3RoZXIgbWFudWFsIGNoZWNrcyBuZWVkZWQu PHU+PC91Pjx1PjwvdT48L3A+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7 PHU+PC91PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJ1dCBjaGVhcCB0byBh bG1vc3QgZnJlZSBPVnMvY29kZSBzaWduaW5nIGNlcnRzIHdvdWxkIGJlIGdyZWF0IGFsdGhvdWdo IHRoYXQgc2FkbHkgZG9lc250IG1ha2UgaXQgZWFzaWVyIGZvciBub3JtYWwgcGVvcGxlIHdpdGhv dXQgYSBjb21wYW55IHRvIGdldCBJVnMgb3IgY29kZSBzaWduaW5nIGNlcnRzLCBidXQgdGhlIElk ZWEgaXMgY2VydGFpbmx5IG5vdCBiYWQuPHU+PC91Pjx1PjwvdT48L3A+PC9kaXY+PC9kaXY+PGRp dj48cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD48ZGl2PjxwIGNs YXNzPSJNc29Ob3JtYWwiPjIwMTctMTItMDEgMTQ6NTMgR01UKzAxOjAwIE1hdHRoaWFzIE1lcmtl bCAmbHQ7PGE+bW9yaXR6MzBAbW9yaXR6MzAuZGU8L2E+Jmd0Ozo8dT48L3U+PHU+PC91PjwvcD48 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI2NjY2NjYyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij48ZGl2PjxkaXY+ PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5JIGhhZCB0aGUgZm9sbG93aW5n IGlkZWEgYWJvdXQgYXV0b21hdGluZyB2ZXJpZmljYXRpb24gYW5kIGlzc3VhbmNlIG9mIE9WIFNT TCBjZXJ0aWZpY2F0ZXM6IENvdWxkbid0IGEgQ0EgaW4gdGhlb3J5IHVzZSB0aGUgRCZhbXA7QiBB UEkgdG8gY2hlY2sgdGhlIGNvbXBhbnkgbmFtZSwgYWRkcmVzcyBhbmQgcGhvbmUgbnVtYmVyIGFu ZCB0aGVuIHBsYWNlIGFuIGF1dG9tYXRpYyBjYWxsPyBUaGF0J3MgYmFzaWNhbGx5IHdoYXQgbW9z dCBDQXMgZG8gYW55d2F5cyBzbyBpcyB0aGVyZSBhbnkgcmVhc29uIHdoeSB0aGV5IGNvdWxkbid0 IGRvIGl0PyBUaGF0IHdvdWxkIGFsc28gYmUgYSB3YXkgZm9yIExldCdzIEVuY3J5cHQgdG8gaXNz dWUgT1YgY2VydGlmaWNhdGVzIGFuZCBjb2RlIHNpZ25pbmcgY2VydGlmaWNhdGVzLjx1PjwvdT48 dT48L3U+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjx1 PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj48 dT48L3U+Jm5ic3A7PHU+PC91PjwvcD48L2Rpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 d2JyPl9fX19fX19fX19fX19fX19fPGJyPkFjbWUgbWFpbGluZyBsaXN0PGJyPjxhPkFjbWVAaWV0 Zi5vcmc8L2E+PGJyPjxhPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vPHdicj5saXN0aW5m by9hY21lPC9hPjx1PjwvdT48dT48L3U+PC9wPjwvYmxvY2txdW90ZT48L2Rpdj48cCBjbGFzcz0i TXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rp dj48L2Rpdj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHdicj5fX19fX19fX19f X19fX19fXzxicj4KQWNtZSBtYWlsaW5nIGxpc3Q8YnI+CjxhIGhyZWY9Im1haWx0bzpBY21lQGll dGYub3JnIj5BY21lQGlldGYub3JnPC9hPjxicj4KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi8iPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vPC9hPjx3YnI+bGlzdGlu Zm8vYWNtZTxicj4KPGJyPjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+CjwvYm9keT48L2h0 bWw+ ----_com.samsung.android.email_341600897222580-- ------=_Part_4_1100691100.1512140468519 Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCAMIIF RTCCBC2gAwIBAgIIY1z1sUcn5kYwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAklUMQ8wDQYD VQQIDAZNaWxhbm8xDzANBgNVBAcMBk1pbGFubzEjMCEGA1UECgwaQWN0YWxpcyBTLnAuQS4vMDMz NTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIENBIEcxMB4X DTE3MTExMTAzMzM0OFoXDTE4MTExMTAzMzM0OFowHTEbMBkGA1UEAwwSc2ViYXN0aWFuQHNlYmJl LmV1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmT1KZ1G4QWcvDCHONMbBynyMsN4A F+8IXSCqu2rpPith70w/KqdILvVDP2denK2tIATLkUPQ7SG2lYzhm1874LDq4Rh2M/dB83sAblGW n1qIFSuYnMFe3jO5XCoN0je0iv/3ASGCQcymhPeeFefGsqpr5btDLKwdZcfZrjqBDLD5hjeqX+f1 Zo5xkPKK0kj9wlBgWzn72IZwZvs0l+bdjVS1bmZFe0+i9R/sgUlNs1/JlfVsXYgPD6ncq7bJCcYN +jFNqR/bQ2sV3rKZXcltiIYROSGnJQ2SOGv/lVQ0wD8OVYqyUuOqMvJBR4sqauclLVRfGKZ1tufR 9qVaQmPsYQIDAQABo4ICITCCAh0wSwYIKwYBBQUHAQEEPzA9MDsGCCsGAQUFBzAChi9odHRwOi8v Y2FjZXJ0LmFjdGFsaXMuaXQvY2VydHMvYWN0YWxpcy1hdXRjbGlnMTAdBgNVHQ4EFgQUzHTxBzTo 9ekiseKvYUaxJVzkzSgwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBR+YPz4bKc9Pdeuk6F5Ao+z dCk79TBHBgNVHSAEQDA+MDwGBiuBHwEYATAyMDAGCCsGAQUFBwIBFiRodHRwczovL3d3dy5hY3Rh bGlzLml0L2FyZWEtZG93bmxvYWQwgegGA1UdHwSB4DCB3TCBm6CBmKCBlYaBkmxkYXA6Ly9sZGFw MDUuYWN0YWxpcy5pdC9jbiUzZEFjdGFsaXMlMjBDbGllbnQlMjBBdXRoZW50aWNhdGlvbiUyMENB JTIwRzEsbyUzZEFjdGFsaXMlMjBTLnAuQS4vMDMzNTg1MjA5NjcsYyUzZElUP2NlcnRpZmljYXRl UmV2b2NhdGlvbkxpc3Q7YmluYXJ5MD2gO6A5hjdodHRwOi8vY3JsMDUuYWN0YWxpcy5pdC9SZXBv c2l0b3J5L0FVVEhDTC1HMS9nZXRMYXN0Q1JMMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0RBBYwFIESc2ViYXN0aWFuQHNlYmJlLmV1MA0GCSqGSIb3 DQEBCwUAA4IBAQCyqAPE4i4dsEsMY/Ukxs+ZILWn6t3LXZm8WBsFV4IAZxaS/GW1VhyxJpFbubdN dfaHxxd4ragdfRyjLw+67sz3Av8U0y/jpEjcKWnAzh5Jitd7obF3qzQUaU0r+JVJ4o3gVzEWTmOS ZLUEiFpMtk5rB0BiNaFh0y6RgK7dt7o7VCWle7+pQG2sMrD6cBl9DOLwY1Wqqjj7crzIm2ST7Cfu O/IUy9mFxm4mECcqpehqTA5NKtS3GXGHy1XpU1WhF4BVHakYt3oNZYw9pnzSLLPuEgf72zpbrgN2 j7QfYH0N0eZ4NBi/dBCJ+MXKobPo8OKmRb999p0pTj7cYacRyeI4MIIGRzCCBC+gAwIBAgIILNSK 07EeD4kwDQYJKoZIhvcNAQELBQAwazELMAkGA1UEBhMCSVQxDjAMBgNVBAcMBU1pbGFuMSMwIQYD VQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEnMCUGA1UEAwweQWN0YWxpcyBBdXRoZW50 aWNhdGlvbiBSb290IENBMB4XDTE1MDUxNDA3MTQxNVoXDTMwMDUxNDA3MTQxNVowgYIxCzAJBgNV BAYTAklUMQ8wDQYDVQQIDAZNaWxhbm8xDzANBgNVBAcMBk1pbGFubzEjMCEGA1UECgwaQWN0YWxp cyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIENBIEcxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwPzBiVbZiOL0BGW/zQk1 qygpMP4MyvcnqxwR7oY9XeT1bES2DFczlZfeiIqNLanbkyqTxydXZ+kxoS9071qWsZ6zS+pxSqXL s+RTvndEaWx5hdHZcKNWGzhy5FiO4GZvGlFInFEiaY+dOEpjjWvSeXpvcDpnYw6M9AXuHo4JhjC3 P/OK//5QFXnztTa4iU66RpLteOTgCtiRCwZNKx8EFeqqfTpYvfEb4H91E7n+Y61jm0d2E8fJ2wGT aSSwjc8nTI2ApXujoczukb2kHqwaGP3q5UuedWcnRZc65XUhK/Z6K32KvrQuNP32F/5MxkvEDnJp Unnt9iMExvEzn31zDQIDAQABo4IB1TCCAdEwQQYIKwYBBQUHAQEENTAzMDEGCCsGAQUFBzABhiVo dHRwOi8vb2NzcDA1LmFjdGFsaXMuaXQvVkEvQVVUSC1ST09UMB0GA1UdDgQWBBR+YPz4bKc9Pdeu k6F5Ao+zdCk79TAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFFLYiDrIn3hm7YnzezhwlMkC AjbQMEUGA1UdIAQ+MDwwOgYEVR0gADAyMDAGCCsGAQUFBwIBFiRodHRwczovL3d3dy5hY3RhbGlz Lml0L2FyZWEtZG93bmxvYWQwgeMGA1UdHwSB2zCB2DCBlqCBk6CBkIaBjWxkYXA6Ly9sZGFwMDUu YWN0YWxpcy5pdC9jbiUzZEFjdGFsaXMlMjBBdXRoZW50aWNhdGlvbiUyMFJvb3QlMjBDQSxvJTNk QWN0YWxpcyUyMFMucC5BLiUyZjAzMzU4NTIwOTY3LGMlM2RJVD9jZXJ0aWZpY2F0ZVJldm9jYXRp b25MaXN0O2JpbmFyeTA9oDugOYY3aHR0cDovL2NybDA1LmFjdGFsaXMuaXQvUmVwb3NpdG9yeS9B VVRILVJPT1QvZ2V0TGFzdENSTDAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQELBQADggIBAE2T ztUkvkEbShZYc19lifLZej5YjLzLxA/lWxZnssFLpDPySfzMmndz3F06S51ltwDe+blTwcpdzUl3 M2alKH3bOr855ku9Rr6uedya+HGQUT0OhqDo2K2CAE9nBcfANxifjfT8XzCoC3ctf9ux3og1WuE8 WTcLZKgCMuNRBmJte9C4Ug0w3iXqPzq8KuRRobNKqddPjk3EiK+QA+EFCCka1xOLh/7cPGTJMNta 1/0u5oLiXaOAHeALt/nqeZ2kZ+lizK8oTv4in5avIf3ela3oL6vrwpTca7TZxTX90e805dZQN4qR VPdPbrBlWtNozH7SdLeLrcoN8l2EXO6190GAJYdynTc2E6EyrLVGcDKUX91VmCSRrqEppZ7W05Tb WRLi6+wPjAzmTq2XSmKfajq7juTKgkkw7FFJByixa0NdSZosdQb3VkLqG8EOYOamZLqH+v7ua0+u lg7FOviFbeZ7YR9eRO81O8FC1uLgutlyGD2+GLjgQnsvneDsbNAWfkory+qqAxvVzX5PSaQp2pJ5 2AaIH1MN1i2/geRSP83TRMrFkwuIMzDhXxKFQvpspNc19vcTryzjtwP4xq0WNS4YWPS4U+9mW+U0 Cgnsgx9fMiJNbLflf5qSb53j3AGHnjK/qJzPa39wFTXLXB648F3w1Qf9R7eZeTRJfCQY/fJUAAAx ggLJMIICxQIBATCBjzCBgjELMAkGA1UEBhMCSVQxDzANBgNVBAgMBk1pbGFubzEPMA0GA1UEBwwG TWlsYW5vMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoGA1UEAwwjQWN0 YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzECCGNc9bFHJ+ZGMA0GCWCGSAFlAwQCAQUA oIIBCjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEyMDExNTAx MDhaMC8GCSqGSIb3DQEJBDEiBCBb7S1IfCZCAprqOL724GUVTJdvO8RgiiflD9bC03WVwTCBngYJ KoZIhvcNAQkPMYGQMIGNMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAPBgkqhkiG9n0HQgoCAgCAMA0GCyqDCIyaSz0BAQEE MA0GCyqDCIyaSz0BAQEDMA0GCyqDCIyaSz0BAQECMAoGCCqDGoyaRAEEMA0GCSqGSIb3DQEBAQUA BIIBABVhymNL5ZOmZiEl/q2ivF8sIkPmaIxaW5nIbb3hKTPi+KnnK14Bd/otlJam0tLwVPw1iszj wqMvKnGw2rPOaZwzqdHfKr+shwluzGKDuczV9WgvjxOw/CP86+2oSWEb5MoNuChNTJ9wAZxFKRax RQV+6HLpngUNmHB+UBoSye4FsXZ29O8t0cLhcFDP5wneMPkyHsHngORPngr2jSzksMbslFacqOxJ GR3ZMx0TVg0/9bA8JA+nnPA4B0WHE3Fn7kt/bRCEe3meh7Lm2yxtHIRUOBSw8DO1dpRsNQ9Q/KyZ WT4JgjwKKk2ScTMPNPpk0ZwBg0oj1tfMERTJ3k35DSoAAAAAAAA= ------=_Part_4_1100691100.1512140468519-- From nobody Fri Dec 1 07:10: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 ED3C31293FF for ; Fri, 1 Dec 2017 07:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 0uPyLxNRTCWp for ; Fri, 1 Dec 2017 07:10:09 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 24337120713 for ; Fri, 1 Dec 2017 07:10:09 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id t196so11565202iof.0 for ; Fri, 01 Dec 2017 07:10:09 -0800 (PST) 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=6gxnFSN2j7iVtxoO9o1bNTGdrXc11WkUM/0ELkaJpoA=; b=KGAz8l7aJ2Ox2Xlig145Q5SBW9kykVuePpvTeuDU9gs3zVyza8TpFhS128pjxctSvE TLHMPoUAGlO86lPuzN0+XdhxEg5jXuLzUGEqYveczkuXL25U8OV7+oFTYBz/lGzXrVJ6 QNPTD8SZQ7jKwpMkhs3sySOYc5rvORf+H7Dgw= 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=6gxnFSN2j7iVtxoO9o1bNTGdrXc11WkUM/0ELkaJpoA=; b=P4CVKBGUlB2Iik/tLEYDRp+UznD7vZStOhGG2ApVDalBLNiy2hCjv4v9zZIGqFS9DW HEXEtVpFANFd1Po1uYqP6vT6OlYKUYF5bw27m6L5PDHdJ+Eb/czaFmaWXPXDpX50RcKx DD/Mq5/68RxS/tIsncXbhdob12BOghrlVLYoK4Bm9c4yjNy5UZVB2GgXXNvggtUF4eKA UnPq4FMTGoeyDVeyrT7MhUEaMh95KWCQo2DDEZwji50SNQHsf4SZhwitfCOL+xUOOsPV mIa4umSofQ/4auIahqjhVGlByTOd2Ifgunlgcs25ftWCLXzuPl9Db16Jv/3MjKR0Nnyn 1oxg== X-Gm-Message-State: AJaThX6n96rkkSblUYn8e7Tqvdy5WLqJwlMwEMfvFhMBd3pdL8zQHMZj bPUw2PiOGoS5qAH6GcOn6IDjndDl6dHk3DheCLn693JrNLs= X-Google-Smtp-Source: AGs4zMbM2jxqwzVwI1+AMezx/93g/+/RffnWwlXmqaudtMKpxSZgJ8wlff6IrqQLFjZa3cY4YTnw6XEgZxZYL/Od/bE= X-Received: by 10.107.33.71 with SMTP id h68mr11660662ioh.167.1512141008338; Fri, 01 Dec 2017 07:10:08 -0800 (PST) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.17.28 with HTTP; Fri, 1 Dec 2017 07:10:07 -0800 (PST) In-Reply-To: References: <0F612577-86CE-4E86-B95C-01C0FF82BDA7@akamai.com> <6c002b3f-8018-45f8-64dd-1bbb2d2918d2@eff.org> <20171130150759.f92dc9a717e92296bf7356a1@andrewayer.name> From: Daniel McCarney Date: Fri, 1 Dec 2017 10:10:07 -0500 Message-ID: To: =?UTF-8?Q?Robert_K=C3=A4stel?= Cc: Andrew Ayer , Jacob Hoffman-Andrews , "Salz, Rich" , IETF ACME , Clint Wilson Content-Type: multipart/alternative; boundary="001a1140f488a71be6055f48c3ed" Archived-At: Subject: Re: [Acme] Removing OOB Challenge Type 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, 01 Dec 2017 15:10:20 -0000 --001a1140f488a71be6055f48c3ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Robert, > We're planning on using the OOB challenge type to signify pre-authorized > domains (in the existing CA system) as already validated challenges in th= e > ACME response, as described in section 7.4.1 Pre-authorization [0]. I don't think Section 7.4.1 indicates that you should use authorizations with an OOB challenge type for this purpose. The requirement is that the order object returned by new-order reflect authorizations obtained by the new-authz endpoint in its response. In this case you describe it sounds like the authorizations are from your existing CA system and are not from `new-authz` and the ACME pre-authorization process - I don't think this section applies. Further, if the authorizations were obtained that way then they weren't obtained by solving an OOB challenge returned by the CA per Section 8.6 and it seems confusing/misleading to return a valid authorization with an OOB challenge that wasn't used to obtain the authorization. Since 7.4.1 doesn't mention challenges at all wouldn't it be sufficient to have the order return valid authorizations covering the domains that were pre-authorized in the legacy system with no accompanying challenges present= ? This is planned for the first release of the ACME service. What date is planned for this release? If there won't be a client and server implementation available by the time we enter last call I still think it is most appropriate to defer the OOB challenge type as follow-up work. - Daniel / cpu On Fri, Dec 1, 2017 at 7:55 AM, Robert K=C3=A4stel wrote= : > We at Telia Company are working on an ACME server implementation that is > going to integrate with an existing CA system using external account > binding. > We're planning on using the OOB challenge type to signify pre-authorized > domains (in the existing CA system) as already validated challenges in th= e > ACME response, as described in section 7.4.1 Pre-authorization [0]. This = is > planned for the first release of the ACME service. > > Another use for it we're planning is to support validating EV and OV > certificates using an OOB href/URL. > > [0] https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme. > html#rfc.section.7.4.1 > > regards, > Robert K=C3=A4stel > > On Fri, Dec 1, 2017 at 12:07 AM, Andrew Ayer wrote= : > >> No objections here. >> >> Regards, >> Andrew >> >> On Thu, 30 Nov 2017 10:22:56 -0800 >> Jacob Hoffman-Andrews wrote: >> >> > I agree with this change. It's a good plan to not try and pre-specify >> > things like OOB that aren't on anyone's roadmap, because that leaves >> > the space open for a better specification once someone wants to >> > implement it. >> > >> > On 11/30/2017 09:39 AM, Clint Wilson wrote: >> > > >> > > I agree with the reasoning and decision to remove this. >> > > While I think it's possible for this challenge type to become useful >> > > in the future, I don't have any justification for keeping it in in >> > > the meantime. As Daniel notes, it's straightforward to add it back >> > > if needed. >> > > >> > > >> > > On Thu, Nov 30, 2017, 10:25 AM Daniel McCarney > > > > wrote: >> > > >> > > > Daniel, please do not merge this until we determine WG >> > > >consensus >> > > >> > > Of course :-) I don't have any merge privileges! >> > > >> > > On Thu, Nov 30, 2017 at 11:42 AM, Salz, Rich > > > > wrote: >> > > >> > > Does anyone disagree with Daniel=E2=80=99s reasoning? If so= , please >> > > speak up before next Friday. >> > > >> > > >> > > >> > > Daniel, please do not merge this until we determine WG >> > > consensus. >> > > >> > > >> > > _______________________________________________ >> > > 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 >> > >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> > > --001a1140f488a71be6055f48c3ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Robert,
=C2=A0
We're planning = on using the OOB challenge type to signify pre-authorized domains (in the e= xisting CA system) as already validated challenges in the ACME response, as= described in section 7.4.1 Pre-authorization [0].
=
I don't think Section 7.4.1 indicates that you should use authoriza= tions with an OOB challenge type for this purpose. The requirement is that = the order object returned by new-order reflect authorizations obtained by t= he new-authz endpoint in its response. In this case you describe it sounds = like the authorizations are from your existing CA system and are not from `= new-authz` and the ACME pre-authorization process - I don't think this = section applies. Further, if the authorizations were obtained that way then= they weren't obtained by solving an OOB challenge returned by the CA p= er Section 8.6 and it seems confusing/misleading to return a valid authoriz= ation with an OOB challenge that wasn't used to obtain the authorizatio= n.

Since 7.4.1 doesn't mention challenges at all wouldn't it= be sufficient to have the order return valid authorizations covering the d= omains that were pre-authorized in the legacy system with no accompanying c= hallenges present?

This is planned for the first release of the ACME service.

What date is planned for this release? If there won't be a client= and server implementation available by the time we enter last call I still= think it is most appropriate to defer the OOB challenge type as follow-up = work.

=C2=A0- Daniel / cpu


On Fri, Dec 1, 2017 at 7:5= 5 AM, Robert K=C3=A4stel <robert@kastel.se> wrote:
We at Telia Company are working on= an ACME server implementation that is going to integrate with an existing = CA system using external account binding.
We're planning on using t= he OOB challenge type to signify pre-authorized domains (in the existing CA= system) as already validated challenges in the ACME response, as described= in section 7.4.1 Pre-authorization [0]. This is planned for the first rele= ase of the ACME service.

Another use for it we'= ;re planning is to support validating EV and OV certificates using an OOB h= ref/URL.


regards,
Robert K=C3=A4= stel

On Fri, Dec 1, 2017 at 12:07 AM, And= rew Ayer <agwa@andrewayer.name> wrote:
No objections here.

Regards,
Andrew

On Thu, 30 Nov 2017 10:22:56 -0800
Jacob Hoffman-Andrews <jsha@eff.org> wrote:

> I agree with this change. It's a good plan to not try and pre-spec= ify
> things like OOB that aren't on anyone's roadmap, because that = leaves
> the space open for a better specification once someone wants to
> implement it.
>
> On 11/30/2017 09:39 AM, Clint Wilson wrote:
> >
> > I agree with the reasoning and decision to remove this.
> > While I think it's possible for this challenge type to become= useful
> > in the future, I don't have any justification for keeping it = in in
> > the meantime. As Daniel notes, it's straightforward to add it= back
> > if needed.
> >
> >
> > On Thu, Nov 30, 2017, 10:25 AM Daniel McCarney <cpu@letsencrypt.org
> > <mailto:cpu@letsencrypt.org>> wrote:
> >
> >=C2=A0 =C2=A0 =C2=A0>=C2=A0Daniel, please do not merge this unt= il we determine WG
> >=C2=A0 =C2=A0 =C2=A0>consensus
> >
> >=C2=A0 =C2=A0 =C2=A0Of course :-) I don't have any merge privi= leges!
> >
> >=C2=A0 =C2=A0 =C2=A0On Thu, Nov 30, 2017 at 11:42 AM, Salz, Rich &= lt;rsalz@akamai.com
> >=C2=A0 =C2=A0 =C2=A0<mailto:rsalz@akamai.com>> wrote:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Does anyone disagree with Daniel= =E2=80=99s reasoning?=C2=A0 If so, please
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0speak up before next Friday.
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Daniel, please do not merge this= until we determine WG
> > consensus.
> >
> >
> >=C2=A0 =C2=A0 =C2=A0_________________________________________= ______
> >=C2=A0 =C2=A0 =C2=A0Acme mailing list
> >=C2=A0 =C2=A0 =C2=A0Acme@ietf.org <mailto:Acme@ietf.org>
> >=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/m= ailman/listinfo/acme
> >
> >
> >
> > _______________________________________________
> > Acme mailing list
> > Acme@ietf.org<= /a>
> > https://www.ietf.org/mailman/listinfo/acme<= /a>
>

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


--001a1140f488a71be6055f48c3ed-- From nobody Fri Dec 1 07:36:45 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0766129405 for ; Fri, 1 Dec 2017 07:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 FzyQBi66wvpZ for ; Fri, 1 Dec 2017 07:36:31 -0800 (PST) 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 03021129404 for ; Fri, 1 Dec 2017 07:36:28 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vB1FWJYJ022847; Fri, 1 Dec 2017 15:36:24 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=zMSR7WbsgEnkMUHWSsjdKvE7QnJyYvTRsQ/7fSmPsMg=; b=WYGNEvVAb+q/RNGJxi5hdyYV2UEizksaVLtN5CKi0PMh7dH0IO5X80SzrpfAGjbPeP5z Gej5lEA09QWZzGwkKMiIBCcULcH44Lv+qO7s6ITUWCyyEQIL+PqkXhk9m74SkSb1pZ1g OX5HMSyl6zqyqLuD58jJGCltL7VHngX6C3CJRuhNc/jMAxLafkEJfcQYxFAtQZVN6Uop C2jJOb+BhLH15ycHSUDi4HIg+qo/+hxc9MK7WyimQTf+ox3ufH9Z54tVFPk9P7oDmp+f RDvJ23xl5f6x3XK1MVXwl6YvOK+AxjboECXBtNKI/jBY9dS2/cmljr6C9S+bF3UyQVTT IQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050095.ppops.net-00190b01. with ESMTP id 2ehpp80hfg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 01 Dec 2017 15:36:24 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vB1FZfNM020514; Fri, 1 Dec 2017 10:36:23 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2ef4qyj5g1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 01 Dec 2017 10:36:22 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 1 Dec 2017 10:36:22 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Fri, 1 Dec 2017 10:36:22 -0500 From: "Salz, Rich" To: "cpu@letsencrypt.org" , =?utf-8?B?Um9iZXJ0IEvDpHN0ZWw=?= CC: Andrew Ayer , Jacob Hoffman-Andrews , IETF ACME , Clint Wilson Thread-Topic: [Acme] Removing OOB Challenge Type Thread-Index: AQHTafS8lPPPxlZRcEOAfxnjrU0qI6MtdD0AgAAL9ICAAAQTAIAADCAAgABPpYCAAOdHAIAAJYqAgAAHSIA= Date: Fri, 1 Dec 2017 15:36:22 +0000 Message-ID: <7CD7A53F-37AC-45DB-AFAE-01AB96775ADD@akamai.com> References: <0F612577-86CE-4E86-B95C-01C0FF82BDA7@akamai.com> <6c002b3f-8018-45f8-64dd-1bbb2d2918d2@eff.org> <20171130150759.f92dc9a717e92296bf7356a1@andrewayer.name> In-Reply-To: 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.32.134] Content-Type: multipart/alternative; boundary="_000_7CD7A53F37AC45DBAFAE01AB96775ADDakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-01_03:, , 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-1709140000 definitions=main-1712010179 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-01_03:, , 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-1709140000 definitions=main-1712010178 Archived-At: Subject: Re: [Acme] Removing OOB Challenge Type 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, 01 Dec 2017 15:36:42 -0000 --_000_7CD7A53F37AC45DBAFAE01AB96775ADDakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgV2hhdCBkYXRlIGlzIHBsYW5uZWQgZm9yIHRoaXMgcmVsZWFzZT8gSWYgdGhlcmUgd29u J3QgYmUgYSBjbGllbnQgYW5kIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBhdmFpbGFibGUgYnkgdGhl IHRpbWUgd2UgZW50ZXIgbGFzdCBjYWxsIEkgc3RpbGwgdGhpbmsgaXQgaXMgbW9zdCBhcHByb3By aWF0ZSB0byBkZWZlciB0aGUgT09CIGNoYWxsZW5nZSB0eXBlIGFzIGZvbGxvdy11cCB3b3JrLg0K DQpUaGF04oCZcyBub3QgcmlnaHQuICBEZXBsb3ltZW50cyByYXJlbHkgb2NjdXIgcmlnaHQgYXMg dGhlIGRyYWZ0IGlzIGZpbmlzaGVkLg0KDQpTbyB0aGUgcXVlc3Rpb24gd2FzIGFza2VkLCBpcyBh bnlvbmUgcGxhbm5pbmcgb24gdXNpbmcgdGhpcz8gIEFuZCB3ZSBnb3QgYSBkZWZpbml0aXZlIHll cyBhbnN3ZXIuICBJIHRoaW5rIHRoZSBxdWVzdGlvbiBub3cgYmVjb21lcywgYXJlIHRoZSBhbHRl cm5hdGl2ZXMgYWNjZXB0YWJsZT8NCg0KV2UgY2FuIG9mIGNvdXJzZSBzdGlsbCBkZWNpZGUgdGhh dCBPT0Igc2hvdWxkIGJlIHJlbW92ZWQsIGJ1dCBsZXTigJlzIHRhbGsgYWJvdXQgb3B0aW9ucyBy aWdodCBub3cuDQo= --_000_7CD7A53F37AC45DBAFAE01AB96775ADDakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <09443C2F56498B41B96E48F03BE4A0B7@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwg bGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXBy aW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2lu LWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1l OiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo2 NTgzOTA4MjQ7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz OjIwNDUwMjU1NjIgNjc2OTg2OTkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBsMDpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyIsc2VyaWY7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9 IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlz YyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPldoYXQgZGF0ZSBpcyBwbGFubmVkIGZvciB0aGlzIHJl bGVhc2U/IElmIHRoZXJlIHdvbid0IGJlIGEgY2xpZW50IGFuZCBzZXJ2ZXIgaW1wbGVtZW50YXRp b24gYXZhaWxhYmxlIGJ5IHRoZSB0aW1lIHdlIGVudGVyIGxhc3QgY2FsbCBJIHN0aWxsIHRoaW5r IGl0IGlzIG1vc3QgYXBwcm9wcmlhdGUgdG8gZGVmZXIgdGhlDQogT09CIGNoYWxsZW5nZSB0eXBl IGFzIGZvbGxvdy11cCB3b3JrLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXTigJlzIG5vdCByaWdodC4mbmJzcDsgRGVwbG95 bWVudHMgcmFyZWx5IG9jY3VyIHJpZ2h0IGFzIHRoZSBkcmFmdCBpcyBmaW5pc2hlZC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+U28gdGhlIHF1ZXN0aW9uIHdhcyBhc2tlZCwgaXMgYW55b25lIHBs YW5uaW5nIG9uIHVzaW5nIHRoaXM/Jm5ic3A7IEFuZCB3ZSBnb3QgYSBkZWZpbml0aXZlIHllcyBh bnN3ZXIuJm5ic3A7IEkgdGhpbmsgdGhlIHF1ZXN0aW9uIG5vdyBiZWNvbWVzLCBhcmUgdGhlIGFs dGVybmF0aXZlcyBhY2NlcHRhYmxlPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBjYW4gb2Yg Y291cnNlIHN0aWxsIGRlY2lkZSB0aGF0IE9PQiBzaG91bGQgYmUgcmVtb3ZlZCwgYnV0IGxldOKA mXMgdGFsayBhYm91dCBvcHRpb25zIHJpZ2h0IG5vdy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7CD7A53F37AC45DBAFAE01AB96775ADDakamaicom_-- From nobody Fri Dec 1 07:36:51 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C0A129404 for ; Fri, 1 Dec 2017 07:36:42 -0800 (PST) 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=kastel-se.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 WztsrGUPPSAu for ; Fri, 1 Dec 2017 07:36:28 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d: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 908F81293EC for ; Fri, 1 Dec 2017 07:36:28 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id j207so13583506qke.10 for ; Fri, 01 Dec 2017 07:36:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kastel-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SNLVO8Hay2bXDXjuX4eb1grqnGLPfGre5jE77D84y88=; b=NvrhM/pEwLiQHlOYXidVH+eiPFhh4xfWSFUjBNjHwZrGDgNrLS6DqBra1J/JKXehry CLAD41xSmjbo9FZijLn7dYmW058QFIsoLUk9Evwq11Ir8f0cezxf+kW6/Sb65v4FYWGl 0T2lg5cefyUGE8mxM6Mfq0Vaj8ySvxTUkWaUBO2PO5PrPtiF34G0YdognuBycapbIbg/ cDjX9VGwnGYYD9kYvrCNXxZWGW3vrrlJA3RTtCim+ic5/Ko6zW4GgizpkK+HuX/5+PYL Wavh8ucAUsSO+nyxFInG2HuFCyJK8saNXrwMBVpcImB5L5FMK0fjJHgFdvmx+qMd0YlY d8uQ== 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=SNLVO8Hay2bXDXjuX4eb1grqnGLPfGre5jE77D84y88=; b=fdJlslj3UEKuTuxs/wYIRzM3+N2hph1MO1BIHArCJmli6b3XtnQOIp+SgGCjKBOBm1 1dXWd6azsA2etAdIGFlb7v1a22PQjerqGDdQWyjTKxcNIVfKB7CdjrKrQkPOqqxR7QTY 5SOSylfWVCSairSrelm2tLH4ZiMITQfpUdcC9jHCPnYlqgdpp+QcYuoR67XWk24q+bCO RhCf7sLem1iW/pkuZ9SCNc5trB33Bg/Qd7lXcNaaGr+iLJWVWmyWnYim4BgcaiSak9bk GeWupJuDrXY/6HwTP8TVgedQtnDDC7dUQWwpyH0QmzrQppOcs1JVIdI8QdnqPmjF4OFt HbqA== X-Gm-Message-State: AKGB3mKP56jLOTzsRl7kIZiHl5uB75G6atUsNXrDBWs82WVuRLK0fGyp cwrR3siPDGW7LOWeIyNor+AB+S9sSgHfdg2qoDZ1rQ== X-Google-Smtp-Source: AGs4zMYGXkqEPvwolzr8V4WAB/WlUAH+EXCjS6iU81+svUzA3DtW7aH5yFBXwtvmWjLB+GJ8e70pvc6bA+I1I+ZXj00= X-Received: by 10.55.158.132 with SMTP id h126mr8884422qke.245.1512142587571; Fri, 01 Dec 2017 07:36:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.209.29 with HTTP; Fri, 1 Dec 2017 07:36:27 -0800 (PST) In-Reply-To: References: <0F612577-86CE-4E86-B95C-01C0FF82BDA7@akamai.com> <6c002b3f-8018-45f8-64dd-1bbb2d2918d2@eff.org> <20171130150759.f92dc9a717e92296bf7356a1@andrewayer.name> From: =?UTF-8?Q?Robert_K=C3=A4stel?= Date: Fri, 1 Dec 2017 16:36:27 +0100 Message-ID: To: cpu@letsencrypt.org Cc: Andrew Ayer , Jacob Hoffman-Andrews , "Salz, Rich" , IETF ACME , Clint Wilson Content-Type: multipart/alternative; boundary="94eb2c074f4ec8463f055f492195" Archived-At: Subject: Re: [Acme] Removing OOB Challenge Type 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, 01 Dec 2017 15:36:42 -0000 --94eb2c074f4ec8463f055f492195 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Daniel, You're right. I've misunderstood that. I don't have to use any challenges at all. I just set the authorization to valid if the domain is already pre-authorized (proprietary CA system-wise). We're targeting 2018 Q1 for the ACME service, but we're aware that we're dependent on the client support for v2-spec/external account binding. When do you think last call will take place? regards, Robert K=C3=A4stel On Fri, Dec 1, 2017 at 4:10 PM, Daniel McCarney wrote= : > Hi Robert, > > >> We're planning on using the OOB challenge type to signify pre-authorized >> domains (in the existing CA system) as already validated challenges in t= he >> ACME response, as described in section 7.4.1 Pre-authorization [0]. > > > I don't think Section 7.4.1 indicates that you should use authorizations > with an OOB challenge type for this purpose. The requirement is that the > order object returned by new-order reflect authorizations obtained by the > new-authz endpoint in its response. In this case you describe it sounds > like the authorizations are from your existing CA system and are not from > `new-authz` and the ACME pre-authorization process - I don't think this > section applies. Further, if the authorizations were obtained that way th= en > they weren't obtained by solving an OOB challenge returned by the CA per > Section 8.6 and it seems confusing/misleading to return a valid > authorization with an OOB challenge that wasn't used to obtain the > authorization. > > Since 7.4.1 doesn't mention challenges at all wouldn't it be sufficient t= o > have the order return valid authorizations covering the domains that were > pre-authorized in the legacy system with no accompanying challenges prese= nt? > > This is planned for the first release of the ACME service. > > > What date is planned for this release? If there won't be a client and > server implementation available by the time we enter last call I still > think it is most appropriate to defer the OOB challenge type as follow-up > work. > > - Daniel / cpu > > > On Fri, Dec 1, 2017 at 7:55 AM, Robert K=C3=A4stel wro= te: > >> We at Telia Company are working on an ACME server implementation that is >> going to integrate with an existing CA system using external account >> binding. >> We're planning on using the OOB challenge type to signify pre-authorized >> domains (in the existing CA system) as already validated challenges in t= he >> ACME response, as described in section 7.4.1 Pre-authorization [0]. This= is >> planned for the first release of the ACME service. >> >> Another use for it we're planning is to support validating EV and OV >> certificates using an OOB href/URL. >> >> [0] https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.htm >> l#rfc.section.7.4.1 >> >> regards, >> Robert K=C3=A4stel >> >> On Fri, Dec 1, 2017 at 12:07 AM, Andrew Ayer >> wrote: >> >>> No objections here. >>> >>> Regards, >>> Andrew >>> >>> On Thu, 30 Nov 2017 10:22:56 -0800 >>> Jacob Hoffman-Andrews wrote: >>> >>> > I agree with this change. It's a good plan to not try and pre-specify >>> > things like OOB that aren't on anyone's roadmap, because that leaves >>> > the space open for a better specification once someone wants to >>> > implement it. >>> > >>> > On 11/30/2017 09:39 AM, Clint Wilson wrote: >>> > > >>> > > I agree with the reasoning and decision to remove this. >>> > > While I think it's possible for this challenge type to become usefu= l >>> > > in the future, I don't have any justification for keeping it in in >>> > > the meantime. As Daniel notes, it's straightforward to add it back >>> > > if needed. >>> > > >>> > > >>> > > On Thu, Nov 30, 2017, 10:25 AM Daniel McCarney >> > > > wrote: >>> > > >>> > > > Daniel, please do not merge this until we determine WG >>> > > >consensus >>> > > >>> > > Of course :-) I don't have any merge privileges! >>> > > >>> > > On Thu, Nov 30, 2017 at 11:42 AM, Salz, Rich >> > > > wrote: >>> > > >>> > > Does anyone disagree with Daniel=E2=80=99s reasoning? If s= o, please >>> > > speak up before next Friday. >>> > > >>> > > >>> > > >>> > > Daniel, please do not merge this until we determine WG >>> > > consensus. >>> > > >>> > > >>> > > _______________________________________________ >>> > > 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 >>> > >>> >>> _______________________________________________ >>> Acme mailing list >>> Acme@ietf.org >>> https://www.ietf.org/mailman/listinfo/acme >>> >> >> > --94eb2c074f4ec8463f055f492195 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Daniel,

You're right. I= 9;ve misunderstood that. I don't have to use any challenges at all. I j= ust set the authorization to valid if the domain is already pre-authorized = (proprietary CA system-wise).

We're targeting 2018 Q= 1 for the ACME service, but we're aware that we're dependent on the= client support for v2-spec/external account binding.

<= div>When do you think last call will take place?

r= egards,
Robert K=C3=A4stel
=
On Fri, Dec 1, 2017 at 4:10 PM, Daniel McCar= ney <cpu@letsencrypt.org> wrote:
Hi Robert,
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">We're planning on using the OOB challenge type to signify pre-au= thorized domains (in the existing CA system) as already validated challenge= s in the ACME response, as described in section 7.4.1 Pre-authorization [0]= .

I don't think Section 7.4.1 indica= tes that you should use authorizations with an OOB challenge type for this = purpose. The requirement is that the order object returned by new-order ref= lect authorizations obtained by the new-authz endpoint in its response. In = this case you describe it sounds like the authorizations are from your exis= ting CA system and are not from `new-authz` and the ACME pre-authorization = process - I don't think this section applies. Further, if the authoriza= tions were obtained that way then they weren't obtained by solving an O= OB challenge returned by the CA per Section 8.6 and it seems confusing/misl= eading to return a valid authorization with an OOB challenge that wasn'= t used to obtain the authorization.

Since 7.4.1 doesn't mention = challenges at all wouldn't it be sufficient to have the order return va= lid authorizations covering the domains that were pre-authorized in the leg= acy system with no accompanying challenges present?
This is planned for the = first release of the ACME service.

What date is= planned for this release? If there won't be a client and server implem= entation available by the time we enter last call I still think it is most = appropriate to defer the OOB challenge type as follow-up work.

=C2= =A0- Daniel / cpu


On= Fri, Dec 1, 2017 at 7:55 AM, Robert K=C3=A4stel <robert@kastel.se><= /span> wrote:
We at Teli= a Company are working on an ACME server implementation that is going to int= egrate with an existing CA system using external account binding.
We= 9;re planning on using the OOB challenge type to signify pre-authorized dom= ains (in the existing CA system) as already validated challenges in the ACM= E response, as described in section 7.4.1 Pre-authorization [0]. This is pl= anned for the first release of the ACME service.

A= nother use for it we're planning is to support validating EV and OV cer= tificates using an OOB href/URL.


regards,<= /div>
Robert K=C3=A4stel
<= br>
On Fri, Dec 1, 2017 at 12:07 AM, Andrew Ayer = <agwa@andrewayer.name> wrote:
No objections here.

Regards,
Andrew

On Thu, 30 Nov 2017 10:22:56 -0800
Jacob Hoffman-Andrews <jsha@eff.org> wrote:

> I agree with this change. It's a good plan to not try and pre-spec= ify
> things like OOB that aren't on anyone's roadmap, because that = leaves
> the space open for a better specification once someone wants to
> implement it.
>
> On 11/30/2017 09:39 AM, Clint Wilson wrote:
> >
> > I agree with the reasoning and decision to remove this.
> > While I think it's possible for this challenge type to become= useful
> > in the future, I don't have any justification for keeping it = in in
> > the meantime. As Daniel notes, it's straightforward to add it= back
> > if needed.
> >
> >
> > On Thu, Nov 30, 2017, 10:25 AM Daniel McCarney <cpu@letsencrypt.org
> > <mailto:cpu@letsencrypt.org>> wrote:
> >
> >=C2=A0 =C2=A0 =C2=A0>=C2=A0Daniel, please do not merge this unt= il we determine WG
> >=C2=A0 =C2=A0 =C2=A0>consensus
> >
> >=C2=A0 =C2=A0 =C2=A0Of course :-) I don't have any merge privi= leges!
> >
> >=C2=A0 =C2=A0 =C2=A0On Thu, Nov 30, 2017 at 11:42 AM, Salz, Rich &= lt;rsalz@akamai.com
> >=C2=A0 =C2=A0 =C2=A0<mailto:rsalz@akamai.com>> wrote:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Does anyone disagree with Daniel= =E2=80=99s reasoning?=C2=A0 If so, please
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0speak up before next Friday.
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Daniel, please do not merge this= until we determine WG
> > consensus.
> >
> >
> >=C2=A0 =C2=A0 =C2=A0_________________________________________= ______
> >=C2=A0 =C2=A0 =C2=A0Acme mailing list
> >=C2=A0 =C2=A0 =C2=A0Acme@ietf.org <mailto:Acme@ietf.org>
> >=C2=A0 =C2=A0 = =C2=A0https://www.ietf.org/mailman/listinfo/acme<= br> > >
> >
> >
> > _______________________________________________
> > Acme mailing list
> > Acme@ietf.org<= /a>
> > https://www.ietf.org/mailman/listinfo/acme<= /a>
>

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



--94eb2c074f4ec8463f055f492195-- From nobody Fri Dec 1 07:49: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 D1B8F127286 for ; Fri, 1 Dec 2017 07:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 pC_TFGvdwz0j for ; Fri, 1 Dec 2017 07:49:30 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 3E6E8124B09 for ; Fri, 1 Dec 2017 07:49:30 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id 81so11697830iof.3 for ; Fri, 01 Dec 2017 07:49:30 -0800 (PST) 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=30cS8SxtqaSOG6WpFNe3CjNtED98sfmScEKtqV+LeYI=; b=MEYIIxYqqBTB5/LKaqXm2CIYzEIqlr0kflHBYbTU5LVCLEZ859+xRXw6W6p+6GT1OI RSyrTksMfcDdGp3jrZ0kLTPPfjvGR1c1XzVKA47sdw8eg/PjQlFaKXnM6prtBB+zQHx1 4xFsj4ytVPib0l2HXoJ1/t/fEDSBUBrJpWftQ= 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=30cS8SxtqaSOG6WpFNe3CjNtED98sfmScEKtqV+LeYI=; b=ZyF6Dcsr93kBsUV4UeGyb+UqoJ1w5X5c0lZ/ARV+vp1EvODXqxILMTlZG1rT6HhcJO ssA1LXx+Y7GIvzl/C5eublnqTHw9m1sK9jf1+zmVdTEeje0qcCDMa9nM1jdRXIi1pVIz FMhFevuX3EwLRRFB+uDZjPcIaRX08uRp+mw5QFyGrCsRKCStmaLlBmzpANEOrO6FRAzK m3uArEC2e62fURoflNSD/CH7xJCGMg9E47GyyBWc6So4W2GZn05TIlHG5xqsQyoYrApy H4YIovtHEcSpfqVbSHthpLiKaFSMcCumnOAbHDP77lU6ZtjB2IkNXgDuKMTRDST13KsL rbKA== X-Gm-Message-State: AJaThX5+dIvI33y9zIjFzV1O3Bucqi0vMn81KtoQHBFZ65v1kfZzUz1O /dwth+3j9XxNLZ62D1eMreZjVtw7SWEGX1GgbB/IixNSHLQ= X-Google-Smtp-Source: AGs4zMbWIY1SGdZfqtWrp0JGGtHM2xPLfB0Van8I/IkeMuxDRZAiWdNT33cNt8P24EWIC4VvQMNtKBDZFTzdRXJqPSY= X-Received: by 10.107.27.8 with SMTP id b8mr13842820iob.31.1512143369531; Fri, 01 Dec 2017 07:49:29 -0800 (PST) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.17.28 with HTTP; Fri, 1 Dec 2017 07:49:28 -0800 (PST) In-Reply-To: <7CD7A53F-37AC-45DB-AFAE-01AB96775ADD@akamai.com> References: <0F612577-86CE-4E86-B95C-01C0FF82BDA7@akamai.com> <6c002b3f-8018-45f8-64dd-1bbb2d2918d2@eff.org> <20171130150759.f92dc9a717e92296bf7356a1@andrewayer.name> <7CD7A53F-37AC-45DB-AFAE-01AB96775ADD@akamai.com> From: Daniel McCarney Date: Fri, 1 Dec 2017 10:49:28 -0500 Message-ID: To: "Salz, Rich" Cc: =?UTF-8?Q?Robert_K=C3=A4stel?= , Andrew Ayer , Jacob Hoffman-Andrews , IETF ACME , Clint Wilson Content-Type: multipart/alternative; boundary="001a113feec6640c90055f4950ea" Archived-At: Subject: Re: [Acme] Removing OOB Challenge Type 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, 01 Dec 2017 15:49:33 -0000 --001a113feec6640c90055f4950ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > That=E2=80=99s not right. Deployments rarely occur right as the draft is= finished. What isn't right? I expressed an opinion that entering last call for specification text that hasn't been implemented by anyone seems like a recipe for errata. My comment was also specific to implementations not deployments. For added context, the OOB challenge type has been in the spec largely unchanged for two years[0]. Plans to use something are nice but I thought our goal was rough consensus and running code. [0] - https://github.com/ietf-wg-acme/acme/commit/3e64248088da56f046c7448a84a0263= d1328f470 On Fri, Dec 1, 2017 at 10:36 AM, Salz, Rich wrote: > > - What date is planned for this release? If there won't be a client > and server implementation available by the time we enter last call I s= till > think it is most appropriate to defer the OOB challenge type as follow= -up > work. > > > That=E2=80=99s not right. Deployments rarely occur right as the draft is= finished. > > > > So the question was asked, is anyone planning on using this? And we got = a > definitive yes answer. I think the question now becomes, are the > alternatives acceptable? > > > > We can of course still decide that OOB should be removed, but let=E2=80= =99s talk > about options right now. > --001a113feec6640c90055f4950ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That=E2=80=99s not right.=C2=A0 Deployments rarely= occur right as the draft is finished.

What isn= 't right? I expressed an opinion that entering last call for specificat= ion text that hasn't been implemented by anyone seems like a recipe for= errata. My comment was also specific to implementations not deployments.
For added context, the OOB challenge type has been in the spec largel= y unchanged for two years[0].=C2=A0 Plans to use something are nice but I t= hought our goal was rough consensus and running code.

[0] -=C2=A0https://github.com/ietf-wg-acme/acme/commit/3e64248088da= 56f046c7448a84a0263d1328f470


On Fri, Dec 1, 2017 at 10:36 AM, Salz, R= ich <rsalz@akamai.com> wrote:
  • What date is planned for this release? If there won't be a client a= nd server implementation available by the time we enter last call I still t= hink it is most appropriate to defer the OOB challenge type as follow-up work.

That=E2=80=99s not right.=C2=A0 Deployments rarely o= ccur right as the draft is finished.

=C2=A0

So the question was asked, is anyone planning on usi= ng this?=C2=A0 And we got a definitive yes answer.=C2=A0 I think the questi= on now becomes, are the alternatives acceptable?

=C2=A0

We can of course still decide that OOB should be rem= oved, but let=E2=80=99s talk about options right now.


--001a113feec6640c90055f4950ea-- From nobody Fri Dec 1 09:33: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 EDDF0124B18 for ; Fri, 1 Dec 2017 09:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 WuNNdugBSs6P for ; Fri, 1 Dec 2017 09:33:07 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 1FB7A1200FC for ; Fri, 1 Dec 2017 09:33:07 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id u42so12012619ioi.9 for ; Fri, 01 Dec 2017 09:33:07 -0800 (PST) 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=FFpMGFXzM59RYnK0oFlHY8TIxSBJ+Ceq9jRYUzAh8kU=; b=bXUve7ld8Qu3xRTo6m4uL4BPO5zoBgAKfKHqrKug/DtrORUzS9KOwvsctUHsnVe+jf QsVvz6+D0/mi4gQVtOirFNO1g8ygtFqgNQe3xzOSEgft+sDbtqQnJYlg7EnnfmtJ/sND sezgpctUdClOHzCXc1VtC6OL+BTey37lTbKX8= 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=FFpMGFXzM59RYnK0oFlHY8TIxSBJ+Ceq9jRYUzAh8kU=; b=q8f9y1Ak2ey/CTzwV3NwlWT37jarQT908PdJU1l7Az7AjGMW8MGstR5edkF22N/Pe5 0nHsqjAK2I1MXMSQaS9YoOHXhWaV6voZKYCSDHEEx8egNgmra2iJJjT+wqfiniIg83Fb 0351APeRGamS68sdnyIBSH1b9hb5ndC5MJlc+jCpHUN1he/DmxHQhtyEmVFhmvufy8bY 3Rz8StKbRMy/g4fdsikyGaif+nXNJTL+4L+dndh4JRBwoKKSqTJEE36OKahT44WjWg6I 7KnaQNtSmXI1tK8eIKWe+NZeqV/LsDOsSfODGLe9I3s0LoVmOfDSUNuYRgSkVj15cnkA x5vg== X-Gm-Message-State: AJaThX60j5jlNu1Ar5+y75ICnClh2QTBLpcAua3agYiHrO7wLkVloSh7 ZEe+AVIMluWKXMtonllaS5I5p6l6QwycxatpYt/q2g== X-Google-Smtp-Source: AGs4zMbO0gXaZvjIXg3Nyh3bQyylJL1D7h4+Sa3Zx4fSEvxyWTVPO3yP77biZK8JVhUKBaqU3shU7q2+ssEdXlZfamI= X-Received: by 10.107.192.7 with SMTP id q7mr3036089iof.89.1512149586470; Fri, 01 Dec 2017 09:33:06 -0800 (PST) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.17.28 with HTTP; Fri, 1 Dec 2017 09:33:05 -0800 (PST) In-Reply-To: References: <0F612577-86CE-4E86-B95C-01C0FF82BDA7@akamai.com> <6c002b3f-8018-45f8-64dd-1bbb2d2918d2@eff.org> <20171130150759.f92dc9a717e92296bf7356a1@andrewayer.name> <7CD7A53F-37AC-45DB-AFAE-01AB96775ADD@akamai.com> From: Daniel McCarney Date: Fri, 1 Dec 2017 12:33:05 -0500 Message-ID: To: "Salz, Rich" Cc: =?UTF-8?Q?Robert_K=C3=A4stel?= , Andrew Ayer , Jacob Hoffman-Andrews , IETF ACME , Clint Wilson Content-Type: multipart/alternative; boundary="001a114f049cf2fa0e055f4ac245" Archived-At: Subject: Re: [Acme] Removing OOB Challenge Type 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, 01 Dec 2017 17:33:10 -0000 --001a114f049cf2fa0e055f4ac245 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > >> That=E2=80=99s not right. Deployments rarely occur right as the draft= is > finished. > What isn't right? I expressed an opinion that entering last call for > specification text that hasn't been implemented by anyone seems like a > recipe for errata. My comment was also specific to implementations not > deployments. Apologies Rich - I reread my original message and I did say "What date is planned for this release" when I should have said "What date do you expect to have an implementation". I understand the source of confusion now & agree with your correction. On Fri, Dec 1, 2017 at 10:49 AM, Daniel McCarney wrote: > That=E2=80=99s not right. Deployments rarely occur right as the draft is= finished. > > > What isn't right? I expressed an opinion that entering last call for > specification text that hasn't been implemented by anyone seems like a > recipe for errata. My comment was also specific to implementations not > deployments. > > For added context, the OOB challenge type has been in the spec largely > unchanged for two years[0]. Plans to use something are nice but I though= t > our goal was rough consensus and running code. > > [0] - https://github.com/ietf-wg-acme/acme/commit/ > 3e64248088da56f046c7448a84a0263d1328f470 > > > On Fri, Dec 1, 2017 at 10:36 AM, Salz, Rich wrote: > >> >> - What date is planned for this release? If there won't be a client >> and server implementation available by the time we enter last call I = still >> think it is most appropriate to defer the OOB challenge type as follo= w-up >> work. >> >> >> That=E2=80=99s not right. Deployments rarely occur right as the draft i= s >> finished. >> >> >> >> So the question was asked, is anyone planning on using this? And we got >> a definitive yes answer. I think the question now becomes, are the >> alternatives acceptable? >> >> >> >> We can of course still decide that OOB should be removed, but let=E2=80= =99s talk >> about options right now. >> > > --001a114f049cf2fa0e055f4ac245 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>>= That=E2=80=99s not right.=C2=A0 Deployments rarely occur right as the draf= t is finished.

> What isn't right? I expressed an opinion that ent= ering last call for specification text that hasn't been implemented by = anyone seems like a recipe for errata. My comment was also specific to impl= ementations not deployments.

Apologies Rich - I reread= my original message and I did say "W= hat date is planned for this release" when I should have said "Wh= at date do you expect to have an implementation".

I understand = the source of confusion now & agree with your correction.
<= div>

On Fri, Dec 1, 2017 at 10:49 AM, Daniel McCarney <<= a href=3D"mailto:cpu@letsencrypt.org" target=3D"_blank">cpu@letsencrypt.org= > wrote:
<= span class=3D"">
That=E2=80=99s not right.=C2=A0 Deployments rarely = occur right as the draft is finished.

Wh= at isn't right? I expressed an opinion that entering last call for spec= ification text that hasn't been implemented by anyone seems like a reci= pe for errata. My comment was also specific to implementations not deployme= nts.

For added context, the OOB challenge type has been in the spec = largely unchanged for two years[0].=C2=A0 Plans to use something are nice b= ut I thought our goal was rough consensus and running code.

[0] -=C2= =A0https://github.com/ietf-wg-= acme/acme/commit/3e64248088da56f046c7448a84a0263d1328f470
=

On Fri, Dec 1, 2017 at 10:36 AM, Sal= z, Rich <rsalz@akamai.com> wrote:
  • What date is planned for this release? If there wo= n't be a client and server implementation available by the time we ente= r last call I still think it is most appropriate to defer the OOB challenge type as follow-up work.

That=E2=80=99s not right.=C2=A0 Deployments rarely o= ccur right as the draft is finished.

=C2=A0

So the question was asked, is anyone planning on usi= ng this?=C2=A0 And we got a definitive yes answer.=C2=A0 I think the questi= on now becomes, are the alternatives acceptable?

=C2=A0

We can of course still decide that OOB should be rem= oved, but let=E2=80=99s talk about options right now.



--001a114f049cf2fa0e055f4ac245-- From nobody Fri Dec 1 09:41:19 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568391274D2 for ; Fri, 1 Dec 2017 09:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hemio.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99viJ7UVmRQG for ; Fri, 1 Dec 2017 09:41:17 -0800 (PST) Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8B91200FC for ; Fri, 1 Dec 2017 09:41:17 -0800 (PST) Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id 9FFFCA6; Fri, 1 Dec 2017 18:41:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hemio.de; s=20170414; t=1512150075; bh=yYjrpUD8CJr2k6pyqNuNUrQ9jQtLIAuHJ5XBOBUUQqw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=gTddmaaU1POipSOWhru17mSqm9Hk5UMvbgHJAvJEcQ59Rhdy3pwcgkV4D0o1YjQgj ezZ9U3AMi0a8eySGlj9VKH4fpkml6g7YjV5RM/Ns8RqA75uJPkjnVMsTbkRSC5Pi1O AYq81tVenGDCu7posZyv4vF4Hggo6rolyXFaRS5fJ2U6tj7R9TlZeg17t3JSHGY7QI 4WRHrnBkNHAQJnBXpMUjLw32zzeLSMOwuPakh5fcyTZ38YXRtVhg4ansdJp06p3k9s nW/+3rFcEEo2JPGz+aUPJlQjt71dlu7aJ81o4CdI1ddc7xK9hDeaM+LOl/3pW2Gs4/ es1VM7UUZaCgw== To: Richard Barnes Cc: ACME WG References: <1c740fe6-1594-44d3-69a7-a9f2170e6446@hemio.de> From: Sophie Herold Message-ID: <3980ab0d-c119-58e9-07ee-294a4bcc8499@hemio.de> Date: Fri, 1 Dec 2017 18:41:14 +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-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] Camel vs. kebab-case 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, 01 Dec 2017 17:41:18 -0000 Hi, PR is here https://github.com/ietf-wg-acme/acme/pull/362 PR text: > Using camelCase like @bifurcation suggested. There does not seem to be standard among RFCs containing JSON. JWE uses snake_case, but I don't see a reason why the payload should use the same convention. > > - Renamed sub-problems to subproblems since this spelling seems to be more common. > - Only changed the parts which refer to the keys. Phrases like "new-account request" are unchanged. > - Changes done via a script. I can resubmit the PR with a different convention if required. Best, Sophie On 01/12/17 14:42, Richard Barnes wrote: > Good observation. I would be OK moving everything to camelCase [1], since > it seems like that's a more natural fit for programming language bindings. > > This also seems like a less disruptive change than some other things we've > been doing lately (finalization). At best, it's a string change; at worst, > some variable renaming. > > Want to submit a PR? > > [1] I had not heard "kebab-case" before! It seems like there should be > extra "-" characters on the ends, like "--new-order--" :) > > > On Fri, Dec 1, 2017 at 7:06 AM, Sophie Herold > wrote: > >> Hi, >> >> while updating my client implementation I noted that there seems to be >> an arbitrary mix in object key naming conventions: >> >> camelCase >> >> - newKey >> - keyAuthorization >> - notBefore >> - notAfter >> >> kebab-case >> >> - (all directory fields) >> - terms-of-service-agreed >> - only-return-existing >> - external-account-binding >> >> In my opinion this makes the mapping of JSON objects to implementation >> language objects/types unnecessarily complicated. I don't know if it is >> to late to do something about that. >> >> Best, >> Sophie >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> > From nobody Fri Dec 1 11:34:57 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E5E1286D6 for ; Fri, 1 Dec 2017 11:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.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_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 WeJoN078kMkF for ; Fri, 1 Dec 2017 11:34:54 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A0E6126CB6 for ; Fri, 1 Dec 2017 11:34:53 -0800 (PST) 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=niE221NHvh2Ph48W+3SqiC8vvr9+JbyuL3Y9TAqhH38=; b=0vW8tBKyt/u6ducy9yJ89+0rJxETCNKuFkwPIP8Zxs2+XZZT1bmaMQawfvaJFfQsr4MnGow0SKH0dC38WsMqedU2TXpyUpB2kqJArnzyzJ+t7/azKa/2Sb8PPWh5XOnn2LvRe9ODGmaH2QPjoZRx+h9fAu6MCxPUpkpdzwX5dbg=; Received: ; Fri, 01 Dec 2017 11:34:49 -0800 To: acme@ietf.org References: <1c740fe6-1594-44d3-69a7-a9f2170e6446@hemio.de> From: Jacob Hoffman-Andrews Message-ID: <1d7b2cf0-1f06-7604-2113-89cf9f2af486@eff.org> Date: Fri, 1 Dec 2017 11:34:52 -0800 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: <1c740fe6-1594-44d3-69a7-a9f2170e6446@hemio.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Acme] Camel vs. kebab-case 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, 01 Dec 2017 19:34:55 -0000 Thanks for pointing this out! On 12/01/2017 04:06 AM, Sophie Herold wrote: > camelCase > > - newKey > - keyAuthorization > - notBefore > - notAfter > > kebab-case > > - (all directory fields) > - terms-of-service-agreed > - only-return-existing > - external-account-binding You forgot to include the field names in the directory object, which are currently all kebab case. I think changing those to camelCase would make it dramatically harder for clients to share code between their current implementation and their v2 implementation. So I'm definitely opposed to switching to camelCase. We could in theory switch newKey and keyAuthorization to kebabs, if that's an exhaustive list (nothing currently uses notBefore and notAfter). However, I just finished changing one client so it can support either the old "uri" field in challenges, or the new "url" field, and it was a surprisingly large hassle. I'd rather not impose the additional hassle of dual-classing more field names. Keep in mind that while Let's Encrypt / Boulder is visible, we've heard from a handful of other CAs who have implemented "Certbot compatible" ACME endpoints privately. We should expect that there will be a transition period where most clients will want to support either the older spec version implemented by Certbot / Boulder, OR the final RFC version. From nobody Fri Dec 1 11:51:50 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED56127599 for ; Fri, 1 Dec 2017 11:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hemio.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqbELfJONObe for ; Fri, 1 Dec 2017 11:51:46 -0800 (PST) Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D1C5124D85 for ; Fri, 1 Dec 2017 11:51:46 -0800 (PST) Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id 85CEAA6; Fri, 1 Dec 2017 20:51:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hemio.de; s=20170414; t=1512157904; bh=1v3iPMYAMGozLH8GF7LfhPcriGBFVPq7/EIf9EFsWGs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=j7aTiyRkZowUET/SJeM6yZ90zjjAd6HVujHqMOjCYy86e79EqXRDhA8eCHxn+Bb1h h2kB4MyhkdGXlG7cwmkZKb2EuQmjFg0EBGyzT+1Ui4wWoCqG0ep5nWZcoPvnpAivbo AhpqZD+Q2NVatG2IPKzv8of0pLDHra/YTR9LqR0MZYW8WcTkYg7kxUCr7/sNSzeWqj Z7y8252JsR1r9IqQBBdxoUnuQHqNlA6Gq65GJFHlht8sn0kHzUWelAbmt5U0PxEsmx x6CsgC5my3lq1Ai2j/voQcbhcxiaoQCwwX8iZnBaMMbBVBusnV6GFZLlplmmZAKocz H5ilZqrK6demA== To: Jacob Hoffman-Andrews , acme@ietf.org References: <1c740fe6-1594-44d3-69a7-a9f2170e6446@hemio.de> <1d7b2cf0-1f06-7604-2113-89cf9f2af486@eff.org> From: Sophie Herold Message-ID: <95c1831c-2a26-9200-369f-765807c23d7b@hemio.de> Date: Fri, 1 Dec 2017 20:51:43 +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: <1d7b2cf0-1f06-7604-2113-89cf9f2af486@eff.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] Camel vs. kebab-case 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, 01 Dec 2017 19:51:47 -0000 I have posted a similar PR for kebab-case https://github.com/ietf-wg-acme/acme/pull/363 Best, Sophie On 01/12/17 20:34, Jacob Hoffman-Andrews wrote: >> kebab-case >> >> - (all directory fields) > You forgot to include the field names in the directory object From nobody Tue Dec 5 15:07:54 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9ADF126C89 for ; Tue, 5 Dec 2017 15:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hemio.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-8XHkVAbjS3 for ; Tue, 5 Dec 2017 15:07:52 -0800 (PST) Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC9611279EB for ; Tue, 5 Dec 2017 15:07:51 -0800 (PST) Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id E27D79E for ; Wed, 6 Dec 2017 00:07:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hemio.de; s=20170414; t=1512515270; bh=2hwxi3yQ7aNvOn38xPIeImHZc52zmf6jBihGJJN4+sg=; h=To:From:Subject:Date:From; b=hXnN+rDXHgZQBr4NXQx+cbAo/15Q3nYBu7RtJH50Mz5xzN7gp1xPhWLQ9zFejv1C3 +dzVWb/ee9jPSpCarxWWgTx+Uzo6s1G+gAT1a7YfAd1gc6CdDHtCM12hiKApyeTu0l F+aF51/5Iz8NHi+liV6gESMQsDXolQ1qTLIGMhEVMjqsp5Rj+3jX3BXBFXmrNhUBTo aCAFpo2sSaiHzL+Ipff07FPH4XvOdYUXZGroxz1Z6Yl5Nk/JT6h7RVq0memHex71kM 0joIFL6soKfvAjai8h2HZxvKgysYEY/I5KVkHoypi0F4YRnUsVv/RaJL4zIl8FT8kQ wBzxXYPFBs9Yg== To: IETF ACME From: Sophie Herold Message-ID: Date: Wed, 6 Dec 2017 00:07:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [Acme] new-authz, new-order and examples 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, 05 Dec 2017 23:07:53 -0000 Hi, i noted that the examples in "7.4. Applying for Certificate Issuance" are still using CSRs. Further, I didn't found explicit coverage of the case that there is a valid authorization (say via new-authz) at the time of posting a new-order. Should the server return "authorizations: valid" in this case and does that imply the client can proceed with finalization immediately? Having mentioned new-authz: The definition of new-authz is now a subset of new-order. Is there any reason to keep the new-authz resource at all? Would there be any difference in using new new-order with the exact same query without finalizing it? Best, Sophie From nobody Wed Dec 6 07:53: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 6D6B0124F57 for ; Wed, 6 Dec 2017 07:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 cMFBJi0rH1uv for ; Wed, 6 Dec 2017 07:53:10 -0800 (PST) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C13F0127077 for ; Wed, 6 Dec 2017 07:53:10 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id d16so7570670itj.1 for ; Wed, 06 Dec 2017 07:53:10 -0800 (PST) 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=0Yg2Lvlwxy9FbCUU/09AP+1ZnqO3Ks3xEnFbD6+6DVg=; b=MQUKJVahiv5ofbSure6M/L73fheGjea0FIKzJGqGHlKifFhO8QyE6lyB2a9tMcPPYf i/Xn/e99czAC48Fe5meZ0meCb5debG9QsZX7TrekDHxRo57sL4nvbYGJ9e2imrYiQkvo +PVAuAg3WwIU+lOyCwoTfoKK9gOUgKR0SUGAI= 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=0Yg2Lvlwxy9FbCUU/09AP+1ZnqO3Ks3xEnFbD6+6DVg=; b=cg2nGdJeRoAM47Wd7BHJoEcmaBpbKcjskolzkm+qEBqHUpTjHFx/YHq9WBhJpXxwFt FhN2qntQo7G9NQhEUISqWaYSqyXHhYbEIV2ao0rFM/ppG4PzDuqFtjUklU/G40pBV32F H0/6AHeElfNOHj4oQfH+WjBt9KuuE+tL6bjC89G9UVF5GSPUtAKsy8U8Vf0+84oDF6Ru Rq069SXbFsZ/tiDBLD3DtkMnTPBTetyxAUbIC2d/6qBWNOFc+sTbeheK6P1e5cGmbxbr e0/8r637xRH6zzOz/LZ9tVA9Y8bbQetFnoSKODg1h3xFInfZnAFVdjcVJDa1ruJJwxbg T2Zw== X-Gm-Message-State: AKGB3mIw6LCKKPFiR2iSLnoh7DDa4oNZVq/4tH5murT5OvI+0RNKavXw 7052Y00I0YpTyqig083wqMJl4TtmUvL+G0VpsgCklo/kN3M= X-Google-Smtp-Source: AGs4zMYgzCKRcufHz5GuXJ+nKmFOEG8NX7vSW3ExhBJWI9hYX6CqBzFG7+CQEG42xQtGSaLOwcyAYSRdcLAlJBF2Kmk= X-Received: by 10.36.4.144 with SMTP id 138mr15462479itb.78.1512575589925; Wed, 06 Dec 2017 07:53:09 -0800 (PST) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.17.28 with HTTP; Wed, 6 Dec 2017 07:53:09 -0800 (PST) In-Reply-To: References: From: Daniel McCarney Date: Wed, 6 Dec 2017 10:53:09 -0500 Message-ID: To: Sophie Herold Cc: IETF ACME Content-Type: multipart/alternative; boundary="001a114089d6bbe0c6055fadf2aa" Archived-At: Subject: Re: [Acme] new-authz, new-order and examples 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, 06 Dec 2017 15:53:14 -0000 --001a114089d6bbe0c6055fadf2aa Content-Type: text/plain; charset="UTF-8" Hi Sophie, i noted that the examples in "7.4. Applying for Certificate Issuance" are > still using CSRs. Good catch! I'll submit a PR to address this oversight this afternoon. > Further, I didn't found explicit coverage of the case that there is a valid > authorization (say via new-authz) at the time of posting a new-order. > Should the server return "authorizations: valid" in this case and does > that imply the client can proceed with finalization immediately? That's my understanding. If a client uses the new-authz preauth flow to obtain a valid authz for "example.com" with ID "https://acme.inc/authz/1234", and then submits a new-order for identifiers `["example.com"]` I would expect the server to return an order with `"authorizations": [" https://acme.inc/authz/1234"]`. When the client GET's each of the Authz IDs it will see all are `state: valid`, no challenges need POSTing, and finalization of the order can occur. Having mentioned new-authz: The definition of new-authz is now a subset of > new-order. Is there any reason to keep the new-authz resource at all? Would > there be any difference in using new new-order with the exact same query > without finalizing it? I agree with you that it seems like the new-authz flow is unnecessary - I believe Jacob Hoffman-Andrews has previously argued it shouldn't be included in the spec. Let's Encrypt does not intend to implement it at all for their new order-based API endpoint. If someone has a use-case for the new-authz flow that isn't addressed by new-order with finalization they should speak up in-thread - otherwise I vote it be removed. - Daniel / cpu On Tue, Dec 5, 2017 at 6:07 PM, Sophie Herold wrote: > Hi, > > i noted that the examples in "7.4. Applying for Certificate Issuance" > are still using CSRs. > > Further, I didn't found explicit coverage of the case that there is a > valid authorization (say via new-authz) at the time of posting a > new-order. Should the server return "authorizations: valid" in this case > and does that imply the client can proceed with finalization immediately? > > Having mentioned new-authz: The definition of new-authz is now a subset > of new-order. Is there any reason to keep the new-authz resource at all? > Would there be any difference in using new new-order with the exact same > query without finalizing it? > > Best, > Sophie > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a114089d6bbe0c6055fadf2aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Sophie,

i not= ed that the examples in "7.4. Applying for Certificate Issuance"= =C2=A0are still using CSRs.<= /blockquote>

Good catch! I'll submit a PR to address this overs= ight this afternoon.
=C2=A0
Further, I didn't found exp= licit coverage of the case that there is a=C2=A0valid authorization (say via new-authz) at the time of posting= a=C2=A0new-order. Should the serve= r return "authorizations: valid" in this case=C2=A0and does that imply the client can proceed with f= inalization immediately?

That's my understa= nding. If a client uses the new-authz preauth flow to obtain a valid authz = for "example.com" with ID &quo= t;https://acme.inc/authz/1234&q= uot;, and then submits a new-order for identifiers `["example.com"]` I would expect the server to return = an order with `"authorizations": ["https://acme.inc/authz/1234"]`. When the client GET= 's each of the Authz IDs it will see all are `state: valid`, no challen= ges need POSTing, and finalization of the order can occur.

H= aving mentioned new-authz: The definition of new-authz is now a subset=C2= =A0of new-order. Is there any reaso= n to keep the new-authz resource at all?=C2=A0Would there be any difference in using new new-order with the ex= act same=C2=A0query without finaliz= ing it?

I agree with you that it seems like the= new-authz flow is unnecessary - I believe Jacob Hoffman-Andrews has previo= usly argued it shouldn't be included in the spec. Let's Encrypt doe= s not intend to implement it at all for their new order-based API endpoint.=

If someone has a use-case for the new-authz flow that isn't ad= dressed by new-order with finalization they should speak up in-thread - oth= erwise I vote it be removed.

- Daniel / cpu



On Tue, Dec 5, 2= 017 at 6:07 PM, Sophie Herold <sophie_herold@hemio.de> = wrote:
Hi,

i noted that the examples in "7.4. Applying for Certificate Issuance&q= uot;
are still using CSRs.

Further, I didn't found explicit coverage of the case that there is a valid authorization (say via new-authz) at the time of posting a
new-order. Should the server return "authorizations: valid" in th= is case
and does that imply the client can proceed with finalization immediately?
Having mentioned new-authz: The definition of new-authz is now a subset
of new-order. Is there any reason to keep the new-authz resource at all? Would there be any difference in using new new-order with the exact same query without finalizing it?

Best,
Sophie

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

--001a114089d6bbe0c6055fadf2aa-- From nobody Wed Dec 6 12:38:58 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D7212426E for ; Wed, 6 Dec 2017 12:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.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_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 dQ8gXNHbMFpr for ; Wed, 6 Dec 2017 12:38:55 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAD981200FC for ; Wed, 6 Dec 2017 12:38:55 -0800 (PST) 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=eJct9BJ6isFBXTSxW4PM1wqGw9Pz+Sa1UvJ173LX1kM=; b=7ffhHAodxdaUZfY0MuRn8ilfK9cC5tqJyIWqQxhDdA+Lk0pnbEC7IeCL+o9uvnfXUxeSsSsiYQRES0fLGwHNYqQwjQKxzBsRf2kX+iKcBST573XJ7QPz1l0zFooUndW1w3n1DGvV3legRZ1Vp7tlfTxztGHara9KpLcBe4ah1tk=; Received: ; Wed, 06 Dec 2017 12:38:50 -0800 To: acme@ietf.org, Eric Rescorla References: From: Jacob Hoffman-Andrews Message-ID: <341f5251-072e-cfe4-9cc0-81967bd583fb@eff.org> Date: Wed, 6 Dec 2017 12:38:54 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.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] new-authz, new-order and examples 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, 06 Dec 2017 20:38:57 -0000 On 12/05/2017 03:07 PM, Sophie Herold wrote: > Having mentioned new-authz: The definition of new-authz is now a subset > of new-order. Is there any reason to keep the new-authz resource at all? > Would there be any difference in using new new-order with the exact same > query without finalizing it? Yeah, I agree that this is a happy side-effect of making order finalization an explicit step: there is now even less need for preauthorization (i.e. new-authz). I strongly favor removing it. Eric, I think you were the strongest voice in favor of adding preauthorization to the spec when we moved to the new-order flow. Do you still feel it's necessary? For context, you can accomplish the same thing by posting a new-order for a single identifier, but not finalizing the order. From nobody Wed Dec 6 12:58:26 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 1E470127337 for ; Wed, 6 Dec 2017 12:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Qugc-ALxY_35 for ; Wed, 6 Dec 2017 12:58:21 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 AF30712717E for ; Wed, 6 Dec 2017 12:58:21 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id t1so9603480ite.5 for ; Wed, 06 Dec 2017 12:58:21 -0800 (PST) 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=U/s0d/pQlNaGFW+ygdjKo43joZTCIGSCxxCcnHnYJj4=; b=Y4A1JIZn0FifIBVSf6lcbJ/C6lrQm62cyNd3jUjjayz1xyzYTML8/8LoNEA/d9SFSM uUMBxUzS8p7ZMZYiTltgQqrWVVwlpace2qmmfJyLsp0uEAVzdp9HDkctLLj2Pbdu3hRZ iBrrEDJC+gwXkz5TNzFYl3ogMKtrvzxxjtoiA= 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=U/s0d/pQlNaGFW+ygdjKo43joZTCIGSCxxCcnHnYJj4=; b=foUkLaNAIdkBvydAeWtnfzoZAlHzfM12tU1CRSS40f2sZ5PSkcHLZM464SvP73Dbxt BpwomI9KWiaryNuNCSGW2TE50w3uCwZwr/03g13ay9lfYwlpsX8qKW4PtM+x08/6osto CsptGBy2ZpWeGiBNYfeh+IpLP2aLHCJHmhkZyPRW92r7vNb4XpWwpxOjEvem8DRArkui xlgjp0wSi9hNJRUiKYav6Bsnw2P/FrBoedR3ZHnJCbmV9DXEsl78vViZtypkGPxxk29E AuDzNJvXELVtkKpUllezeb4VbJFWuuAVseD5iE1IeObM8BujdDTacX19tXf4CaIfttbQ 49iQ== X-Gm-Message-State: AJaThX5OJytzZmYYIdQCwD3wJE1rVbmsZWe9XeafOn1QSWn2HVybHvH9 FwXh4vxYNDQN37C0dYh20ypjlYXAMoROQ0405oRS+N6eaTM= X-Google-Smtp-Source: AGs4zMYHRDsnAONc4z2uJrFseFcVc9AGLICBldNvCRJSRRXlelWx7N04/SdvWkBtWfno4+RQuIpWUwWVRq93ZbELsbk= X-Received: by 10.107.170.40 with SMTP id t40mr37182600ioe.73.1512593900995; Wed, 06 Dec 2017 12:58:20 -0800 (PST) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.17.28 with HTTP; Wed, 6 Dec 2017 12:58:20 -0800 (PST) In-Reply-To: References: From: Daniel McCarney Date: Wed, 6 Dec 2017 15:58:20 -0500 Message-ID: To: Sophie Herold Cc: IETF ACME Content-Type: multipart/alternative; boundary="001a1142d86e289bbf055fb23689" Archived-At: Subject: Re: [Acme] new-authz, new-order and examples 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, 06 Dec 2017 20:58:25 -0000 --001a1142d86e289bbf055fb23689 Content-Type: text/plain; charset="UTF-8" > >> i noted that the examples in "7.4. Applying for Certificate Issuance" are > still using CSRs. > Good catch! I'll submit a PR to address this oversight this afternoon. https://github.com/ietf-wg-acme/acme/pull/367 On Wed, Dec 6, 2017 at 10:53 AM, Daniel McCarney wrote: > Hi Sophie, > > i noted that the examples in "7.4. Applying for Certificate Issuance" are >> still using CSRs. > > > Good catch! I'll submit a PR to address this oversight this afternoon. > > >> Further, I didn't found explicit coverage of the case that there is a valid >> authorization (say via new-authz) at the time of posting a new-order. >> Should the server return "authorizations: valid" in this case and does >> that imply the client can proceed with finalization immediately? > > > That's my understanding. If a client uses the new-authz preauth flow to > obtain a valid authz for "example.com" with ID " > https://acme.inc/authz/1234", and then submits a new-order for > identifiers `["example.com"]` I would expect the server to return an > order with `"authorizations": ["https://acme.inc/authz/1234"]`. When the > client GET's each of the Authz IDs it will see all are `state: valid`, no > challenges need POSTing, and finalization of the order can occur. > > Having mentioned new-authz: The definition of new-authz is now a subset of >> new-order. Is there any reason to keep the new-authz resource at all? Would >> there be any difference in using new new-order with the exact same query >> without finalizing it? > > > I agree with you that it seems like the new-authz flow is unnecessary - I > believe Jacob Hoffman-Andrews has previously argued it shouldn't be > included in the spec. Let's Encrypt does not intend to implement it at all > for their new order-based API endpoint. > > If someone has a use-case for the new-authz flow that isn't addressed by > new-order with finalization they should speak up in-thread - otherwise I > vote it be removed. > > - Daniel / cpu > > > > On Tue, Dec 5, 2017 at 6:07 PM, Sophie Herold > wrote: > >> Hi, >> >> i noted that the examples in "7.4. Applying for Certificate Issuance" >> are still using CSRs. >> >> Further, I didn't found explicit coverage of the case that there is a >> valid authorization (say via new-authz) at the time of posting a >> new-order. Should the server return "authorizations: valid" in this case >> and does that imply the client can proceed with finalization immediately? >> >> Having mentioned new-authz: The definition of new-authz is now a subset >> of new-order. Is there any reason to keep the new-authz resource at all? >> Would there be any difference in using new new-order with the exact same >> query without finalizing it? >> >> Best, >> Sophie >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> > > --001a1142d86e289bbf055fb23689 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= >> i noted that the examples in &quo= t;7.4. Applying for Certificate Issuance"=C2=A0are still using CSRs.

> Good catch! I'll submit a PR to address this oversight this after= noon.
=C2= =A0

On= Wed, Dec 6, 2017 at 10:53 AM, Daniel McCarney <cpu@letsencrypt.org&= gt; wrote:
Hi Sop= hie,

i noted t= hat the examples in "7.4. Applying for Certificate Issuance"=C2= =A0are still using CSRs.

Good catch! I'll submit a PR to address this o= versight this afternoon.
=C2=A0
Further, = I didn't found explicit coverage of the case that there is a=C2=A0valid authorization (say via new-authz) = at the time of posting a=C2=A0new-o= rder. Should the server return "authorizations: valid" in this ca= se=C2=A0and does that imply the cli= ent can proceed with finalization immediately?

That's my understanding. If a client uses the new-authz preauth = flow to obtain a valid authz for "example.com" with ID "https://acme.inc/authz/1234", and = then submits a new-order for identifiers `["example.com"]` I would expect the server to= return an order with `"authorizations": ["https://acme.inc/authz/1234&qu= ot;]`. When the client GET's each of the Authz IDs it will see all= are `state: valid`, no challenges need POSTing, and finalization of the or= der can occur.

Having mentioned new-authz: = The definition of new-authz is now a subset=C2=A0of new-order. Is there any reason to keep the new-authz resou= rce at all?=C2=A0Would there be any= difference in using new new-order with the exact same=C2=A0query without finalizing it?

I agree with you that it seems like the new-authz flow is unn= ecessary - I believe Jacob Hoffman-Andrews has previously argued it shouldn= 't be included in the spec. Let's Encrypt does not intend to implem= ent it at all for their new order-based API endpoint.

If someone ha= s a use-case for the new-authz flow that isn't addressed by new-order w= ith finalization they should speak up in-thread - otherwise I vote it be re= moved.

- Daniel / cpu



On Tue, Dec 5, 2017 at 6:07 PM, Sophie Herold <sophie_herold@hemio.= de> wrote:
Hi,

i noted that the examples in "7.4. Applying for Certificate Issuance&q= uot;
are still using CSRs.

Further, I didn't found explicit coverage of the case that there is a valid authorization (say via new-authz) at the time of posting a
new-order. Should the server return "authorizations: valid" in th= is case
and does that imply the client can proceed with finalization immediately?
Having mentioned new-authz: The definition of new-authz is now a subset
of new-order. Is there any reason to keep the new-authz resource at all? Would there be any difference in using new new-order with the exact same query without finalizing it?

Best,
Sophie

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


--001a1142d86e289bbf055fb23689-- From nobody Wed Dec 6 13:58: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 E8512127AD4 for ; Wed, 6 Dec 2017 13:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 P16XcJEpm3Ex for ; Wed, 6 Dec 2017 13:58:21 -0800 (PST) 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 AD879127ABE for ; Wed, 6 Dec 2017 13:58:20 -0800 (PST) Received: by mail-wr0-x236.google.com with SMTP id y21so5456297wrc.1 for ; Wed, 06 Dec 2017 13:58:20 -0800 (PST) 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=D214qOjusuANBNt8Vci7kEJwO7rxKZztoVdPl2DIwxA=; b=Q22LOI4MHasXJYjnt9d82u+wQQMszOngw520egH/1Md1+QgLiBHD0LPgf7h9lygMUc SF6qkZVPWOCnPCgkraEkyQ0GuEl3X/OgvpJV1cSjz9u9ERvk5v5Bq8uV9liN7cDI/mkR xzK8viSXBHa3iZNPstR7eQp/aNOso2QOviJLY5Ax/ga/CcSpNG4g5BPR3yAFlbV3bh5o nKAYYYVqqe5fzHX3D1CoJIErDJ7BjogqcQo06KuHT8Le1o+h0vaKOr2q7B5mkL196iVs OmeIZ4LfzxPTxUyKkNmT4q5tUu+Y3t7ZOcOLe5xzE89jVgQQzRHJmtiJC66vgjf0oGVa /22A== 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=D214qOjusuANBNt8Vci7kEJwO7rxKZztoVdPl2DIwxA=; b=Bja+rfPL8LHNNZLVBMe2yqctCkd/saDm+aHi+FC6RM2iboy0Q81HMXEg4E5vo1kVXT 1W5Cjvwh5Z3lZPpxqW6q7mAX5YZbiegV+oLQyGaCC0dAKf1I4dT06euC0KWGrzKNTYNQ qDkOBs/AL2P3IG8G38PtSxANCrBrfMy9+bDR1/tI0d1FAQaqJC/SV/EI2VtlGRGNHCAC 9U2G2B6i0E0rOedtiRPS+FOkcA6LzYzwiE3uugFlwObT/J5WgrOFG2dZpVOXqminIj5X rHH8crez0+W1dZm3tY6mnpd8J84JSAxznKPM/g1GT4+cuOqDb7VsrMoRxkr2uQ0olLqK VfbQ== X-Gm-Message-State: AJaThX5r1EWZ0IOQluPyT7f+8Xxgrxop9E4PCcw/k0BKz9qiy9fJPyVL 1coZXpg8PJdZPicnv+9LN0kmSGDLyR9Afgt04SfQug== X-Google-Smtp-Source: AGs4zMZ54dDSAZNPEbLwMBb1mgnvMY0czm59wV6yJgdQwY3AB26+aiOJvzlRW3WNUUafbvUjpfgvOAd9gX/V10thwjQ= X-Received: by 10.223.141.134 with SMTP id o6mr20606653wrb.95.1512597499003; Wed, 06 Dec 2017 13:58:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.167.74 with HTTP; Wed, 6 Dec 2017 13:58:18 -0800 (PST) In-Reply-To: <341f5251-072e-cfe4-9cc0-81967bd583fb@eff.org> References: <341f5251-072e-cfe4-9cc0-81967bd583fb@eff.org> From: Richard Barnes Date: Wed, 6 Dec 2017 16:58:18 -0500 Message-ID: To: Jacob Hoffman-Andrews Cc: "acme@ietf.org" , Eric Rescorla Content-Type: multipart/alternative; boundary="f403045f569a9de049055fb30cdc" Archived-At: Subject: Re: [Acme] new-authz, new-order and examples 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, 06 Dec 2017 21:58:23 -0000 --f403045f569a9de049055fb30cdc Content-Type: text/plain; charset="UTF-8" On Wed, Dec 6, 2017 at 3:38 PM, Jacob Hoffman-Andrews wrote: > On 12/05/2017 03:07 PM, Sophie Herold wrote: > > Having mentioned new-authz: The definition of new-authz is now a subset > > of new-order. Is there any reason to keep the new-authz resource at all? > > Would there be any difference in using new new-order with the exact same > > query without finalizing it? > > Yeah, I agree that this is a happy side-effect of making order > finalization an explicit step: there is now even less need for > preauthorization (i.e. new-authz). I strongly favor removing it. Eric, I > think you were the strongest voice in favor of adding preauthorization > to the spec when we moved to the new-order flow. Do you still feel it's > necessary? For context, you can accomplish the same thing by posting a > new-order for a single identifier, but not finalizing the order. > I'll let EKR speak for himself, but this seems really clumsy to me. At the very least, it requires the server to allocate more resources than it otherwise would, order+authz instead of just authz. The new-authz endpoint is simple enough (and optional enough) that I think it's worth keeping around on its own for those who want it. --Richard --f403045f569a9de049055fb30cdc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Dec 6, 2017 at 3:38 PM, Jacob Hoffman-Andrews <jsha@ef= f.org> wrote:
On 12/05/2017 03:= 07 PM, Sophie Herold wrote:
> Having mentioned new-authz: The definition of new-authz is now a subse= t
> of new-order. Is there any reason to keep the new-authz resource at al= l?
> Would there be any difference in using new new-order with the exact sa= me
> query without finalizing it?

Yeah, I agree that this is a happy side-effect of making order
finalization an explicit step: there is now even less need for
preauthorization (i.e. new-authz). I strongly favor removing it. Eric, I think you were the strongest voice in favor of adding preauthorization
to the spec when we moved to the new-order flow. Do you still feel it's=
necessary? For context, you can accomplish the same thing by posting a
new-order for a single identifier, but not finalizing the order.

I'll let EKR speak for himself, but this seem= s really clumsy to me.=C2=A0 At the very least, it requires the server to a= llocate more resources than it otherwise would, order+authz instead of just= authz.=C2=A0 The new-authz endpoint is simple enough (and optional enough)= that I think it's worth keeping around on its own for those who want i= t.

--Richard

--f403045f569a9de049055fb30cdc-- From nobody Fri Dec 8 00:14:19 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCFA3126C2F for ; Fri, 8 Dec 2017 00:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.314 X-Spam-Level: ** X-Spam-Status: No, score=2.314 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_IMAGE_ONLY_16=1.092, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URI_HEX=1.122] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotwaxsystems-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 0fsy-bHO7YDL for ; Fri, 8 Dec 2017 00:14:15 -0800 (PST) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B91E9124D68 for ; Fri, 8 Dec 2017 00:14:15 -0800 (PST) Received: by mail-it0-x241.google.com with SMTP id f190so3105790ita.5 for ; Fri, 08 Dec 2017 00:14:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotwaxsystems-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=zujgtGpRs+laWhtKhBlUTaQhy4vMEWF6IaRwGw5/OxE=; b=nkJafIu74LSu//FGWTnszne4rZdKZYeB9y3dfGoqj7ZnB2Ahb6053o4AyCVWUg8wJn 7v/iJ+Wj19sfIr+VLLCtj3Z/rM6I67JzXGCD28DTHu/Ic6lT+Ydbja376J5OQ1d2siux //bwIANCHqBFXoF5A4OGan6aWPVYwlOJKmFjtHLWkB6Bl6VhyOl0oz5HJSSFLiRewmug IrpzpK78II9MGtADWovGz2SsSkWSkXAcF+JtlE2JU7MnuoYWH9cL42VqT4tx13P3t2ng tqqa7zEDuqc/7rl570ei4AhjRfQox1HiJaNl98UBwypBwqFNLzWLa55BZ2wTwh3LPCgT Kkog== 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=zujgtGpRs+laWhtKhBlUTaQhy4vMEWF6IaRwGw5/OxE=; b=IK4jLnN9t8YSO8pSnifcotTdxt+Q37qcsq/GuuYD2HWgApREhZxDrfrYv76GkqVUmq oAc3DqBDjHRuQNyJVq5czQGnFOn/mJfuEqjinK9WOCkcAlMz6HdPEwBlm6+7h3gH//eH hGjT/mGdKn/QUoE8zI+wg0TKwlLxafPtCM/7xOtiCh3Kz7tOMy7arWUU4giQ80V71t8R 6jAor91RTEQ7UsoiuRvMfl7Ir5r2EkNWbBzo/3WSHlVCEssNXGkug8AJyO+tcrL328+t 3WFn6J7ewoCUKWlz3lzcUHYqi8RTB0mUFgM/1jJqnZ3q8PomJ/zHlbdJOdSEFPFDcgv6 OUWA== X-Gm-Message-State: AKGB3mJ3DdvgINu4QNwPberNZYlJgI1XsBehgEU3R5ZmEME3T6vj9MD1 NVbPwWS7/0kjrNbtw5heDFGUaV/ZQQKruktpSHA9Qg== X-Google-Smtp-Source: AGs4zMbCsJP/HBWZIsowBUC5gCAW9ebG/aSq/Rx8uUufvfeTOAmxHrbeDdy9gcCdFzRD0yyZ3eSlyB9qr+axqcFCXWI= X-Received: by 10.107.9.234 with SMTP id 103mr16719160ioj.126.1512720854551; Fri, 08 Dec 2017 00:14:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.7.36 with HTTP; Fri, 8 Dec 2017 00:14:14 -0800 (PST) From: Praveen Sharma Date: Fri, 8 Dec 2017 13:44:14 +0530 Message-ID: To: acme@ietf.org Content-Type: multipart/alternative; boundary="001a113f28582e241a055fcfc57e" Archived-At: Subject: [Acme] [ACME][QUESTION] Mac Based Algorithm Verfication 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, 08 Dec 2017 08:14:18 -0000 --001a113f28582e241a055fcfc57e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Devs, How to verify that the provided algorithm is MAC based algorithm using any node module? Thanks --=20 *Praveen Sharma* | Enterprise Software Engineer HotWax Systems > Cell phone: 8878488144 =E2=80=8C --001a113f28582e241a055fcfc57e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=3D""Hi Devs,

<= div>How to verify that the provided algorithm is MAC based=C2=A0algorithm u= sing any node module?



Thanks
--
Praveen Sharma |=C2=A0Enterprise Software Engineer
HotWax Sy= stems <http= s://www.hotwaxsystems.com>
Cell phone: 8878488144
<= /div>



=E2=80=8C --001a113f28582e241a055fcfc57e-- From nobody Fri Dec 8 00:46: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 05DE8126B6E for ; Fri, 8 Dec 2017 00:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 d34WgmXCZyNL for ; Fri, 8 Dec 2017 00:45:51 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 148BA126C2F for ; Fri, 8 Dec 2017 00:45:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 6D578B5371; Fri, 8 Dec 2017 10:45:48 +0200 (EET) 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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id Hs8qY7O4LBKZ; Fri, 8 Dec 2017 10:45:48 +0200 (EET) 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 2286D27B; Fri, 8 Dec 2017 10:45:46 +0200 (EET) Date: Fri, 8 Dec 2017 10:45:45 +0200 From: Ilari Liusvaara To: Praveen Sharma Cc: acme@ietf.org Message-ID: <20171208084545.GA27675@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] [ACME][QUESTION] Mac Based Algorithm Verfication 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, 08 Dec 2017 08:46:01 -0000 On Fri, Dec 08, 2017 at 01:44:14PM +0530, Praveen Sharma wrote: > Hi Devs, > > How to verify that the provided algorithm is MAC based algorithm using any > node module? > Don't know about Node modules (maybe whatever JOSE module you use has such function?), but: function is_signature_alg(alg) { return /^[EPR]S(256|384|512)|EdDSA$/.test(alg); } function is_mac_alg(alg) { return /^HS(256|384|512)$/.test(alg) } (Those two do direct regexps with known valid JOSE signature and MAC algorithms). -Ilari From nobody Fri Dec 8 01:02:56 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 496E3126FB3 for ; Fri, 8 Dec 2017 01:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.314 X-Spam-Level: ** X-Spam-Status: No, score=2.314 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_IMAGE_ONLY_16=1.092, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URI_HEX=1.122] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotwaxsystems-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 u1NA0yn2NyKQ for ; Fri, 8 Dec 2017 01:02:51 -0800 (PST) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (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 77A9B126DEE for ; Fri, 8 Dec 2017 01:02:51 -0800 (PST) Received: by mail-it0-x242.google.com with SMTP id p139so3500013itb.1 for ; Fri, 08 Dec 2017 01:02:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotwaxsystems-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=+rgwcDb/C5RhP2JU4m40SiiG/mESBw74cJjunEPsL/Y=; b=0jgvmgoJiuESSNGLt5XY3vjI0AEFbrd51T0WsnHExoWLQqfxNLlt18p9CvxUNilPq9 DsbuFDeawqRvwOXv4su2IYShpXocIoS1q+Nhjlc4dxxm99uFTwxCJjEc0fGphOGCuUNe WoxWV2dvEIQZlXwBrKAkmRdH1QMpqFPOBh2I1w6JW9an/coYjnEKjPN8RfqrOX9+AwUi HonqvcJSSmzM234duRnVqakWZmx0dJR9um1zJcyaY0NLxhG8+RZziHYcwCHnFvrMFnSJ WlkU7aIj632EqvQ32r/ZLebHAVxud9x6d+dvgs3pfyWAjmBnyuU4R4NsHezmsDPw50SZ 5BFA== 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=+rgwcDb/C5RhP2JU4m40SiiG/mESBw74cJjunEPsL/Y=; b=JP1jP1pRimaSArvElkMATnTkr9n0uRHf043g7EGrT+iLpZ29krRHyleyYauBCrPoa3 nMkOWcOf92fJCBI/R9jwkU9du1LCvE+6okBN1QQd/5xXPImazPLulhV6FzEZHwbHFJQo njywYLPftbYoaFwofApPi3InMioh1ac+Dl8qL54by76pIeppsopiEY0n8vA5PYCR3P4c 6f8atKJoyggAZERA8dfXVWOYCl8GAQ3HRyXhN6nV5huZkbrttk80DB5tIyYcOk7Wios6 W9vvmoHMNewdqrxEipsHURj66u9TeEbH1klo9rcADdwZgCS2EyZEbsUKfgMm4Po63kgN 6Hmg== X-Gm-Message-State: AJaThX6vfR7Byq074lqgGwcFvI/7DsNGWC0jo00y66yW8FDiCqVlLr2p hvFuolub9L7P9eljhLMT3LkJznd76mCSPit62g7LgJbf X-Google-Smtp-Source: AGs4zMbH8KpzHtgK/ur8OnhyM+cQ0UkTGT9wpnlOvu/ZGIyLnX0ZC5LW1P9N2tfgfCJFH/8t+RylpSbcbwyJmOBGO5s= X-Received: by 10.107.83.3 with SMTP id h3mr41649091iob.287.1512723770613; Fri, 08 Dec 2017 01:02:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.7.36 with HTTP; Fri, 8 Dec 2017 01:02:50 -0800 (PST) From: Praveen Sharma Date: Fri, 8 Dec 2017 14:32:50 +0530 Message-ID: To: acme@ietf.org Content-Type: multipart/alternative; boundary="089e082663f8fdb4ce055fd072a4" Archived-At: Subject: [Acme] [ACME][QUESTION] JWS Signature Verification Using JWK 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, 08 Dec 2017 09:02:53 -0000 --089e082663f8fdb4ce055fd072a4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Devs, How can we verify the signature in a JWS using the JWK field in the header of the JWS? Thanks --=20 *Praveen Sharma* | Enterprise Software Engineer HotWax Systems > Cell phone: 8878488144 =E2=80=8C --089e082663f8fdb4ce055fd072a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=3D""Hi Devs,

<= div>How can we verify the signature in a=C2=A0JWS=C2=A0using the JWK field = in the header of the JWS?

Thanks
--
=
Praveen Sharma |=C2=A0Enterprise Software Engineer
Cell phone: 8878488144



=E2=80=8C
--089e082663f8fdb4ce055fd072a4-- From nobody Fri Dec 8 01:48:31 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC68126CB6 for ; Fri, 8 Dec 2017 01:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.198 X-Spam-Level: X-Spam-Status: No, score=0.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_IMAGE_ONLY_08=1.651, HTML_IMAGE_RATIO_02=0.437, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=hotwaxsystems-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 5NY6sb5d9Xqx for ; Fri, 8 Dec 2017 01:48:28 -0800 (PST) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (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 10C651200CF for ; Fri, 8 Dec 2017 01:48:27 -0800 (PST) Received: by mail-it0-x243.google.com with SMTP id b5so3696143itc.3 for ; Fri, 08 Dec 2017 01:48:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotwaxsystems-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=pNd0ujMmW7Y1HAOaOXpVQpkqZo+swV/UPNIF45o4KJY=; b=lqLqmoQZBhWGDX6XKGBHH3S969coi5ZESR4xD5T9MTzCyXSXgNN225u/5rxMNUy6Us +xRaPYpAS20niSLOT/dJsApPrEH3ljYsQCOVSjiV7FM/7gvYbAZxFGghAocWusjzTHQs Re1aUe6SqtKaE0lxQT+Y5Jv4S5EaipnWHkYqNRDObXb3Xl0kykPyO92rD1v/6YUb3Te/ v6HuDTcBT62M/bn1oQaXOhK7YR5tBjLn9ozDoPd0tF8UG13Q7qoRL9RkEV0GQftumcZj u4XYqLM+C892X3KzYPhjr7ZsUSE1nTU2FEAr5fHKPUUTa9xoEwyXgQJVe8o4+v7w2rz8 FfYw== 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=pNd0ujMmW7Y1HAOaOXpVQpkqZo+swV/UPNIF45o4KJY=; b=tTyXxH+345drR1qrtm6GLj6t96Dp8rUkuD/wQu5Qu+gmvw05vSopaq77HUHJ9lmVQG QtRZokQKqYMmBB155ME05QefDnjbhOOpFud3xQBpCOjs+Bfns2jKOm4At0R+IdjL3kpu iObsZoXCoNPiehSCeg6JPdzK6XGvI/XTxJB3OF4TBdMUKunc+9H44QZawHlISgmOk6rj xJFH/yAGLXwrUOg80LZXXowLbIEEp5Wu/o/8uaxCeoyDI7CE68XGUA0Yc/v2zy2pXpsb GPFt4Ct95E/XJw1TQ4eLBTmSkis+Qv4Akra1ywSH+vkOtTVtImj5dHSvPdQ+IUflFcW9 RXTw== X-Gm-Message-State: AKGB3mJdlNo6ch01z6OeOhJwxDUSW5NnxwpSkCtSHOiIY+h3nPnYJRe5 Mxo05o+PrAQHdtTID/64XL8ohiuEdRtLE+HhjuDUaw== X-Google-Smtp-Source: AGs4zMZNdMiOY0HFU4rHxd8L6WWEZfDTItAfsAD3Ah3746nQ9P8H820TburgpQU1VRjxC/WNoLkdshTv5HUBHf7EEyA= X-Received: by 10.36.66.209 with SMTP id i200mr5606279itb.102.1512726507059; Fri, 08 Dec 2017 01:48:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.7.36 with HTTP; Fri, 8 Dec 2017 01:48:26 -0800 (PST) From: Praveen Sharma Date: Fri, 8 Dec 2017 15:18:26 +0530 Message-ID: To: acme@ietf.org Content-Type: multipart/alternative; boundary="001a1144b8e0189155055fd116ce" Archived-At: Subject: [Acme] [ACME][QUESTION] Verify Well Formed JWS 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, 08 Dec 2017 09:48:30 -0000 --001a1144b8e0189155055fd116ce Content-Type: text/plain; charset="UTF-8" Hi Devs, How to validate that a JWS is a well-formed JWS? Thanks -- *Praveen Sharma* --001a1144b8e0189155055fd116ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=3D""
Hi Devs,
=
How to validate that a JWS is a well-formed JWS?


Thanks
--
=
Praveen Sharma
--001a1144b8e0189155055fd116ce-- From nobody Fri Dec 8 05:26: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 A2009126C22 for ; Fri, 8 Dec 2017 05:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 cjcNY0YG36MQ for ; Fri, 8 Dec 2017 05:25:57 -0800 (PST) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 22B7B12700F for ; Fri, 8 Dec 2017 05:25:56 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id 68so4686668ite.4 for ; Fri, 08 Dec 2017 05:25:56 -0800 (PST) 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=X9r3TgXj6TuzJiwfJtORX/10StzDsZZG+3Xcr2vntxA=; b=RJ0Nmml43XhM9keJIC/ZAlVVcolqvJAH72aVvE9z434dh3rhur/c5IGj7mb7/HEUte +AYeAEIPFz3vyn6a8UetOfb3TnfdG+uf/O1qz62arDZG85Unf8H+kM2wjco3AZIRpp14 dA+/pf73utt6OduNdzVTpq+rpD4ovffKbOUKQ= 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=X9r3TgXj6TuzJiwfJtORX/10StzDsZZG+3Xcr2vntxA=; b=a8j017CWGhzdvOh3IjQhkHYKyQZohFKw0ncqqSTNQikIjziDB+in6efM2LXIziBTM6 YEfLvJjfNKdtPzVe7AOcj3jLplXOqyubPuXS7NOT0nesvT06Nx2R51nsEtBUL1AtnOQA NbSf0KP7NpYR95F7kgMo93sswAoqQ5F4vLjyHkr2SRImj7RV2/3OqSBh71oWwwYguy2+ SyJLa1nvT0zxxX/dANYM2EqgFwisCst/w+oQAz/Qnyct1ZEcM4C9FFsuJvDCAUMbnXig Be3dBNBTaM38WLmu4SeV+as5nuHyro43f7MyrqSazlWdqJxq0lBd4o2eX99u8aj5Bavl Ch2Q== X-Gm-Message-State: AJaThX77a8dIbvyu1P7Z215g1yxG+Kmdtap0vhBTU0jORYIyL5GnzG0x 9VXIDEWi1j5Kr+Z5YR/3aYjqaE0fVlju3BgvNopJH7q27r0= X-Google-Smtp-Source: AGs4zMbvoE6WIdRFx4hkjfiel8CW8wvZyEzCHg31ZQMPmDcFqOpp1HKbZkQBhQeE0dMsJ4r04q8OWThGgbUXTLeWNYM= X-Received: by 10.107.33.71 with SMTP id h68mr40333935ioh.167.1512739556126; Fri, 08 Dec 2017 05:25:56 -0800 (PST) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.17.28 with HTTP; Fri, 8 Dec 2017 05:25:55 -0800 (PST) In-Reply-To: <0F612577-86CE-4E86-B95C-01C0FF82BDA7@akamai.com> References: <0F612577-86CE-4E86-B95C-01C0FF82BDA7@akamai.com> From: Daniel McCarney Date: Fri, 8 Dec 2017 08:25:55 -0500 Message-ID: To: "Salz, Rich" Cc: IETF ACME Content-Type: multipart/alternative; boundary="001a1140f488e19c50055fd41fb6" Archived-At: Subject: Re: [Acme] Removing OOB Challenge Type 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, 08 Dec 2017 13:26:00 -0000 --001a1140f488e19c50055fd41fb6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Happy Friday folks ;-) Can we move forward with removing the OOB challenge? It seems like there is rough consensus: Clint, Jacob, Andrew and myself all vote for removal. Robert posed one use-case that he thought required OOB challenges but doesn't, and one use-case where they have plans for the future but no concrete implementations. On Thu, Nov 30, 2017 at 11:42 AM, Salz, Rich wrote: > Does anyone disagree with Daniel=E2=80=99s reasoning? If so, please spea= k up > before next Friday. > > > > Daniel, please do not merge this until we determine WG consensus. > --001a1140f488e19c50055fd41fb6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Happy Friday folks ;-)

Can we move forward with rem= oving the OOB challenge? It seems like there is rough consensus:

Cli= nt, Jacob, Andrew and myself all vote for removal. Robert posed one use-cas= e that he thought required OOB challenges but doesn't, and one use-case= where they have plans for the future but no concrete implementations.
<= br>

On Thu, = Nov 30, 2017 at 11:42 AM, Salz, Rich <rsalz@akamai.com> wrote= :

Does anyone disagree with Daniel=E2=80=99s reasoning= ?=C2=A0 If so, please speak up before next Friday.

=C2=A0

Daniel, please do not merge this until we determine = WG consensus.


--001a1140f488e19c50055fd41fb6-- From nobody Fri Dec 8 05:55: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 B5168126C89 for ; Fri, 8 Dec 2017 05:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 hRWStrHcULSU for ; Fri, 8 Dec 2017 05:55:03 -0800 (PST) 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 C4345124D6C for ; Fri, 8 Dec 2017 05:55:03 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vB8Dqmqf017273; Fri, 8 Dec 2017 13:55:01 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=E+cgNrUbp7cMpNM5DmpLZyhlpOl9VOJOr10g0jl7Mzg=; b=EL/DsIUpuVD+eUWRpSOycZC7mxGW2n0MT6bokw0eC+1IQCyGEuQnlECoate8N4pXIFEx eiewOZtZN5FxYj08F0mQQc+EWxx0S7a0k3ff42hG8CADquDo7poa9tUw2e7bmOsZiSYu tLVYkiXJtKPFHsOKfXZdX+1imTe2utRGqAhjIFXH1pabjk0vHBkZOwegnqRJNRFON6gy ljFgUVMiXfLtQhf9BhvBU+cEoJi1DmHEDrcMt2nvrTmIBSeKyRj4gOuCKV3CM6GyJhZd cx1QvThtrtpN7+6RU9AzMya6xvdzgo4giUJsDDQ/zctnUum4HuDJZ0dyz7EUC1pSCB2o 8Q== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2eqn6p90de-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 08 Dec 2017 13:55:01 +0000 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 vB8Dpo75018907; Fri, 8 Dec 2017 08:55:00 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2eqg71t5rk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 08 Dec 2017 08:55:00 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb4.msg.corp.akamai.com (172.27.123.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 8 Dec 2017 05:55:00 -0800 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 8 Dec 2017 08:54:59 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Fri, 8 Dec 2017 08:54:59 -0500 From: "Salz, Rich" To: "cpu@letsencrypt.org" CC: IETF ACME Thread-Topic: [Acme] Removing OOB Challenge Type Thread-Index: AQHTafS8lPPPxlZRcEOAfxnjrU0qI6MtdD0AgAxb0YCAAAgeAA== Date: Fri, 8 Dec 2017 13:54:58 +0000 Message-ID: References: <0F612577-86CE-4E86-B95C-01C0FF82BDA7@akamai.com> In-Reply-To: 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.42.160] Content-Type: multipart/alternative; boundary="_000_D6F9B1EF83D2474DBC02CA6C0F280C27akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-08_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=652 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712080192 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-08_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 mlxscore=0 impostorscore=0 mlxlogscore=588 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712080192 Archived-At: Subject: Re: [Acme] Removing OOB Challenge Type 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, 08 Dec 2017 13:55:06 -0000 --_000_D6F9B1EF83D2474DBC02CA6C0F280C27akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91IGZvciB0aGUgcmVtaW5kZXIuDQoNCkFzIGNoYWlyLCBJIHNheSB0aGF0IHdlIGhh dmUgY29uc2Vuc3VzIHRvIHJlbW92ZSB0aGUgT09CIGNoYWxsZW5nZS4NCg0K --_000_D6F9B1EF83D2474DBC02CA6C0F280C27akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <734BED16D3C5954584FEDC1D221F067D@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1u YW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFuayB5b3UgZm9yIHRoZSByZW1pbmRl ci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgY2hhaXIsIEkgc2F5IHRoYXQgd2UgaGF2ZSBj b25zZW5zdXMgdG8gcmVtb3ZlIHRoZSBPT0IgY2hhbGxlbmdlLjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D6F9B1EF83D2474DBC02CA6C0F280C27akamaicom_-- From nobody Fri Dec 8 09:01: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 8D3CC12895E for ; Fri, 8 Dec 2017 09:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.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_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 GZHljXhG65ke for ; Fri, 8 Dec 2017 09:01:49 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 600651288A9 for ; Fri, 8 Dec 2017 09:01:49 -0800 (PST) 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=tkXqIJOpOfC7CdB2mKqAVvJIIemjo+YK4M/YeU4Y72A=; b=NBVAFU+ARN5pOJG29AonuhmvlSiAGDpqKNlqzNfy/GlEOuhBn4WKsqcBjSGRN85gZdPwybvsJKa/k27s3D6ycYIHThF1bCLtgfgx8DMa3cILayEtMMOHuBdH1+giNszzSukHdNF+KFGgypV649MoQ+An8+Gm1jucWSPaJY2XTKs=; Received: ; Fri, 08 Dec 2017 09:01:44 -0800 To: Praveen Sharma , acme@ietf.org References: From: Jacob Hoffman-Andrews Message-ID: <634f4c72-5682-a54b-4737-1358099e048d@eff.org> Date: Fri, 8 Dec 2017 09:01:47 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Acme] [ACME][QUESTION] JWS Signature Verification Using JWK 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, 08 Dec 2017 17:01:51 -0000 I think the answers to both of your questions will be found in the JWK and JWS RFCs: https://tools.ietf.org/html/rfc7517 https://tools.ietf.org/html/rfc7515 If you're looking for additional examples, you can look at the Boulder source code: https://github.com/letsencrypt/boulder/, or a variety of JOSE / JWS libraries available in the wild. From nobody Thu Dec 14 06:14:04 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 1D47D1201F2; Thu, 14 Dec 2017 06:14:02 -0800 (PST) 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.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151326084207.6071.15107283698966377699@ietfa.amsl.com> Date: Thu, 14 Dec 2017 06:14:02 -0800 Archived-At: Subject: [Acme] I-D Action: draft-ietf-acme-acme-09.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: Thu, 14 Dec 2017 14:14:02 -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 Daniel McCarney James Kasten Filename : draft-ietf-acme-acme-09.txt Pages : 80 Date : 2017-12-14 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. RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for this draft is maintained in GitHub. Suggested changes should be submitted as pull requests at https://github.com/ietf-wg-acme/acme [1]. Instructions are on that page as well. Editorial changes can be managed in GitHub, but any substantive change should be discussed on the ACME mailing list (acme@ietf.org). 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-09 https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 14 06:16:58 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F731200CF for ; Thu, 14 Dec 2017 06:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable 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 opcwiRTh6Qfx for ; Thu, 14 Dec 2017 06:16:51 -0800 (PST) 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 48DCB12420B for ; Thu, 14 Dec 2017 06:16:51 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id t8so11576852wmc.3 for ; Thu, 14 Dec 2017 06:16:51 -0800 (PST) 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=/D2QfdhHrCMpXJLtqYslNMkqIdDyDHGnuV40+xCFmHc=; b=EVtK2J8lxM5DVwzyrGnhkpL2bAeiNw2/APcoQ1g8OJ5gcMIIVOIUDDCEkSd0aO3Jtd dQ/3qj0dCY/n01FF0uKD8u7tcP/e1+r0Dqvn9aZ0SNufdJFBQpqxkgpditeXsAwGQAah FayVTh/ce5ITQmTpp4+EuHiPyO+LEBVTJ/ABaBGHr9tXKnWpd7VTNUk3KXfQL7EORZhj 2cas9Pj0maPOMdE+j2oA6glAFMjUSiT8TFedN5YcXqSlKmdNvwiyjrk7+CVn9NKiE0+b IIBNBho+nhrpQh6eIcS5uTR5O9C3FDAvUqmysYJIOBIib6l+jMyZZpY4AhsnztcsQ/MK Jt0w== 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=/D2QfdhHrCMpXJLtqYslNMkqIdDyDHGnuV40+xCFmHc=; b=OSHUi50DMdV3hGXZhkNs1EtroUnGcQ5/N6ynwpcFNA//+cVbsKdd7/Dco9fGZMgW4E Si81kI1SW8uNJNnZD+VKHEahQFs5tiev8W9pB6zr8E0/g1x57Zk2p3hkyztqCfKDpm3M 3J4jfEbiGK2MO9z+PPzEBWIYYUfpvfQiV91c5K+VJOYTDx3fZqekSasz1+BjfviuNJDW 0UTNor4fSOO0yCXi3ZIgYvpyrdOLWk0wnqU2kbM8sQPFLSJU4vfWgEl0V0Enp3ncUZx5 P/thKiBVL6cCz02rmjMEXxJLlzEamKP7TekPNcyv/YVp2rhxSmzf6fmJaigLYKP2x2XM mRmg== X-Gm-Message-State: AKGB3mKbSt4JRUaex45664lebHwVThKoGDiS+H6SZaM/8zw3duxaOmzU d/wCCEZ8+9wectdu7CpKypTDYx8EjAZUUNkYKLzh/A+l4aY= X-Google-Smtp-Source: ACJfBoutbsOI5vA1OT76IYPfTODhCnnOWtMZSDK/WMZ+cTby+AKDVi9wt5mfddPUpXtut6JkZSvS0kFNUCslG5J0l9s= X-Received: by 10.28.45.193 with SMTP id t184mr2563126wmt.140.1513261009532; Thu, 14 Dec 2017 06:16:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.167.74 with HTTP; Thu, 14 Dec 2017 06:16:48 -0800 (PST) In-Reply-To: <151326084207.6071.15107283698966377699@ietfa.amsl.com> References: <151326084207.6071.15107283698966377699@ietfa.amsl.com> From: Richard Barnes Date: Thu, 14 Dec 2017 09:16:48 -0500 Message-ID: To: internet-drafts@ietf.org Cc: i-d-announce@ietf.org, "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a11422b5aed193805604d88e2" Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-acme-09.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 14:16:55 -0000 --001a11422b5aed193805604d88e2 Content-Type: text/plain; charset="UTF-8" For reference, this version incorporates several PRs that we got finished since the last IETF meeting, listed below. One I would like to note in particular is that we added Daniel McCarney as a co-author in recognition of the role he's already been playing, contributing a lot of text and reviews. Thanks, Daniel! Now you're signed up to help address IESG review comments :) Chairs: I think this version is ready to go back into WGLC / IESG processing. --Richard WIP: Further AD review responses (#348) Removed "tel" URIs from the examples (#353) Remove proactive issuance & csr-first new-order. (#342) Remove optional "scope" field from authorization objects. (#349) Define sub-problems. (#354) Use consistent example URLs. (#352) Remove incorrect "instance" usage. (#355) List feedback (#357) Responses to Gen-ART review (#358) Fix detail key in sub-problems (#361) Remove obsolete mention of authz reuse in pre-auth flow. (#365) Ignore `.targets.mk`. (#366) Remove the Out-of-Band (OOB) Challenge type. (#360) Add order finalization examples, fix new-order examples. (#367) Clarify external-account requirements (#359) Add a registry to track 'meta' fields (#369) Unifies to all object keys in camelCase (#362) Add Daniel McCarney as co-author (#370) On Thu, Dec 14, 2017 at 9:14 AM, 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 > Daniel McCarney > James Kasten > Filename : draft-ietf-acme-acme-09.txt > Pages : 80 > Date : 2017-12-14 > > 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. > > RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for > this draft is maintained in GitHub. Suggested changes should be > submitted as pull requests at https://github.com/ietf-wg-acme/acme > [1]. Instructions are on that page as well. Editorial changes can > be managed in GitHub, but any substantive change should be discussed > on the ACME mailing list (acme@ietf.org). > > > 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-09 > https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-09 > > > 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 > --001a11422b5aed193805604d88e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For reference, this version incorporates several PRs = that we got finished since the last IETF meeting, listed below.=C2=A0 One I= would like to note in particular is that we added Daniel McCarney as a co-= author in recognition of the role he's already been playing, contributi= ng a lot of text and reviews.=C2=A0 Thanks, Daniel!=C2=A0 Now you're si= gned up to help address IESG review comments :)

Chairs: I think this version is ready to go back into WGLC / IESG process= ing.

--Richard

WIP: F= urther AD review responses (#348)
Removed "tel" URIs from the= examples (#353)
Remove proactive issuance & csr-first new-order. (#= 342)
Remove optional "scope" field from authorization objects.= (#349)
Define sub-problems. (#354)
Use consistent example URLs. (#35= 2)
Remove incorrect "instance" usage. (#355)
List feedback = (#357)
Responses to Gen-ART review (#358)
Fix detail key in sub-prob= lems (#361)
Remove obsolete mention of authz reuse in pre-auth flow. (#3= 65)
Ignore `.targets.mk`. (#366)
= Remove the Out-of-Band (OOB) Challenge type. (#360)
Add order finalizat= ion examples, fix new-order examples. (#367)
Clarify external-account re= quirements (#359)
Add a registry to track 'meta' fields (#369) =
Unifies to all object keys in camelCase (#362)
Add Daniel McCarney a= s co-author (#370)


On Thu, Dec 14, 2017 at 9:14 AM, &l= t;internet-dr= afts@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 Daniel McCarney
=C2=A0 =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-09.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 80
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-12-14

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.

=C2=A0 =C2=A0RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source = for
=C2=A0 =C2=A0this draft is maintained in GitHub.=C2=A0 Suggested changes sh= ould be
=C2=A0 =C2=A0submitted as pull requests at https://github.com/ie= tf-wg-acme/acme
=C2=A0 =C2=A0[1].=C2=A0 Instructions are on that page as well.=C2=A0 Editor= ial changes can
=C2=A0 =C2=A0be managed in GitHub, but any substantive change should be dis= cussed
=C2=A0 =C2=A0on the ACME mailing list (acm= e@ietf.org).


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

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


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

--001a11422b5aed193805604d88e2-- From nobody Thu Dec 14 09:29: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 0F7311293DA for ; Thu, 14 Dec 2017 09:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pappooAsKiFg for ; Thu, 14 Dec 2017 09:29:04 -0800 (PST) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9854C127871 for ; Thu, 14 Dec 2017 09:29:03 -0800 (PST) Received: by mail-wr0-x22f.google.com with SMTP id g53so5830841wra.2 for ; Thu, 14 Dec 2017 09:29:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:references:to:date; bh=gw/lSvMecljdE6gvkxs2Fz6hyJe2Na19LEkPaGYLQdA=; b=DESV/G7UDBNU/PvXmnYnUafueK2QaH1er9RKas12g5McrNXj+UfdncysBQs4dv9J+O db9R8ZiYp5OGk/CdrxQyelb9ynzBztsT3mcrU5nXDwfWcYkovy+s1UnzXM17m6oJG1DC 3TSf1XeZtbyW0GdhPJj3brdPRGqYtsnW70wDxwFFsp2gFFlxY6pHG/P5EULF7aZwt93I 1Zz14CFgLJl+IZ6WpT5ww4VQMRRNl2aK045Gf/68ZXGmA6ZSAOM/JBZk/ifrdpHJXYRa H2fgYJGnSBILJMRVBHWhhbXnxdS9S38icnYyTbXnmqoqzA3GN9m+h2I/Wf1do9wfS5u6 z15g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=gw/lSvMecljdE6gvkxs2Fz6hyJe2Na19LEkPaGYLQdA=; b=SDdvhHaLwmjhRujohCxYKsdkfQ98FnJTOTZULPqCJLQMUwNVQUBs564aKqXyc4Ntf2 a4i2ONi2r6EOaQNjZd9ebcPTqzOC3cGjfKxYA4fKGfDayqPzKWEa8ZGBGJeXk2vksXiq x3DWgSwG33vxsbMbyz8BUaQQD0wUH0GG2acYDbPZZdIFsfJY2w6mmdLFnC/bKsA8/3lM e03jL9g3InNEuckrpbsnHeUxFqYaypLjO7IC1Uz3JjCnCCwiv1gO1yD02wgBy92XxIMd knz951Kar320umihIIo29aHqgAHfiTmuDuVAeUUT78rEtj1S0Sp9YwjjYo2MjjpAr4eu vKcA== X-Gm-Message-State: AKGB3mJopoksGUfqYExrvxUjXFVRRgAU7tK+2F4amr7GOXYNFaXMsAFn qIaQe9APWFlPwtxl9OI/lh677Roh X-Google-Smtp-Source: ACJfBov516zzRQUYl3vuXceLvO0+NKZ+wTJN7f7tUP7e+sWV/ybNyW7rHcHO1BcjWmaBhokt+D8bjg== X-Received: by 10.223.164.22 with SMTP id d22mr7261344wra.232.1513272541986; Thu, 14 Dec 2017 09:29:01 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id k30sm4888588wrf.63.2017.12.14.09.29.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Dec 2017 09:29:01 -0800 (PST) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_E182C38E-2410-418D-AF16-B8715FBD634B" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <7B7A3807-500F-4C8A-859A-3A7CB5B5FB6D@gmail.com> References: <151326084207.6071.15107283698966377699@ietfa.amsl.com> To: IETF ACME Date: Thu, 14 Dec 2017 19:28:59 +0200 X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [Acme] YA WGLC for 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, 14 Dec 2017 17:29:06 -0000 --Apple-Mail=_E182C38E-2410-418D-AF16-B8715FBD634B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Draft-09 is now available and has (IMO) addressed all or the outstanding = issues. This starts an abbreviated WGLC for this draft. Please review the draft = and send in your comments by EOD Monday the 25th. Please note that = Monday the 25th is Christmas day, so don=E2=80=99t delay - send in your = comments sooner rather than later. If all goes well, we can go to IETF LC in early January and have this in = the RFC Editor queue before the London meeting. Yoav > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: [Acme] I-D Action: draft-ietf-acme-acme-09.txt > Date: 14 December 2017 at 16:14:02 GMT+2 > To: > Cc: acme@ietf.org >=20 >=20 > 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. >=20 > Title : Automatic Certificate Management Environment = (ACME) > Authors : Richard Barnes > Jacob Hoffman-Andrews > Daniel McCarney > James Kasten > Filename : draft-ietf-acme-acme-09.txt > Pages : 80 > Date : 2017-12-14 >=20 > 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. >=20 > RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for > this draft is maintained in GitHub. Suggested changes should be > submitted as pull requests at https://github.com/ietf-wg-acme/acme > [1]. Instructions are on that page as well. Editorial changes can > be managed in GitHub, but any substantive change should be discussed > on the ACME mailing list (acme@ietf.org). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-acme-acme-09 > https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-09 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-acme-acme-09 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme --Apple-Mail=_E182C38E-2410-418D-AF16-B8715FBD634B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi

Draft-09= is now available and has (IMO) addressed all or the outstanding = issues.

This = starts an abbreviated WGLC for this draft. Please review the draft and = send in your comments by EOD Monday the 25th. Please note that Monday = the 25th is Christmas day, so don=E2=80=99t delay - send in your = comments sooner rather than later.

If all goes well, we can go to IETF LC = in early January and have this in the RFC Editor queue before the London = meeting.

Yoav

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = [Acme] I-D = Action: draft-ietf-acme-acme-09.txt
Date: = 14 December 2017 at 16:14:02 = GMT+2
To: = <i-d-announce@ietf.org>
Cc: acme@ietf.org


A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Automated = Certificate Management Environment WG of the IETF.

       Title =           : Automatic = Certificate Management Environment (ACME)
=        Authors =         : Richard Barnes
=             &n= bsp;           &nbs= p;Jacob Hoffman-Andrews
=             &n= bsp;           &nbs= p;Daniel McCarney
=             &n= bsp;           &nbs= p;James Kasten
Filename =        : = draft-ietf-acme-acme-09.txt
Pages =           : 80
= Date =            : = 2017-12-14

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.

  RFC = EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for
  this draft is maintained in GitHub. =  Suggested changes should be
  submitted = as pull requests at https://github.com/ietf-wg-acme/acme
=   [1].  Instructions are on that page as well. =  Editorial changes can
  be managed in = GitHub, but any substantive change should be discussed
=   on the ACME mailing list (acme@ietf.org).


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-09
https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-09
A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-acme-acme-09


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

= --Apple-Mail=_E182C38E-2410-418D-AF16-B8715FBD634B-- From nobody Thu Dec 14 11:08: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 0DF7F129443 for ; Thu, 14 Dec 2017 11:08:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hemio.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T_Lb7wjNPbq6 for ; Thu, 14 Dec 2017 11:08:39 -0800 (PST) Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12C071200C1 for ; Thu, 14 Dec 2017 11:08:39 -0800 (PST) Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id 91A169E for ; Thu, 14 Dec 2017 20:08:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hemio.de; s=20170414; t=1513278517; bh=sIVvrhPQoTe4sY7hwEs06xiQf8TSvV0j6/o3bpK1iS0=; h=From:Subject:To:Date:From; b=OlzJjBoE3vmFoABTG/5Hxm401D+F2CFSqV/z4NgCPGJdHfFwx0DOmxQBE5Y4QffST 1N6xqo0ER3Y0fxB/iQwrRpZyi7MJTXE0LHXKcJMTVW6bKrHWZ4jMPpgYyEFzoRU14F K+AlCccpz43Q6nh+oGjEostOhZ1vitujsLGJR8UVJdRk8v66IRJAr1vtGmZknHpqp4 6Sx9ruxhvE5wpbBg3ukPdmHUEgORq63/d+pf+oygwnSwFJmN1Z8csUcIBINqSL5QgE /gRX2s0POUP3I2V9fIOPkdSlTnAT5PmXlqrO13fNz2Bdyxm4suzcQHUWFUp6BgJrbq 2TDiy5TPKs6Rg== From: Sophie Herold To: IETF ACME Message-ID: <0347d7f8-dc62-921f-b3e4-eb303b390e74@hemio.de> Date: Thu, 14 Dec 2017 20:08:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [Acme] 7.1. Resources "typical sequence of requests" 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, 14 Dec 2017 19:08:41 -0000 Hi, I think there are two "mistakes" in this example: | Action | Request | Response | |:---------------------|:--------------------|:----------------| | Get a nonce | HEAD newNonce | 204 | | Create account | POST newAccount | 201 -> account | | Submit an order | POST newOrder | 201 -> order | | Fetch challenges | GET authz | 200 | | Respond to challenge | POST challenge | 200 | | Finalize order | POST order finalize | 200 | | Poll for status | GET authz | 200 | | Check for new cert | GET cert | 200 | 1. "Poll for status" should not be "GET authz" but "GET order". Only if the order is "pending" or "invalid", authz are of interest. 2. "Check for new cert": There is nothing to check here. To avoid unnecessary confusion, I suggest that the table could look something like this: | Action | Request | Response | |:---------------------|:-------------------------|:---------------| | Get directory | GET directory | 200 | | Get nonce | HEAD newNonce | 204 | | Create account | POST newAccount | 201 -> account | | Submit order | POST newOrder | 201 -> order | | Fetch challenges | GET order authorization | 200 | | Respond to challenge | POST challenge url | 200 | | Finalize order | POST order finalize | 200 | | Poll for status | GET order | 200 | | Download certificate | GET order cert | 200 | Also the diagram seems to have a few issues: 1. new-nonce should be newNonce (my fault) 2. should "finalize" appear somewhere? maybe like this? order -----> finalize -----> cert 3. I think "authz" could be called authorization here Best, Sophie From nobody Fri Dec 15 07:24: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 BCFD4128D3E for ; Fri, 15 Dec 2017 07:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 kIEPPW8UnBaW for ; Fri, 15 Dec 2017 07:24:07 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4001D1201F2 for ; Fri, 15 Dec 2017 07:24:07 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id m11so29977117iti.1 for ; Fri, 15 Dec 2017 07:24:07 -0800 (PST) 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=gBgPYrSHiD0UEv29YASIgt5pH5bS81cEm3hhm2KDLjg=; b=XVp+/NjMS9D+s1O2wF091jMSGJdKqmsKpr3MrMHHO9Pw4lbYupHZdp2ME7WJ9bIMzU Hbn1NQD1e6uw1TPu6dfuMXTjexaFEdsYlLY/YKT0TvON3JapxSUuqMu4W8lW5UFrOeDt b9e8f83c7wOknZyf0hNoAuB/tGZHL/d6nW+Dc= 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=gBgPYrSHiD0UEv29YASIgt5pH5bS81cEm3hhm2KDLjg=; b=lgXUBBAWzxJRTjhPHMWonkp+TO+Skeo3WIiFK2kYAo1mtGmyL1rXxLkhpMBijM8s+l fZ1ehzINzryLXUGu7OqDRmZGBZ6O/Qlxsqfkto0cVXO2eUvUFDWRATahGU6OmfWiR90m by3WPv1+6Utk7S3C0yBuZjDuqwEu5SGuwMW9swzp/Y4naYYneiOzNRyaru3hFVDzj4OF 4PR+kHLgfxzuDBapkOBqhXMbbrHx0KrwXHeJv7VDT0Djr5Ukefk6wFmq4CcM6MHMT49F m2TYzdkzV0i5UVQREJk0kGthqrG2xjcn+xwhlqc7yfvFlh9FTrtnlGRV3HFTrU6ncqsY qCRw== X-Gm-Message-State: AKGB3mKkZGl01zdBh47CjAUJgTx9GhxRzHEPcbiAGaOL/yTaYtI+yWVb LHL2uraLnUmE1r4SNp4ppmbAWVITwoL1xOtxX6MuPLxxcWw= X-Google-Smtp-Source: ACJfBot9UfTy490g6VEnnJrCyalyO3LySDmrfy+bRUEK7hrP30WVuGiaohJxZr3aLVQueWI/lzVYQkE5kMYLxT2PSTA= X-Received: by 10.36.192.2 with SMTP id u2mr8490300itf.119.1513351446401; Fri, 15 Dec 2017 07:24:06 -0800 (PST) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.22.2 with HTTP; Fri, 15 Dec 2017 07:24:05 -0800 (PST) In-Reply-To: <0347d7f8-dc62-921f-b3e4-eb303b390e74@hemio.de> References: <0347d7f8-dc62-921f-b3e4-eb303b390e74@hemio.de> From: Daniel McCarney Date: Fri, 15 Dec 2017 10:24:05 -0500 Message-ID: To: Sophie Herold Cc: IETF ACME Content-Type: multipart/alternative; boundary="94eb2c05b8ce622dbf0560629730" Archived-At: Subject: Re: [Acme] 7.1. Resources "typical sequence of requests" 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, 15 Dec 2017 15:24:10 -0000 --94eb2c05b8ce622dbf0560629730 Content-Type: text/plain; charset="UTF-8" > > Hi Sophie, I think there are two "mistakes" in this example: Agreed on both mistakes. Thanks for flagging! To avoid unnecessary confusion, I suggest that the table could look something > like this: I like your proposed fixes. I think the only change I'd request is that I think the "Fetch challenges" action should have a plural request stage "GET order authorization*s*". Similarly the "Respond to challenge" action should be plural ("Respond to challenge*s*") and should have a plural request "POST challenge url*s*". I think that will emphasize that there can be multiple authorizations in one order and multiple challenges in one authorization. Also the diagram seems to have a few issues: Agreed that we should capture the finalization step here & remove the "new-nonce"/"authz" inconsistencies. Sophie: Do you want to submit a PR implementing these changes? Thanks again! On Thu, Dec 14, 2017 at 2:08 PM, Sophie Herold wrote: > Hi, > > I think there are two "mistakes" in this example: > > | Action | Request | Response | > |:---------------------|:--------------------|:----------------| > | Get a nonce | HEAD newNonce | 204 | > | Create account | POST newAccount | 201 -> account | > | Submit an order | POST newOrder | 201 -> order | > | Fetch challenges | GET authz | 200 | > | Respond to challenge | POST challenge | 200 | > | Finalize order | POST order finalize | 200 | > | Poll for status | GET authz | 200 | > | Check for new cert | GET cert | 200 | > > 1. "Poll for status" should not be "GET authz" but "GET order". > Only if the order is "pending" or "invalid", authz are of interest. > 2. "Check for new cert": There is nothing to check here. > > > To avoid unnecessary confusion, I suggest that the table could look > something like this: > > | Action | Request | Response | > |:---------------------|:-------------------------|:---------------| > | Get directory | GET directory | 200 | > | Get nonce | HEAD newNonce | 204 | > | Create account | POST newAccount | 201 -> account | > | Submit order | POST newOrder | 201 -> order | > | Fetch challenges | GET order authorization | 200 | > | Respond to challenge | POST challenge url | 200 | > | Finalize order | POST order finalize | 200 | > | Poll for status | GET order | 200 | > | Download certificate | GET order cert | 200 | > > > Also the diagram seems to have a few issues: > > 1. new-nonce should be newNonce (my fault) > 2. should "finalize" appear somewhere? maybe like this? > order -----> finalize > -----> cert > 3. I think "authz" could be called authorization here > > Best, > Sophie > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --94eb2c05b8ce622dbf0560629730 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Sophie,

=C2=A0I think there are two "mista= kes" in this example:

Agreed on both mist= akes. Thanks for flagging!

To avoid unnecessary confusion,= I suggest that the table could look=C2=A0something like this:

I like your propose= d fixes. I think the only change I'd request is that I think the "= Fetch challenges" action should have a plural request stage "GET = order authorizations". Similarly the "Respond to challenge= " action should be plural ("Respond to challenges") a= nd should have a plural request "POST challenge urls". I t= hink that will emphasize that there can be multiple authorizations in one o= rder and multiple challenges in one authorization.

Also the = diagram seems to have a few issues:

Agreed tha= t we should capture the finalization step here & remove the "new-n= once"/"authz" inconsistencies.

Sophie: Do you want to= submit a PR implementing these changes?

Thanks again!

=

On Thu, Dec 14, 2= 017 at 2:08 PM, Sophie Herold <sophie_herold@hemio.de> = wrote:
Hi,

I think there are two "mistakes" in this example:

| Action=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Request=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Response=C2=A0 =C2=A0 =C2=A0= =C2=A0 |
|:---------------------|:--------------------|:----------------|<= br> | Get a nonce=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | HEAD newNonce=C2=A0 =C2= =A0 =C2=A0 =C2=A0| 204=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
| Create account=C2=A0 =C2=A0 =C2=A0 =C2=A0| POST newAccount=C2=A0 =C2=A0 = =C2=A0| 201 -> account=C2=A0 |
| Submit an order=C2=A0 =C2=A0 =C2=A0 | POST newOrder=C2=A0 =C2=A0 =C2=A0 = =C2=A0| 201 -> order=C2=A0 =C2=A0 |
| Fetch challenges=C2=A0 =C2=A0 =C2=A0| GET=C2=A0 authz=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 | 200=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
| Respond to challenge | POST challenge=C2=A0 =C2=A0 =C2=A0 | 200=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
| Finalize order=C2=A0 =C2=A0 =C2=A0 =C2=A0| POST order finalize | 200=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
| Poll for status=C2=A0 =C2=A0 =C2=A0 | GET=C2=A0 authz=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 | 200=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
| Check for new cert=C2=A0 =C2=A0| GET=C2=A0 cert=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| 200=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

1. "Poll for status" should not be "GET authz" but &quo= t;GET order".
=C2=A0 =C2=A0Only if the order is "pending" or "invalid"= ;, authz are of interest.
2. "Check for new cert": There is nothing to check here.


To avoid unnecessary confusion, I suggest that the table could look
something like this:

| Action=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Request=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Response=C2= =A0 =C2=A0 =C2=A0 =C2=A0|
|:---------------------|:-------------------------|:-------------= --|
| Get directory=C2=A0 =C2=A0 =C2=A0 =C2=A0 | GET=C2=A0 directory=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 200=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
| Get nonce=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | HEAD newNonce=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 204=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
| Create account=C2=A0 =C2=A0 =C2=A0 =C2=A0| POST newAccount=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | 201 -> account |
| Submit order=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| POST newOrder=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 201 -> order=C2=A0 =C2=A0|
| Fetch challenges=C2=A0 =C2=A0 =C2=A0| GET=C2=A0 order authorization | 200= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
| Respond to challenge | POST challenge url=C2=A0 =C2=A0 =C2=A0 =C2=A0| 200= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
| Finalize order=C2=A0 =C2=A0 =C2=A0 =C2=A0| POST order finalize=C2=A0 =C2= =A0 =C2=A0 | 200=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
| Poll for status=C2=A0 =C2=A0 =C2=A0 | GET=C2=A0 order=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 200=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
| Download certificate | GET=C2=A0 order cert=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | 200=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |


Also the diagram seems to have a few issues:

1. new-nonce should be newNonce (my fault)
2. should "finalize" appear somewhere? maybe like this?
=C2=A0 =C2=A0 order -----> finalize
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -----> cert
3. I think "authz" could be called authorization here

Best,
Sophie

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

--94eb2c05b8ce622dbf0560629730-- From nobody Fri Dec 15 07:28: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 5D3D9128D3E for ; Fri, 15 Dec 2017 07:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oLbpPd94zkui for ; Fri, 15 Dec 2017 07:28:03 -0800 (PST) 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 6FBFD124205 for ; Fri, 15 Dec 2017 07:28:03 -0800 (PST) Received: by mail-wr0-x233.google.com with SMTP id z34so8350844wrz.10 for ; Fri, 15 Dec 2017 07:28:03 -0800 (PST) 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=X4BA6tksuqmRuUbjKdIG7NznNrBZh8Ne3fM7G4gCm8c=; b=roICtdl0t3FUMXAcWZymUlIZ1CtJsqbFeWuphFRsBUZiYSRK+rDIWdHQdcId9V7Mpn 24+5YZRxYV+zWoO/shsddnqWMIqtBikKMNWKhBXQmWcmrcD4f74v+BvHSSu1dBiH7Ojn Gj4hPn9I47wH2OBSJKS4sbM2NSe4R4WIDxbrRUlQIQFWoHsA242F2pvX/5J62ujHi+kS j3sEuZKZt4mGW/N2kYHNVIqLkFwVF9DmXZbKGU/WvcRUwYmoYXOa0ehk3vfiuX7U1Tx5 Fs9V172y0Wr28BuQKGIHATswEscPu5QqE8B4D4yw6t/9vOW8eRS+O8v767o6OdXAOlPK BSig== 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=X4BA6tksuqmRuUbjKdIG7NznNrBZh8Ne3fM7G4gCm8c=; b=GSEytJ4aPdpJ67zO80iTl6KFZuOZLLOEJCnJcp1a3h+v2+9jNHkD/WiY0N2fK5+08C x2yulRtPloO+RYUnTgtlQLjItTi+DgN+0OmdPmyIXXrEkyUHUnxmUiAFZ4DQV5ETRpN2 0SWGAKzsSRFrXDnpIUKln3dQnB5MorCPVVYSLQaMEXx1rp894hqLYXiIWhsV9J3DKlIG YXHkMMHeZO0BwICGNupBjyi9y3Is6Pb+qczSIpYGpBypByIVFzloSIJevC4u91clEEw6 I8jxJxxqF9VJyJSpAjL1U5GWPC4pMTJm+5AfceBdeL4Wk3AlQUNelKrUD1euKVUJ596x MLSg== X-Gm-Message-State: AKGB3mJruQn2ST9PLdcbrT+4KYxW36Bui977/d+8oPB/1txBQ3CasR3f YJkWPtzl6CBz6ywjtfms8RnBX38ENOOjqplwk1lYO06V X-Google-Smtp-Source: ACJfBouJdf1mo3LX1eORRHIVYJA/h2FGEFJPaSCLKSMsGpSejjj74hpkbMxh7pdccyJKuGkgZjTGuNnn/OgxIVb/CE0= X-Received: by 10.223.157.137 with SMTP id p9mr10016543wre.92.1513351681722; Fri, 15 Dec 2017 07:28:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.167.74 with HTTP; Fri, 15 Dec 2017 07:28:01 -0800 (PST) In-Reply-To: References: <0347d7f8-dc62-921f-b3e4-eb303b390e74@hemio.de> From: Richard Barnes Date: Fri, 15 Dec 2017 10:28:01 -0500 Message-ID: To: Daniel McCarney Cc: Sophie Herold , IETF ACME Content-Type: multipart/alternative; boundary="f403043a279468ddfa056062a580" Archived-At: Subject: Re: [Acme] 7.1. Resources "typical sequence of requests" 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, 15 Dec 2017 15:28:06 -0000 --f403043a279468ddfa056062a580 Content-Type: text/plain; charset="UTF-8" +1 On Fri, Dec 15, 2017 at 10:24 AM, Daniel McCarney wrote: > Hi Sophie, > > I think there are two "mistakes" in this example: > > > Agreed on both mistakes. Thanks for flagging! > > To avoid unnecessary confusion, I suggest that the table could look something >> like this: > > > I like your proposed fixes. I think the only change I'd request is that I > think the "Fetch challenges" action should have a plural request stage "GET > order authorization*s*". Similarly the "Respond to challenge" action > should be plural ("Respond to challenge*s*") and should have a plural > request "POST challenge url*s*". I think that will emphasize that there > can be multiple authorizations in one order and multiple challenges in one > authorization. > > Also the diagram seems to have a few issues: > > > Agreed that we should capture the finalization step here & remove the > "new-nonce"/"authz" inconsistencies. > > Sophie: Do you want to submit a PR implementing these changes? > > Thanks again! > > > On Thu, Dec 14, 2017 at 2:08 PM, Sophie Herold > wrote: > >> Hi, >> >> I think there are two "mistakes" in this example: >> >> | Action | Request | Response | >> |:---------------------|:--------------------|:----------------| >> | Get a nonce | HEAD newNonce | 204 | >> | Create account | POST newAccount | 201 -> account | >> | Submit an order | POST newOrder | 201 -> order | >> | Fetch challenges | GET authz | 200 | >> | Respond to challenge | POST challenge | 200 | >> | Finalize order | POST order finalize | 200 | >> | Poll for status | GET authz | 200 | >> | Check for new cert | GET cert | 200 | >> >> 1. "Poll for status" should not be "GET authz" but "GET order". >> Only if the order is "pending" or "invalid", authz are of interest. >> 2. "Check for new cert": There is nothing to check here. >> >> >> To avoid unnecessary confusion, I suggest that the table could look >> something like this: >> >> | Action | Request | Response | >> |:---------------------|:-------------------------|:---------------| >> | Get directory | GET directory | 200 | >> | Get nonce | HEAD newNonce | 204 | >> | Create account | POST newAccount | 201 -> account | >> | Submit order | POST newOrder | 201 -> order | >> | Fetch challenges | GET order authorization | 200 | >> | Respond to challenge | POST challenge url | 200 | >> | Finalize order | POST order finalize | 200 | >> | Poll for status | GET order | 200 | >> | Download certificate | GET order cert | 200 | >> >> >> Also the diagram seems to have a few issues: >> >> 1. new-nonce should be newNonce (my fault) >> 2. should "finalize" appear somewhere? maybe like this? >> order -----> finalize >> -----> cert >> 3. I think "authz" could be called authorization here >> >> Best, >> Sophie >> >> _______________________________________________ >> 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 > > --f403043a279468ddfa056062a580 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

On Fri, Dec 15, 2017 at 10:24 AM, Daniel McCarney <cpu@letse= ncrypt.org> wrote:
Hi Sophie,

=C2=A0I think there are two &q= uot;mistakes" in this example:

Agr= eed on both mistakes. Thanks for flagging!

= To avoid unnecessary confusion, I suggest that the table could look=C2=A0something like this:

I like your proposed fixes. I think the only change I= 9;d request is that I think the "Fetch challenges" action should = have a plural request stage "GET order authorizations". Si= milarly the "Respond to challenge" action should be plural ("= ;Respond to challenges") and should have a plural request "= ;POST challenge urls". I think that will emphasize that there c= an be multiple authorizations in one order and multiple challenges in one a= uthorization.

Also the diagram seems to hav= e a few issues:

Agreed that we should c= apture the finalization step here & remove the "new-nonce"/&q= uot;authz" inconsistencies.

Sophie: Do you want to submit a PR = implementing these changes?

Thanks again!


On Thu, Dec 14, 2017 at 2:08 PM, Sophie Herold = <sophie_hero= ld@hemio.de> wrote:
Hi,

I think there are two "mistakes" in this example:

| Action=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Request=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Response=C2=A0 =C2=A0 =C2=A0= =C2=A0 |
|:---------------------|:--------------------|:----------------|<= br> | Get a nonce=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | HEAD newNonce=C2=A0 =C2= =A0 =C2=A0 =C2=A0| 204=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
| Create account=C2=A0 =C2=A0 =C2=A0 =C2=A0| POST newAccount=C2=A0 =C2=A0 = =C2=A0| 201 -> account=C2=A0 |
| Submit an order=C2=A0 =C2=A0 =C2=A0 | POST newOrder=C2=A0 =C2=A0 =C2=A0 = =C2=A0| 201 -> order=C2=A0 =C2=A0 |
| Fetch challenges=C2=A0 =C2=A0 =C2=A0| GET=C2=A0 authz=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 | 200=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
| Respond to challenge | POST challenge=C2=A0 =C2=A0 =C2=A0 | 200=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
| Finalize order=C2=A0 =C2=A0 =C2=A0 =C2=A0| POST order finalize | 200=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
| Poll for status=C2=A0 =C2=A0 =C2=A0 | GET=C2=A0 authz=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 | 200=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
| Check for new cert=C2=A0 =C2=A0| GET=C2=A0 cert=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0| 200=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

1. "Poll for status" should not be "GET authz" but &quo= t;GET order".
=C2=A0 =C2=A0Only if the order is "pending" or "invalid"= ;, authz are of interest.
2. "Check for new cert": There is nothing to check here.


To avoid unnecessary confusion, I suggest that the table could look
something like this:

| Action=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Request=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Response=C2= =A0 =C2=A0 =C2=A0 =C2=A0|
|:---------------------|:-------------------------|:-------------= --|
| Get directory=C2=A0 =C2=A0 =C2=A0 =C2=A0 | GET=C2=A0 directory=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 200=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
| Get nonce=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | HEAD newNonce=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 204=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
| Create account=C2=A0 =C2=A0 =C2=A0 =C2=A0| POST newAccount=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | 201 -> account |
| Submit order=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| POST newOrder=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 201 -> order=C2=A0 =C2=A0|
| Fetch challenges=C2=A0 =C2=A0 =C2=A0| GET=C2=A0 order authorization | 200= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
| Respond to challenge | POST challenge url=C2=A0 =C2=A0 =C2=A0 =C2=A0| 200= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
| Finalize order=C2=A0 =C2=A0 =C2=A0 =C2=A0| POST order finalize=C2=A0 =C2= =A0 =C2=A0 | 200=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
| Poll for status=C2=A0 =C2=A0 =C2=A0 | GET=C2=A0 order=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 200=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
| Download certificate | GET=C2=A0 order cert=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | 200=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |


Also the diagram seems to have a few issues:

1. new-nonce should be newNonce (my fault)
2. should "finalize" appear somewhere? maybe like this?
=C2=A0 =C2=A0 order -----> finalize
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -----> cert
3. I think "authz" could be called authorization here

Best,
Sophie

_______________________________________________
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


--f403043a279468ddfa056062a580-- From nobody Fri Dec 15 07:43:26 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 D5A241270A7 for ; Fri, 15 Dec 2017 07:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hemio.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Qz2T7OSBHWW for ; Fri, 15 Dec 2017 07:43:22 -0800 (PST) Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4F08126C89 for ; Fri, 15 Dec 2017 07:43:21 -0800 (PST) Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id 61B059E; Fri, 15 Dec 2017 16:43:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hemio.de; s=20170414; t=1513352600; bh=5M7S4vcxURHlUNoVYky/QCXbuggtsC6Q9xQ18c/ZNtY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=WVbIn9BPRvnmhohy8+X5mYBcyLRnNKHkRYyFo+2C9U/7oXQjNUx9JDxw2wTd8/tQV U9sLtdI63kww4axb0jJCriQldLXPxNqRmrDtCN8CgKbiI0MnUEIZxvPyU5e8hCJ54R 24p5ShsSCXT6sTausorlHvnCMmhl+qGNxCs32bnC4QVgWVGczoHiblvkgpN3um6p6h ESRPvaJlrfLf2vUD89Lq4x6Y3HG3XbAA4XP8G1R5KMTOhiYHQ7Hozelh06PbR95b76 o569M27Q0omY//c/8QoP0ghvjHtWmXF2DuuORSd05sLb8S0Vi49a/iM9R0s3tGegW0 DCS6Idcs9pgEQ== To: Richard Barnes , Daniel McCarney Cc: IETF ACME References: <0347d7f8-dc62-921f-b3e4-eb303b390e74@hemio.de> From: Sophie Herold Message-ID: <8a7bd02b-1e65-4c1d-93a1-55d802791914@hemio.de> Date: Fri, 15 Dec 2017 16:43:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.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] 7.1. Resources "typical sequence of requests" 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, 15 Dec 2017 15:43:25 -0000 Hi, thank you for the feedback! The PR is here Best, Sophie On 15/12/17 16:28, Richard Barnes wrote: > +1 > > On Fri, Dec 15, 2017 at 10:24 AM, Daniel McCarney > wrote: > >> Hi Sophie, >> >> I think there are two "mistakes" in this example: >> >> >> Agreed on both mistakes. Thanks for flagging! >> >> To avoid unnecessary confusion, I suggest that the table could look something >>> like this: >> >> >> I like your proposed fixes. I think the only change I'd request is that I >> think the "Fetch challenges" action should have a plural request stage "GET >> order authorization*s*". Similarly the "Respond to challenge" action >> should be plural ("Respond to challenge*s*") and should have a plural >> request "POST challenge url*s*". I think that will emphasize that there >> can be multiple authorizations in one order and multiple challenges in one >> authorization. >> >> Also the diagram seems to have a few issues: >> >> >> Agreed that we should capture the finalization step here & remove the >> "new-nonce"/"authz" inconsistencies. >> >> Sophie: Do you want to submit a PR implementing these changes? >> >> Thanks again! >> >> >> On Thu, Dec 14, 2017 at 2:08 PM, Sophie Herold >> wrote: >> >>> Hi, >>> >>> I think there are two "mistakes" in this example: >>> >>> | Action | Request | Response | >>> |:---------------------|:--------------------|:----------------| >>> | Get a nonce | HEAD newNonce | 204 | >>> | Create account | POST newAccount | 201 -> account | >>> | Submit an order | POST newOrder | 201 -> order | >>> | Fetch challenges | GET authz | 200 | >>> | Respond to challenge | POST challenge | 200 | >>> | Finalize order | POST order finalize | 200 | >>> | Poll for status | GET authz | 200 | >>> | Check for new cert | GET cert | 200 | >>> >>> 1. "Poll for status" should not be "GET authz" but "GET order". >>> Only if the order is "pending" or "invalid", authz are of interest. >>> 2. "Check for new cert": There is nothing to check here. >>> >>> >>> To avoid unnecessary confusion, I suggest that the table could look >>> something like this: >>> >>> | Action | Request | Response | >>> |:---------------------|:-------------------------|:---------------| >>> | Get directory | GET directory | 200 | >>> | Get nonce | HEAD newNonce | 204 | >>> | Create account | POST newAccount | 201 -> account | >>> | Submit order | POST newOrder | 201 -> order | >>> | Fetch challenges | GET order authorization | 200 | >>> | Respond to challenge | POST challenge url | 200 | >>> | Finalize order | POST order finalize | 200 | >>> | Poll for status | GET order | 200 | >>> | Download certificate | GET order cert | 200 | >>> >>> >>> Also the diagram seems to have a few issues: >>> >>> 1. new-nonce should be newNonce (my fault) >>> 2. should "finalize" appear somewhere? maybe like this? >>> order -----> finalize >>> -----> cert >>> 3. I think "authz" could be called authorization here >>> >>> Best, >>> Sophie >>> >>> _______________________________________________ >>> 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 >> >> > From nobody Tue Dec 19 01:48: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 148EE12D84D for ; Tue, 19 Dec 2017 01:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hemio.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9k-ibf61oiC for ; Tue, 19 Dec 2017 01:47:57 -0800 (PST) Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A24127077 for ; Tue, 19 Dec 2017 01:47:57 -0800 (PST) Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id 5B95B9B for ; Tue, 19 Dec 2017 10:47:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hemio.de; s=20170414; t=1513676875; bh=lhSXGl0qxZFl0UNKU2Aq1lZaHDnFxvITiCgoCubfesM=; h=To:From:Subject:Date:From; b=fk6CkGMHpxjGdsJssot2ovDIjuSXwIuO0LQuzyGC3DPGna00H2CAwWx2LmtdkxDje OwLIivjQQryprPsYlthH5U12pxlY7O6eQf640QyACFnsYWKII6czyFw6stbFuQbsf8 OLXqA7s/esnaiWC7fk+NfvZfEPj/ZFkxO8NCbRoEGDJu3+DmXkwDRCSkwcT+eHKzhP 5iIRqJ3gYXg87wIgtx+ofPL10ISAQxNoka5bdU/7QTMAXfM/LDEZ7S3aoD+IvmqN9L LTiShQGlmWWbUa7QiNe80l8/QDZD2naCz0svxf+uru74OOkmQ9cqjqGeFy9LavoQ45 Jt6Yi3WL3WwsQ== To: IETF ACME From: Sophie Herold Message-ID: Date: Tue, 19 Dec 2017 10:47:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [Acme] PRs for HEAD status code and Key Authorizations X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 09:47:59 -0000 Small changes to "Key Authorizations" section Fixes divergence from the rest of the draft. Changes HEAD status code to 200 This came up in a PR discussion. From nobody Tue Dec 19 03:10:40 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5FC126B71 for ; Tue, 19 Dec 2017 03:10:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hemio.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmrzSR2GMGao for ; Tue, 19 Dec 2017 03:10:38 -0800 (PST) Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCE0412025C for ; Tue, 19 Dec 2017 03:10:37 -0800 (PST) Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id 7A3CB9B for ; Tue, 19 Dec 2017 12:10:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hemio.de; s=20170414; t=1513681836; bh=vXXzBE6Ei+DJ3tQTPmntkcQOP+MpOw1tEIAsW5+LgV0=; h=To:From:Subject:Date:From; b=rzTjEZKOYhT10yc36Y26ThXpb2GDvgb+YltghuSR2tuidtAccYmlQFNDDHqI1M4K5 KF8uytBdZwMfWNTxquNwQC0iudtOgj5QBqiPyIWZBXCNi7lKxLnvu3ktfrBKAzItFU wohPg/sc4wsri89bbO771IAGWvw2cXCtK5/YSHdMgsTU5FRJ5LWNhqC28rhTjL85M0 YX4V9yaKjpUCQRvQw+Istr+IKloJsAixXUtYr1sBB5Y3BWDsiXaC+Ly/GAk5AJ1c2g 4j0KtaxJEuWIcJPmQs4nFckoq4gK0jtHoYWZeN+I2k5R3vYBR6kGcdZxZUMx09C77N UFiOyomiBtH9g== To: IETF ACME From: Sophie Herold Message-ID: <8eb3c147-4fa7-9176-c9ef-1a8964c0df3f@hemio.de> Date: Tue, 19 Dec 2017 12:10:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Acme] Challenge objects are provoking implementation mistakes 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, 19 Dec 2017 11:10:39 -0000 Hi, It is part of the ACME security model that clients use the key authorizations they have computed themselves for fulfilling challenges. However, Sections 7.1.4. and 7.1.5. give examples of the server returning the keyAuthorization as part of the challenge object. If the client follows the schema 1. fulfill challenge 2. POST challenge URL it is unlikely that the keyAuthorization returned by the server would be used to fulfill the challenge (again). However, it should be possible to obtain a working ACME client by POSTing to the challenge URL first and using the keyAuthorization returned by the server (and possibly changed by the server) to fulfill the challenge afterwards. This should work since the servers challenge checks (DNS, HTTP, ...) are not instantaneous and even retried. In this case the MitM protection is bypassed by incautious client implementation. If my interpretation is correct, I would suggest that the server MUST NOT return the keyAuthorization object. That would reduce the likelihood that the client is using a keyAuthorization fields returned by the server. Maybe it would be also worth pointing out that clients MUST use the keyAuthorization they computed themselves. However, without context that might become a confusing tautology. One more thing: During client implementation I also started to wonder if I should check the identifier values (i.e. domains) the server returns in challenges. I don't see an immediate risk in fulfilling challenges for arbitrary domains the server returns to the client. But maybe there would be a security benefit in checking if the challenge identifiers match (up to some sub-domain logic) the once passed to newOrder/newAuthz originally or are 'managed by the client in general'. This would be relevant if the client has access to a domains web- or dns-server, but this domain should only use ACME with a different CA/JWK or no ACME at all. Best, Sophie From nobody Tue Dec 19 03:23:23 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A09112DA4F for ; Tue, 19 Dec 2017 03:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hemio.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68Osf0tj8aQW for ; Tue, 19 Dec 2017 03:23:14 -0800 (PST) Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32F4F12D95E for ; Tue, 19 Dec 2017 03:23:14 -0800 (PST) Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id E1CB79B for ; Tue, 19 Dec 2017 12:23:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hemio.de; s=20170414; t=1513682592; bh=AeZM5Dian2U2JjjuosjOKA4SbT1SN9/fw27mlYoZ+ew=; h=From:Subject:To:Date:From; b=qQhLozq/cy+heR6M7Rb8QSayV6omm6nNfP7gcxhY8NhzwGVS6yAjmwfG5vUPu9COq 2Go4X1unbrvW/GIqR+ATt3RHVy9Kx6/ILiWknqXH+oFiD2FQqg+4PzXTc6GPTQVh5g Ai0/kCTRkaGIxfQWfbGkvt4xa1HZgbyr6bOm9vTu9iblWW9OZJKdnmxv6FAS+8yCJd ERxebXW7w/TXawDNaW8UDqY6I72EQoDD3BorZhA9kpetghKU7jHCTwSzSJ9DSerrDF 9nsOdq/cDGWuN/XiPSUa675zQaEweNx7RKKrSIyGqRMx9Q/Ke9zHVTM8yQYF+dZg3C cADKQc0KXRgrQ== From: Sophie Herold To: IETF ACME Message-ID: Date: Tue, 19 Dec 2017 12:23:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Acme] Prepended zero octets in the fields of a JWK 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, 19 Dec 2017 11:23:19 -0000 Hi, I found those two statements contradictory. R and S should be part of the JWK object if I am not mistaken. Can someone point me to the relevant statement in RFC 7518? Best, Sophie ACME-09 > As noted in JWA {{!RFC7518}} any prepended > zero octets in the fields of a JWK object MUST be stripped before doing the computation. RFC 7518 > 2. Turn R and S into octet sequences in big-endian order, with each > array being be 32 octets long. The octet sequence > representations MUST NOT be shortened to omit any leading zero > octets contained in the values. From nobody Tue Dec 19 03:34:51 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AC812DA4E for ; Tue, 19 Dec 2017 03:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93kLn2CY0vdr for ; Tue, 19 Dec 2017 03:34:48 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4CB512D95E for ; Tue, 19 Dec 2017 03:34:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 162A9B538D; Tue, 19 Dec 2017 13:34:45 +0200 (EET) 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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id XbMSiV3brKMW; Tue, 19 Dec 2017 13:34:44 +0200 (EET) 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 C800F27B; Tue, 19 Dec 2017 13:34:42 +0200 (EET) Date: Tue, 19 Dec 2017 13:34:42 +0200 From: Ilari Liusvaara To: Sophie Herold Cc: IETF ACME Message-ID: <20171219113442.GA1831@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] Prepended zero octets in the fields of a JWK 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, 19 Dec 2017 11:34:50 -0000 On Tue, Dec 19, 2017 at 12:23:12PM +0100, Sophie Herold wrote: > Hi, > > I found those two statements contradictory. R and S should be part of > the JWK object if I am not mistaken. Can someone point me to the > relevant statement in RFC 7518? No, R and S are not part of JWK object. They are part of ECDSA signature. The public JWK fields include crv, e, kty, n, x and y (not all present at once). > ACME-09 > > > As noted in JWA {{!RFC7518}} any prepended > > zero octets in the fields of a JWK object MUST be stripped before > > doing the computation. This is about JWKs, which are keys. > RFC 7518 > > > 2. Turn R and S into octet sequences in big-endian order, with each > > array being be 32 octets long. The octet sequence > > representations MUST NOT be shortened to omit any leading zero > > octets contained in the values. This is about ECDSA signatures. So one is talking about keys, the other about signatures, so there is no contradiction. -Ilari From nobody Tue Dec 19 07:09: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 675E0126CE8 for ; Tue, 19 Dec 2017 07:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 pLyfoGxGGQlh for ; Tue, 19 Dec 2017 07:08:59 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 3599C129C6E for ; Tue, 19 Dec 2017 07:08:59 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id t196so13897601iof.0 for ; Tue, 19 Dec 2017 07:08:59 -0800 (PST) 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=DmrRd8IC+k4wdsEZ++laQWed69E1Nk0xjDKa1AI1Hrs=; b=giTBY1GZlltBuvMeOtekJuzbp2YW8XDAcnM15MQVejC5yggAfotJx2Y3rpr2bUNSk1 kHaTa6fVTbpD7x7iCHjEUN2uFiQQ9xMsyq2BTzPuqxFj2+3BRu2Z5lveMvVZFDA4Q/LN z9Zw1R1nI1I3UJvqzUWYjCZGwKLDNQGSA0DPs= 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=DmrRd8IC+k4wdsEZ++laQWed69E1Nk0xjDKa1AI1Hrs=; b=nUHLHpXI1vhjPNkCh8rOUWW/eJjqMTspCNatGth4jyCS8uGPjwENA/dwgkZpYp2VPD bWxed6LVYA2dEHxjFKc4x8s+gFbgnZB+28o1fKiYabxtKOqfimmrNOtq+B0wijuXb91y vjCU5/n/UUQwILKYGnIuORjLEY+SraZWSfI4yFFr87QTYhJBnA2GN+/eNRbkrBx/uoF0 WEIv6Wxz5MN0hQFlnhcW30KSfI+NBBDDbN7eChCSbU4oGpaM05Ky6IzDcACgYBIDvklc 2tztLFEFKyaEKu02JQOwaFie+a6FnlV/YK5/K4QSC4vPuJSEzcetkdLLe29i0y2TM77Q iKhQ== X-Gm-Message-State: AKGB3mLvUFxWdLe/bj/K7pAEa/3Pk044L6bOm8tE+240tz7YnEwNvUfg mcg6q3VCReI7J4inCLjpxQKmN9NZlRjiYHdouYKRW1Ru X-Google-Smtp-Source: ACJfBouaEzZCfgTZTSMH7ZZzTKfAISraK0VOG9ciCufnUlPrFfdbhuJeaLYX8XorlTtiSRNfrHZAJV3Ekw0fPRGtNVY= X-Received: by 10.107.50.1 with SMTP id y1mr4445841ioy.31.1513696138365; Tue, 19 Dec 2017 07:08:58 -0800 (PST) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.22.2 with HTTP; Tue, 19 Dec 2017 07:08:57 -0800 (PST) In-Reply-To: References: From: Daniel McCarney Date: Tue, 19 Dec 2017 10:08:57 -0500 Message-ID: To: Sophie Herold Cc: IETF ACME Content-Type: multipart/alternative; boundary="001a1144719ca065460560b2d83f" Archived-At: Subject: Re: [Acme] PRs for HEAD status code and Key Authorizations X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 15:09:01 -0000 --001a1144719ca065460560b2d83f Content-Type: text/plain; charset="UTF-8" #373 and #374 both approved & merged. Thanks again! On Tue, Dec 19, 2017 at 4:47 AM, Sophie Herold wrote: > Small changes to "Key Authorizations" section > > > Fixes divergence from the rest of the draft. > > > > Changes HEAD status code to 200 > > > This came up in a PR discussion. > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a1144719ca065460560b2d83f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
#373 and #374 both approved & merged. Thanks again!

On Tue, Dec 19= , 2017 at 4:47 AM, Sophie Herold <sophie_herold@hemio.de> wrote:
Small changes to "Key Auth= orizations" section
<https://github.com/ietf-wg-acme/acme/pull/373<= /a>>

Fixes divergence from the rest of the draft.



Changes HEAD <nonce> status code to 200
<https://github.com/ietf-wg-acme/acme/pull/374<= /a>>

This came up in a PR discussion.
<https://github.com/ietf-wg-acme/acme/pull/371#discussion_r157250883>

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

--001a1144719ca065460560b2d83f-- From nobody Wed Dec 20 13:27: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 707D9124239 for ; Wed, 20 Dec 2017 13:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 ilGxDGjCLjfi for ; Wed, 20 Dec 2017 13:27:55 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43B0F1200C5 for ; Wed, 20 Dec 2017 13:27:55 -0800 (PST) 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=V9mYtH/pmEMoHyYNgyoNkCSp1jTXamEfIxmLnwzGM8w=; b=sFc1UT/8PX2WzcJ8U+DyLwZ5wU/PihTqTXNfW+eV/+jy8eEkB6Oqsh5oaL1k1wOyJiLsyePutGE08HfexD90CBjt7O5IzD9dbRYplBio23JR/LdMTfFYpTcInAGkbCQefD/tH/WQBH4lGU4Ogg6SFwwkYF7Or2Pj/kPnmYOvFI4=; Received: ; Wed, 20 Dec 2017 13:27:49 -0800 To: acme@ietf.org References: From: Jacob Hoffman-Andrews Message-ID: <676b57df-95c2-4e65-59e2-a3c45a3412c3@eff.org> Date: Wed, 20 Dec 2017 13:27:53 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.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] Discussion of draft-ietf-acme-ip 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, 20 Dec 2017 21:27:57 -0000 On 11/16/2017 02:28 PM, Roland Bracewell Shoemaker wrote: > The point of the draft is to provide a method for validating the control > of IP addresses in the same way that the ACME draft does for DNS names. > This allows ACME implementing CAs to be on an equal footing with > existing implementations. The draft does three major things > > * Adds a IP identifier type > * Provides guidance on using http-01 and tls-sni-02 challenges for IP > validation > * Adds a new challenge, reverse-dns-01, which conforms with CABF B/R > Section 3.2.2.5. > > The only major objection that was previously voiced revolved around the > lack of a policy mechanism for allowing a IP/network owner to block > issuance and that there should be some kind of default denial required. > It is my opinion that this draft is the wrong place for CA policy to be > dictated and the right place to fix this problem would be in a document > implementing an lookup mechanism for CAA records for IP addresses (see > draft-shoemaker-caa-ip). > > Any major thoughts/objections? If there are no significant hurdles I'd > like to move towards getting this document finalized. Any further thoughts about draft-shoemaker-caa-ip? I'd love to get it adopted as a WG document. From nobody Wed Dec 20 13:51:10 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 BE37C129C51 for ; Wed, 20 Dec 2017 13:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vi83QELVG_6N for ; Wed, 20 Dec 2017 13:50:58 -0800 (PST) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D9A9129511 for ; Wed, 20 Dec 2017 13:50:58 -0800 (PST) Received: by mail-wr0-x22b.google.com with SMTP id l41so11336742wre.11 for ; Wed, 20 Dec 2017 13:50:58 -0800 (PST) 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=fBHPr5H+4z6C7nCjPXhde/u95Q+HF68wHxayoZW+qJw=; b=zaLl/ekebsUCecZTUD7aoM5bPymEssBMqRMUF3650ti8F/eSTiheMQ0yKHjIyR9tF8 yVaxGCtW6jwZeQ7Hfp+ZohV8npSUQgEkfkO/Q5OHkvqT1cjw/68w2QJFmBwTAsgpj/gv HkGM3RpUfa0y3jr0HE5hVy48LlnLA5zDuVRtkOYqSpVyqZmf06f3jzRekR82ocvEqvgx Of0efw2wtfVbiZqQtG86Wo2RXWrhy5H+vSKek4Z9rYVhiWfpcL2kIy/nVh1HXQkBPZbo 7ErtUy45tA4+xGL7mKaYpus0ecGZJOx6YNYyKAfQQq9Apul3clvAl3H/Mt+AkWsh9jFH 3ajw== 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=fBHPr5H+4z6C7nCjPXhde/u95Q+HF68wHxayoZW+qJw=; b=V7z+Ie0KjpUIdNmUOfUcqHLEfSH5NvosfxEPKeKk/ECltkD2C7b/x1eSbZ411sU0rL tZv9WqhLe67XCk2ntLBIZzbwLxL3X5fH4ynNXJlxSbJKzhx9cjN5q7op/4Cr/9cd8U5m ArKLnCQyY+n10NGTee8RdWFaAGYQEm6t2Lde/O7NlIdcEAcYt7ULp3seZUvxifZ94hU3 vyoqD0k39dKAWQQP+tbk+cg0Ov4Zlc+dZBW4XLUMqwl0xbdrxaMjD1hY6Zkrk6/yiiQb JostEjWzydB+XW+j/LV1G0Lii8FPcbmllTUY4w+pCBYmHiQ1NhZpORhVzEueyxJh6V9J DnQg== X-Gm-Message-State: AKGB3mK3050ZA2zxcvtUycIzylFgHQQrkvrQSnT57iJtwCJpe4FfmhIU xINHB4Zf84XZXZQ3hPIHaWuU57V9GqibsB3L+oiMSgo2 X-Google-Smtp-Source: ACJfBouz2hjkC4cEmtqZtIBG7gbQpw3Ly0+Urq6/VGwKKLa5sVhhb7MU/1EorT4s9uaRDmwj42l1dI2d8tAzmDndqFI= X-Received: by 10.223.161.210 with SMTP id v18mr8973104wrv.170.1513806656642; Wed, 20 Dec 2017 13:50:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.167.74 with HTTP; Wed, 20 Dec 2017 13:50:56 -0800 (PST) In-Reply-To: <676b57df-95c2-4e65-59e2-a3c45a3412c3@eff.org> References: <676b57df-95c2-4e65-59e2-a3c45a3412c3@eff.org> From: Richard Barnes Date: Wed, 20 Dec 2017 16:50:56 -0500 Message-ID: To: Jacob Hoffman-Andrews Cc: acme@ietf.org Content-Type: multipart/alternative; boundary="f403045f2ee2073aba0560cc94aa" Archived-At: Subject: Re: [Acme] Discussion of draft-ietf-acme-ip 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, 20 Dec 2017 21:51:01 -0000 --f403045f2ee2073aba0560cc94aa Content-Type: text/plain; charset="UTF-8" On Wed, Dec 20, 2017 at 4:27 PM, Jacob Hoffman-Andrews wrote: > On 11/16/2017 02:28 PM, Roland Bracewell Shoemaker wrote: > > The point of the draft is to provide a method for validating the control > > of IP addresses in the same way that the ACME draft does for DNS names. > > This allows ACME implementing CAs to be on an equal footing with > > existing implementations. The draft does three major things > > > > * Adds a IP identifier type > > * Provides guidance on using http-01 and tls-sni-02 challenges for IP > > validation > > * Adds a new challenge, reverse-dns-01, which conforms with CABF B/R > > Section 3.2.2.5. > > > > The only major objection that was previously voiced revolved around the > > lack of a policy mechanism for allowing a IP/network owner to block > > issuance and that there should be some kind of default denial required. > > It is my opinion that this draft is the wrong place for CA policy to be > > dictated and the right place to fix this problem would be in a document > > implementing an lookup mechanism for CAA records for IP addresses (see > > draft-shoemaker-caa-ip). > > > > Any major thoughts/objections? If there are no significant hurdles I'd > > like to move towards getting this document finalized. > > Any further thoughts about draft-shoemaker-caa-ip? I'd love to get it > adopted as a WG document. > Do you mean draft-ietf-acme-ip? It's already adopted; that's what the "draft-ietf" signifies. If you think all the open issues are resolved, then we should go to WGLC. Personally, I have not reviewed it recently. --Richard > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --f403045f2ee2073aba0560cc94aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Dec 20, 2017 at 4:27 PM, Jacob Hoffman-Andrews <jsha@eff.org>= ; wrote:
On 11/16= /2017 02:28 PM, Roland Bracewell Shoemaker wrote:
> The point of the draft is to provide a method for validating the contr= ol
> of IP addresses in the same way that the ACME draft does for DNS names= .
> This allows ACME implementing CAs to be on an equal footing with
> existing implementations. The draft does three major things
>
> * Adds a IP identifier type
> * Provides guidance on using http-01 and tls-sni-02 challenges for IP<= br> > validation
> * Adds a new challenge, reverse-dns-01, which conforms with CABF B/R > Section 3.2.2.5.
>
> The only major objection that was previously voiced revolved around th= e
> lack of a policy mechanism for allowing a IP/network owner to block > issuance and that there should be some kind of default denial required= .
> It is my opinion that this draft is the wrong place for CA policy to b= e
> dictated and the right place to fix this problem would be in a documen= t
> implementing an lookup mechanism for CAA records for IP addresses (see=
> draft-shoemaker-caa-ip).
>
> Any major thoughts/objections? If there are no significant hurdles I&#= 39;d
> like to move towards getting this document finalized.

Any further thoughts about draft-shoemaker-caa-ip? I'd love to g= et it
adopted as a WG document.

Do you mean d= raft-ietf-acme-ip?=C2=A0 It's already adopted; that's what the &quo= t;draft-ietf" signifies.

If you think all the= open issues are resolved, then we should go to WGLC.=C2=A0 Personally, I h= ave not reviewed it recently.

--Richard
<= div>
=C2=A0

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

--f403045f2ee2073aba0560cc94aa-- From nobody Wed Dec 20 14:46: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 BF7D4126E01 for ; Wed, 20 Dec 2017 14:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 iIHl5m_DD0ap for ; Wed, 20 Dec 2017 14:46:01 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97D531205D3 for ; Wed, 20 Dec 2017 14:46:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=tHnIHRYYo/3dl7dybmQp+8tcs819885PUzv2baZDbDk=; b=EAQq/CXndnNGLrBc1HsCEgP6nYtprgq7e1lj9HTbDJ9/WpltWnPiOhIe8lqbv+CBIs+0NLbfrzF1Rc2pRtwmQ5y0Ry+nJ7wNS6ECvmvOa1IPuvRv8qsDlnWGrxgUtzxNQSuAMwCAYr+DX4+k6ndCvYr0Fj03o0SnySaIY9jp1AM=; Received: ; Wed, 20 Dec 2017 14:45:56 -0800 To: Richard Barnes Cc: acme@ietf.org References: <676b57df-95c2-4e65-59e2-a3c45a3412c3@eff.org> From: Jacob Hoffman-Andrews Message-ID: Date: Wed, 20 Dec 2017 14:46:00 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Acme] Discussion of draft-ietf-acme-ip 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, 20 Dec 2017 22:46:03 -0000 On 12/20/2017 01:50 PM, Richard Barnes wrote: > Do you mean draft-ietf-acme-ip?  It's already adopted; that's what the > "draft-ietf" signifies. Whoops, I missed that. Thanks! From nobody Wed Dec 20 19:07: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 4EF2F124F57 for ; Wed, 20 Dec 2017 19:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 j9VS2qHv4vMU for ; Wed, 20 Dec 2017 19:07:20 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02B571242EA for ; Wed, 20 Dec 2017 19:07:20 -0800 (PST) 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=IdOJE8yB2VROrpYHpZqEhif+eRufPuQKHRWBV0fWSwU=; b=Viv3UYOoxc7wOWb3dGH/MKbPlQFRXuzRb6UKTxIn2vcE9DwUc5NVquQrQ7yJaud/R3xa1Q5UgOuy4nU/oMzNyBX1E7pcV6tGs2Nzkazh2M0HKhU8c6yLXfbYL2uqix9Bh/cARw9+2ifDeh823BJi+4w4W/U43F2KJQhhsygUEdc=; Received: ; Wed, 20 Dec 2017 19:07:15 -0800 To: acme@ietf.org References: <8eb3c147-4fa7-9176-c9ef-1a8964c0df3f@hemio.de> From: Jacob Hoffman-Andrews Message-ID: <7bab66ca-80f6-cbea-5426-496e348bc17b@eff.org> Date: Wed, 20 Dec 2017 19:07:19 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <8eb3c147-4fa7-9176-c9ef-1a8964c0df3f@hemio.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] Challenge objects are provoking implementation mistakes 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, 21 Dec 2017 03:07:21 -0000 On 12/19/2017 03:10 AM, Sophie Herold wrote: > If the client follows the schema > > 1. fulfill challenge > 2. POST challenge URL > > it is unlikely that the keyAuthorization returned by the server would be > used to fulfill the challenge (again). > > However, it should be possible to obtain a working ACME client by > POSTing to the challenge URL first and using the keyAuthorization > returned by the server (and possibly changed by the server) to fulfill > the challenge afterwards. This should work since the servers challenge > checks (DNS, HTTP, ...) are not instantaneous and even retried. In this > case the MitM protection is bypassed by incautious client implementation. This is a good point. The other potential issue is reliability: a client the depends on the returned keyAuthorization rather than the one it provided might appear to work for a while, then stop working if the server started validating challenges more quickly. I would support a change so that the server does not echo the keyAuthorization. This brings up another question: Why have the client include the keyAuthorization in the challenge POST at all? Both sides can calculate it from scratch, the POST is essentially just "I'm ready for validation now!" I think we originally included it because we anticipated had other challenges where the client would be expected to provide some secret token in the challenge response, or some proof of control of a key, so including some payload (keyAuthorization) for the other challenge types seemed stylistically consistent with that. However, I don't think it's really necessary. From nobody Tue Dec 26 20:46:13 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363CE1270A0 for ; Tue, 26 Dec 2017 20:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Xo9_AUfjagxW for ; Tue, 26 Dec 2017 20:46:09 -0800 (PST) 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 4636012426E for ; Tue, 26 Dec 2017 20:46:08 -0800 (PST) Received: by mail-wr0-x235.google.com with SMTP id w68so23428366wrc.10 for ; Tue, 26 Dec 2017 20:46:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=ICAJJ9Oo10G+GKTi14RdRI5ITzPPwLgWinrm1+RP4jw=; b=j3fYIjFl7trMRV40xnLrBP2NZcMzaYIgQZPDtro8hiCEjJe2WoDNpyjdIG04/HufNo /XSFUHNcFOULWBicmdyJTLghsa8IOfeBviElenPppHJWlVp6aYHKOorqaOzF1CLkrVcE BvKaf5IqH6EYnn2utwGf+hh3lFqogPuXx/xqKQFOA4okKu5pLOFOw8gm1m4p92f2DTiu 8xpE3TykDN+eFr676aMuzyqWEpxc+MNiWlYcEDARvic2v8cNhUliq0DvbouTzYzbDXc2 lzHd7JMLoIAkSqgZsQ8EYmsVf0o6IH2xwOCMLEgDampybfXK+cYvtWNx/NwB7PcR3Lox RuiA== 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:date:references:to :in-reply-to:message-id; bh=ICAJJ9Oo10G+GKTi14RdRI5ITzPPwLgWinrm1+RP4jw=; b=kFBHDQKwRbwj15tH7hC1L9k2mLaYBlJfWGKwD5mtcFci9vJOrQRaXS3siUiwL0zuo+ h0HXOJmmMYTckM6nn9cWzPZmZTt2D7qut3cFISG6aqnoQMvgtSXgaLlcvCrIY1mPmF0E sftEjdn6qErfnO3m1GzwPS310gHQyIKtdnf6GokeYBTu7c1VOqp45DbPNNVON1GifbEF kgp39ptSUqNNp0WXRXPx1ugNVOrljpbMSDljnAP1A6x6gz095ywEo6IIvAcEcXFVEHfC dRRiL0Gaap2ypaQMpZ9QLAlqHzJMUEl3UXIpUJZxy4n8CSZcpolSd80CO6SKiVM5XmGk LoAg== X-Gm-Message-State: AKGB3mIu7S/R0tl1IyJkjXAO8H0oZDXE7OMsQIr6ullGV/XsAKn1KSsh g7csXZJRNTCOzT2ONAhhLOTum+MW X-Google-Smtp-Source: ACJfBovVCwyhs4Dh5dAZebRuzLgRDWO5r3ej/sjbs0Wi5j4Q0V1PKvTj7RtSyWofj8ynLra0ZGUmXw== X-Received: by 10.223.170.143 with SMTP id h15mr22189844wrc.132.1514349967098; Tue, 26 Dec 2017 20:46:07 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id t65sm11270019wmt.39.2017.12.26.20.46.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Dec 2017 20:46:06 -0800 (PST) From: Yoav Nir Content-Type: multipart/signed; boundary="Apple-Mail=_B2BA6EBF-B27A-4841-968E-0B5DEC4C8EC2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 27 Dec 2017 06:46:04 +0200 References: <151326084207.6071.15107283698966377699@ietfa.amsl.com> <7B7A3807-500F-4C8A-859A-3A7CB5B5FB6D@gmail.com> To: IETF ACME In-Reply-To: <7B7A3807-500F-4C8A-859A-3A7CB5B5FB6D@gmail.com> Message-Id: <5CA9E337-4DC5-4CFB-AEA1-A6CB799CB28A@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Acme] YA WGLC for 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: Wed, 27 Dec 2017 04:46:12 -0000 --Apple-Mail=_B2BA6EBF-B27A-4841-968E-0B5DEC4C8EC2 Content-Type: multipart/alternative; boundary="Apple-Mail=_87F18B6E-F58D-461E-B435-23E0C9EB145B" --Apple-Mail=_87F18B6E-F58D-461E-B435-23E0C9EB145B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thank you for all who participated. There have been two editorial changes suggested and accepted in the = GitHub repository. As soon as a new draft is published, I think we can = progress this. Thanks again. Yoav > On 14 Dec 2017, at 19:28, Yoav Nir wrote: >=20 > Hi >=20 > Draft-09 is now available and has (IMO) addressed all or the = outstanding issues. >=20 > This starts an abbreviated WGLC for this draft. Please review the = draft and send in your comments by EOD Monday the 25th. Please note that = Monday the 25th is Christmas day, so don=E2=80=99t delay - send in your = comments sooner rather than later. >=20 > If all goes well, we can go to IETF LC in early January and have this = in the RFC Editor queue before the London meeting. >=20 > Yoav >=20 >> Begin forwarded message: >>=20 >> From: internet-drafts@ietf.org >> Subject: [Acme] I-D Action: draft-ietf-acme-acme-09.txt >> Date: 14 December 2017 at 16:14:02 GMT+2 >> To: > >> Cc: acme@ietf.org >>=20 >>=20 >> 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. >>=20 >> Title : Automatic Certificate Management Environment = (ACME) >> Authors : Richard Barnes >> Jacob Hoffman-Andrews >> Daniel McCarney >> James Kasten >> Filename : draft-ietf-acme-acme-09.txt >> Pages : 80 >> Date : 2017-12-14 >>=20 >> 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. >>=20 >> RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for >> this draft is maintained in GitHub. Suggested changes should be >> submitted as pull requests at https://github.com/ietf-wg-acme/acme = >> [1]. Instructions are on that page as well. Editorial changes can >> be managed in GitHub, but any substantive change should be = discussed >> on the ACME mailing list (acme@ietf.org ). >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ = >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-acme-acme-09 >> https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-09 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-acme-acme-09 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >=20 --Apple-Mail=_87F18B6E-F58D-461E-B435-23E0C9EB145B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thank= you for all who participated.

There have been two editorial changes suggested and accepted = in the GitHub repository. As soon as a new draft is published, I think = we can progress this.

Thanks again.

Yoav

On 14 Dec 2017, at 19:28, Yoav = Nir <ynir.ietf@gmail.com> wrote:

Hi

Draft-09 is now available and has (IMO) = addressed all or the outstanding issues.

This starts an abbreviated WGLC for = this draft. Please review the draft and send in your comments by EOD = Monday the 25th. Please note that Monday the 25th is Christmas day, so = don=E2=80=99t delay - send in your comments sooner rather than = later.

If all = goes well, we can go to IETF LC in early January and have this in the = RFC Editor queue before the London meeting.

Yoav

Begin = forwarded message:

From: internet-drafts@ietf.org
Subject: [Acme] I-D Action: draft-ietf-acme-acme-09.txt
Date: 14 December 2017 at 16:14:02 GMT+2
To: <i-d-announce@ietf.org>
Cc: acme@ietf.org

A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of = the Automated Certificate Management Environment WG of the IETF.

=        Title =           : Automatic = Certificate Management Environment (ACME)
=        Authors =         : Richard Barnes
=             &n= bsp;           &nbs= p;Jacob Hoffman-Andrews
=             &n= bsp;           &nbs= p;Daniel McCarney
=             &n= bsp;           &nbs= p;James Kasten
Filename =        : = draft-ietf-acme-acme-09.txt
Pages =           : 80
= Date =            : = 2017-12-14

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.

  RFC = EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for
  this draft is maintained in GitHub. =  Suggested changes should be
  submitted = as pull requests at https://github.com/ietf-wg-acme/acme
=   [1].  Instructions are on that page as well. =  Editorial changes can
  be managed in = GitHub, but any substantive change should be discussed
=   on the ACME mailing list (acme@ietf.org).


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-09
https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-09
A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-acme-acme-09


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


= --Apple-Mail=_87F18B6E-F58D-461E-B435-23E0C9EB145B-- --Apple-Mail=_B2BA6EBF-B27A-4841-968E-0B5DEC4C8EC2 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----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAlpDJYwACgkQuEkLFQpY zJlLawgAi5fmsQk/RhoQbG7+HhF/HvssbJeRz+NZtg6XpCrv6Aw0lVzkvHur+Z5x djF7zWVYZVSIxNBQcT95akzgyoMYVo0yBAy4cil8GaCxkN0KaCq3TefG72/8dOPS p626sd2i3h6C7OjwKrYcjfW9EAWlT+SR+s/P1bQZWnPrGUK69Ox5EsIr0HGc+uqd pdBNd8ID+PtgFyD2zQ42CBWTQko82f+DwCbhlDmUi2lgvDQD+MMdbBbqmp+zU8Sg vvQEolKO8fXY0F4jjR8AbKmLctB0CrFu9PgiWiv0HZ3jpfU2+WKPwXsBo9l8TE9J WEpld3qWitXj7dY5S5yFaioGQYcdRw== =8MKi -----END PGP SIGNATURE----- --Apple-Mail=_B2BA6EBF-B27A-4841-968E-0B5DEC4C8EC2-- From nobody Wed Dec 27 05:35:48 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4090129C53 for ; Wed, 27 Dec 2017 05:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hemio.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Atz_5bu-Rj-O for ; Wed, 27 Dec 2017 05:35:44 -0800 (PST) Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C50EA128D2E for ; Wed, 27 Dec 2017 05:35:44 -0800 (PST) Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id DE5D89B for ; Wed, 27 Dec 2017 14:35:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hemio.de; s=20170414; t=1514381742; bh=BR4gvg08kirxsH9iemvA2gxMDsxfZSz73uHSeMTw1NQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Ve+bjP4ZVk9R/jcbEN4oy7Zt3vyrV5FX/wYU4O7USBellEAHG9sgbzQoNZKctxtVU yW0fwXZWJU9kuKrTyl/g1gtFb7FxSg5DW+yiJZGomxUJCh6ljy+2eZEqlPuhIO9onZ Kt170ATBRIocxB6yVL6/BvbR/WfZL4KaNAI2ts7vxnAv8784PGEtcJ6DYMFE1nCddN QYb9AGuOfY8r5/M0AjqMr9HXe77d/GaqXGWoqrjKJmLe0PglimPEQqo0I/Pj08f4QK MKoGljT3fRnsim85OLaZwgYKHrN1zFFxjS50OgYRROxcBH8Li9H+5zbBsDMWOX8Ilq ajIAOGKyIRfMA== To: acme@ietf.org References: <8eb3c147-4fa7-9176-c9ef-1a8964c0df3f@hemio.de> <7bab66ca-80f6-cbea-5426-496e348bc17b@eff.org> From: Sophie Herold Message-ID: Date: Wed, 27 Dec 2017 14:35:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <7bab66ca-80f6-cbea-5426-496e348bc17b@eff.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] Challenge objects are provoking implementation mistakes 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, 27 Dec 2017 13:35:47 -0000 Hi, I have posted a PR that implements both changes (not expecting and not returning the keyAuthorization) as basis for a discussion. https://github.com/ietf-wg-acme/acme/pull/375 Notably, I think this should be backwards compatible for clients as far as we want it to be. The redundant keyAuthorization would just be ignored by the server. Best, Sophie On 21/12/17 04:07, Jacob Hoffman-Andrews wrote: > On 12/19/2017 03:10 AM, Sophie Herold wrote: >> If the client follows the schema >> >> 1. fulfill challenge >> 2. POST challenge URL >> >> it is unlikely that the keyAuthorization returned by the server would be >> used to fulfill the challenge (again). >> >> However, it should be possible to obtain a working ACME client by >> POSTing to the challenge URL first and using the keyAuthorization >> returned by the server (and possibly changed by the server) to fulfill >> the challenge afterwards. This should work since the servers challenge >> checks (DNS, HTTP, ...) are not instantaneous and even retried. In this >> case the MitM protection is bypassed by incautious client implementation. > > This is a good point. The other potential issue is reliability: a client > the depends on the returned keyAuthorization rather than the one it > provided might appear to work for a while, then stop working if the > server started validating challenges more quickly. > > I would support a change so that the server does not echo the > keyAuthorization. This brings up another question: Why have the client > include the keyAuthorization in the challenge POST at all? Both sides > can calculate it from scratch, the POST is essentially just "I'm ready > for validation now!" I think we originally included it because we > anticipated had other challenges where the client would be expected to > provide some secret token in the challenge response, or some proof of > control of a key, so including some payload (keyAuthorization) for the > other challenge types seemed stylistically consistent with that. > However, I don't think it's really necessary. > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > From nobody Wed Dec 27 11:01: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 E9E78129C59 for ; Wed, 27 Dec 2017 11:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hemio.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMJzl6A2BVB2 for ; Wed, 27 Dec 2017 11:01:18 -0800 (PST) Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE6D2128D2E for ; Wed, 27 Dec 2017 11:01:17 -0800 (PST) Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id 93EE99B for ; Wed, 27 Dec 2017 20:01:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hemio.de; s=20170414; t=1514401276; bh=ESFQOA8uaENjX1WUuqpn9zQs2E+/GWdSWGAJa1ZnBOY=; h=To:From:Subject:Date:From; b=oncJgtkn9dAF+zWYfEh0tyhqIyvFphaoD99zwYSpKMwrAsOiWH+YD9Fly+kZbaLUg +fuG2Jvum7T1yrm4Qx5mEM8kzkQe9KvU9ldeIz/EfGvKQXfxln9DEMMUce7mK0RLEw o8OaQbtJuerJCaJHfnNtI71BKlOFe4hjpLvH7xv3qIbCE32z/DAjOrznymtf4W+7e2 hLz+AQa4vyqTa6mCeTk4DqX9P0UW8HJcwxFwuKN1dsE3iIcwh7fq+r15wVpfXskEVU bZCBmiGY83PZhP5Ugfrt65JwNelR6cY3Ubto2lki9SOdd0iZFlL6WE9a1tEk25VtN3 0IB3OasZPPQNQ== To: IETF ACME From: Sophie Herold Message-ID: <27d24389-f906-9e8a-d2e2-61d69d8ad8d0@hemio.de> Date: Wed, 27 Dec 2017 20:01:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [Acme] Challenge url -> finalize flow and status definitions 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, 27 Dec 2017 19:01:20 -0000 Hi, sorry to come up with this issue that late, but it is currently blocking client implementation for me. I think that the definitions of order status meanings are not covering all possible server states. > “pending”: The server does not believe that the client has fulfilled the requirements. Check the “authorizations” array for entries that are still pending. = client action needed > “processing”: The server agrees that the requirements have been fulfilled, and is in the process of generating the certificate. Retry after the time given in the “Retry-After” header field of the response, if any. = authorizations are 'valid' = the server has validated the challenge That leaves no status at which the server is validating the challenge. Which in turn raises the question how exactly the order/finalize and polling flow should look like. (I also think that the meaning of the status fields for authorization and challenge objects should be defined explicitly. Currently, the challenge status even seems to be lacking a way to represent that the client has responded to the challenge.) For reference: I have also create an issue for pebble that is related to those problems It almost seems like there are different interpretations of the current spec. Best, Sophie From nobody Wed Dec 27 11:16: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 9403912D7E9 for ; Wed, 27 Dec 2017 11:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 8c8a3LXlYR-M for ; Wed, 27 Dec 2017 11:16:04 -0800 (PST) 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 B4A321200FC for ; Wed, 27 Dec 2017 11:16:03 -0800 (PST) Received: by mail-wr0-x235.google.com with SMTP id p17so13765370wre.7 for ; Wed, 27 Dec 2017 11:16:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=l7jl8e6wojYX6oJDe/ra43VBtV70S7C5EWYegUKdn1s=; b=AB0g5vIeRi5yWsm/w+LF/3KTc+gCcjXW8hhCXmjKp2C0nCEOsfed1V4RRk3GCEGEFj oXc2eRvyh5++JWy2CNcmlVIcK5kk5KqWItULhnaxuW3w0AXMN5lHAeNRKc+EJ9JLHsYT gKGSeGYHMMSbnFddG57aGP8b0IxPpts1EZJs2Iea5vwSYo9nSlxawGQYrML2marhiT7T nTl0UAzJnLnq4+vlyjfVkbRCkEcQKe7GIQlFOyIWOYk6I9EufG4OuCHcnr1gVzTozXdF oOgr3CH3tJN143qOLWacwQB7p38aZszvvERYYb7KvIEOz8PxYvskydIwbAjZMSog1iya N7Vg== 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:date:references:to :in-reply-to:message-id; bh=l7jl8e6wojYX6oJDe/ra43VBtV70S7C5EWYegUKdn1s=; b=KY4x3h7IPaerFHl/bmkQRr35NCKiwIRUL4rgSdB5kIvSBGz0uLbAPHVD2w3LrdTZnR aRFB6gbMmc3ukg6yYfwhEOvgpAUrwBTGeiPlxBfEvYrh5eEDZ4F5CS6yZOaYC2P29rF9 EDhg/82QIHi1Hg1wCgR/VRJpCSH+119vm/HsyQ6GcaEsA3KSv5vpj5Kt5yN/p2uBaJCz Gd8+ceMiemWOWTLxbEM8yp6Nfq9YiRE+eeOXmfq7cs+1oFnidG0M9D6AHspNn4QWDLBB K1KuQ3hnfyrSjcvYEi3thJ7T3tm0wMrKmWHXofYK7N0H3OKoiHD0AVTcd3iNrBqksaDB /J6Q== X-Gm-Message-State: AKGB3mIG0OYfbnRVpqm5n7Ng5FOUCNexLJMVsQytuREM07rzW0onLj9u KVmhcb2DlAZz5MkEq1hQdOFWui95 X-Google-Smtp-Source: ACJfBotgwuhlqzYza4g26nqKEkIEyl31IjggthdWcVUHjc+RaWMDXbO4OfWH/7kkwVM0X289RfueNw== X-Received: by 10.223.199.70 with SMTP id b6mr17991411wrh.223.1514402161959; Wed, 27 Dec 2017 11:16:01 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id y124sm15822129wmb.42.2017.12.27.11.16.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Dec 2017 11:16:01 -0800 (PST) From: Yoav Nir Content-Type: multipart/signed; boundary="Apple-Mail=_0F7D6FCC-A56D-406B-BD94-4B1AEA1929E0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 27 Dec 2017 21:15:58 +0200 References: <151326084207.6071.15107283698966377699@ietfa.amsl.com> <7B7A3807-500F-4C8A-859A-3A7CB5B5FB6D@gmail.com> <5CA9E337-4DC5-4CFB-AEA1-A6CB799CB28A@gmail.com> To: IETF ACME In-Reply-To: <5CA9E337-4DC5-4CFB-AEA1-A6CB799CB28A@gmail.com> Message-Id: <3344C96C-28D5-42CD-B82E-80CFAB373681@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Acme] YA WGLC for 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: Wed, 27 Dec 2017 19:16:06 -0000 --Apple-Mail=_0F7D6FCC-A56D-406B-BD94-4B1AEA1929E0 Content-Type: multipart/alternative; boundary="Apple-Mail=_A8641C31-431B-4F4C-8896-6932D74C8D90" --Apple-Mail=_A8641C31-431B-4F4C-8896-6932D74C8D90 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I take that back. Solve Sophie=E2=80=99s issue (from the other thread) = first, and then publish a new draft. > On 27 Dec 2017, at 6:46, Yoav Nir wrote: >=20 > Thank you for all who participated. >=20 > There have been two editorial changes suggested and accepted in the = GitHub repository. As soon as a new draft is published, I think we can = progress this. >=20 > Thanks again. >=20 > Yoav >=20 >> On 14 Dec 2017, at 19:28, Yoav Nir > wrote: >>=20 >> Hi >>=20 >> Draft-09 is now available and has (IMO) addressed all or the = outstanding issues. >>=20 >> This starts an abbreviated WGLC for this draft. Please review the = draft and send in your comments by EOD Monday the 25th. Please note that = Monday the 25th is Christmas day, so don=E2=80=99t delay - send in your = comments sooner rather than later. >>=20 >> If all goes well, we can go to IETF LC in early January and have this = in the RFC Editor queue before the London meeting. >>=20 >> Yoav >>=20 >>> Begin forwarded message: >>>=20 >>> From: internet-drafts@ietf.org >>> Subject: [Acme] I-D Action: draft-ietf-acme-acme-09.txt >>> Date: 14 December 2017 at 16:14:02 GMT+2 >>> To: > >>> Cc: acme@ietf.org >>>=20 >>>=20 >>> 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. >>>=20 >>> Title : Automatic Certificate Management = Environment (ACME) >>> Authors : Richard Barnes >>> Jacob Hoffman-Andrews >>> Daniel McCarney >>> James Kasten >>> Filename : draft-ietf-acme-acme-09.txt >>> Pages : 80 >>> Date : 2017-12-14 >>>=20 >>> 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. >>>=20 >>> RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for >>> this draft is maintained in GitHub. Suggested changes should be >>> submitted as pull requests at https://github.com/ietf-wg-acme/acme = >>> [1]. Instructions are on that page as well. Editorial changes = can >>> be managed in GitHub, but any substantive change should be = discussed >>> on the ACME mailing list (acme@ietf.org ). >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ = >>>=20 >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-acme-acme-09 = >>> https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-09 >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-acme-acme-09 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> Acme mailing list >>> Acme@ietf.org >>> https://www.ietf.org/mailman/listinfo/acme >>=20 >=20 --Apple-Mail=_A8641C31-431B-4F4C-8896-6932D74C8D90 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = take that back.  Solve Sophie=E2=80=99s issue (from the other = thread) first, and then publish a new draft.

On 27 = Dec 2017, at 6:46, Yoav Nir <ynir.ietf@gmail.com> wrote:

Thank you for all who = participated.

There = have been two editorial changes suggested and accepted in the GitHub = repository. As soon as a new draft is published, I think we can progress = this.

Thanks = again.

Yoav

On 14 Dec 2017, at 19:28, Yoav Nir <ynir.ietf@gmail.com>= wrote:

Hi

Draft-09 is now available and has (IMO) = addressed all or the outstanding issues.

This starts an abbreviated WGLC for = this draft. Please review the draft and send in your comments by EOD = Monday the 25th. Please note that Monday the 25th is Christmas day, so = don=E2=80=99t delay - send in your comments sooner rather than = later.

If all = goes well, we can go to IETF LC in early January and have this in the = RFC Editor queue before the London meeting.

Yoav

Begin = forwarded message:

From: internet-drafts@ietf.org
Subject: [Acme] I-D Action: draft-ietf-acme-acme-09.txt
Date: 14 December 2017 at 16:14:02 GMT+2
To: <i-d-announce@ietf.org>
Cc: acme@ietf.org

A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of = the Automated Certificate Management Environment WG of the IETF.

=        Title =           : Automatic = Certificate Management Environment (ACME)
=        Authors =         : Richard Barnes
=             &n= bsp;           &nbs= p;Jacob Hoffman-Andrews
=             &n= bsp;           &nbs= p;Daniel McCarney
=             &n= bsp;           &nbs= p;James Kasten
Filename =        : = draft-ietf-acme-acme-09.txt
Pages =           : 80
= Date =            : = 2017-12-14

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.

  RFC = EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for
  this draft is maintained in GitHub. =  Suggested changes should be
  submitted = as pull requests at https://github.com/ietf-wg-acme/acme
=   [1].  Instructions are on that page as well. =  Editorial changes can
  be managed in = GitHub, but any substantive change should be discussed
=   on the ACME mailing list (acme@ietf.org).


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-09
https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-09

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


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



= --Apple-Mail=_A8641C31-431B-4F4C-8896-6932D74C8D90-- --Apple-Mail=_0F7D6FCC-A56D-406B-BD94-4B1AEA1929E0 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----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAlpD8W4ACgkQuEkLFQpY zJldxgf/aWZ5P2z2mE0IyhpLD2bxFzFj7+mPeT45yRrhTSokP/gBBMSdWVfoLC2T Qw9CLnI93DdVgE60e/7GDt1UTXFBzy8e0glesfMnBPn1KHNV3yqXZ1EAE2XFkr/X lGUNNjBeKOwSR2bFLMa6WpopcOJpLNfzs1HdxaOKGaEADmLzrhz/Zz4x412Kdyjv YM9isaSR/0rjD4yi54CGBdvV9B6YRg1TyySQTdAUa3LMZnIn4WdNzlaGEGowpk9c qgRxT7wplUsZOoOE8PM4VWY6DpDIZmQnsNbF8MLDr9RxmfBE1aV+3tQiFZgbs7sy 493yatXcvx4wc7JVkxP3OH4wkJdcFg== =rohe -----END PGP SIGNATURE----- --Apple-Mail=_0F7D6FCC-A56D-406B-BD94-4B1AEA1929E0-- From nobody Wed Dec 27 11:37: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 9572A12D7F6 for ; Wed, 27 Dec 2017 11:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOqUqFSVrFuF for ; Wed, 27 Dec 2017 11:37:49 -0800 (PST) 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 E248B12D7F4 for ; Wed, 27 Dec 2017 11:37:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id C3AA95DE49; Wed, 27 Dec 2017 21:37:46 +0200 (EET) 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 VoEhARlLAGPs; Wed, 27 Dec 2017 21:37:46 +0200 (EET) 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 67F08287; Wed, 27 Dec 2017 21:37:44 +0200 (EET) Date: Wed, 27 Dec 2017 21:37:44 +0200 From: Ilari Liusvaara To: Sophie Herold Cc: IETF ACME Message-ID: <20171227193744.GA30020@LK-Perkele-VII> References: <27d24389-f906-9e8a-d2e2-61d69d8ad8d0@hemio.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <27d24389-f906-9e8a-d2e2-61d69d8ad8d0@hemio.de> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] Challenge url -> finalize flow and status definitions 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, 27 Dec 2017 19:37:51 -0000 On Wed, Dec 27, 2017 at 08:01:15PM +0100, Sophie Herold wrote: > Hi, > > sorry to come up with this issue that late, but it is currently blocking > client implementation for me. > > > I think that the definitions of order status meanings are not covering > all possible server states. > > > “pending”: The server does not believe that the client has fulfilled the requirements. Check the “authorizations” array for entries that are still pending. > > = client action needed > > > “processing”: The server agrees that the requirements have been fulfilled, and is in the process of generating the certificate. Retry after the time given in the “Retry-After” header field of the response, if any. > > = authorizations are 'valid' = the server has validated the challenge > > > That leaves no status at which the server is validating the challenge. > Which in turn raises the question how exactly the order/finalize and > polling flow should look like. > > > (I also think that the meaning of the status fields for authorization > and challenge objects should be defined explicitly. Currently, the > challenge status even seems to be lacking a way to represent that the > client has responded to the challenge.) > > > For reference: I have also create an issue for pebble that is related to > those problems > > > > It almost seems like there are different interpretations of the current > spec. Also, I may be botching things but: Doesn't this also interact with finalization? Checking the Editor's copy, I see four states for order: - invalid: "This order is invalid" - pending: "Missing one or more authorizations" - processing: "Finalization received, manufacturing certificate" - valid: "Here is your certificate". However, with finalizations, there would be fifth state: "Authorizations are in, waiting for finalization". Seemingly either that fifth state needs to be added, or the definitions of states altered so that that state is folded with pending state. The text of "processing" state might need a bit of adjustment regardless. Also, authorization objects have "processing" state, which presumably means "I am working on validation right now". However, I do not see definitions for the authorization object states anywhere. -Ilari From kevinbo@ucsb.edu Fri Dec 29 13:44:19 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5220B12708C for ; Fri, 29 Dec 2017 13:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=cs.ucsb.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nhNc1XmGHsV for ; Fri, 29 Dec 2017 13:44:17 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 F185C126DCA for ; Fri, 29 Dec 2017 13:44:16 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id a25so23277089uak.3 for ; Fri, 29 Dec 2017 13:44:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucsb.edu; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=m8CdwP6Vjon3en+tsatd27oVkOD4Wb9AIBFNhgFdsUs=; b=AfRBpXTEg+gpXYgy/vqed3TzPgjZtq80c07X/AQicT9b/zl7gbeTBydsAzMhl6eY0X 2+I7pzL3Y0IjbnXZ0gCJopYFUCGa3CidqBG2+FdVxwBMoZgmpOD1dSO4XFkgnyCMyQJr 5ZfTo2iEYDLn/cq3cNHGOVM2LbcmRklEr0LpzoXWTHVGpGsCUuLxV0M4J8Q3kFpwBJZP cfdGPfFGwXhb7j6cWe/vKDXM2HqjWrFFczm7O8O+3L0iOsWcJl3y3ox91tB+f7pzHpRP f2weVYmJ0ClOStOBviB1QHO9DefAsBRPPlWavEmtQLN6JlJZU+bp3mhIe/1J+S98jp5f Tiwg== 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=m8CdwP6Vjon3en+tsatd27oVkOD4Wb9AIBFNhgFdsUs=; b=F0Y8e2vkDfqoMMcdgYTsi/UfP7sltqo5/Fc1n90pPryxBXSVOG2a2V2XeQb4rfchcF qQrhPI545J1xMvjJqbc6N6YRrrImK+gZEm5nJcDJj/ZD7dOrMNaBm0tgXTcT8epMzkTp T7JhGWRXeDVRoXdrR+1JQGwwqyWSwY+g9Vb8oF/x8dMRikDn1UW6CK6qwdjfWA41JsIp WucQwHfQJUtdDYjSLMSYXt01piSu/xjfrOzRZRU4BvnuEq1pgZy1rxOB7Y/xRYKvIfDi VPd7lLinHgaXr+/XkoQ4Smyk6grisXvdlQW45rz11aXfoqDHD2nEbVhMVsJchpQKkQea ZLvw== X-Gm-Message-State: AKGB3mKTHDO1Y2vb/W/1yJpDu3smje1HujT8uVw/DH1eXnNaPMr/ZkOr 5AFFrq3ONRzVGlwqYoTBcb636T8rYY8= X-Google-Smtp-Source: ACJfBov8qtbMS1pQdU//ygBtokr1boWbHKNtOWZLh4N2UfbwhJ5ydJX4cgezlQXiAojN2V1U99RBDQ== X-Received: by 10.159.53.67 with SMTP id o61mr5641012uao.197.1514583855506; Fri, 29 Dec 2017 13:44:15 -0800 (PST) Received: from mail-ua0-f180.google.com (mail-ua0-f180.google.com. [209.85.217.180]) by smtp.gmail.com with ESMTPSA id 6sm27285602vkn.44.2017.12.29.13.44.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Dec 2017 13:44:14 -0800 (PST) Received: by mail-ua0-f180.google.com with SMTP id e39so7299539uae.12 for ; Fri, 29 Dec 2017 13:44:13 -0800 (PST) X-Received: by 10.159.57.195 with SMTP id p3mr40156832uag.39.1514583853707; Fri, 29 Dec 2017 13:44:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.50.78 with HTTP; Fri, 29 Dec 2017 13:43:43 -0800 (PST) X-Originating-IP: [68.6.115.77] From: Kevin Borgolte Date: Fri, 29 Dec 2017 22:43:43 +0100 X-Gmail-Original-Message-ID: Message-ID: To: acme@ietf.org Cc: Tobias Fiebig , Shuang Hao , Christopher Kruegel , Giovanni Vigna Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Acme] Stale DNS and high-risk issuance 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, 29 Dec 2017 21:47:02 -0000 Hi all, we have reached out a while ago about IP address staleness and domain takeover attacks, and a way to prevent certificate issuance in these cases (July 2017). Since then, we have conducted some measurements on the practicality of the attacks. Furthermore, we wrote down our defense in a structured manner. The results of this will appear as a paper at the Network and Distributed Systems Symposium (NDSS) in February 2018. As you suggested when we approached the list earlier, we would love to contribute a RFC on it. However, based on that initial feedback, we were wondering how to move forward? Would you prefer an additional RFC for the proposed ACME challenge, or would you want to incorporate it into an existing RFC? If you are interested in reading the paper, please reach out. While we have not made the paper public yet, we are happy to share it privately here. Best, Kevin P.S. We plan to release the paper publicly early January. From nobody Sat Dec 30 03:05: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 199711241F5 for ; Sat, 30 Dec 2017 03:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-jjUivP1aRW for ; Sat, 30 Dec 2017 03:05:39 -0800 (PST) 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 A9F96120713 for ; Sat, 30 Dec 2017 03:05:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 5E2CF5DE95; Sat, 30 Dec 2017 13:05:34 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id HnxNS9uErN8b; Sat, 30 Dec 2017 13:05:34 +0200 (EET) 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-smtp3.welho.com (Postfix) with ESMTPSA id DDD152308; Sat, 30 Dec 2017 13:05:27 +0200 (EET) Date: Sat, 30 Dec 2017 13:05:27 +0200 From: Ilari Liusvaara To: Kevin Borgolte Cc: acme@ietf.org, Tobias Fiebig , Shuang Hao , Giovanni Vigna , Christopher Kruegel Message-ID: <20171230110527.GA14453@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] Stale DNS and high-risk issuance 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, 30 Dec 2017 11:05:41 -0000 On Fri, Dec 29, 2017 at 10:43:43PM +0100, Kevin Borgolte wrote: > Hi all, > > we have reached out a while ago about IP address staleness and domain > takeover attacks, and a way to prevent certificate issuance in these > cases (July 2017). > > Since then, we have conducted some measurements on the practicality of > the attacks. Furthermore, we wrote down our defense in a structured > manner. The results of this will appear as a paper at the Network and > Distributed Systems Symposium (NDSS) in February 2018. > > As you suggested when we approached the list earlier, we would love to > contribute a RFC on it. However, based on that initial feedback, we > were wondering how to move forward? Would you prefer an additional RFC > for the proposed ACME challenge, or would you want to incorporate it > into an existing RFC? I think it is bit too late for the existing RFC. So it would have to be new RFC. Which means you would need to post draft for it. I think there would be much to discuss about ecosystem impact on the proposed countermeasures[1], and also cryptographic cleaniness (e.g., it is not cryptographically kosher to use TLS private key for JWS[2]). [1] Just as example, the following kinds of stuff are (legimately) seen fairly often or more: - Rolling over the account key for each renewal (this is usually caused by containers forgetting things). - Rolling over the TLS key for each renewal (some actually recommend this, I do not). Sometimes with very frequent renewals. - Getting multiple certificates with different keys for multiple servers with the same name. - Handling validation on separate system and pushing the certificates (and likely the TLS keys too, probably not in safe manner!) to server systems. These systems might utilize HTTP redirects (which HTTP-01 does follow) or DNS CNAMEs (which DNS-01 does follow). - Users wiping out the TLS keys and account keys (without backup!) to "reset" something (admin mistake). - Transferring site between servers and losing the keys (account and TLS) in the process. - Users using all sorts of whacky ACME clients that just do not implement anything more than bare minimum for the common case. - Users using HTTPS on servers they don't have proper control of DNS for (can't edit records, or can only use very few record types, at worst only A/AAAA, or worse yet, A only). Thinking about recovery is rather important. One of the major reasons HPKP is so hated is lack of pretty much any kind of recovery. [2] This was actually one of the major reasons why the PoP challenge was removed. -Ilari