From nobody Wed Nov 1 09: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 35BE413FDFB for ; Wed, 1 Nov 2017 09:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rl9ewD4Oq8EZ for ; Wed, 1 Nov 2017 09:16:03 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D72713FDD3 for ; Wed, 1 Nov 2017 09:14:00 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id y9so2378599wrb.2 for ; Wed, 01 Nov 2017 09:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xwQ27OY2lp4dj8UFiNJnN+h+YxA92F26zte7mtG/6sw=; b=vUL6lbqjfqQIIbjxaSbt4i/OxKC6rcH4+2CXuYiVUzRggtezk/UKiHU3qUFxQFJ0YF 14LkCg6ph7sOuG+ej9bQMhkLdRp2BzxiS5P/fIqdAMB7En5uIbWRIopXzqmIIIj5olPe 93pJsxmlx8SzlyyWFVZZA4z96sEGMaUPsGtrTWdy7Gzn4ljiHsNIZX2u2+/bktgDJTkm YB/Abv7sUT3ZXnYIcWD+Z6aJFssQq7EVvhS9zPZ7HoC+1mYXDxN6R0YIWDbnqVBmevd6 ix4CMRWw757pcK4KOMVWEsWrm0OlvqfGBAIKTI5KWyPq6MPBJerS6riKifjOR1XX8vLl fniQ== 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=xwQ27OY2lp4dj8UFiNJnN+h+YxA92F26zte7mtG/6sw=; b=hffm8XkKIbFRqCrH7p2RrKf80dj+K4AAxhUQEHnsOrfZJUKdZ/OLa6VDmn+4LkDkmS a2z+eON0esGXhRC+fB9Vzb+hSoOv1JYri412DeG3WhfkTHH4jkWZ0qwReV326Tkno34U S++6PI5omlsT2CUDC3mXzFnlK2C1ZrpS/xmaCZRWHa+fa6Pn+vzH9x9XLfhgbvAJNW1L Ga+QmcwafsD54K/5YUqdqYAztOM+Fjcf4xIjYplRXx2EIyfxWM4vcRXP1ScEsClSFQPg QtqS37dpT0M+aOP8+ueYVD7WO0tf6BQ5nNUw+MC5vum4bRM3LlYEtOG50DdEEBRk6OFK c6TA== X-Gm-Message-State: AMCzsaXVfCFVb/bcxqERYjQZOyTyFM6jTepa9vQI0ViJA8O+fB5kkVph VDUDnVTt8LCqhMBIR7BdJURjFrO4hg2VGDR2tgFKsA== X-Google-Smtp-Source: ABhQp+SMOIygeKwUdqKj2RNi/5w22wUyRdAYX3ZX9NtJHS2orzBEv90csMHIwzxTngS2Mx7PKFLeRaeZemCqoKFr2EI= X-Received: by 10.223.136.170 with SMTP id f39mr254148wrf.162.1509552838753; Wed, 01 Nov 2017 09:13:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Wed, 1 Nov 2017 09:13:58 -0700 (PDT) In-Reply-To: References: <71f3e975-7cee-18cf-2635-80eb13adff12@devever.net> <20171024141732.ufjysx5f73pyc5f4@LK-Perkele-VII> From: Richard Barnes Date: Wed, 1 Nov 2017 12:13:58 -0400 Message-ID: To: Daniel McCarney Cc: Ilari Liusvaara , IETF ACME , Hugo Landau Content-Type: multipart/alternative; boundary="001a11460aacb95023055cee2871" Archived-At: Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 16:16:06 -0000 --001a11460aacb95023055cee2871 Content-Type: text/plain; charset="UTF-8" Some of us have been discussing this off-list, and where we got to was basically as follows: 1. We should have some sort of explicit "finalize" request that triggers issuance of a certificate 2. The finalize request will need to have the CSR attached to it, so that the CA doesn't have to cache the CSR from new-order 3. The "new-order" request still needs to have some sort of description of the certificate being requested, in order to support legacy back-end interfaces, 4. That description can be either: 4.1. In the form of a CSR, or 4.2. In the form of a list of identifiers (as in @cpu's PR [0]) On the one hand, sending a CSR twice seems clumsy (as Hugo notes above) and it makes the server parse the CSR twice. On the other hand, using a CSR both times makes the client logic a bit simpler since you just send the same thing in both requests. Anyone else have thoughts here? --Richard [0] https://github.com/ietf-wg-acme/acme/pull/342 On Mon, Oct 30, 2017 at 3:48 PM, Daniel McCarney wrote: > Wouldn't it be a lot better not to do the validations at all if you can >> tell at new-order time that you're not going to be willing to issue? > > > Yes, that would be better in this one capacity. However I don't think it > comes close to justify the scaling issues associated with accepting the CSR > up-front, and as mentioned, there are other reasons why validations may > occur for an order that the CA isn't willing to issue at the time of > finalization. > > There also isn't a CAA-PKP so we're bikeshedding about impact on features > that are both unspecified & unimplemented. > > - Daniel / cpu > > On Mon, Oct 30, 2017 at 3:33 PM, Richard Barnes wrote: > >> >> >> On Mon, Oct 30, 2017 at 10:15 AM, Daniel McCarney >> wrote: >> >>> > Example: Suppose that CAA-PKP got added (restrict issuance on SPKI key). >>> Implementing that without knowing the public key at validation time is >>> annoying. >>> >>> Can you expand on "annoying"? >>> >>> It seems completely possible to reject the order finalization message >>> based on a CAA-PKP property. >>> >> >> Wouldn't it be a lot better not to do the validations at all if you can >> tell at new-order time that you're not going to be willing to issue? >> >> >> >>> In-fact, we already have to be rechecking CAA for authorizations >>> validated more than 8 hours ago at the time of issuance so there must be >>> code in place to check CAA at finalization and clients must be prepared for >>> their order to be rejected at finalization based on CAA already. >>> >>> I don't see how this is any more annoying. >>> >>> - cpu >>> >>> On Tue, Oct 24, 2017 at 10:17 AM, Ilari Liusvaara < >>> ilariliusvaara@welho.com> wrote: >>> >>>> On Tue, Oct 24, 2017 at 02:45:01PM +0100, Hugo Landau wrote: >>>> > >>>> > The ACME protocol should permit CAs to implement policy as far as is >>>> > reasonably practicable with regard to the workflows around which the >>>> > protocol is organised. Providing the CSR up-front allows the CA to >>>> > predicate order processing on aspects of that CSR, both with regard to >>>> > the present protocol and any future extensions, both now and in the >>>> > future in ways that we can and cannot foresee. I don't think it's >>>> > appropriate to defer giving critical information to the CA until the >>>> > last minute due to a resource utilisation concern which LE has already >>>> > proven capable of dealing with, especially when the whole point of the >>>> > order flow in the first place was to provide more flexibility for CAs >>>> to >>>> > institute policy. >>>> >>>> Example: Suppose that CAA-PKP got added (restrict issuance on SPKI >>>> key). Implementing that without knowing the public key at validation >>>> time is annoying. >>>> >>>> As to why one would want something like that, it would allow limiting >>>> trust on certficiate management system without deploying something as >>>> dangerous as HPKP. >>>> >>>> >>>> >>>> -Ilari >>>> >>> >>> >>> _______________________________________________ >>> Acme mailing list >>> Acme@ietf.org >>> https://www.ietf.org/mailman/listinfo/acme >>> >>> >> > --001a11460aacb95023055cee2871 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Some of us have been discussing this off-list, and wh= ere we got to was basically as follows:

1. We shou= ld have some sort of explicit "finalize" request that triggers is= suance of a certificate
2. The finalize request will need to have= the CSR attached to it, so that the CA doesn't have to cache the CSR f= rom new-order
3. The "new-order" request still need= s to have some sort of description of the certificate being requested, in o= rder to support legacy back-end interfaces,
4. That description c= an be either:
=C2=A0 4.1. In the form of a CSR, or
<= div>=C2=A0 4.2. In the form of a list of identifiers (as in @cpu's PR [= 0])

On the one hand, sending a CSR twice seems= clumsy (as Hugo notes above) and it makes the server parse the CSR twice.= =C2=A0 On the other hand, using a CSR both times makes the client logic a b= it simpler since you just send the same thing in both requests.
<= br>
Anyone else have thoughts here?

--Ri= chard




<= div>


On Mon, Oct 30, 2017 at 3:48 PM, Daniel McCarney <cpu@letsen= crypt.org> wrote:
Wouldn't it be a lot better not to do the valida= tions at all if you can tell at new-order time that you're not going to= be willing to issue?

Yes, that would be= better in this one capacity. However I don't think it comes close to j= ustify the scaling issues associated with accepting the CSR up-front, and a= s mentioned, there are other reasons why validations may occur for an order= that the CA isn't willing to issue at the time of finalization.
There also isn't a CAA-PKP so we're bikeshedding about impact on f= eatures that are both unspecified & unimplemented.=C2=A0

- Danie= l / cpu

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

=

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

Can yo= u expand on "annoying"?

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

Wouldn't it be a lot better = not to do the validations at all if you can tell at new-order time that you= 're not going to be willing to issue?

=C2= =A0
In-fact, we already have to be rechecking CAA for aut= horizations validated more than 8 hours ago at the time of issuance so ther= e must be code in place to check CAA at finalization and clients must be pr= epared for their order to be rejected at finalization based on CAA already.=

I don't see how this is any more annoying.

- cpu=C2=A0

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

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

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



-Ilari


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




--001a11460aacb95023055cee2871-- From nobody Wed Nov 1 15:12:06 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 2FEF213F6B2 for ; Wed, 1 Nov 2017 15:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umcgD_yKdWZQ for ; Wed, 1 Nov 2017 15:12:02 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B28E513F6A1 for ; Wed, 1 Nov 2017 15:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=n1NITrACJYY/wS5uv4pH9m/Nwba7C22/4PG6DuukYko=; b=jDZPaEucOzpX75BuFyP6C+RyyUBNNwCeyhUt3qPy5TQ2cRZqajQiyKCoqujpDd2TvkVk3BHtVIHBOIalfhSyA9nTeon0+hVLTruB6jm3yjwRLhcA08I2kuyxg8CEMJV+rsMMam+gsZxzASeCsqE50wP8nK54H1JMTkxT30eVWlA=; Received: ; Wed, 01 Nov 2017 15:11:58 -0700 To: Richard Barnes , Daniel McCarney Cc: Ilari Liusvaara , Hugo Landau , IETF ACME References: <71f3e975-7cee-18cf-2635-80eb13adff12@devever.net> <20171024141732.ufjysx5f73pyc5f4@LK-Perkele-VII> From: Brad Warren Message-ID: <63029bbd-a9d5-0f30-718a-8d78f76a8e82@eff.org> Date: Wed, 1 Nov 2017 15:12:01 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E244B1A0E24F57E9EABAE71B" Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 22:12:05 -0000 This is a multi-part message in MIME format. --------------E244B1A0E24F57E9EABAE71B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable As a client developer, I slightly prefer submitting the CSR twice. In addition to making the request logic a bit simpler, it causes the client to provide more information about the cert it would like to obtain earlier in the process. This was mentioned in another thread on this topic, but to provide a concrete example of where this might be useful, Let's Encrypt currently refuses to issue for CSRs containing a weak key. By initially providing the CSR, the server is able to immediately reject the request rather than waiting until the end of the process. This approach would mean something else needs to be done to alleviate bloat in in the server's database, but I think it provides a better experience on the client side. On 11/01/2017 09:13 AM, Richard Barnes wrote: > Some of us have been discussing this off-list, and where we got to was > basically as follows: > > 1. We should have some sort of explicit "finalize" request that > triggers issuance of a certificate > 2. The finalize request will need to have the CSR attached to it, so > that the CA doesn't have to cache the CSR from new-order > 3. The "new-order" request still needs to have some sort of > description of the certificate being requested, in order to support > legacy back-end interfaces, > 4. That description can be either: > =C2=A0 4.1. In the form of a CSR, or > =C2=A0 4.2. In the form of a list of identifiers (as in @cpu's PR [0]) > > On the one hand, sending a CSR twice seems clumsy (as Hugo notes > above) and it makes the server parse the CSR twice.=C2=A0 On the other > hand, using a CSR both times makes the client logic a bit simpler > since you just send the same thing in both requests. > > Anyone else have thoughts here? > > --Richard > > > [0] https://github.com/ietf-wg-acme/acme/pull/342 > > > > > > > On Mon, Oct 30, 2017 at 3:48 PM, Daniel McCarney > wrote: > > Wouldn't it be a lot better not to do the validations at all > if you can tell at new-order time that you're not going to be > willing to issue? > > > Yes, that would be better in this one capacity. However I don't > think it comes close to justify the scaling issues associated with > accepting the CSR up-front, and as mentioned, there are other > reasons why validations may occur for an order that the CA isn't > willing to issue at the time of finalization. > > There also isn't a CAA-PKP so we're bikeshedding about impact on > features that are both unspecified & unimplemented.=C2=A0 > > - Daniel / cpu > > On Mon, Oct 30, 2017 at 3:33 PM, Richard Barnes > wrote: > > > > On Mon, Oct 30, 2017 at 10:15 AM, Daniel McCarney > > wrote: > > >=C2=A0Example: Suppose that CAA-PKP got added (restrict is= suance > on SPKI=C2=A0key). Implementing that without knowing the pu= blic > key at validation=C2=A0time is annoying. > > Can you expand on "annoying"? > > It seems completely possible to reject the order > finalization message based on a CAA-PKP property. > > > Wouldn't it be a lot better not to do the validations at all > if you can tell at new-order time that you're not going to be > willing to issue? > > =C2=A0 > > In-fact, we already have to be rechecking CAA for > authorizations validated more than 8 hours ago at the time > of issuance so there must be code in place to check CAA at > finalization and clients must be prepared for their order > to be rejected at finalization based on CAA already. > > I don't see how this is any more annoying. > > - cpu=C2=A0 > > On Tue, Oct 24, 2017 at 10:17 AM, Ilari Liusvaara > > wrote: > > On Tue, Oct 24, 2017 at 02:45:01PM +0100, Hugo Landau > wrote: > > > > The ACME protocol should permit CAs to implement > policy as far as is > > reasonably practicable with regard to the workflows > around which the > > protocol is organised. Providing the CSR up-front > allows the CA to > > predicate order processing on aspects of that CSR, > both with regard to > > the present protocol and any future extensions, both > now and in the > > future in ways that we can and cannot foresee. I > don't think it's > > appropriate to defer giving critical information to > the CA until the > > last minute due to a resource utilisation concern > which LE has already > > proven capable of dealing with, especially when the > whole point of the > > order flow in the first place was to provide more > flexibility for CAs to > > institute policy. > > Example: Suppose that CAA-PKP got added (restrict > issuance on SPKI > key). Implementing that without knowing the public key > at validation > time is annoying. > > As to why one would want something like that, it would > allow limiting > trust on certficiate management system without > deploying something as > dangerous as HPKP. > > > > -Ilari > > > > _______________________________________________ > 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 --------------E244B1A0E24F57E9EABAE71B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

As a client developer, I slightly prefer submitting the CSR twice. In addition to making the request logic a bit simpler, it causes the client to provide more information about the cert it would like to obtain earlier in the process. This was mentioned in another thread on this topic, but to provide a concrete example of where this might be useful, Let's Encrypt currently refuses to issue for CSRs containing a weak key. By initially providing the CSR, the server is able to immediately reject the request rather than waiting until the end of the process.

This approach would mean something else needs to be done to alleviate bloat in in the server's database, but I think it provides a better experience on the client side.

On 11/01/2017 09:13 AM, Richard Barnes wrote:
Some of us have been discussing this off-list, and where we got to was basically as follows:

1. We should have some sort of explicit "finalize" request that triggers issuance of a certificate
2. The finalize request will need to have the CSR attached to it, so that the CA doesn't have to cache the CSR from new-order
3. The "new-order" request still needs to have some sort of description of the certificate being requested, in order to support legacy back-end interfaces,
4. That description can be either:
  4.1. In the form of a CSR, or
  4.2. In the form of a list of identifiers (as in @cpu's PR [0])

On the one hand, sending a CSR twice seems clumsy (as Hugo notes above) and it makes the server parse the CSR twice.  On the other hand, using a CSR both times makes the client logic a bit simpler since you just send the same thing in both requests.

Anyone else have thoughts here?

--Richard







On Mon, Oct 30, 2017 at 3:48 PM, Daniel McCarney <cpu@letsencrypt.org> wrote:
Wouldn't it be a lot better not to do the validations at all if you can tell at new-order time that you're not going to be willing to issue?

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

There also isn't a CAA-PKP so we're bikeshedding about impact on features that are both unspecified & unimplemented. 

- Daniel / cpu

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


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

Can you expand on "annoying"?

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

Wouldn't it be a lot better not to do the validations at all if you can tell at new-order time that you're not going to be willing to issue?

 
In-fact, we already have to be rechecking CAA for authorizations validated more than 8 hours ago at the time of issuance so there must be code in place to check CAA at finalization and clients must be prepared for their order to be rejected at finalization based on CAA already.

I don't see how this is any more annoying.

- cpu 

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

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

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



-Ilari


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






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

--------------E244B1A0E24F57E9EABAE71B-- From nobody Wed Nov 1 19:10: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 385A91397F3 for ; Wed, 1 Nov 2017 19:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzyCOkS3Q76N for ; Wed, 1 Nov 2017 19:10:10 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEE7513942F for ; Wed, 1 Nov 2017 19:10:09 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id r79so3571655wrb.13 for ; Wed, 01 Nov 2017 19:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7oIgXaTQUh7wGchcCUVzrtIY7lzdncCzffvgJo5582E=; b=f9IHd1orJKWooHMypOpiVw8rseZ1yY2S7wLDjnhl920mnVYPuxeFK3r0m5obJLQbzs P8SgrWohL+DwbFSOKLv7RlSCt0IYE7tfWnOtXPKgFtYhc8aXZ8o6vdFs5aPFS+HyJ6LC MLKqrS8HtJQ9hNCfYhO2oDyetBCZWIpbhEBJr4hhs9ntjftqsIbD5D3MRNr/KddyCCMo sADCwJHWsWZm4rnrV7IDj4LA/TttTUcxOTK8HvrAWUpKHIi6DrBeEAuLUu0LAxWu7K3D dRj+50zkP9Ah6CEfvAMoYuU5VMOHu5A4zIMtCXESk3woof2BNP0/8rAIvAynHOxyXT1w 0g9g== 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=7oIgXaTQUh7wGchcCUVzrtIY7lzdncCzffvgJo5582E=; b=O0WjG/XNwf6TgDIAsjUWe6tXU3WHdY4vS5BHq2vVNY4Fqdv9mvzfjZ4nm7MxZ9Rj76 oO8vldCnop23Hvm41252YOfJvjaS+sKp/Rad6VFYxDUqq5gx2Byp4Jh/YdtAbo6/nejr GRIsk1FmvpvLo6W/Je58XuJszcG9kvl9AFxifUJXwjEZmiTlvjtLDi3ErClKBnSbmIFp bnJTn+Ffh507Qto29WJfZ5y5rybWFw341Qh5QA6/vxO8wAzIwhKEKSO1OoxyuW8QoIcy UsVXOuUi+WV+VLbXjQ1xeIajveWio1ltsGH0KZ40bu+9Deqv7aftenFmiF1W/nVCWUT6 whDQ== X-Gm-Message-State: AMCzsaUH0rlsIBX3O/c4DiSiRdf17gJTERs0pdWvdPRfCaTUEPpjfAdK 4wRWo3SM1mwVC5yLZ1iY2c1Oy1bPJaPL+ANRIpVSoA== X-Google-Smtp-Source: ABhQp+ST+VgS42IqI+feJPLiglIr1GX5BYRAcfUn/4YKi3U3ETn6y5UXYnpeui41QnS4UkN1silNv5u/F6Q9zda9Bp8= X-Received: by 10.223.136.170 with SMTP id f39mr1179542wrf.162.1509588608239; Wed, 01 Nov 2017 19:10:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Wed, 1 Nov 2017 19:10:07 -0700 (PDT) In-Reply-To: <63029bbd-a9d5-0f30-718a-8d78f76a8e82@eff.org> References: <71f3e975-7cee-18cf-2635-80eb13adff12@devever.net> <20171024141732.ufjysx5f73pyc5f4@LK-Perkele-VII> <63029bbd-a9d5-0f30-718a-8d78f76a8e82@eff.org> From: Richard Barnes Date: Wed, 1 Nov 2017 22:10:07 -0400 Message-ID: To: Brad Warren Cc: Daniel McCarney , Ilari Liusvaara , Hugo Landau , IETF ACME Content-Type: multipart/alternative; boundary="001a11460aacc05d2e055cf67c99" Archived-At: Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 02:10:13 -0000 --001a11460aacc05d2e055cf67c99 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 1, 2017 at 6:12 PM, Brad Warren wrote: > As a client developer, I slightly prefer submitting the CSR twice. In > addition to making the request logic a bit simpler, it causes the client to > provide more information about the cert it would like to obtain earlier in > the process. This was mentioned in another thread on this topic, but to > provide a concrete example of where this might be useful, Let's Encrypt > currently refuses to issue for CSRs containing a weak key. By initially > providing the CSR, the server is able to immediately reject the request > rather than waiting until the end of the process. > > This approach would mean something else needs to be done to alleviate > bloat in in the server's database, but I think it provides a better > experience on the client side. > I think as long as the CSR is also included in the finalize request, we're OK for CA bloat -- the CA can throw away the first CSR after it parses it and produces the authorizations. Or rather, they should keep around a hash of the CSR so that they can verify that the second CSR is the same. Since we should require that. --Richard > On 11/01/2017 09:13 AM, Richard Barnes wrote: > > Some of us have been discussing this off-list, and where we got to was > basically as follows: > > 1. We should have some sort of explicit "finalize" request that triggers > issuance of a certificate > 2. The finalize request will need to have the CSR attached to it, so that > the CA doesn't have to cache the CSR from new-order > 3. The "new-order" request still needs to have some sort of description of > the certificate being requested, in order to support legacy back-end > interfaces, > 4. That description can be either: > 4.1. In the form of a CSR, or > 4.2. In the form of a list of identifiers (as in @cpu's PR [0]) > > On the one hand, sending a CSR twice seems clumsy (as Hugo notes above) > and it makes the server parse the CSR twice. On the other hand, using a > CSR both times makes the client logic a bit simpler since you just send the > same thing in both requests. > > Anyone else have thoughts here? > > --Richard > > > [0] https://github.com/ietf-wg-acme/acme/pull/342 > > > > > > On Mon, Oct 30, 2017 at 3:48 PM, Daniel McCarney > wrote: > >> Wouldn't it be a lot better not to do the validations at all if you can >>> tell at new-order time that you're not going to be willing to issue? >> >> >> Yes, that would be better in this one capacity. However I don't think it >> comes close to justify the scaling issues associated with accepting the CSR >> up-front, and as mentioned, there are other reasons why validations may >> occur for an order that the CA isn't willing to issue at the time of >> finalization. >> >> There also isn't a CAA-PKP so we're bikeshedding about impact on features >> that are both unspecified & unimplemented. >> >> - Daniel / cpu >> >> On Mon, Oct 30, 2017 at 3:33 PM, Richard Barnes wrote: >> >>> >>> >>> On Mon, Oct 30, 2017 at 10:15 AM, Daniel McCarney >>> wrote: >>> >>>> > Example: Suppose that CAA-PKP got added (restrict issuance on SPKI key). >>>> Implementing that without knowing the public key at validation time is >>>> annoying. >>>> >>>> Can you expand on "annoying"? >>>> >>>> It seems completely possible to reject the order finalization message >>>> based on a CAA-PKP property. >>>> >>> >>> Wouldn't it be a lot better not to do the validations at all if you can >>> tell at new-order time that you're not going to be willing to issue? >>> >>> >>> >>>> In-fact, we already have to be rechecking CAA for authorizations >>>> validated more than 8 hours ago at the time of issuance so there must be >>>> code in place to check CAA at finalization and clients must be prepared for >>>> their order to be rejected at finalization based on CAA already. >>>> >>>> I don't see how this is any more annoying. >>>> >>>> - cpu >>>> >>>> On Tue, Oct 24, 2017 at 10:17 AM, Ilari Liusvaara < >>>> ilariliusvaara@welho.com> wrote: >>>> >>>>> On Tue, Oct 24, 2017 at 02:45:01PM +0100, Hugo Landau wrote: >>>>> > >>>>> > The ACME protocol should permit CAs to implement policy as far as is >>>>> > reasonably practicable with regard to the workflows around which the >>>>> > protocol is organised. Providing the CSR up-front allows the CA to >>>>> > predicate order processing on aspects of that CSR, both with regard >>>>> to >>>>> > the present protocol and any future extensions, both now and in the >>>>> > future in ways that we can and cannot foresee. I don't think it's >>>>> > appropriate to defer giving critical information to the CA until the >>>>> > last minute due to a resource utilisation concern which LE has >>>>> already >>>>> > proven capable of dealing with, especially when the whole point of >>>>> the >>>>> > order flow in the first place was to provide more flexibility for >>>>> CAs to >>>>> > institute policy. >>>>> >>>>> Example: Suppose that CAA-PKP got added (restrict issuance on SPKI >>>>> key). Implementing that without knowing the public key at validation >>>>> time is annoying. >>>>> >>>>> As to why one would want something like that, it would allow limiting >>>>> trust on certficiate management system without deploying something as >>>>> dangerous as HPKP. >>>>> >>>>> >>>>> >>>>> -Ilari >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Acme mailing list >>>> Acme@ietf.org >>>> https://www.ietf.org/mailman/listinfo/acme >>>> >>>> >>> >> > > > _______________________________________________ > Acme mailing listAcme@ietf.orghttps://www.ietf.org/mailman/listinfo/acme > > > --001a11460aacc05d2e055cf67c99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 1, 2017 at 6:12 PM, Brad Warren <bmw@eff.org> wrot= e:
=20 =20 =20

As a client developer, I slightly prefer submitting the CSR twice. In addition to making the request logic a bit simpler, it causes the client to provide more information about the cert it would like to obtain earlier in the process. This was mentioned in another thread on this topic, but to provide a concrete example of where this might be useful, Let's Encrypt currently refuses to issue for CSRs containing a weak key. By initially providing the CSR, the server is able to immediately reject the request rather than waiting until the end of the process.

This approach would mean something else needs to be done to alleviate bloat in in the server's database, but I think it provides a better experience on the client side.

I think as long as the CSR is also included in the finalize requ= est, we're OK for CA bloat -- the CA can throw away the first CSR after= it parses it and produces the authorizations.

Or = rather, they should keep around a hash of the CSR so that they can verify t= hat the second CSR is the same.=C2=A0 Since we should require that.

--Richard
=C2=A0

On 11/01/2017 09:13= AM, Richard Barnes wrote:
Some of us have been discussing this off-list, and where we got to was basically as follows:

1. We should have some sort of explicit "finalize" r= equest that triggers issuance of a certificate
2. The finalize request will need to have the CSR attached to it, so that the CA doesn't have to cache the CSR from new-order
3. The "new-order" request still needs to have some = sort of description of the certificate being requested, in order to support legacy back-end interfaces,
4. That description can be either:
=C2=A0 4.1. In the form of a CSR, or
=C2=A0 4.2. In the form of a list of identifiers (as in @cpu&#= 39;s PR [0])

On the one hand, sending a CSR twice seems clumsy (as Hugo notes above) and it makes the server parse the CSR twice.=C2=A0 O= n the other hand, using a CSR both times makes the client logic a bit simpler since you just send the same thing in both requests.

Anyone else have thoughts here?

--Richard







On Mon, Oct 30, 2017 at 3:48 PM, Daniel McCarney <cpu@letsencrypt.org> wrote:
Wouldn't it be a lot better not to do the validations at all if you can tell at new-order time that you're not going to b= e willing to issue?

Yes, that would be better in this one capacity. However I don't think it comes close to justify the scaling issues associated with accepting the CSR up-front, and as mentioned, there are other reasons why validations may occur for an order that the CA isn't willing to issue at the time of finalization.
There also isn't a CAA-PKP so we're bikeshedding = about impact on features that are both unspecified & unimplemented.=C2=A0

- Daniel / cpu

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


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

Can you expand on "annoying"= ;?

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

Wouldn't it be a lot better not to d= o the validations at all if you can tell at new-order time that you're not going to be willing to issue?

=C2=A0
In-fact, we already have to be rechecking CAA for authorizations validated more than 8 hours ago at the time of issuance so there must be code in place to check CAA at finalization and clients must be prepared for their order to be rejected at finalization based on CAA already.

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

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

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

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



-Ilari


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






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


--001a11460aacc05d2e055cf67c99-- From nobody Thu Nov 2 06:51:14 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4D2138BCD for ; Thu, 2 Nov 2017 06:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 ZaSO6LRx31Bm for ; Thu, 2 Nov 2017 06:51:09 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA56113A415 for ; Thu, 2 Nov 2017 06:51:08 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id h70so14106767ioi.4 for ; Thu, 02 Nov 2017 06:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=4cBK8OV6IsYlzvsWFkfVMawmw6DwRRaC2i0vTy9L7fs=; b=XzZ3QJuMT8p5d7uJtqZPMxTMQeeQYlpuWks0EUETMVhiG+3YiPHEFPmDVo8zGGlSfz crotEg6ai9G74YWpRPN1a14jf6mwRCYlBYEIU7DjcIoguursH0UEWfD22mnetfb2QAvy jEOv3RZFUt6HL2DroRe6tclAO4s1VvqM0VFCE= 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=4cBK8OV6IsYlzvsWFkfVMawmw6DwRRaC2i0vTy9L7fs=; b=nd1K1bKx8/ZnL3OHLymWUWeKm8EXVW9+e50yQKnoLgg3VVrv+0U6rYKIDhlbiumDtx qonI9041x7o+3CJqsY+R+Dmbx1DEEKNKoGef2FpT9XCGVIIw26Bn8oI8/r+4p/p1qGyl TPmEv9kSMrmoWER4Oxehj5p5fU9z1vOGM8FdtTAvgRcZBVsnjD2IzMp9BTCmSie0joxm dY80V1KJ+2Wy8SwIApszNSLyWiE4EIYaxqtM6PRGi66dQLxpfi6qqcmnvd3JL6BD8Vfv I2bkAOgX4g2PQrWvheGfAhQUGH+7y8I9NkyoNoFuDBbnEr0haxq0wrzFkwRFUQ0LXhTa 6GPQ== X-Gm-Message-State: AMCzsaU/NFSwZ0jUiV6x4Lfbdg+2lWIoujY3yuyT8q3+gyYAkOWpTqjV N0+lrqS8Ick8tMco0LKItnX7DWDjDoIyNychnRCiHw== X-Google-Smtp-Source: ABhQp+T1s1toDIP3Dchuxeilot8/iEUOgA00G0MSOjtsa7F34wfP6q7ypt06R3fujAqXyGwvIdI0bwwxIZNZrjzHacM= X-Received: by 10.107.43.75 with SMTP id r72mr4543077ior.31.1509630667895; Thu, 02 Nov 2017 06:51:07 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.88.21 with HTTP; Thu, 2 Nov 2017 06:51:07 -0700 (PDT) In-Reply-To: <63029bbd-a9d5-0f30-718a-8d78f76a8e82@eff.org> References: <71f3e975-7cee-18cf-2635-80eb13adff12@devever.net> <20171024141732.ufjysx5f73pyc5f4@LK-Perkele-VII> <63029bbd-a9d5-0f30-718a-8d78f76a8e82@eff.org> From: Daniel McCarney Date: Thu, 2 Nov 2017 09:51:07 -0400 Message-ID: To: Brad Warren Cc: Richard Barnes , Ilari Liusvaara , Hugo Landau , IETF ACME Content-Type: multipart/alternative; boundary="001a113949f0b3d5e8055d0047f5" Archived-At: Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 13:51:12 -0000 --001a113949f0b3d5e8055d0047f5 Content-Type: text/plain; charset="UTF-8" > > This was mentioned in another thread on this topic, but to provide a > concrete example of where this might be useful, Let's Encrypt currently > refuses to issue for CSRs containing a weak key. By initially providing the > CSR, the server is able to immediately reject the request rather than > waiting until the end of the process. I'm sympathetic to wanting to give this information earlier in the process but I want to point out again that there will always be the potential for errors/rejection to happen at the time of finalization/issuance. All clients will have to handle it whether or not the CSR is included at the time of new-order. I think having two places where the same weak key rejection could occur will be more complicated. It also means that some orders will have to be recreated from scratch, making it harder to recover than in the case where the CSR is only sent at finalization. As a concrete example with "double CSR" orders: * Client A creates an order with CSR_1, covering "example.com", using CPU's ACME CA * Client A fully authorizes their order * CPU's CA becomes aware of a new vulnerability, RIVESTGATEKEYBLEED and updates the weak key policy * Client A sends CSR_1 again to finalize their order. Oops - it's affected by RIVESTKEYBLEED and is rejected. * Client A can not rekey their order and must always send the same CSR as from the new-order request. Outcome: Client A has to create a brand new order with CSR_2, potentially redoing all authorizations depending on CA policy (CPU's CA never reuses authorizations) Conversely, if the CSR was only sent at finalization time there would be only one place for weak-key rejection to occur. If the key policy changed no orders will have to be recreated, a different finalization CSR can be sent with the same set of identifiers. Again more concretely: * Client A creates an order for identifiers "example.com", no CSR is included. * Client A fully authorizes their order * CPU's CA becomes aware of a new vulnerability, RIVESTGATEKEYBLEED and updates the weak key policy * Client A sends CSR_1 covering "example.com" to finalize their order. Oops - it's affected by RIVESTKEYBLEED and is rejected. * Client A sends CSR_2 covering "example.com" to finalize their order. It doesn't use a weak key so the order is finalized. Otucome: Client A gets a cert. Thoughts? In this case it seems like learning later is perhaps an advantage since the actions available to remediate the error are less involved. - Daniel / cpu On Wed, Nov 1, 2017 at 6:12 PM, Brad Warren wrote: > As a client developer, I slightly prefer submitting the CSR twice. In > addition to making the request logic a bit simpler, it causes the client to > provide more information about the cert it would like to obtain earlier in > the process. This was mentioned in another thread on this topic, but to > provide a concrete example of where this might be useful, Let's Encrypt > currently refuses to issue for CSRs containing a weak key. By initially > providing the CSR, the server is able to immediately reject the request > rather than waiting until the end of the process. > > This approach would mean something else needs to be done to alleviate > bloat in in the server's database, but I think it provides a better > experience on the client side. > On 11/01/2017 09:13 AM, Richard Barnes wrote: > > Some of us have been discussing this off-list, and where we got to was > basically as follows: > > 1. We should have some sort of explicit "finalize" request that triggers > issuance of a certificate > 2. The finalize request will need to have the CSR attached to it, so that > the CA doesn't have to cache the CSR from new-order > 3. The "new-order" request still needs to have some sort of description of > the certificate being requested, in order to support legacy back-end > interfaces, > 4. That description can be either: > 4.1. In the form of a CSR, or > 4.2. In the form of a list of identifiers (as in @cpu's PR [0]) > > On the one hand, sending a CSR twice seems clumsy (as Hugo notes above) > and it makes the server parse the CSR twice. On the other hand, using a > CSR both times makes the client logic a bit simpler since you just send the > same thing in both requests. > > Anyone else have thoughts here? > > --Richard > > > [0] https://github.com/ietf-wg-acme/acme/pull/342 > > > > > > On Mon, Oct 30, 2017 at 3:48 PM, Daniel McCarney > wrote: > >> Wouldn't it be a lot better not to do the validations at all if you can >>> tell at new-order time that you're not going to be willing to issue? >> >> >> Yes, that would be better in this one capacity. However I don't think it >> comes close to justify the scaling issues associated with accepting the CSR >> up-front, and as mentioned, there are other reasons why validations may >> occur for an order that the CA isn't willing to issue at the time of >> finalization. >> >> There also isn't a CAA-PKP so we're bikeshedding about impact on features >> that are both unspecified & unimplemented. >> >> - Daniel / cpu >> >> On Mon, Oct 30, 2017 at 3:33 PM, Richard Barnes wrote: >> >>> >>> >>> On Mon, Oct 30, 2017 at 10:15 AM, Daniel McCarney >>> wrote: >>> >>>> > Example: Suppose that CAA-PKP got added (restrict issuance on SPKI key). >>>> Implementing that without knowing the public key at validation time is >>>> annoying. >>>> >>>> Can you expand on "annoying"? >>>> >>>> It seems completely possible to reject the order finalization message >>>> based on a CAA-PKP property. >>>> >>> >>> Wouldn't it be a lot better not to do the validations at all if you can >>> tell at new-order time that you're not going to be willing to issue? >>> >>> >>> >>>> In-fact, we already have to be rechecking CAA for authorizations >>>> validated more than 8 hours ago at the time of issuance so there must be >>>> code in place to check CAA at finalization and clients must be prepared for >>>> their order to be rejected at finalization based on CAA already. >>>> >>>> I don't see how this is any more annoying. >>>> >>>> - cpu >>>> >>>> On Tue, Oct 24, 2017 at 10:17 AM, Ilari Liusvaara < >>>> ilariliusvaara@welho.com> wrote: >>>> >>>>> On Tue, Oct 24, 2017 at 02:45:01PM +0100, Hugo Landau wrote: >>>>> > >>>>> > The ACME protocol should permit CAs to implement policy as far as is >>>>> > reasonably practicable with regard to the workflows around which the >>>>> > protocol is organised. Providing the CSR up-front allows the CA to >>>>> > predicate order processing on aspects of that CSR, both with regard >>>>> to >>>>> > the present protocol and any future extensions, both now and in the >>>>> > future in ways that we can and cannot foresee. I don't think it's >>>>> > appropriate to defer giving critical information to the CA until the >>>>> > last minute due to a resource utilisation concern which LE has >>>>> already >>>>> > proven capable of dealing with, especially when the whole point of >>>>> the >>>>> > order flow in the first place was to provide more flexibility for >>>>> CAs to >>>>> > institute policy. >>>>> >>>>> Example: Suppose that CAA-PKP got added (restrict issuance on SPKI >>>>> key). Implementing that without knowing the public key at validation >>>>> time is annoying. >>>>> >>>>> As to why one would want something like that, it would allow limiting >>>>> trust on certficiate management system without deploying something as >>>>> dangerous as HPKP. >>>>> >>>>> >>>>> >>>>> -Ilari >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Acme mailing list >>>> Acme@ietf.org >>>> https://www.ietf.org/mailman/listinfo/acme >>>> >>>> >>> >> > > > _______________________________________________ > Acme mailing listAcme@ietf.orghttps://www.ietf.org/mailman/listinfo/acme > > > --001a113949f0b3d5e8055d0047f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This was= mentioned in another thread on this topic, but to provide a concrete examp= le of where this might be useful, Let's Encrypt currently refuses to is= sue for CSRs containing a weak key. By initially providing the CSR, the ser= ver is able to immediately reject the request rather than waiting until the= end of the process.

I'm sympathetic to= wanting to give this information earlier in the process but I want to poin= t out again that there will always be the potential for errors/rejection to= happen at the time of finalization/issuance. All clients will have to hand= le it whether or not the CSR is included at the time of new-order.

I think having two places where the same weak key rejectio= n could occur will be more complicated. It also means that some orders will= have to be recreated from scratch, making it harder to recover than in the= case where the CSR is only sent at finalization.

= As a concrete example with "double CSR" orders:

* Client A creates an order with CSR_1, covering "example.com", using CPU's ACME=C2=A0 =C2=A0= CA
* Client A fully authorizes their order
* CPU's CA beco= mes aware of a new vulnerability, RIVESTGATEKEYBLEED and updates
= =C2=A0 the weak key policy
* Client A sends CSR_1 again to finali= ze their order. Oops - it's affected by RIVESTKEYBLEED and is rejected.=
* Client A can not rekey their order and must always send the sa= me CSR as from the new-order request. Outcome: Client A has to create a bra= nd new order with CSR_2, potentially redoing all authorizations depending o= n CA policy (CPU's CA never reuses authorizations)

=
Conversely, if the CSR was only sent at finalization time there would = be only one place for weak-key rejection to occur. If the key policy change= d no orders will have to be recreated, a different finalization CSR can be = sent with the same set of identifiers. Again more concretely:
* Client A creates an order for identifiers "example.com", no CSR is included.
* Cl= ient A fully authorizes their order
* CPU's CA becomes aware = of a new vulnerability, RIVESTGATEKEYBLEED and updates the weak key policy<= /div>
* Client A sends CSR_1 covering "example.com" to finalize their order. Oops - it's affected= by RIVESTKEYBLEED and is rejected.
* Client A sends CSR_2 coveri= ng "example.com" to finalize t= heir order. It doesn't use a weak key so the order is finalized. Otucom= e: Client A gets a cert.

Thoughts? In this case it= seems like learning later is perhaps an advantage since the actions availa= ble to remediate the error are less involved.

- Da= niel / cpu


On Wed, Nov 1, 2017 at 6:12 PM, Brad Warren <bmw@eff.org> wrote:
=20 =20 =20

As a client developer, I slightly prefer submitting the CSR twice. In addition to making the request logic a bit simpler, it causes the client to provide more information about the cert it would like to obtain earlier in the process. This was mentioned in another thread on this topic, but to provide a concrete example of where this might be useful, Let's Encrypt currently refuses to issue for CSRs containing a weak key. By initially providing the CSR, the server is able to immediately reject the request rather than waiting until the end of the process.

This approach would mean something else needs to be done to alleviate bloat in in the server's database, but I think it provides a better experience on the client side.

On 11/01/2017 09:1= 3 AM, Richard Barnes wrote:
Some of us have been discussing this off-list, and where we got to was basically as follows:

1. We should have some sort of explicit "finalize" r= equest that triggers issuance of a certificate
2. The finalize request will need to have the CSR attached to it, so that the CA doesn't have to cache the CSR from new-order
3. The "new-order" request still needs to have some = sort of description of the certificate being requested, in order to support legacy back-end interfaces,
4. That description can be either:
=C2=A0 4.1. In the form of a CSR, or
=C2=A0 4.2. In the form of a list of identifiers (as in @cpu&#= 39;s PR [0])

On the one hand, sending a CSR twice seems clumsy (as Hugo notes above) and it makes the server parse the CSR twice.=C2=A0 O= n the other hand, using a CSR both times makes the client logic a bit simpler since you just send the same thing in both requests.

Anyone else have thoughts here?

--Richard





On Mon, Oct 30, 2017 at 3:48 PM, Daniel McCarney <cpu@letsencrypt.org> wrote:
Wouldn't it be a lot better not to do the validations at all if you can tell at new-order time that you're not going to b= e willing to issue?

Yes, that would be better in this one capacity. However I don't think it comes close to justify the scaling issues associated with accepting the CSR up-front, and as mentioned, there are other reasons why validations may occur for an order that the CA isn't willing to issue at the time of finalization.
There also isn't a CAA-PKP so we're bikeshedding = about impact on features that are both unspecified & unimplemented.=C2=A0

- Daniel / cpu

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


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

Can you expand on "annoying"= ;?

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

Wouldn't it be a lot better not to d= o the validations at all if you can tell at new-order time that you're not going to be willing to issue?

=C2=A0
In-fact, we already have to be rechecking CAA for authorizations validated more than 8 hours ago at the time of issuance so there must be code in place to check CAA at finalization and clients must be prepared for their order to be rejected at finalization based on CAA already.

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

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

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

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



-Ilari


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






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


--001a113949f0b3d5e8055d0047f5-- From nobody Thu Nov 2 07:02:09 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2838A13B42C for ; Thu, 2 Nov 2017 07:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Ou9hg5hdw6YY for ; Thu, 2 Nov 2017 07:02:05 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E185138BCD for ; Thu, 2 Nov 2017 07:01:55 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id m81so14139856ioi.13 for ; Thu, 02 Nov 2017 07:01:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=g2OP0gfN9pnvkZJdA+QoV2ITmcJqpojGJufGLxGoB10=; b=UgkO5m1z72vnofh+Fv2yNPyZxDIop/5vj4KEwKdnmUNgYD/ekGgzGuomc1Tat2Q+xd xaQyLhyZ8Bbld4nmbBYxx1x67NO6JqcrA00HL3C8NSTCWUkzjzWph/9ZZuJ8cYh1EqRl VUowedb+k9Z/auu5tFuDKTjBdlWgh8dA6MCXU= 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=g2OP0gfN9pnvkZJdA+QoV2ITmcJqpojGJufGLxGoB10=; b=SskQfvw6a6lv0ke56y6X+Rmz1c7/0IfUZMGTS9rjiACowSA+Ggut4MFDfSmBcdsnL5 VwwFtWj7TozA9MyQ0eYCfD/Yi8mfSu5fFn4xLK/knDxuIgAQ6bg6CCAMix4SGHyWgGLP 9JMUHUTmKTWTfljOIDrotjJvFRn0eXytnV4JzaOBZCsAiwsefl4BSVwuLiUU9zTBiwsm GZUkpCsBLHKO5MUs0enFr0Zgz1/5TSeYGgpNu46eP8KsivziPXNHtW6bmW5+kJk+1/3u AnVjgCFnHpguDn+/cezfTp1+NzL/fSu1Row854fWx03aVGTH3NdyoVqcLbXQZeeSADYH Fs+A== X-Gm-Message-State: AMCzsaUU0lrr5J3imKtcq12ET+sG0/fQKT7mVQ+dhqksTpGwO2+3TaA8 raxiuD1OKdciPJRFyrlnMC2ffDSa8jxv8IZ1SnsVjbMzEYQ= X-Google-Smtp-Source: ABhQp+TW1LArFOfHsHvGUAwpmX1PsgFOM9jx7YP1gAvyauDIEBD/4hWwKpSnqM+DCrrTO/SvSBO7lEDfzwoEF7Oin+g= X-Received: by 10.36.124.197 with SMTP id a188mr2578064itd.53.1509631314372; Thu, 02 Nov 2017 07:01:54 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.88.21 with HTTP; Thu, 2 Nov 2017 07:01:53 -0700 (PDT) In-Reply-To: References: From: Daniel McCarney Date: Thu, 2 Nov 2017 10:01:53 -0400 Message-ID: To: Mads Egil Henriksveen Cc: IETF ACME Content-Type: multipart/alternative; boundary="001a114a95ec3c52ab055d006e4e" Archived-At: Subject: Re: [Acme] Survey of draft-07 implementations X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 14:02:07 -0000 --001a114a95ec3c52ab055d006e4e Content-Type: text/plain; charset="UTF-8" Hi Mads, Happy to hear about another implementation! Thanks for replying. We are also running a constrained pilot in our production environment > (supporting CertBot) and this will be upgraded to the ACME draft-07 version > shortly. What is your plan for testing your draft-07 pilot? It sounds like you only target Certbot and there is no order based issuance support in Certbot presently (among other divergences with draft-07/08). However, we are considering to use the Out-of-Band Challenge type and > possibly also External Account Binding in a next phase where the idea is to > exploit how the ACME protocol may be used to support issuance and > administration of other types of TLS certificates than DV. Can you speak to when this phase may begin/end? I worry that it will be too late for any implementation experience to be able to influence the draft if this phase of your project won't be complete for some time. - Daniel / cpu On Sat, Oct 21, 2017 at 2:56 AM, Mads Egil Henriksveen < Mads.Henriksveen@buypass.no> wrote: > Hi > > > > Buypass has implemented an ACME server based on ACME draft-07 which use > order based issuance, this version is currently available in a test > environment only. We are also running a constrained pilot in our production > environment (supporting CertBot) and this will be upgraded to the ACME > draft-07 version shortly. > > > > We have included support for Pre-Authorization, but we are not using > neither External Account Binding nor the Out-of-Band Challenge in our > current version. However, we are considering to use the Out-of-Band > Challenge type and possibly also External Account Binding in a next phase > where the idea is to exploit how the ACME protocol may be used to support > issuance and administration of other types of TLS certificates than DV. > > > > Regards > > Mads > > > > *From:* Acme [mailto:acme-bounces@ietf.org] *On Behalf Of *Daniel McCarney > *Sent:* fredag 20. oktober 2017 22:36 > *To:* IETF ACME > *Subject:* [Acme] Survey of draft-07 implementations > > > > Hi folks, > > > > As the WG approaches last-call on ACME draft-07[0] I wanted to get a sense > of which portions of the spec have been implemented and which haven't. > > > > In particular I'd like to hear if anyone has implemented: > > * External Account Binding (Section 7.3.5) > > * Pre-Authorization for Order based issuance (Section 7.4.1) > > * The Out-of-Band Challenge type (Section 8.6) > > > > Let's Encrypt has made good progress on draft-07 server implementation but > has no plans to implement the above three features. It would be nice to > hear someone has running code for these protions of spec. > > > > Ignoring the above three items Let's Encrypt has implemented the core > portions of draft-07 in Pebble[1]. It's presently using the pro-active > issuance method described in draft-07. It does not support key change or > revocation but is ready to be used by clients. There is an integration test > client[2] based on Certbot's ACME python module and ACME4j has an > experimental branch[3] capable of issuing certificates from Pebble. > > > > Let's Encrypt has also made significant progress implementing draft-07 in > Boulder[4], the production Let's Encrypt CA software, but it is not yet > ready for use by clients. This implementation does include key change and > revocation but does **not** use pro-active issuance. I began a separate > thread[5] for the order finalization approach that we have started to > implement for Boulder. Pebble will be updated to use this issuance approach > in place of pro-active issuance shortly. > > > > Are there any other servers or clients out there that are speaking > draft-07 ACME and using order based issuance? > > > > - Daniel / cpu > > > > [0]: https://tools.ietf.org/html/draft-ietf-acme-acme-07 > > [1]: https://github.com/letsencrypt/pebble > > [2]: https://github.com/letsencrypt/boulder/blob/ > e2cc6fbe682dd5d49da32c2357838b0cc831f10f/test/chisel2.py > > [3]: https://github.com/shred/acme4j/tree/draft > > [4]: https://github.com/letsencrypt/boulder > > [5]: https://mailarchive.ietf.org/arch/msg/acme/ > DIjJEB06J5cFyuOlGPVcY2I51vg > --001a114a95ec3c52ab055d006e4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mads,

Happy to hear about another implementation= ! Thanks for replying.

We are also running a constrained pilot in our production environment = (supporting CertBot) and this will be upgraded to the ACME draft-07 version= shortly.

What is your plan for testing your draft-07 = pilot? It sounds like you only target Certbot and there is no order based i= ssuance support in Certbot presently (among other divergences with draft-07= /08).

=C2=A0Howeve= r, we are considering to use the Out-of-Band Challenge type and possibly al= so External Account Binding in a next phase where the idea is to exploit ho= w the ACME protocol may be used to support issuance and administration of o= ther types of TLS certificates than DV.

Can you speak = to when this phase may begin/end? I worry that it will be too late for any = implementation experience to be able to influence the draft if this phase o= f your project won't be complete for some time.

- Daniel / cpu= =C2=A0

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

Hi

=C2=A0

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

=C2=A0

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

=C2=A0

Regards<= /span>

Mads

=C2=A0

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

=C2=A0

Hi folks,

=C2=A0

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

=C2=A0

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

* External Account Binding (Section 7.3.5)=

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

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

=C2=A0

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

=C2=A0

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

=C2=A0

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

=C2=A0

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

=C2=A0

- Daniel / cpu

=C2=A0

--001a114a95ec3c52ab055d006e4e-- From nobody Thu Nov 2 07:07: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 49C6413F87F for ; Thu, 2 Nov 2017 07:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 NUEfe_3jiGFo for ; Thu, 2 Nov 2017 07:07:00 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB39813F723 for ; Thu, 2 Nov 2017 07:06:59 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id b186so14210089iof.8 for ; Thu, 02 Nov 2017 07:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UFwICP6NMELx4GctohnzuKXUCxVMV0PUk1a80FN7aMQ=; b=c9ohmnzg+eFjguKDkxfuBgmeiGoi2yOs5aHM/QOPQM1Um0yIMVqzIy0uyswvayXTUT Var6roilhKPfRjyze61FH0ZnxjeaJl+/lL8pZhMKpYwQtCymhsj9+GstmXb3WN2aczRl wXzbVPa37nI3dURr5M9RG5PygDtl6/mhrseyo= 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=UFwICP6NMELx4GctohnzuKXUCxVMV0PUk1a80FN7aMQ=; b=s/Y61atRDGgj6evjRAy2+iYHnIBoM1nL3Yb4+5PRX5AmEY29ak8FGgLaJJeybqHN6V 00J2sM6/jX6t/csIGlf/F7YeLSNIXrEZS+pgHfkTf7GUfSFhqkQmVDX9ZRccptQsO/b9 njNdYM7SqBuatFIPItKUCzsmtTV/ogciM0mgBndJtcImMd86t32Zkb0ugpoLQd2egOfQ HarcpkeBRQO1Tlm3ntiYzyT4cZEg4LNPQ74U5oB+6/C8JIipSNqqfJZ8ePSEqh0Kl7SM 2fYx3Jy49RzEoOsA0ElR2TOeF4oPp3KstneZTRmhOhsgfsiIWrhZQpHjlPQF+dIDZu43 pF0g== X-Gm-Message-State: AMCzsaUstUf3FWXQUCbyO1TTV9klx3ldw2OjtlVOInDitt/KP8lgahIg fNpK8qhfLOumqzfCkV8U7fAu+KKZuWnfdB8echj3NA== X-Google-Smtp-Source: ABhQp+SLQG+NwycE6oQzU6uuKIZVoA3JRD1Kzm2kur6V48GFnX2ekok75JhSaxKfbUSbGi9F9/0VdVcZP2ZEjZzHrpo= X-Received: by 10.107.43.75 with SMTP id r72mr4612323ior.31.1509631619199; Thu, 02 Nov 2017 07:06:59 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.88.21 with HTTP; Thu, 2 Nov 2017 07:06:58 -0700 (PDT) In-Reply-To: References: From: Daniel McCarney Date: Thu, 2 Nov 2017 10:06:58 -0400 Message-ID: To: Clint Wilson Cc: Mads Egil Henriksveen , IETF ACME Content-Type: multipart/alternative; boundary="001a113949f0679330055d00802c" Archived-At: Subject: Re: [Acme] Survey of draft-07 implementations X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 14:07:02 -0000 --001a113949f0679330055d00802c Content-Type: text/plain; charset="UTF-8" So far it sounds like there are no implementations of the OOB challenge type. Given the feedback from Clint about the external account binding feature being sufficient for their needs so far is there a strong reason to include OOB challenges at all? If I remember the discussion right this challenge type was added specifically to facilitate non-ACME "legacy" CAs. So far a call for implementations has heard from two such CAs and neither have implemented OOB challenges or have a fixed schedule for when they might. Perhaps it would be better to remove OOB challenges from the specification and treat it as follow-up work once there are implementations and CAs expressing interest in deploying them? I think this would be preferable to finalizing the standardization of a mechanism that no one has implemented ("Rough consensus and running code"...). (As an aside: Have any ACME **clients** implemented External Account Binding or OOB challenges? Server support is only 1/2 of the battle) - Daniel / cpu On Sat, Oct 21, 2017 at 4:15 PM, Clint Wilson wrote: > Hi team! > > DigiCert has implemented a proof of concept ACME server using ACME > draft-07. We utilize External Account Binding, but not Out-of-Band > Challenges nor Pre-Authorization, though both are of potential interest to > us in the future. We currently handle both of those by way of the External > Account Binding, which provides the full context of a customer account, and > therefore has the support of Pre-Authorization functions and our > Support/Validation teams to assist with Out-of-Band Challenges. Our > interest in ACME would be the potential complete automation of those steps, > but given the available workaround, we opted to not focus on supporting > that yet. > > Cheers! > -Clint > > > On Sat, Oct 21, 2017 at 12:56 AM Mads Egil Henriksveen < > Mads.Henriksveen@buypass.no> wrote: > >> Hi >> >> >> >> Buypass has implemented an ACME server based on ACME draft-07 which use >> order based issuance, this version is currently available in a test >> environment only. We are also running a constrained pilot in our production >> environment (supporting CertBot) and this will be upgraded to the ACME >> draft-07 version shortly. >> >> >> >> We have included support for Pre-Authorization, but we are not using >> neither External Account Binding nor the Out-of-Band Challenge in our >> current version. However, we are considering to use the Out-of-Band >> Challenge type and possibly also External Account Binding in a next phase >> where the idea is to exploit how the ACME protocol may be used to support >> issuance and administration of other types of TLS certificates than DV. >> >> >> >> Regards >> >> Mads >> >> >> >> *From:* Acme [mailto:acme-bounces@ietf.org] *On Behalf Of *Daniel >> McCarney >> *Sent:* fredag 20. oktober 2017 22:36 >> *To:* IETF ACME >> *Subject:* [Acme] Survey of draft-07 implementations >> >> >> >> Hi folks, >> >> >> >> As the WG approaches last-call on ACME draft-07[0] I wanted to get a >> sense of which portions of the spec have been implemented and which haven't. >> >> >> >> In particular I'd like to hear if anyone has implemented: >> >> * External Account Binding (Section 7.3.5) >> >> * Pre-Authorization for Order based issuance (Section 7.4.1) >> >> * The Out-of-Band Challenge type (Section 8.6) >> >> >> >> Let's Encrypt has made good progress on draft-07 server implementation >> but has no plans to implement the above three features. It would be nice to >> hear someone has running code for these protions of spec. >> >> >> >> Ignoring the above three items Let's Encrypt has implemented the core >> portions of draft-07 in Pebble[1]. It's presently using the pro-active >> issuance method described in draft-07. It does not support key change or >> revocation but is ready to be used by clients. There is an integration test >> client[2] based on Certbot's ACME python module and ACME4j has an >> experimental branch[3] capable of issuing certificates from Pebble. >> >> >> >> Let's Encrypt has also made significant progress implementing draft-07 in >> Boulder[4], the production Let's Encrypt CA software, but it is not yet >> ready for use by clients. This implementation does include key change and >> revocation but does **not** use pro-active issuance. I began a separate >> thread[5] for the order finalization approach that we have started to >> implement for Boulder. Pebble will be updated to use this issuance approach >> in place of pro-active issuance shortly. >> >> >> >> Are there any other servers or clients out there that are speaking >> draft-07 ACME and using order based issuance? >> >> >> >> - Daniel / cpu >> >> >> >> [0]: https://tools.ietf.org/html/draft-ietf-acme-acme-07 >> >> [1]: https://github.com/letsencrypt/pebble >> >> [2]: https://github.com/letsencrypt/boulder/blob/ >> e2cc6fbe682dd5d49da32c2357838b0cc831f10f/test/chisel2.py >> >> [3]: https://github.com/shred/acme4j/tree/draft >> >> [4]: https://github.com/letsencrypt/boulder >> >> [5]: https://mailarchive.ietf.org/arch/msg/acme/ >> DIjJEB06J5cFyuOlGPVcY2I51vg >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> > --001a113949f0679330055d00802c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So far it sounds like there are no implementations of the = OOB challenge type. Given the feedback from Clint about the external accoun= t binding feature being sufficient for their needs so far is there a strong= reason to include OOB challenges at all?

If I remember the discussi= on right this challenge type was added specifically to facilitate non-ACME = "legacy" CAs. So far a call for implementations has heard from tw= o such CAs and neither have implemented OOB challenges or have a fixed sche= dule for when they might.
Perhaps it would be better to remove OOB chall= enges from the specification and treat it as follow-up work once there are = implementations and CAs expressing interest in deploying them? I think this= would be preferable to finalizing the standardization of a mechanism that = no one has implemented ("Rough consensus and running code"...).= =C2=A0

(As an aside: Have any ACME **clients** implemented External = Account Binding or OOB challenges? Server support is only 1/2 of the battle= )

- Daniel / cpu
<= br>
On Sat, Oct 21, 2017 at 4:15 PM, Clint Wilson= <clint.t.wilson@gmail.com> wrote:
Hi team!

DigiCert has= implemented a proof of concept ACME server using ACME draft-07. We utilize= External Account Binding, but not Out-of-Band Challenges nor=C2=A0Pre-Auth= orization, though both are of potential interest to us in the future. We cu= rrently handle both of those by way of the External Account Binding, which = provides the full context of a customer account, and therefore has the supp= ort of Pre-Authorization functions and our Support/Validation teams to assi= st with Out-of-Band Challenges. Our interest in ACME would be the potential= complete automation of those steps, but given the available workaround, we= opted to not focus on supporting that yet.

Cheers= !
-Clint


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

Hi

=C2=A0

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

=C2=A0

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

=C2=A0

Regards<= /span>

Mads

=C2=A0

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

=C2=A0

Hi folks,

=C2=A0

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

=C2=A0

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

* External Account Binding (Section 7.3.5)=

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

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

=C2=A0

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

=C2=A0

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

=C2=A0

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

=C2=A0

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

=C2=A0

- Daniel / cpu

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

--001a113949f0679330055d00802c-- From nobody Thu Nov 2 07:15: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 9D02F13F7DA for ; Thu, 2 Nov 2017 07:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nkfR-l2711H0 for ; Thu, 2 Nov 2017 07:15:47 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34B78138BCD for ; Thu, 2 Nov 2017 07:15:47 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id y9so5166291wrb.2 for ; Thu, 02 Nov 2017 07:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+Ik9Alw6nvtHnyD6r03tKhfZUUWPntcH5PRSR3oSVf0=; b=M2DnPy1zDQ+Ye+awkdOz7UrWXAITF87wLscvKNL71G92EXvG6dQhhIyyathTcnIUN3 XnqddXjN2M2J1YWUzojK7mZ0/uTvB89MSx7KuWPWNsSUJpS52mHkgIbu7wfcwjaHrnyi FqXVoMeedwog/F2VZ8JQL7Nuei/P5i+tPab7lFfsLXv0WnHI9vky7M+O8ks56YQSgWaV 1+0nq1HU4CHXHOYL7ziBi8DDAYeGcAqmKKIgyszCA7K9DriCed4UHENXMeL7nJ2V7DsI 09PuuzpKFrZurF5RNtzanxlaXywMRWbKRNyug1uBacCAPdDBS0a2eR+CL7HzjCeDxpZh 0Jfg== 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=+Ik9Alw6nvtHnyD6r03tKhfZUUWPntcH5PRSR3oSVf0=; b=btQcUdB5ibeWRZo2jIRyBcUzo1apFr1IuEEPBNg24Dsd/fKjX3cnsH4/LiZ96lkhvp z9ivfjMsbz146ToSY/IaAEtJtCsXB8hO6Svhg93Ccvk+Z97w2bw2WOpAJ+YalTxCFXzC aToEtIS+ih5lhs/9FH5Vot86ZDeOrXGd9AN/aTe67mMxk92Udha8oumMYXImBnuptTkj Ae41MPKknqFuMgJHsCLv8J6yp+LEo32RoAlUytdU+9vmyZqpUo7cY6UJS4LDigr8XA1+ xIlM47buykZ4XlXxzas7jUP0v4HpyUGziqlvkfNsnikPYJX1G/3FuIItr8ZJJtAlT9hM jeDA== X-Gm-Message-State: AMCzsaV6dvThrHRmNK16+/Qqnz05BRijuN++WCaek/S60qluiHjd7prC wtdXBOa3Ront69afEqDtR5omkikhlgwd/lHc7XAa+A== X-Google-Smtp-Source: ABhQp+Q2lzq9goaJjebf4uJkz3qlEakuTxWcBsnED6ZweGuyN7VZoGoc3mU7MZUNW/O5sA10nrRL+90+VesK4ZY1G6E= X-Received: by 10.223.160.132 with SMTP id m4mr2996413wrm.45.1509632145417; Thu, 02 Nov 2017 07:15:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Thu, 2 Nov 2017 07:15:44 -0700 (PDT) In-Reply-To: References: <71f3e975-7cee-18cf-2635-80eb13adff12@devever.net> <20171024141732.ufjysx5f73pyc5f4@LK-Perkele-VII> <63029bbd-a9d5-0f30-718a-8d78f76a8e82@eff.org> From: Richard Barnes Date: Thu, 2 Nov 2017 10:15:44 -0400 Message-ID: To: Daniel McCarney Cc: Brad Warren , Ilari Liusvaara , Hugo Landau , IETF ACME Content-Type: multipart/alternative; boundary="001a114b4738c4fa72055d009fdf" Archived-At: Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 14:15:50 -0000 --001a114b4738c4fa72055d009fdf Content-Type: text/plain; charset="UTF-8" On Thu, Nov 2, 2017 at 9:51 AM, Daniel McCarney wrote: > This was mentioned in another thread on this topic, but to provide a >> concrete example of where this might be useful, Let's Encrypt currently >> refuses to issue for CSRs containing a weak key. By initially providing the >> CSR, the server is able to immediately reject the request rather than >> waiting until the end of the process. > > > I'm sympathetic to wanting to give this information earlier in the process > but I want to point out again that there will always be the potential for > errors/rejection to happen at the time of finalization/issuance. All > clients will have to handle it whether or not the CSR is included at the > time of new-order. > > I think having two places where the same weak key rejection could occur > will be more complicated. It also means that some orders will have to be > recreated from scratch, making it harder to recover than in the case where > the CSR is only sent at finalization. > > As a concrete example with "double CSR" orders: > > * Client A creates an order with CSR_1, covering "example.com", using > CPU's ACME CA > * Client A fully authorizes their order > * CPU's CA becomes aware of a new vulnerability, RIVESTGATEKEYBLEED and > updates > the weak key policy > * Client A sends CSR_1 again to finalize their order. Oops - it's affected > by RIVESTKEYBLEED and is rejected. > * Client A can not rekey their order and must always send the same CSR as > from the new-order request. Outcome: Client A has to create a brand new > order with CSR_2, potentially redoing all authorizations depending on CA > policy (CPU's CA never reuses authorizations) > > Conversely, if the CSR was only sent at finalization time there would be > only one place for weak-key rejection to occur. If the key policy changed > no orders will have to be recreated, a different finalization CSR can be > sent with the same set of identifiers. Again more concretely: > > * Client A creates an order for identifiers "example.com", no CSR is > included. > * Client A fully authorizes their order > * CPU's CA becomes aware of a new vulnerability, RIVESTGATEKEYBLEED and > updates the weak key policy > * Client A sends CSR_1 covering "example.com" to finalize their order. > Oops - it's affected by RIVESTKEYBLEED and is rejected. > * Client A sends CSR_2 covering "example.com" to finalize their order. It > doesn't use a weak key so the order is finalized. Otucome: Client A gets a > cert. > > Thoughts? In this case it seems like learning later is perhaps an > advantage since the actions available to remediate the error are less > involved. > This doesn't seem like a very convincing line of argument, for a few reasons: - There's not that much time between new-order and finalize (is there?), so it doesn't seem tremendously likely that there will be a change in security posture - Even if there is, there's nothing that says the CA has to behave as you describe. It could: A. Do all the checks on the first shot, at the cost of possibly doing a revocation later B. Do all the checks on the second shot, at the risk of possibly doing some unnecessary authz C. Reuse authorizations, so that the new-order is cheap (Note that the current non-CSR PR is effectively (B), so either case has that risk.) You're basically saying if (1) you do checks both times and (2) you don't re-use authorizations, then you might have to do some unnecessary authz. I would be satisfied to resolve this by saying "you ought not do that". --Richard > > - Daniel / cpu > > > On Wed, Nov 1, 2017 at 6:12 PM, Brad Warren wrote: > >> As a client developer, I slightly prefer submitting the CSR twice. In >> addition to making the request logic a bit simpler, it causes the client to >> provide more information about the cert it would like to obtain earlier in >> the process. This was mentioned in another thread on this topic, but to >> provide a concrete example of where this might be useful, Let's Encrypt >> currently refuses to issue for CSRs containing a weak key. By initially >> providing the CSR, the server is able to immediately reject the request >> rather than waiting until the end of the process. >> >> This approach would mean something else needs to be done to alleviate >> bloat in in the server's database, but I think it provides a better >> experience on the client side. >> On 11/01/2017 09:13 AM, Richard Barnes wrote: >> >> Some of us have been discussing this off-list, and where we got to was >> basically as follows: >> >> 1. We should have some sort of explicit "finalize" request that triggers >> issuance of a certificate >> 2. The finalize request will need to have the CSR attached to it, so that >> the CA doesn't have to cache the CSR from new-order >> 3. The "new-order" request still needs to have some sort of description >> of the certificate being requested, in order to support legacy back-end >> interfaces, >> 4. That description can be either: >> 4.1. In the form of a CSR, or >> 4.2. In the form of a list of identifiers (as in @cpu's PR [0]) >> >> On the one hand, sending a CSR twice seems clumsy (as Hugo notes above) >> and it makes the server parse the CSR twice. On the other hand, using a >> CSR both times makes the client logic a bit simpler since you just send the >> same thing in both requests. >> >> Anyone else have thoughts here? >> >> --Richard >> >> >> [0] https://github.com/ietf-wg-acme/acme/pull/342 >> >> >> >> >> >> On Mon, Oct 30, 2017 at 3:48 PM, Daniel McCarney >> wrote: >> >>> Wouldn't it be a lot better not to do the validations at all if you can >>>> tell at new-order time that you're not going to be willing to issue? >>> >>> >>> Yes, that would be better in this one capacity. However I don't think it >>> comes close to justify the scaling issues associated with accepting the CSR >>> up-front, and as mentioned, there are other reasons why validations may >>> occur for an order that the CA isn't willing to issue at the time of >>> finalization. >>> >>> There also isn't a CAA-PKP so we're bikeshedding about impact on >>> features that are both unspecified & unimplemented. >>> >>> - Daniel / cpu >>> >>> On Mon, Oct 30, 2017 at 3:33 PM, Richard Barnes wrote: >>> >>>> >>>> >>>> On Mon, Oct 30, 2017 at 10:15 AM, Daniel McCarney >>>> wrote: >>>> >>>>> > Example: Suppose that CAA-PKP got added (restrict issuance on SPKI key). >>>>> Implementing that without knowing the public key at validation time >>>>> is annoying. >>>>> >>>>> Can you expand on "annoying"? >>>>> >>>>> It seems completely possible to reject the order finalization message >>>>> based on a CAA-PKP property. >>>>> >>>> >>>> Wouldn't it be a lot better not to do the validations at all if you can >>>> tell at new-order time that you're not going to be willing to issue? >>>> >>>> >>>> >>>>> In-fact, we already have to be rechecking CAA for authorizations >>>>> validated more than 8 hours ago at the time of issuance so there must be >>>>> code in place to check CAA at finalization and clients must be prepared for >>>>> their order to be rejected at finalization based on CAA already. >>>>> >>>>> I don't see how this is any more annoying. >>>>> >>>>> - cpu >>>>> >>>>> On Tue, Oct 24, 2017 at 10:17 AM, Ilari Liusvaara < >>>>> ilariliusvaara@welho.com> wrote: >>>>> >>>>>> On Tue, Oct 24, 2017 at 02:45:01PM +0100, Hugo Landau wrote: >>>>>> > >>>>>> > The ACME protocol should permit CAs to implement policy as far as is >>>>>> > reasonably practicable with regard to the workflows around which the >>>>>> > protocol is organised. Providing the CSR up-front allows the CA to >>>>>> > predicate order processing on aspects of that CSR, both with regard >>>>>> to >>>>>> > the present protocol and any future extensions, both now and in the >>>>>> > future in ways that we can and cannot foresee. I don't think it's >>>>>> > appropriate to defer giving critical information to the CA until the >>>>>> > last minute due to a resource utilisation concern which LE has >>>>>> already >>>>>> > proven capable of dealing with, especially when the whole point of >>>>>> the >>>>>> > order flow in the first place was to provide more flexibility for >>>>>> CAs to >>>>>> > institute policy. >>>>>> >>>>>> Example: Suppose that CAA-PKP got added (restrict issuance on SPKI >>>>>> key). Implementing that without knowing the public key at validation >>>>>> time is annoying. >>>>>> >>>>>> As to why one would want something like that, it would allow limiting >>>>>> trust on certficiate management system without deploying something as >>>>>> dangerous as HPKP. >>>>>> >>>>>> >>>>>> >>>>>> -Ilari >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Acme mailing list >>>>> Acme@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/acme >>>>> >>>>> >>>> >>> >> >> >> _______________________________________________ >> Acme mailing listAcme@ietf.orghttps://www.ietf.org/mailman/listinfo/acme >> >> >> > --001a114b4738c4fa72055d009fdf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Nov 2, 2017 at 9:51 AM, Daniel McCarney <<= a href=3D"mailto:cpu@letsencrypt.org" target=3D"_blank">cpu@letsencrypt.org= > wrote:
<= span class=3D"">
This was = mentioned in another thread on this topic, but to provide a concrete exampl= e of where this might be useful, Let's Encrypt currently refuses to iss= ue for CSRs containing a weak key. By initially providing the CSR, the serv= er is able to immediately reject the request rather than waiting until the = end of the process.

I'm sympathe= tic to wanting to give this information earlier in the process but I want t= o point out again that there will always be the potential for errors/reject= ion to happen at the time of finalization/issuance. All clients will have t= o handle it whether or not the CSR is included at the time of new-order.

I think having two places where the same weak key re= jection could occur will be more complicated. It also means that some order= s will have to be recreated from scratch, making it harder to recover than = in the case where the CSR is only sent at finalization.

As a concrete example with "double CSR" orders:
<= br>
* Client A creates an order with CSR_1, covering "example.com", using CPU= 's ACME=C2=A0 =C2=A0CA
* Client A fully authorizes their orde= r
* CPU's CA becomes aware of a new vulnerability, RIVESTGATEKEYBLEE= D and updates
=C2=A0 the weak key policy
* Client A sen= ds CSR_1 again to finalize their order. Oops - it's affected by RIVESTK= EYBLEED and is rejected.
* Client A can not rekey their order and= must always send the same CSR as from the new-order request. Outcome: Clie= nt A has to create a brand new order with CSR_2, potentially redoing all au= thorizations depending on CA policy (CPU's CA never reuses authorizatio= ns)

Conversely, if the CSR was only sent at finali= zation time there would be only one place for weak-key rejection to occur. = If the key policy changed no orders will have to be recreated, a different = finalization CSR can be sent with the same set of identifiers. Again more c= oncretely:

* Client A creates an order for identif= iers "example.com= ", no CSR is included.
* Client A fully authorizes their ord= er
* CPU's CA becomes aware of a new vulnerability, RIVESTGAT= EKEYBLEED and updates the weak key policy
* Client A sends CSR_1 = covering "example.com= " to finalize their order. Oops - it's affected by RIVESTKEYBL= EED and is rejected.
* Client A sends CSR_2 covering "example.com" to finaliz= e their order. It doesn't use a weak key so the order is finalized. Otu= come: Client A gets a cert.

Thoughts? In this case= it seems like learning later is perhaps an advantage since the actions ava= ilable to remediate the error are less involved.

This doesn't seem like a very convincing line of argu= ment, for a few reasons:

- There's not that mu= ch time between new-order and finalize (is there?), so it doesn't seem = tremendously likely that there will be a change in security posture
- Even if there is, there's nothing that says the CA has to behave a= s you describe.=C2=A0 It could:
=C2=A0 A. Do all the checks on th= e first shot, at the cost of possibly doing a revocation later
= =C2=A0 B. Do all the checks on the second shot, at the risk of possibly doi= ng some unnecessary authz
=C2=A0 C. Reuse authorizations, so = that the new-order is cheap

(Note that the cur= rent non-CSR PR is effectively (B), so either case has that risk.)=C2=A0 Yo= u're basically saying if (1) you do checks both times and (2) you don&#= 39;t re-use authorizations, then you might have to do some unnecessary auth= z.=C2=A0 I would be satisfied to resolve this by saying "you ought not= do that".

--Richard

=C2=A0
<= br>
- Daniel / cpu


On Wed, Nov 1, 2017 = at 6:12 PM, Brad Warren <bmw@eff.org> wrote:
=20 =20 =20

As a client developer, I slightly prefer submitting the CSR twice. In addition to making the request logic a bit simpler, it causes the client to provide more information about the cert it would like to obtain earlier in the process. This was mentioned in another thread on this topic, but to provide a concrete example of where this might be useful, Let's Encrypt currently refuses to issue for CSRs containing a weak key. By initially providing the CSR, the server is able to immediately reject the request rather than waiting until the end of the process.

This approach would mean something else needs to be done to alleviate bloat in in the server's database, but I think it provides a better experience on the client side.

On 11/01/2017 09:13 AM, Richard Barnes wrote:
Some of us have been discussing this off-list, and where we got to was basically as follows:

1. We should have some sort of explicit "finalize" r= equest that triggers issuance of a certificate
2. The finalize request will need to have the CSR attached to it, so that the CA doesn't have to cache the CSR from new-order
3. The "new-order" request still needs to have some = sort of description of the certificate being requested, in order to support legacy back-end interfaces,
4. That description can be either:
=C2=A0 4.1. In the form of a CSR, or
=C2=A0 4.2. In the form of a list of identifiers (as in @cpu&#= 39;s PR [0])

On the one hand, sending a CSR twice seems clumsy (as Hugo notes above) and it makes the server parse the CSR twice.=C2=A0 O= n the other hand, using a CSR both times makes the client logic a bit simpler since you just send the same thing in both requests.

Anyone else have thoughts here?

--Richard







On Mon, Oct 30, 2017 at 3:48 PM, Daniel McCarney <cpu@letsencrypt.org> wrote:
Wouldn't it be a lot better not to do the validations at all if you can tell at new-order time that you're not going to b= e willing to issue?

Yes, that would be better in this one capacity. However I don't think it comes close to justify the scaling issues associated with accepting the CSR up-front, and as mentioned, there are other reasons why validations may occur for an order that the CA isn't willing to issue at the time of finalization.
There also isn't a CAA-PKP so we're bikeshedding = about impact on features that are both unspecified & unimplemented.=C2=A0

- Daniel / cpu

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


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

Can you expand on "annoying"= ;?

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

Wouldn't it be a lot better not to d= o the validations at all if you can tell at new-order time that you're not going to be willing to issue?

=C2=A0
In-fact, we already have to be rechecking CAA for authorizations validated more than 8 hours ago at the time of issuance so there must be code in place to check CAA at finalization and clients must be prepared for their order to be rejected at finalization based on CAA already.

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

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

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

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


-Ilari


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






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



--001a114b4738c4fa72055d009fdf-- From nobody Thu Nov 2 07:30:06 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 3349213F8C4 for ; Thu, 2 Nov 2017 07:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 e86DEByHb4Ty for ; Thu, 2 Nov 2017 07:30:00 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7944F13F66C for ; Thu, 2 Nov 2017 07:30:00 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id m81so14357725ioi.13 for ; Thu, 02 Nov 2017 07:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=gm2tXnxeNu8GeIUg6nHEid4rB/hl5v6G5XeuFoh0ylc=; b=LiGwTTjDeuD0SceLyjCgan07WzfNm+jjHsfn/dg9SlyGAnJwoYT/R1upSleAicMrLd PfDJ9m+yvyJS2WVzwN+1ChrOyerESosNvC2E9GQQEdZYjO272Sz/Qucezn2hCA6Xa2L2 0j2ufY+hE3fRF3kxuqIGTntaKFS2PHD4//CMM= 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=gm2tXnxeNu8GeIUg6nHEid4rB/hl5v6G5XeuFoh0ylc=; b=KecbTEAv3rvvkHLNp3MrhIVvPtiCzxpEAZIIGoqdNDXVsi3peW/h2F7OBLF1klfw6v 40SUz/5oCPm4goIe5FU2UpGY+vw0LWYN4tbChe0MjkhJUv5dx9TCJGAkLiPpBmnAkuvi DoRBBlDtadyW6lNCtkIdADbz+i6cPI0MW2EHRvKKQRdvXUGBwNxlEDZVE/c+THH8HEIr aripGLOlBXsCNpeLkUZxBrMo5L6LW1Bup9gaHqhMzg804aau74MrL7WfW3FCmpC4wE8f ip+VlqUUXQVRZYzAsY7DcIgpOqyGxiydmNB5bjt3QnEgUFscIA1n3RzPeqyAa0icaAmh 5/Pg== X-Gm-Message-State: AJaThX6uoCl+R8GKAMRRibN3yTG31LmF/zliy5iAciR44g5M9xubbZeT o5x7/jwFfp/1VFl1vqxH9lNR/0QO7cFgXDo32OP5TPZFDKs= X-Google-Smtp-Source: ABhQp+RxeBBy+DG98z9gDjGpvw0I2hASFxyuyENOXZLEAcUR2tN0FfC/OY+BNxoyz2jYtj34g61+AaEIo07L5OWfeHU= X-Received: by 10.107.170.29 with SMTP id t29mr4623343ioe.73.1509632999548; Thu, 02 Nov 2017 07:29:59 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.88.21 with HTTP; Thu, 2 Nov 2017 07:29:58 -0700 (PDT) In-Reply-To: References: <71f3e975-7cee-18cf-2635-80eb13adff12@devever.net> <20171024141732.ufjysx5f73pyc5f4@LK-Perkele-VII> <63029bbd-a9d5-0f30-718a-8d78f76a8e82@eff.org> From: Daniel McCarney Date: Thu, 2 Nov 2017 10:29:58 -0400 Message-ID: To: Richard Barnes Cc: Brad Warren , Ilari Liusvaara , Hugo Landau , IETF ACME Content-Type: multipart/alternative; boundary="001a1142df5eae1dc0055d00d28f" Archived-At: Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 14:30:04 -0000 --001a1142df5eae1dc0055d00d28f Content-Type: text/plain; charset="UTF-8" > > - There's not that much time between new-order and finalize (is there?), > so it doesn't seem tremendously likely that there will be a change in > security posture [ citation needed ] A. Do all the checks on the first shot, at the cost of possibly doing a > revocation later Is this the kind of behaviour we want to encourage for CAs? I realize ACME doesn't address policy questions but it also shouldn't encourage sloppy behaviour from CAs with its design. You're basically saying if (1) you do checks both times and (2) you don't > re-use authorizations, then you might have to do some unnecessary authz. I > would be satisfied to resolve this by saying "you ought not do that". I'm trying to point out that sending the CSR twice seems like it makes client development easier but there are corner cases that do not match that assessment. We can try to reduce the corner cases with a warning that "you ought not do that" but there will be server implementations that ignore that recommendation and clients will likely have to update their implementations to accommodate this reality. I understand that these corner cases aren't a super convincing line of argument, but I also don't think a slight preference for double CSR strictly because it allows delivering a public key rejection error slightly earlier in the order flow is a very convincing argument either. Does someone have something stronger in mind? - Daniel / cpu On Thu, Nov 2, 2017 at 10:15 AM, Richard Barnes wrote: > > > On Thu, Nov 2, 2017 at 9:51 AM, Daniel McCarney > wrote: > >> This was mentioned in another thread on this topic, but to provide a >>> concrete example of where this might be useful, Let's Encrypt currently >>> refuses to issue for CSRs containing a weak key. By initially providing the >>> CSR, the server is able to immediately reject the request rather than >>> waiting until the end of the process. >> >> >> I'm sympathetic to wanting to give this information earlier in the >> process but I want to point out again that there will always be the >> potential for errors/rejection to happen at the time of >> finalization/issuance. All clients will have to handle it whether or not >> the CSR is included at the time of new-order. >> >> I think having two places where the same weak key rejection could occur >> will be more complicated. It also means that some orders will have to be >> recreated from scratch, making it harder to recover than in the case where >> the CSR is only sent at finalization. >> >> As a concrete example with "double CSR" orders: >> >> * Client A creates an order with CSR_1, covering "example.com", using >> CPU's ACME CA >> * Client A fully authorizes their order >> * CPU's CA becomes aware of a new vulnerability, RIVESTGATEKEYBLEED and >> updates >> the weak key policy >> * Client A sends CSR_1 again to finalize their order. Oops - it's >> affected by RIVESTKEYBLEED and is rejected. >> * Client A can not rekey their order and must always send the same CSR as >> from the new-order request. Outcome: Client A has to create a brand new >> order with CSR_2, potentially redoing all authorizations depending on CA >> policy (CPU's CA never reuses authorizations) >> >> Conversely, if the CSR was only sent at finalization time there would be >> only one place for weak-key rejection to occur. If the key policy changed >> no orders will have to be recreated, a different finalization CSR can be >> sent with the same set of identifiers. Again more concretely: >> >> * Client A creates an order for identifiers "example.com", no CSR is >> included. >> * Client A fully authorizes their order >> * CPU's CA becomes aware of a new vulnerability, RIVESTGATEKEYBLEED and >> updates the weak key policy >> * Client A sends CSR_1 covering "example.com" to finalize their order. >> Oops - it's affected by RIVESTKEYBLEED and is rejected. >> * Client A sends CSR_2 covering "example.com" to finalize their order. >> It doesn't use a weak key so the order is finalized. Otucome: Client A gets >> a cert. >> >> Thoughts? In this case it seems like learning later is perhaps an >> advantage since the actions available to remediate the error are less >> involved. >> > > This doesn't seem like a very convincing line of argument, for a few > reasons: > > - There's not that much time between new-order and finalize (is there?), > so it doesn't seem tremendously likely that there will be a change in > security posture > - Even if there is, there's nothing that says the CA has to behave as you > describe. It could: > A. Do all the checks on the first shot, at the cost of possibly doing a > revocation later > B. Do all the checks on the second shot, at the risk of possibly doing > some unnecessary authz > C. Reuse authorizations, so that the new-order is cheap > > (Note that the current non-CSR PR is effectively (B), so either case has > that risk.) You're basically saying if (1) you do checks both times and > (2) you don't re-use authorizations, then you might have to do some > unnecessary authz. I would be satisfied to resolve this by saying "you > ought not do that". > > --Richard > > > >> >> - Daniel / cpu >> >> >> On Wed, Nov 1, 2017 at 6:12 PM, Brad Warren wrote: >> >>> As a client developer, I slightly prefer submitting the CSR twice. In >>> addition to making the request logic a bit simpler, it causes the client to >>> provide more information about the cert it would like to obtain earlier in >>> the process. This was mentioned in another thread on this topic, but to >>> provide a concrete example of where this might be useful, Let's Encrypt >>> currently refuses to issue for CSRs containing a weak key. By initially >>> providing the CSR, the server is able to immediately reject the request >>> rather than waiting until the end of the process. >>> >>> This approach would mean something else needs to be done to alleviate >>> bloat in in the server's database, but I think it provides a better >>> experience on the client side. >>> On 11/01/2017 09:13 AM, Richard Barnes wrote: >>> >>> Some of us have been discussing this off-list, and where we got to was >>> basically as follows: >>> >>> 1. We should have some sort of explicit "finalize" request that triggers >>> issuance of a certificate >>> 2. The finalize request will need to have the CSR attached to it, so >>> that the CA doesn't have to cache the CSR from new-order >>> 3. The "new-order" request still needs to have some sort of description >>> of the certificate being requested, in order to support legacy back-end >>> interfaces, >>> 4. That description can be either: >>> 4.1. In the form of a CSR, or >>> 4.2. In the form of a list of identifiers (as in @cpu's PR [0]) >>> >>> On the one hand, sending a CSR twice seems clumsy (as Hugo notes above) >>> and it makes the server parse the CSR twice. On the other hand, using a >>> CSR both times makes the client logic a bit simpler since you just send the >>> same thing in both requests. >>> >>> Anyone else have thoughts here? >>> >>> --Richard >>> >>> >>> [0] https://github.com/ietf-wg-acme/acme/pull/342 >>> >>> >>> >>> >>> >>> On Mon, Oct 30, 2017 at 3:48 PM, Daniel McCarney >>> wrote: >>> >>>> Wouldn't it be a lot better not to do the validations at all if you can >>>>> tell at new-order time that you're not going to be willing to issue? >>>> >>>> >>>> Yes, that would be better in this one capacity. However I don't think >>>> it comes close to justify the scaling issues associated with accepting the >>>> CSR up-front, and as mentioned, there are other reasons why validations may >>>> occur for an order that the CA isn't willing to issue at the time of >>>> finalization. >>>> >>>> There also isn't a CAA-PKP so we're bikeshedding about impact on >>>> features that are both unspecified & unimplemented. >>>> >>>> - Daniel / cpu >>>> >>>> On Mon, Oct 30, 2017 at 3:33 PM, Richard Barnes wrote: >>>> >>>>> >>>>> >>>>> On Mon, Oct 30, 2017 at 10:15 AM, Daniel McCarney >>>> > wrote: >>>>> >>>>>> > Example: Suppose that CAA-PKP got added (restrict issuance on SPKI key). >>>>>> Implementing that without knowing the public key at validation time >>>>>> is annoying. >>>>>> >>>>>> Can you expand on "annoying"? >>>>>> >>>>>> It seems completely possible to reject the order finalization message >>>>>> based on a CAA-PKP property. >>>>>> >>>>> >>>>> Wouldn't it be a lot better not to do the validations at all if you >>>>> can tell at new-order time that you're not going to be willing to issue? >>>>> >>>>> >>>>> >>>>>> In-fact, we already have to be rechecking CAA for authorizations >>>>>> validated more than 8 hours ago at the time of issuance so there must be >>>>>> code in place to check CAA at finalization and clients must be prepared for >>>>>> their order to be rejected at finalization based on CAA already. >>>>>> >>>>>> I don't see how this is any more annoying. >>>>>> >>>>>> - cpu >>>>>> >>>>>> On Tue, Oct 24, 2017 at 10:17 AM, Ilari Liusvaara < >>>>>> ilariliusvaara@welho.com> wrote: >>>>>> >>>>>>> On Tue, Oct 24, 2017 at 02:45:01PM +0100, Hugo Landau wrote: >>>>>>> > >>>>>>> > The ACME protocol should permit CAs to implement policy as far as >>>>>>> is >>>>>>> > reasonably practicable with regard to the workflows around which >>>>>>> the >>>>>>> > protocol is organised. Providing the CSR up-front allows the CA to >>>>>>> > predicate order processing on aspects of that CSR, both with >>>>>>> regard to >>>>>>> > the present protocol and any future extensions, both now and in the >>>>>>> > future in ways that we can and cannot foresee. I don't think it's >>>>>>> > appropriate to defer giving critical information to the CA until >>>>>>> the >>>>>>> > last minute due to a resource utilisation concern which LE has >>>>>>> already >>>>>>> > proven capable of dealing with, especially when the whole point of >>>>>>> the >>>>>>> > order flow in the first place was to provide more flexibility for >>>>>>> CAs to >>>>>>> > institute policy. >>>>>>> >>>>>>> Example: Suppose that CAA-PKP got added (restrict issuance on SPKI >>>>>>> key). Implementing that without knowing the public key at validation >>>>>>> time is annoying. >>>>>>> >>>>>>> As to why one would want something like that, it would allow limiting >>>>>>> trust on certficiate management system without deploying something as >>>>>>> dangerous as HPKP. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -Ilari >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Acme mailing list >>>>>> Acme@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/acme >>>>>> >>>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> Acme mailing listAcme@ietf.orghttps://www.ietf.org/mailman/listinfo/acme >>> >>> >>> >> > --001a1142df5eae1dc0055d00d28f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
- There&= #39;s not that much time between new-order and finalize (is there?), so it = doesn't seem tremendously likely that there will be a change in securit= y posture

[ citation needed ]

=C2=A0=C2= =A0 A. Do all the checks on the first shot, at the cost of possibly doing a= revocation later

Is this the kind of behaviour= we want to encourage for CAs? I realize ACME doesn't address policy qu= estions but it also shouldn't encourage sloppy behaviour from CAs with = its design.

You're basically saying if (1) you do checks= both times and (2) you don't re-use authorizations, then you might hav= e to do some unnecessary authz.=C2=A0 I would be satisfied to resolve this = by saying "you ought not do that".

I&= #39;m trying to point out that sending the CSR twice seems like it makes cl= ient development easier but there are corner cases that do not match that a= ssessment. We can try to reduce the corner cases with a warning that "= you ought not do that" but there will be server implementations that i= gnore that recommendation and clients will likely have to update their impl= ementations to accommodate this reality.

I understand that these cor= ner cases aren't a super convincing line of argument, but I also don= 9;t think a slight preference for double CSR strictly because it allows del= ivering a public key rejection error slightly earlier in the order flow is = a very convincing argument either. Does someone have something stronger in = mind?

- Daniel / cpu=C2=A0
=C2=A0

=C2=A0



On Thu, Nov 2, 2017 = at 10:15 AM, Richard Barnes <rlb@ipv.sx> wrote:


On Thu, Nov 2, 2017 at 9:51 AM, Daniel = McCarney <cpu@letsencrypt.org> wrote:
This was mentioned in another thread on this topic, but to prov= ide a concrete example of where this might be useful, Let's Encrypt cur= rently refuses to issue for CSRs containing a weak key. By initially provid= ing the CSR, the server is able to immediately reject the request rather th= an waiting until the end of the process.

=
I'm sympathetic to wanting to give this information earlier in the= process but I want to point out again that there will always be the potent= ial for errors/rejection to happen at the time of finalization/issuance. Al= l clients will have to handle it whether or not the CSR is included at the = time of new-order.

I think having two places where= the same weak key rejection could occur will be more complicated. It also = means that some orders will have to be recreated from scratch, making it ha= rder to recover than in the case where the CSR is only sent at finalization= .

As a concrete example with "double CSR"= ; orders:

* Client A creates an order with CSR_1, = covering "example.com= ", using CPU's ACME=C2=A0 =C2=A0CA
* Client A fully = authorizes their order
* CPU's CA becomes aware of a new vulnerabili= ty, RIVESTGATEKEYBLEED and updates
=C2=A0 the weak key policy
* Client A sends CSR_1 again to finalize their order. Oops - it'= s affected by RIVESTKEYBLEED and is rejected.
* Client A can not = rekey their order and must always send the same CSR as from the new-order r= equest. Outcome: Client A has to create a brand new order with CSR_2, poten= tially redoing all authorizations depending on CA policy (CPU's CA neve= r reuses authorizations)

Conversely, if the CSR wa= s only sent at finalization time there would be only one place for weak-key= rejection to occur. If the key policy changed no orders will have to be re= created, a different finalization CSR can be sent with the same set of iden= tifiers. Again more concretely:

* Client A creates= an order for identifiers "example.com", no CSR is included.
* Client A fully= authorizes their order
* CPU's CA becomes aware of a new vul= nerability, RIVESTGATEKEYBLEED and updates the weak key policy
* = Client A sends CSR_1 covering "example.com" to finalize their order. Oops - it's = affected by RIVESTKEYBLEED and is rejected.
* Client A sends CSR_= 2 covering "example.c= om" to finalize their order. It doesn't use a weak key so the = order is finalized. Otucome: Client A gets a cert.

Thoughts? In this case it seems like learning later is perhaps an advantag= e since the actions available to remediate the error are less involved.

This doesn't seem like = a very convincing line of argument, for a few reasons:

=
- There's not that much time between new-order and finalize (is th= ere?), so it doesn't seem tremendously likely that there will be a chan= ge in security posture
- Even if there is, there's nothing th= at says the CA has to behave as you describe.=C2=A0 It could:
=C2= =A0 A. Do all the checks on the first shot, at the cost of possibly doing a= revocation later
=C2=A0 B. Do all the checks on the second shot,= at the risk of possibly doing some unnecessary authz
=C2=A0 = C. Reuse authorizations, so that the new-order is cheap

<= /div>
(Note that the current non-CSR PR is effectively (B), so either c= ase has that risk.)=C2=A0 You're basically saying if (1) you do checks = both times and (2) you don't re-use authorizations, then you might have= to do some unnecessary authz.=C2=A0 I would be satisfied to resolve this b= y saying "you ought not do that".

--Richard

=C2=A0

- Daniel / cpu

<= /div>

On Wed= , Nov 1, 2017 at 6:12 PM, Brad Warren <bmw@eff.org> wrote:
=20 =20 =20

As a client developer, I slightly prefer submitting the CSR twice. In addition to making the request logic a bit simpler, it causes the client to provide more information about the cert it would like to obtain earlier in the process. This was mentioned in another thread on this topic, but to provide a concrete example of where this might be useful, Let's Encrypt currently refuses to issue for CSRs containing a weak key. By initially providing the CSR, the server is able to immediately reject the request rather than waiting until the end of the process.

This approach would mean something else needs to be done to alleviate bloat in in the server's database, but I think it provides a better experience on the client side.

On 11/01/2017 09:13 AM, Richard Barnes wrote:
Some of us have been discussing this off-list, and where we got to was basically as follows:

1. We should have some sort of explicit "finalize" r= equest that triggers issuance of a certificate
2. The finalize request will need to have the CSR attached to it, so that the CA doesn't have to cache the CSR from new-order
3. The "new-order" request still needs to have some = sort of description of the certificate being requested, in order to support legacy back-end interfaces,
4. That description can be either:
=C2=A0 4.1. In the form of a CSR, or
=C2=A0 4.2. In the form of a list of identifiers (as in @cpu&#= 39;s PR [0])

On the one hand, sending a CSR twice seems clumsy (as Hugo notes above) and it makes the server parse the CSR twice.=C2=A0 O= n the other hand, using a CSR both times makes the client logic a bit simpler since you just send the same thing in both requests.

Anyone else have thoughts here?

--Richard







On Mon, Oct 30, 2017 at 3:48 PM, Daniel McCarney <cpu@letsencrypt.org> wrote:
Wouldn't it be a lot better not to do the validations at all if you can tell at new-order time that you're not going to b= e willing to issue?

Yes, that would be better in this one capacity. However I don't think it comes close to justify the scaling issues associated with accepting the CSR up-front, and as mentioned, there are other reasons why validations may occur for an order that the CA isn't willing to issue at the time of finalization.
There also isn't a CAA-PKP so we're bikeshedding = about impact on features that are both unspecified & unimplemented.=C2=A0

- Daniel / cpu

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


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

Can you expand on "annoying"= ;?

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

Wouldn't it be a lot better not to d= o the validations at all if you can tell at new-order time that you're not going to be willing to issue?

=C2=A0
In-fact, we already have to be rechecking CAA for authorizations validated more than 8 hours ago at the time of issuance so there must be code in place to check CAA at finalization and clients must be prepared for their order to be rejected at finalization based on CAA already.

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

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

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

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



-Ilari


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






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




--001a1142df5eae1dc0055d00d28f-- From nobody Thu Nov 2 07:32:21 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFEA13F91E for ; Thu, 2 Nov 2017 07:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qj_OqKCz9tpy for ; Thu, 2 Nov 2017 07:32:13 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7206C13F41B for ; Thu, 2 Nov 2017 07:32:13 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id k11so4960472ywh.1 for ; Thu, 02 Nov 2017 07:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EmTeaeK/d3O8suCe8+AK83xTXWRDIIIMSEwqt6BRLCM=; b=D707RkFLBe1nXQeJqzB/+AwUXq9CffrCULbaXWMSOCqerE2pMLAeqAuGdJJd++gewC OlI+RyVjcjr2MccXs2mWJfqJiDXrAzf2Q//7rq/br6n5tTwNSYc46fk+B/xnwPrEenbO Dk5PEUTPj9dmgVdiuBe1uLjcDznE9kmJIr3WkcfVZWoX0PzAmwta6nJJFQQI66e2Lph1 aipYjXIyMzyJ0mCmkdacKQaf7Tb342yN1tZY3NXSwonYmwUZWG4P75f1mzqk2YefYR3P raWc9VXOcRrVUMHwS7mD5Ba9BA41CcvNsGcRqr2e4Y02NQIibHjJG4Gv6otDq5ovghN1 18tQ== 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=EmTeaeK/d3O8suCe8+AK83xTXWRDIIIMSEwqt6BRLCM=; b=rZi0sI8LhitO7sizfJRPYQhfst/BevAZ5hw8Sn7f67HEJrl5BcVb1DX9uDppyes3lr xN335+lrii3O9KDRpZgGflYrA+oie+SJ0oGD4GbQx3Nb+DBL/7ismpVqAVKKDIYUELgS evET/1NeKMNLPCSkj+DusAf5MvuhGEYaUFeq0zhsZDHfUTQrfdpZN/aHRI6g6jk2tZTn sM94ohjdkyZAImzStzhdTjDXQlWhLtSNWgG3qgoxEZw2Lob286IakwXWTxoQpnx1y+ib fUbA8xvOnbSruz7RebDrAKamE0hegaRAIOGEhnwGq8AD6/LsikqK4LDMnhEF0mpHTNtB jxHA== X-Gm-Message-State: AMCzsaXZOMPLctpRp8/0Xn9Az3qBJkvGBMZoIoj+lHs76y3lX7tANPPX z5DsCcoTRruyLSu6TI6L0vieTSLfdm7dDuw+P4OvDA== X-Google-Smtp-Source: ABhQp+SgkAg1QLJpmTp2rG3Sv+hprkN8uYu0si180QrnWTglkoYhoYOb4dp7JN/TgMdMzDy70rNBngIj8g3hvXeluEY= X-Received: by 10.129.108.3 with SMTP id h3mr2359116ywc.327.1509633132686; Thu, 02 Nov 2017 07:32:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Thu, 2 Nov 2017 07:31:32 -0700 (PDT) In-Reply-To: References: <71f3e975-7cee-18cf-2635-80eb13adff12@devever.net> <20171024141732.ufjysx5f73pyc5f4@LK-Perkele-VII> <63029bbd-a9d5-0f30-718a-8d78f76a8e82@eff.org> From: Eric Rescorla Date: Thu, 2 Nov 2017 07:31:32 -0700 Message-ID: To: Richard Barnes Cc: Brad Warren , Hugo Landau , Ilari Liusvaara , Daniel McCarney , IETF ACME Content-Type: multipart/alternative; boundary="001a114d9a289d7cda055d00dade" Archived-At: Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 14:32:20 -0000 --001a114d9a289d7cda055d00dade Content-Type: text/plain; charset="UTF-8" On Wed, Nov 1, 2017 at 7:10 PM, Richard Barnes wrote: > > > On Wed, Nov 1, 2017 at 6:12 PM, Brad Warren wrote: > >> As a client developer, I slightly prefer submitting the CSR twice. In >> addition to making the request logic a bit simpler, it causes the client to >> provide more information about the cert it would like to obtain earlier in >> the process. This was mentioned in another thread on this topic, but to >> provide a concrete example of where this might be useful, Let's Encrypt >> currently refuses to issue for CSRs containing a weak key. By initially >> providing the CSR, the server is able to immediately reject the request >> rather than waiting until the end of the process. >> >> This approach would mean something else needs to be done to alleviate >> bloat in in the server's database, but I think it provides a better >> experience on the client side. >> > I think as long as the CSR is also included in the finalize request, we're > OK for CA bloat -- the CA can throw away the first CSR after it parses it > and produces the authorizations. > > Or rather, they should keep around a hash of the CSR so that they can > verify that the second CSR is the same. Since we should require that. > This seems like a great opportunity for defects. -Ekr > > --Richard > > >> On 11/01/2017 09:13 AM, Richard Barnes wrote: >> >> Some of us have been discussing this off-list, and where we got to was >> basically as follows: >> >> 1. We should have some sort of explicit "finalize" request that triggers >> issuance of a certificate >> 2. The finalize request will need to have the CSR attached to it, so that >> the CA doesn't have to cache the CSR from new-order >> 3. The "new-order" request still needs to have some sort of description >> of the certificate being requested, in order to support legacy back-end >> interfaces, >> 4. That description can be either: >> 4.1. In the form of a CSR, or >> 4.2. In the form of a list of identifiers (as in @cpu's PR [0]) >> >> On the one hand, sending a CSR twice seems clumsy (as Hugo notes above) >> and it makes the server parse the CSR twice. On the other hand, using a >> CSR both times makes the client logic a bit simpler since you just send the >> same thing in both requests. >> >> Anyone else have thoughts here? >> >> --Richard >> >> >> [0] https://github.com/ietf-wg-acme/acme/pull/342 >> >> >> >> >> >> On Mon, Oct 30, 2017 at 3:48 PM, Daniel McCarney >> wrote: >> >>> Wouldn't it be a lot better not to do the validations at all if you can >>>> tell at new-order time that you're not going to be willing to issue? >>> >>> >>> Yes, that would be better in this one capacity. However I don't think it >>> comes close to justify the scaling issues associated with accepting the CSR >>> up-front, and as mentioned, there are other reasons why validations may >>> occur for an order that the CA isn't willing to issue at the time of >>> finalization. >>> >>> There also isn't a CAA-PKP so we're bikeshedding about impact on >>> features that are both unspecified & unimplemented. >>> >>> - Daniel / cpu >>> >>> On Mon, Oct 30, 2017 at 3:33 PM, Richard Barnes wrote: >>> >>>> >>>> >>>> On Mon, Oct 30, 2017 at 10:15 AM, Daniel McCarney >>>> wrote: >>>> >>>>> > Example: Suppose that CAA-PKP got added (restrict issuance on SPKI key). >>>>> Implementing that without knowing the public key at validation time >>>>> is annoying. >>>>> >>>>> Can you expand on "annoying"? >>>>> >>>>> It seems completely possible to reject the order finalization message >>>>> based on a CAA-PKP property. >>>>> >>>> >>>> Wouldn't it be a lot better not to do the validations at all if you can >>>> tell at new-order time that you're not going to be willing to issue? >>>> >>>> >>>> >>>>> In-fact, we already have to be rechecking CAA for authorizations >>>>> validated more than 8 hours ago at the time of issuance so there must be >>>>> code in place to check CAA at finalization and clients must be prepared for >>>>> their order to be rejected at finalization based on CAA already. >>>>> >>>>> I don't see how this is any more annoying. >>>>> >>>>> - cpu >>>>> >>>>> On Tue, Oct 24, 2017 at 10:17 AM, Ilari Liusvaara < >>>>> ilariliusvaara@welho.com> wrote: >>>>> >>>>>> On Tue, Oct 24, 2017 at 02:45:01PM +0100, Hugo Landau wrote: >>>>>> > >>>>>> > The ACME protocol should permit CAs to implement policy as far as is >>>>>> > reasonably practicable with regard to the workflows around which the >>>>>> > protocol is organised. Providing the CSR up-front allows the CA to >>>>>> > predicate order processing on aspects of that CSR, both with regard >>>>>> to >>>>>> > the present protocol and any future extensions, both now and in the >>>>>> > future in ways that we can and cannot foresee. I don't think it's >>>>>> > appropriate to defer giving critical information to the CA until the >>>>>> > last minute due to a resource utilisation concern which LE has >>>>>> already >>>>>> > proven capable of dealing with, especially when the whole point of >>>>>> the >>>>>> > order flow in the first place was to provide more flexibility for >>>>>> CAs to >>>>>> > institute policy. >>>>>> >>>>>> Example: Suppose that CAA-PKP got added (restrict issuance on SPKI >>>>>> key). Implementing that without knowing the public key at validation >>>>>> time is annoying. >>>>>> >>>>>> As to why one would want something like that, it would allow limiting >>>>>> trust on certficiate management system without deploying something as >>>>>> dangerous as HPKP. >>>>>> >>>>>> >>>>>> >>>>>> -Ilari >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Acme mailing list >>>>> Acme@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/acme >>>>> >>>>> >>>> >>> >> >> >> _______________________________________________ >> Acme mailing listAcme@ietf.orghttps://www.ietf.org/mailman/listinfo/acme >> >> >> > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --001a114d9a289d7cda055d00dade Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 1, 2017 at 7:10 PM, Richard Barnes <rlb@ipv.sx> wro= te:


On Wed, Nov 1, 2= 017 at 6:12 PM, Brad Warren <bmw@eff.org> wrote:
=20 =20 =20

As a client developer, I slightly prefer submitting the CSR twice. In addition to making the request logic a bit simpler, it causes the client to provide more information about the cert it would like to obtain earlier in the process. This was mentioned in another thread on this topic, but to provide a concrete example of where this might be useful, Let's Encrypt currently refuses to issue for CSRs containing a weak key. By initially providing the CSR, the server is able to immediately reject the request rather than waiting until the end of the process.

This approach would mean something else needs to be done to alleviate bloat in in the server's database, but I think it provides a better experience on the client side.

I think as long as the CSR is also included in the finali= ze request, we're OK for CA bloat -- the CA can throw away the first CS= R after it parses it and produces the authorizations.

<= div>Or rather, they should keep around a hash of the CSR so that they can v= erify that the second CSR is the same.=C2=A0 Since we should require that.<= /div>

This seems like a g= reat opportunity for defects.

-Ekr

<= /div>


--Richard
=C2=A0

On 11/01/2017 09:13 AM, Richard Barnes wrote:
Some of us have been discussing this off-list, and where we got to was basically as follows:

1. We should have some sort of explicit "finalize" r= equest that triggers issuance of a certificate
2. The finalize request will need to have the CSR attached to it, so that the CA doesn't have to cache the CSR from new-order
3. The "new-order" request still needs to have some = sort of description of the certificate being requested, in order to support legacy back-end interfaces,
4. That description can be either:
=C2=A0 4.1. In the form of a CSR, or
=C2=A0 4.2. In the form of a list of identifiers (as in @cpu&#= 39;s PR [0])

On the one hand, sending a CSR twice seems clumsy (as Hugo notes above) and it makes the server parse the CSR twice.=C2=A0 O= n the other hand, using a CSR both times makes the client logic a bit simpler since you just send the same thing in both requests.

Anyone else have thoughts here?

--Richard







On Mon, Oct 30, 2017 at 3:48 PM, Daniel McCarney <cpu@letsencrypt.org> wrote:
Wouldn't it be a lot better not to do the validations at all if you can tell at new-order time that you're not going to b= e willing to issue?

Yes, that would be better in this one capacity. However I don't think it comes close to justify the scaling issues associated with accepting the CSR up-front, and as mentioned, there are other reasons why validations may occur for an order that the CA isn't willing to issue at the time of finalization.
There also isn't a CAA-PKP so we're bikeshedding = about impact on features that are both unspecified & unimplemented.=C2=A0

- Daniel / cpu

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


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

Can you expand on "annoying"= ;?

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

Wouldn't it be a lot better not to d= o the validations at all if you can tell at new-order time that you're not going to be willing to issue?

=C2=A0
In-fact, we already have to be rechecking CAA for authorizations validated more than 8 hours ago at the time of issuance so there must be code in place to check CAA at finalization and clients must be prepared for their order to be rejected at finalization based on CAA already.

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

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

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

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



-Ilari


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






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



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


--001a114d9a289d7cda055d00dade-- From nobody Thu Nov 2 09:18:49 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11EDF13F608 for ; Thu, 2 Nov 2017 09:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFdcoqbWiyCs for ; Thu, 2 Nov 2017 09:18:44 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97EB513AB36 for ; Thu, 2 Nov 2017 09:18:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 70D6A5DE64; Thu, 2 Nov 2017 18:18:40 +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 SZhOtb7P-E3i; Thu, 2 Nov 2017 18:18:40 +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 3636F21C; Thu, 2 Nov 2017 18:18:34 +0200 (EET) Date: Thu, 2 Nov 2017 18:18:33 +0200 From: Ilari Liusvaara To: Daniel McCarney Cc: Richard Barnes , Brad Warren , Hugo Landau , IETF ACME Message-ID: <20171102161833.pqxnd6ql22k4qiul@LK-Perkele-VII> References: <71f3e975-7cee-18cf-2635-80eb13adff12@devever.net> <20171024141732.ufjysx5f73pyc5f4@LK-Perkele-VII> <63029bbd-a9d5-0f30-718a-8d78f76a8e82@eff.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 16:18:47 -0000 On Thu, Nov 02, 2017 at 10:29:58AM -0400, Daniel McCarney wrote: > > I understand that these corner cases aren't a super convincing line of > argument, but I also don't think a slight preference for double CSR > strictly because it allows delivering a public key rejection error slightly > earlier in the order flow is a very convincing argument either. Does > someone have something stronger in mind? I guess if you find any use for the key at all depends on if authorizations are order-scoped or account-scoped. If authorizations are order-scoped, then the keys could be used for additional validation methods... There is at least one method in "10 methods" that absolutely requires the key to be known (number 9). Also, if the variant of the validation method uses the key, it does not seem safe to reuse it for different key. If orders can live over 8 hours, then one MUST be prepared to take rejection at finalization anyway. Because even if CAA was checked at authorization creation, it might have been changed and consequently fail the recheck. -Ilari From nobody Thu Nov 2 11:52:55 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6813B13F898 for ; Thu, 2 Nov 2017 11:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 DGso-ecVbUYb for ; Thu, 2 Nov 2017 11:52:52 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 68B5213F59F for ; Thu, 2 Nov 2017 11:52:52 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id 97so1174350iok.7 for ; Thu, 02 Nov 2017 11:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:reply-to:from:date:message-id:subject:to; bh=n0vLS5hz0MoQ9BY1/Vq3FM4RzyELUjxlK8imYUbZXmQ=; b=fKF7lI/ya/5DqIKnKGzZs6ht8h8bMZ1tT2Do//7V76tMekhNK9HQ+gzDta6c4omOf0 HIxzWua4khVg0crFmcA9NWggSW6v14FCI6fnwKLCroDPtEIffd+Xm6u2A0MnbjhjIeHb hWTJWP8YL9t6Fw0LYG41x52zkEFRoS3TRlmro= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=n0vLS5hz0MoQ9BY1/Vq3FM4RzyELUjxlK8imYUbZXmQ=; b=dwu0QGS2JLDb80/OYiTNPksvEOK7bfjZ7kFDEVVB/Cgaqs+haS21KU+SnhNG9YfGVs NxUZKTwS6ByOkYreLWw6BftxUiiQyFhkap7KL9NIwJ3lN9ve8rLI0Us1kbydEyc0T+F/ w6KUHdeE1NJm2nHwa4+mmBdZHeTfGEKcSFkmEezPtObUESAwBGvUc7HKee6ddnAL78gP DopYfpiDDnko0IhOlhwsph5yJ0fbp/+jiL7qrETpGb/6fwoB79H0PXzkk//PchuUWvsn seOcWPe3ESce/KFgE4nSxUk9MYxg713LkYOu/d3ed0h1gFxDkPOt/qozUDnYR9q25Oa7 EDNA== X-Gm-Message-State: AMCzsaX/H5+F+WJCKVw95DYDxnb8iwwoIHCyq7MQnWVxaP4vxMUMPxPY pnNRLZNp1B5WhcjAOG+eUsJ/yZVuohLXK9PUUYb+qheAfhU= X-Google-Smtp-Source: ABhQp+TNAyDnOuWEf3yCIK7ZaWEVThyyARfjWD3cHd+u7pL8Uxb5YuVZtfZv5Zf72Y76W6cIE/v/AZBsUOKgN/ghy3g= X-Received: by 10.36.118.210 with SMTP id z201mr4053191itb.78.1509648771199; Thu, 02 Nov 2017 11:52:51 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.88.21 with HTTP; Thu, 2 Nov 2017 11:52:50 -0700 (PDT) From: Daniel McCarney Date: Thu, 2 Nov 2017 14:52:50 -0400 Message-ID: To: IETF ACME Content-Type: multipart/alternative; boundary="001a1144080cbe5a7b055d047ec4" Archived-At: Subject: [Acme] Missing rationale for the Authorization "scope" field 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, 02 Nov 2017 18:52:54 -0000 --001a1144080cbe5a7b055d047ec4 Content-Type: text/plain; charset="UTF-8" Section 7.1.4 "Authorization Objects" describes an optional "scope" field. If present it must be a URI pointing to an order and the authorization is considered to be valid only for that order. If no scope value is present it is assumed that the authorization is valid for any order. Looking back at the PR that introduced the "scope" field[0] and knowing the current state of order based issuance I'm not clear why this field is needed, or what a client could do with the scope information. Can someone clarify or should this part of the spec be removed? The server determines as a matter of policy which authorizations are required for an order and includes these in the order's `authorizations` array. If part of that server policy is to treat some valid authorizations as only being valid for a specific order then the server can simply not include those valid authorizations in the order's authorizations array and can instead create new pending authorizations for the client to solve. The client doesn't need to understand authorization scope it just needs to know which authorizations the server says are required and how to move these authorizations to a valid state. Since the client can't ask for specific authorizations to be used with specific orders and must react to what the server provides why is it helpful to tell a client that one of the authorizations it solved won't be used with future orders? Similarly I think the scope field interacts weirdly with pre-authorization. Are all authorization objects created with pre-authorization assumed to be global scope since they aren't associated with an order? Have any ACME clients or servers implemented order scope? Let's Encrypt/Boulder/Pebble have not. - Daniel / cpu [0] - https://github.com/ietf-wg-acme/acme/pull/124 --001a1144080cbe5a7b055d047ec4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Section 7.1.4 "Authorization Objects" descr= ibes an optional "scope" field. If present it must be a URI point= ing to an order and the authorization is considered to be valid only for th= at order. If no scope value is present it is assumed that the authorization= is valid for any order.

Looking back at the PR th= at introduced the "scope" field[0] and knowing the current state = of order based issuance I'm not clear why this field is needed, or what= a client could do with the scope information. Can someone clarify or shoul= d this part of the spec be removed?

The server det= ermines as a matter of policy which authorizations are required for an orde= r and includes these in the order's `authorizations` array. If part of = that server policy is to treat some valid authorizations as only being vali= d for a specific order then the server can simply not include those valid a= uthorizations in the order's authorizations array and can instead creat= e new pending authorizations for the client to solve. The client doesn'= t need to understand authorization scope it just needs to know which author= izations the server says are required and how to move these authorizations = to a valid state.

Since the client can't ask f= or specific authorizations to be used with specific orders and must react t= o what the server provides why is it helpful to tell a client that one of t= he authorizations it solved won't be used with future orders?

Similarly I think the scope field interacts weirdly with pr= e-authorization. Are all authorization objects created with pre-authorizati= on assumed to be global scope since they aren't associated with an orde= r?

Have any ACME clients or servers implemented or= der scope? Let's Encrypt/Boulder/Pebble have not.

<= div>- Daniel / cpu


--001a1144080cbe5a7b055d047ec4-- From nobody Thu Nov 2 13:18:29 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874E413F907 for ; Thu, 2 Nov 2017 13:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andreasschulze.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 s1AGKxAMnTDX for ; Thu, 2 Nov 2017 13:18:25 -0700 (PDT) Received: from mail.somaf.de (mail.somaf.de [IPv6:2001:470:77b3:100::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33AEE13F6BF for ; Thu, 2 Nov 2017 13:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andreasschulze.de; s=ybz; t=1509653901; x=1514653901; bh=AwOns2Q/ReafwyZFnFXx0rtrE61cRWSRcbt/juJ2JTw=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To: Content-Type:from:reply-to:subject:date:to:cc:content-type: message-id; b=ZqLMBG4k0PQd3Ae9C17Nyp1Lq2O9dGFvDRURY6bwq/jdbSLpJBU0iwGD3Nt7PEgOn FG2DyV3FOVDxpf8q97Ojh+hHkyW+mX2O48+yoGtQ7KUQJrHdsHj3heYL/h8pR5pnmt w8fHZ3N3TX/HHv3vKEzdpaNCbZ0LnuFaWzkQtaVgLsx7Ms9NN8JgdPXvEMTNmPmZ+t tZvEMlukjyJEfyzFGlHWb99QDbEAkQvZHrbH/N/KGwaJxQxcWqmPkgBFsiJJsRaq+B hKcbQO7NWaP3POm/XQlsfewgnbQ8RkYnKBMZAL0hgGCVTm/oebo2GCnrIOTy5Zss62 EU57QfmkNBAYQ== To: acme@ietf.org References: <150930017939.11200.10967750996278552667@ietfa.amsl.com> From: "A. Schulze" Message-ID: <743ed0a3-8e2d-88db-0b6c-61a0bc88b5f2@andreasschulze.de> Date: Thu, 2 Nov 2017 21:18:21 +0100 MIME-Version: 1.0 In-Reply-To: <150930017939.11200.10967750996278552667@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-email-smime-01.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 20:18:27 -0000 Am 29.10.2017 um 19:02 schrieb internet-drafts@ietf.org: > Title : Extensions to Automatic Certificate Management Environment for end user S/MIME certificates > Author : Alexey Melnikov > Filename : draft-ietf-acme-email-smime-01.txt > Pages : 4 > Date : 2017-10-29 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-acme-email-smime/ Hello, I like to comment the questions (open issues section) 1. Do we need to handle text/html or multipart/alternative in email challenge? Simplicity suggests "no". I would vote for text/plain, but given the messages users send these days I expect many do not even know there is something other then text/html That may be a problem... 2. Do we need a proof that ACME client can submit email on behalf of the user, not just read the challenge using IMAP? Receiving a message is relevant if the certificates public key is used for encryption A submitted email mean the certificated private key is used for signing. Maybe that view help to answer the question (which I currently cannot :-/) Andreas From nobody Thu Nov 2 13:22: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 3A9D213F918 for ; Thu, 2 Nov 2017 13:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSIYceQZQE2K for ; Thu, 2 Nov 2017 13:22:39 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2D5A1389C1 for ; Thu, 2 Nov 2017 13:22:38 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id k62so686656wrc.9 for ; Thu, 02 Nov 2017 13:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AfdZL8QxSBTbVRagpKp80G8d9jxsVbNxg8B6qOylOWY=; b=V3tDgd3AHklQd8p4afHcrn4KiIQPnVGt4JmXKzoYaz4usbvSnbpFrPQ2OtRnpRZ+ke sxbDi9j7c5SSk7I5QlwDeXtZKv8+qwt7aA+/ukax7fZ+WsR2kuZlbRKQeLLBugsaA9QN aNdE1kG0WZQZ7ZeUrRGGzGTYkYR6nLELMySx4p6wAwW+yWS7kYbN8zLqU3qP4F7QDmR+ 6PgD6da4LemR9JJ0M/LGtYgO+VJGU6nPJtX/bxHruk3W3C1JqOcb3tFm7DzGg9LrWZoA S+tAJ806bFN403TYRL3pvsGnU96X5rj2n41cp5BC9vnrS2xqQ9jkrqx6bFhMvJ996yyh Fgrg== 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=AfdZL8QxSBTbVRagpKp80G8d9jxsVbNxg8B6qOylOWY=; b=T1hp3zYkVd0PKkdSTKi5ki8M59XS/lz6eEDwckkJKn5WMZ/ZnEIWgcWFrJh9IjI7Pb dZrQPNvft9ckyhYbd4b1/3BLFGN/Jlv7kMBur/xnz3rHrS+Bv4/vWrct8du+0QnkoVTk yEJQ+wtMiuEYTzHbrzGAotw6Nu51K1WrUVbz7n3CVemNdnppzckWKmGFcJRR58p7mDQ8 yRAGCpSo52UqBKSQL+BEpn0gPFgTgBPQ/fFvY6KlKiKg7YVhtmPPusngYyrzM+pDKg9f jVkx4nb7SOvudXZ4k8TI2MUWcW1FpXnto7Z3zTfryH/y6yQ6jCXj4o2/+diUs2HYg1Ag KFuA== X-Gm-Message-State: AMCzsaWRBMDE4MKZdW2VgTFSuBhmMbeRCHldPpGn6puvECNmFPNVfnjH RQ+1Dvj76Pf2sRWdNMPvPLdee8Fz9gZ7ZXy8m9NYuYz6 X-Google-Smtp-Source: ABhQp+TmjC5yVMQkdlXpV706zEZiFwwdzPrNSQTtbN2F+E5Eydaxeu1viEFI8eIWM5Nq7IT4xpZ4TP3s5Cuuwu6szKg= X-Received: by 10.223.152.16 with SMTP id v16mr3729768wrb.108.1509654157361; Thu, 02 Nov 2017 13:22:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Thu, 2 Nov 2017 13:22:36 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Thu, 2 Nov 2017 16:22:36 -0400 Message-ID: To: Daniel McCarney Cc: IETF ACME Content-Type: multipart/alternative; boundary="f403045d55a6c886f4055d05bfce" Archived-At: Subject: Re: [Acme] Missing rationale for the Authorization "scope" field 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, 02 Nov 2017 20:22:41 -0000 --f403045d55a6c886f4055d05bfce Content-Type: text/plain; charset="UTF-8" I think the intent when we implemented it was to communicate to clients that an authz was only good for a single issuance, so that if a client was doing pre-authorization, they would know that that authorization wouldn't be reused. Given that all issuance now goes through new-order, it's probably safe to remove this. If the client guesses wrong about what authz it needs, the server can tell it what else it needs to do. --Richard On Thu, Nov 2, 2017 at 2:52 PM, Daniel McCarney wrote: > Section 7.1.4 "Authorization Objects" describes an optional "scope" field. > If present it must be a URI pointing to an order and the authorization is > considered to be valid only for that order. If no scope value is present it > is assumed that the authorization is valid for any order. > > Looking back at the PR that introduced the "scope" field[0] and knowing > the current state of order based issuance I'm not clear why this field is > needed, or what a client could do with the scope information. Can someone > clarify or should this part of the spec be removed? > > The server determines as a matter of policy which authorizations are > required for an order and includes these in the order's `authorizations` > array. If part of that server policy is to treat some valid authorizations > as only being valid for a specific order then the server can simply not > include those valid authorizations in the order's authorizations array and > can instead create new pending authorizations for the client to solve. The > client doesn't need to understand authorization scope it just needs to know > which authorizations the server says are required and how to move these > authorizations to a valid state. > > Since the client can't ask for specific authorizations to be used with > specific orders and must react to what the server provides why is it > helpful to tell a client that one of the authorizations it solved won't be > used with future orders? > > Similarly I think the scope field interacts weirdly with > pre-authorization. Are all authorization objects created with > pre-authorization assumed to be global scope since they aren't associated > with an order? > > Have any ACME clients or servers implemented order scope? Let's > Encrypt/Boulder/Pebble have not. > > - Daniel / cpu > > [0] - https://github.com/ietf-wg-acme/acme/pull/124 > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --f403045d55a6c886f4055d05bfce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think the intent when we implemented it was to comm= unicate to clients that an authz was only good for a single issuance, so th= at if a client was doing pre-authorization, they would know that that autho= rization wouldn't be reused.

Given that all is= suance now goes through new-order, it's probably safe to remove this.= =C2=A0 If the client guesses wrong about what authz it needs, the server ca= n tell it what else it needs to do.

--Richard
<= /div>

On Thu= , Nov 2, 2017 at 2:52 PM, Daniel McCarney <cpu@letsencrypt.org> wrote:
Sectio= n 7.1.4 "Authorization Objects" describes an optional "scope= " field. If present it must be a URI pointing to an order and the auth= orization is considered to be valid only for that order. If no scope value = is present it is assumed that the authorization is valid for any order.

Looking back at the PR that introduced the "scop= e" field[0] and knowing the current state of order based issuance I= 9;m not clear why this field is needed, or what a client could do with the = scope information. Can someone clarify or should this part of the spec be r= emoved?

The server determines as a matter of polic= y which authorizations are required for an order and includes these in the = order's `authorizations` array. If part of that server policy is to tre= at some valid authorizations as only being valid for a specific order then = the server can simply not include those valid authorizations in the order&#= 39;s authorizations array and can instead create new pending authorizations= for the client to solve. The client doesn't need to understand authori= zation scope it just needs to know which authorizations the server says are= required and how to move these authorizations to a valid state.
=
Since the client can't ask for specific authorizations t= o be used with specific orders and must react to what the server provides w= hy is it helpful to tell a client that one of the authorizations it solved = won't be used with future orders?

Similarly I = think the scope field interacts weirdly with pre-authorization. Are all aut= horization objects created with pre-authorization assumed to be global scop= e since they aren't associated with an order?

= Have any ACME clients or servers implemented order scope? Let's Encrypt= /Boulder/Pebble have not.

- Daniel / cpu



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


--f403045d55a6c886f4055d05bfce-- From nobody Fri Nov 3 06:38: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 1868D13FC30 for ; Fri, 3 Nov 2017 06:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.646 X-Spam-Level: X-Spam-Status: No, score=-0.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2rRX0MHt9Ac for ; Fri, 3 Nov 2017 06:38:01 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7001413FAEF for ; Fri, 3 Nov 2017 06:38:01 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id l1so2543899wrc.3 for ; Fri, 03 Nov 2017 06:38:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=3+cp1cfVW9/m+DuFVyEl+k6woacqe8JvZTYt92XQtMQ=; b=r3bttf3nFX9Ge/ag89KoGVwA9rwbitRAYwH3NJj1D5p4Q9CVQD7DWU8/QRoT/XL/v1 DXWjRWmynbaCCbmPTGLkl8AAKMicC3jsSbFp3q6j7CJ8xspAzOgQjmWspKSjkrByczji Mfg1SXF5rEBoFOWCZ08SRD5yaTDYhPgcbA6osfpHYK2171FCZ/juwZVu4J1G6rO+qbSt KtM+qY/pHfCP52enx5Nr3lkyBKz2eF0LnL4m1lFeA0LB7qChBfSJe1YWXFV2atEWYXGv vL/8dgrMe8YGUJhUsm++v0mWEA7uVL08aMbW/G85mNqtMdtbgnXwqiN5wTB01r29QaOD VzOQ== 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=3+cp1cfVW9/m+DuFVyEl+k6woacqe8JvZTYt92XQtMQ=; b=oUzbz3OyKFXyYhrX9u9MV6fP9i0gWQS7lM9QJIwixcExG1TLkeGeb+o19RR94YRFdT 5yjUCY8YCYi68B+O0dDZc2+RdSlhU0djLpHjW40P7LmLK8HpN8ZoZvj6jo0mn+y0U3ps B+FxvTDvDLdxbCMVGAF3kMjAsidpKOEDlNrg2BL38bd44/TzkCw+Y5gconq08Ml+Diw/ JFmJOTi2uK0xNYkAw9WFvQwTKNY0DEkfpW7PtdyuI3vhQnywGqejVf4pw+jzcLThFhbV bH0a8hd7cKOF8F2xG9M7VTk5+zEEwM1SMPFzFeSIR+amYiUvF0tYo58uUQUjTUjmY5jz U+Ow== X-Gm-Message-State: AJaThX7AxoStbjlioX/ErOWBFrwMQBquhZ5igWxnd4QRbqrxkbMtY+pV PCo8Fb6ElrCRcGwPwl1LBYkHQoulvHDMo+roKvk= X-Google-Smtp-Source: ABhQp+RlqUEKioACktKcno6tYSkWVL1haYn8fRRv0yPeP1krKqUw98i2hupCnNSts2+BX86VD5QEaf4C5FPzlWkoEi0= X-Received: by 10.223.176.82 with SMTP id g18mr2067568wra.234.1509716279300; Fri, 03 Nov 2017 06:37:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.11.1 with HTTP; Fri, 3 Nov 2017 06:37:38 -0700 (PDT) From: Prasheel Soni Date: Fri, 3 Nov 2017 19:07:38 +0530 Message-ID: To: "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a114983468a1681055d143614" Archived-At: Subject: [Acme] Implementation of ACME in Node.JS X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 13:38:03 -0000 --001a114983468a1681055d143614 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Devs, I'm a beginner in ACME and trying to implement it in Node.JS. I came across some doubts while implementing it. Here are some of them: 1) What is TLS SNI Challenge and How to implement this in Node.JS, can anyone suggest some links to videos or documents or tutorials which I can refer for better understanding. 2) What should be the process flow of 'new-order' implementation process? 3) What should be the implementation strategy if there is no 'pre-authorization'? Thanks *Prasheel* =E2=80=8C --001a114983468a1681055d143614 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=3D""
Hi Devs,=C2=A0

I'm a beginner in ACME and trying to implement it = in Node.JS. I came across some doubts while implementing it. Here are some = of them:=C2=A0

1) What is TLS SNI Challenge and Ho= w to implement this in Node.JS, can anyone suggest some links to videos or = documents or tutorials which I can refer for better understanding.

2) What should be the process flow of 'new-order' = implementation process?

3) What should be the impl= ementation strategy if there is no 'pre-authorization'?=C2=A0
=

Thanks

= Prasheel

=E2=80=8C
--001a114983468a1681055d143614-- From nobody Fri Nov 3 09:26: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 6D5D913FEE3 for ; Fri, 3 Nov 2017 09:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 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, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 UukEm1fuSguv for ; Fri, 3 Nov 2017 09:26:37 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8392E13FED7 for ; Fri, 3 Nov 2017 09:26:37 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id i38so7462665iod.2 for ; Fri, 03 Nov 2017 09:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:cc; bh=hDtUVmDWHOaVY2DLp+MNkpa8F1ejE40CQrabwm6UZSY=; b=KVgvU7zgEVwXSMbVF1mTZSW0x1SgtIii3xr/EhEkmDO/4e1bpmijfNJBK9pJ+Ebw61 MxDgDxRZgwzCSn0ulOqr2YpQz2DLUIuISi2mw0xIusnfmI61tpqFPXJ56/16oGvEOP9S wm3E/XJYpfH8Lm+BEFCTc5ygFDOxaBSk576k8= 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:cc; bh=hDtUVmDWHOaVY2DLp+MNkpa8F1ejE40CQrabwm6UZSY=; b=ab82hT+mUIl1vH4I+cStJ2PWLGUAvflgyuEUyej5UDBknW3n++4jEl0HbWIE5WCI5W AkH+Aat+3f+LvmXazqZXS/73C9OkBhwxJIMCxTVDpWmof2p5tvx2MXtplopzVFfB6fao dQxjTgEUUMHQ1QPIm9LHCjGxXRGMMik0MTy3OCSHceynfq/yXQEnAdyqmgIHjl5nHPn9 gjj1hj3n8q2UzkD23RhbOn8EXhha5KnDKL8xkQJIQ/nYiG6KoIg1FQCutJbp55CcKSHs ePY93qkJj4g/JGFoBDaPoD5O9DxFHr7zu4RmcsZj1cw8b9twEG+6mrXtFZTt7V7x78+a lxmQ== X-Gm-Message-State: AMCzsaUsaPjqIIJUcb9MVSfcNArVQdUMwfE/LN/s2MXDabU8H/XxQMUs C5tChlNLneM1Y4dZuxToTVxIm7jkZiuql9LmENjhe5S9Ur0= X-Google-Smtp-Source: ABhQp+R3FVgHDPCN1jhEUmOJEaNKTiMIwbKom6AzosoFSQywdlcKe//gvwIQbMxirv/zpSO05IQZy7SEqglO6CQ2FEU= X-Received: by 10.107.33.18 with SMTP id h18mr9526308ioh.167.1509726396711; Fri, 03 Nov 2017 09:26:36 -0700 (PDT) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.88.21 with HTTP; Fri, 3 Nov 2017 09:26:36 -0700 (PDT) In-Reply-To: References: From: Daniel McCarney Date: Fri, 3 Nov 2017 12:26:36 -0400 Message-ID: Cc: IETF ACME Content-Type: multipart/alternative; boundary="001a1141bbf6959d44055d169114" Archived-At: Subject: Re: [Acme] Missing rationale for the Authorization "scope" field 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, 03 Nov 2017 16:26:39 -0000 --001a1141bbf6959d44055d169114 Content-Type: text/plain; charset="UTF-8" > Given that all issuance now goes through new-order, it's probably safe to > remove this. If the client guesses wrong about what authz it needs, the > server can tell it what else it needs to do. Sounds good to me. Here's a PR to do so: https://github.com/ietf-wg-acme/acme/pull/349 - Daniel / cpu On Thu, Nov 2, 2017 at 4:22 PM, Richard Barnes wrote: > I think the intent when we implemented it was to communicate to clients > that an authz was only good for a single issuance, so that if a client was > doing pre-authorization, they would know that that authorization wouldn't > be reused. > > Given that all issuance now goes through new-order, it's probably safe to > remove this. If the client guesses wrong about what authz it needs, the > server can tell it what else it needs to do. > > --Richard > > On Thu, Nov 2, 2017 at 2:52 PM, Daniel McCarney > wrote: > >> Section 7.1.4 "Authorization Objects" describes an optional "scope" >> field. If present it must be a URI pointing to an order and the >> authorization is considered to be valid only for that order. If no scope >> value is present it is assumed that the authorization is valid for any >> order. >> >> Looking back at the PR that introduced the "scope" field[0] and knowing >> the current state of order based issuance I'm not clear why this field is >> needed, or what a client could do with the scope information. Can someone >> clarify or should this part of the spec be removed? >> >> The server determines as a matter of policy which authorizations are >> required for an order and includes these in the order's `authorizations` >> array. If part of that server policy is to treat some valid authorizations >> as only being valid for a specific order then the server can simply not >> include those valid authorizations in the order's authorizations array and >> can instead create new pending authorizations for the client to solve. The >> client doesn't need to understand authorization scope it just needs to know >> which authorizations the server says are required and how to move these >> authorizations to a valid state. >> >> Since the client can't ask for specific authorizations to be used with >> specific orders and must react to what the server provides why is it >> helpful to tell a client that one of the authorizations it solved won't be >> used with future orders? >> >> Similarly I think the scope field interacts weirdly with >> pre-authorization. Are all authorization objects created with >> pre-authorization assumed to be global scope since they aren't associated >> with an order? >> >> Have any ACME clients or servers implemented order scope? Let's >> Encrypt/Boulder/Pebble have not. >> >> - Daniel / cpu >> >> [0] - https://github.com/ietf-wg-acme/acme/pull/124 >> >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> >> > --001a1141bbf6959d44055d169114 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Given that all issuance now goes throu= gh new-order, it's probably safe to remove this.=C2=A0 If the client gu= esses wrong about what authz it needs, the server can tell it what else it = needs to do.


Sounds good to me. Here&= #39;s a PR to do so:

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

- Daniel / cpu

On= Thu, Nov 2, 2017 at 4:22 PM, Richard Barnes <rlb@ipv.sx> wrote:
I think the intent w= hen we implemented it was to communicate to clients that an authz was only = good for a single issuance, so that if a client was doing pre-authorization= , they would know that that authorization wouldn't be reused.

Given that all issuance now goes through new-order, it'= s probably safe to remove this.=C2=A0 If the client guesses wrong about wha= t authz it needs, the server can tell it what else it needs to do.

--Richard

On Thu, Nov 2, 2017 at 2:52= PM, Daniel McCarney <cpu@letsencrypt.org> wrote:
Section 7.1.4 "Authorization Objects" describes an option= al "scope" field. If present it must be a URI pointing to an orde= r and the authorization is considered to be valid only for that order. If n= o scope value is present it is assumed that the authorization is valid for = any order.

Looking back at the PR that introduced = the "scope" field[0] and knowing the current state of order based= issuance I'm not clear why this field is needed, or what a client coul= d do with the scope information. Can someone clarify or should this part of= the spec be removed?

The server determines as a m= atter of policy which authorizations are required for an order and includes= these in the order's `authorizations` array. If part of that server po= licy is to treat some valid authorizations as only being valid for a specif= ic order then the server can simply not include those valid authorizations = in the order's authorizations array and can instead create new pending = authorizations for the client to solve. The client doesn't need to unde= rstand authorization scope it just needs to know which authorizations the s= erver says are required and how to move these authorizations to a valid sta= te.

Since the client can't ask for specific au= thorizations to be used with specific orders and must react to what the ser= ver provides why is it helpful to tell a client that one of the authorizati= ons it solved won't be used with future orders?

Similarly I think the scope field interacts weirdly with pre-authorizatio= n. Are all authorization objects created with pre-authorization assumed to = be global scope since they aren't associated with an order?
<= br>
Have any ACME clients or servers implemented order scope? Let= 's Encrypt/Boulder/Pebble have not.

- Daniel /= cpu



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



--001a1141bbf6959d44055d169114-- From nobody Fri Nov 3 10:00: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 4069113FEDD for ; Fri, 3 Nov 2017 09:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yfdhnnz15Y2 for ; Fri, 3 Nov 2017 09:59:56 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 7C5DB13FDEF for ; Fri, 3 Nov 2017 09:59:56 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id t188so2609076pfd.10 for ; Fri, 03 Nov 2017 09:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NLZJHvcWpsVsWJZmOrnV0xvAodkBZVBOxoitSviaB1Q=; b=J4JgZ0g9rXpJkHHvQbz7GK47gWGuw6StSd15C1mF2hIPJeFf8hXTf7vuWO7oV1MWeW 264GnXBEIx4HtTA2szD4P5gPzxyoB9oObW8CtuDwDyxACqjk/T3DNucsPmZN/1Jw4j65 296C+j7oaj7NlPPCMiycXfqyJQ13HT9Iw15lGBCBoyJBYfTunTr/Z3qhOpb6POI+bAx5 Khqornu/PKGkeMXz5RgB2e/1UMMNlMgcnIEuODooZy/xnrPCky578pbtUXXnv0EdUZd3 hplIgKJwtOQ5zQQBkWuvpQtoLBDcieT8Y2Z5JgPNdyBV4tVMXkMBXomtTypIKfPGw5Lw vGDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=NLZJHvcWpsVsWJZmOrnV0xvAodkBZVBOxoitSviaB1Q=; b=buo1lG1U3UdDq6ivWkPE69IMSVjGsBz2oWyd5JZVvWc8muL9cfmqEpr5OWENxLKOWe rIauQD11U0DVWH6lyEOVVhQnQcFKdJmWFvySIVK4C/jPVQlSApiWEqzfRvVrvnrfkuIM KSXGUu2Rd8+dYXmqj2yrcGqPDbAJkEsPmvYdZJiM80z29sic17Yc9qnQBQL79625OPRO h5kqetkfvBJlgGlUkcGIrS032Ht7987tQGb0fF6CATG0sdAt8uk2Pqmqog6I5yNN1OHQ llBYN5SG5QVOS7YWx0lTmzmvy4aHNv2uNp2yVfJJvV9de7BYhtKnFcM36i18eN+s/iC9 mI6w== X-Gm-Message-State: AMCzsaWqREnX0e63A7mk0CUuypyudjpj1TiQIJviD5R4QuEGuoQlshyl hx7exMUS71WF7Ai0CPnJKG0TDM4jSG6eBMhsbIY= X-Google-Smtp-Source: ABhQp+Sr1zvIooXJ1ez7PyhCabGNcH5thlhJDI2bS1Ov/UkuAiCqY+D1Il+iAoTtjFjqYilqf6rRo8cu4nWRRToHZNo= X-Received: by 10.84.234.198 with SMTP id i6mr7416220plt.260.1509728395780; Fri, 03 Nov 2017 09:59:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.194 with HTTP; Fri, 3 Nov 2017 09:59:15 -0700 (PDT) In-Reply-To: References: From: Kathleen Moriarty Date: Fri, 3 Nov 2017 12:59:15 -0400 Message-ID: To: Richard Barnes Cc: IETF ACME Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Acme] AD review of draft-ietf-acme-acme X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 16:59:59 -0000 On Tue, Oct 31, 2017 at 3:51 PM, Richard Barnes wrote: > > > On Mon, Oct 30, 2017 at 9:37 PM, Kathleen Moriarty > wrote: >> >> Hi Richard, >> >> On Mon, Oct 30, 2017 at 6:27 PM, Richard Barnes wrote: >> > >> > >> > On Mon, Oct 30, 2017 at 5:00 PM, Kathleen Moriarty >> > wrote: >> >> >> >> Hi Richard, >> >> >> >> Thanks for posting the diff, I reviewed the changes and they look >> >> good, but I have a couple of questions. FYI - I had started looking >> >> at the PR, but something came up, sorry for the delay and this was a >> >> good reminder. >> >> >> >> On Thu, Oct 19, 2017 at 12:45 PM, Richard Barnes wrote: >> >> > Hi Kathleen, >> >> > >> >> > Thanks for the review. Some responses inline. I've started a PR t= o >> >> > respond >> >> > to these comments here: >> >> > >> >> > https://github.com/ietf-wg-acme/acme/pull/345 >> >> > >> >> > I agree with Daniel that we should hold off on IETF LC until we've >> >> > addressed >> >> > the issues around proactive issuance / caching of CSRs. That may >> >> > require a >> >> > re-WGLC, but once that's closed, it should be safe to send to IETF >> >> > LC. >> >> > >> >> > >> >> > On Fri, Sep 22, 2017 at 4:14 PM, Kathleen Moriarty >> >> > wrote: >> >> >> >> >> >> Hello, >> >> >> >> >> >> Thank you to the editors and WG for your efforts on >> >> >> draft-ietf-acme-acme, it's a well written and easy to understand >> >> >> draft. I do have a few comments, that need to be address by the >> >> >> editors and SHEPHERD. >> >> >> >> >> >> Please review the idnits. There are a few warnings that should be >> >> >> correctable and can be addressed, but more importantly, it calls o= ut >> >> >> several downrefs that are not in the shepherd writeup. These need >> >> >> to >> >> >> be in the writeup and then also mentioned in the IETF last call >> >> >> announcement (I'll make sure the latter happens). >> >> >> >> >> >> Here's my mostly editorial comments: >> >> >> >> >> >> Introduction: >> >> >> It reads very well, but it would be helpful to those unfamiliar wi= th >> >> >> the work to explicitly state that ACME is about DV certificates. >> >> >> The >> >> >> first sentence of the last paragraph seems like the best place to >> >> >> add >> >> >> this in. >> >> >> Current text: >> >> >> This document describes an extensible framework for automating >> >> >> the >> >> >> issuance and domain validation procedure, thereby allowing >> >> >> servers >> >> >> and infrastructural software to obtain certificates without use= r >> >> >> interaction. >> >> >> Proposed: >> >> >> This document describes an extensible framework for automating >> >> >> the >> >> >> issuance and domain validation procedure for DV certificates, >> >> >> thereby allowing servers >> >> >> and infrastructural software to obtain certificates without use= r >> >> >> interaction. >> >> > >> >> > >> >> > As others have pointed out, ACME is not just about DV. PR has some >> >> > clarification on this point. >> >> >> >> I see the text on uses in other PKI contexts in the introduction, but >> >> don't see anything on the certificate types and out-of-band processes >> >> (as is the case for the STIR use case Mary mentioned). Maybe I'm >> >> missing it, can you tell me where to look? >> > >> > >> > I don't think you're missing anything. What do you mean by "certifica= te >> > types and out-of-band processes"? How is that different from "other P= KI >> > contexts"? >> >> I think by PKI-context, you mean the application of use, is that >> right? I am separating out the type of certificate (DV, EV, etc.) as >> you have done in the second paragraph of the introduction. When >> reading the rest of the document, there isn't text that says what type >> of certificate ACME produces without any additional processes >> (out-of-band authentication/validation). If you think about >> administrators who operate servers (whatever the protocol) or even >> those who may wish to incorporate ACME into a new application, they >> will may have to figure out what level ACME provides as a default and >> also know that there can be additional processes added to obtain >> certificates types at a higher assurance level using ACME. Since the >> text already does a nice job of explaining the certificate types, this >> should be an easy follow up that I think will be very helpful to >> people outside of the IETF or who look at this in the future. >> >> Maybe something like the following: >> >> Strictly following the automation enabled by ACME, DV certificates >> are issued. >> Additional processes can be provided by the CA to increase the level = of >> validation on an end entity to issue certificates at a higher >> assurance level, >> for instance an EV certificate. > STIR >> example Mary mentioned in this thread.> >> >> Does that help? Thinking about this in former roles and having been >> to some conferences lately, I think being explicit about this will >> help those trying to evaluate and deploy ACME. They may look for >> providers who meet the assurance levels they need knowing there are >> options and understanding the baseline provided by this spec. > > > > It's wrong to frame this as being about assurance levels -- you seem to b= e > presuming that manual processes can give higher assurance than automated > ones, a fact which I think has been repeatedly proven false in the web PK= I. > > But I'm fine clarifying that certain things (like EV validation) have not > yet been audited: > > +ACME can also be used to automate some aspects of certificate management > even > +where non-automated processes are still needed. For example, the extern= al > +account binding feature (see {{external-account-binding}}) can be used t= o > +associate authorizations with an account that were not validated through > the > +ACME authorization process. This allows ACME to address issuance scenar= ios > that > +cannot yet be fully automated, such as the issuance of Extended Validati= on > +certificates. You're essentially saying the same thing with this text, so I'm fine with it. The introduction describing cert types and then not having any statements about what is automated and what might need additional non-automated process is an important link to make, so thanks. Kathleen > > Updated PR: https://github.com/ietf-wg-acme/acme/pull/348 > > --Richard > > > >> >> >> Thanks, >> Kathleen >> >> >> > >> > >> >> >> >> > >> >> > >> >> >> >> >> >> I do like how the introduction is framed as it=E2=80=99s clear the= level of >> >> >> security provided by the certificates issued via ACME. Thanks for >> >> >> that. >> >> >> >> >> >> The introduction should also make it clear that ACME can be used f= or >> >> >> other services using DV certificates, not just HTTP. This is >> >> >> mentioned in the Terminology section, but I think a clear sentence >> >> >> upfront would be helpful. >> >> >> >> >> >> Section 2: Nit/suggestion: Change the tense to read as a published >> >> >> RFC >> >> >> in the last paragraph, last sentence (take it or leave it). >> >> >> Current: >> >> >> Such close integration of ACME with HTTPS >> >> >> servers would allow the immediate and automated deployment of >> >> >> certificates as they are issued, sparing the human administrato= r >> >> >> from >> >> >> much of the time-consuming work described in the previous >> >> >> section. >> >> >> Proposed: >> >> >> Such close integration of ACME with HTTPS >> >> >> servers allows the immediate and automated deployment of >> >> >> certificates as they are issued, sparing the human administrato= r >> >> >> from >> >> >> much of the time-consuming work described in the previous >> >> >> section. >> >> > >> >> > >> >> > Done. >> >> > >> >> > >> >> >> >> >> >> IANA Section: >> >> >> Everything looks good except that RFC5226 has been obsoleted, so t= he >> >> >> new reference is RFC8126 and =E2=80=9Cspecification required=E2=80= =9D >> >> >> https://tools.ietf.org/html/rfc8126#section-4.6 still means the sa= me >> >> >> thing, so using that is fine. >> >> > >> >> > >> >> > Updated reference. >> >> > >> >> > >> >> >> >> >> >> Security considerations: >> >> >> I think it would be good to mention here that they are DV certs so >> >> >> the >> >> >> reader understands from he introduction and this section the level >> >> >> of >> >> >> cert issued through ACME and doesn=E2=80=99t assume a higher level= of >> >> >> assurance. >> >> >> >> >> >> s/ACME is a protocol for managing certificates/ACME is a protocol >> >> >> for >> >> >> managing DV certificates/ >> >> > >> >> > >> >> > Given the discussion about DV, I don't think this change is >> >> > appropriate. >> >> > >> >> > >> >> >> >> >> >> 10.1 - I know this is obvious to the people in the WG, but a >> >> >> reference >> >> >> to RFC7525 to properly configure TLS 1.2 should be included to >> >> >> protect >> >> >> against the mentioned attacks. If you want to also reference TLS >> >> >> 1.3 >> >> >> and specify no 0-RTT that would be good too. It=E2=80=99d be grea= t to see >> >> >> this get widely deployed, so there may be a number of newcomers >> >> >> reading this to make their lives easier with cert >> >> >> issuance/maintenance. >> >> > >> >> > >> >> > I don't see how TLS configuration plays into the security >> >> > considerations >> >> > for >> >> > ACME. How you use the certificates you get from ACME is your >> >> > business, >> >> > and >> >> > indeed, several of the envisioned applications have nothing to do >> >> > with >> >> > TLS >> >> > (e.g., the email and STIR use cases). >> >> > >> >> > That said, I have added some language to suggest that ACME servers >> >> > should >> >> > follow the advice in RFC 7525. 0xRTT should be safe here, because >> >> > there >> >> > are >> >> > anti-replay protections at the application layer. >> >> >> >> Can you add a pointer in your text about the provided anti-replay >> >> protections in the application layer? >> > >> > >> > Draft PR here: >> > >> > https://github.com/ietf-wg-acme/acme/pull/348 >> > >> > --Richard >> > >> > >> >> >> >> >> >> Thanks, >> >> Kathleen >> >> >> >> > >> >> > >> >> >> >> >> >> 10.2 - what if the server that the account verifier has an account >> >> >> on >> >> >> (client for ACME) is compromised and is used to request new >> >> >> certificates or perform other actions? I think this is one of the >> >> >> larger risks, so mentioning this is possible and hardening measure= s >> >> >> should be taken to prevent compromise would be prudent. Hardening >> >> >> measures or appropriate security controls should be broadly >> >> >> understood >> >> >> terms (I think) so that you wouldn=E2=80=99t need to list out thin= gs like >> >> >> turing off unnecessary services. >> >> > >> >> > >> >> > Added a brief note. >> >> > >> >> > >> >> >> >> >> >> 10.5 - I would think you=E2=80=99d see requests for new phishing d= omains >> >> >> rather than known ones through this process. What would you look >> >> >> for >> >> >> there as that=E2=80=99s a complex problem - it would be hard to kn= ow all >> >> >> legit >> >> >> names to know if one was a play off of the original. This happene= d >> >> >> with equifax - they provided a site name with a typo and a =E2=80= =98white >> >> >> hat=E2=80=99 >> >> >> attacker had set up a site that looked just like theirs at that >> >> >> site. >> >> >> But it was announced by equifax. Tough problem as automating a >> >> >> check >> >> >> on the DNS registration may not detect something unusual, but mayb= e >> >> >> recommending this check could help? RDP lessens what needs to be >> >> >> shared from whois though, although I don=E2=80=99t think that=E2= =80=99s widely >> >> >> deployed. >> >> > >> >> > >> >> > This is a policy question, not one for the issuance protocol. >> >> > >> >> > --Richard >> >> > >> >> > >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> >> Best regards, >> >> >> Kathleen >> >> >> >> >> >> _______________________________________________ >> >> >> Acme mailing list >> >> >> Acme@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/acme >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> >> >> Best regards, >> >> Kathleen >> > >> > >> >> >> >> -- >> >> Best regards, >> Kathleen > > --=20 Best regards, Kathleen From nobody Fri Nov 3 10:19: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 A2D0D13FB0F for ; Fri, 3 Nov 2017 10:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9U8hQ-MCsfDj for ; Fri, 3 Nov 2017 10:19:46 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1300E13FF00 for ; Fri, 3 Nov 2017 10:19:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 8E01849DA3; Fri, 3 Nov 2017 19:19:42 +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-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id a0BWEt0_cpMv; Fri, 3 Nov 2017 19:19:42 +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 DAE422315; Fri, 3 Nov 2017 19:19:39 +0200 (EET) Date: Fri, 3 Nov 2017 19:19:39 +0200 From: Ilari Liusvaara To: Prasheel Soni Cc: "acme@ietf.org" Message-ID: <20171103171939.7dnxvzrtvp26guh2@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] Implementation of ACME in Node.JS X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 17:19:49 -0000 On Fri, Nov 03, 2017 at 07:07:38PM +0530, Prasheel Soni wrote: > Hi Devs, > > I'm a beginner in ACME and trying to implement it in Node.JS. I came across > some doubts while implementing it. Here are some of them: Note that in the below, "server" and "ACME client" may or may not be the same entity. Server is the process that listens for port 443, ACME client is the process that talks with the ACME server, which is taken to be the CA. > 1) What is TLS SNI Challenge and How to implement this in Node.JS, can > anyone suggest some links to videos or documents or tutorials which I can > refer for better understanding. Basically, ACME has a set of challenge methods. Challenge methods are methods intended for the server to authenticate to the CA that it is the name it claims to be. TLS SNI challenge, internally called "tls-sni-02" is one such method. In it, the acme client provisions a self-signed certificate containing given names in SubjectAlternativeNames section for a specific TLS Server Name Indication value. The CA will then contact the server, using IP address resolved from the DNS A or AAAA record for the name to validate, always on port 443, send the specific Server Name Indication value, and check that the returned certificate consists of the given names. If it does, the challenge is valid. Otherwise the challenge fails. As far as I understand, the names (of DNS type) that need to appear in the certifiate are computed as follows: 1) encode(sha256(token)) || ".token.acme.invalid" 2) encode(sha256(token||"."||accountfp)) || . ".ka.acme.invalid" Where: encode(x) does the following: - Encode x into 64 lowercase hexadecimal digits. - Split the result into two halves of 32 hexdigits each. - Concatenate the halves back with "." in between. || is string concatenation. sha256(x) is (binary) SHA-256 hash of x. "foo" is the fixed ASCII string foo. Both names need to appear, and only these names can appear. The request will be sent for 1), as ServerName of HostName type. If you are writing ACME client, Note that unless the TLS stack or the webserver has special support for this method, it will require very nasty hacks. I am aware of just one piece of software (that I happended to write) with such support that is programmable from outside. Some other pieces of software also have internal support for internal ACME client, but nothing to use from outside. For the above reason, I would not advise you to use tls-sni-01 if the ACME client is separate from the server. Use http-01 instead in this case (or dns-01 if you have access to API that modifies DNS data). Also note that there is _no_ way for server to verify the purported challenge is legimate or what it actually covers. This is in contrast to the http-01 and dns-01 methods, where the server can indeed verify that the challenge is for name it is purported to be (by at least causing validation to fail if it is not). > 2) What should be the process flow of 'new-order' implementation process? 1) Client sends new-order request containg names it wants in the certiifcate. This list can contain wildcards. 2) The CA creates authorizations it wants, none of them for a wildcard, and returns the list to the ACME client. 3) The ACME client solves one challenge for each authorization returned. 4) The ACME client finalizes the order. 5) The ACME client downloads the certificate. > 3) What should be the implementation strategy if there is no > 'pre-authorization'? For the ACME client, Instead of figuring authorizations you need, let the CA tell what it needs. For the CA, if the order can not be immediately satisfied, create authorizations for each name you need authorized before issuance, and return this list to the ACME client. -Ilari From nobody Sun Nov 5 20:30: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 6F97C13FAF4 for ; Sun, 5 Nov 2017 20:30:30 -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 Xp6bwXUrQ2P9 for ; Sun, 5 Nov 2017 20:30:27 -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 8B41713FAE0 for ; Sun, 5 Nov 2017 20:30:26 -0800 (PST) Received: by mail-wr0-x22f.google.com with SMTP id l8so7332552wre.12 for ; Sun, 05 Nov 2017 20:30:26 -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=d3ZxIzboUg3KW0RnjcUpfpEu7xAWzdLwoKyTdWu8hwo=; b=U2MHqSS7aIwNwLyjkHHP946dh+GExAAa9EyW3YZOA6MV1+Ht7oQ6ewZoEKxhVVZKyY Gh2NLvnJ1gxityAeKEwXaWLlrQeQffTa+/244985Hgad4H0fcsV82B6dNYOHSQlnUBXf IwPxJoQPSpgXzzHG629n3Xl7UMuFZGFLI+tJJIY26MnGUqyCl3o5YnyMFzBUsuPqH4eX b/4R+ZBUhHKyfD9P4dYAU8bT5dSnXKDJPQB9PpOEdEjGIN5jLAoQ/E0RW1CUVnwG5CFP KPj4n3JrYs4NLqS4jDW3BFBpLwrsciZXJabXkmTKBZRAWRi2pE/LtEgWoxQdM+W+lp7N UcEg== 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=d3ZxIzboUg3KW0RnjcUpfpEu7xAWzdLwoKyTdWu8hwo=; b=aQbnPOsfixqXHJjkvnm8vjp315491gJNhykU6yzE3UHCni1c7g/tuMnTD/Jq8FCqhP zGAXMxzcI3z+Jr+reHX+n2oVql4G5noQBG3wvnU4LbLYa7SmQ5f29CTXLZDAZ46k+/rP VLpotxOl5Ise4SzAFBf+ekK2TROaDDrERz0bNZVv6IDmF7Nvb13CcG5u6X+KlQvEvWEb 2VoMssc1s9POaZIfulJpg92jfNcRH7e9gln0VjwWr2LLHIF5W0ffXeJJRkbPIC6LE7bX LUla9ttTeKHUDySX8dYXFYYKelQVOUWZhqL5Kq1sIeieusiYzXyXkPsFag3a7cbt3RNJ dM7Q== X-Gm-Message-State: AMCzsaUr54TRaJIOmleMkdFK+N7vOzxpWJ4N9N23bg/oAJsUuFPFdLfI 2BBXw8JufKc9uyEo+0yReqS7ACzgA6pvTG2cjG5OMg== X-Google-Smtp-Source: ABhQp+TWgWCe/ATPIcbzecmQlMagN8X64ppOSqVof/MO/gS8uxCCh/5EmswXU3rURKSvJLYmpr82JcpI4DSOsa0nqNU= X-Received: by 10.223.152.16 with SMTP id v16mr10571550wrb.108.1509942624879; Sun, 05 Nov 2017 20:30:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Sun, 5 Nov 2017 20:30:24 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Sun, 5 Nov 2017 23:30:24 -0500 Message-ID: To: Kathleen Moriarty Cc: IETF ACME Content-Type: multipart/alternative; boundary="f403045d55a6c998d5055d48e949" Archived-At: Subject: Re: [Acme] AD review of draft-ietf-acme-acme X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 04:30:30 -0000 --f403045d55a6c998d5055d48e949 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Nov 3, 2017 at 12:59 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > On Tue, Oct 31, 2017 at 3:51 PM, Richard Barnes wrote: > > > > > > On Mon, Oct 30, 2017 at 9:37 PM, Kathleen Moriarty > > wrote: > >> > >> Hi Richard, > >> > >> On Mon, Oct 30, 2017 at 6:27 PM, Richard Barnes wrote: > >> > > >> > > >> > On Mon, Oct 30, 2017 at 5:00 PM, Kathleen Moriarty > >> > wrote: > >> >> > >> >> Hi Richard, > >> >> > >> >> Thanks for posting the diff, I reviewed the changes and they look > >> >> good, but I have a couple of questions. FYI - I had started lookin= g > >> >> at the PR, but something came up, sorry for the delay and this was = a > >> >> good reminder. > >> >> > >> >> On Thu, Oct 19, 2017 at 12:45 PM, Richard Barnes wrote= : > >> >> > Hi Kathleen, > >> >> > > >> >> > Thanks for the review. Some responses inline. I've started a PR > to > >> >> > respond > >> >> > to these comments here: > >> >> > > >> >> > https://github.com/ietf-wg-acme/acme/pull/345 > >> >> > > >> >> > I agree with Daniel that we should hold off on IETF LC until we'v= e > >> >> > addressed > >> >> > the issues around proactive issuance / caching of CSRs. That may > >> >> > require a > >> >> > re-WGLC, but once that's closed, it should be safe to send to IET= F > >> >> > LC. > >> >> > > >> >> > > >> >> > On Fri, Sep 22, 2017 at 4:14 PM, Kathleen Moriarty > >> >> > wrote: > >> >> >> > >> >> >> Hello, > >> >> >> > >> >> >> Thank you to the editors and WG for your efforts on > >> >> >> draft-ietf-acme-acme, it's a well written and easy to understand > >> >> >> draft. I do have a few comments, that need to be address by the > >> >> >> editors and SHEPHERD. > >> >> >> > >> >> >> Please review the idnits. There are a few warnings that should = be > >> >> >> correctable and can be addressed, but more importantly, it calls > out > >> >> >> several downrefs that are not in the shepherd writeup. These ne= ed > >> >> >> to > >> >> >> be in the writeup and then also mentioned in the IETF last call > >> >> >> announcement (I'll make sure the latter happens). > >> >> >> > >> >> >> Here's my mostly editorial comments: > >> >> >> > >> >> >> Introduction: > >> >> >> It reads very well, but it would be helpful to those unfamiliar > with > >> >> >> the work to explicitly state that ACME is about DV certificates. > >> >> >> The > >> >> >> first sentence of the last paragraph seems like the best place t= o > >> >> >> add > >> >> >> this in. > >> >> >> Current text: > >> >> >> This document describes an extensible framework for automatin= g > >> >> >> the > >> >> >> issuance and domain validation procedure, thereby allowing > >> >> >> servers > >> >> >> and infrastructural software to obtain certificates without > user > >> >> >> interaction. > >> >> >> Proposed: > >> >> >> This document describes an extensible framework for automatin= g > >> >> >> the > >> >> >> issuance and domain validation procedure for DV certificates, > >> >> >> thereby allowing servers > >> >> >> and infrastructural software to obtain certificates without > user > >> >> >> interaction. > >> >> > > >> >> > > >> >> > As others have pointed out, ACME is not just about DV. PR has so= me > >> >> > clarification on this point. > >> >> > >> >> I see the text on uses in other PKI contexts in the introduction, b= ut > >> >> don't see anything on the certificate types and out-of-band process= es > >> >> (as is the case for the STIR use case Mary mentioned). Maybe I'm > >> >> missing it, can you tell me where to look? > >> > > >> > > >> > I don't think you're missing anything. What do you mean by > "certificate > >> > types and out-of-band processes"? How is that different from "other > PKI > >> > contexts"? > >> > >> I think by PKI-context, you mean the application of use, is that > >> right? I am separating out the type of certificate (DV, EV, etc.) as > >> you have done in the second paragraph of the introduction. When > >> reading the rest of the document, there isn't text that says what type > >> of certificate ACME produces without any additional processes > >> (out-of-band authentication/validation). If you think about > >> administrators who operate servers (whatever the protocol) or even > >> those who may wish to incorporate ACME into a new application, they > >> will may have to figure out what level ACME provides as a default and > >> also know that there can be additional processes added to obtain > >> certificates types at a higher assurance level using ACME. Since the > >> text already does a nice job of explaining the certificate types, this > >> should be an easy follow up that I think will be very helpful to > >> people outside of the IETF or who look at this in the future. > >> > >> Maybe something like the following: > >> > >> Strictly following the automation enabled by ACME, DV certificates > >> are issued. > >> Additional processes can be provided by the CA to increase the leve= l > of > >> validation on an end entity to issue certificates at a higher > >> assurance level, > >> for instance an EV certificate. the > >> STIR > >> example Mary mentioned in this thread.> > >> > >> Does that help? Thinking about this in former roles and having been > >> to some conferences lately, I think being explicit about this will > >> help those trying to evaluate and deploy ACME. They may look for > >> providers who meet the assurance levels they need knowing there are > >> options and understanding the baseline provided by this spec. > > > > > > > > It's wrong to frame this as being about assurance levels -- you seem to > be > > presuming that manual processes can give higher assurance than automate= d > > ones, a fact which I think has been repeatedly proven false in the web > PKI. > > > > But I'm fine clarifying that certain things (like EV validation) have n= ot > > yet been audited: > > > > +ACME can also be used to automate some aspects of certificate manageme= nt > > even > > +where non-automated processes are still needed. For example, the > external > > +account binding feature (see {{external-account-binding}}) can be used > to > > +associate authorizations with an account that were not validated throu= gh > > the > > +ACME authorization process. This allows ACME to address issuance > scenarios > > that > > +cannot yet be fully automated, such as the issuance of Extended > Validation > > +certificates. > > You're essentially saying the same thing with this text, so I'm fine > with it. The introduction describing cert types and then not having > any statements about what is automated and what might need additional > non-automated process is an important link to make, so thanks. > These changes have been merged into the document. https://github.com/ietf-wg-acme/acme/pull/348 > > Kathleen > > > > > Updated PR: https://github.com/ietf-wg-acme/acme/pull/348 > > > > --Richard > > > > > > > >> > >> > >> Thanks, > >> Kathleen > >> > >> > >> > > >> > > >> >> > >> >> > > >> >> > > >> >> >> > >> >> >> I do like how the introduction is framed as it=E2=80=99s clear t= he level > of > >> >> >> security provided by the certificates issued via ACME. Thanks f= or > >> >> >> that. > >> >> >> > >> >> >> The introduction should also make it clear that ACME can be used > for > >> >> >> other services using DV certificates, not just HTTP. This is > >> >> >> mentioned in the Terminology section, but I think a clear senten= ce > >> >> >> upfront would be helpful. > >> >> >> > >> >> >> Section 2: Nit/suggestion: Change the tense to read as a publish= ed > >> >> >> RFC > >> >> >> in the last paragraph, last sentence (take it or leave it). > >> >> >> Current: > >> >> >> Such close integration of ACME with HTTPS > >> >> >> servers would allow the immediate and automated deployment of > >> >> >> certificates as they are issued, sparing the human > administrator > >> >> >> from > >> >> >> much of the time-consuming work described in the previous > >> >> >> section. > >> >> >> Proposed: > >> >> >> Such close integration of ACME with HTTPS > >> >> >> servers allows the immediate and automated deployment of > >> >> >> certificates as they are issued, sparing the human > administrator > >> >> >> from > >> >> >> much of the time-consuming work described in the previous > >> >> >> section. > >> >> > > >> >> > > >> >> > Done. > >> >> > > >> >> > > >> >> >> > >> >> >> IANA Section: > >> >> >> Everything looks good except that RFC5226 has been obsoleted, so > the > >> >> >> new reference is RFC8126 and =E2=80=9Cspecification required=E2= =80=9D > >> >> >> https://tools.ietf.org/html/rfc8126#section-4.6 still means the > same > >> >> >> thing, so using that is fine. > >> >> > > >> >> > > >> >> > Updated reference. > >> >> > > >> >> > > >> >> >> > >> >> >> Security considerations: > >> >> >> I think it would be good to mention here that they are DV certs = so > >> >> >> the > >> >> >> reader understands from he introduction and this section the lev= el > >> >> >> of > >> >> >> cert issued through ACME and doesn=E2=80=99t assume a higher lev= el of > >> >> >> assurance. > >> >> >> > >> >> >> s/ACME is a protocol for managing certificates/ACME is a protoco= l > >> >> >> for > >> >> >> managing DV certificates/ > >> >> > > >> >> > > >> >> > Given the discussion about DV, I don't think this change is > >> >> > appropriate. > >> >> > > >> >> > > >> >> >> > >> >> >> 10.1 - I know this is obvious to the people in the WG, but a > >> >> >> reference > >> >> >> to RFC7525 to properly configure TLS 1.2 should be included to > >> >> >> protect > >> >> >> against the mentioned attacks. If you want to also reference TL= S > >> >> >> 1.3 > >> >> >> and specify no 0-RTT that would be good too. It=E2=80=99d be gr= eat to see > >> >> >> this get widely deployed, so there may be a number of newcomers > >> >> >> reading this to make their lives easier with cert > >> >> >> issuance/maintenance. > >> >> > > >> >> > > >> >> > I don't see how TLS configuration plays into the security > >> >> > considerations > >> >> > for > >> >> > ACME. How you use the certificates you get from ACME is your > >> >> > business, > >> >> > and > >> >> > indeed, several of the envisioned applications have nothing to do > >> >> > with > >> >> > TLS > >> >> > (e.g., the email and STIR use cases). > >> >> > > >> >> > That said, I have added some language to suggest that ACME server= s > >> >> > should > >> >> > follow the advice in RFC 7525. 0xRTT should be safe here, becaus= e > >> >> > there > >> >> > are > >> >> > anti-replay protections at the application layer. > >> >> > >> >> Can you add a pointer in your text about the provided anti-replay > >> >> protections in the application layer? > >> > > >> > > >> > Draft PR here: > >> > > >> > https://github.com/ietf-wg-acme/acme/pull/348 > >> > > >> > --Richard > >> > > >> > > >> >> > >> >> > >> >> Thanks, > >> >> Kathleen > >> >> > >> >> > > >> >> > > >> >> >> > >> >> >> 10.2 - what if the server that the account verifier has an accou= nt > >> >> >> on > >> >> >> (client for ACME) is compromised and is used to request new > >> >> >> certificates or perform other actions? I think this is one of t= he > >> >> >> larger risks, so mentioning this is possible and hardening > measures > >> >> >> should be taken to prevent compromise would be prudent. Hardeni= ng > >> >> >> measures or appropriate security controls should be broadly > >> >> >> understood > >> >> >> terms (I think) so that you wouldn=E2=80=99t need to list out th= ings like > >> >> >> turing off unnecessary services. > >> >> > > >> >> > > >> >> > Added a brief note. > >> >> > > >> >> > > >> >> >> > >> >> >> 10.5 - I would think you=E2=80=99d see requests for new phishing= domains > >> >> >> rather than known ones through this process. What would you loo= k > >> >> >> for > >> >> >> there as that=E2=80=99s a complex problem - it would be hard to = know all > >> >> >> legit > >> >> >> names to know if one was a play off of the original. This > happened > >> >> >> with equifax - they provided a site name with a typo and a =E2= =80=98white > >> >> >> hat=E2=80=99 > >> >> >> attacker had set up a site that looked just like theirs at that > >> >> >> site. > >> >> >> But it was announced by equifax. Tough problem as automating a > >> >> >> check > >> >> >> on the DNS registration may not detect something unusual, but > maybe > >> >> >> recommending this check could help? RDP lessens what needs to b= e > >> >> >> shared from whois though, although I don=E2=80=99t think that=E2= =80=99s widely > >> >> >> deployed. > >> >> > > >> >> > > >> >> > This is a policy question, not one for the issuance protocol. > >> >> > > >> >> > --Richard > >> >> > > >> >> > > >> >> >> > >> >> >> > >> >> >> -- > >> >> >> > >> >> >> Best regards, > >> >> >> Kathleen > >> >> >> > >> >> >> _______________________________________________ > >> >> >> Acme mailing list > >> >> >> Acme@ietf.org > >> >> >> https://www.ietf.org/mailman/listinfo/acme > >> >> > > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> > >> >> Best regards, > >> >> Kathleen > >> > > >> > > >> > >> > >> > >> -- > >> > >> Best regards, > >> Kathleen > > > > > > > > -- > > Best regards, > Kathleen > --f403045d55a6c998d5055d48e949 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Nov 3, 2017 at 12:59 PM, Kathleen Moriarty &l= t;kat= hleen.moriarty.ietf@gmail.com> wrote:
On Tue, Oct 31, 2017 at 3:51 PM, Richard Barnes <rlb@ipv.sx> w= rote:
>
>
> On Mon, Oct 30, 2017 at 9:37 PM, Kathleen Moriarty
> <kathleen.moria= rty.ietf@gmail.com> wrote:
>>
>> Hi Richard,
>>
>> On Mon, Oct 30, 2017 at 6:27 PM, Richard Barnes <rlb@ipv.sx>= wrote:
>> >
>> >
>> > On Mon, Oct 30, 2017 at 5:00 PM, Kathleen Moriarty
>> > <kathl= een.moriarty.ietf@gmail.com> wrote:
>> >>
>> >> Hi Richard,
>> >>
>> >> Thanks for posting the diff, I reviewed the changes and t= hey look
>> >> good, but I have a couple of questions.=C2=A0 FYI - I had= started looking
>> >> at the PR, but something came up, sorry for the delay and= this was a
>> >> good reminder.
>> >>
>> >> On Thu, Oct 19, 2017 at 12:45 PM, Richard Barnes <rlb@= ipv.sx> wrote:
>> >> > Hi Kathleen,
>> >> >
>> >> > Thanks for the review.=C2=A0 Some responses inline.= =C2=A0 I've started a PR to
>> >> > respond
>> >> > to these comments here:
>> >> >
>> >> > https://github.com/ietf-wg-= acme/acme/pull/345
>> >> >
>> >> > I agree with Daniel that we should hold off on IETF = LC until we've
>> >> > addressed
>> >> > the issues around proactive issuance / caching of CS= Rs.=C2=A0 That may
>> >> > require a
>> >> > re-WGLC, but once that's closed, it should be sa= fe to send to IETF
>> >> > LC.
>> >> >
>> >> >
>> >> > On Fri, Sep 22, 2017 at 4:14 PM, Kathleen Moriarty >> >> > <kathleen.moriarty.ietf@gmail.com> wrote:
>> >> >>
>> >> >> Hello,
>> >> >>
>> >> >> Thank you to the editors and WG for your efforts= on
>> >> >> draft-ietf-acme-acme, it's a well written an= d easy to understand
>> >> >> draft.=C2=A0 I do have a few comments, that need= to be address by the
>> >> >> editors and SHEPHERD.
>> >> >>
>> >> >> Please review the idnits.=C2=A0 There are a few = warnings that should be
>> >> >> correctable and can be addressed, but more impor= tantly, it calls out
>> >> >> several downrefs that are not in the shepherd wr= iteup.=C2=A0 These need
>> >> >> to
>> >> >> be in the writeup and then also mentioned in the= IETF last call
>> >> >> announcement (I'll make sure the latter happ= ens).
>> >> >>
>> >> >> Here's my mostly editorial comments:
>> >> >>
>> >> >> Introduction:
>> >> >> It reads very well, but it would be helpful to t= hose unfamiliar with
>> >> >> the work to explicitly state that ACME is about = DV certificates.
>> >> >> The
>> >> >> first sentence of the last paragraph seems like = the best place to
>> >> >> add
>> >> >> this in.
>> >> >> Current text:
>> >> >>=C2=A0 =C2=A0 This document describes an extensib= le framework for automating
>> >> >> the
>> >> >>=C2=A0 =C2=A0 issuance and domain validation proc= edure, thereby allowing
>> >> >> servers
>> >> >>=C2=A0 =C2=A0 and infrastructural software to obt= ain certificates without user
>> >> >>=C2=A0 =C2=A0 interaction.
>> >> >> Proposed:
>> >> >>=C2=A0 =C2=A0 This document describes an extensib= le framework for automating
>> >> >> the
>> >> >>=C2=A0 =C2=A0 issuance and domain validation proc= edure for DV certificates,
>> >> >> thereby allowing servers
>> >> >>=C2=A0 =C2=A0 and infrastructural software to obt= ain certificates without user
>> >> >>=C2=A0 =C2=A0 interaction.
>> >> >
>> >> >
>> >> > As others have pointed out, ACME is not just about D= V.=C2=A0 PR has some
>> >> > clarification on this point.
>> >>
>> >> I see the text on uses in other PKI contexts in the intro= duction, but
>> >> don't see anything on the certificate types and out-o= f-band processes
>> >> (as is the case for the STIR use case Mary mentioned).=C2= =A0 Maybe I'm
>> >> missing it, can you tell me where to look?
>> >
>> >
>> > I don't think you're missing anything.=C2=A0 What do = you mean by "certificate
>> > types and out-of-band processes"?=C2=A0 How is that diff= erent from "other PKI
>> > contexts"?
>>
>> I think by PKI-context, you mean the application of use, is that >> right?=C2=A0 I am separating out the type of certificate (DV, EV, = etc.) as
>> you have done in the second paragraph of the introduction.=C2=A0 W= hen
>> reading the rest of the document, there isn't text that says w= hat type
>> of certificate ACME produces without any additional processes
>> (out-of-band authentication/validation).=C2=A0 If you think about<= br> >> administrators who operate servers (whatever the protocol) or even=
>> those who may wish to incorporate ACME into a new application, the= y
>> will may have to figure out what level ACME provides as a default = and
>> also know that there can be additional processes added to obtain >> certificates types at a higher assurance level using ACME.=C2=A0 S= ince the
>> text already does a nice job of explaining the certificate types, = this
>> should be an easy follow up that I think will be very helpful to >> people outside of the IETF or who look at this in the future.
>>
>> Maybe something like the following:
>>
>>=C2=A0 =C2=A0 Strictly following the automation enabled by ACME, DV= certificates
>> are issued.
>>=C2=A0 =C2=A0 Additional processes can be provided by the CA to inc= rease the level of
>>=C2=A0 =C2=A0 validation on an end entity to issue certificates at = a higher
>> assurance level,
>>=C2=A0 =C2=A0 for instance an EV certificate.=C2=A0 <Then maybe = provide a reference to the
>> STIR
>>=C2=A0 =C2=A0 example Mary mentioned in this thread.>
>>
>> Does that help?=C2=A0 Thinking about this in former roles and havi= ng been
>> to some conferences lately, I think being explicit about this will=
>> help those trying to evaluate and deploy ACME.=C2=A0 They may look= for
>> providers who meet the assurance levels they need knowing there ar= e
>> options and understanding the baseline provided by this spec.
>
>
>
> It's wrong to frame this as being about assurance levels -- you se= em to be
> presuming that manual processes can give higher assurance than automat= ed
> ones, a fact which I think has been repeatedly proven false in the web= PKI.
>
> But I'm fine clarifying that certain things (like EV validation) h= ave not
> yet been audited:
>
> +ACME can also be used to automate some aspects of certificate managem= ent
> even
> +where non-automated processes are still needed.=C2=A0 For example, th= e external
> +account binding feature (see {{external-account-binding}}) can be use= d to
> +associate authorizations with an account that were not validated thro= ugh
> the
> +ACME authorization process.=C2=A0 This allows ACME to address issuanc= e scenarios
> that
> +cannot yet be fully automated, such as the issuance of Extended Valid= ation
> +certificates.

You're essentially saying the same thing with this text, so= I'm fine
with it.=C2=A0 The introduction describing cert types and then not having any statements about what is automated and what might need additional
non-automated process is an important link to make, so thanks.

These changes have been merged into the document. <= br>



=C2=A0

Kathleen

>
> Updated PR: https://github.com/ietf-wg-acme/a= cme/pull/348
>
> --Richard
>
>
>
>>
>>
>> Thanks,
>> Kathleen
>>
>>
>> >
>> >
>> >>
>> >> >
>> >> >
>> >> >>
>> >> >> I do like how the introduction is framed as it= =E2=80=99s clear the level of
>> >> >> security provided by the certificates issued via= ACME.=C2=A0 Thanks for
>> >> >> that.
>> >> >>
>> >> >> The introduction should also make it clear that = ACME can be used for
>> >> >> other services using DV certificates, not just H= TTP.=C2=A0 This is
>> >> >> mentioned in the Terminology section, but I thin= k a clear sentence
>> >> >> upfront would be helpful.
>> >> >>
>> >> >> Section 2: Nit/suggestion: Change the tense to r= ead as a published
>> >> >> RFC
>> >> >> in the last paragraph, last sentence (take it or= leave it).
>> >> >> Current:
>> >> >>=C2=A0 =C2=A0 Such close integration of ACME with= HTTPS
>> >> >>=C2=A0 =C2=A0 servers would allow the immediate a= nd automated deployment of
>> >> >>=C2=A0 =C2=A0 certificates as they are issued, sp= aring the human administrator
>> >> >> from
>> >> >>=C2=A0 =C2=A0 much of the time-consuming work des= cribed in the previous
>> >> >> section.
>> >> >> Proposed:
>> >> >>=C2=A0 =C2=A0 Such close integration of ACME with= HTTPS
>> >> >>=C2=A0 =C2=A0 servers allows the immediate and au= tomated deployment of
>> >> >>=C2=A0 =C2=A0 certificates as they are issued, sp= aring the human administrator
>> >> >> from
>> >> >>=C2=A0 =C2=A0 much of the time-consuming work des= cribed in the previous
>> >> >> section.
>> >> >
>> >> >
>> >> > Done.
>> >> >
>> >> >
>> >> >>
>> >> >> IANA Section:
>> >> >> Everything looks good except that RFC5226 has be= en obsoleted, so the
>> >> >> new reference is RFC8126 and =E2=80=9Cspecificat= ion required=E2=80=9D
>> >> >> https://tools.ietf.org/htm= l/rfc8126#section-4.6 still means the same
>> >> >> thing, so using that is fine.
>> >> >
>> >> >
>> >> > Updated reference.
>> >> >
>> >> >
>> >> >>
>> >> >> Security considerations:
>> >> >> I think it would be good to mention here that th= ey are DV certs so
>> >> >> the
>> >> >> reader understands from he introduction and this= section the level
>> >> >> of
>> >> >> cert issued through ACME and doesn=E2=80=99t ass= ume a higher level of
>> >> >> assurance.
>> >> >>
>> >> >> s/ACME is a protocol for managing certificates/A= CME is a protocol
>> >> >> for
>> >> >> managing DV certificates/
>> >> >
>> >> >
>> >> > Given the discussion about DV, I don't think thi= s change is
>> >> > appropriate.
>> >> >
>> >> >
>> >> >>
>> >> >> 10.1 - I know this is obvious to the people in t= he WG, but a
>> >> >> reference
>> >> >> to RFC7525 to properly configure TLS 1.2 should = be included to
>> >> >> protect
>> >> >> against the mentioned attacks.=C2=A0 If you want= to also reference TLS
>> >> >> 1.3
>> >> >> and specify no 0-RTT that would be good too.=C2= =A0 It=E2=80=99d be great to see
>> >> >> this get widely deployed, so there may be a numb= er of newcomers
>> >> >> reading this to make their lives easier with cer= t
>> >> >> issuance/maintenance.
>> >> >
>> >> >
>> >> > I don't see how TLS configuration plays into the= security
>> >> > considerations
>> >> > for
>> >> > ACME.=C2=A0 How you use the certificates you get fro= m ACME is your
>> >> > business,
>> >> > and
>> >> > indeed, several of the envisioned applications have = nothing to do
>> >> > with
>> >> > TLS
>> >> > (e.g., the email and STIR use cases).
>> >> >
>> >> > That said, I have added some language to suggest tha= t ACME servers
>> >> > should
>> >> > follow the advice in RFC 7525.=C2=A0 0xRTT should be= safe here, because
>> >> > there
>> >> > are
>> >> > anti-replay protections at the application layer. >> >>
>> >> Can you add a pointer in your text about the provided ant= i-replay
>> >> protections in the application layer?
>> >
>> >
>> > Draft PR here:
>> >
>> > https://github.com/ietf-wg-acme/acme= /pull/348
>> >
>> > --Richard
>> >
>> >
>> >>
>> >>
>> >> Thanks,
>> >> Kathleen
>> >>
>> >> >
>> >> >
>> >> >>
>> >> >> 10.2 - what if the server that the account verif= ier has an account
>> >> >> on
>> >> >> (client for ACME) is compromised and is used to = request new
>> >> >> certificates or perform other actions?=C2=A0 I t= hink this is one of the
>> >> >> larger risks, so mentioning this is possible and= hardening measures
>> >> >> should be taken to prevent compromise would be p= rudent.=C2=A0 Hardening
>> >> >> measures or appropriate security controls should= be broadly
>> >> >> understood
>> >> >> terms (I think) so that you wouldn=E2=80=99t nee= d to list out things like
>> >> >> turing off unnecessary services.
>> >> >
>> >> >
>> >> > Added a brief note.
>> >> >
>> >> >
>> >> >>
>> >> >> 10.5 - I would think you=E2=80=99d see requests = for new phishing domains
>> >> >> rather than known ones through this process.=C2= =A0 What would you look
>> >> >> for
>> >> >> there as that=E2=80=99s a complex problem - it w= ould be hard to know all
>> >> >> legit
>> >> >> names to know if one was a play off of the origi= nal.=C2=A0 This happened
>> >> >> with equifax - they provided a site name with a = typo and a =E2=80=98white
>> >> >> hat=E2=80=99
>> >> >> attacker had set up a site that looked just like= theirs at that
>> >> >> site.
>> >> >> But it was announced by equifax.=C2=A0 Tough pro= blem as automating a
>> >> >> check
>> >> >> on the DNS registration may not detect something= unusual, but maybe
>> >> >> recommending this check could help?=C2=A0 RDP le= ssens what needs to be
>> >> >> shared from whois though, although I don=E2=80= =99t think that=E2=80=99s widely
>> >> >> deployed.
>> >> >
>> >> >
>> >> > This is a policy question, not one for the issuance = protocol.
>> >> >
>> >> > --Richard
>> >> >
>> >> >
>> >> >>
>> >> >>
>> >> >> --
>> >> >>
>> >> >> Best regards,
>> >> >> Kathleen
>> >> >>
>> >> >> ___________________________________________= ____
>> >> >> Acme mailing list
>> >> >> Acme@ietf.org
>> >> >> https://www.ietf.org/mailman/listinfo/acme
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> Best regards,
>> >> Kathleen
>> >
>> >
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>
>



--

Best regards,
Kathleen

--f403045d55a6c998d5055d48e949-- From nobody Mon Nov 6 03:53: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 29DE513FBAD for ; Mon, 6 Nov 2017 03:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0BKdm-vseFf for ; Mon, 6 Nov 2017 03:53:08 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::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 9FAD413FB9B for ; Mon, 6 Nov 2017 03:53:07 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id o6so3546450qkh.3 for ; Mon, 06 Nov 2017 03:53:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W4xdXolHwJdO+uIhY+XrstkoLF67KLKbyjALSQuM/CI=; b=R4US3YC/S9TOCflGeCHRkjS9WkhwhTEk1wmKh9y+4Yd4gl3ZDb2kQKj5LKmjoTb8UY M0jovlxh31SXvu/XRnzy4dFNrRZzVg7KFPJOvE3Q3ZiuPoQ8CmKueKgWByQhM87NJfmw e885wQ5PX/gma1KPXbv2W1JO65DjJxYfQ7c5RFFFnHmVg1b3fhNlpRsZFnrhFhd68G3D pbZNTb2oBNBq751yQODS7TXsU0WxlcmUwy55OoeCevuHoMsLO/rJQo+CW6xqMx7yi7OV och76Qjt+1xsNKieBCw72I3a5ZcEUZ+ldqTr9GHkp1QQSczup8O3IjNvXTLVvQ9Re5Im LpTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W4xdXolHwJdO+uIhY+XrstkoLF67KLKbyjALSQuM/CI=; b=OCTz5s3P9RMICvDRMfwiLcyr4W7eFEt+AcOXG9x/HAcppTEoBiQg6tI2pgfVHyqbDr 9I10DKxsZ1i9utZTZowkZBK/BUgul5lT2/cfvUmfe6HKQ4Z6juaKuS+tbn0vOtZcw1NM x1nYA8BCJoM2rCeIeNjMTLwekU4ZSyLNS3WHntukv4yCQR92PqsMRhZKtzeLlo90c3dW YZIwgurCbnCmYL+wYhJpMovLLxqB0r12NerNKOQeu2DvH46SKOFILgG2D3ILNl2MgN0p 2zMYhgK+5E5ACnmZCCNMaqEmIAwadVrVJFiUb5BLE7pbCvCQms8vZXBB5//peLQH59OP vEGQ== X-Gm-Message-State: AJaThX5easO12vU3aQiYvuTvfpfhgCLi+ZB9edZYIJKF2+D2FgPqvUAd JdZ3eD1KKllLZelaWPSDu3B/tiah X-Google-Smtp-Source: ABhQp+R0Fco3ZkmToVQek4MTbqlJAW8TsygflC2PDmQakgz5d8xhICQ+B4UdcufP2PCBlXi02lMn7g== X-Received: by 10.55.217.85 with SMTP id u82mr7641572qki.257.1509969186467; Mon, 06 Nov 2017 03:53:06 -0800 (PST) Received: from [192.168.1.186] (209-6-112-84.s338.c3-0.arl-ubr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.112.84]) by smtp.gmail.com with ESMTPSA id x35sm8049393qte.26.2017.11.06.03.53.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Nov 2017 03:53:05 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-32B74BAA-C463-4250-8D2E-D9DB23CB45E6 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Mon, 6 Nov 2017 06:53:04 -0500 Cc: IETF ACME Content-Transfer-Encoding: 7bit Message-Id: <6401CB54-C876-403E-9F09-E2698011A30D@gmail.com> References: To: Richard Barnes Archived-At: Subject: Re: [Acme] AD review of draft-ietf-acme-acme X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 11:53:11 -0000 --Apple-Mail-32B74BAA-C463-4250-8D2E-D9DB23CB45E6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you! Sent from my iPhone > On Nov 5, 2017, at 11:30 PM, Richard Barnes wrote: >=20 >=20 >=20 >> On Fri, Nov 3, 2017 at 12:59 PM, Kathleen Moriarty wrote: >> On Tue, Oct 31, 2017 at 3:51 PM, Richard Barnes wrote: >> > >> > >> > On Mon, Oct 30, 2017 at 9:37 PM, Kathleen Moriarty >> > wrote: >> >> >> >> Hi Richard, >> >> >> >> On Mon, Oct 30, 2017 at 6:27 PM, Richard Barnes wrote: >> >> > >> >> > >> >> > On Mon, Oct 30, 2017 at 5:00 PM, Kathleen Moriarty >> >> > wrote: >> >> >> >> >> >> Hi Richard, >> >> >> >> >> >> Thanks for posting the diff, I reviewed the changes and they look >> >> >> good, but I have a couple of questions. FYI - I had started lookin= g >> >> >> at the PR, but something came up, sorry for the delay and this was a= >> >> >> good reminder. >> >> >> >> >> >> On Thu, Oct 19, 2017 at 12:45 PM, Richard Barnes wrote= : >> >> >> > Hi Kathleen, >> >> >> > >> >> >> > Thanks for the review. Some responses inline. I've started a PR= to >> >> >> > respond >> >> >> > to these comments here: >> >> >> > >> >> >> > https://github.com/ietf-wg-acme/acme/pull/345 >> >> >> > >> >> >> > I agree with Daniel that we should hold off on IETF LC until we'v= e >> >> >> > addressed >> >> >> > the issues around proactive issuance / caching of CSRs. That may= >> >> >> > require a >> >> >> > re-WGLC, but once that's closed, it should be safe to send to IET= F >> >> >> > LC. >> >> >> > >> >> >> > >> >> >> > On Fri, Sep 22, 2017 at 4:14 PM, Kathleen Moriarty >> >> >> > wrote: >> >> >> >> >> >> >> >> Hello, >> >> >> >> >> >> >> >> Thank you to the editors and WG for your efforts on >> >> >> >> draft-ietf-acme-acme, it's a well written and easy to understand= >> >> >> >> draft. I do have a few comments, that need to be address by the= >> >> >> >> editors and SHEPHERD. >> >> >> >> >> >> >> >> Please review the idnits. There are a few warnings that should b= e >> >> >> >> correctable and can be addressed, but more importantly, it calls= out >> >> >> >> several downrefs that are not in the shepherd writeup. These ne= ed >> >> >> >> to >> >> >> >> be in the writeup and then also mentioned in the IETF last call >> >> >> >> announcement (I'll make sure the latter happens). >> >> >> >> >> >> >> >> Here's my mostly editorial comments: >> >> >> >> >> >> >> >> Introduction: >> >> >> >> It reads very well, but it would be helpful to those unfamiliar w= ith >> >> >> >> the work to explicitly state that ACME is about DV certificates.= >> >> >> >> The >> >> >> >> first sentence of the last paragraph seems like the best place t= o >> >> >> >> add >> >> >> >> this in. >> >> >> >> Current text: >> >> >> >> This document describes an extensible framework for automatin= g >> >> >> >> the >> >> >> >> issuance and domain validation procedure, thereby allowing >> >> >> >> servers >> >> >> >> and infrastructural software to obtain certificates without u= ser >> >> >> >> interaction. >> >> >> >> Proposed: >> >> >> >> This document describes an extensible framework for automatin= g >> >> >> >> the >> >> >> >> issuance and domain validation procedure for DV certificates,= >> >> >> >> thereby allowing servers >> >> >> >> and infrastructural software to obtain certificates without u= ser >> >> >> >> interaction. >> >> >> > >> >> >> > >> >> >> > As others have pointed out, ACME is not just about DV. PR has so= me >> >> >> > clarification on this point. >> >> >> >> >> >> I see the text on uses in other PKI contexts in the introduction, b= ut >> >> >> don't see anything on the certificate types and out-of-band process= es >> >> >> (as is the case for the STIR use case Mary mentioned). Maybe I'm >> >> >> missing it, can you tell me where to look? >> >> > >> >> > >> >> > I don't think you're missing anything. What do you mean by "certifi= cate >> >> > types and out-of-band processes"? How is that different from "other= PKI >> >> > contexts"? >> >> >> >> I think by PKI-context, you mean the application of use, is that >> >> right? I am separating out the type of certificate (DV, EV, etc.) as >> >> you have done in the second paragraph of the introduction. When >> >> reading the rest of the document, there isn't text that says what type= >> >> of certificate ACME produces without any additional processes >> >> (out-of-band authentication/validation). If you think about >> >> administrators who operate servers (whatever the protocol) or even >> >> those who may wish to incorporate ACME into a new application, they >> >> will may have to figure out what level ACME provides as a default and >> >> also know that there can be additional processes added to obtain >> >> certificates types at a higher assurance level using ACME. Since the >> >> text already does a nice job of explaining the certificate types, this= >> >> should be an easy follow up that I think will be very helpful to >> >> people outside of the IETF or who look at this in the future. >> >> >> >> Maybe something like the following: >> >> >> >> Strictly following the automation enabled by ACME, DV certificates >> >> are issued. >> >> Additional processes can be provided by the CA to increase the leve= l of >> >> validation on an end entity to issue certificates at a higher >> >> assurance level, >> >> for instance an EV certificate. > >> STIR >> >> example Mary mentioned in this thread.> >> >> >> >> Does that help? Thinking about this in former roles and having been >> >> to some conferences lately, I think being explicit about this will >> >> help those trying to evaluate and deploy ACME. They may look for >> >> providers who meet the assurance levels they need knowing there are >> >> options and understanding the baseline provided by this spec. >> > >> > >> > >> > It's wrong to frame this as being about assurance levels -- you seem to= be >> > presuming that manual processes can give higher assurance than automate= d >> > ones, a fact which I think has been repeatedly proven false in the web P= KI. >> > >> > But I'm fine clarifying that certain things (like EV validation) have n= ot >> > yet been audited: >> > >> > +ACME can also be used to automate some aspects of certificate manageme= nt >> > even >> > +where non-automated processes are still needed. For example, the exte= rnal >> > +account binding feature (see {{external-account-binding}}) can be used= to >> > +associate authorizations with an account that were not validated throu= gh >> > the >> > +ACME authorization process. This allows ACME to address issuance scen= arios >> > that >> > +cannot yet be fully automated, such as the issuance of Extended Valida= tion >> > +certificates. >>=20 >> You're essentially saying the same thing with this text, so I'm fine >> with it. The introduction describing cert types and then not having >> any statements about what is automated and what might need additional >> non-automated process is an important link to make, so thanks. >=20 > These changes have been merged into the document.=20 >=20 > https://github.com/ietf-wg-acme/acme/pull/348 >=20 >=20 > =20 >>=20 >> Kathleen >>=20 >> > >> > Updated PR: https://github.com/ietf-wg-acme/acme/pull/348 >> > >> > --Richard >> > >> > >> > >> >> >> >> >> >> Thanks, >> >> Kathleen >> >> >> >> >> >> > >> >> > >> >> >> >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> I do like how the introduction is framed as it=E2=80=99s clear t= he level of >> >> >> >> security provided by the certificates issued via ACME. Thanks f= or >> >> >> >> that. >> >> >> >> >> >> >> >> The introduction should also make it clear that ACME can be used= for >> >> >> >> other services using DV certificates, not just HTTP. This is >> >> >> >> mentioned in the Terminology section, but I think a clear senten= ce >> >> >> >> upfront would be helpful. >> >> >> >> >> >> >> >> Section 2: Nit/suggestion: Change the tense to read as a publish= ed >> >> >> >> RFC >> >> >> >> in the last paragraph, last sentence (take it or leave it). >> >> >> >> Current: >> >> >> >> Such close integration of ACME with HTTPS >> >> >> >> servers would allow the immediate and automated deployment of= >> >> >> >> certificates as they are issued, sparing the human administra= tor >> >> >> >> from >> >> >> >> much of the time-consuming work described in the previous >> >> >> >> section. >> >> >> >> Proposed: >> >> >> >> Such close integration of ACME with HTTPS >> >> >> >> servers allows the immediate and automated deployment of >> >> >> >> certificates as they are issued, sparing the human administra= tor >> >> >> >> from >> >> >> >> much of the time-consuming work described in the previous >> >> >> >> section. >> >> >> > >> >> >> > >> >> >> > Done. >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> IANA Section: >> >> >> >> Everything looks good except that RFC5226 has been obsoleted, so= the >> >> >> >> new reference is RFC8126 and =E2=80=9Cspecification required=E2=80= =9D >> >> >> >> https://tools.ietf.org/html/rfc8126#section-4.6 still means the s= ame >> >> >> >> thing, so using that is fine. >> >> >> > >> >> >> > >> >> >> > Updated reference. >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> Security considerations: >> >> >> >> I think it would be good to mention here that they are DV certs s= o >> >> >> >> the >> >> >> >> reader understands from he introduction and this section the lev= el >> >> >> >> of >> >> >> >> cert issued through ACME and doesn=E2=80=99t assume a higher lev= el of >> >> >> >> assurance. >> >> >> >> >> >> >> >> s/ACME is a protocol for managing certificates/ACME is a protoco= l >> >> >> >> for >> >> >> >> managing DV certificates/ >> >> >> > >> >> >> > >> >> >> > Given the discussion about DV, I don't think this change is >> >> >> > appropriate. >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> 10.1 - I know this is obvious to the people in the WG, but a >> >> >> >> reference >> >> >> >> to RFC7525 to properly configure TLS 1.2 should be included to >> >> >> >> protect >> >> >> >> against the mentioned attacks. If you want to also reference TL= S >> >> >> >> 1.3 >> >> >> >> and specify no 0-RTT that would be good too. It=E2=80=99d be gr= eat to see >> >> >> >> this get widely deployed, so there may be a number of newcomers >> >> >> >> reading this to make their lives easier with cert >> >> >> >> issuance/maintenance. >> >> >> > >> >> >> > >> >> >> > I don't see how TLS configuration plays into the security >> >> >> > considerations >> >> >> > for >> >> >> > ACME. How you use the certificates you get from ACME is your >> >> >> > business, >> >> >> > and >> >> >> > indeed, several of the envisioned applications have nothing to do= >> >> >> > with >> >> >> > TLS >> >> >> > (e.g., the email and STIR use cases). >> >> >> > >> >> >> > That said, I have added some language to suggest that ACME server= s >> >> >> > should >> >> >> > follow the advice in RFC 7525. 0xRTT should be safe here, becaus= e >> >> >> > there >> >> >> > are >> >> >> > anti-replay protections at the application layer. >> >> >> >> >> >> Can you add a pointer in your text about the provided anti-replay >> >> >> protections in the application layer? >> >> > >> >> > >> >> > Draft PR here: >> >> > >> >> > https://github.com/ietf-wg-acme/acme/pull/348 >> >> > >> >> > --Richard >> >> > >> >> > >> >> >> >> >> >> >> >> >> Thanks, >> >> >> Kathleen >> >> >> >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> 10.2 - what if the server that the account verifier has an accou= nt >> >> >> >> on >> >> >> >> (client for ACME) is compromised and is used to request new >> >> >> >> certificates or perform other actions? I think this is one of t= he >> >> >> >> larger risks, so mentioning this is possible and hardening measu= res >> >> >> >> should be taken to prevent compromise would be prudent. Hardeni= ng >> >> >> >> measures or appropriate security controls should be broadly >> >> >> >> understood >> >> >> >> terms (I think) so that you wouldn=E2=80=99t need to list out th= ings like >> >> >> >> turing off unnecessary services. >> >> >> > >> >> >> > >> >> >> > Added a brief note. >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> 10.5 - I would think you=E2=80=99d see requests for new phishing= domains >> >> >> >> rather than known ones through this process. What would you loo= k >> >> >> >> for >> >> >> >> there as that=E2=80=99s a complex problem - it would be hard to k= now all >> >> >> >> legit >> >> >> >> names to know if one was a play off of the original. This happe= ned >> >> >> >> with equifax - they provided a site name with a typo and a =E2=80= =98white >> >> >> >> hat=E2=80=99 >> >> >> >> attacker had set up a site that looked just like theirs at that >> >> >> >> site. >> >> >> >> But it was announced by equifax. Tough problem as automating a >> >> >> >> check >> >> >> >> on the DNS registration may not detect something unusual, but ma= ybe >> >> >> >> recommending this check could help? RDP lessens what needs to b= e >> >> >> >> shared from whois though, although I don=E2=80=99t think that=E2= =80=99s widely >> >> >> >> deployed. >> >> >> > >> >> >> > >> >> >> > This is a policy question, not one for the issuance protocol. >> >> >> > >> >> >> > --Richard >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> >> >> >> Best regards, >> >> >> >> Kathleen >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> Acme mailing list >> >> >> >> Acme@ietf.org >> >> >> >> https://www.ietf.org/mailman/listinfo/acme >> >> >> > >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> >> >> Best regards, >> >> >> Kathleen >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> >> >> Best regards, >> >> Kathleen >> > >> > >>=20 >>=20 >>=20 >> -- >>=20 >> Best regards, >> Kathleen >=20 --Apple-Mail-32B74BAA-C463-4250-8D2E-D9DB23CB45E6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thank you!

Sent from my iPhone<= /div>

On Nov 5, 2017, at 11:30 PM, Richard Barnes <rlb@ipv.sx> wrote:



On Fri, Nov 3, 2017 at 12:59 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
On Tue, Oct 31, 2017 at 3:51 PM, Richard Barnes <rlb@ipv.sx> wrote:
>
>
> On Mon, Oct 30, 2017 at 9:37 PM, Kathleen Moriarty
> <kathleen.moriar= ty.ietf@gmail.com> wrote:
>>
>> Hi Richard,
>>
>> On Mon, Oct 30, 2017 at 6:27 PM, Richard Barnes <rlb@ipv.sx> wrote:
>> >
>> >
>> > On Mon, Oct 30, 2017 at 5:00 PM, Kathleen Moriarty
>> > <kathle= en.moriarty.ietf@gmail.com> wrote:
>> >>
>> >> Hi Richard,
>> >>
>> >> Thanks for posting the diff, I reviewed the changes and th= ey look
>> >> good, but I have a couple of questions.  FYI - I had s= tarted looking
>> >> at the PR, but something came up, sorry for the delay and t= his was a
>> >> good reminder.
>> >>
>> >> On Thu, Oct 19, 2017 at 12:45 PM, Richard Barnes <rlb@ipv.sx> wrote:
>> >> > Hi Kathleen,
>> >> >
>> >> > Thanks for the review.  Some responses inline.&n= bsp; I've started a PR to
>> >> > respond
>> >> > to these comments here:
>> >> >
>> >> > https://github.com/ietf-wg-ac= me/acme/pull/345
>> >> >
>> >> > I agree with Daniel that we should hold off on IETF L= C until we've
>> >> > addressed
>> >> > the issues around proactive issuance / caching of CSR= s.  That may
>> >> > require a
>> >> > re-WGLC, but once that's closed, it should be safe to= send to IETF
>> >> > LC.
>> >> >
>> >> >
>> >> > On Fri, Sep 22, 2017 at 4:14 PM, Kathleen Moriarty >> >> > <kathleen.moriarty.ietf@gmail.com> wrote:
>> >> >>
>> >> >> Hello,
>> >> >>
>> >> >> Thank you to the editors and WG for your efforts o= n
>> >> >> draft-ietf-acme-acme, it's a well written and eas= y to understand
>> >> >> draft.  I do have a few comments, that need t= o be address by the
>> >> >> editors and SHEPHERD.
>> >> >>
>> >> >> Please review the idnits.  There are a few w= arnings that should be
>> >> >> correctable and can be addressed, but more import= antly, it calls out
>> >> >> several downrefs that are not in the shepherd wri= teup.  These need
>> >> >> to
>> >> >> be in the writeup and then also mentioned in the I= ETF last call
>> >> >> announcement (I'll make sure the latter happens).=
>> >> >>
>> >> >> Here's my mostly editorial comments:
>> >> >>
>> >> >> Introduction:
>> >> >> It reads very well, but it would be helpful to th= ose unfamiliar with
>> >> >> the work to explicitly state that ACME is about D= V certificates.
>> >> >> The
>> >> >> first sentence of the last paragraph seems like t= he best place to
>> >> >> add
>> >> >> this in.
>> >> >> Current text:
>> >> >>    This document describes an extensibl= e framework for automating
>> >> >> the
>> >> >>    issuance and domain validation proce= dure, thereby allowing
>> >> >> servers
>> >> >>    and infrastructural software to obta= in certificates without user
>> >> >>    interaction.
>> >> >> Proposed:
>> >> >>    This document describes an extensibl= e framework for automating
>> >> >> the
>> >> >>    issuance and domain validation proce= dure for DV certificates,
>> >> >> thereby allowing servers
>> >> >>    and infrastructural software to obta= in certificates without user
>> >> >>    interaction.
>> >> >
>> >> >
>> >> > As others have pointed out, ACME is not just about DV= .  PR has some
>> >> > clarification on this point.
>> >>
>> >> I see the text on uses in other PKI contexts in the introd= uction, but
>> >> don't see anything on the certificate types and out-of-ban= d processes
>> >> (as is the case for the STIR use case Mary mentioned).&nbs= p; Maybe I'm
>> >> missing it, can you tell me where to look?
>> >
>> >
>> > I don't think you're missing anything.  What do you mean b= y "certificate
>> > types and out-of-band processes"?  How is that different f= rom "other PKI
>> > contexts"?
>>
>> I think by PKI-context, you mean the application of use, is that >> right?  I am separating out the type of certificate (DV, EV, e= tc.) as
>> you have done in the second paragraph of the introduction.  Wh= en
>> reading the rest of the document, there isn't text that says what t= ype
>> of certificate ACME produces without any additional processes
>> (out-of-band authentication/validation).  If you think about >> administrators who operate servers (whatever the protocol) or even<= br> >> those who may wish to incorporate ACME into a new application, they=
>> will may have to figure out what level ACME provides as a default a= nd
>> also know that there can be additional processes added to obtain >> certificates types at a higher assurance level using ACME.  Si= nce the
>> text already does a nice job of explaining the certificate types, t= his
>> should be an easy follow up that I think will be very helpful to >> people outside of the IETF or who look at this in the future.
>>
>> Maybe something like the following:
>>
>>    Strictly following the automation enabled by ACME, DV c= ertificates
>> are issued.
>>    Additional processes can be provided by the CA to incr= ease the level of
>>    validation on an end entity to issue certificates at a= higher
>> assurance level,
>>    for instance an EV certificate.  <Then maybe p= rovide a reference to the
>> STIR
>>    example Mary mentioned in this thread.>
>>
>> Does that help?  Thinking about this in former roles and havin= g been
>> to some conferences lately, I think being explicit about this will<= br> >> help those trying to evaluate and deploy ACME.  They may look f= or
>> providers who meet the assurance levels they need knowing there are=
>> options and understanding the baseline provided by this spec.
>
>
>
> It's wrong to frame this as being about assurance levels -- you seem to= be
> presuming that manual processes can give higher assurance than automate= d
> ones, a fact which I think has been repeatedly proven false in the web P= KI.
>
> But I'm fine clarifying that certain things (like EV validation) have n= ot
> yet been audited:
>
> +ACME can also be used to automate some aspects of certificate manageme= nt
> even
> +where non-automated processes are still needed.  For example, the= external
> +account binding feature (see {{external-account-binding}}) can be used= to
> +associate authorizations with an account that were not validated throu= gh
> the
> +ACME authorization process.  This allows ACME to address issuance= scenarios
> that
> +cannot yet be fully automated, such as the issuance of Extended Valida= tion
> +certificates.

You're essentially saying the same thing with this text, so I'm f= ine
with it.  The introduction describing cert types and then not having any statements about what is automated and what might need additional
non-automated process is an important link to make, so thanks.

These changes have been merged into the document.


 

Kathleen

>
> Updated PR: https://github.com/ietf-wg-acme/acm= e/pull/348
>
> --Richard
>
>
>
>>
>>
>> Thanks,
>> Kathleen
>>
>>
>> >
>> >
>> >>
>> >> >
>> >> >
>> >> >>
>> >> >> I do like how the introduction is framed as it=E2= =80=99s clear the level of
>> >> >> security provided by the certificates issued via A= CME.  Thanks for
>> >> >> that.
>> >> >>
>> >> >> The introduction should also make it clear that A= CME can be used for
>> >> >> other services using DV certificates, not just HT= TP.  This is
>> >> >> mentioned in the Terminology section, but I think= a clear sentence
>> >> >> upfront would be helpful.
>> >> >>
>> >> >> Section 2: Nit/suggestion: Change the tense to re= ad as a published
>> >> >> RFC
>> >> >> in the last paragraph, last sentence (take it or l= eave it).
>> >> >> Current:
>> >> >>    Such close integration of ACME with H= TTPS
>> >> >>    servers would allow the immediate an= d automated deployment of
>> >> >>    certificates as they are issued, spa= ring the human administrator
>> >> >> from
>> >> >>    much of the time-consuming work desc= ribed in the previous
>> >> >> section.
>> >> >> Proposed:
>> >> >>    Such close integration of ACME with H= TTPS
>> >> >>    servers allows the immediate and aut= omated deployment of
>> >> >>    certificates as they are issued, spa= ring the human administrator
>> >> >> from
>> >> >>    much of the time-consuming work desc= ribed in the previous
>> >> >> section.
>> >> >
>> >> >
>> >> > Done.
>> >> >
>> >> >
>> >> >>
>> >> >> IANA Section:
>> >> >> Everything looks good except that RFC5226 has bee= n obsoleted, so the
>> >> >> new reference is RFC8126 and =E2=80=9Cspecificati= on required=E2=80=9D
>> >> >> https://tools.ietf.org/html/= rfc8126#section-4.6 still means the same
>> >> >> thing, so using that is fine.
>> >> >
>> >> >
>> >> > Updated reference.
>> >> >
>> >> >
>> >> >>
>> >> >> Security considerations:
>> >> >> I think it would be good to mention here that the= y are DV certs so
>> >> >> the
>> >> >> reader understands from he introduction and this s= ection the level
>> >> >> of
>> >> >> cert issued through ACME and doesn=E2=80=99t assu= me a higher level of
>> >> >> assurance.
>> >> >>
>> >> >> s/ACME is a protocol for managing certificates/AC= ME is a protocol
>> >> >> for
>> >> >> managing DV certificates/
>> >> >
>> >> >
>> >> > Given the discussion about DV, I don't think this cha= nge is
>> >> > appropriate.
>> >> >
>> >> >
>> >> >>
>> >> >> 10.1 - I know this is obvious to the people in th= e WG, but a
>> >> >> reference
>> >> >> to RFC7525 to properly configure TLS 1.2 should b= e included to
>> >> >> protect
>> >> >> against the mentioned attacks.  If you want t= o also reference TLS
>> >> >> 1.3
>> >> >> and specify no 0-RTT that would be good too. = ; It=E2=80=99d be great to see
>> >> >> this get widely deployed, so there may be a numbe= r of newcomers
>> >> >> reading this to make their lives easier with cert=
>> >> >> issuance/maintenance.
>> >> >
>> >> >
>> >> > I don't see how TLS configuration plays into the secu= rity
>> >> > considerations
>> >> > for
>> >> > ACME.  How you use the certificates you get from= ACME is your
>> >> > business,
>> >> > and
>> >> > indeed, several of the envisioned applications have n= othing to do
>> >> > with
>> >> > TLS
>> >> > (e.g., the email and STIR use cases).
>> >> >
>> >> > That said, I have added some language to suggest that= ACME servers
>> >> > should
>> >> > follow the advice in RFC 7525.  0xRTT should be s= afe here, because
>> >> > there
>> >> > are
>> >> > anti-replay protections at the application layer.
= >> >>
>> >> Can you add a pointer in your text about the provided anti= -replay
>> >> protections in the application layer?
>> >
>> >
>> > Draft PR here:
>> >
>> > https://github.com/ietf-wg-acme/acme/pul= l/348
>> >
>> > --Richard
>> >
>> >
>> >>
>> >>
>> >> Thanks,
>> >> Kathleen
>> >>
>> >> >
>> >> >
>> >> >>
>> >> >> 10.2 - what if the server that the account verifi= er has an account
>> >> >> on
>> >> >> (client for ACME) is compromised and is used to r= equest new
>> >> >> certificates or perform other actions?  I th= ink this is one of the
>> >> >> larger risks, so mentioning this is possible and h= ardening measures
>> >> >> should be taken to prevent compromise would be pr= udent.  Hardening
>> >> >> measures or appropriate security controls should b= e broadly
>> >> >> understood
>> >> >> terms (I think) so that you wouldn=E2=80=99t need= to list out things like
>> >> >> turing off unnecessary services.
>> >> >
>> >> >
>> >> > Added a brief note.
>> >> >
>> >> >
>> >> >>
>> >> >> 10.5 - I would think you=E2=80=99d see requests f= or new phishing domains
>> >> >> rather than known ones through this process. = ; What would you look
>> >> >> for
>> >> >> there as that=E2=80=99s a complex problem - it wo= uld be hard to know all
>> >> >> legit
>> >> >> names to know if one was a play off of the origin= al.  This happened
>> >> >> with equifax - they provided a site name with a t= ypo and a =E2=80=98white
>> >> >> hat=E2=80=99
>> >> >> attacker had set up a site that looked just like t= heirs at that
>> >> >> site.
>> >> >> But it was announced by equifax.  Tough prob= lem as automating a
>> >> >> check
>> >> >> on the DNS registration may not detect something u= nusual, but maybe
>> >> >> recommending this check could help?  RDP les= sens what needs to be
>> >> >> shared from whois though, although I don=E2=80=99= t think that=E2=80=99s widely
>> >> >> deployed.
>> >> >
>> >> >
>> >> > This is a policy question, not one for the issuance p= rotocol.
>> >> >
>> >> > --Richard
>> >> >
>> >> >
>> >> >>
>> >> >>
>> >> >> --
>> >> >>
>> >> >> Best regards,
>> >> >> Kathleen
>> >> >>
>> >> >> ____________________________________________= ___
>> >> >> Acme mailing list
>> >> >> Acme@ietf.org
>> >> >> https://www.ietf.org/mailman/listinfo/acme
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> Best regards,
>> >> Kathleen
>> >
>> >
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>
>



--

Best regards,
Kathleen

= --Apple-Mail-32B74BAA-C463-4250-8D2E-D9DB23CB45E6-- From nobody Tue Nov 7 09:17: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 A1A3F120724 for ; Tue, 7 Nov 2017 09:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyBDSP_Q9970 for ; Tue, 7 Nov 2017 09:17:15 -0800 (PST) Received: from mr10.infostorm.no (mr10.infostorm.no [217.18.206.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A65A128D0D for ; Tue, 7 Nov 2017 09:17:14 -0800 (PST) Received: from Buyp-gvk-ex01.intra.buypass.no (unknown [146.192.247.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mr10.infostorm.no (Postfix) with ESMTP id 7D38F13775C; Tue, 7 Nov 2017 18:17:11 +0100 (CET) Received: from BUYP-GVK-EX01.intra.buypass.no (10.11.2.9) by Buyp-gvk-ex01.intra.buypass.no (10.11.2.9) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 7 Nov 2017 18:17:11 +0100 Received: from BUYP-GVK-EX01.intra.buypass.no ([10.11.2.241]) by Buyp-gvk-ex01.intra.buypass.no ([10.11.2.241]) with mapi id 15.00.0995.032; Tue, 7 Nov 2017 18:17:11 +0100 From: Mads Egil Henriksveen To: "cpu@letsencrypt.org" CC: IETF ACME Thread-Topic: [Acme] Survey of draft-07 implementations Thread-Index: AQHTSeMY8JEM4uMmCU+DxV9S1jVWXaLtzDXwgBNVhoCAADjbEA== Date: Tue, 7 Nov 2017 17:17:10 +0000 Message-ID: <8cdc021953fa48ea83e104cb412b5368@Buyp-gvk-ex01.intra.buypass.no> References: In-Reply-To: Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.11.51.31] Content-Type: multipart/alternative; boundary="_000_8cdc021953fa48ea83e104cb412b5368Buypgvkex01intrabuypass_" MIME-Version: 1.0 X-mr10-MailScanner-Information: Please contact the ISP for more information X-mr10-MailScanner-ID: 7D38F13775C.AAFE6 X-mr10-MailScanner: Found to be clean X-mr10-MailScanner-From: mads.henriksveen@buypass.no Archived-At: Subject: Re: [Acme] Survey of draft-07 implementations X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 17:17:20 -0000 --_000_8cdc021953fa48ea83e104cb412b5368Buypgvkex01intrabuypass_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGFuaWVsDQoNClRoZSB0ZXN0aW5nIHdpbGwgYmUgYmFzZWQgb24gb3VyIG93biB0ZXN0IGNs aWVudHMgYW5kIGNsaWVudCBzb2Z0d2FyZSBkZXZlbG9wZWQgYnkgb3VyIHBhcnRuZXJzLiBJZiB5 b3Uga25vdyBhYm91dCBhbnkgb3RoZXIgY2xpZW50cyBzdXBwb3J0aW5nIGRyYWZ0LTA3LCBwbGVh c2UgbGV0IG1lIGtub3cuDQoNCldlIGFyZSBjdXJyZW50bHkgd29ya2luZyB3aXRoIGEgc3BlY2lm aWNhdGlvbiBmb3IgdGhlIG5leHQgcGhhc2UgaW5jbHVkaW5nIE9PQiBhbmQgYWNjb3JkaW5nIHRv IG91ciBjdXJyZW50IHBsYW4gdGhpcyB3aWxsIGJlIGNvbXBsZXRlZCBpbiBRNCAyMDE3LiBXZSBo b3BlIHRvIGJlZ2luIHRoZSBpbXBsZW1lbnRhdGlvbiBpbiBRMSAyMDE4LCBidXQgcmlnaHQgbm93 IEkgYW0gbm90IGFibGUgdG8gc2F5IHdoZW4gdGhpcyB3aWxsIGJlIGZpbmlzaGVkLg0KDQpSZWdh cmRzDQpNYWRzDQoNCkZyb206IERhbmllbCBNY0Nhcm5leSBbbWFpbHRvOmNwdUBsZXRzZW5jcnlw dC5vcmddDQpTZW50OiB0b3JzZGFnIDIuIG5vdmVtYmVyIDIwMTcgMTU6MDINClRvOiBNYWRzIEVn aWwgSGVucmlrc3ZlZW4gPE1hZHMuSGVucmlrc3ZlZW5AYnV5cGFzcy5ubz4NCkNjOiBJRVRGIEFD TUUgPGFjbWVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0FjbWVdIFN1cnZleSBvZiBkcmFmdC0w NyBpbXBsZW1lbnRhdGlvbnMNCg0KSGkgTWFkcywNCg0KSGFwcHkgdG8gaGVhciBhYm91dCBhbm90 aGVyIGltcGxlbWVudGF0aW9uISBUaGFua3MgZm9yIHJlcGx5aW5nLg0KV2UgYXJlIGFsc28gcnVu bmluZyBhIGNvbnN0cmFpbmVkIHBpbG90IGluIG91ciBwcm9kdWN0aW9uIGVudmlyb25tZW50IChz dXBwb3J0aW5nIENlcnRCb3QpIGFuZCB0aGlzIHdpbGwgYmUgdXBncmFkZWQgdG8gdGhlIEFDTUUg ZHJhZnQtMDcgdmVyc2lvbiBzaG9ydGx5Lg0KDQpXaGF0IGlzIHlvdXIgcGxhbiBmb3IgdGVzdGlu ZyB5b3VyIGRyYWZ0LTA3IHBpbG90PyBJdCBzb3VuZHMgbGlrZSB5b3Ugb25seSB0YXJnZXQgQ2Vy dGJvdCBhbmQgdGhlcmUgaXMgbm8gb3JkZXIgYmFzZWQgaXNzdWFuY2Ugc3VwcG9ydCBpbiBDZXJ0 Ym90IHByZXNlbnRseSAoYW1vbmcgb3RoZXIgZGl2ZXJnZW5jZXMgd2l0aCBkcmFmdC0wNy8wOCku DQogSG93ZXZlciwgd2UgYXJlIGNvbnNpZGVyaW5nIHRvIHVzZSB0aGUgT3V0LW9mLUJhbmQgQ2hh bGxlbmdlIHR5cGUgYW5kIHBvc3NpYmx5IGFsc28gRXh0ZXJuYWwgQWNjb3VudCBCaW5kaW5nIGlu IGEgbmV4dCBwaGFzZSB3aGVyZSB0aGUgaWRlYSBpcyB0byBleHBsb2l0IGhvdyB0aGUgQUNNRSBw cm90b2NvbCBtYXkgYmUgdXNlZCB0byBzdXBwb3J0IGlzc3VhbmNlIGFuZCBhZG1pbmlzdHJhdGlv biBvZiBvdGhlciB0eXBlcyBvZiBUTFMgY2VydGlmaWNhdGVzIHRoYW4gRFYuDQoNCkNhbiB5b3Ug c3BlYWsgdG8gd2hlbiB0aGlzIHBoYXNlIG1heSBiZWdpbi9lbmQ/IEkgd29ycnkgdGhhdCBpdCB3 aWxsIGJlIHRvbyBsYXRlIGZvciBhbnkgaW1wbGVtZW50YXRpb24gZXhwZXJpZW5jZSB0byBiZSBh YmxlIHRvIGluZmx1ZW5jZSB0aGUgZHJhZnQgaWYgdGhpcyBwaGFzZSBvZiB5b3VyIHByb2plY3Qg d29uJ3QgYmUgY29tcGxldGUgZm9yIHNvbWUgdGltZS4NCg0KLSBEYW5pZWwgLyBjcHUNCg0KT24g U2F0LCBPY3QgMjEsIDIwMTcgYXQgMjo1NiBBTSwgTWFkcyBFZ2lsIEhlbnJpa3N2ZWVuIDxNYWRz LkhlbnJpa3N2ZWVuQGJ1eXBhc3Mubm88bWFpbHRvOk1hZHMuSGVucmlrc3ZlZW5AYnV5cGFzcy5u bz4+IHdyb3RlOg0KSGkNCg0KQnV5cGFzcyBoYXMgaW1wbGVtZW50ZWQgYW4gQUNNRSBzZXJ2ZXIg YmFzZWQgb24gQUNNRSBkcmFmdC0wNyB3aGljaCB1c2Ugb3JkZXIgYmFzZWQgaXNzdWFuY2UsIHRo aXMgdmVyc2lvbiBpcyBjdXJyZW50bHkgYXZhaWxhYmxlIGluIGEgdGVzdCBlbnZpcm9ubWVudCBv bmx5LiBXZSBhcmUgYWxzbyBydW5uaW5nIGEgY29uc3RyYWluZWQgcGlsb3QgaW4gb3VyIHByb2R1 Y3Rpb24gZW52aXJvbm1lbnQgKHN1cHBvcnRpbmcgQ2VydEJvdCkgYW5kIHRoaXMgd2lsbCBiZSB1 cGdyYWRlZCB0byB0aGUgQUNNRSBkcmFmdC0wNyB2ZXJzaW9uIHNob3J0bHkuDQoNCldlIGhhdmUg aW5jbHVkZWQgc3VwcG9ydCBmb3IgUHJlLUF1dGhvcml6YXRpb24sIGJ1dCB3ZSBhcmUgbm90IHVz aW5nIG5laXRoZXIgRXh0ZXJuYWwgQWNjb3VudCBCaW5kaW5nIG5vciB0aGUgT3V0LW9mLUJhbmQg Q2hhbGxlbmdlIGluIG91ciBjdXJyZW50IHZlcnNpb24uIEhvd2V2ZXIsIHdlIGFyZSBjb25zaWRl cmluZyB0byB1c2UgdGhlIE91dC1vZi1CYW5kIENoYWxsZW5nZSB0eXBlIGFuZCBwb3NzaWJseSBh bHNvIEV4dGVybmFsIEFjY291bnQgQmluZGluZyBpbiBhIG5leHQgcGhhc2Ugd2hlcmUgdGhlIGlk ZWEgaXMgdG8gZXhwbG9pdCBob3cgdGhlIEFDTUUgcHJvdG9jb2wgbWF5IGJlIHVzZWQgdG8gc3Vw cG9ydCBpc3N1YW5jZSBhbmQgYWRtaW5pc3RyYXRpb24gb2Ygb3RoZXIgdHlwZXMgb2YgVExTIGNl cnRpZmljYXRlcyB0aGFuIERWLg0KDQpSZWdhcmRzDQpNYWRzDQoNCkZyb206IEFjbWUgW21haWx0 bzphY21lLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmFjbWUtYm91bmNlc0BpZXRmLm9yZz5dIE9u IEJlaGFsZiBPZiBEYW5pZWwgTWNDYXJuZXkNClNlbnQ6IGZyZWRhZyAyMC4gb2t0b2JlciAyMDE3 IDIyOjM2DQpUbzogSUVURiBBQ01FIDxhY21lQGlldGYub3JnPG1haWx0bzphY21lQGlldGYub3Jn Pj4NClN1YmplY3Q6IFtBY21lXSBTdXJ2ZXkgb2YgZHJhZnQtMDcgaW1wbGVtZW50YXRpb25zDQoN CkhpIGZvbGtzLA0KDQpBcyB0aGUgV0cgYXBwcm9hY2hlcyBsYXN0LWNhbGwgb24gQUNNRSBkcmFm dC0wN1swXSBJIHdhbnRlZCB0byBnZXQgYSBzZW5zZSBvZiB3aGljaCBwb3J0aW9ucyBvZiB0aGUg c3BlYyBoYXZlIGJlZW4gaW1wbGVtZW50ZWQgYW5kIHdoaWNoIGhhdmVuJ3QuDQoNCkluIHBhcnRp Y3VsYXIgSSdkIGxpa2UgdG8gaGVhciBpZiBhbnlvbmUgaGFzIGltcGxlbWVudGVkOg0KKiBFeHRl cm5hbCBBY2NvdW50IEJpbmRpbmcgKFNlY3Rpb24gNy4zLjUpDQoqIFByZS1BdXRob3JpemF0aW9u IGZvciBPcmRlciBiYXNlZCBpc3N1YW5jZSAoU2VjdGlvbiA3LjQuMSkNCiogVGhlIE91dC1vZi1C YW5kIENoYWxsZW5nZSB0eXBlIChTZWN0aW9uIDguNikNCg0KTGV0J3MgRW5jcnlwdCBoYXMgbWFk ZSBnb29kIHByb2dyZXNzIG9uIGRyYWZ0LTA3IHNlcnZlciBpbXBsZW1lbnRhdGlvbiBidXQgaGFz IG5vIHBsYW5zIHRvIGltcGxlbWVudCB0aGUgYWJvdmUgdGhyZWUgZmVhdHVyZXMuIEl0IHdvdWxk IGJlIG5pY2UgdG8gaGVhciBzb21lb25lIGhhcyBydW5uaW5nIGNvZGUgZm9yIHRoZXNlIHByb3Rp b25zIG9mIHNwZWMuDQoNCklnbm9yaW5nIHRoZSBhYm92ZSB0aHJlZSBpdGVtcyBMZXQncyBFbmNy eXB0IGhhcyBpbXBsZW1lbnRlZCB0aGUgY29yZSBwb3J0aW9ucyBvZiBkcmFmdC0wNyBpbiBQZWJi bGVbMV0uIEl0J3MgcHJlc2VudGx5IHVzaW5nIHRoZSBwcm8tYWN0aXZlIGlzc3VhbmNlIG1ldGhv ZCBkZXNjcmliZWQgaW4gZHJhZnQtMDcuIEl0IGRvZXMgbm90IHN1cHBvcnQga2V5IGNoYW5nZSBv ciByZXZvY2F0aW9uIGJ1dCBpcyByZWFkeSB0byBiZSB1c2VkIGJ5IGNsaWVudHMuIFRoZXJlIGlz IGFuIGludGVncmF0aW9uIHRlc3QgY2xpZW50WzJdIGJhc2VkIG9uIENlcnRib3QncyBBQ01FIHB5 dGhvbiBtb2R1bGUgYW5kIEFDTUU0aiBoYXMgYW4gZXhwZXJpbWVudGFsIGJyYW5jaFszXSBjYXBh YmxlIG9mIGlzc3VpbmcgY2VydGlmaWNhdGVzIGZyb20gUGViYmxlLg0KDQpMZXQncyBFbmNyeXB0 IGhhcyBhbHNvIG1hZGUgc2lnbmlmaWNhbnQgcHJvZ3Jlc3MgaW1wbGVtZW50aW5nIGRyYWZ0LTA3 IGluIEJvdWxkZXJbNF0sIHRoZSBwcm9kdWN0aW9uIExldCdzIEVuY3J5cHQgQ0Egc29mdHdhcmUs IGJ1dCBpdCBpcyBub3QgeWV0IHJlYWR5IGZvciB1c2UgYnkgY2xpZW50cy4gVGhpcyBpbXBsZW1l bnRhdGlvbiBkb2VzIGluY2x1ZGUga2V5IGNoYW5nZSBhbmQgcmV2b2NhdGlvbiBidXQgZG9lcyAq Km5vdCoqIHVzZSBwcm8tYWN0aXZlIGlzc3VhbmNlLiBJIGJlZ2FuIGEgc2VwYXJhdGUgdGhyZWFk WzVdIGZvciB0aGUgb3JkZXIgZmluYWxpemF0aW9uIGFwcHJvYWNoIHRoYXQgd2UgaGF2ZSBzdGFy dGVkIHRvIGltcGxlbWVudCBmb3IgQm91bGRlci4gUGViYmxlIHdpbGwgYmUgdXBkYXRlZCB0byB1 c2UgdGhpcyBpc3N1YW5jZSBhcHByb2FjaCBpbiBwbGFjZSBvZiBwcm8tYWN0aXZlIGlzc3VhbmNl IHNob3J0bHkuDQoNCkFyZSB0aGVyZSBhbnkgb3RoZXIgc2VydmVycyBvciBjbGllbnRzIG91dCB0 aGVyZSB0aGF0IGFyZSBzcGVha2luZyBkcmFmdC0wNyBBQ01FIGFuZCB1c2luZyBvcmRlciBiYXNl ZCBpc3N1YW5jZT8NCg0KLSBEYW5pZWwgLyBjcHUNCg0KWzBdOiBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1hY21lLWFjbWUtMDcNClsxXTogaHR0cHM6Ly9naXRodWIuY29t L2xldHNlbmNyeXB0L3BlYmJsZQ0KWzJdOiBodHRwczovL2dpdGh1Yi5jb20vbGV0c2VuY3J5cHQv Ym91bGRlci9ibG9iL2UyY2M2ZmJlNjgyZGQ1ZDQ5ZGEzMmMyMzU3ODM4YjBjYzgzMWYxMGYvdGVz dC9jaGlzZWwyLnB5DQpbM106IGh0dHBzOi8vZ2l0aHViLmNvbS9zaHJlZC9hY21lNGovdHJlZS9k cmFmdA0KWzRdOiBodHRwczovL2dpdGh1Yi5jb20vbGV0c2VuY3J5cHQvYm91bGRlcg0KWzVdOiBo dHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2FjbWUvRElqSkVCMDZKNWNGeXVP bEdQVmNZMkk1MXZnDQoNCg== --_000_8cdc021953fa48ea83e104cb412b5368Buypgvkex01intrabuypass_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQg NzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJOTy1CT0siIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgRGFuaWVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoZSB0ZXN0aW5nIHdpbGwg YmUgYmFzZWQgb24gb3VyIG93biB0ZXN0IGNsaWVudHMgYW5kIGNsaWVudCBzb2Z0d2FyZSBkZXZl bG9wZWQgYnkgb3VyIHBhcnRuZXJzLiBJZiB5b3Uga25vdyBhYm91dCBhbnkNCiBvdGhlciBjbGll bnRzIHN1cHBvcnRpbmcgZHJhZnQtMDcsIHBsZWFzZSBsZXQgbWUga25vdy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+V2Ug YXJlIGN1cnJlbnRseSB3b3JraW5nIHdpdGggYSBzcGVjaWZpY2F0aW9uIGZvciB0aGUgbmV4dCBw aGFzZSBpbmNsdWRpbmcgT09CIGFuZCBhY2NvcmRpbmcgdG8gb3VyIGN1cnJlbnQgcGxhbiB0aGlz DQogd2lsbCBiZSBjb21wbGV0ZWQgaW4gUTQgMjAxNy4gV2UgaG9wZSB0byBiZWdpbiB0aGUgaW1w bGVtZW50YXRpb24gaW4gUTEgMjAxOCwgYnV0IHJpZ2h0IG5vdyBJIGFtIG5vdCBhYmxlIHRvIHNh eSB3aGVuIHRoaXMgd2lsbCBiZSBmaW5pc2hlZC4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5N YWRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+IERhbmllbCBNY0Nhcm5leSBbbWFpbHRvOmNwdUBsZXRzZW5j cnlwdC5vcmddDQo8YnI+DQo8Yj5TZW50OjwvYj4gdG9yc2RhZyAyLiBub3ZlbWJlciAyMDE3IDE1 OjAyPGJyPg0KPGI+VG86PC9iPiBNYWRzIEVnaWwgSGVucmlrc3ZlZW4gJmx0O01hZHMuSGVucmlr c3ZlZW5AYnV5cGFzcy5ubyZndDs8YnI+DQo8Yj5DYzo8L2I+IElFVEYgQUNNRSAmbHQ7YWNtZUBp ZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtBY21lXSBTdXJ2ZXkgb2YgZHJh ZnQtMDcgaW1wbGVtZW50YXRpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBNYWRzLDxicj4NCjxicj4NCkhhcHB5IHRvIGhlYXIgYWJv dXQgYW5vdGhlciBpbXBsZW1lbnRhdGlvbiEgVGhhbmtzIGZvciByZXBseWluZy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5XZSBhcmUgYWxz byBydW5uaW5nIGEgY29uc3RyYWluZWQgcGlsb3QgaW4gb3VyIHByb2R1Y3Rpb24gZW52aXJvbm1l bnQgKHN1cHBvcnRpbmcgQ2VydEJvdCkgYW5kIHRoaXMgd2lsbCBiZSB1cGdyYWRlZCB0byB0aGUg QUNNRSBkcmFmdC0wNyB2ZXJzaW9uIHNob3J0bHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCldoYXQgaXMgeW91ciBwbGFuIGZv ciB0ZXN0aW5nIHlvdXIgZHJhZnQtMDcgcGlsb3Q/IEl0IHNvdW5kcyBsaWtlIHlvdSBvbmx5IHRh cmdldCBDZXJ0Ym90IGFuZCB0aGVyZSBpcyBubyBvcmRlciBiYXNlZCBpc3N1YW5jZSBzdXBwb3J0 IGluIENlcnRib3QgcHJlc2VudGx5IChhbW9uZyBvdGhlciBkaXZlcmdlbmNlcyB3aXRoIGRyYWZ0 LTA3LzA4KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBj bTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDtIb3dldmVyLCB3ZSBhcmUgY29uc2lkZXJpbmcgdG8gdXNlIHRoZSBPdXQt b2YtQmFuZCBDaGFsbGVuZ2UgdHlwZSBhbmQgcG9zc2libHkgYWxzbyBFeHRlcm5hbCBBY2NvdW50 IEJpbmRpbmcgaW4gYSBuZXh0IHBoYXNlIHdoZXJlIHRoZSBpZGVhIGlzIHRvIGV4cGxvaXQgaG93 IHRoZSBBQ01FIHByb3RvY29sIG1heSBiZSB1c2VkIHRvIHN1cHBvcnQgaXNzdWFuY2UgYW5kIGFk bWluaXN0cmF0aW9uDQogb2Ygb3RoZXIgdHlwZXMgb2YgVExTIGNlcnRpZmljYXRlcyB0aGFuIERW LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KQ2FuIHlvdSBzcGVhayB0byB3aGVu IHRoaXMgcGhhc2UgbWF5IGJlZ2luL2VuZD8gSSB3b3JyeSB0aGF0IGl0IHdpbGwgYmUgdG9vIGxh dGUgZm9yIGFueSBpbXBsZW1lbnRhdGlvbiBleHBlcmllbmNlIHRvIGJlIGFibGUgdG8gaW5mbHVl bmNlIHRoZSBkcmFmdCBpZiB0aGlzIHBoYXNlIG9mIHlvdXIgcHJvamVjdCB3b24ndCBiZSBjb21w bGV0ZSBmb3Igc29tZSB0aW1lLjxicj4NCjxicj4NCi0gRGFuaWVsIC8gY3B1Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFNh dCwgT2N0IDIxLCAyMDE3IGF0IDI6NTYgQU0sIE1hZHMgRWdpbCBIZW5yaWtzdmVlbiAmbHQ7PC9z cGFuPjxhIGhyZWY9Im1haWx0bzpNYWRzLkhlbnJpa3N2ZWVuQGJ1eXBhc3Mubm8iIHRhcmdldD0i X2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+TWFkcy5IZW5yaWtzdmVlbkBidXlwYXNzLm5vPC9z cGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CdXlwYXNzIGhhcyBpbXBsZW1l bnRlZCBhbiBBQ01FIHNlcnZlciBiYXNlZCBvbiBBQ01FIGRyYWZ0LTA3IHdoaWNoIHVzZSBvcmRl ciBiYXNlZCBpc3N1YW5jZSwNCiB0aGlzIHZlcnNpb24gaXMgY3VycmVudGx5IGF2YWlsYWJsZSBp biBhIHRlc3QgZW52aXJvbm1lbnQgb25seS4gV2UgYXJlIGFsc28gcnVubmluZyBhIGNvbnN0cmFp bmVkIHBpbG90IGluIG91ciBwcm9kdWN0aW9uIGVudmlyb25tZW50IChzdXBwb3J0aW5nIENlcnRC b3QpIGFuZCB0aGlzIHdpbGwgYmUgdXBncmFkZWQgdG8gdGhlIEFDTUUgZHJhZnQtMDcgdmVyc2lv biBzaG9ydGx5Lg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2UgaGF2ZSBpbmNsdWRlZCBzdXBwb3J0IGZvciBQcmUt QXV0aG9yaXphdGlvbiwgYnV0IHdlIGFyZSBub3QgdXNpbmcgbmVpdGhlciBFeHRlcm5hbA0KIEFj Y291bnQgQmluZGluZyBub3IgdGhlIE91dC1vZi1CYW5kIENoYWxsZW5nZSBpbiBvdXIgY3VycmVu dCB2ZXJzaW9uLiBIb3dldmVyLCB3ZSBhcmUgY29uc2lkZXJpbmcgdG8gdXNlIHRoZSBPdXQtb2Yt QmFuZCBDaGFsbGVuZ2UgdHlwZSBhbmQgcG9zc2libHkgYWxzbyBFeHRlcm5hbCBBY2NvdW50IEJp bmRpbmcgaW4gYSBuZXh0IHBoYXNlIHdoZXJlIHRoZSBpZGVhIGlzIHRvIGV4cGxvaXQgaG93IHRo ZSBBQ01FIHByb3RvY29sIG1heSBiZSB1c2VkDQogdG8gc3VwcG9ydCBpc3N1YW5jZSBhbmQgYWRt aW5pc3RyYXRpb24gb2Ygb3RoZXIgdHlwZXMgb2YgVExTIGNlcnRpZmljYXRlcyB0aGFuIERWLg0K PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+UmVnYXJkczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk1hZHM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiBBY21lDQogW21haWx0bzo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmFj bWUtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPmFjbWUtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5EYW5pZWwgTWNDYXJuZXk8YnI+ DQo8Yj5TZW50OjwvYj4gZnJlZGFnIDIwLiBva3RvYmVyIDIwMTcgMjI6MzY8YnI+DQo8Yj5Ubzo8 L2I+IElFVEYgQUNNRSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzphY21lQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+YWNtZUBpZXRmLm9y Zzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBbQWNtZV0gU3VydmV5IG9mIGRyYWZ0LTA3IGltcGxlbWVudGF0aW9uczwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiPkhpIGZvbGtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiPkFzIHRoZSBXRyBhcHByb2FjaGVzIGxhc3QtY2FsbCBvbiBB Q01FIGRyYWZ0LTA3WzBdIEkgd2FudGVkIHRvIGdldCBhIHNlbnNlIG9mIHdoaWNoIHBvcnRpb25z IG9mIHRoZSBzcGVjIGhhdmUgYmVlbiBpbXBsZW1lbnRlZCBhbmQgd2hpY2ggaGF2ZW4ndC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiBwYXJ0 aWN1bGFyIEknZCBsaWtlIHRvIGhlYXIgaWYgYW55b25lIGhhcyBpbXBsZW1lbnRlZDo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj4qIEV4dGVybmFsIEFjY291bnQgQmluZGluZyAoU2VjdGlvbiA3LjMu NSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4qIFByZS1BdXRob3JpemF0aW9uIGZvciBPcmRlciBi YXNlZCBpc3N1YW5jZSAoU2VjdGlvbiA3LjQuMSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4qIFRo ZSBPdXQtb2YtQmFuZCBDaGFsbGVuZ2UgdHlwZSAoU2VjdGlvbiA4LjYpPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+TGV0J3MgRW5jcnlwdCBoYXMg bWFkZSBnb29kIHByb2dyZXNzIG9uIGRyYWZ0LTA3IHNlcnZlciBpbXBsZW1lbnRhdGlvbiBidXQg aGFzIG5vIHBsYW5zIHRvIGltcGxlbWVudCB0aGUgYWJvdmUgdGhyZWUgZmVhdHVyZXMuIEl0IHdv dWxkIGJlIG5pY2UgdG8gaGVhciBzb21lb25lDQogaGFzIHJ1bm5pbmcgY29kZSBmb3IgdGhlc2Ug cHJvdGlvbnMgb2Ygc3BlYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj5JZ25vcmluZyB0aGUgYWJvdmUgdGhyZWUgaXRlbXMgTGV0J3MgRW5jcnlw dCBoYXMgaW1wbGVtZW50ZWQgdGhlIGNvcmUgcG9ydGlvbnMgb2YgZHJhZnQtMDcgaW4gUGViYmxl WzFdLiBJdCdzIHByZXNlbnRseSB1c2luZyB0aGUgcHJvLWFjdGl2ZSBpc3N1YW5jZSBtZXRob2Qg ZGVzY3JpYmVkDQogaW4gZHJhZnQtMDcuIEl0IGRvZXMgbm90IHN1cHBvcnQga2V5IGNoYW5nZSBv ciByZXZvY2F0aW9uIGJ1dCBpcyByZWFkeSB0byBiZSB1c2VkIGJ5IGNsaWVudHMuIFRoZXJlIGlz IGFuIGludGVncmF0aW9uIHRlc3QgY2xpZW50WzJdIGJhc2VkIG9uIENlcnRib3QncyBBQ01FIHB5 dGhvbiBtb2R1bGUgYW5kIEFDTUU0aiBoYXMgYW4gZXhwZXJpbWVudGFsIGJyYW5jaFszXSBjYXBh YmxlIG9mIGlzc3VpbmcgY2VydGlmaWNhdGVzIGZyb20gUGViYmxlLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkxldCdzIEVuY3J5cHQgaGFzIGFs c28gbWFkZSBzaWduaWZpY2FudCBwcm9ncmVzcyBpbXBsZW1lbnRpbmcgZHJhZnQtMDcgaW4gQm91 bGRlcls0XSwgdGhlIHByb2R1Y3Rpb24gTGV0J3MgRW5jcnlwdCBDQSBzb2Z0d2FyZSwgYnV0IGl0 IGlzIG5vdCB5ZXQgcmVhZHkgZm9yIHVzZQ0KIGJ5IGNsaWVudHMuIFRoaXMgaW1wbGVtZW50YXRp b24gZG9lcyBpbmNsdWRlIGtleSBjaGFuZ2UgYW5kIHJldm9jYXRpb24gYnV0IGRvZXMgKipub3Qq KiB1c2UgcHJvLWFjdGl2ZSBpc3N1YW5jZS4gSSBiZWdhbiBhIHNlcGFyYXRlIHRocmVhZFs1XSBm b3IgdGhlIG9yZGVyIGZpbmFsaXphdGlvbiBhcHByb2FjaCB0aGF0IHdlIGhhdmUgc3RhcnRlZCB0 byBpbXBsZW1lbnQgZm9yIEJvdWxkZXIuIFBlYmJsZSB3aWxsIGJlIHVwZGF0ZWQgdG8gdXNlIHRo aXMNCiBpc3N1YW5jZSBhcHByb2FjaCBpbiBwbGFjZSBvZiBwcm8tYWN0aXZlIGlzc3VhbmNlIHNo b3J0bHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+QXJlIHRoZXJlIGFueSBvdGhlciBzZXJ2ZXJzIG9yIGNsaWVudHMgb3V0IHRoZXJlIHRoYXQg YXJlIHNwZWFraW5nIGRyYWZ0LTA3IEFDTUUgYW5kIHVzaW5nIG9yZGVyIGJhc2VkIGlzc3VhbmNl PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPi0g RGFuaWVsIC8gY3B1PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+WzBdOg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWFjbWUtYWNtZS0wNyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVO LVVTIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hY21lLWFjbWUtMDc8 L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5bMV06 DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2xldHNlbmNyeXB0L3BlYmJsZSIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIj5odHRwczovL2dpdGh1Yi5jb20vbGV0 c2VuY3J5cHQvcGViYmxlPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+WzJdOg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9sZXRz ZW5jcnlwdC9ib3VsZGVyL2Jsb2IvZTJjYzZmYmU2ODJkZDVkNDlkYTMyYzIzNTc4MzhiMGNjODMx ZjEwZi90ZXN0L2NoaXNlbDIucHkiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+ aHR0cHM6Ly9naXRodWIuY29tL2xldHNlbmNyeXB0L2JvdWxkZXIvYmxvYi9lMmNjNmZiZTY4MmRk NWQ0OWRhMzJjMjM1NzgzOGIwY2M4MzFmMTBmL3Rlc3QvY2hpc2VsMi5weTwvc3Bhbj48L2E+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlszXToNCjwvc3Bhbj48YSBo cmVmPSJodHRwczovL2dpdGh1Yi5jb20vc2hyZWQvYWNtZTRqL3RyZWUvZHJhZnQiIHRhcmdldD0i X2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+aHR0cHM6Ly9naXRodWIuY29tL3NocmVkL2FjbWU0 ai90cmVlL2RyYWZ0PC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+WzRdOg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9sZXRzZW5j cnlwdC9ib3VsZGVyIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0dHBzOi8v Z2l0aHViLmNvbS9sZXRzZW5jcnlwdC9ib3VsZGVyPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+WzVdOg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8v bWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvYWNtZS9ESWpKRUIwNko1Y0Z5dU9sR1BWY1ky STUxdmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+aHR0cHM6Ly9tYWlsYXJj aGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9hY21lL0RJakpFQjA2SjVjRnl1T2xHUFZjWTJJNTF2Zzwv c3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8cdc021953fa48ea83e104cb412b5368Buypgvkex01intrabuypass_-- From nobody Wed Nov 8 05:49: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 5B2A4126CD8 for ; Wed, 8 Nov 2017 05:48: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 f_hNXB7mDKUP for ; Wed, 8 Nov 2017 05:48:56 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C32821201F2 for ; Wed, 8 Nov 2017 05:48:56 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id m81so5978461ioi.13 for ; Wed, 08 Nov 2017 05:48: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=2XrFQHtIvM5fEhdzsj94kAJ89rovOFFd2eQ76iHGAXA=; b=K1NfVfJXyJ0P3OYBpVSA34fXBM2xhGsJenDPeOAjaqb3I8wjepf/Qs260yii9cQKOu qwO4wxXM4Fw4mFQwRSQbwHZmAvFlGckSnv12zHS2GHdcunbai8uahLraSIavJPiGvehC mLWQloo58KpjRqXZxfnmKoSTcdA5Qq429mXRo= 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=2XrFQHtIvM5fEhdzsj94kAJ89rovOFFd2eQ76iHGAXA=; b=BZdroN5A/EmypCP0MNOITrwVLy3ljnTNb1QUqDuRvRmGoQEfnzktoo5TrgM8b2aVJw VIqjpvWkcCPCe6r4RxJqZYMknEZ9SCPby2akyOhyLvGVBGycmygVilmaRRIXfoVjnl8W FX/Y+AhkePUlNZA36HSQ1/pKTggocsGuVLJ3V/8XCUJIpMzRURFORA62PdJKLI1PjO9m 2Ob8rHNmj750cND9z61uF+X2dI0kIhNUQ91DX0/vmARtyqMr228NPq5gsECf5GIEzOxb bTWd5Lrtb2bXmQSrIwrM+O1n249ykVnaEV3sXvv6UIW2UsZu7W+HLyZ+D1ajhDXLgA5T SLcw== X-Gm-Message-State: AJaThX55x1JDZ1OOxNz8o+xJOidHNUKD3BE+It7jlUTHuIdpTU+Gk6MU 8/OLBy/HkDlXiWasB5fqmYs+Fx2DyT+0MISD+giEcvV8C4M= X-Google-Smtp-Source: AGs4zMZNkNwLRTW1zk51T/m1sjHR5ViesUjgP+xFRt3+EicpbaZJgWKzbHRaxVmdBpR/NdTcYwr+lKyECyjbGwi4sFQ= X-Received: by 10.107.33.18 with SMTP id h18mr648820ioh.167.1510148935968; Wed, 08 Nov 2017 05:48:55 -0800 (PST) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.88.21 with HTTP; Wed, 8 Nov 2017 05:48:55 -0800 (PST) In-Reply-To: <8cdc021953fa48ea83e104cb412b5368@Buyp-gvk-ex01.intra.buypass.no> References: <8cdc021953fa48ea83e104cb412b5368@Buyp-gvk-ex01.intra.buypass.no> From: Daniel McCarney Date: Wed, 8 Nov 2017 08:48:55 -0500 Message-ID: To: Mads Egil Henriksveen Cc: IETF ACME Content-Type: multipart/alternative; boundary="001a1141bbf6e2fa83055d78f2a0" Archived-At: Subject: Re: [Acme] Survey of draft-07 implementations X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 13:48:59 -0000 --001a1141bbf6e2fa83055d78f2a0 Content-Type: text/plain; charset="UTF-8" Hi Mads, The testing will be based on our own test clients and client software > developed by our partners. If you know about any other clients supporting > draft-07, please let me know. I'm only aware of ACME4j's draft branch that I linked to in my original post. Note: of course it's presently based on proactive issuance which is likely to be removed shortly. Are any of Buypass' (or your partner's) test clients available open source? We are currently working with a specification for the next phase including > OOB and according to our current plan this will be completed in Q4 2017 Can you expand on your use-case for the OOB challenge and perhaps address areas where external account binding isn't sufficient? Thanks! - Daniel / cpu On Tue, Nov 7, 2017 at 12:17 PM, Mads Egil Henriksveen < Mads.Henriksveen@buypass.no> wrote: > Hi Daniel > > > > The testing will be based on our own test clients and client software > developed by our partners. If you know about any other clients supporting > draft-07, please let me know. > > > > We are currently working with a specification for the next phase including > OOB and according to our current plan this will be completed in Q4 2017. We > hope to begin the implementation in Q1 2018, but right now I am not able to > say when this will be finished. > > > > Regards > > Mads > > > > *From:* Daniel McCarney [mailto:cpu@letsencrypt.org] > *Sent:* torsdag 2. november 2017 15:02 > *To:* Mads Egil Henriksveen > *Cc:* IETF ACME > *Subject:* Re: [Acme] Survey of draft-07 implementations > > > > Hi Mads, > > Happy to hear about another implementation! Thanks for replying. > > We are also running a constrained pilot in our production environment > (supporting CertBot) and this will be upgraded to the ACME draft-07 version > shortly. > > > What is your plan for testing your draft-07 pilot? It sounds like you only > target Certbot and there is no order based issuance support in Certbot > presently (among other divergences with draft-07/08). > > However, we are considering to use the Out-of-Band Challenge type and > possibly also External Account Binding in a next phase where the idea is to > exploit how the ACME protocol may be used to support issuance and > administration of other types of TLS certificates than DV. > > > Can you speak to when this phase may begin/end? I worry that it will be > too late for any implementation experience to be able to influence the > draft if this phase of your project won't be complete for some time. > > - Daniel / cpu > > > > On Sat, Oct 21, 2017 at 2:56 AM, Mads Egil Henriksveen < > Mads.Henriksveen@buypass.no> wrote: > > Hi > > > > Buypass has implemented an ACME server based on ACME draft-07 which use > order based issuance, this version is currently available in a test > environment only. We are also running a constrained pilot in our production > environment (supporting CertBot) and this will be upgraded to the ACME > draft-07 version shortly. > > > > We have included support for Pre-Authorization, but we are not using > neither External Account Binding nor the Out-of-Band Challenge in our > current version. However, we are considering to use the Out-of-Band > Challenge type and possibly also External Account Binding in a next phase > where the idea is to exploit how the ACME protocol may be used to support > issuance and administration of other types of TLS certificates than DV. > > > > Regards > > Mads > > > > *From:* Acme [mailto:acme-bounces@ietf.org] *On Behalf Of *Daniel McCarney > *Sent:* fredag 20. oktober 2017 22:36 > *To:* IETF ACME > *Subject:* [Acme] Survey of draft-07 implementations > > > > Hi folks, > > > > As the WG approaches last-call on ACME draft-07[0] I wanted to get a sense > of which portions of the spec have been implemented and which haven't. > > > > In particular I'd like to hear if anyone has implemented: > > * External Account Binding (Section 7.3.5) > > * Pre-Authorization for Order based issuance (Section 7.4.1) > > * The Out-of-Band Challenge type (Section 8.6) > > > > Let's Encrypt has made good progress on draft-07 server implementation but > has no plans to implement the above three features. It would be nice to > hear someone has running code for these protions of spec. > > > > Ignoring the above three items Let's Encrypt has implemented the core > portions of draft-07 in Pebble[1]. It's presently using the pro-active > issuance method described in draft-07. It does not support key change or > revocation but is ready to be used by clients. There is an integration test > client[2] based on Certbot's ACME python module and ACME4j has an > experimental branch[3] capable of issuing certificates from Pebble. > > > > Let's Encrypt has also made significant progress implementing draft-07 in > Boulder[4], the production Let's Encrypt CA software, but it is not yet > ready for use by clients. This implementation does include key change and > revocation but does **not** use pro-active issuance. I began a separate > thread[5] for the order finalization approach that we have started to > implement for Boulder. Pebble will be updated to use this issuance approach > in place of pro-active issuance shortly. > > > > Are there any other servers or clients out there that are speaking > draft-07 ACME and using order based issuance? > > > > - Daniel / cpu > > > > [0]: https://tools.ietf.org/html/draft-ietf-acme-acme-07 > > [1]: https://github.com/letsencrypt/pebble > > [2]: https://github.com/letsencrypt/boulder/blob/ > e2cc6fbe682dd5d49da32c2357838b0cc831f10f/test/chisel2.py > > [3]: https://github.com/shred/acme4j/tree/draft > > [4]: https://github.com/letsencrypt/boulder > > [5]: https://mailarchive.ietf.org/arch/msg/acme/ > DIjJEB06J5cFyuOlGPVcY2I51vg > > > --001a1141bbf6e2fa83055d78f2a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mads,


The testing will be b= ased on our own test clients and client software developed by our partners.= If you know about any other clients supporting draft-07, please let me kno= w.

I'm only aware of ACME4j's draft branch tha= t I linked to in my original post. Note: of course it's presently based= on proactive issuance which is likely to be removed shortly.
Are any of= Buypass' (or your partner's) test clients available open source?


We are c= urrently working with a specification for the next phase including OOB and = according to our current plan this will be completed in Q4 2017

Can you expand on your use-case for the OOB challenge and perhaps= address areas where external account binding isn't sufficient?

= Thanks!
=C2=A0
- Daniel / cpu

On Tue, Nov 7, 2017 at 12:17 PM,= Mads Egil Henriksveen <Mads.Henriksveen@buypass.no> wrote:

Hi Daniel

=C2=A0

The testing will be ba= sed on our own test clients and client software developed by our partners. = If you know about any other clients supporting draft-07, please let me know.

=C2=A0

We are currently worki= ng with a specification for the next phase including OOB and according to o= ur current plan this will be completed in Q4 2017. We hope to begin the implementation in Q1 20= 18, but right now I am not able to say when this will be finished.=C2=A0

=C2=A0

Regards<= /span>

Mads

=C2=A0

From: = Daniel McCarney [mailto:cpu@letsencrypt.org]
Sent: torsdag 2. november 2017 15:02
To: Mads Egil Henriksveen <Mads.Henriksveen@buypass.no>
Cc: IETF ACME <acme@ietf.org>
Subject: Re: [Acme] Survey of draft-07 implementations=

=C2=A0

= Hi Mads,

Happy to hear about another implementation! Thanks for replying.<= /u>

We are also running a constrain= ed pilot in our production environment (supporting CertBot) and this will b= e upgraded to the ACME draft-07 version shortly.

=
What is your plan for testing your draft-07 pilot? It sounds like you only = target Certbot and there is no order based issuance support in Certbot pres= ently (among other divergences with draft-07/08).

=C2=A0However, we are consideri= ng to use the Out-of-Band Challenge type and possibly also External Account= Binding in a next phase where the idea is to exploit how the ACME protocol= may be used to support issuance and administration of other types of TLS certificates than DV.


Can you speak to when this phase may begin/end? I worry that it will be too= late for any implementation experience to be able to influence the draft i= f this phase of your project won't be complete for some time.

- Daniel / cpu=C2=A0

=C2=A0

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

Hi

=C2=A0

Buypass has implemente= d an ACME server based on ACME draft-07 which use order based issuance, this version is currently available in a test environment only. We are als= o running a constrained pilot in our production environment (supporting Cer= tBot) and this will be upgraded to the ACME draft-07 version shortly.

=C2=A0

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

=C2=A0

Regards

Mads

=C2=A0

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

=C2=A0

Hi folks,<= /p>

=C2=A0

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

=C2=A0

In particular I'd like to h= ear if anyone has implemented:

* External Account Binding (Sec= tion 7.3.5)

* Pre-Authorization for Order b= ased issuance (Section 7.4.1)

* The Out-of-Band Challenge typ= e (Section 8.6)

=C2=A0

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

=C2=A0

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

=C2=A0

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

=C2=A0

Are there any other servers or = clients out there that are speaking draft-07 ACME and using order based iss= uance?

=C2=A0

- Daniel / cpu

=C2=A0

[1]: = https://github.com/letsencrypt/pebble<= span lang=3D"EN-US">

=C2=A0


--001a1141bbf6e2fa83055d78f2a0-- From nobody Wed Nov 8 06:05:24 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D61127010 for ; Wed, 8 Nov 2017 06:05: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 q9x47_56pouM for ; Wed, 8 Nov 2017 06:05:18 -0800 (PST) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3973126C3D for ; Wed, 8 Nov 2017 06:05:17 -0800 (PST) Received: by mail-it0-x22d.google.com with SMTP id u132so3355689ita.0 for ; Wed, 08 Nov 2017 06:05:17 -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=jckIeVo39ZlHxjx88TRkNjVggyZsO4ljyu+wkXWqYx0=; b=cJlQ0nKVXHhknEV9Ug1E8QZ1JFg/P+epbsVbtVH36bEtLTAk6iZPEeWtPUUp8bhJD0 t/ca/ERtMphRzYEjgB6ciqPLwLXY/CjguDTsJbNvSOMaUZY+lnJtqQvPv77Po84JBQ2Q ehKiB5zGKchnGzSnY3dS4YJL5oOnhK1Tq+3ww= 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=jckIeVo39ZlHxjx88TRkNjVggyZsO4ljyu+wkXWqYx0=; b=t4rY0Fxj0ILQFWO5TDGDl7O0gbl8R3SHwbsZcXlpG5N2YK5Qmi2bfYo972cmjvfoY0 BzjZsCrgvmrNzUz3GmsKVChXKYOJhlzL7Cs9hnjC2xi61m566/RDLo2FO19YUqY/GnwY c+mmzN9rMV4hoiH+AStsvgqPbkYGwuMjdpZHCI//eoYu9oNsMVEtJ8WzYivZkKkupH7K caH09U0uvebX5TSwDkWOKScG/hjHg8A2ComhOwQtWBzhoI3OHiFbVhDpgtDX18NIQTOk 9/j3lFacXLIsZucnEAUjDmVMBC/pcZjr8UN6/0j/S0Gj6w4ETamAJOD529A2RQNG93TU FulQ== X-Gm-Message-State: AJaThX6Q2b5yHF3lJ+vo6mIJCZG/Jdt+MA5ppvMTu1xx/lp9mpnpHJT8 2SuaUy8svvGoQigRsWSEnaQEpt6rumcNRZ11SH1LpQ== X-Google-Smtp-Source: ABhQp+R9s9czJmBKQEyAJjLAHFonARtQvFS6iQ2532LP4AegslDV4qFVUg86QOCz42V0+0QG5Wy8d7WeH5rhfVRsV18= X-Received: by 10.36.215.67 with SMTP id y64mr753617itg.145.1510149917251; Wed, 08 Nov 2017 06:05:17 -0800 (PST) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.88.21 with HTTP; Wed, 8 Nov 2017 06:05:16 -0800 (PST) In-Reply-To: <20171102161833.pqxnd6ql22k4qiul@LK-Perkele-VII> References: <71f3e975-7cee-18cf-2635-80eb13adff12@devever.net> <20171024141732.ufjysx5f73pyc5f4@LK-Perkele-VII> <63029bbd-a9d5-0f30-718a-8d78f76a8e82@eff.org> <20171102161833.pqxnd6ql22k4qiul@LK-Perkele-VII> From: Daniel McCarney Date: Wed, 8 Nov 2017 09:05:16 -0500 Message-ID: To: Ilari Liusvaara Cc: Richard Barnes , Brad Warren , Hugo Landau , IETF ACME Content-Type: multipart/alternative; boundary="94eb2c0b05a4602779055d792d92" Archived-At: Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 14:05:20 -0000 --94eb2c0b05a4602779055d792d92 Content-Type: text/plain; charset="UTF-8" Hi Ilari, I guess if you find any use for the key at all depends on if authorizations > are order-scoped or account-scoped. See this follow-up thread[0] - it seems like "scope" on orders is unnecessary & confusing. I vote it be removed and Richard Barnes seems to be supportive of that. There is at least one method in "10 methods" that absolutely requires the > key to be known (number 9). Also, if the variant of the validation method > uses the key, it does not seem safe to reuse it for different key. Can you cite the specific challenge method you mean (or the section of the baseline requirements) - I don't know which specific validation method you're referring to. More broadly: ACME defines a number of validation challenge methods. It does not define a validation method based on using the public key from a CSR. Using unspecified challenge types as an argument for why the CSR should be submitted early doesn't seem very convincing to me. What is the rationale for needing such a challenge type? What problems does this challenge type resolve that are not resolved by the current challenge types? Do you or any other ACME servers have interest in specifying & implementing such a challenge type? I'm extremely hesitant to make design decisions based on allowing for very open-ended features in the future when there isn't a strong case for the feature or any established interest in implementing & shipping it. If orders can live over 8 hours, then one MUST be prepared to take rejection > at finalization anyway. Because even if CAA was checked at authorization > creation, it might have been changed and consequently fail the recheck. Yes, this is something I mentioned in my reply[1] to one of your earlier messages as well as in my reply to Brad Warren[2]. - Daniel / cpu [0] - https://mailarchive.ietf.org/arch/msg/acme/wkQH2AqypoGnByiuCfYgq2UI3nI [1] - https://mailarchive.ietf.org/arch/msg/acme/ KEB3sLRswTT3m_XIbZSW52r3lxM/?qid=abcabbc372443fbe31c952558aa3392f [2] - https://mailarchive.ietf.org/arch/msg/acme/-uamQ4SPkxHR_eschpBSqkG1-yE On Thu, Nov 2, 2017 at 12:18 PM, Ilari Liusvaara wrote: > On Thu, Nov 02, 2017 at 10:29:58AM -0400, Daniel McCarney wrote: > > > > > I understand that these corner cases aren't a super convincing line of > > argument, but I also don't think a slight preference for double CSR > > strictly because it allows delivering a public key rejection error > slightly > > earlier in the order flow is a very convincing argument either. Does > > someone have something stronger in mind? > > I guess if you find any use for the key at all depends on if > authorizations are order-scoped or account-scoped. > > If authorizations are order-scoped, then the keys could be used for > additional validation methods... There is at least one method in "10 > methods" that absolutely requires the key to be known (number 9). > Also, if the variant of the validation method uses the key, it does > not seem safe to reuse it for different key. > > If orders can live over 8 hours, then one MUST be prepared to take > rejection at finalization anyway. Because even if CAA was checked at > authorization creation, it might have been changed and consequently > fail the recheck. > > > -Ilari > --94eb2c0b05a4602779055d792d92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ilari,

I guess if you find any use for= the key at all depends on if=C2=A0= authorizations are order-scoped or account-scoped.
=
See this follow-up thread[0] - it seems like "scope" on order= s is unnecessary & confusing. I vote it be removed and Richard Barnes s= eems to be supportive of that.

There is at least one method = in "10=C2=A0methods" that= absolutely requires the key to be known (number 9).=C2=A0Also, if the variant of the validation method uses t= he key, it does=C2=A0not seem safe = to reuse it for different key.

Can you cite the spec= ific challenge method you mean (or the section of the baseline requirements= ) - I don't know which specific validation method you're referring = to.

More broadly: ACME defines a number of validation challenge meth= ods. It does not define a validation method based on using the public key f= rom a CSR. Using unspecified challenge types as an argument for why the CSR= should be submitted early doesn't seem very convincing to me.=C2=A0

What is the rationale for needing such a challenge t= ype?
What problems does this challenge type resolve that are not resolv= ed by the current challenge types?
Do you or any other ACME servers hav= e interest in specifying & implementing such a challenge type?

I= 'm extremely hesitant to make design decisions based on allowing for ve= ry open-ended features in the future when there isn't a strong case for= the feature or any established interest in implementing & shipping it.= =C2=A0

If orders can live over 8 = hours, then one MUST be prepared to take=C2=A0rejection at finalization anyway. Because even if CAA was checke= d at=C2=A0=C2=A0authorization creat= ion, it might have been changed and consequently=C2=A0fail the recheck.

Yes, this is something I mentioned in m= y reply[1] to one of your earlier messages as well as in my reply to Brad W= arren[2].


On Thu, N= ov 2, 2017 at 12:18 PM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On = Thu, Nov 02, 2017 at 10:29:58AM -0400, Daniel McCarney wrote:

>
> I understand that these corner cases aren't a super convincing lin= e of
> argument, but I also don't think a slight preference for double CS= R
> strictly because it allows delivering a public key rejection error sli= ghtly
> earlier in the order flow is a very convincing argument either. Does > someone have something stronger in mind?

I guess if you find any use for the key at all depends on if
authorizations are order-scoped or account-scoped.

If authorizations are order-scoped, then the keys could be used for
additional validation methods... There is at least one method in "10 methods" that absolutely requires the key to be known (number 9).
Also, if the variant of the validation method uses the key, it does
not seem safe to reuse it for different key.

If orders can live over 8 hours, then one MUST be prepared to take
rejection at finalization anyway. Because even if CAA was checked at
authorization creation, it might have been changed and consequently
fail the recheck.


-Ilari

--94eb2c0b05a4602779055d792d92-- From nobody Thu Nov 9 14:18:41 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B59126D73 for ; Thu, 9 Nov 2017 14:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ibMH1qJAHOA2 for ; Thu, 9 Nov 2017 14:18:38 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C854B1252BA for ; Thu, 9 Nov 2017 14:18:37 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id s66so20048200wmf.5 for ; Thu, 09 Nov 2017 14:18:37 -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=aj8hsmJQTDN0hsUeuJh3+1HrT087KjH+ll36uVIb23I=; b=LrzGb6rJiaGQJZNtutq/Pk6bQRKnl75GnoBYy+Er4Tg6cMdA/XR2orXL/J9HSDRxlY YOdl6q8mHkVFZBq1ohlArkpmPOByBsieDli9V6KDJtLzdO8HTdHVmXqq8cArbVJWD5hR XAkcy4Opj35hsyoI4UOcC239GM+1nUIGGinmDzFFIEJTNXexR0iNhROcgNgHGJer5LC5 8bHE5+ZRB1CYZxxVNAr0wbvgviigh2ksKOZaowfqcADIwsAGAk+Pcnh3c+JgyuSK5+4G OpgYe/uMhGq76m+VoF5hJz2pxGAZstRz8kEFUVwneQXXFq9BKAPmLn1SAh+WhTog+Zzu usNQ== 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=aj8hsmJQTDN0hsUeuJh3+1HrT087KjH+ll36uVIb23I=; b=gIbf+d8UtXdssvZjC3WW0hnTXsitt+DKbhUrY3ZRMEWkcoDUaUYmb7JNNWTb+6ZsAf K+peUF/xK5UquyEVBlY/Ja6LR6F+3C1GJuzypzTkVTBUk79OOT94CWVxD7Mcb5KLJFnj PWflDSQQXcl1ED+7zXGt+ksIkTvzlwHy+C2vVDRdXCOVFEpQ+PfkMI5Whf8gPEQCGWSN YWRx+sX7i9fmPo/L5ZJR/ICmk5FdwA05JnwEGtoT1TrHoc3yti7ywf/bgrCdJowUxXnU q/IKSnPBaZO13T9Cun6vvitw/zoeqpXR0e/Lgpf75NEeGxzq5nkVNcOHLYP4h8d3ZDWP JWfw== X-Gm-Message-State: AJaThX7aRsQ71+V5PUECbR31jPBD4rVVLKp6ZsEyiH0v641z6lhM+P2G xl/F8+zChSSFCAIHX+zER/fj12CHZAyI5YYmVUHdzRfwsbc= X-Google-Smtp-Source: ABhQp+RGMo4Rd9+B/lMsZ8rMnJZnJSUODWw8Cx0rXs47v1yXG1KnxXvPkU/Mq9d27IsQIvhh/8SOPjfo74+hyOKDBVk= X-Received: by 10.28.69.91 with SMTP id s88mr976218wma.19.1510265916158; Thu, 09 Nov 2017 14:18:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Thu, 9 Nov 2017 14:18:35 -0800 (PST) In-Reply-To: References: <71f3e975-7cee-18cf-2635-80eb13adff12@devever.net> <20171024141732.ufjysx5f73pyc5f4@LK-Perkele-VII> <63029bbd-a9d5-0f30-718a-8d78f76a8e82@eff.org> <20171102161833.pqxnd6ql22k4qiul@LK-Perkele-VII> From: Richard Barnes Date: Thu, 9 Nov 2017 17:18:35 -0500 Message-ID: To: Daniel McCarney Cc: Ilari Liusvaara , Brad Warren , Hugo Landau , IETF ACME Content-Type: multipart/alternative; boundary="94eb2c0723a67308c3055d942fc3" Archived-At: Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 22:18:41 -0000 --94eb2c0723a67308c3055d942fc3 Content-Type: text/plain; charset="UTF-8" Since people don't seem happy about either of these alternatives (identifiers+CSR because of legacy issues; CSR+CSR because of fragility), here's one last attempt at a different approach: 1. Add an error code for new-order, say "authorizationFirst", which means "I only accept orders with all authz fulfilled; go and do these authz and then submit new-order" 2. When you send an "authorizationFirst" error, you MUST send authorizations for the client to complete 3. Add a note that the server MAY delay issuance until it receives the first GET request to the certificate URL This is basically equivalent to the CSR+CSR proposal from the server POV, but now there's no formal relationship between the two CSRs (they're independent orders), so you don't have to worry about what happens if they're different. It also removes the authentication on the "finalize" step (replacing it with a GET), but I don't think we had heard a reason for the authentication anyway. From a client perspective, it admits a pretty simple flow: a. Submit new-order b. If response is 2XX or authzNeeded, go do the authz c. If you got authzNeeded, re-submit new-order; else poll order until cert URL shows up d. Poll cert URL Draft PR: https://github.com/ietf-wg-acme/acme/pull/350 In any case, it would be helpful if people could provide thoughts on which of the three options they prefer here: 1. Identifiers + CSR (https://github.com/ietf-wg-acme/acme/pull/342) 2. CSR + CSR (same, but with a CSR instead of identifiers) 3. authorizationFirst (https://github.com/ietf-wg-acme/acme/pull/350) Personally, my current preference is for (3), because it seems like the least complex / error prone way to support both back-end cases (CSR first / CSR last). Thanks, --Richard On Wed, Nov 8, 2017 at 9:05 AM, Daniel McCarney wrote: > Hi Ilari, > > I guess if you find any use for the key at all depends on if authorizations >> are order-scoped or account-scoped. > > > See this follow-up thread[0] - it seems like "scope" on orders is > unnecessary & confusing. I vote it be removed and Richard Barnes seems to > be supportive of that. > > There is at least one method in "10 methods" that absolutely requires the >> key to be known (number 9). Also, if the variant of the validation >> method uses the key, it does not seem safe to reuse it for different key. > > > Can you cite the specific challenge method you mean (or the section of the > baseline requirements) - I don't know which specific validation method > you're referring to. > > More broadly: ACME defines a number of validation challenge methods. It > does not define a validation method based on using the public key from a > CSR. Using unspecified challenge types as an argument for why the CSR > should be submitted early doesn't seem very convincing to me. > > What is the rationale for needing such a challenge type? > What problems does this challenge type resolve that are not resolved by > the current challenge types? > Do you or any other ACME servers have interest in specifying & > implementing such a challenge type? > > I'm extremely hesitant to make design decisions based on allowing for very > open-ended features in the future when there isn't a strong case for the > feature or any established interest in implementing & shipping it. > > If orders can live over 8 hours, then one MUST be prepared to take rejection >> at finalization anyway. Because even if CAA was checked at authorization >> creation, it might have been changed and consequently fail the recheck. > > > Yes, this is something I mentioned in my reply[1] to one of your earlier > messages as well as in my reply to Brad Warren[2]. > > - Daniel / cpu > > > [0] - https://mailarchive.ietf.org/arch/msg/acme/wkQH2AqypoGnByi > uCfYgq2UI3nI > [1] - https://mailarchive.ietf.org/arch/msg/acme/KEB3sLRswTT3m_X > IbZSW52r3lxM/?qid=abcabbc372443fbe31c952558aa3392f > [2] - https://mailarchive.ietf.org/arch/msg/acme/-uamQ4SPkxHR_ > eschpBSqkG1-yE > > On Thu, Nov 2, 2017 at 12:18 PM, Ilari Liusvaara > wrote: > >> On Thu, Nov 02, 2017 at 10:29:58AM -0400, Daniel McCarney wrote: >> >> > >> > I understand that these corner cases aren't a super convincing line of >> > argument, but I also don't think a slight preference for double CSR >> > strictly because it allows delivering a public key rejection error >> slightly >> > earlier in the order flow is a very convincing argument either. Does >> > someone have something stronger in mind? >> >> I guess if you find any use for the key at all depends on if >> authorizations are order-scoped or account-scoped. >> >> If authorizations are order-scoped, then the keys could be used for >> additional validation methods... There is at least one method in "10 >> methods" that absolutely requires the key to be known (number 9). >> Also, if the variant of the validation method uses the key, it does >> not seem safe to reuse it for different key. >> >> If orders can live over 8 hours, then one MUST be prepared to take >> rejection at finalization anyway. Because even if CAA was checked at >> authorization creation, it might have been changed and consequently >> fail the recheck. >> >> >> -Ilari >> > > --94eb2c0723a67308c3055d942fc3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Since people don't seem happy about either of the= se alternatives (identifiers+CSR because of legacy issues; CSR+CSR because = of fragility), here's one last attempt at a different approach:

1. Add an error code for new-order, say=20 "authorizationFirst", which means "I only accept orders with= all authz=20 fulfilled; go and do these authz=20 and then submit new-order"
2. When you send an "authori= zationFirst" error, you MUST send authorizations for the client to com= plete
3. Add a note that the server MAY delay issuance until it re= ceives the first GET request to the certificate URL

This is basically equivalent to the CSR+CSR proposal from the server POV,= but now there's no formal relationship between the two CSRs (they'= re independent orders), so you don't have to worry about what happens i= f they're different.=C2=A0 It also removes the authentication on the &q= uot;finalize" step (replacing it with a GET), but I don't think we= had heard a reason for the authentication anyway.=C2=A0 From a client pers= pective, it admits a pretty simple flow:



In any case, it would be helpf= ul if people could provide thoughts on which of the three options they pref= er here:

2. CSR + CSR (same, but with a CSR instead of iden= tifiers)

Personally, my current pre= ference is for (3), because it seems like the least complex / error prone w= ay to support both back-end cases (CSR first / CSR last).
Thanks,
--Richard



On Wed, Nov 8= , 2017 at 9:05 AM, Daniel McCarney <cpu@letsencrypt.org> w= rote:
Hi Ilari,

<= span style=3D"font-size:12.8px">I guess if you find any use for the key at = all depends on if=C2=A0authorizatio= ns are order-scoped or account-scoped.

S= ee this follow-up thread[0] - it seems like "scope" on orders is = unnecessary & confusing. I vote it be removed and Richard Barnes seems = to be supportive of that.

There is at least one method= in "10=C2=A0methods" tha= t absolutely requires the key to be known (number 9).=C2=A0Also, if the variant of the validation method uses = the key, it does=C2=A0not seem safe= to reuse it for different key.

Can you cite = the specific challenge method you mean (or the section of the baseline requ= irements) - I don't know which specific validation method you're re= ferring to.

More broadly: ACME defines a number of validation challe= nge methods. It does not define a validation method based on using the publ= ic key from a CSR. Using unspecified challenge types as an argument for why= the CSR should be submitted early doesn't seem very convincing to me.= =C2=A0

What is the rationale for needing such a ch= allenge type?
What problems does this challenge type resolve that are n= ot resolved by the current challenge types?
Do you or any other ACME se= rvers have interest in specifying & implementing such a challenge type?=

I'm extremely hesitant to make design decisions based on allowi= ng for very open-ended features in the future when there isn't a strong= case for the feature or any established interest in implementing & shi= pping it.=C2=A0

If orders= can live over 8 hours, then one MUST be prepared to take=C2=A0rejection at finalization anyway. Because even = if CAA was checked at=C2=A0=C2=A0au= thorization creation, it might have been changed and consequently=C2=A0fail the recheck.

<= /span>Yes, this is something I mentioned in my reply[1] to one of your earl= ier messages as well as in my reply to Brad Warren[2].

=

On Th= u, Nov 2, 2017 at 12:18 PM, Ilari Liusvaara <ilariliusvaara@welho= .com> wrote:
On Thu, Nov 02, 2017 at 10:29:58AM -0400, Daniel McCarney wrote:=

>
> I understand that these corner cases aren't a super convincing lin= e of
> argument, but I also don't think a slight preference for double CS= R
> strictly because it allows delivering a public key rejection error sli= ghtly
> earlier in the order flow is a very convincing argument either. Does > someone have something stronger in mind?

I guess if you find any use for the key at all depends on if
authorizations are order-scoped or account-scoped.

If authorizations are order-scoped, then the keys could be used for
additional validation methods... There is at least one method in "10 methods" that absolutely requires the key to be known (number 9).
Also, if the variant of the validation method uses the key, it does
not seem safe to reuse it for different key.

If orders can live over 8 hours, then one MUST be prepared to take
rejection at finalization anyway. Because even if CAA was checked at
authorization creation, it might have been changed and consequently
fail the recheck.


-Ilari


--94eb2c0723a67308c3055d942fc3-- From nobody Fri Nov 10 06:03: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 1BE111242F7 for ; Fri, 10 Nov 2017 06:03:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 XQMFCJ1qn1jf for ; Fri, 10 Nov 2017 06:03:05 -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 F200E120721 for ; Fri, 10 Nov 2017 06:03:04 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id d66so13682664ioe.5 for ; Fri, 10 Nov 2017 06:03:04 -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=prQfMMwBsKiLXume77hDCYUBhc9Fx6hta22H9ku3XAE=; b=V+gea2fb2V9vuhnyfQYcemtfoJ3T7tN60mxa2/AL2mRmL7LiDnskxIGQN6Ivtku013 lxbvqEZCd2+MAwX4TtwoO5m+jLbVhyzCr4gfbSz+N45kpBEOEpucrIk5XYtEMmwMEk+b rdz6vjI+eL0TMCPSx/xw+Lbtw1y/hmOFOED+U= 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=prQfMMwBsKiLXume77hDCYUBhc9Fx6hta22H9ku3XAE=; b=JYVrisMNWg0QMYwp4HtIwXl8TS0/Oua2DcpzNwoW4/MvIfSa77lQFBtUo39XSIQFQ5 EEwJDlUWbrqgB4/WxOoKi8PvVIfxqQDMcGBjW1Sye5KYOkI8dQNFm83GwDB9/VLWhjoG MufF7TmGy6N7H4PiZH4QKtIPW4JE3anfIJKvyihByxCg7yZ3Ke5GcSyGR1sPosI5IISr q+4zg+KhzbLoBNivNkBPB636SinGpkbkAVF7yu9MWDcM4/MqCBCxUe1AcDRveoAIg7jk 167zELVqkX5iYYCxn5MwuuYIGTaYA0i11OLMEabldxv6Hdwsvka66r3a2nwW3HdT8Row ybQg== X-Gm-Message-State: AJaThX6ZWhh8MrPS+EzWu0WDv7JcQWWg0cVor+PgYy07ByM6hZzghvnm 1DN+l8mj7GcS4IIZ0hCrCivJnM8eCK1NgLINAc0qtQ== X-Google-Smtp-Source: AGs4zMYOESZh+IFfvotpxSHjCPpZTCQ4+rYN1QvRmWlIAYKcCX/r/mVjfMBparEjxl7VZhZyDYzD21WLIlUtXbIikQ8= X-Received: by 10.107.43.75 with SMTP id r72mr519733ior.31.1510322584036; Fri, 10 Nov 2017 06:03:04 -0800 (PST) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.32.144 with HTTP; Fri, 10 Nov 2017 06:03:03 -0800 (PST) In-Reply-To: References: <71f3e975-7cee-18cf-2635-80eb13adff12@devever.net> <20171024141732.ufjysx5f73pyc5f4@LK-Perkele-VII> <63029bbd-a9d5-0f30-718a-8d78f76a8e82@eff.org> <20171102161833.pqxnd6ql22k4qiul@LK-Perkele-VII> From: Daniel McCarney Date: Fri, 10 Nov 2017 09:03:03 -0500 Message-ID: To: Richard Barnes Cc: Ilari Liusvaara , Brad Warren , Hugo Landau , IETF ACME Content-Type: multipart/alternative; boundary="001a113949f01e404b055da161d0" Archived-At: Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 14:03:08 -0000 --001a113949f01e404b055da161d0 Content-Type: text/plain; charset="UTF-8" > > Since people don't seem happy about either of these alternatives > (identifiers+CSR because of legacy issues; CSR+CSR because of fragility), > here's one last attempt at a different approach: I think this is a mis-characterization. What are the legacy issues that can't be handled with identifiers+CSR? The opposition to this approach on-list has focused on challenge types that could exist that would require the CSR public key & the benefits of delivering errors to clients regarding the CSR earlier. Neither of which seem to be a question of legacy issues. It also removes the authentication on the "finalize" step (replacing it > with a GET), but I don't think we had heard a reason for the authentication > anyway. This returns to issuing a certificate on a GET request - I think there was some opposition to this approach. >From a client perspective, it admits a pretty simple flow: This flow seems more complicated than my original proposal. How is it simpler than: a. submit new-order with identifiers b. fulfill the authorizations c. finalize the order with CSR This is also *much* closer to the current "V1" issuance process where clients request authzs, fulfill them, and then submit to new-cert with a CSR. Given that 100% of existing ACME clients implement a finalization based approach (using new-cert), would it not be easier for them to adapt current code if we matched this behaviour for the new-order flow? - Daniel / cpu On Thu, Nov 9, 2017 at 5:18 PM, Richard Barnes wrote: > Since people don't seem happy about either of these alternatives > (identifiers+CSR because of legacy issues; CSR+CSR because of fragility), > here's one last attempt at a different approach: > > 1. Add an error code for new-order, say "authorizationFirst", which means > "I only accept orders with all authz fulfilled; go and do these authz and > then submit new-order" > 2. When you send an "authorizationFirst" error, you MUST send > authorizations for the client to complete > 3. Add a note that the server MAY delay issuance until it receives the > first GET request to the certificate URL > > This is basically equivalent to the CSR+CSR proposal from the server POV, > but now there's no formal relationship between the two CSRs (they're > independent orders), so you don't have to worry about what happens if > they're different. It also removes the authentication on the "finalize" > step (replacing it with a GET), but I don't think we had heard a reason for > the authentication anyway. From a client perspective, it admits a pretty > simple flow: > > a. Submit new-order > b. If response is 2XX or authzNeeded, go do the authz > c. If you got authzNeeded, re-submit new-order; else poll order until > cert URL shows up > d. Poll cert URL > > Draft PR: https://github.com/ietf-wg-acme/acme/pull/350 > > In any case, it would be helpful if people could provide thoughts on which > of the three options they prefer here: > > 1. Identifiers + CSR (https://github.com/ietf-wg-acme/acme/pull/342) > 2. CSR + CSR (same, but with a CSR instead of identifiers) > 3. authorizationFirst (https://github.com/ietf-wg-acme/acme/pull/350) > > Personally, my current preference is for (3), because it seems like the > least complex / error prone way to support both back-end cases (CSR first / > CSR last). > > Thanks, > --Richard > > > > On Wed, Nov 8, 2017 at 9:05 AM, Daniel McCarney > wrote: > >> Hi Ilari, >> >> I guess if you find any use for the key at all depends on if authorizations >>> are order-scoped or account-scoped. >> >> >> See this follow-up thread[0] - it seems like "scope" on orders is >> unnecessary & confusing. I vote it be removed and Richard Barnes seems to >> be supportive of that. >> >> There is at least one method in "10 methods" that absolutely requires >>> the key to be known (number 9). Also, if the variant of the validation >>> method uses the key, it does not seem safe to reuse it for different >>> key. >> >> >> Can you cite the specific challenge method you mean (or the section of >> the baseline requirements) - I don't know which specific validation method >> you're referring to. >> >> More broadly: ACME defines a number of validation challenge methods. It >> does not define a validation method based on using the public key from a >> CSR. Using unspecified challenge types as an argument for why the CSR >> should be submitted early doesn't seem very convincing to me. >> >> What is the rationale for needing such a challenge type? >> What problems does this challenge type resolve that are not resolved by >> the current challenge types? >> Do you or any other ACME servers have interest in specifying & >> implementing such a challenge type? >> >> I'm extremely hesitant to make design decisions based on allowing for >> very open-ended features in the future when there isn't a strong case for >> the feature or any established interest in implementing & shipping it. >> >> If orders can live over 8 hours, then one MUST be prepared to take rejection >>> at finalization anyway. Because even if CAA was checked at authorization >>> creation, it might have been changed and consequently fail the recheck. >> >> >> Yes, this is something I mentioned in my reply[1] to one of your earlier >> messages as well as in my reply to Brad Warren[2]. >> >> - Daniel / cpu >> >> >> [0] - https://mailarchive.ietf.org/arch/msg/acme/wkQH2AqypoGnByi >> uCfYgq2UI3nI >> [1] - https://mailarchive.ietf.org/arch/msg/acme/KEB3sLRswTT3m_X >> IbZSW52r3lxM/?qid=abcabbc372443fbe31c952558aa3392f >> [2] - https://mailarchive.ietf.org/arch/msg/acme/-uamQ4SPkxHR_es >> chpBSqkG1-yE >> >> On Thu, Nov 2, 2017 at 12:18 PM, Ilari Liusvaara < >> ilariliusvaara@welho.com> wrote: >> >>> On Thu, Nov 02, 2017 at 10:29:58AM -0400, Daniel McCarney wrote: >>> >>> > >>> > I understand that these corner cases aren't a super convincing line of >>> > argument, but I also don't think a slight preference for double CSR >>> > strictly because it allows delivering a public key rejection error >>> slightly >>> > earlier in the order flow is a very convincing argument either. Does >>> > someone have something stronger in mind? >>> >>> I guess if you find any use for the key at all depends on if >>> authorizations are order-scoped or account-scoped. >>> >>> If authorizations are order-scoped, then the keys could be used for >>> additional validation methods... There is at least one method in "10 >>> methods" that absolutely requires the key to be known (number 9). >>> Also, if the variant of the validation method uses the key, it does >>> not seem safe to reuse it for different key. >>> >>> If orders can live over 8 hours, then one MUST be prepared to take >>> rejection at finalization anyway. Because even if CAA was checked at >>> authorization creation, it might have been changed and consequently >>> fail the recheck. >>> >>> >>> -Ilari >>> >> >> > --001a113949f01e404b055da161d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Since pe= ople don't seem happy about either of these alternatives (identifiers+C= SR because of legacy issues; CSR+CSR because of fragility), here's one = last attempt at a different approach:

I think this is = a mis-characterization. What are the legacy issues that can't be handle= d with identifiers+CSR?=C2=A0

The opposition to th= is approach on-list has focused on challenge types that could exist that wo= uld require the CSR public key & the benefits of delivering errors to c= lients regarding the CSR earlier. Neither of which seem to be a question of= legacy issues.

It also removes the authentication on the &q= uot;finalize" step (replacing it with a GET), but I don't think we= had heard a reason for the authentication anyway.
=
This returns to issuing a certificate on a GET request - I think there = was some opposition to this approach.

From a client perspect= ive, it admits a pretty simple flow:

This flow = seems more complicated than my original proposal. How is it simpler than:
a. submit new-order with identifiers
b. fulfill the authori= zations
c. finalize the order with CSR

This is also *much*= closer to the current "V1" issuance process where clients reques= t authzs, fulfill them, and then submit to new-cert with a CSR. Given that = 100% of existing ACME clients implement a finalization based approach (usin= g new-cert), would it not be easier for them to adapt current code if we ma= tched this behaviour for the new-order flow?

- Daniel / cpu=C2=A0

On Thu, Nov 9, 2017 at 5:18 PM, Richard Barnes <rlb@ipv.sx> wro= te:
Since people do= n't seem happy about either of these alternatives (identifiers+CSR beca= use of legacy issues; CSR+CSR because of fragility), here's one last at= tempt at a different approach:

1. Add an erro= r code for new-order, say=20 "authorizationFirst", which means "I only accept orders with= all authz=20 fulfilled; go and do these authz=20 and then submit new-order"
2. When you send an "authori= zationFirst" error, you MUST send authorizations for the client to com= plete
3. Add a note that the server MAY delay issuance until it re= ceives the first GET request to the certificate URL

This is basically equivalent to the CSR+CSR proposal from the server POV,= but now there's no formal relationship between the two CSRs (they'= re independent orders), so you don't have to worry about what happens i= f they're different.=C2=A0 It also removes the authentication on the &q= uot;finalize" step (replacing it with a GET), but I don't think we= had heard a reason for the authentication anyway.=C2=A0 From a client pers= pective, it admits a pretty simple flow:

= =C2=A0 a. Submit new-order
=C2=A0 b. If response is 2XX or a= uthzNeeded, go do the authz
=C2=A0 c. If you got authzNeeded, re-= submit new-order; else poll order until cert URL shows up
=C2= =A0 d. Poll cert URL


In any = case, it would be helpful if people could provide thoughts on which of the = three options they prefer here:

2. C= SR + CSR (same, but with a CSR instead of identifiers)

Personally, my curr= ent preference is for (3), because it seems like the least complex / error = prone way to support both back-end cases (CSR first / CSR last).
<= div>
Thanks,
--Richard



On Wed, Nov 8, 2017 at 9:05 AM, Daniel McCarney <cpu@l= etsencrypt.org> wrote:
Hi Ilari,

I guess if y= ou find any use for the key at all depends on if=C2=A0authorizations are order-scoped or account-scoped.

See this follow-up thread[0] - it seems like = "scope" on orders is unnecessary & confusing. I vote it be re= moved and Richard Barnes seems to be supportive of that.

There is at least one method in "10=C2=A0methods" that absolutely requires the key to be known (n= umber 9).=C2=A0Also, if the variant= of the validation method uses the key, it does=C2=A0not seem safe to reuse it for different key.
Can you cite the specific challenge method you mean (or t= he section of the baseline requirements) - I don't know which specific = validation method you're referring to.

More broadly: ACME define= s a number of validation challenge methods. It does not define a validation= method based on using the public key from a CSR. Using unspecified challen= ge types as an argument for why the CSR should be submitted early doesn'= ;t seem very convincing to me.=C2=A0

What is the r= ationale for needing such a challenge type?
What problems does this cha= llenge type resolve that are not resolved by the current challenge types? <= br>Do you or any other ACME servers have interest in specifying & imple= menting such a challenge type?

I'm extremely hesitant to make de= sign decisions based on allowing for very open-ended features in the future= when there isn't a strong case for the feature or any established inte= rest in implementing & shipping it.=C2=A0

If orders can live over 8 hours, then one MUST be prepar= ed to take=C2=A0rejection at finali= zation anyway. Because even if CAA was checked at=C2=A0=C2=A0authorization creation, it might have been change= d and consequently=C2=A0fail the re= check.

Yes, this is something I mentioned in my reply[1] to one of your earlier= messages as well as in my reply to Brad Warren[2].

- Daniel / cpu
=C2=A0

[0] -=C2=A0https://mailarchive.ietf.org/arch/msg/acme/wkQH2AqypoGnByiuCfY= gq2UI3nI=C2=A0
[1] -=C2=A0https://mailarchive.ietf.org/arch/msg/acme/KEB= 3sLRswTT3m_XIbZSW52r3lxM/?qid=3Dabcabbc372443fbe31c952558aa3392f<= /a>
[2] -=C2=A0https://mailarchive.ietf.org/arch/msg/acme/-uamQ4SPkxHR_eschpBSqkG1-yE

On Thu, Nov 2, 2017 at 12:18 PM, Ilari = Liusvaara <ilariliusvaara@welho.com> wrote:
On Thu, Nov 02, 2017 at 1= 0:29:58AM -0400, Daniel McCarney wrote:

>
> I understand that these corner cases aren't a super convincing lin= e of
> argument, but I also don't think a slight preference for double CS= R
> strictly because it allows delivering a public key rejection error sli= ghtly
> earlier in the order flow is a very convincing argument either. Does > someone have something stronger in mind?

I guess if you find any use for the key at all depends on if
authorizations are order-scoped or account-scoped.

If authorizations are order-scoped, then the keys could be used for
additional validation methods... There is at least one method in "10 methods" that absolutely requires the key to be known (number 9).
Also, if the variant of the validation method uses the key, it does
not seem safe to reuse it for different key.

If orders can live over 8 hours, then one MUST be prepared to take
rejection at finalization anyway. Because even if CAA was checked at
authorization creation, it might have been changed and consequently
fail the recheck.


-Ilari



--001a113949f01e404b055da161d0-- From nobody Fri Nov 10 07:13:18 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91DB81200F3 for ; Fri, 10 Nov 2017 07:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ev9Ax3pTS1k5 for ; Fri, 10 Nov 2017 07:13:14 -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 9120B120046 for ; Fri, 10 Nov 2017 07:13:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 205595DE90; Fri, 10 Nov 2017 17:13:12 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id qmRubxqRVWLn; Fri, 10 Nov 2017 17:13:11 +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-smtp1.welho.com (Postfix) with ESMTPSA id 9F872C4; Fri, 10 Nov 2017 17:13:06 +0200 (EET) Date: Fri, 10 Nov 2017 17:13:06 +0200 From: Ilari Liusvaara To: Daniel McCarney Cc: Richard Barnes , Brad Warren , Hugo Landau , IETF ACME Message-ID: <20171110151306.3zemo2mr4dx5lwnw@LK-Perkele-VII> References: <63029bbd-a9d5-0f30-718a-8d78f76a8e82@eff.org> <20171102161833.pqxnd6ql22k4qiul@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 15:13:16 -0000 On Fri, Nov 10, 2017 at 09:03:03AM -0500, Daniel McCarney wrote: > > > > Since people don't seem happy about either of these alternatives > > (identifiers+CSR because of legacy issues; CSR+CSR because of fragility), > > here's one last attempt at a different approach: > > > I think this is a mis-characterization. What are the legacy issues that > can't be handled with identifiers+CSR? > > The opposition to this approach on-list has focused on challenge types that > could exist that would require the CSR public key & the benefits of > delivering errors to clients regarding the CSR earlier. Neither of which > seem to be a question of legacy issues. Also, do not confuse challege types and validation methods. Neither contains the other. Actually looking at the "10 methods" and seeing if they are key- dependent or key-independent (only key-independent works if just domain list is given up front): Key-Independent: - Method 1 (Authenticate DC via registry) - Method 2 (Message DC) - Method 3 (Call DC) - Method 4 (E-Mail domain) - Method 5 (Domain Authorization Document) - Method 10 (Certificate Random Value) Key-Dependent: - Method 9 (Test certificate) Can be either: - Method 6 (HTTP) - Method 7 (DNS) - Method 8 (IP address) So every one of the present methods can be key-independent (situation is similar with proposed IP address validation methods), except 9. Method 9 can be replaced with method 10, and since the client (or TLS server) constructs the certificate, it can understand the scope of the authorization if the validation method is so designed (I have a feeling this is supposed to be required, but apparently not, given that TLS-SNI fails this... But then, method 10 allows blatantly insecure stuff). I have seen some proposed methods (I think four), and those are pretty much all key-independent or can be either. So there does not seem much reason to provode keys up front in order to support different validation methods. On checking earlier, the client needs to be prepared to get a fault on order finalization anyway. Especially if order can take over 8 hours to fill (Due to CAA recheck), which it can easily do if one hits pending OOB challenges. -Ilari From nobody Fri Nov 10 07:42: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 852FB126CC4 for ; Fri, 10 Nov 2017 07:42: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 lxIWI35k-cAR for ; Fri, 10 Nov 2017 07:42:07 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42D90126C3D for ; Fri, 10 Nov 2017 07:42:07 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id x63so1782762ioe.6 for ; Fri, 10 Nov 2017 07:42: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=8Mic6U5pNQlB6Zj3U6QWPWYPSE+VZNc+46DeRhoSfSM=; b=aqSDj4MOdlMr+aWar1wZzyQIg50LlsGAN9PJuZXjY4WEPvttIjw1SubRq1SbjZqkIl fevkklGJOW6OLkfBXXyUp8WxJLguhLirSGm8q2mluUUByAA+i1WE3JMlYmfDkYr56Kop ImgFPSbzK0PUvALK9bp3spOlHU5tdgtAc8rtM= 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=8Mic6U5pNQlB6Zj3U6QWPWYPSE+VZNc+46DeRhoSfSM=; b=nN7/1uxor9hQBNCczogm5w1GjGZ84ZLJQOS5qsy7BjKlpoe5wy/ATdvQITCPBZcYSB bpMiH34aEfQBsVYPhEjfHOM1XDWW41A0BeOMPLvZ6Cf+VrvbaS5J1h3SXaNhA9R6L+aW EZx3pQ6icwrOwdAwjiG7db8IqxDkLCpu3cYsCW+00ZyoTEWG/6NXCrsdqAFX9xIlkT8N 6MH4aRL5RndidhGPJ0q/S6n0kbRBKs1mNH8J0VqV4i11Nwc/8G/5fkgvVxL9IRAcoYwt O++sFpwPM10AKrE8OFBUkRUbF1hTtN05LrHKoy7AJjYUBZh9pVgMpMGCqdRU+ex7IICe I+TQ== X-Gm-Message-State: AJaThX72ltszLU9hchD8s4LjryZD8YFJza0Lmm0TFh7irmWGX+/22+Nn pQ5PHZvfCQ0n1bnQF0pbhXB7HKlO8mN3xcQSsk/9dA== X-Google-Smtp-Source: AGs4zMYpnqhBJMklv7WmhdovVt/n1z0aCYu6bKGiFx1gRAZiVcNfogwL7kYVd9YjkVHeRAICHa8grlGk/QVsPPj8cu8= X-Received: by 10.107.43.75 with SMTP id r72mr915285ior.31.1510328526653; Fri, 10 Nov 2017 07:42:06 -0800 (PST) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.32.144 with HTTP; Fri, 10 Nov 2017 07:42:05 -0800 (PST) In-Reply-To: <20171110151306.3zemo2mr4dx5lwnw@LK-Perkele-VII> References: <63029bbd-a9d5-0f30-718a-8d78f76a8e82@eff.org> <20171102161833.pqxnd6ql22k4qiul@LK-Perkele-VII> <20171110151306.3zemo2mr4dx5lwnw@LK-Perkele-VII> From: Daniel McCarney Date: Fri, 10 Nov 2017 10:42:05 -0500 Message-ID: To: Ilari Liusvaara Cc: Richard Barnes , Brad Warren , Hugo Landau , IETF ACME Content-Type: multipart/alternative; boundary="001a113949f0536502055da2c391" Archived-At: Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 15:42:09 -0000 --001a113949f0536502055da2c391 Content-Type: text/plain; charset="UTF-8" Hi Ilari, Also, do not confuse challege types and validation methods. Neither contains > the other. Thanks for clarifying. So there does not seem much reason to provode keys up front in order to support > different validation methods. Great! I agree with your reasoning here. So to update my earlier statement it seems that the only argument in favour of presenting the CSR in the new-order request that has appeared on-list is that it helps provide some potential errors to clients earlier. We both agree that clients will still have to handle errors at finalization time so it seems like a weak argument. - Daniel / cpu On Fri, Nov 10, 2017 at 10:13 AM, Ilari Liusvaara wrote: > On Fri, Nov 10, 2017 at 09:03:03AM -0500, Daniel McCarney wrote: > > > > > > Since people don't seem happy about either of these alternatives > > > (identifiers+CSR because of legacy issues; CSR+CSR because of > fragility), > > > here's one last attempt at a different approach: > > > > > > I think this is a mis-characterization. What are the legacy issues that > > can't be handled with identifiers+CSR? > > > > The opposition to this approach on-list has focused on challenge types > that > > could exist that would require the CSR public key & the benefits of > > delivering errors to clients regarding the CSR earlier. Neither of which > > seem to be a question of legacy issues. > > Also, do not confuse challege types and validation methods. Neither > contains the other. > > > Actually looking at the "10 methods" and seeing if they are key- > dependent or key-independent (only key-independent works if just domain > list is given up front): > > Key-Independent: > > - Method 1 (Authenticate DC via registry) > - Method 2 (Message DC) > - Method 3 (Call DC) > - Method 4 (E-Mail domain) > - Method 5 (Domain Authorization Document) > - Method 10 (Certificate Random Value) > > Key-Dependent: > > - Method 9 (Test certificate) > > Can be either: > > - Method 6 (HTTP) > - Method 7 (DNS) > - Method 8 (IP address) > > So every one of the present methods can be key-independent (situation > is similar with proposed IP address validation methods), except 9. > > Method 9 can be replaced with method 10, and since the client (or TLS > server) constructs the certificate, it can understand the scope of the > authorization if the validation method is so designed (I have a feeling > this is supposed to be required, but apparently not, given that TLS-SNI > fails this... But then, method 10 allows blatantly insecure stuff). > > I have seen some proposed methods (I think four), and those are pretty > much all key-independent or can be either. > > So there does not seem much reason to provode keys up front in order to > support different validation methods. > > > On checking earlier, the client needs to be prepared to get a fault on > order finalization anyway. Especially if order can take over 8 hours to > fill (Due to CAA recheck), which it can easily do if one hits pending > OOB challenges. > > > > -Ilari > --001a113949f0536502055da2c391 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ilari,

Also, do not confuse challege t= ypes and validation methods. Neither=C2=A0contains the other.

Thanks for clarifyin= g.

=C2=A0So there does not seem much reason to provode keys = up front in order to=C2=A0support d= ifferent validation methods.

Great! I agree wit= h your reasoning here. So to update my earlier statement it seems that the = only argument in favour of presenting the CSR in the new-order request that= has appeared on-list is that it helps provide some potential errors to cli= ents earlier.
We both agree that clients will still have to handle erro= rs at finalization time so it seems like a weak argument.

- Daniel /= cpu

=C2=A0

On Fri, Nov 10, 2017 at 10:13 AM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Fri, Nov 10, 2017 at 09:03:03AM -0500, Da= niel McCarney wrote:
> >
> > Since people don't seem happy about either of these alternati= ves
> > (identifiers+CSR because of legacy issues; CSR+CSR because of fra= gility),
> > here's one last attempt at a different approach:
>
>
> I think this is a mis-characterization. What a= re the legacy issues that
> can't be handled with identifiers+CSR?
>
> The opposition to this approach on-list has focused on challenge types= that
> could exist that would require the CSR public key & the benefits o= f
> delivering errors to clients regarding the CSR earlier. Neither of whi= ch
> seem to be a question of legacy issues.

Also, do not confuse challege types and validation methods. Neither<= br> contains the other.


Actually looking at the "10 methods" and seeing if they are key-<= br> dependent or key-independent (only key-independent works if just domain
list is given up front):

Key-Independent:

- Method 1 (Authenticate DC via registry)
- Method 2 (Message DC)
- Method 3 (Call DC)
- Method 4 (E-Mail domain)
- Method 5 (Domain Authorization Document)
- Method 10 (Certificate Random Value)

Key-Dependent:

- Method 9 (Test certificate)

Can be either:

- Method 6 (HTTP)
- Method 7 (DNS)
- Method 8 (IP address)

So every one of the present methods can be key-independent (situation
is similar with proposed IP address validation methods), except 9.

Method 9 can be replaced with method 10, and since the client (or TLS
server) constructs the certificate, it can understand the scope of the
authorization if the validation method is so designed (I have a feeling
this is supposed to be required, but apparently not, given that TLS-SNI
fails this... But then, method 10 allows blatantly insecure stuff).

I have seen some proposed methods (I think four), and those are pretty
much all key-independent or can be either.

So there does not seem much reason to provode keys up front in order to
support different validation methods.


On checking earlier, the client needs to be prepared to get a fault on
order finalization anyway. Especially if order can take over 8 hours to
fill (Due to CAA recheck), which it can easily do if one hits pending
OOB challenges.



-Ilari

--001a113949f0536502055da2c391-- From nobody Fri Nov 10 13:06:47 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAED1294AB for ; Fri, 10 Nov 2017 13:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9KvommFSYIG for ; Fri, 10 Nov 2017 13:06:41 -0800 (PST) Received: from mr11.infostorm.no (mr11.infostorm.no [217.18.206.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A80FA1294A6 for ; Fri, 10 Nov 2017 13:06:11 -0800 (PST) Received: from Buyp-gvk-ex01.intra.buypass.no (unknown [146.192.247.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mr11.infostorm.no (Postfix) with ESMTP id DD92E1377FF; Fri, 10 Nov 2017 22:06:08 +0100 (CET) Received: from BUYP-GVK-EX01.intra.buypass.no (10.11.2.9) by Buyp-gvk-ex01.intra.buypass.no (10.11.2.9) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 10 Nov 2017 22:06:08 +0100 Received: from BUYP-GVK-EX01.intra.buypass.no ([10.11.2.241]) by Buyp-gvk-ex01.intra.buypass.no ([10.11.2.241]) with mapi id 15.00.0995.032; Fri, 10 Nov 2017 22:06:08 +0100 From: Andriy Mahats To: "cpu@letsencrypt.org" , Richard Barnes CC: Ilari Liusvaara , Brad Warren , Hugo Landau , IETF ACME Thread-Topic: [Acme] Revisiting Proactive Issuance & new-order CSR Thread-Index: AQHTWiyqKDLZk7pTWk68pg/AfviisqMOE0hQ Date: Fri, 10 Nov 2017 21:06:07 +0000 Message-ID: <5d84e71c34624c4ebfb46053d02ab2c0@Buyp-gvk-ex01.intra.buypass.no> References: <71f3e975-7cee-18cf-2635-80eb13adff12@devever.net> <20171024141732.ufjysx5f73pyc5f4@LK-Perkele-VII> <63029bbd-a9d5-0f30-718a-8d78f76a8e82@eff.org> <20171102161833.pqxnd6ql22k4qiul@LK-Perkele-VII> In-Reply-To: Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.11.51.28] Content-Type: multipart/alternative; boundary="_000_5d84e71c34624c4ebfb46053d02ab2c0Buypgvkex01intrabuypass_" MIME-Version: 1.0 X-mr11-MailScanner-Information: Please contact the ISP for more information X-mr11-MailScanner-ID: DD92E1377FF.ADA82 X-mr11-MailScanner: Found to be clean X-mr11-MailScanner-From: andriy.mahats@buypass.no Archived-At: Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 21:06:45 -0000 --_000_5d84e71c34624c4ebfb46053d02ab2c0Buypgvkex01intrabuypass_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsDQoNCkkgYW0gbm90IHJlc3BvbnNpbmcgdG8gbGF0ZXN0IG1lc3NhZ2UgaW4gdGhyZWFk IGN1cnJlbnRseSAoRGFuaWVscyByZXBseSB0byBJbGFyaSkgYmVjYXVzZSBpdCBsb3N0IHRoZSBj b250ZW50IHRvIHdoaWNoIEkgd291bGQgbGlrZSB0byByZWZlci4NCg0KSSB3b3VsZCBwcmVmZXIg dGhlIHRoaXJkIGFwcHJvYWNoIHN1Z2dlc3RlZCBieSBSaWNoYXJkIC0gYXV0aG9yaXphdGlvbkZp cnN0Lg0KSW4gdGhhdCBhcHByb2FjaCBpbiBjYXNlIHRoZSBhdXRob3JpemF0aW9uRmlyc3QgaGFw cGVuZWQsIHRoZSBzZXJ2ZXIgY2FuIHByb3ZpZGUgYXV0aG9yaXphdGlvbnMgdG8gYmUgZnVsZmls bGVkDQp3aXRob3V0IGJpbmRpbmcgdGhlbSB0byBzb21lIG9yZGVyIOKAkyBzbyBubyBvcmRlciBp cyBhbGxvY2F0ZWQgYXQgdGhpcyBzdGVwIChqdXN0IGFzIGl0IGlzIGluIG5ldy1hdXRoeiBvZiB2 MSkuDQpOZXh0LCBhZnRlciBjbGllbnQgZnVsZmlsbGVkIHRoZSBhdXRob3JpemF0aW9ucyBhbmQg cGxhY2VzIG5ldy1vcmRlciB0aGVuIGl0IGNhbiBiZSBpc3N1ZWQgKGp1c3QgbGlrZSBuZXctY2Vy dCBvZiB2MSkNCg0KSW4gaWRlbnRpZmllcnMrQ1NSOiB0aGUgbmV3LW9yZGVyIHdvdWxkIGNyZWF0 ZSBhbiBvcmRlcklkIGFuZCBhZnRlciB0aGF0IHByb3ZpZGUgdGhlIGNsaWVudCB3aXRoIGxpbmtz IHRvIGF1dGhvcml6YXRpb25zIHRvIGJlIGZ1bGZpbGxlZC4NCg0KDQoNClBlcnNvbmFsbHkgSSBw cmVmZXIgdGhlIGF1dGhvcml6YXRpb25GaXJzdC4gSXQgaXMgZnJvbSBvbmUgc2lkZSBzaW1wbGVy LCBtb3JlIHNpbWlsYXIgdG8gdjEgd2F5IGFuZCBhbHNvIHNlZW1zIHRvIGJlIGxlc3MgcmVzb3Vy Y2UgZGVtYW5kaW5nIG9uIHNlcnZlci4NCg0KU2luY2UgaWRlbnRpZmllcnMrQ1NSIGFwcHJvYWNo IHdvdWxkIG5lZWQgdG8gY3JlYXRlL2dvIHRocm91Z2ggYWxsIGF1dGhvcml6YXRpb25zIG9uIG5l dy1vcmRlciBzdGVwIGFuZCBsYXRlciBvbiBmaW5hbGl6YXRpb24gYXQgb25jZS4NCkFsc28gaW4g Y2FzZXMgd2hlbiBjbGllbnRzIGFyZSB1bmFibGUgdG8gZnVsZmlsbCB0aGUgb3JkZXIgaXQgd2ls bCBzdGlsbCBzdGF5IGluIHRoZSBkYg0KDQoNClJlZ2FyZHMsDQpBbmRyaXkNCg0KDQoNCg0KRnJv bTogRGFuaWVsIE1jQ2FybmV5IFttYWlsdG86Y3B1QGxldHNlbmNyeXB0Lm9yZ10NClNlbnQ6IGZy ZWRhZyAxMC4gbm92ZW1iZXIgMjAxNyAxNTowMw0KVG86IFJpY2hhcmQgQmFybmVzIDxybGJAaXB2 LnN4Pg0KQ2M6IElsYXJpIExpdXN2YWFyYSA8aWxhcmlsaXVzdmFhcmFAd2VsaG8uY29tPjsgQnJh ZCBXYXJyZW4gPGJtd0BlZmYub3JnPjsgSHVnbyBMYW5kYXUgPGhsYW5kYXVAZGV2ZXZlci5uZXQ+ OyBJRVRGIEFDTUUgPGFjbWVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0FjbWVdIFJldmlzaXRp bmcgUHJvYWN0aXZlIElzc3VhbmNlICYgbmV3LW9yZGVyIENTUg0KDQpTaW5jZSBwZW9wbGUgZG9u J3Qgc2VlbSBoYXBweSBhYm91dCBlaXRoZXIgb2YgdGhlc2UgYWx0ZXJuYXRpdmVzIChpZGVudGlm aWVycytDU1IgYmVjYXVzZSBvZiBsZWdhY3kgaXNzdWVzOyBDU1IrQ1NSIGJlY2F1c2Ugb2YgZnJh Z2lsaXR5KSwgaGVyZSdzIG9uZSBsYXN0IGF0dGVtcHQgYXQgYSBkaWZmZXJlbnQgYXBwcm9hY2g6 DQoNCkkgdGhpbmsgdGhpcyBpcyBhIG1pcy1jaGFyYWN0ZXJpemF0aW9uLiBXaGF0IGFyZSB0aGUg bGVnYWN5IGlzc3VlcyB0aGF0IGNhbid0IGJlIGhhbmRsZWQgd2l0aCBpZGVudGlmaWVycytDU1I/ DQoNClRoZSBvcHBvc2l0aW9uIHRvIHRoaXMgYXBwcm9hY2ggb24tbGlzdCBoYXMgZm9jdXNlZCBv biBjaGFsbGVuZ2UgdHlwZXMgdGhhdCBjb3VsZCBleGlzdCB0aGF0IHdvdWxkIHJlcXVpcmUgdGhl IENTUiBwdWJsaWMga2V5ICYgdGhlIGJlbmVmaXRzIG9mIGRlbGl2ZXJpbmcgZXJyb3JzIHRvIGNs aWVudHMgcmVnYXJkaW5nIHRoZSBDU1IgZWFybGllci4gTmVpdGhlciBvZiB3aGljaCBzZWVtIHRv IGJlIGEgcXVlc3Rpb24gb2YgbGVnYWN5IGlzc3Vlcy4NCkl0IGFsc28gcmVtb3ZlcyB0aGUgYXV0 aGVudGljYXRpb24gb24gdGhlICJmaW5hbGl6ZSIgc3RlcCAocmVwbGFjaW5nIGl0IHdpdGggYSBH RVQpLCBidXQgSSBkb24ndCB0aGluayB3ZSBoYWQgaGVhcmQgYSByZWFzb24gZm9yIHRoZSBhdXRo ZW50aWNhdGlvbiBhbnl3YXkuDQoNClRoaXMgcmV0dXJucyB0byBpc3N1aW5nIGEgY2VydGlmaWNh dGUgb24gYSBHRVQgcmVxdWVzdCAtIEkgdGhpbmsgdGhlcmUgd2FzIHNvbWUgb3Bwb3NpdGlvbiB0 byB0aGlzIGFwcHJvYWNoLg0KRnJvbSBhIGNsaWVudCBwZXJzcGVjdGl2ZSwgaXQgYWRtaXRzIGEg cHJldHR5IHNpbXBsZSBmbG93Og0KDQpUaGlzIGZsb3cgc2VlbXMgbW9yZSBjb21wbGljYXRlZCB0 aGFuIG15IG9yaWdpbmFsIHByb3Bvc2FsLiBIb3cgaXMgaXQgc2ltcGxlciB0aGFuOg0KDQphLiBz dWJtaXQgbmV3LW9yZGVyIHdpdGggaWRlbnRpZmllcnMNCmIuIGZ1bGZpbGwgdGhlIGF1dGhvcml6 YXRpb25zDQpjLiBmaW5hbGl6ZSB0aGUgb3JkZXIgd2l0aCBDU1INCg0KVGhpcyBpcyBhbHNvICpt dWNoKiBjbG9zZXIgdG8gdGhlIGN1cnJlbnQgIlYxIiBpc3N1YW5jZSBwcm9jZXNzIHdoZXJlIGNs aWVudHMgcmVxdWVzdCBhdXRoenMsIGZ1bGZpbGwgdGhlbSwgYW5kIHRoZW4gc3VibWl0IHRvIG5l dy1jZXJ0IHdpdGggYSBDU1IuIEdpdmVuIHRoYXQgMTAwJSBvZiBleGlzdGluZyBBQ01FIGNsaWVu dHMgaW1wbGVtZW50IGEgZmluYWxpemF0aW9uIGJhc2VkIGFwcHJvYWNoICh1c2luZyBuZXctY2Vy dCksIHdvdWxkIGl0IG5vdCBiZSBlYXNpZXIgZm9yIHRoZW0gdG8gYWRhcHQgY3VycmVudCBjb2Rl IGlmIHdlIG1hdGNoZWQgdGhpcyBiZWhhdmlvdXIgZm9yIHRoZSBuZXctb3JkZXIgZmxvdz8NCg0K LSBEYW5pZWwgLyBjcHUNCg0KT24gVGh1LCBOb3YgOSwgMjAxNyBhdCA1OjE4IFBNLCBSaWNoYXJk IEJhcm5lcyA8cmxiQGlwdi5zeDxtYWlsdG86cmxiQGlwdi5zeD4+IHdyb3RlOg0KU2luY2UgcGVv cGxlIGRvbid0IHNlZW0gaGFwcHkgYWJvdXQgZWl0aGVyIG9mIHRoZXNlIGFsdGVybmF0aXZlcyAo aWRlbnRpZmllcnMrQ1NSIGJlY2F1c2Ugb2YgbGVnYWN5IGlzc3VlczsgQ1NSK0NTUiBiZWNhdXNl IG9mIGZyYWdpbGl0eSksIGhlcmUncyBvbmUgbGFzdCBhdHRlbXB0IGF0IGEgZGlmZmVyZW50IGFw cHJvYWNoOg0KDQoxLiBBZGQgYW4gZXJyb3IgY29kZSBmb3IgbmV3LW9yZGVyLCBzYXkgImF1dGhv cml6YXRpb25GaXJzdCIsIHdoaWNoIG1lYW5zICJJIG9ubHkgYWNjZXB0IG9yZGVycyB3aXRoIGFs bCBhdXRoeiBmdWxmaWxsZWQ7IGdvIGFuZCBkbyB0aGVzZSBhdXRoeiBhbmQgdGhlbiBzdWJtaXQg bmV3LW9yZGVyIg0KMi4gV2hlbiB5b3Ugc2VuZCBhbiAiYXV0aG9yaXphdGlvbkZpcnN0IiBlcnJv ciwgeW91IE1VU1Qgc2VuZCBhdXRob3JpemF0aW9ucyBmb3IgdGhlIGNsaWVudCB0byBjb21wbGV0 ZQ0KMy4gQWRkIGEgbm90ZSB0aGF0IHRoZSBzZXJ2ZXIgTUFZIGRlbGF5IGlzc3VhbmNlIHVudGls IGl0IHJlY2VpdmVzIHRoZSBmaXJzdCBHRVQgcmVxdWVzdCB0byB0aGUgY2VydGlmaWNhdGUgVVJM DQoNClRoaXMgaXMgYmFzaWNhbGx5IGVxdWl2YWxlbnQgdG8gdGhlIENTUitDU1IgcHJvcG9zYWwg ZnJvbSB0aGUgc2VydmVyIFBPViwgYnV0IG5vdyB0aGVyZSdzIG5vIGZvcm1hbCByZWxhdGlvbnNo aXAgYmV0d2VlbiB0aGUgdHdvIENTUnMgKHRoZXkncmUgaW5kZXBlbmRlbnQgb3JkZXJzKSwgc28g eW91IGRvbid0IGhhdmUgdG8gd29ycnkgYWJvdXQgd2hhdCBoYXBwZW5zIGlmIHRoZXkncmUgZGlm ZmVyZW50LiAgSXQgYWxzbyByZW1vdmVzIHRoZSBhdXRoZW50aWNhdGlvbiBvbiB0aGUgImZpbmFs aXplIiBzdGVwIChyZXBsYWNpbmcgaXQgd2l0aCBhIEdFVCksIGJ1dCBJIGRvbid0IHRoaW5rIHdl IGhhZCBoZWFyZCBhIHJlYXNvbiBmb3IgdGhlIGF1dGhlbnRpY2F0aW9uIGFueXdheS4gIEZyb20g YSBjbGllbnQgcGVyc3BlY3RpdmUsIGl0IGFkbWl0cyBhIHByZXR0eSBzaW1wbGUgZmxvdzoNCg0K ICBhLiBTdWJtaXQgbmV3LW9yZGVyDQogIGIuIElmIHJlc3BvbnNlIGlzIDJYWCBvciBhdXRoek5l ZWRlZCwgZ28gZG8gdGhlIGF1dGh6DQogIGMuIElmIHlvdSBnb3QgYXV0aHpOZWVkZWQsIHJlLXN1 Ym1pdCBuZXctb3JkZXI7IGVsc2UgcG9sbCBvcmRlciB1bnRpbCBjZXJ0IFVSTCBzaG93cyB1cA0K ICBkLiBQb2xsIGNlcnQgVVJMDQoNCkRyYWZ0IFBSOiBodHRwczovL2dpdGh1Yi5jb20vaWV0Zi13 Zy1hY21lL2FjbWUvcHVsbC8zNTANCg0KSW4gYW55IGNhc2UsIGl0IHdvdWxkIGJlIGhlbHBmdWwg aWYgcGVvcGxlIGNvdWxkIHByb3ZpZGUgdGhvdWdodHMgb24gd2hpY2ggb2YgdGhlIHRocmVlIG9w dGlvbnMgdGhleSBwcmVmZXIgaGVyZToNCg0KMS4gSWRlbnRpZmllcnMgKyBDU1IgKGh0dHBzOi8v Z2l0aHViLmNvbS9pZXRmLXdnLWFjbWUvYWNtZS9wdWxsLzM0MikNCjIuIENTUiArIENTUiAoc2Ft ZSwgYnV0IHdpdGggYSBDU1IgaW5zdGVhZCBvZiBpZGVudGlmaWVycykNCjMuIGF1dGhvcml6YXRp b25GaXJzdCAoaHR0cHM6Ly9naXRodWIuY29tL2lldGYtd2ctYWNtZS9hY21lL3B1bGwvMzUwKQ0K DQpQZXJzb25hbGx5LCBteSBjdXJyZW50IHByZWZlcmVuY2UgaXMgZm9yICgzKSwgYmVjYXVzZSBp dCBzZWVtcyBsaWtlIHRoZSBsZWFzdCBjb21wbGV4IC8gZXJyb3IgcHJvbmUgd2F5IHRvIHN1cHBv cnQgYm90aCBiYWNrLWVuZCBjYXNlcyAoQ1NSIGZpcnN0IC8gQ1NSIGxhc3QpLg0KDQpUaGFua3Ms DQotLVJpY2hhcmQNCg0KDQoNCk9uIFdlZCwgTm92IDgsIDIwMTcgYXQgOTowNSBBTSwgRGFuaWVs IE1jQ2FybmV5IDxjcHVAbGV0c2VuY3J5cHQub3JnPG1haWx0bzpjcHVAbGV0c2VuY3J5cHQub3Jn Pj4gd3JvdGU6DQpIaSBJbGFyaSwNCkkgZ3Vlc3MgaWYgeW91IGZpbmQgYW55IHVzZSBmb3IgdGhl IGtleSBhdCBhbGwgZGVwZW5kcyBvbiBpZiBhdXRob3JpemF0aW9ucyBhcmUgb3JkZXItc2NvcGVk IG9yIGFjY291bnQtc2NvcGVkLg0KDQpTZWUgdGhpcyBmb2xsb3ctdXAgdGhyZWFkWzBdIC0gaXQg c2VlbXMgbGlrZSAic2NvcGUiIG9uIG9yZGVycyBpcyB1bm5lY2Vzc2FyeSAmIGNvbmZ1c2luZy4g SSB2b3RlIGl0IGJlIHJlbW92ZWQgYW5kIFJpY2hhcmQgQmFybmVzIHNlZW1zIHRvIGJlIHN1cHBv cnRpdmUgb2YgdGhhdC4NClRoZXJlIGlzIGF0IGxlYXN0IG9uZSBtZXRob2QgaW4gIjEwIG1ldGhv ZHMiIHRoYXQgYWJzb2x1dGVseSByZXF1aXJlcyB0aGUga2V5IHRvIGJlIGtub3duIChudW1iZXIg OSkuIEFsc28sIGlmIHRoZSB2YXJpYW50IG9mIHRoZSB2YWxpZGF0aW9uIG1ldGhvZCB1c2VzIHRo ZSBrZXksIGl0IGRvZXMgbm90IHNlZW0gc2FmZSB0byByZXVzZSBpdCBmb3IgZGlmZmVyZW50IGtl eS4NCg0KQ2FuIHlvdSBjaXRlIHRoZSBzcGVjaWZpYyBjaGFsbGVuZ2UgbWV0aG9kIHlvdSBtZWFu IChvciB0aGUgc2VjdGlvbiBvZiB0aGUgYmFzZWxpbmUgcmVxdWlyZW1lbnRzKSAtIEkgZG9uJ3Qg a25vdyB3aGljaCBzcGVjaWZpYyB2YWxpZGF0aW9uIG1ldGhvZCB5b3UncmUgcmVmZXJyaW5nIHRv Lg0KDQpNb3JlIGJyb2FkbHk6IEFDTUUgZGVmaW5lcyBhIG51bWJlciBvZiB2YWxpZGF0aW9uIGNo YWxsZW5nZSBtZXRob2RzLiBJdCBkb2VzIG5vdCBkZWZpbmUgYSB2YWxpZGF0aW9uIG1ldGhvZCBi YXNlZCBvbiB1c2luZyB0aGUgcHVibGljIGtleSBmcm9tIGEgQ1NSLiBVc2luZyB1bnNwZWNpZmll ZCBjaGFsbGVuZ2UgdHlwZXMgYXMgYW4gYXJndW1lbnQgZm9yIHdoeSB0aGUgQ1NSIHNob3VsZCBi ZSBzdWJtaXR0ZWQgZWFybHkgZG9lc24ndCBzZWVtIHZlcnkgY29udmluY2luZyB0byBtZS4NCg0K V2hhdCBpcyB0aGUgcmF0aW9uYWxlIGZvciBuZWVkaW5nIHN1Y2ggYSBjaGFsbGVuZ2UgdHlwZT8N CldoYXQgcHJvYmxlbXMgZG9lcyB0aGlzIGNoYWxsZW5nZSB0eXBlIHJlc29sdmUgdGhhdCBhcmUg bm90IHJlc29sdmVkIGJ5IHRoZSBjdXJyZW50IGNoYWxsZW5nZSB0eXBlcz8NCkRvIHlvdSBvciBh bnkgb3RoZXIgQUNNRSBzZXJ2ZXJzIGhhdmUgaW50ZXJlc3QgaW4gc3BlY2lmeWluZyAmIGltcGxl bWVudGluZyBzdWNoIGEgY2hhbGxlbmdlIHR5cGU/DQoNCkknbSBleHRyZW1lbHkgaGVzaXRhbnQg dG8gbWFrZSBkZXNpZ24gZGVjaXNpb25zIGJhc2VkIG9uIGFsbG93aW5nIGZvciB2ZXJ5IG9wZW4t ZW5kZWQgZmVhdHVyZXMgaW4gdGhlIGZ1dHVyZSB3aGVuIHRoZXJlIGlzbid0IGEgc3Ryb25nIGNh c2UgZm9yIHRoZSBmZWF0dXJlIG9yIGFueSBlc3RhYmxpc2hlZCBpbnRlcmVzdCBpbiBpbXBsZW1l bnRpbmcgJiBzaGlwcGluZyBpdC4NCklmIG9yZGVycyBjYW4gbGl2ZSBvdmVyIDggaG91cnMsIHRo ZW4gb25lIE1VU1QgYmUgcHJlcGFyZWQgdG8gdGFrZSByZWplY3Rpb24gYXQgZmluYWxpemF0aW9u IGFueXdheS4gQmVjYXVzZSBldmVuIGlmIENBQSB3YXMgY2hlY2tlZCBhdCAgYXV0aG9yaXphdGlv biBjcmVhdGlvbiwgaXQgbWlnaHQgaGF2ZSBiZWVuIGNoYW5nZWQgYW5kIGNvbnNlcXVlbnRseSBm YWlsIHRoZSByZWNoZWNrLg0KDQpZZXMsIHRoaXMgaXMgc29tZXRoaW5nIEkgbWVudGlvbmVkIGlu IG15IHJlcGx5WzFdIHRvIG9uZSBvZiB5b3VyIGVhcmxpZXIgbWVzc2FnZXMgYXMgd2VsbCBhcyBp biBteSByZXBseSB0byBCcmFkIFdhcnJlblsyXS4NCg0KLSBEYW5pZWwgLyBjcHUNCg0KDQpbMF0g LSBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2FjbWUvd2tRSDJBcXlwb0du QnlpdUNmWWdxMlVJM25JDQpbMV0gLSBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gv bXNnL2FjbWUvS0VCM3NMUnN3VFQzbV9YSWJaU1c1MnIzbHhNLz9xaWQ9YWJjYWJiYzM3MjQ0M2Zi ZTMxYzk1MjU1OGFhMzM5MmYNClsyXSAtIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJj aC9tc2cvYWNtZS8tdWFtUTRTUGt4SFJfZXNjaHBCU3FrRzEteUUNCg0KT24gVGh1LCBOb3YgMiwg MjAxNyBhdCAxMjoxOCBQTSwgSWxhcmkgTGl1c3ZhYXJhIDxpbGFyaWxpdXN2YWFyYUB3ZWxoby5j b208bWFpbHRvOmlsYXJpbGl1c3ZhYXJhQHdlbGhvLmNvbT4+IHdyb3RlOg0KT24gVGh1LCBOb3Yg MDIsIDIwMTcgYXQgMTA6Mjk6NThBTSAtMDQwMCwgRGFuaWVsIE1jQ2FybmV5IHdyb3RlOg0KDQo+ DQo+IEkgdW5kZXJzdGFuZCB0aGF0IHRoZXNlIGNvcm5lciBjYXNlcyBhcmVuJ3QgYSBzdXBlciBj b252aW5jaW5nIGxpbmUgb2YNCj4gYXJndW1lbnQsIGJ1dCBJIGFsc28gZG9uJ3QgdGhpbmsgYSBz bGlnaHQgcHJlZmVyZW5jZSBmb3IgZG91YmxlIENTUg0KPiBzdHJpY3RseSBiZWNhdXNlIGl0IGFs bG93cyBkZWxpdmVyaW5nIGEgcHVibGljIGtleSByZWplY3Rpb24gZXJyb3Igc2xpZ2h0bHkNCj4g ZWFybGllciBpbiB0aGUgb3JkZXIgZmxvdyBpcyBhIHZlcnkgY29udmluY2luZyBhcmd1bWVudCBl aXRoZXIuIERvZXMNCj4gc29tZW9uZSBoYXZlIHNvbWV0aGluZyBzdHJvbmdlciBpbiBtaW5kPw0K DQpJIGd1ZXNzIGlmIHlvdSBmaW5kIGFueSB1c2UgZm9yIHRoZSBrZXkgYXQgYWxsIGRlcGVuZHMg b24gaWYNCmF1dGhvcml6YXRpb25zIGFyZSBvcmRlci1zY29wZWQgb3IgYWNjb3VudC1zY29wZWQu DQoNCklmIGF1dGhvcml6YXRpb25zIGFyZSBvcmRlci1zY29wZWQsIHRoZW4gdGhlIGtleXMgY291 bGQgYmUgdXNlZCBmb3INCmFkZGl0aW9uYWwgdmFsaWRhdGlvbiBtZXRob2RzLi4uIFRoZXJlIGlz IGF0IGxlYXN0IG9uZSBtZXRob2QgaW4gIjEwDQptZXRob2RzIiB0aGF0IGFic29sdXRlbHkgcmVx dWlyZXMgdGhlIGtleSB0byBiZSBrbm93biAobnVtYmVyIDkpLg0KQWxzbywgaWYgdGhlIHZhcmlh bnQgb2YgdGhlIHZhbGlkYXRpb24gbWV0aG9kIHVzZXMgdGhlIGtleSwgaXQgZG9lcw0Kbm90IHNl ZW0gc2FmZSB0byByZXVzZSBpdCBmb3IgZGlmZmVyZW50IGtleS4NCg0KSWYgb3JkZXJzIGNhbiBs aXZlIG92ZXIgOCBob3VycywgdGhlbiBvbmUgTVVTVCBiZSBwcmVwYXJlZCB0byB0YWtlDQpyZWpl Y3Rpb24gYXQgZmluYWxpemF0aW9uIGFueXdheS4gQmVjYXVzZSBldmVuIGlmIENBQSB3YXMgY2hl Y2tlZCBhdA0KYXV0aG9yaXphdGlvbiBjcmVhdGlvbiwgaXQgbWlnaHQgaGF2ZSBiZWVuIGNoYW5n ZWQgYW5kIGNvbnNlcXVlbnRseQ0KZmFpbCB0aGUgcmVjaGVjay4NCg0KDQotSWxhcmkNCg0KDQoN Cg== --_000_5d84e71c34624c4ebfb46053d02ab2c0Buypgvkex01intrabuypass_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4ubS02MzcxNjE5NTYw MjAyNzA4NTU3Z21haWwtYmxvYi1jb2RlLWlubmVyDQoJe21zby1zdHlsZS1uYW1lOm1fLTYzNzE2 MTk1NjAyMDI3MDg1NTdnbWFpbC1ibG9iLWNvZGUtaW5uZXI7fQ0Kc3Bhbi5tLTYzNzE2MTk1NjAy MDI3MDg1NTdnbWFpbC1wbC1zDQoJe21zby1zdHlsZS1uYW1lOm1fLTYzNzE2MTk1NjAyMDI3MDg1 NTdnbWFpbC1wbC1zO30NCnNwYW4ubS02MzcxNjE5NTYwMjAyNzA4NTU3Z21haWwtbTgyMDg4NzY1 MjY5NTQ1NjMwMjVtNDczNzkxNTEzNjM2NjEzNTE5MWhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpt Xy02MzcxNjE5NTYwMjAyNzA4NTU3Z21haWwtbV84MjA4ODc2NTI2OTU0NTYzMDI1bV80NzM3OTE1 MTM2MzY2MTM1MTkxaG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iTk8t Qk9LIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGkgYWxsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5JIGFtIG5vdCByZXNwb25zaW5nIHRvIGxhdGVzdCBtZXNzYWdlIGluIHRo cmVhZCBjdXJyZW50bHkgKERhbmllbHMgcmVwbHkgdG8gSWxhcmkpIGJlY2F1c2UgaXQgbG9zdCB0 aGUgY29udGVudCB0byB3aGljaCBJIHdvdWxkIGxpa2UgdG8gcmVmZXIuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5JIHdvdWxkIHByZWZlciB0aGUgdGhpcmQgYXBwcm9hY2ggc3VnZ2VzdGVkIGJ5IFJpY2hh cmQgLSBhdXRob3JpemF0aW9uRmlyc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkluIHRoYXQgYXBwcm9hY2ggaW4gY2FzZSB0 aGUgYXV0aG9yaXphdGlvbkZpcnN0IGhhcHBlbmVkLCB0aGUgc2VydmVyIGNhbiBwcm92aWRlIGF1 dGhvcml6YXRpb25zIHRvIGJlIGZ1bGZpbGxlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj53aXRob3V0IGJpbmRpbmcgdGhlbSB0 byBzb21lIG9yZGVyIOKAkyBzbyBubyBvcmRlciBpcyBhbGxvY2F0ZWQgYXQgdGhpcyBzdGVwIChq dXN0IGFzIGl0IGlzIGluIG5ldy1hdXRoeiBvZiB2MSkuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk5leHQsIGFmdGVyIGNsaWVu dCBmdWxmaWxsZWQgdGhlIGF1dGhvcml6YXRpb25zIGFuZCBwbGFjZXMgbmV3LW9yZGVyIHRoZW4g aXQgY2FuIGJlIGlzc3VlZCAoanVzdCBsaWtlIG5ldy1jZXJ0IG9mIHYxKTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+SW4gaWRlbnRpZmllcnMmIzQzO0NTUjogdGhlIG5ldy1vcmRlciB3b3VsZCBjcmVhdGUg YW4gb3JkZXJJZCBhbmQgYWZ0ZXIgdGhhdCBwcm92aWRlIHRoZSBjbGllbnQgd2l0aCBsaW5rcyB0 byBhdXRob3JpemF0aW9ucyB0byBiZSBmdWxmaWxsZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPlBlcnNvbmFsbHkgSSBwcmVmZXIgdGhlIGF1dGhvcml6YXRp b25GaXJzdC4gSXQgaXMgZnJvbSBvbmUgc2lkZSBzaW1wbGVyLCBtb3JlIHNpbWlsYXIgdG8gdjEg d2F5IGFuZCBhbHNvIHNlZW1zIHRvIGJlIGxlc3MgcmVzb3VyY2UgZGVtYW5kaW5nIG9uIHNlcnZl ci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNpbmNlIGlkZW50aWZpZXJzJiM0MztDU1IgYXBwcm9hY2gg d291bGQgbmVlZCB0byBjcmVhdGUvZ28gdGhyb3VnaCBhbGwgYXV0aG9yaXphdGlvbnMgb24gbmV3 LW9yZGVyIHN0ZXAgYW5kIGxhdGVyIG9uIGZpbmFsaXphdGlvbiBhdCBvbmNlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BbHNv IGluIGNhc2VzIHdoZW4gY2xpZW50cyBhcmUgdW5hYmxlIHRvIGZ1bGZpbGwgdGhlIG9yZGVyIGl0 IHdpbGwgc3RpbGwgc3RheSBpbiB0aGUgZGI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5BbmRyaXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiBEYW5pZWwgTWNDYXJuZXkgW21haWx0bzpjcHVAbGV0c2VuY3J5cHQub3Jn XQ0KPGJyPg0KPGI+U2VudDo8L2I+IGZyZWRhZyAxMC4gbm92ZW1iZXIgMjAxNyAxNTowMzxicj4N CjxiPlRvOjwvYj4gUmljaGFyZCBCYXJuZXMgJmx0O3JsYkBpcHYuc3gmZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBJbGFyaSBMaXVzdmFhcmEgJmx0O2lsYXJpbGl1c3ZhYXJhQHdlbGhvLmNvbSZndDs7IEJy YWQgV2FycmVuICZsdDtibXdAZWZmLm9yZyZndDs7IEh1Z28gTGFuZGF1ICZsdDtobGFuZGF1QGRl dmV2ZXIubmV0Jmd0OzsgSUVURiBBQ01FICZsdDthY21lQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW0FjbWVdIFJldmlzaXRpbmcgUHJvYWN0aXZlIElzc3VhbmNlICZhbXA7 IG5ldy1vcmRlciBDU1I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+U2luY2UgcGVvcGxlIGRvbid0IHNlZW0gaGFwcHkgYWJvdXQgZWl0aGVyIG9mIHRo ZXNlIGFsdGVybmF0aXZlcyAoaWRlbnRpZmllcnMmIzQzO0NTUiBiZWNhdXNlIG9mIGxlZ2FjeSBp c3N1ZXM7IENTUiYjNDM7Q1NSIGJlY2F1c2Ugb2YgZnJhZ2lsaXR5KSwgaGVyZSdzIG9uZSBsYXN0 IGF0dGVtcHQgYXQgYSBkaWZmZXJlbnQgYXBwcm9hY2g6PG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSSB0aGluayB0aGlzIGlz IGEgbWlzLWNoYXJhY3Rlcml6YXRpb24uIFdoYXQgYXJlIHRoZSBsZWdhY3kgaXNzdWVzIHRoYXQg Y2FuJ3QgYmUgaGFuZGxlZCB3aXRoIGlkZW50aWZpZXJzJiM0MztDU1I/Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+VGhlIG9wcG9zaXRpb24gdG8gdGhpcyBhcHByb2FjaCBvbi1saXN0 IGhhcyBmb2N1c2VkIG9uIGNoYWxsZW5nZSB0eXBlcyB0aGF0IGNvdWxkIGV4aXN0IHRoYXQgd291 bGQgcmVxdWlyZSB0aGUgQ1NSIHB1YmxpYyBrZXkgJmFtcDsgdGhlIGJlbmVmaXRzIG9mIGRlbGl2 ZXJpbmcgZXJyb3JzIHRvIGNsaWVudHMgcmVnYXJkaW5nIHRoZSBDU1IgZWFybGllci4gTmVpdGhl cg0KIG9mIHdoaWNoIHNlZW0gdG8gYmUgYSBxdWVzdGlvbiBvZiBsZWdhY3kgaXNzdWVzLjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS41cHQiPkl0IGFsc28gcmVtb3ZlcyB0aGUgYXV0aGVudGljYXRpb24gb24g dGhlICZxdW90O2ZpbmFsaXplJnF1b3Q7IHN0ZXAgKHJlcGxhY2luZyBpdCB3aXRoIGEgR0VUKSwg YnV0IEkgZG9uJ3QgdGhpbmsgd2UgaGFkIGhlYXJkIGEgcmVhc29uIGZvciB0aGUgYXV0aGVudGlj YXRpb24gYW55d2F5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4N ClRoaXMgcmV0dXJucyB0byBpc3N1aW5nIGEgY2VydGlmaWNhdGUgb24gYSBHRVQgcmVxdWVzdCAt IEkgdGhpbmsgdGhlcmUgd2FzIHNvbWUgb3Bwb3NpdGlvbiB0byB0aGlzIGFwcHJvYWNoLjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS41cHQiPkZyb20gYSBjbGllbnQgcGVyc3BlY3RpdmUsIGl0IGFkbWl0cyBh IHByZXR0eSBzaW1wbGUgZmxvdzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KVGhpcyBmbG93IHNlZW1zIG1vcmUg Y29tcGxpY2F0ZWQgdGhhbiBteSBvcmlnaW5hbCBwcm9wb3NhbC4gSG93IGlzIGl0IHNpbXBsZXIg dGhhbjo8YnI+DQo8YnI+DQphLiBzdWJtaXQgbmV3LW9yZGVyIHdpdGggaWRlbnRpZmllcnM8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmIuIGZ1bGZp bGwgdGhlIGF1dGhvcml6YXRpb25zPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5jLiBmaW5hbGl6ZSB0aGUgb3JkZXIgd2l0aCBDU1I8YnI+DQo8YnI+ DQpUaGlzIGlzIGFsc28gKm11Y2gqIGNsb3NlciB0byB0aGUgY3VycmVudCAmcXVvdDtWMSZxdW90 OyBpc3N1YW5jZSBwcm9jZXNzIHdoZXJlIGNsaWVudHMgcmVxdWVzdCBhdXRoenMsIGZ1bGZpbGwg dGhlbSwgYW5kIHRoZW4gc3VibWl0IHRvIG5ldy1jZXJ0IHdpdGggYSBDU1IuIEdpdmVuIHRoYXQg MTAwJSBvZiBleGlzdGluZyBBQ01FIGNsaWVudHMgaW1wbGVtZW50IGEgZmluYWxpemF0aW9uIGJh c2VkIGFwcHJvYWNoICh1c2luZyBuZXctY2VydCksIHdvdWxkIGl0IG5vdA0KIGJlIGVhc2llciBm b3IgdGhlbSB0byBhZGFwdCBjdXJyZW50IGNvZGUgaWYgd2UgbWF0Y2hlZCB0aGlzIGJlaGF2aW91 ciBmb3IgdGhlIG5ldy1vcmRlciBmbG93Pzxicj4NCjxicj4NCi0gRGFuaWVsIC8gY3B1Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBUaHUsIE5vdiA5LCAyMDE3IGF0IDU6MTggUE0sIFJpY2hhcmQgQmFy bmVzICZsdDs8YSBocmVmPSJtYWlsdG86cmxiQGlwdi5zeCIgdGFyZ2V0PSJfYmxhbmsiPnJsYkBp cHYuc3g8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNpbmNlIHBlb3BsZSBkb24ndCBzZWVtIGhhcHB5 IGFib3V0IGVpdGhlciBvZiB0aGVzZSBhbHRlcm5hdGl2ZXMgKGlkZW50aWZpZXJzJiM0MztDU1Ig YmVjYXVzZSBvZiBsZWdhY3kgaXNzdWVzOyBDU1ImIzQzO0NTUiBiZWNhdXNlIG9mIGZyYWdpbGl0 eSksIGhlcmUncyBvbmUgbGFzdCBhdHRlbXB0IGF0IGEgZGlmZmVyZW50IGFwcHJvYWNoOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ MS4gQWRkIGFuIGVycm9yIGNvZGUgZm9yIG5ldy1vcmRlciwgc2F5ICZxdW90O2F1dGhvcml6YXRp b25GaXJzdCZxdW90Oywgd2hpY2ggbWVhbnMgJnF1b3Q7SSBvbmx5IGFjY2VwdCBvcmRlcnMgd2l0 aCBhbGwgYXV0aHogZnVsZmlsbGVkOyBnbyBhbmQgZG8gdGhlc2UgYXV0aHogYW5kIHRoZW4gc3Vi bWl0IG5ldy1vcmRlciZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Mi4gV2hlbiB5b3Ugc2VuZCBhbiAmcXVvdDthdXRob3JpemF0aW9uRmly c3QmcXVvdDsgZXJyb3IsIHlvdSBNVVNUIHNlbmQgYXV0aG9yaXphdGlvbnMgZm9yIHRoZSBjbGll bnQgdG8gY29tcGxldGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+My4gQWRkIGEgbm90ZSB0aGF0IHRoZSBzZXJ2ZXIgTUFZIGRlbGF5IGlzc3VhbmNlIHVudGls IGl0IHJlY2VpdmVzIHRoZSBmaXJzdCBHRVQgcmVxdWVzdCB0byB0aGUgY2VydGlmaWNhdGUgVVJM PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo aXMgaXMgYmFzaWNhbGx5IGVxdWl2YWxlbnQgdG8gdGhlIENTUiYjNDM7Q1NSIHByb3Bvc2FsIGZy b20gdGhlIHNlcnZlciBQT1YsIGJ1dCBub3cgdGhlcmUncyBubyBmb3JtYWwgcmVsYXRpb25zaGlw IGJldHdlZW4gdGhlIHR3byBDU1JzICh0aGV5J3JlIGluZGVwZW5kZW50IG9yZGVycyksIHNvIHlv dSBkb24ndCBoYXZlIHRvIHdvcnJ5IGFib3V0IHdoYXQgaGFwcGVucyBpZiB0aGV5J3JlIGRpZmZl cmVudC4mbmJzcDsgSXQNCiBhbHNvIHJlbW92ZXMgdGhlIGF1dGhlbnRpY2F0aW9uIG9uIHRoZSAm cXVvdDtmaW5hbGl6ZSZxdW90OyBzdGVwIChyZXBsYWNpbmcgaXQgd2l0aCBhIEdFVCksIGJ1dCBJ IGRvbid0IHRoaW5rIHdlIGhhZCBoZWFyZCBhIHJlYXNvbiBmb3IgdGhlIGF1dGhlbnRpY2F0aW9u IGFueXdheS4mbmJzcDsgRnJvbSBhIGNsaWVudCBwZXJzcGVjdGl2ZSwgaXQgYWRtaXRzIGEgcHJl dHR5IHNpbXBsZSBmbG93OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IGEuIFN1Ym1pdCBuZXctb3JkZXIgPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgYi4gSWYg cmVzcG9uc2UgaXMgMlhYIG9yIGF1dGh6TmVlZGVkLCBnbyBkbyB0aGUgYXV0aHo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBjLiBJZiB5 b3UgZ290IGF1dGh6TmVlZGVkLCByZS1zdWJtaXQgbmV3LW9yZGVyOyBlbHNlIHBvbGwgb3JkZXIg dW50aWwgY2VydCBVUkwgc2hvd3MgdXA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBkLiBQb2xsIGNlcnQgVVJMPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RHJhZnQgUFI6 IDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9pZXRmLXdnLWFjbWUvYWNtZS9wdWxsLzM1MCIg dGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9naXRodWIuY29tL2lldGYtd2ctYWNtZS9hY21lL3B1 bGwvMzUwPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JbiBhbnkgY2FzZSwgaXQgd291bGQgYmUgaGVscGZ1bCBpZiBwZW9wbGUgY291bGQg cHJvdmlkZSB0aG91Z2h0cyBvbiB3aGljaCBvZiB0aGUgdGhyZWUgb3B0aW9ucyB0aGV5IHByZWZl ciBoZXJlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4xLiBJZGVudGlmaWVycyAmIzQzOyBDU1IgKDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNv bS9pZXRmLXdnLWFjbWUvYWNtZS9wdWxsLzM0MiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0 aHViLmNvbS9pZXRmLXdnLWFjbWUvYWNtZS9wdWxsLzM0MjwvYT4pPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBDU1IgJiM0MzsgQ1NSIChzYW1l LCBidXQgd2l0aCBhIENTUiBpbnN0ZWFkIG9mIGlkZW50aWZpZXJzKTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My4gPHNwYW4gY2xhc3M9Im0tNjM3 MTYxOTU2MDIwMjcwODU1N2dtYWlsLXBsLXMiPmF1dGhvcml6YXRpb25GaXJzdCAoPGEgaHJlZj0i aHR0cHM6Ly9naXRodWIuY29tL2lldGYtd2ctYWNtZS9hY21lL3B1bGwvMzUwIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly9naXRodWIuY29tL2lldGYtd2ctYWNtZS9hY21lL3B1bGwvMzUwPC9hPik8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlBlcnNvbmFsbHksIG15IGN1cnJlbnQgcHJlZmVyZW5jZSBpcyBmb3IgKDMpLCBiZWNhdXNl IGl0IHNlZW1zIGxpa2UgdGhlIGxlYXN0IGNvbXBsZXggLyBlcnJvciBwcm9uZSB3YXkgdG8gc3Vw cG9ydCBib3RoIGJhY2stZW5kIGNhc2VzIChDU1IgZmlyc3QgLyBDU1IgbGFzdCkuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tUmljaGFy ZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gV2VkLCBOb3YgOCwgMjAxNyBhdCA5OjA1IEFNLCBEYW5pZWwgTWNDYXJuZXkg Jmx0OzxhIGhyZWY9Im1haWx0bzpjcHVAbGV0c2VuY3J5cHQub3JnIiB0YXJnZXQ9Il9ibGFuayI+ Y3B1QGxldHNlbmNyeXB0Lm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPkhpIElsYXJpLDxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPkkgZ3Vlc3MgaWYgeW91IGZp bmQgYW55IHVzZSBmb3IgdGhlIGtleSBhdCBhbGwgZGVwZW5kcyBvbiBpZiZuYnNwO2F1dGhvcml6 YXRpb25zIGFyZSBvcmRlci1zY29wZWQgb3IgYWNjb3VudC1zY29wZWQuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KU2VlIHRoaXMgZm9sbG93LXVwIHRocmVhZFsw XSAtIGl0IHNlZW1zIGxpa2UgJnF1b3Q7c2NvcGUmcXVvdDsgb24gb3JkZXJzIGlzIHVubmVjZXNz YXJ5ICZhbXA7IGNvbmZ1c2luZy4gSSB2b3RlIGl0IGJlIHJlbW92ZWQgYW5kIFJpY2hhcmQgQmFy bmVzIHNlZW1zIHRvIGJlIHN1cHBvcnRpdmUgb2YgdGhhdC48bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0 Ij5UaGVyZSBpcyBhdCBsZWFzdCBvbmUgbWV0aG9kIGluICZxdW90OzEwJm5ic3A7bWV0aG9kcyZx dW90OyB0aGF0IGFic29sdXRlbHkgcmVxdWlyZXMgdGhlIGtleSB0byBiZSBrbm93biAobnVtYmVy IDkpLiZuYnNwO0Fsc28sIGlmIHRoZSB2YXJpYW50IG9mIHRoZSB2YWxpZGF0aW9uIG1ldGhvZCB1 c2VzIHRoZSBrZXksIGl0IGRvZXMmbmJzcDtub3Qgc2VlbSBzYWZlIHRvIHJldXNlIGl0IGZvciBk aWZmZXJlbnQNCiBrZXkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KQ2FuIHlvdSBjaXRlIHRoZSBzcGVjaWZpYyBjaGFsbGVu Z2UgbWV0aG9kIHlvdSBtZWFuIChvciB0aGUgc2VjdGlvbiBvZiB0aGUgYmFzZWxpbmUgcmVxdWly ZW1lbnRzKSAtIEkgZG9uJ3Qga25vdyB3aGljaCBzcGVjaWZpYyB2YWxpZGF0aW9uIG1ldGhvZCB5 b3UncmUgcmVmZXJyaW5nIHRvLjxicj4NCjxicj4NCk1vcmUgYnJvYWRseTogQUNNRSBkZWZpbmVz IGEgbnVtYmVyIG9mIHZhbGlkYXRpb24gY2hhbGxlbmdlIG1ldGhvZHMuIEl0IGRvZXMgbm90IGRl ZmluZSBhIHZhbGlkYXRpb24gbWV0aG9kIGJhc2VkIG9uIHVzaW5nIHRoZSBwdWJsaWMga2V5IGZy b20gYSBDU1IuIFVzaW5nIHVuc3BlY2lmaWVkIGNoYWxsZW5nZSB0eXBlcyBhcyBhbiBhcmd1bWVu dCBmb3Igd2h5IHRoZSBDU1Igc2hvdWxkIGJlIHN1Ym1pdHRlZCBlYXJseSBkb2Vzbid0IHNlZW0g dmVyeQ0KIGNvbnZpbmNpbmcgdG8gbWUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ V2hhdCBpcyB0aGUgcmF0aW9uYWxlIGZvciBuZWVkaW5nIHN1Y2ggYSBjaGFsbGVuZ2UgdHlwZT8N Cjxicj4NCldoYXQgcHJvYmxlbXMgZG9lcyB0aGlzIGNoYWxsZW5nZSB0eXBlIHJlc29sdmUgdGhh dCBhcmUgbm90IHJlc29sdmVkIGJ5IHRoZSBjdXJyZW50IGNoYWxsZW5nZSB0eXBlcz8NCjxicj4N CkRvIHlvdSBvciBhbnkgb3RoZXIgQUNNRSBzZXJ2ZXJzIGhhdmUgaW50ZXJlc3QgaW4gc3BlY2lm eWluZyAmYW1wOyBpbXBsZW1lbnRpbmcgc3VjaCBhIGNoYWxsZW5nZSB0eXBlPzxicj4NCjxicj4N CkknbSBleHRyZW1lbHkgaGVzaXRhbnQgdG8gbWFrZSBkZXNpZ24gZGVjaXNpb25zIGJhc2VkIG9u IGFsbG93aW5nIGZvciB2ZXJ5IG9wZW4tZW5kZWQgZmVhdHVyZXMgaW4gdGhlIGZ1dHVyZSB3aGVu IHRoZXJlIGlzbid0IGEgc3Ryb25nIGNhc2UgZm9yIHRoZSBmZWF0dXJlIG9yIGFueSBlc3RhYmxp c2hlZCBpbnRlcmVzdCBpbiBpbXBsZW1lbnRpbmcgJmFtcDsgc2hpcHBpbmcgaXQuJm5ic3A7PG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjVwdCI+SWYgb3JkZXJzIGNhbiBsaXZlIG92ZXIgOCBob3VycywgdGhl biBvbmUgTVVTVCBiZSBwcmVwYXJlZCB0byB0YWtlJm5ic3A7cmVqZWN0aW9uIGF0IGZpbmFsaXph dGlvbiBhbnl3YXkuIEJlY2F1c2UgZXZlbiBpZiBDQUEgd2FzIGNoZWNrZWQgYXQmbmJzcDsmbmJz cDthdXRob3JpemF0aW9uIGNyZWF0aW9uLCBpdCBtaWdodCBoYXZlIGJlZW4gY2hhbmdlZCBhbmQg Y29uc2VxdWVudGx5Jm5ic3A7ZmFpbA0KIHRoZSByZWNoZWNrLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClllcywgdGhpcyBp cyBzb21ldGhpbmcgSSBtZW50aW9uZWQgaW4gbXkgcmVwbHlbMV0gdG8gb25lIG9mIHlvdXIgZWFy bGllciBtZXNzYWdlcyBhcyB3ZWxsIGFzIGluIG15IHJlcGx5IHRvIEJyYWQgV2FycmVuWzJdLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIERh bmllbCAvIGNwdTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpb MF0gLSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cv YWNtZS93a1FIMkFxeXBvR25CeWl1Q2ZZZ3EyVUkzbkkiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2FjbWUvd2tRSDJBcXlwb0duQnlpdUNmWWdx MlVJM25JPC9hPiZuYnNwOzxicj4NClsxXSAtJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJj aGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9hY21lL0tFQjNzTFJzd1RUM21fWEliWlNXNTJyM2x4TS8/ cWlkPWFiY2FiYmMzNzI0NDNmYmUzMWM5NTI1NThhYTMzOTJmIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9hY21lL0tFQjNzTFJzd1RUM21fWEli WlNXNTJyM2x4TS8/cWlkPWFiY2FiYmMzNzI0NDNmYmUzMWM5NTI1NThhYTMzOTJmPC9hPjxicj4N ClsyXSAtJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21z Zy9hY21lLy11YW1RNFNQa3hIUl9lc2NocEJTcWtHMS15RSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvYWNtZS8tdWFtUTRTUGt4SFJfZXNjaHBC U3FrRzEteUU8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBOb3YgMiwgMjAxNyBhdCAxMjoxOCBQTSwg SWxhcmkgTGl1c3ZhYXJhICZsdDs8YSBocmVmPSJtYWlsdG86aWxhcmlsaXVzdmFhcmFAd2VsaG8u Y29tIiB0YXJnZXQ9Il9ibGFuayI+aWxhcmlsaXVzdmFhcmFAd2VsaG8uY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g VGh1LCBOb3YgMDIsIDIwMTcgYXQgMTA6Mjk6NThBTSAtMDQwMCwgRGFuaWVsIE1jQ2FybmV5IHdy b3RlOjxicj4NCjxicj4NCiZndDs8YnI+DQomZ3Q7IEkgdW5kZXJzdGFuZCB0aGF0IHRoZXNlIGNv cm5lciBjYXNlcyBhcmVuJ3QgYSBzdXBlciBjb252aW5jaW5nIGxpbmUgb2Y8YnI+DQomZ3Q7IGFy Z3VtZW50LCBidXQgSSBhbHNvIGRvbid0IHRoaW5rIGEgc2xpZ2h0IHByZWZlcmVuY2UgZm9yIGRv dWJsZSBDU1I8YnI+DQomZ3Q7IHN0cmljdGx5IGJlY2F1c2UgaXQgYWxsb3dzIGRlbGl2ZXJpbmcg YSBwdWJsaWMga2V5IHJlamVjdGlvbiBlcnJvciBzbGlnaHRseTxicj4NCiZndDsgZWFybGllciBp biB0aGUgb3JkZXIgZmxvdyBpcyBhIHZlcnkgY29udmluY2luZyBhcmd1bWVudCBlaXRoZXIuIERv ZXM8YnI+DQomZ3Q7IHNvbWVvbmUgaGF2ZSBzb21ldGhpbmcgc3Ryb25nZXIgaW4gbWluZD88YnI+ DQo8YnI+DQpJIGd1ZXNzIGlmIHlvdSBmaW5kIGFueSB1c2UgZm9yIHRoZSBrZXkgYXQgYWxsIGRl cGVuZHMgb24gaWY8YnI+DQphdXRob3JpemF0aW9ucyBhcmUgb3JkZXItc2NvcGVkIG9yIGFjY291 bnQtc2NvcGVkLjxicj4NCjxicj4NCklmIGF1dGhvcml6YXRpb25zIGFyZSBvcmRlci1zY29wZWQs IHRoZW4gdGhlIGtleXMgY291bGQgYmUgdXNlZCBmb3I8YnI+DQphZGRpdGlvbmFsIHZhbGlkYXRp b24gbWV0aG9kcy4uLiBUaGVyZSBpcyBhdCBsZWFzdCBvbmUgbWV0aG9kIGluICZxdW90OzEwPGJy Pg0KbWV0aG9kcyZxdW90OyB0aGF0IGFic29sdXRlbHkgcmVxdWlyZXMgdGhlIGtleSB0byBiZSBr bm93biAobnVtYmVyIDkpLjxicj4NCkFsc28sIGlmIHRoZSB2YXJpYW50IG9mIHRoZSB2YWxpZGF0 aW9uIG1ldGhvZCB1c2VzIHRoZSBrZXksIGl0IGRvZXM8YnI+DQpub3Qgc2VlbSBzYWZlIHRvIHJl dXNlIGl0IGZvciBkaWZmZXJlbnQga2V5Ljxicj4NCjxicj4NCklmIG9yZGVycyBjYW4gbGl2ZSBv dmVyIDggaG91cnMsIHRoZW4gb25lIE1VU1QgYmUgcHJlcGFyZWQgdG8gdGFrZTxicj4NCnJlamVj dGlvbiBhdCBmaW5hbGl6YXRpb24gYW55d2F5LiBCZWNhdXNlIGV2ZW4gaWYgQ0FBIHdhcyBjaGVj a2VkIGF0PGJyPg0KYXV0aG9yaXphdGlvbiBjcmVhdGlvbiwgaXQgbWlnaHQgaGF2ZSBiZWVuIGNo YW5nZWQgYW5kIGNvbnNlcXVlbnRseTxicj4NCmZhaWwgdGhlIHJlY2hlY2suPGJyPg0KPHNwYW4g c3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJtLTYzNzE2MTk1 NjAyMDI3MDg1NTdnbWFpbC1tODIwODg3NjUyNjk1NDU2MzAyNW00NzM3OTE1MTM2MzY2MTM1MTkx aG9lbnpiIj4tSWxhcmk8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5d84e71c34624c4ebfb46053d02ab2c0Buypgvkex01intrabuypass_-- From nobody Sun Nov 12 04:12:26 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 2CC6712940E; Sun, 12 Nov 2017 04:12:18 -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.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151048873813.30898.2416784914901502271@ietfa.amsl.com> Date: Sun, 12 Nov 2017 04:12:18 -0800 Archived-At: Subject: [Acme] I-D Action: draft-ietf-acme-star-01.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 12:12:18 -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 : Support for Short-Term, Automatically-Renewed (STAR) Certificates in Automated Certificate Management Environment (ACME) Authors : Yaron Sheffer Diego Lopez Oscar Gonzalez de Dios Antonio Agustin Pastor Perales Thomas Fossati Filename : draft-ietf-acme-star-01.txt Pages : 17 Date : 2017-11-12 Abstract: This memo proposes an ACME extension to enable the issuance of short- term and automatically renewed certificates. [RFC Editor: please remove before publication] While the draft is being developed, the editor's version can be found at https://github.com/yaronf/I-D/tree/master/STAR. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-acme-star/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-acme-star-01 https://datatracker.ietf.org/doc/html/draft-ietf-acme-star-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-star-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Nov 12 13:23:41 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 0840A126B7F; Sun, 12 Nov 2017 13:23:39 -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.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151052181895.30872.514171055267675676@ietfa.amsl.com> Date: Sun, 12 Nov 2017 13:23:39 -0800 Archived-At: Subject: [Acme] I-D Action: draft-ietf-acme-email-tls-02.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 21:23:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Automated Certificate Management Environment WG of the IETF. Title : Extensions to Automatic Certificate Management Environment for email TLS Author : Alexey Melnikov Filename : draft-ietf-acme-email-tls-02.txt Pages : 7 Date : 2017-11-12 Abstract: This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for use by TLS email services. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-acme-email-tls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-acme-email-tls-02 https://datatracker.ietf.org/doc/html/draft-ietf-acme-email-tls-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-email-tls-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Nov 12 13:33:29 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA1A1267BB for ; Sun, 12 Nov 2017 13:33:28 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYi-Kie60Y0v for ; Sun, 12 Nov 2017 13:33:26 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 57B08124F57 for ; Sun, 12 Nov 2017 13:33:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1510522405; d=isode.com; s=june2016; i=@isode.com; bh=aM6wzEmJCFfjV1p9I6MmbPK3dbvrfOLtWaO+QXNiSVo=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Nz8OeGcRYrPkss5RDoMnZgGd4qbpTYpKJxYDDBvGIbP0JQqWjrbY0+8LGrnRxTHgUHqqWl HDgyMlfPVGywbw5Hpd1mB2/xmZYYvobAE/RnAYSSRFRVuoceO859pAE2D/5Ay2BBXrHxnB iSPK5PbuGfaKF6ZV3OKo0kXNm3ywY08=; Received: from [192.168.31.83] ((unknown) [42.61.208.15]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 12 Nov 2017 21:33:24 +0000 X-SMTP-Protocol-Errors: NORDNS References: <151052181895.30872.514171055267675676@ietfa.amsl.com> To: acme@ietf.org From: Alexey Melnikov Message-ID: <5A08BE22.2080204@isode.com> Date: Mon, 13 Nov 2017 05:33:22 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: <151052181895.30872.514171055267675676@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] I-D Action: draft-ietf-acme-email-tls-02.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 21:33:28 -0000 On 13/11/2017 05:23, internet-drafts@ietf.org 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 : Extensions to Automatic Certificate Management Environment for email TLS > Author : Alexey Melnikov > Filename : draft-ietf-acme-email-tls-02.txt > Pages : 7 > Date : 2017-11-12 > > Abstract: > This document specifies identifiers and challenges required to enable > the Automated Certificate Management Environment (ACME) to issue > certificates for use by TLS email services. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-acme-email-tls/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-acme-email-tls-02 > https://datatracker.ietf.org/doc/html/draft-ietf-acme-email-tls-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-email-tls-02 In this version I corrected some typos, added a reference to RFC 7817 and elaborated on various open issues. From nobody Sun Nov 12 19:56: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 A80BF12944B for ; Sun, 12 Nov 2017 19:56:01 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyBiXll54ELO for ; Sun, 12 Nov 2017 19:56:00 -0800 (PST) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 044091293FF for ; Sun, 12 Nov 2017 19:56:00 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id z184so6375806pgd.13 for ; Sun, 12 Nov 2017 19:55:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=/dcVo8gOo0ZcnGZDJpSJdEGFDB3G846ZBUoaBByMn8g=; b=tNJ4lXT0F4w0vV+ZRgighs7WuT/dJPNgrKkLX7aj9qqpRAK2KY9gPcDJ+PCpjO6+6C qTMxs32Z5adTEgmd63S8WzQ+PxCxOpaJodAzPrHVe7xtEpS1XwrdOfQhMFiST6nliMUx HanXKvqnfnW5ebZxgvqmdaZ/gouWCb6iwil0psmBHVnowh5IyeQ7vutVoTamexlIGhVU FBa1jyjE+SVtSdVJija9iIgVNqFgEGyg04hn8K+p9ANNjt0nXFw91Qkle73obB3h2pVU VYWrWuy8Ebt9TMA2fudUaA1Gm+3vzaOMApZ9HOV942827fUFJCqjemHCB5R0H6S/ht1F VRnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=/dcVo8gOo0ZcnGZDJpSJdEGFDB3G846ZBUoaBByMn8g=; b=QiOCz7LdfiGp3NL6uQbvYXEVd5UJT1VEUVPxdZdK4ZMb0f5TkGCr/OH/Q7JxaBreS5 8n0GQKTEcHaphr0f6tbG+AQ45OsOreV0Pgkoff8dAn0RT18FIbDkLtZTKV3fnuTeScyQ K/C7mIio0HtdPRFzT5jmVtId7Fm7TJuze/wDQzSygcdapFoB+TEtP/WHhrItmUo+yiat iYTL3uhxDdRwLvMPIJCojqV9W7/HU7mFQ4khb9khfvfwZOMhSN59MlwcEZQ5mqyki6CQ qjE5pl+GCTE6Y8mrYdBlvo/N9+DIqFbBzRQqsTBMAdehhhLltA1HueB77pUXv33TzYj3 3LkQ== X-Gm-Message-State: AJaThX5eatSRD5ROt9114EdmmPTz70Zz701EcZESkvV79Hf50jFhqR4g P/ZfRGRmhZqjbenVHIOw0jf0CUut X-Google-Smtp-Source: AGs4zMbbwVD3TIlq8ILv0yrGpE/qp9AXGr8D3+VJew2M3cFUSYGjekAM5XSoW8984pKd7UebT4Hjew== X-Received: by 10.99.172.88 with SMTP id z24mr7600703pgn.46.1510545359455; Sun, 12 Nov 2017 19:55:59 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:a40a:d302:10d8:a1b3? ([2001:67c:370:128:a40a:d302:10d8:a1b3]) by smtp.gmail.com with ESMTPSA id b10sm7138068pfj.20.2017.11.12.19.55.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 19:55:58 -0800 (PST) From: Yoav Nir Content-Type: multipart/signed; boundary="Apple-Mail=_C25F99FB-3456-4DB3-ADA4-8B68917A18F4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Message-Id: Date: Mon, 13 Nov 2017 11:56:26 +0800 To: IETF ACME X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: [Acme] Slides for the meeting tomorrow X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 03:56:01 -0000 --Apple-Mail=_C25F99FB-3456-4DB3-ADA4-8B68917A18F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi. Those people presenting tomorrow who have not yet sent us the slides, = please do so today. You know who you are. Thanks, Rich and Yoav --Apple-Mail=_C25F99FB-3456-4DB3-ADA4-8B68917A18F4 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----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAloJF+oACgkQuEkLFQpY zJmqMQf/eotWvlL6pK4d8NZ0U8+Ha4eYpkm0SMcTaow4aBG8uotoJikzqQYzt271 aDy6N2LYPV4NhNnDcV4enFjKbcjEpFDuZWJsKzuzJ2TGsgd4FSiHznehVXj+uaWk X48N9z4WRHWBxgauX03yd2R/RTFEbphCWw4DPY2dUrLBBVfpMOf9gU8vRXk22gJS Ig+/SGePOiGqbZZSH9eNy+LpZ2jBYhAta/+P37fA7x2tFqdx1PwBH8q6ihHBnPZ+ 5ELVgTTaekle92wXrhLStL+1+KDrXW7HXPO/tKhXWRrZYV2ZWlhlC5XYNFlcwFer RYY1bcaW7PcwlFJxocOdfZSnPBIU7w== =1s4q -----END PGP SIGNATURE----- --Apple-Mail=_C25F99FB-3456-4DB3-ADA4-8B68917A18F4-- From nobody Sun Nov 12 21:07:49 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6786F124B0A for ; Sun, 12 Nov 2017 21:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MjRjy99XXll for ; Sun, 12 Nov 2017 21:07:44 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3697B127078 for ; Sun, 12 Nov 2017 21:07:44 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id j202so7418748qke.10 for ; Sun, 12 Nov 2017 21:07:44 -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=YfWi8HD1hqehkfEWAJULiCGAowHzHrkby4aELKB3fmY=; b=JLEOUSUj1QVinRLvaRZyn7NchmSdj3NLSVfUM+5tVYaEe/ZJpJWqZWOUtcG+e5nJ+S Rr4QnpNYhOrkrl4LxkxwhKL+b5taxpd7Q19G2G+rTbx85Y2DHp7J4tPwUm4qSjhpp4OK pZ2XuL/s9Qp1Eu2yER7TyhKYl7wBW+sFquPHNzEKmni+Kk/CDnEe5SVQqCbvgXE9ZiMW iyFF0yCQYakFX6TiGqfNs6sCLzGK3BT2/z0pi0IOjdW0Yp7HF2pUKz2Z/l0KWGW6eeXJ bgudjMmLX5rjrUy7rfDS7sAIv7tvJ2PjzIFxrtOWQIOGTWlcKQF/Og6CRYGP6R+aVIWK JISw== 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=YfWi8HD1hqehkfEWAJULiCGAowHzHrkby4aELKB3fmY=; b=ezOQwZf7HgSwh/YDsEGtf6eevPSxQGVsbrLC3CO0V7tjhmPHZO1EVX9xj6wlKeDQ4t L0SYhssP0eVyuJe2D/0ct0BiOF/At1aaJ7nInl227h/g8XweGu7gyFoFlJwHGZMsww0q p2B66C2Vd+U9zjqes+j2fSU/m0QDCt4NZQkbA8mCuZbGT920mW4eUTNJsKWzbzriV/fQ q8t8Y2WuauI0iPkSZmr3+ss5FIVlxZTgaqHHmta2MV6zzYV61C3Gyl9OatS84Cz04FEu UvGbDmCTbMxmPEY5hHgO4SdNsqkcJvbrISFXOe/+U2Grv7GfN/VG8y0i4LcHPd5CXQBg zZOQ== X-Gm-Message-State: AJaThX6d9BTzT1ZVwOE6F4Sb5MpoXl3i7uRJWnl25WrdA4jTl21NJUPj nRRLxcICcl1+DloTUlGlFtA7j/ka6bs7XUpx1hg= X-Google-Smtp-Source: AGs4zMaEtQS0WxYOm5/3vknzizkAqGvrLwUGSkAYK0Zkcxl2gyEKd9IZfe5TyEFfwqVqya2QhjcVRtUdF4jeM6G+IMw= X-Received: by 10.55.102.207 with SMTP id a198mr4167483qkc.345.1510549663176; Sun, 12 Nov 2017 21:07:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.36.163 with HTTP; Sun, 12 Nov 2017 21:07:42 -0800 (PST) In-Reply-To: References: From: Mary Barnes Date: Sun, 12 Nov 2017 23:07:42 -0600 Message-ID: To: Yoav Nir Cc: IETF ACME Content-Type: multipart/alternative; boundary="94eb2c0571a816dd7f055dd64046" Archived-At: Subject: Re: [Acme] Slides for the meeting tomorrow X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 05:07:48 -0000 --94eb2c0571a816dd7f055dd64046 Content-Type: text/plain; charset="UTF-8" I'm a little confused as I don't see ACME on the agenda until Thursday afternoon. Although, I am working on slides right now. On Sun, Nov 12, 2017 at 9:56 PM, Yoav Nir wrote: > Hi. > > Those people presenting tomorrow who have not yet sent us the slides, > please do so today. > > You know who you are. > > Thanks, > > Rich and Yoav > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --94eb2c0571a816dd7f055dd64046 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm a little confused as I don't see ACME on the a= genda until Thursday afternoon.=C2=A0 =C2=A0Although, I am working on slide= s right now.=C2=A0

On Sun, Nov 12, 2017 at 9:56 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
Hi.

Those people presenting tomorrow who have not yet sent us the slides, pleas= e do so today.

You know who you are.

Thanks,

Rich and Yoav


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


--94eb2c0571a816dd7f055dd64046-- From nobody Sun Nov 12 21:17: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 2808C1270AE for ; Sun, 12 Nov 2017 21:17:02 -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 N8xd7PRQtUWn for ; Sun, 12 Nov 2017 21:17:00 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9859E129451 for ; Sun, 12 Nov 2017 21:17:00 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id z184so6510179pgd.13 for ; Sun, 12 Nov 2017 21:17:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=N99BEaLNr81hOSpMBus9r4OsI24yO/3GEBU6TMBbh4E=; b=Zol/R4dIpKUo2qLNFYoXFHfWQAh8fY4JiEmca76U/dYexql4PvgTJibrS5BkFOViaL f2ECVtALPZpm2LA40MWxOIEsM/YU1rBA2PfPveiIMCj57wOspSbmcv9ExPa9NG5a3eXo F20b/9zv3nY1BX75Ed2Ou8FaUP5uY9qmAG6plhuzgsOVp2GGqazTFEH9FlbwwosJLpvL fYKDyJZVxOgflJj9sTLeNXaqsEhI5qHI2Yasfw174td2/MN1rrBUvF0xsQFxCIQ4SbBa LADai4DzOGvLk8P03SrO9s8gqED3jurkvSFlz37gYd0D6wY4GO+FjsOkywMKR4BKcz7O HOvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=N99BEaLNr81hOSpMBus9r4OsI24yO/3GEBU6TMBbh4E=; b=ME3ofVA7rTc4NBfqMWlTJXsRrdcmxbbY0t87wX1EXJsn2KvWmaPlIwZZe/PwhOZvI7 CX3HTmSpOdeU6kWTYoF1W3kmJ9H59/46KMOS2+6GGFzS4ItPVSnC+4kjNlQ1vxFCfjWT WdvJOY9BIt23QxVcU6ot/d3Mpu6Ep0x/RoZURmWYFVVYSA/GeM8uEahTBk5ja/6nZqqU 5Cytb42HPhuakAv0RzRvarABY12m3cqNgv6MHm/ljmU18D2uYQhRvy2eeZou0vFfuJ1h JoDLq3DaFucABgb+hG4NqvWQuONIV4zJd8DKea5vVv5UTqfOfEuHLMxdZ76Plc19X0U2 ru8Q== X-Gm-Message-State: AJaThX4J8eGKQdQcwTAy3MX9120oGz4cgBAWpM3XR7e6kpwJMDqnKyYr Zh0X147YegO3cTLx03PsTOGnGCm+ X-Google-Smtp-Source: AGs4zMbaSho0OWJiqlnqIFRou+iGqVhcMSK4sWsirGqPrl70ZVsrhL6ge8l49M/ulAkW0zayl8Q3ZQ== X-Received: by 10.98.130.4 with SMTP id w4mr6110812pfd.238.1510550220250; Sun, 12 Nov 2017 21:17:00 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:9dae:10ae:d5d2:e685? ([2001:67c:370:128:9dae:10ae:d5d2:e685]) by smtp.gmail.com with ESMTPSA id a78sm23297304pfl.155.2017.11.12.21.16.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 21:16:59 -0800 (PST) From: Yoav Nir Message-Id: <9ACBC571-15ED-48F2-9AFB-38351601EDA2@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_BB2E9690-7E5A-4727-A099-C29611CCAC36"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Mon, 13 Nov 2017 13:17:27 +0800 In-Reply-To: Cc: IETF ACME To: Mary Barnes References: X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: [Acme] Slides for Thursday (was Re: Slides for the meeting tomorrow) X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 05:17:02 -0000 --Apple-Mail=_BB2E9690-7E5A-4727-A099-C29611CCAC36 Content-Type: multipart/alternative; boundary="Apple-Mail=_50350BCF-FEAA-44DB-B6E5-55F81D5CF14D" --Apple-Mail=_50350BCF-FEAA-44DB-B6E5-55F81D5CF14D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yeah. Sorry about that. The meeting is on Thursday. Thanks > On 13 Nov 2017, at 13:07, Mary Barnes = wrote: >=20 > I'm a little confused as I don't see ACME on the agenda until Thursday = afternoon. Although, I am working on slides right now. >=20 > On Sun, Nov 12, 2017 at 9:56 PM, Yoav Nir > wrote: > Hi. >=20 > Those people presenting tomorrow who have not yet sent us the slides, = please do so today. >=20 > You know who you are. >=20 > Thanks, >=20 > Rich and Yoav >=20 >=20 > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme = >=20 >=20 --Apple-Mail=_50350BCF-FEAA-44DB-B6E5-55F81D5CF14D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Yeah.= Sorry about that. The meeting is on Thursday.

Thanks


On 13 Nov 2017, at 13:07, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

I'm a little confused as I don't see ACME on the agenda until = Thursday afternoon.   Although, I am working on slides right = now. 

On Sun, Nov 12, 2017 at 9:56 PM, Yoav Nir <ynir.ietf@gmail.com> = wrote:
Hi.

Those people presenting tomorrow who have not yet sent us the slides, = please do so today.

You know who you are.

Thanks,

Rich and Yoav


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



= --Apple-Mail=_50350BCF-FEAA-44DB-B6E5-55F81D5CF14D-- --Apple-Mail=_BB2E9690-7E5A-4727-A099-C29611CCAC36 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----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAloJKucACgkQuEkLFQpY zJnD9Qf9GcjWb5x3w43XWMKDdMGiPfBdTZ0GDCFr4GlbUMhBbbIjGVl3zPOndIXw WK+mNQtz/06AOBgnuCkSrJBxeEN2VCy4E7nZw7uuVgrFD4I3yfcPyCVhfT18jPaf 5cS66QWajlEJjyNReba2sM05mUa8I/Y/Zw1SMtRDrIP6Mzuk3xM1UYEiWwWaIjfF HJ9fSo1S4DihVdcY71uNfhrn0aYEuEZB4tUy66s4mdzbFmH5aiksmlzulyZkY+m5 LvtlS+9vBwoQhmc7tBUnjzYgvgsqrRlR7/+ZkAwhuOkr0K4hqDHrAHxxjNxxBNNm SPxss2Bp/xpkeBno3zE1dWblG/HR7A== =ATme -----END PGP SIGNATURE----- --Apple-Mail=_BB2E9690-7E5A-4727-A099-C29611CCAC36-- From nobody Mon Nov 13 02:31: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 DED601273B1 for ; Mon, 13 Nov 2017 02:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 NI0pSbcpuiB6 for ; Mon, 13 Nov 2017 02:31:47 -0800 (PST) Received: from dns2.sebbe.eu (dns2.sebbe.eu [IPv6:2001:470:dff1:1:10::2]) (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 6913E124BE8 for ; Mon, 13 Nov 2017 02:31:47 -0800 (PST) Received: from linuxlite-desktop (localhost [127.0.0.1]) by dns2.sebbe.eu (Postfix) with ESMTP id 5EEFE76021B for ; Mon, 13 Nov 2017 11:31:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sebbe.eu; s=root; t=1510569105; bh=Y9iPRL49PV+cTfODqz0xtqSYqPaldw+sSxFVBddBxsU=; h=Date:From:To:Subject:From; b=yuxPbC/zkpuL8ETTs7xlmSMZLR8PlBBiGpZma6cquf3NY0LPEexRzRyIhtv8Ff8Tb ee78AbdoOrI5iDB1N0bO2+Wd5PPb6gPKRiF9BWDYgWfOuoHGp/Ygga8GEGz8t0b9ZD orvoZUCBVm9SPwkMOQIPZ5FE5FABxf61NaM9v3G8= Received: from DESKTOPA8GMOTG (unknown [192.168.4.100]) by dns1.sebbe.eu (Postfix) with ESMTP id 9310D76021B for ; Mon, 13 Nov 2017 11:31:44 +0100 (CET) Date: Mon, 13 Nov 2017 11:31:49 +0100 From: "Sebastian Nielsen" To: Message-ID: <001501d35c6a$9d480d30$d7d82790$@sebbe.eu> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_24_1418191692.1510569105340" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdNcafgoeBEkuj7vScqMZJnp2GRXGQ== Archived-At: Subject: [Acme] One suggestion for ACME, and also one question about CAA X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 10:31:49 -0000 ------=_Part_24_1418191692.1510569105340 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01D35C72.FF0CEA60" Content-Language: sv This is a multipart message in MIME format. ------=_NextPart_000_0016_01D35C72.FF0CEA60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit First, I want to make a suggestion, and that is possibility for a permanent domain authorization. The CABF says that it is permitted to use SPKI hash or CSR hash as authentication token, without any nonce. Since SPKI hash is static for the same public key, and the CSR hash is static if you use the same CSR all the time, it would be permitted as a pre-authorization. Thus avoiding a unnecessary restart of the name server each renew. This could be combined with that the CAA record must specify that permanent authorization is permitted for that host. An question about CAA: Why was it decided to use a new record type of CAA instead of using TXT? Using TXT to convey policies has been something that have been in use for a long time, for example "v=spf1 +mx -all". Same with SMTP-STS. The main problem of introducing new record types is that DNS providers & web hosts need to implement support for these, both in their DNS servers and/or their web interfaces. Using TXT for this, example: "v=caa1; f=128; t=issue; d=letsencrypt.org ;", gives the same advantages, but also the advantage that any DNS operator supporting TXT, will also support the new policy. the record type 99 (SPF) was depreciated for this very reason. ------=_NextPart_000_0016_01D35C72.FF0CEA60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

First, I want to make a suggestion, and that is = possibility for a permanent domain authorization.

The CABF says that it is permitted to use SPKI hash or = CSR hash as authentication token, without any nonce.

Since SPKI hash is static for the same public key, and = the CSR hash is static if you use the same CSR all the time, it would be = permitted as a pre-authorization.

 

Thus = avoiding a unnecessary restart of the name server each = renew.

 

This could be combined with that the CAA record must = specify that permanent authorization is permitted for that = host.

 

 

An question = about CAA:

Why was it decided to use = a new record type of CAA instead of using TXT?

Using TXT to convey policies has been something that = have been in use for a long time, for example “v=3Dspf1 +mx = -all”.
Same with SMTP-STS.

The main problem of introducing new record types is = that DNS providers & web hosts need to implement support for these, = both in their DNS servers and/or their web interfaces.

Using TXT for this, example: “v=3Dcaa1; f=3D128; = t=3Dissue; d=3Dletsencrypt.org;”, = gives the same advantages, but also the advantage that any DNS operator = supporting TXT, will also support the new policy.

the record type 99 (SPF) was depreciated for this very = reason.

------=_NextPart_000_0016_01D35C72.FF0CEA60-- ------=_Part_24_1418191692.1510569105340 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 oIIBCjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzExMTMxMDMx NDVaMC8GCSqGSIb3DQEJBDEiBCBHdNpuzlYeV0abSL5WNcSo6ZpYuH84eRZlmBhhdiPk2TCBngYJ KoZIhvcNAQkPMYGQMIGNMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAPBgkqhkiG9n0HQgoCAgCAMA0GCyqDCIyaSz0BAQEE MA0GCyqDCIyaSz0BAQEDMA0GCyqDCIyaSz0BAQECMAoGCCqDGoyaRAEEMA0GCSqGSIb3DQEBAQUA BIIBACLWRK4JTVT089kzgPLOnNYnk7nBDddrN6veuhIMWKSezdnOJ9V6MRzYmCo2GP9QHk8LQ7mU H8jiMByloO0mkqJxhUP33VB83Hh2HNRldiUKCw4imMFl1xSmbIGp7N42KdlBw9H3QZ/ZKnQBIlfi ND9RSsY+Trw/F8x1XWTFpPOintKooxVUBqIqju+Qt82V1e6r+JV6XUZzWeWFVrd5kqgwOlQA2xeI dJJBl7x+iooLK5aKlwvYnLoEhEI5d8u5B8qBSxojTncWBrV84RJwpPCdGD1Xm+UGqn+0p+l2i5BE pYL643aOrnxEfLLJJL9oeIZcD8cSyUIHBps2CVmQeFwAAAAAAAA= ------=_Part_24_1418191692.1510569105340-- From nobody Mon Nov 13 03:22: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 34756128D40 for ; Mon, 13 Nov 2017 03:22:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iScocslp4VUk for ; Mon, 13 Nov 2017 03:22:39 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18181127333 for ; Mon, 13 Nov 2017 03:22:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 7C4B997B5F; Mon, 13 Nov 2017 13:22:36 +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-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id oueATc69ciA9; Mon, 13 Nov 2017 13:22:36 +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 2AEBB21C; Mon, 13 Nov 2017 13:22:34 +0200 (EET) Date: Mon, 13 Nov 2017 13:22:34 +0200 From: Ilari Liusvaara To: Sebastian Nielsen Cc: acme@ietf.org Message-ID: <20171113112234.pescn4lqknkpn672@LK-Perkele-VII> References: <001501d35c6a$9d480d30$d7d82790$@sebbe.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <001501d35c6a$9d480d30$d7d82790$@sebbe.eu> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] One suggestion for ACME, and also one question about CAA X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 11:22:41 -0000 On Mon, Nov 13, 2017 at 11:31:49AM +0100, Sebastian Nielsen wrote: > First, I want to make a suggestion, and that is possibility for a permanent > domain authorization. > > The CABF says that it is permitted to use SPKI hash or CSR hash as > authentication token, without any nonce. Such token would be valid for one use only unless timestamped. And even if timestamped, it would be limited to 30 days at most. > Since SPKI hash is static for the same public key, and the CSR hash is > static if you use the same CSR all the time, it would be permitted as a > pre-authorization. The token would still change, see above. > Thus avoiding a unnecessary restart of the name server each renew. Use DNS dynamic updates. There is 20 year old RFC(!) describing one way of doing that. And then there are many DNS-server specific ways. And automating DNS-01 requires such API anyway. If talking about HTTP-01, it does not require server restart/reload in anything I know of. And TLS-SNI-02 is insane without special server support (which presumably eliminates restarts/reloads too). -Ilari From nobody Mon Nov 13 03:32:47 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158A7124BFA for ; Mon, 13 Nov 2017 03:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 pwx7Tvnwrz0H for ; Mon, 13 Nov 2017 03:32:43 -0800 (PST) Received: from dns2.sebbe.eu (dns2.sebbe.eu [185.86.107.140]) (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 24EC21204DA for ; Mon, 13 Nov 2017 03:32:42 -0800 (PST) Received: from linuxlite-desktop (localhost [127.0.0.1]) by dns2.sebbe.eu (Postfix) with ESMTP id 899F77600C2 for ; Mon, 13 Nov 2017 12:32:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sebbe.eu; s=root; t=1510572760; bh=J/fpqZV/50j9ZqZ3AvsVBE/WnPmmY9fslzwMq4t0yEo=; h=Date:From:To:In-Reply-To:References:Subject:From; b=kBoE5C3bTj0FfBjnUDdJLTioRXCcasepBkIGnYPDIWkHGZA3hqh7eY3qKOU9HlaM1 PeoDS/zKLlm7pz85e+sFgNOonLhYt2+W4GZyYAYRklBIhOIX3r8Hl8cA0Wh3kR5Yna zDT09CAoh5qxKgYFhg8yfoKkvzJSDSvAIPXwPQUQ= Received: from DESKTOPA8GMOTG (unknown [192.168.4.100]) by dns1.sebbe.eu (Postfix) with ESMTP id 9BE6E7600C2 for ; Mon, 13 Nov 2017 12:32:39 +0100 (CET) Date: Mon, 13 Nov 2017 12:32:44 +0100 From: "Sebastian Nielsen" To: Message-ID: <000301d35c73$1fe3e5e0$5fabb1a0$@sebbe.eu> In-Reply-To: <20171113112234.pescn4lqknkpn672@LK-Perkele-VII> References: <001501d35c6a$9d480d30$d7d82790$@sebbe.eu> <20171113112234.pescn4lqknkpn672@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_28_1920108990.1510572760505" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJDzQSqF9KSEAOe615e0o13npwOyQIfwuXToiBLwNA= Archived-At: Subject: Re: [Acme] One suggestion for ACME, and also one question about CAA X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 11:32:46 -0000 ------=_Part_28_1920108990.1510572760505 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: sv What I have understand with the 30 day limit, is that the authorization = granted must be granted for a maximum of 30 days. Eg, one token, regardless of if its random or static, may either be = single-use or allow a maximum of 30 days where the system considers = domain as "validated". And a token must either be a random value, the hash of certificate CSR, = or the hash of certificate SPKI. In the CAB forum guidelines version 1.4.5, I don't see something that = require a timestamp, however, they recommend a timestamp in the hash. The idea is that you should be able to automate set up DNS-01 once, and = then is set once for all. -----Ursprungligt meddelande----- Fr=C3=A5n: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com]=20 Skickat: den 13 november 2017 12:23 Till: Sebastian Nielsen Kopia: acme@ietf.org =C3=84mne: Re: [Acme] One suggestion for ACME, and also one question = about CAA On Mon, Nov 13, 2017 at 11:31:49AM +0100, Sebastian Nielsen wrote: > First, I want to make a suggestion, and that is possibility for a=20 > permanent domain authorization. >=20 > The CABF says that it is permitted to use SPKI hash or CSR hash as=20 > authentication token, without any nonce. Such token would be valid for one use only unless timestamped. And even = if timestamped, it would be limited to 30 days at most. > Since SPKI hash is static for the same public key, and the CSR hash is = > static if you use the same CSR all the time, it would be permitted as=20 > a pre-authorization. The token would still change, see above. > Thus avoiding a unnecessary restart of the name server each renew. Use DNS dynamic updates. There is 20 year old RFC(!) describing one way = of doing that. And then there are many DNS-server specific ways. And automating DNS-01 requires such API anyway. If talking about HTTP-01, it does not require server restart/reload in = anything I know of. And TLS-SNI-02 is insane without special server = support (which presumably eliminates restarts/reloads too). -Ilari ------=_Part_28_1920108990.1510572760505 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 oIIBCjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzExMTMxMTMy NDBaMC8GCSqGSIb3DQEJBDEiBCAsWkFtGHPbXC1dIlOvzZ4jdoJXhxMzarVxeaTWZ4xK9DCBngYJ KoZIhvcNAQkPMYGQMIGNMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAPBgkqhkiG9n0HQgoCAgCAMA0GCyqDCIyaSz0BAQEE MA0GCyqDCIyaSz0BAQEDMA0GCyqDCIyaSz0BAQECMAoGCCqDGoyaRAEEMA0GCSqGSIb3DQEBAQUA BIIBAEHBifsTleXUxwpt07KCzAbuuyAAJdua5G3NmeG8W1wY7hov8QoD56tnsPP6qrR25B9xam55 42u93i+ZdI2vAp6gp2TSXR03hoYw1thMRFJUR25D/1Qom6s53tvWFuHrHNakwKPzjsj5RO+24F2u pY+hJeAXaFJdJiuwCyDeoV3c5+Dsnunypxeh0zGy1vNjtbMbNU7teX5moRWdJFK7QzjWuroPReC6 nuNWwRAvvV9qjz+JpaK1zUY6Y4d34N8X+Q9I4cO/UZu9IXE1IErBnxqFP5UmCOuGElWoNy6qzv7N pvNvklllAHVaEhbCVpJ/HK/mKpOy7ov8Oq4s+o/GZqAAAAAAAAA= ------=_Part_28_1920108990.1510572760505-- From nobody Mon Nov 13 03: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 090591293F3 for ; Mon, 13 Nov 2017 03:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5pfbyUQUlv_X for ; Mon, 13 Nov 2017 03:51:46 -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 F3293128D64 for ; Mon, 13 Nov 2017 03:51:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 37646B51BA; Mon, 13 Nov 2017 13:51:44 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id Vr5C88LyIiPi; Mon, 13 Nov 2017 13:51: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-smtp1.welho.com (Postfix) with ESMTPSA id E064DC4; Mon, 13 Nov 2017 13:51:41 +0200 (EET) Date: Mon, 13 Nov 2017 13:51:41 +0200 From: Ilari Liusvaara To: Sebastian Nielsen Cc: acme@ietf.org Message-ID: <20171113115141.aenh56gv7agvyqnk@LK-Perkele-VII> References: <001501d35c6a$9d480d30$d7d82790$@sebbe.eu> <20171113112234.pescn4lqknkpn672@LK-Perkele-VII> <000301d35c73$1fe3e5e0$5fabb1a0$@sebbe.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <000301d35c73$1fe3e5e0$5fabb1a0$@sebbe.eu> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] One suggestion for ACME, and also one question about CAA X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 11:51:48 -0000 On Mon, Nov 13, 2017 at 12:32:44PM +0100, Sebastian Nielsen wrote: > What I have understand with the 30 day limit, is that the authorization granted must be granted for a maximum of 30 days. > Eg, one token, regardless of if its random or static, may either be single-use or allow a maximum of 30 days where the system considers domain as "validated". The technical term used by BR is "Request Token" " Request Token: [...] A Request Token MAY include a timestamp to indicate when it was created. [...] A Request Token that includes a timestamp SHALL remain valid for no more than 30 days from the time of creation. A Request Token that includes a timestamp SHALL be treated as invalid if its timestamp is in the future. A Request Token that does not include a timestamp is valid for a single use and the CA SHALL NOT reuse it for a subsequent validation. [...] " Source: CA/Browser Forum: Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Version 1.5.4, Section 1.6.1: Definitions. And SHALL/SHALL NOT are absolute requirements. I.e. tokens themselves may live for at most 30 days. How long the validations granted can live is actually unclear even to CABForum partipicants. One could interpret that such grants can be at most 30 days for tokens, or one could interpret that such grants can be valid for at most 825 days (the maximum grant lifetime for any method). > The idea is that you should be able to automate set up DNS-01 once, > and then is set once for all. There have been proposals in that direction. However, it would take BR changes. -Ilari From nobody Mon Nov 13 18:12: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 6FA6C129B4D for ; Mon, 13 Nov 2017 18:12:15 -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 44xkNT14iBpA for ; Mon, 13 Nov 2017 18:12:13 -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 29F1B129B75 for ; Mon, 13 Nov 2017 18:12:12 -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=8cHezqFVY5TYMNvY2crf6b2iY/4vgSlAXjEoXbndGEU=; b=yqdGZ3GMNHG6nWQ6lsvpg3swliYjfOteZ5GCNjEP/a4QX6DDLrYQ0gKDssfjywF5XElcjajn98P/3cpzlTJT9P8RRErzxuvm5BjBox1uto+Zlb4kljS362gPDNMfqREw20bNrZ0nKUkMzi3A5AIKzMlqBmyYytzq/2yuicUU65Y=; Received: ; Mon, 13 Nov 2017 18:12:06 -0800 To: Richard Barnes , Daniel McCarney Cc: Brad Warren , Ilari Liusvaara , Hugo Landau , IETF ACME References: <71f3e975-7cee-18cf-2635-80eb13adff12@devever.net> <20171024141732.ufjysx5f73pyc5f4@LK-Perkele-VII> <63029bbd-a9d5-0f30-718a-8d78f76a8e82@eff.org> <20171102161833.pqxnd6ql22k4qiul@LK-Perkele-VII> From: Jacob Hoffman-Andrews Message-ID: Date: Mon, 13 Nov 2017 18:11:49 -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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 02:12:15 -0000 On 11/09/2017 02:18 PM, Richard Barnes wrote: > Since people don't seem happy about either of these alternatives > (identifiers+CSR because of legacy issues; CSR+CSR because of > fragility), here's one last attempt at a different approach: > Draft PR: https://github.com/ietf-wg-acme/acme/pull/350 I think this approach complicates things unnecessarily. My feeling of the list is that CSR+CSR has reasonable support as a compromise solution. Hugo said it's "quite clumsy", and Eric said "seems like a great opportunity for defects." I think we can reduce (but not eliminate) the chance for defects by saying the initial CSR and final CSR MUST be identical; then Let's Encrypt can store a hash (32 bytes) rather than the full hash. I still think identifiers+CSR is better, in particular because what I've heard from a few CAs is that they generally ignore everything in the CSR except the public key, and this approach mirrors that one more closely. But ultimately finding an approach that works well enough is better than stalling out trying to find a solution that everyone finds ideal. From nobody Tue Nov 14 18:50: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 ECF43127863 for ; Tue, 14 Nov 2017 18:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVGGBPbKx0kp for ; Tue, 14 Nov 2017 18:50:01 -0800 (PST) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (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 8FF431292D3 for ; Tue, 14 Nov 2017 18:50:01 -0800 (PST) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-02v.sys.comcast.net with ESMTP id EnlreWWP44HLQEnm4eaOG3; Wed, 15 Nov 2017 02:50:00 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-02v.sys.comcast.net with SMTP id Enm3e02adXN9KEnm4e73IU; Wed, 15 Nov 2017 02:50:00 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id vAF2nwMX024507 for ; Tue, 14 Nov 2017 21:49:58 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id vAF2nwAx024504; Tue, 14 Nov 2017 21:49:58 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: acme@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 14 Nov 2017 21:49:57 -0500 Message-ID: <87d14kuuga.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfLjhEm1qHkHlLV4Y53ESb6hKclyKsRWEwq82gN8PtQOzrFioFfZz30HYtvXmpp4mJPGJKRbS+yLKKBNF1L/bcFHWmvHtw5kQW4IFJxQz1BE+r61hS+/7 OeCv6u+4TqrGAHhhDBfEdD6UO04Cj0q+q08jjMHxJ/4/88EeBSpKkaGu Archived-At: Subject: [Acme] Resend: [Gen-art] Genart telechat review of draft-ietf-acme-acme-07] 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, 15 Nov 2017 02:50:05 -0000 From: Dale Worley To: Date: Tue, 24 Oct 2017 18:55:40 -0700 Archived-At: Subject: [Gen-art] Genart telechat review of draft-ietf-acme-acme-07 Cc: draft-ietf-acme-acme.all@ietf.org, acme@ietf.org, ietf@ietf.org Reviewer: Dale Worley Review result: On the Right Track I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-acme-acme-07 Reviewer: Dale R. Worley Review Date: 2017-10-24 IETF LC End Date: 2017-09-14 IESG Telechat date: 2017-10-26 Summary: This draft is on the right track but has open issues, described in the review. My general impression is that this is a sound piece of work, and apparently one that satisfies a serious practical need. But this draft has a large number of open issues, and really needs a careful, thorough clean-up pass. And until that's done, it's not clear what genuine problems might be lurking. I haven't put in the time I would have liked to, so some of the issues I've detected might prove to be nonexistent. A lot of these issues are simply English usage. The structure of the exposition needs to be improved, including pulling the specialized vocabulary into a glossary, providing overviews of processes whose multiple details are discussed, etc. Some issues are technical slips, like missing required fields in HTTP messages. Some seem to be more substantial technical issues -- What is the versioning and extensibility system? What are the requirements on POST operations that effectively carry no more information than that the operation happens? And one question -- the terms of service agreement -- seems to brush into legal territory. The number and variety of these minor problems suggests that the whole work needs to be thought through more carefully before being frozen. Within that context, I will not attempt to sort these items into categories or rate them on importance, but just list them in order by parts of the text that they relate to. And note that a number of these items are mentioned relative to only one of several places in the text they apply to. ---------------------------------------------------------------------- There's a lot of talk about accounts, but no overview of the lifecycle of an account. Compare to the presentation of the overview of the lifecycle of a certificate request. There should be blanket policies on whether and where non-standard fields can be included by both client and server. Also, there ought to be versioning of Acme itself. Abstract Certificates in PKI using X.509 (PKIX) are used for a number of purposes, the most significant of which is the authentication of domain names. I'm no expert here, but it seems to me that "the authentication of domain names" is not correct -- only actors can be authenticated. I think the accurate phrasing is "the authentication of servers (TLS, HTTPS, etc.) which act on behalf of domain names". (This would be a minor matter in the body, especially if this elision was universally used in the field, but an abstract should require little context.) Ditto for the first paragraph of section 1. DISCLAIMER: This is a work in progress draft of ACME and has not yet had a thorough security analysis. I assume that this is going to be removed once this document is published as an RFC. If the RFC hadn't had a thorough security analysis, there would be no value in publishing it as an RFC. However there is no attached statement indicating when this statement is to be removed. What is actually going on here? Table of Contents 6.4. Replay protection 6.4.2. "nonce" (Nonce) JWS header parameter 6.5. Rate limits These section titles aren't capitalized the same way as the other section titles. 1. Introduction Existing Web PKI certificate authorities tend to run on a set of ad hoc protocols for certificate issuance and identity verification. s/run on/use/? a typical user experience is something like: I think you want to broaden this to "a typical protocol is". That doesn't change things much, because the user is one endpoint of the protocol. But you don't want to de-emphasize what the CA does, either. (I reflexively think of this as a protocol problem, whereas the authors probably reflexively think of this as a user experience problem.) * Put a CA-provided challenge at a DNS location corresponding to the target domain. What does "corresponding to" mean? I think you want "in a DNS record for the target domain". * Receive CA challenge at a (hopefully) administrator-controlled email address corresponding to the domain and then respond to it on the CA's web page. s/CA challenge/CA-provided challenge/ for parallelism. s/corresponding to the domain/within the domain/? It seems that there should be an item between the third and fourth items: o The CA makes the newly issued certificate accessible to the user (via the CA's web site? via e-mail?) -- This document describes an extensible framework for automating the issuance and domain validation procedure, thereby allowing servers and infrastructural software to obtain certificates without user interaction. Use of this protocol should radically simplify the deployment of HTTPS and the practicality of PKIX authentication for other protocols based on Transport Layer Security (TLS) [RFC5246]. I think you need some background on why this matters. In the naive default model, someone wants to set up a web server and needs to obtain a certificate. Yes, this will require 1 to 3 hours, but it's a one-time cost over the life of the web site. And I doubt that getting one's self plugged into the Acme system of a CA will take *less* time. Your model seems to be an operator that wants to set up many servers that are authenticatable to many different identities, with each identity being initially vouched for by the same operator. But this suggests that the multiple identities are third parties that are in some way subordinate or derived identities to the operator's identity, either "departments" within one entity, or customers of a vendor. In particular, how does Acme work relative to the case where a service provider claims it is setting up a web site for a third party? [ruminations deleted] I think you need to underline that this only handles the DV case, and not the OV and EV cases. On the first reading, I overlooked the bit about "automating the issuance and domain validation procedure", and immediately started wondering how Acme prevents a service provider from generating bogus web servers for third parties, and thinking it doesn't. But I reflexively think of certificates in terms of OV rather than DV. I suspect many readers also make this assumption. 2. Deployment Model and Operator Experience The guiding use case for ACME is obtaining certificates for websites (HTTPS [RFC2818]). You probably want to emphasize "obtaining domain validation-type certificates ". Prior to ACME, when deploying an HTTPS server, an operator typically This is the first use of "operator", so you probably want to say "the server operator". o The ACME client prompts the operator for the intended domain name(s) that the web server is to stand for. Probably want to say "The operator's ACME client" to make it clear that the client is working for/controlled by/attached to/located at the operator. o In the background, the ACME client contacts the CA and requests that it issue a certificate for the intended domain name(s). It seems that all of the remaining steps are "in the background", as they can run to completion without operator intervention. So I think you want to emphasize "In the background" as an assertion about the remaining steps as a group. o The CA verifies that the client controls the requested domain name(s). "here a miracle happens" -- I think you want to flesh this out or provide a reference to the previous discussion, and especially emphasize that the Internet operations are carried out by the Acme client. E.g., "The ACME client proves to the CA that the operator controls the domain by one of the above-described methods." But maybe I'm being too fussy about the words "controls the requested domain name(s)". o Once the CA is satisfied, the certificate is issued There's no point using the passive when the subject has already been used in the sentence: "Once the CA is satisfied, it issues the certificate". In this way, it would be nearly as easy to deploy with a CA-issued certificate as with a self-signed certificate. As someone who detests setting up yet another account for yet another web site, I would like you to modify this to, "once the operator has an ACME relationship with one or more CAs, it would be nearly ...". [Check how much work the operator needs to get his ACME client connected to a CA. If this is easy, emphasize it in the intro, as it's a major virtue of ACME!] 3. Terminology The two main roles in ACME are "client" and "server". The ACME client uses the protocol to ... An ACME client is represented by an "account key pair". The client uses the private key ... These two paragraphs contain two sentences of terminology definition and two paragraphs of setting up the structure of the ACME client/server system. That's not a bad thing, but it's more than simply "Terminology". Conversely, there's a lot of terminology in this draft that isn't defined here. Probably foremost is "operator", but there should also be some explanation of the use of "response" when that is used to describe an HTTP *request*. One approach would be to move most of these two paragraphs into the beginning of section 4, and then expanding section 3 to include various terms that might not be familiar to people not fully involved in certificate-issuance procedures. The server uses the public key to verify the authenticity and integrity of messages from the client. What information is given to the server by authenticating the request using the public key? One possibility is that the server only needs to know that two requests came from "the same" Acme client, in which case all it needs to check is that both were signed by the same key. But if the key conveys identity information to the server, how is that managed? That should be described (or referenced) at the very beginning of the protocol description, as that is the first action of the Acme protocol, setting up the client and connecting it to the CA. In many ways, ACME functions much like a traditional CA, I think you mean, "In many ways, an ACME server functions ...". ACME allows a client to request certificate management actions using a set of JavaScript Object Notation (JSON) messages carried over HTTPS. In many ways, ACME functions much like a traditional CA, in which a user creates an account, requests a certificate, and proves control of the domains in that certificate in order for the CA to sign the requested certificate. The first sentence of this paragraph should go after the part about setting up the client/server relationship. The second sentence is actually overview for all of section 4 and should stay at the beginning of the section. The server then validates the challenges to check that the client has accomplished them. You may want to say "validates the responses to the challenges". (I'm from an environment where the phrase "challenge/response" is used a lot.) the server will issue the requested certificate and make it available to the client. If the Acme protocol can actually carry the certificate to the client, you probably want to make that clear in this sentence. "and send it to the client"? Order Signature -------> Required <------- Authorizations I assume that messages from the server are also signed. (How is the client to authenticate that it is talking to the server it thinks it's talking to?) I'd say, "the server's signatures also ought to be shown", but at this level of detail, I probably prefer that the signatures not be shown, as they seem to cause me visual clutter. This chart seems to leave out a lot of steps. Perhaps: Order -------> <------- Required Authorizations [Perform response actions.] Response Notification -------> [Verify response actions.] <------- Certificate 6.2. Request Authentication * "jwk" (JSON Web Key, only for requests to new-account and revoke-cert resources) For new-account requests, and for revoke-cert requests authenticated by certificate key, there MUST be a "jwk" field. These two requirements don't appear to be the same. If the client sends a JWS signed with an algorithm that the server does not support, then the server MUST return an error with status code 400 (Bad Request) and type "urn:ietf:params:acme:error:badSignatureAlgorithm". This is hard to understand until the type field is introduced below. (The type field doesn't seem to be a standard feature of JWS.) Easier wold be If the client sends a JWS signed with an algorithm that the server does not support, then the server MUST return an error document with status code 400 (Bad Request) and "urn:ietf:params:acme:error:badSignatureAlgorithm" in the "type" field. 6.3. Request URL Integrity As noted in Section 6.2 above, all ACME request objects carry a "url" header parameter in their protected header. Actually, section 6.2 calls it a "field". You should use consistent terminology, particularly given that in the context of HTTP, the term "header" has a special meaning. (What is the general usage in JWS discussions?) Except for the directory resource, all ACME resources are addressed with URLs provided to the client by the server. For these resources, the client MUST set the "url" header parameter to the exact string provided by the server (rather than performing any re-encoding on the URL). The server SHOULD perform the corresponding string equality check, configuring each resource with the URL string provided to clients and having the resource check that requests have the same string in their "url" header parameter. This is awkwardly phrased. Perhaps: Except for the directory resource, all ACME resources are addressed with URLs provided to the client by the server. When addressing these resources, the client MUST set the "url" header parameter to the exact string provided by the server (rather than performing any re-encoding on the URL). Conversely, the server MUST provide clients with the URLs by which the resources can be addressed through the server, and it SHOULD verify that the "url" header parameter the client provides when accessing a resource is the same string as the server provides clients for that resource. 6.3.1. "url" (URL) JWS header parameter Perhaps the last two paragraphs of section 6.3 should be moved into this section. This text is not as exact as I'd like. What does "to which this JWS object is directed" mean? Do you mean "The request that contains this object is not valid unless the HTTP request URL is exactly the same string as the value of this header parameter." And the phrase "be a string representing the URL" is extremely dangerous. Remember that a URL *is* a string, and if you mess with character encodings or the like, you get a *different* URL, albeit one that some process might consider "equivalent" to the original URL for some purposes. I'm not up to date on HTTP, but there are some complications regarding what the "request URI" of a request is; it's not always just the value of the "request-URI" field of the request-line. There's probably a set terminology for this concept; it would be wise to align with it. 6.4. Replay protection In order to protect ACME resources from any possible replay attacks, Could this be shortened to "In order to protect ACME resources from replay attacks, ..."? Every JWS sent by an ACME client MUST include, in its protected header, It's vague here what "JWS" means as an unqualified noun. I suspect, "JWS object", but some other uses suggest that there is a larger JWS construct within which the "object" is the "payload". In any case, the terminology should be brought into alignment with the JWS standard(s). It's not clear why the nonces are provided in the Replay-Nonce header rather than being provided in the JWS response. Compare when the client sends the nonce, when it is provide inside the JWS object. Indeed, this seems to be a layering violation -- the nonce is sent by the server in a header, but sent by the client in the JWS. It would be cleaner to send the nonce in both directions in a header, or send it in both directions in the JWS. Perhaps the standard JWS practice is to do it this way -- but the existence of section 6.4.1 suggests otherwise. It might be worth noting that it is acceptable for the server to "expire" unused nonces by not accepting nonces that were provided in responses too far in the past. (Assuming you want to allow it.) Since a client is required to retry requests that are rejected due to nonce failure, and that retry is expected to be done promptly, this behavior does not cause protocol failure. As written, this section suggests that a server MUST NOT reject a request as long as the nonce is valid, regardless of how long ago the nonce was issued. 6.4.1. Replay-Nonce This section reads very awkwardly. I think the intention is to provide a specification of the Reply-Nonce header field that stands alone. But it is a specification only in regard to the syntax of the field, not the semantics. OTOH, the first sentence of the section seems to be trying to describe the semantics of the field, which is confusing since it is nowhere near complete. If you want to say "generally, this field is to provide nonces that clients can use to uniquely identify requests" you want to be careful to qualify it with some statement that the exact usage is described in other specifications. Wording this correctly could get awkward. The phrase "unique to each message" isn't clear with regard to scope. Is it like SIP Call-Ids, which are unique over all space and time? Or just unique over the history of the server? The language is not as clear as I'd like about where it appears. Better to say "The server provides this header field in responses to carry a server-generated nonce to the client..." and "The Replay-Nonce header field MUST only be carried in HTTP response messages." 6.4.2. "nonce" (Nonce) JWS header parameter Again, this section hints at but does not specify the semantics of the datum. 6.5. Rate limits Creation of resources can be rate limited to ensure fair usage and prevent abuse. Once the rate limit is exceeded, the server MUST respond with an error with the type "urn:ietf:params:acme:error:rateLimited". Additionally, the server SHOULD send a "Retry-After" header indicating when the current request may succeed again. If multiple rate limits are in place, that is the time where all rate limits allow access again for the current request with exactly the same parameters. This is written as of rate limiting is some sort of global correctness property -- which can't be reduced to any property observable by either client or server. The first sentence doesn't even state that it's the *server* that can limit rates! Better is to clarify the intentions and roles of the various actors: A server MAY limit the rate at which it accepts various requests from various clients, e.g., to ensure fair usage and prevent abuse. If a server desires to postpone submission of a particular request, it MUST respond with an error with the type "urn:ietf:params:acme:error:rateLimited". Additionally, the server SHOULD [I can't see a reason why this isn't MUST] include a "Retry-After" header indicating the time interval after which all limitations the server is currently applying to this request will permit processing of this request. Different requests (even if from the same client) may be subject to different rate limits; the Retry-After value gives no information about other requests. -- In addition to the human readable "detail" field of the error response, the server MAY send one or multiple tokens in the "Link" header pointing to documentation about the specific hit rate limits using the "urn:ietf:params:acme:documentation" relation. What does "token" mean here? From context, I think you mean "link-value" (after RFC 5988), or better, "URI". Also, the value "urn:ietf:params:acme:documentation" doesn't seem to be placed in the IANA registry described in section 9.6. 6.6. Errors this document defines the following standard tokens for use in the "type" field (within the "urn:ietf:params:acme:error:" namespace): This isn't correct terminology. The namespace of these URNs is "ietf". Part of the problem is that there isn't a standardized term for the parts of a URN that are separated by colons, despite that almost all URN namespaces use colons as major separators. I think this version is both correct and readable: ... this document defines the following standard URIs for use in the "type" field (where each listed token is appended to "urn:ietf:params:acme:error:" to make the URI): +-----------------------+-------------------------------------------+ | Token | Description | +-----------------------+-------------------------------------------+ | badCSR | The CSR is unacceptable (e.g., due to a | | | short key) | -- This list is not exhaustive. The server MAY return errors whose "type" field is set to a URI other than those defined above. Servers MUST NOT use the ACME URN [RFC3553] namespace for errors other than the standard types. "namespace" isn't really correct here, but I think "sub-namespace" is. Clients SHOULD display the "detail" field of all errors. s/display/display to the user/ 7.1. Resources Each function is listed in a directory along with its corresponding URL, so clients only need to be configured with the directory URL. s/a directory/the directory resource/ The "up" link relation from "cert" to the CA chain is not shown in the figure. The "index" link relation isn't shown at all, though that couldn't be shown easily. You might want to note that in some way in the paragraph before the figure. | Submit an order | POST new-order | 201 -> order | When I first read this, I was unclear what an "order" is. It turns out that it is a request for a certificate. E.g., o Order resources, representing an account's requests to issue certificates (Section 7.1.3) You might want to either move toward the nomenclature "request a certificate" or more heavily emphasize "order" in the text. If you enlarge section 2 to cover all the specialized terminology, putting an entry in it for "order" would be helpful. There are quite a number of example request responses that do not contain the "index" link header. The figure does not show the key-change resource. 7.1.1. Directory whose fields names are drawn from the following table s/fields names/field names/ +-------------+--------------------+ | Field | URL in value | +-------------+--------------------+ | new-nonce | New nonce | | | | | new-account | New account | | | | | new-order | New order | | | | | new-authz | New authorization | | | | | revoke-cert | Revoke certificate | | | | | key-change | Key change | +-------------+--------------------+ In this table, one of the "URL in value" items is a predicate (verb-object), which makes sense; one is a noun phrase naming an action; and four are noun phrases (which are objects of an implied "get" or "obtain"). I suggest rephrasing the items into predicates directly telling what the URL does, e.g., "request new nonce", "change key". There is no constraint on the actual URL of the directory except that "actual" is probably superfluous here. The following metadata items are defined, all of which are OPTIONAL: It would probably be wise to allow servers to include non-standard metadata items. HTTP/1.1 200 OK Content-Type: application/json This should be preceded by something like "An example response to a directory GET is:". I suggest providing some sort of direct description of each example, and it would help to show requests and responses together. (But perhaps the RFC Editor thinks that unlabeled examples are OK if the context makes their purpose clear enough.) 7.1.2. Account Objects contact (optional, array of string): An array of URLs that the server can use to contact the client for issues related to this account. For example, the server may wish to notify the client about server-initiated revocation or certificate expiration. Strictly, you want "URIs" here, as tel:, sip:, and mailto: URIs are not URLs [RFC 6068]. 7.1.2.1. Orders List How long does an order URL remain valid? The particular URLs in the example suggests that the order URLs are valid only as long as the set of orders doesn't change. A larger question is whether order objects are ever purged from the orders list? Indeed, these questions can be generalized -- Can the server ever purge resources, invalidating the URLs that pointed to them? What sort of assurances can the client rely on? 7.1.3. Order Objects For final orders, the authorizations that were completed. What is a "final" order? The term "final" is used in a number of places, with possibly slightly different meanings, and needs to be properly defined. 7.1.4. Authorization Objects status (required, string): The status of this authorization. Possible values are: "pending", "processing", "valid", "invalid" and "revoked". It might be worth spelling out here what these states mean, as this is the definition of this field of the authorization object. If this field is absent, then the CA MUST consider this authorization valid for all orders until the authorization expires. There doesn't seem to be an "expired" status, so how can an authorization expire? For final authorizations it contains the challenges that were successfully completed. What is a "final" authorization? Section 8 describes a set of challenges for domain name validation. Section 8 is about challenges generally; really the challenges for domain name validation are sections 8.4 to 8.6. Perhaps they should be grouped into a subsection and this sentence should point to that? 7.3. Account Creation If the server wishes to present the client with terms under which the ACME service is to be used, it MUST indicate the URL where such terms can be accessed in the "terms-of-service" subfield of the "meta" field in the directory object, and the server MUST reject new-account requests that do not have the "terms-of-service-agreed" set to "true". Clients SHOULD NOT automatically agree to terms by default. Rather, they SHOULD require some user interaction for agreement to terms. I note that there seems to be no recording of when the account was created, i.e., *when* the terms of service was agreed to. Since the content behind the terms of service URL can change unpredictably, noting that the terms of service were agreed to is meaningless unless there is some fixation of the time of agreement. an error of type "invalidContact". The wording of the text is inconsistent (or just unclear) whether error types are give as full URNs or just the last component. 7.3.4. Changes of Terms of Service The problem document returned with the error MUST also include an "instance" field, indicating a URL that the client should direct a human user to visit in order for instructions on how to agree to the terms. This seems inconsistent with section 7.3, as the client can agree to the terms of service when creating an account within Acme, but changes in terms seem to require going out-of-band to agree to the new terms of service. Given that this could become a legal matter, it seems like a lot of care and thought should be put in on this. Ideally, a good lawyer should be consulted on this. HTTP/1.1 403 Forbidden Replay-Nonce: IXVHDyxIRGcTE0VSblhPzw Link: ;rel="terms-of-service" Content-Type: application/problem+json Content-Language: en The various examples don't seem to be indented consistently. Although I expect the RFC Editor will clean that up. 7.3.5. External Account Binding This can be used to an ACME account with an existing account in a non-ACME system, such as a CA customer database. There's a word missing after "This can be used to". The server MAY require a value to be present for the "external- account-binding" field. It would help the reader recover the context by starting this with, "In an account creation request,". To enable ACME account binding, a CA needs to provision the ACME client with a MAC key and a key identifier. You might want to annotate this, "by some means outside the scope of this document", or "presumably as part of establishing the external account". And I would use "provide" rather than "provision" -- "provision" suggests to me that there is a specific provisioning process that will be defined. What is a "MAC key"? I think you mean that any account binding must be represented by a key pair for the external account, and the private key of that pair is the "MAC key". OTOH, this may be inconveniently heavy-weight for real-world use -- I would expect the CA to simply provide a secret associated with the external account. (Or is that what a "MAC key" is?) The ACME client then computes a binding JWS to indicate the external account's approval of the ACME account key. This isn't quite correct. Perhaps The ACME client then computes a binding JWS to indicate that that the client, the owner of the external account, approves of the ACME account key. Or is that "the client, on behalf of the owner of the external account"? -- MUST reflect value of the "external-account-binding" field s/reflect value/reflect the value/ 7.3.6. Account Key Roll-over The client then encapsulates the key-change object in a JWS, signed with the requested new account key (i.e., the key matching the "newKey" value). The outer JWS MUST meet the normal requirements for an ACME JWS (see Section 6.2). The inner JWS MUST meet the normal requirements, with the following exceptions: Some detail is being left out. I think that the JWS described in the first of these paragraphs becomes the "inner JWS" of the next paragraph. But exactly how that nesting is to be performed doesn't seem to be described. 3. Check that the JWS protected header of the inner JWS has a "jwk" field. Is the generation of the "jwk" field specified in the text anywhere? 7.4. Applying for Certificate Issuance then the server MUST proactively issue the requested certificate and provide a URL for it in the "certificate" field of the order. I'm not sure that "proactively" has a specific meaning. I think you can just s/proactively issue/issue/ and capture the desired meaning -- the server doesn't have to issue a certificate instantly, but it cannot delay. The status of the order will indicate what action the client should take: This list is part of the definition of the order object, and should be put in section 7.1.3. 7.4.1. Pre-Authorization In some cases, a CA running an ACME server might have a completely external, non-ACME process for authorizing a client to issue for an identifier. I'm not sure that "client" is a proper subject for "issue". Perhaps you mean "for authorizing a client to be issued certificate(s) for an identifier". 7.4.2. Downloading the Certificate A certificate resource represents a single, immutable certificate. If the client wishes to obtain a renewed certificate, the client initiates a new order process to request one. Though I think you want to add what you really mean, namely that the new certificate will be fetched from a different URL. 7.5. Identifier Authorization The server may declare that an authorization is only valid for a specific order by setting the "scope" field of the authorization to the URL for that order. "scope" isn't shown in the figure in section 7.1. 7.5.1. Responding to Challenges The server is said to "finalize" the authorization when it has Despite the existence of a section titled "Terminology", very little of the terminology created for this document is listed there. 8. Identifier Validation Challenges Each challenge must describe: This isn't right; a challenge doesn't describe anything. But the descriptions of the challenge types include various information, etc. status (required, string): The status of this authorization. Possible values are: "pending", "valid", and "invalid". I think you mean "the status of this challenge". But you might mean "the status of the authorization containing this challenge". validated (optional, string): The time at which this challenge was completed by the server I'm not sure in what sense you mean "completed by", since it's the client that does the completing. I think you mean "the time at which the server recognized that the challenge was completed". The server can limit the size of this object by limiting the number of times it will retry a challenge. Rather, "the number of times it will permit the client to retry a challenge". Actually, the semantics of this field probably depends on the pattern of the actions by which the challenge is satisfied, and so may be dependent on the challenge type. If the server sets a challenge's "status" to "invalid", it SHOULD also include the "error" field to help the client diagnose why the challenge failed. Presumably, 'the "errors" field'. Also, section 8.2, "The server MUST add an entry to the "errors" field in the challenge after each failed validation query.", suggests that the server MUST include the "errors" field, not just SHOULD include. 8.1. Key Authorizations A key authorization is a string that expresses a domain holder's authorization for a specified key to satisfy a specified challenge, by concatenating the token for the challenge with a key fingerprint, separated by a "." character: key-authz = token || '.' || base64url(JWK_Thumbprint(accountKey)) In what way does a key authorization indicate something about a "domain holder"? The k.a. includes the token (presumably from the challenge object) and a computation based on an account's (private) key, so it includes information from the account holder. Or do you mean that "in the challenge, a token will be sent by the server that only the domain holder will be able to receive, and as part of the account holder's response to the challenge, it composes a key authorization string"? Really, I doubt that this is understandable without first explaining the general model of challenge/response that the challenge types defined here use, and that model doesn't seem to be described anywhere. I think it would be very helpful if that model was presented first, before the specific challenge types that use that model. Alternatively, you could just describe this as an abstract operation on strings, key-authz(token, accountKey) = token || '.' || base64url(JWK_Thumbprint(accountKey)) and leave defining its semantics to where key-authz() is used. The "JWK_Thumbprint" step indicates the computation specified in [RFC7638], using the SHA-256 digest [FIPS180-4]. As noted in JWA [RFC7518] any prepended zero octets in the JWK object MUST be stripped before doing the computation. The second sentence seems to be unclear. Is the "JWK object" the output of "JWK_Thumbprint(accountKey)"? If so, why isn't it called "the JWK_Thumbprint object"? And the significance of "prepended zero octets" is unclear; RFC 7518 does not include the word "prepend", so presumably does not specify any prepending. I suspect you mean that some stage of the processing of RFC 7518 is modified by stripping initial zero octets from some string, but such octets wouldn't be described as "prepended". 8.2. Retrying Challenges Clients can explicitly request a retry by re-sending their response to a challenge in a new POST request (with a new nonce, etc.). Again, this makes sense only under the assumption that satisfying a challenge has certain data-flow patterns, in that (apparently) the client must send a "response" and then -- well, it's not entirely clear what "a retry" is. You really need to lay out this pattern -- and the names you use for the actions within it -- before you specify the details of how clients and servers can perform it. In order to avoid denial-of-service attacks via client-initiated retries, servers SHOULD rate-limit such requests. There are two uses of "request" in the preceding sentence -- which of them is being rate-limited? 8.3. HTTP Challenge With HTTP validation, the client in an ACME transaction proves its control over a domain name by proving that for that domain name it can provision resources to be returned by an HTTP server. Better, "by proving that it can provision resources that are returned by an HTTP server accessible using a URL whose host is that domain name". type (required, string): The string "http-01" You don't actually say that these two fields are part of HTTP challenge objects. It MUST NOT contain any characters outside the base64url alphabet, including padding characters ("="). This could be read two ways; are the padding characters part of "the base64url alphabet", or are they part of "characters outside the base64url alphabet"? Perhaps: It MUST NOT contain any characters that are outside the base64url alphabet, or padding characters ("="). or It MUST NOT contain any characters that are outside the base64url alphabet (including padding characters ("=")). Maybe better would be "It must contain only characters in the base64url alphabet including/excluding padding characters("=")." Actually, this is just ugly to specify using English, because it's really hard to say it without using two negatives in one sentence, and making clear what the scope of each negative is. I think the best approach is to rely on the fact that RFC 7515 section 2 clearly defines that "=" is *not* in the base64url alphabet: It MUST NOT contain any characters that are not in the base64url alphabet. If someone complains this is unclear, add separate sentence saying that following RFC 7515 section 2, "=" is not in the base64url alphabet. The value of the resource MUST be the ASCII representation of the key authorization. Given that the key authorization is an ASCII string, it's not clear what its "ASCII representation" is. The client's response to this challenge indicates its agreement to this challenge by sending the server the key authorization covering the challenge's token and the client's account key. I think you mean, "The client responds to this challenge by POSTing an update to the challenge object, adding a "keyAuthorization" field containing the key authorization derived from the challenge's token and the client's account key." 1. Construct a URL by populating the URL template [RFC6570] "http://{domain}/.well-known/acme-challenge/{token}", where: * the domain field is set to the domain name being verified; and * the token field is set to the token in the challenge. What do the "*" mean? 8.5. DNS Challenge The record provisioned to the DNS is the base64url encoding of this digest. This doesn't make sense, as a DNS record is not a string per se. However, the next two sentences make clear what the DNS record should be. _acme-challenge.example.org. 300 IN TXT "gfj9Xq...Rg85nM" It's not clear where "gfj9Xq...Rg85nM" came from, as it's supposed to be a SHA-256 digest. Though the previous paragraph doesn't specify how the digest is to be represented; in parallel to earlier discussion, lower-case hexadecimal seems to be assumed. 8.6. Out-of-Band Challenge the client indicates this by sending a simple acknowledgment response to the server. The text doesn't describe what a "simple acknowledgements response" is. However, the other challenge types involve what seem to be parallel acknowledgment responses that are required to contain copies of token values, though in none of these cases does the POST carry any actual information other than the fact that the POST was made to the particular URL. What is the reason for this inconsistency? For that matter, why does the payload of the response for this challenge contain a "type" field? Perhaps there is something I don't understand about these POSTs which seem to convey no information other than triggering the server to take some action with regard to the target resource. 9.1. MIME Type: application/pem-certificate-chain The "Media Types" registry should be updated with the following additional value: IMO it's better to phrase this, "The following entry should be added to the "Media Types" registry:". I like to use "update" only for operations that modify existing entries. File should contain one or more certificates encoded as PEM according to RFC 7468 [RFC7468]. "should contain"? I think you want to say "File contains". Actually, "File must consist of ...". "encoded as PEM" seems to be undefined by RFC 7468. Perhaps "encoded using PEM textual encoding according to RFC 7468" is meant. 9.6. URN Sub-namespace for ACME (urn:ietf:params:acme) I don't see how this specifies that this registry is connected with the the registry (ACME Error Types, section 9.7.3) which provides the final component of "urn:ietf:params:acme:*" URNs. I suspect you want the "Repository" datum in this section to state that it points to the registry created per section 9.7.3. 9.7. New Registries Is there a registry for fields in authorization objects? 9.7.4. Resource Types Are there entries for "new-nonce" and "new-authz"? [END] _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Nov 15 17:23:32 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5218E124319 for ; Wed, 15 Nov 2017 17:23:30 -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 BOzwJ9LHuwXT for ; Wed, 15 Nov 2017 17:23:28 -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 C34C4120227 for ; Wed, 15 Nov 2017 17:23:28 -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:MIME-Version:Date:Message-ID:Subject:From:To; bh=vbNwH3t3juIf0PMy1zKjZIFgvKhitNI7w08Z9VO5OqA=; b=sp8HOft+kNZYJHH8vgsm8RqEU3WM1cZMK2QHP/paKzfuVHTdw2IWa+sX3CNZClAi/wrtbwZoqNWj5zpYVXCrjTbHOrWL8XDWdj5Nz2EhjyfOZxTqziodpGnVFPddDfUPXaVWLfEZlsf+XXP3CJre2Djy6Gj1FjMpllOTvpaDjWM=; Received: ; Wed, 15 Nov 2017 17:23:24 -0800 To: "acme@ietf.org" From: Jacob Hoffman-Andrews Message-ID: <3994bc53-7a68-c1f2-4a6b-64bbfd9ea99d@eff.org> Date: Wed, 15 Nov 2017 17:23:07 -0800 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-Transfer-Encoding: quoted-printable Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: [Acme] Returning multiple errors 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, 16 Nov 2017 01:23:30 -0000 In previous versions of ACME, there was sometimes a need to return multiple errors, broken out by domain name. For instance, when issuing a certificate by making a new-cert request, the CA has to check CAA, which may fail for multiple domains. Ideally, the client should not have to guess which identifiers (domains) failed, or engage in string parsing. So far, this hasn't been terrible because *most* errors occur during new-authz or during validation, and so are implicitly associated with a specific identifier. However, in the latest spec, this problem is a lot worse. Since all issuance starts with new-order, which can request multiple identifiers, all attempts to issue for multiple identifiers will potentially fail for one or more of those identifiers. Fortunately, JSON problem details provide enough flexibility for this, with problem-specific extensions (https://tools.ietf.org/html/rfc7807#page-4). I propose we define a field, "sub-problems", on all ACME problem types. This field would contain a list of JSON problem details, each of which may contain an identifier. So for instance, you might receive this response from a new-order request: { =C2=A0 "type": "urn:ietf:params:acme:error:malformed", =C2=A0 "detail": "Some of the identifiers requested were rejected", =C2=A0 "sub-problems": [ { =C2=A0=C2=A0=C2=A0 "identifier": { "value": "_example.com", "type": "dns"= }, =C2=A0=C2=A0=C2=A0 "type": "urn:ietf:params:acme:error:malformed", =C2=A0=C2=A0=C2=A0 "value": "Invalid underscore in DNS name \"_example.co= m\"", =C2=A0 }, { =C2=A0=C2=A0=C2=A0 "identifier": { "value": "example.net", "type": "dns" = }, =C2=A0=C2=A0=C2=A0 "type": "urn:ietf:params:acme:error:malformed", =C2=A0=C2=A0=C2=A0 "value": "\"example.net\" is considered a high-risk do= main", =C2=A0 } ] } That way, clients that issue for large numbers of domains may choose to automatically retry new-order with the problem identifiers removed. Thoughts? From nobody Wed Nov 15 19:07:09 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D62126CC4 for ; Wed, 15 Nov 2017 19:07:08 -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 7ogwj9i_vZtR for ; Wed, 15 Nov 2017 19:07:06 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96E0F124BE8 for ; Wed, 15 Nov 2017 19:07:06 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id y80so6627280wmd.0 for ; Wed, 15 Nov 2017 19:07:06 -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=NWzYJv8jYGyUTLPwojvADWCY+E1Yfco7UoUH24gzJTM=; b=hwVq07ibWJRGm5d/lXzXKUu1FVa54zLal73nN0ShHGTD2De4Bl+1MnJd48TxIzThLc Xk2R+CB6zu9axoPqXIK/VS2v4+OQv+Fy4C0gz/jS1A6jRoTQh0wvccGCk0+7SSypa+8E cP4oWN3U+7gN/NcKK0jFwt3DobvnqM1iFXBLODI8d4AlQWSOE7kN992w3XuqqajmSeUT 8Rro1MDL256jzxz/shmSvNaidC8QZVP8ANmZRyHZ2n4rukpKe/izfwkdYCp+QXB1K7Hl SiqTEVec03M5C/nqaWZGvColkWN/v0+pn+RuljVtGy+YSSz3+KvmFtDlkxq84CWm82Pk 8eAQ== 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=NWzYJv8jYGyUTLPwojvADWCY+E1Yfco7UoUH24gzJTM=; b=jZVxRmgXzTlrPGkZaoJKm5Vi0AAOQpTRqVEFSvwsMzqZy9VaJ5l5QoTLeI4vDoIqis knjH78vfBmoerF+L2IucL/p+Srf07h6xOQSgEypvE9ZaCUxOR6tKiSDQpLXT6OMBDVX+ hWsZznYMYEdCXB6dpHqcl1DcuxmDbjUmXeEsQaHjd1jUKBAh5rqReuQFy3BGmsgopLCc sjg1yjZPftxCerem94lIEioV60ccwMSJG68cBiyMcQb+Lf6W4QDFm8yH4QaACDiXMGCF Xml5hRSMAegssVEwjVurqhB4p3G1YYNAwf+oTAhIGuCovvTEL4vcsZZKcQjmKbpA+lR4 OfVQ== X-Gm-Message-State: AJaThX7HieMf9ClSp6k5naKhQWCxTQYORLck50TtltVylbLeBZjEUnMh UgA1gG9hdDd3LnAZQYyj4yoKO70DzN2wNlkhJcIpag== X-Google-Smtp-Source: AGs4zMbR0zswS5ixdgQUYN90sMvvUlmFvRbZnzOtyCZOX6+yb9G0c/zl4P+cvBTfH9G+BdxU05lF4nUGz8N/nAD32UE= X-Received: by 10.28.192.24 with SMTP id q24mr28214wmf.98.1510801624882; Wed, 15 Nov 2017 19:07:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Wed, 15 Nov 2017 19:07:04 -0800 (PST) In-Reply-To: <3994bc53-7a68-c1f2-4a6b-64bbfd9ea99d@eff.org> References: <3994bc53-7a68-c1f2-4a6b-64bbfd9ea99d@eff.org> From: Richard Barnes Date: Thu, 16 Nov 2017 11:07:04 +0800 Message-ID: To: Jacob Hoffman-Andrews Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="089e083147842d75c4055e10ea47" Archived-At: Subject: Re: [Acme] Returning multiple errors 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, 16 Nov 2017 03:07:08 -0000 --089e083147842d75c4055e10ea47 Content-Type: text/plain; charset="UTF-8" This sounds pretty inoffensive to me. Want to send a PR? Following Daniel's lead on looking for implementation: Is this something LE would be implementing? On Thu, Nov 16, 2017 at 9:23 AM, Jacob Hoffman-Andrews wrote: > In previous versions of ACME, there was sometimes a need to return > multiple errors, broken out by domain name. For instance, when issuing a > certificate by making a new-cert request, the CA has to check CAA, which > may fail for multiple domains. Ideally, the client should not have to > guess which identifiers (domains) failed, or engage in string parsing. > So far, this hasn't been terrible because *most* errors occur during > new-authz or during validation, and so are implicitly associated with a > specific identifier. > > However, in the latest spec, this problem is a lot worse. Since all > issuance starts with new-order, which can request multiple identifiers, > all attempts to issue for multiple identifiers will potentially fail for > one or more of those identifiers. > > Fortunately, JSON problem details provide enough flexibility for this, > with problem-specific extensions > (https://tools.ietf.org/html/rfc7807#page-4). I propose we define a > field, "sub-problems", on all ACME problem types. This field would > contain a list of JSON problem details, each of which may contain an > identifier. So for instance, you might receive this response from a > new-order request: > > { > "type": "urn:ietf:params:acme:error:malformed", > "detail": "Some of the identifiers requested were rejected", > "sub-problems": [ { > "identifier": { "value": "_example.com", "type": "dns" }, > "type": "urn:ietf:params:acme:error:malformed", > "value": "Invalid underscore in DNS name \"_example.com\"", > }, { > "identifier": { "value": "example.net", "type": "dns" }, > "type": "urn:ietf:params:acme:error:malformed", > "value": "\"example.net\" is considered a high-risk domain", > } ] > } > > That way, clients that issue for large numbers of domains may choose to > automatically retry new-order with the problem identifiers removed. > > Thoughts? > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --089e083147842d75c4055e10ea47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This sounds pretty inoffensive to me.=C2=A0 Want to s= end a PR?

Following Daniel's lead on looki= ng for implementation: Is this something LE would be implementing?

On Thu, No= v 16, 2017 at 9:23 AM, Jacob Hoffman-Andrews <jsha@eff.org> wrot= e:
In previous versions of ACME, there wa= s sometimes a need to return
multiple errors, broken out by domain name. For instance, when issuing a certificate by making a new-cert request, the CA has to check CAA, which may fail for multiple domains. Ideally, the client should not have to
guess which identifiers (domains) failed, or engage in string parsing.
So far, this hasn't been terrible because *most* errors occur during new-authz or during validation, and so are implicitly associated with a
specific identifier.

However, in the latest spec, this problem is a lot worse. Since all
issuance starts with new-order, which can request multiple identifiers,
all attempts to issue for multiple identifiers will potentially fail for one or more of those identifiers.

Fortunately, JSON problem details provide enough flexibility for this,
with problem-specific extensions
(https://tools.ietf.org/html/rfc7807#page-4). I p= ropose we define a
field, "sub-problems", on all ACME problem types. This field woul= d
contain a list of JSON problem details, each of which may contain an
identifier. So for instance, you might receive this response from a
new-order request:

{
=C2=A0 "type": "urn:ietf:params:acme:error:malformed&qu= ot;,
=C2=A0 "detail": "Some of the identifiers requested were rej= ected",
=C2=A0 "sub-problems": [ {
=C2=A0=C2=A0=C2=A0 "identifier": { "value": "_example.com= ", "type": "dns" },
=C2=A0=C2=A0=C2=A0 "type": "urn:ietf:params:acme:error:= malformed",
=C2=A0=C2=A0=C2=A0 "value": "Invalid underscore in DNS name = \"_example.com\"",
=C2=A0 }, {
=C2=A0=C2=A0=C2=A0 "identifier": { "value": "example.net<= /a>", "type": "dns" },
=C2=A0=C2=A0=C2=A0 "type": "urn:ietf:params:acme:error:= malformed",
=C2=A0=C2=A0=C2=A0 "value": "\"example.net\" is consi= dered a high-risk domain",
=C2=A0 } ]
}

That way, clients that issue for large numbers of domains may choose to
automatically retry new-order with the problem identifiers removed.

Thoughts?

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

--089e083147842d75c4055e10ea47-- From nobody Wed Nov 15 23:54: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 6C30712957F for ; Wed, 15 Nov 2017 23:54:54 -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 QV3tdTfdRfKe for ; Wed, 15 Nov 2017 23:54:52 -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 78E5C120724 for ; Wed, 15 Nov 2017 23:54:52 -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=bpAjNMJmmkG4pWDE6b98vJ1jK77Pq1p2w7+FU6tp6Ws=; b=oL61D88Louxbi1AkrAvpfopM2bakyg4jEY8fW8mOreuBk1vsVRRFFsgXSw4lDILJw7T+HZq3YVTEgCtbXBAByDB/L0eekKAAB+PqMqie5SXisqum6rWSEC1Xbl+YOfdSDpHX/shevAomVQiG9SGXvZllNmAglvXgQHUlUv8vk7k=; Received: ; Wed, 15 Nov 2017 23:54:48 -0800 To: Richard Barnes Cc: "acme@ietf.org" References: <3994bc53-7a68-c1f2-4a6b-64bbfd9ea99d@eff.org> From: Jacob Hoffman-Andrews Message-ID: <632eb456-bc9d-6e95-b414-137ce4b6a8e1@eff.org> Date: Wed, 15 Nov 2017 23:54:51 -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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Acme] Returning multiple errors 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, 16 Nov 2017 07:54:54 -0000 On 11/15/2017 07:07 PM, Richard Barnes wrote: > Following Daniel's lead on looking for implementation: Is this > something LE would be implementing? Yep, we would definitely implement this. I'll send a PR. From nobody Thu Nov 16 00:45: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 47CE0126BFD for ; Thu, 16 Nov 2017 00:45:04 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mhpm_agwz3nx for ; Thu, 16 Nov 2017 00:45:01 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003: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 4F169124217 for ; Thu, 16 Nov 2017 00:45:01 -0800 (PST) Received: by mail-oi0-x235.google.com with SMTP id a132so17890776oih.11 for ; Thu, 16 Nov 2017 00:45:01 -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=mM92+71pJJTvBpVNXWWe1oDJ+OhFmcrMQKrhIJOgo6Y=; b=NOnqIG8k7541c2flDKygYFFPHhfSEn/8jt+x5bHXo+YwqhL+Z/Cr2x1kphdKiZt7Yk UVi+DFw/4tQU6VYLFDhPphp4dGzUtxLWwPAG6NrV7PItHz6aadksO6tJh2eFBACqSuy0 MU0Su0o6m+hHDk463Af9KHonkCi6nSPq8uqPJQqzDXO1fEgWGkCXTAKWOjMQu69TgV+U o13isIwKRj6TwK6NToCA1WDEaxA8I3SQoThHMSjWjjQ2IP14KAFH0OANBnV7RpEAD/jc 7U9FIwB/QeHa4ikIRH84ptAxstajo/tCu/x9WLLil2zgpyzPpkllEvPxLL2sdORWkODV wgLQ== 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=mM92+71pJJTvBpVNXWWe1oDJ+OhFmcrMQKrhIJOgo6Y=; b=hE/AT2WQpX9DEKzDf3060N1YFfeUyoc8p9hoaSBgiIsE9NeLqPM/JF4I6XPHA8IhLb Dse4hdbqvHqxZR5whkNJl9jpw8U5EMY/ofdr2DdWTyq+NejZmGxqZlhZKp8upB8O+hfU wPrXg1jAuCJ+OMolLyTe2HlFhwNWhNVZc7QOJdprNyBD+Eo+wcNAyMaQlIcBo3B15UB8 l4AmbQoWvo1eD8PZT/233q53RLfuemxGXKt4LYkJscy8QE2kVscKhNDDMN0dr58kWaz2 Gz2muaVqMc6zh+w3TN6iPvDlWdcT1NeughEPOKH3XATY5BHCjIxiKb1IanXpuil0hef4 1Zdg== X-Gm-Message-State: AJaThX6rX6hJ2n0h+Dx3EnLTBU2/bqIrQpcXNFFQgar5dGec7W83/S4S Xj8+v2JlCcCln/IgKt61woZ1oUzKwtahP27lx65rM0mg X-Google-Smtp-Source: AGs4zMaKJkgQFfZBadUqNOHJtiiiGHmJEN+PvkhXscsdZdXN6dT6Qes6cSb0huhhA7xF2rc2PZVGGkGjLoMb8UIft0I= X-Received: by 10.202.86.84 with SMTP id k81mr553362oib.50.1510821900652; Thu, 16 Nov 2017 00:45:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Thu, 16 Nov 2017 00:45:00 -0800 (PST) In-Reply-To: <632eb456-bc9d-6e95-b414-137ce4b6a8e1@eff.org> References: <3994bc53-7a68-c1f2-4a6b-64bbfd9ea99d@eff.org> <632eb456-bc9d-6e95-b414-137ce4b6a8e1@eff.org> From: Martin Thomson Date: Thu, 16 Nov 2017 16:45:00 +0800 Message-ID: To: Jacob Hoffman-Andrews Cc: Richard Barnes , "acme@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Acme] Returning multiple errors 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, 16 Nov 2017 08:45:04 -0000 Have you considered json text sequences: https://tools.ietf.org/html/rfc7464 ? I don't know what a random JSON parser would do with your stacked error codes. On Thu, Nov 16, 2017 at 3:54 PM, Jacob Hoffman-Andrews wrote: > On 11/15/2017 07:07 PM, Richard Barnes wrote: >> Following Daniel's lead on looking for implementation: Is this >> something LE would be implementing? > Yep, we would definitely implement this. I'll send a PR. > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme From nobody Thu Nov 16 00:47: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 76F6A126CBF for ; Thu, 16 Nov 2017 00:47:08 -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 EXne6cH42S6u for ; Thu, 16 Nov 2017 00:47:07 -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 625C5126BFD for ; Thu, 16 Nov 2017 00:47:07 -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=AweXFiAHSTjPj5K44qeJf7JZXf6SZAyBalyF6WEKjQc=; b=XEbIhjC44/821fP6XUrRLMkiZVK21C3z3BDk05GwQMG8e+GyWadp+9Igy0UOtStZeCE4lPPMHavf95QWeqAYmb2jmps+a3TKzKxaSCgVUOD4SZmzOzXRuPltdVuqSV8LA3O0V5BCJNXExo4TBd1Sti8lX+fVtSC7Z+CNkpvMpt4=; Received: ; Thu, 16 Nov 2017 00:47:03 -0800 To: Martin Thomson Cc: Richard Barnes , "acme@ietf.org" References: <3994bc53-7a68-c1f2-4a6b-64bbfd9ea99d@eff.org> <632eb456-bc9d-6e95-b414-137ce4b6a8e1@eff.org> From: Jacob Hoffman-Andrews Message-ID: <607b7f74-338a-40b6-5ba9-35c6aeace87f@eff.org> Date: Thu, 16 Nov 2017 00:47:06 -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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Acme] Returning multiple errors 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, 16 Nov 2017 08:47:08 -0000 On 11/16/2017 12:45 AM, Martin Thomson wrote: > I don't know what a random JSON parser would do with your stacked error codes. I don't understand. What I'm proposing is an array of JSON objects under the sub-problems field, which should be supported by any JSON parser. From nobody Thu Nov 16 00:49:36 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692461275FD for ; Thu, 16 Nov 2017 00:49:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=outer-planes-net.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 x4oLyEZXHaYe for ; Thu, 16 Nov 2017 00:49:33 -0800 (PST) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB140127369 for ; Thu, 16 Nov 2017 00:49:32 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id s75so20123544pgs.0 for ; Thu, 16 Nov 2017 00:49:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=5g61G00PffAxeHm0sxRDgka8k+1P9efLNqPGj0SUAs0=; b=AFv3fWxbfMmG1rfZWT2Smz6o+tR/4LCseDsRuSwn7TSpXrDLHhKLMzXNmxGCPmUA// UscHgx/zDBKSPzaWye4crH6JJRjoFvt8P4hxaCSpZNenichtVxpdcOPz4A4YSH9w2TPV WczfoB8zZvtmFhVPl7lYoaJMs82WhAXrohDhx1/904Y8kPLF6aHByeELQddSu78IbN/M NV0K7n3rve3TdAV8NQ8uJ533Iy2iyjKU/KyN1TpRxbRzYa//o08KyEd6HQqoNNcz3jWr xeFjsLK3oX+8lOMf16egELry8Q9ol0WARpjKegZHxRmVV2WdP4hW7cGt+u0npDLF+CdG zigw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to; bh=5g61G00PffAxeHm0sxRDgka8k+1P9efLNqPGj0SUAs0=; b=n++iXBT0VOwR94BTKSrFAOmgZidj2a1aKQH8c1uMHs9RcecGPHWBP9pwTZNMl70Z1k cZuy/Sj3bHKXTDpzmk2W6ehv7KePPn0QG7SN+xKXodF+pnwgA1/8UA8UCmvuAXVX/jNd ElVPPMtPbfp3y9+vK0DFz80zlAcyUzJpslQJfj4vHYv2BW3blQzHSCD47JGHCuhCb/J6 wdE4sFQN79oRtrgYwTTOf1X98Y/gy+G5fQft5pxFZSrpkbc2O373piwOOoSPxaR5jZU0 NWLfqehQ+lAg/I5Aa19FuA6lzLD8h2og0SZ65BOQPYw2e0hkCZaTCUK7Y0sQOAmTDSPg QVqQ== X-Gm-Message-State: AJaThX5Mqf1MHvTVdvhtBBa1kFKn/4IwghBvMM90TktCctEZ1YKlfM+A enKq/Hhv8jAQ0lnFTkl6CLJMrqk3pJ0= X-Google-Smtp-Source: AGs4zMbAEHbda6AxzbsiaXfGpF8+NqjKY6G2KhsqnQR/MfTeqbVX3Oj4IY18NGl5jTbmG0eZ6DQGJA== X-Received: by 10.99.191.10 with SMTP id v10mr926111pgf.291.1510822172086; Thu, 16 Nov 2017 00:49:32 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:98eb:22c2:3772:214d? ([2001:67c:370:128:98eb:22c2:3772:214d]) by smtp.gmail.com with ESMTPSA id g13sm1534749pgr.93.2017.11.16.00.49.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 00:49:31 -0800 (PST) Sender: Matthew Miller To: Jacob Hoffman-Andrews , Martin Thomson Cc: Richard Barnes , "acme@ietf.org" References: <3994bc53-7a68-c1f2-4a6b-64bbfd9ea99d@eff.org> <632eb456-bc9d-6e95-b414-137ce4b6a8e1@eff.org> <607b7f74-338a-40b6-5ba9-35c6aeace87f@eff.org> From: "Matthew A. Miller" Message-ID: <5f87fddf-e0ce-84f8-bb75-f4ed30c46b26@outer-planes.net> Date: Thu, 16 Nov 2017 16:49:28 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <607b7f74-338a-40b6-5ba9-35c6aeace87f@eff.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DLC108weeiBK73GreowfaXhULeuoTtuQm" Archived-At: Subject: Re: [Acme] Returning multiple errors 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, 16 Nov 2017 08:49:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DLC108weeiBK73GreowfaXhULeuoTtuQm Content-Type: multipart/mixed; boundary="cNrhwcAvGILwctCs6vVKRPUhswUK5NVXM"; protected-headers="v1" From: "Matthew A. Miller" To: Jacob Hoffman-Andrews , Martin Thomson Cc: Richard Barnes , "acme@ietf.org" Message-ID: <5f87fddf-e0ce-84f8-bb75-f4ed30c46b26@outer-planes.net> Subject: Re: [Acme] Returning multiple errors References: <3994bc53-7a68-c1f2-4a6b-64bbfd9ea99d@eff.org> <632eb456-bc9d-6e95-b414-137ce4b6a8e1@eff.org> <607b7f74-338a-40b6-5ba9-35c6aeace87f@eff.org> In-Reply-To: <607b7f74-338a-40b6-5ba9-35c6aeace87f@eff.org> --cNrhwcAvGILwctCs6vVKRPUhswUK5NVXM Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 17/11/16 16:47, Jacob Hoffman-Andrews wrote: > On 11/16/2017 12:45 AM, Martin Thomson wrote: >> I don't know what a random JSON parser would do with your stacked erro= r codes. > I don't understand. What I'm proposing is an array of JSON objects unde= r > the sub-problems field, which should be supported by any JSON parser. >=20 I don't think JSON text sequences is the right solution here, either. A JSON array seems perfectly appropriate to me. - m&m Matthew A. Miller --cNrhwcAvGILwctCs6vVKRPUhswUK5NVXM-- --DLC108weeiBK73GreowfaXhULeuoTtuQm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEMddYjeyQaQ1rzJjg7PRyThCeBbsFAloNURgACgkQ7PRyThCe Bbva3Qf/R+rLjXBHpp0UkON5FvmD3dhC1y2D8zKBhI6/xAHaN2Z/fcOKSJ9B4KXj vP4tH701jWA730aoA09/Of9me9GbBmDbfEgg/8pGPLqn4SiQZ122tz39bo9DqYpp PzKFiK7DNKkykadMoAdV+Fxgxq6BxSy+aHEbqzjCJ0dVbqVSOFOAanZAp8pJ4sAw W3MSiPup5U55wY+V6Esbn6iZCNARR/3SntszlDsTgw3VrdQ2OZMX4cinMe4EC9+3 w4sAJCDXsjT7L/scVMuQCfH1ZA6CJ7el7RmETxxT1FslwKdwxDsQR00+fJzzdflb 5mLzRJaO7tAZKzLNJaX3+54Ro90nEw== =sd4u -----END PGP SIGNATURE----- --DLC108weeiBK73GreowfaXhULeuoTtuQm-- From nobody Thu Nov 16 00:53:18 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2128B127369 for ; Thu, 16 Nov 2017 00:53:17 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6UyZmzGsBIM for ; Thu, 16 Nov 2017 00:53:15 -0800 (PST) Received: from mail-ot0-x244.google.com (mail-ot0-x244.google.com [IPv6:2607:f8b0:4003:c0f::244]) (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 B3FF9124217 for ; Thu, 16 Nov 2017 00:53:15 -0800 (PST) Received: by mail-ot0-x244.google.com with SMTP id v15so12751052ote.6 for ; Thu, 16 Nov 2017 00:53:15 -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=PsVMKEq7VvTszxZnUuAUfaoQx3BjGevqGQ8zukKqdsU=; b=TOqLBr24xM8wU18VWV6sa50lPP10i8zpGWsPxot+sed61FWa7/41hlHuJ3e+c7xnoA Bk42SELF8147B5Vci9vjy1aqlUMN/1xpagfzRs3hvstKV3jzU89mPmTHpm3lB1ytRJc/ VVgVP6Bz9q54RjfbK1u9Mz71Ia78NoxHxBj7ms7RRHXjwDQ60UNMTY7eo4oJem79oNyQ RJGtJwQcJf+ZP8QToJCjdgRnSZCk7rEwq7Gqp9+NpFmCgCGZJps3e5OckA5BiOUCwDsJ b3JUGOnO3h6SJ7KlKx6eAohvRYVohP0JenfcNbpuH/93Y2j1WSrNSwob9SuzFDXZcemj j8/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=PsVMKEq7VvTszxZnUuAUfaoQx3BjGevqGQ8zukKqdsU=; b=X/s787wTxfx5KIXCTv8j/P83ey7obXs2I+GHIRwoTdGgrXA2fnoGMDpKZt3Y8nN8IW dNh4+RvLW+CwpPhDqb72vNJDmGGwevRf2dxjoQpPh+WqyiEvtc2ZEjwebI0bp8TjAQ1u gAu0TuCtYtNCIfaTxOXzVIbBqeomal2UDAOWjNTJ1lDbgbuI0tv0oPSZ2079TQO1Cill LOvJ7yjOKfZdHcy8C/NV1m3QyXGtea3NyFK/9is92LruJ1L2ZGQZWZpRKTy71W26yb56 ueyiVQZv4YgdluRcBEFvESolmWrwb0L0fvQy7KfO/YSECMgSBPq54zfAPW1uxIvjOSdn N7Yw== X-Gm-Message-State: AJaThX53gq6amEIzrQKn+riK/S+XqjypLtpHta46LwrguaGDSdZymCPy wZO1/uzBQghrKoJVGTNOQivDk2fuB//T6Ypqbu8= X-Google-Smtp-Source: AGs4zMbB3y2jlGrTiPjBNGNQ/mLjKx04d0R4ToVGZ4fxyaDwIklW/J2dfRG4/uHPc2O8rjfsLK2K6MqW5FONs/lbDTk= X-Received: by 10.157.39.45 with SMTP id r42mr713304ota.71.1510822395079; Thu, 16 Nov 2017 00:53:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Thu, 16 Nov 2017 00:53:14 -0800 (PST) In-Reply-To: <5f87fddf-e0ce-84f8-bb75-f4ed30c46b26@outer-planes.net> References: <3994bc53-7a68-c1f2-4a6b-64bbfd9ea99d@eff.org> <632eb456-bc9d-6e95-b414-137ce4b6a8e1@eff.org> <607b7f74-338a-40b6-5ba9-35c6aeace87f@eff.org> <5f87fddf-e0ce-84f8-bb75-f4ed30c46b26@outer-planes.net> From: Martin Thomson Date: Thu, 16 Nov 2017 16:53:14 +0800 Message-ID: To: "Matthew A. Miller" Cc: Jacob Hoffman-Andrews , Richard Barnes , "acme@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Acme] Returning multiple errors 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, 16 Nov 2017 08:53:17 -0000 Oh, my bad, my eyes turn out to be a terrible JSON parser. On Thu, Nov 16, 2017 at 4:49 PM, Matthew A. Miller wrote: > On 17/11/16 16:47, Jacob Hoffman-Andrews wrote: >> On 11/16/2017 12:45 AM, Martin Thomson wrote: >>> I don't know what a random JSON parser would do with your stacked error codes. >> I don't understand. What I'm proposing is an array of JSON objects under >> the sub-problems field, which should be supported by any JSON parser. >> > > I don't think JSON text sequences is the right solution here, either. A > JSON array seems perfectly appropriate to me. > > > - m&m > > Matthew A. Miller > From nobody Thu Nov 16 05:22:29 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2BE7127ABE for ; Thu, 16 Nov 2017 05:22:26 -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 81JwQqd_H6aP for ; Thu, 16 Nov 2017 05:22:25 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F40ED120726 for ; Thu, 16 Nov 2017 05:22:24 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id f187so5885957itb.1 for ; Thu, 16 Nov 2017 05:22:24 -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=/YTbs3Pf9wkexBGZRTy579uE4vRJQWKLeTeCrXMraNE=; b=ecXIdGy8f2ZlqMzsOfzQlQv/+WF17T2A2rxXuLsdloZwPfooKny42I3ixgdv1TQ2ls Zya1jl3obOiBkwCgxefNTxe9jsMDSQNtmWRVaJ7aYis4g5jJjPrMHo1hmK3Kv0+/oiUv UZn/7iUP+IwYjnnfzipyhGz3jimHb4IJKNFSM= 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=/YTbs3Pf9wkexBGZRTy579uE4vRJQWKLeTeCrXMraNE=; b=EeaarFHm0eQ1GNP9tEBMEWC9GPoQx//U7HxiScF1AbIzFvaT+boHLiXsRVrCeFfGa+ C3zyNA7NiASwrTRFwNmMBwDACoBsmymt7zqbTzqj77Wsut7Xt70ltR2DZmvZNN/R1ZEx tIjE7H6U8jK2+3hSFbuYOSR35yGQnidWH0RnY5m9V6fIm/wIrOITP/aDPAmFi8r2Za5a Ix3fVQ9HLqeXNf6f+SbTuCoIC+uMMa64LWdAfT9e8T3jy3wOuFc/m4w+obOmovJchpiT eHf2lvmurg0saDvNv8hOoiUXZDntuqzGXijGCZJnYV/Lh5iBRWTNBUdzlEJ1/ktaS7e5 O0dA== X-Gm-Message-State: AJaThX4VgZ3Qb+5tglELGvSs0hxq1w8MNX0JUadPjmrERR0fuhhdCDa3 1ip5M9wu4L3hNeMsyEpGetPF3kQ1PFLwtSHVdjc/OQ== X-Google-Smtp-Source: AGs4zMbZh8MbYdkRK4OnmfkQd5uCZCoadEt5OcW7i+I2V+3Y38DT56fHjBT5o2J9h094Fft4JYAgmB5XY9zNgyyYE84= X-Received: by 10.36.4.144 with SMTP id 138mr2311797itb.78.1510838544299; Thu, 16 Nov 2017 05:22:24 -0800 (PST) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.32.144 with HTTP; Thu, 16 Nov 2017 05:22:23 -0800 (PST) In-Reply-To: <3994bc53-7a68-c1f2-4a6b-64bbfd9ea99d@eff.org> References: <3994bc53-7a68-c1f2-4a6b-64bbfd9ea99d@eff.org> From: Daniel McCarney Date: Thu, 16 Nov 2017 08:22:23 -0500 Message-ID: To: Jacob Hoffman-Andrews Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a114089d6bf1677055e1982ba" Archived-At: Subject: Re: [Acme] Returning multiple errors 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, 16 Nov 2017 13:22:27 -0000 --001a114089d6bf1677055e1982ba Content-Type: text/plain; charset="UTF-8" I think this is a solid proposal addressing a real need. I'm +1 for supporting it both in spec and in Boulder/Pebble. Thanks Jacob, On Wed, Nov 15, 2017 at 8:23 PM, Jacob Hoffman-Andrews wrote: > In previous versions of ACME, there was sometimes a need to return > multiple errors, broken out by domain name. For instance, when issuing a > certificate by making a new-cert request, the CA has to check CAA, which > may fail for multiple domains. Ideally, the client should not have to > guess which identifiers (domains) failed, or engage in string parsing. > So far, this hasn't been terrible because *most* errors occur during > new-authz or during validation, and so are implicitly associated with a > specific identifier. > > However, in the latest spec, this problem is a lot worse. Since all > issuance starts with new-order, which can request multiple identifiers, > all attempts to issue for multiple identifiers will potentially fail for > one or more of those identifiers. > > Fortunately, JSON problem details provide enough flexibility for this, > with problem-specific extensions > (https://tools.ietf.org/html/rfc7807#page-4). I propose we define a > field, "sub-problems", on all ACME problem types. This field would > contain a list of JSON problem details, each of which may contain an > identifier. So for instance, you might receive this response from a > new-order request: > > { > "type": "urn:ietf:params:acme:error:malformed", > "detail": "Some of the identifiers requested were rejected", > "sub-problems": [ { > "identifier": { "value": "_example.com", "type": "dns" }, > "type": "urn:ietf:params:acme:error:malformed", > "value": "Invalid underscore in DNS name \"_example.com\"", > }, { > "identifier": { "value": "example.net", "type": "dns" }, > "type": "urn:ietf:params:acme:error:malformed", > "value": "\"example.net\" is considered a high-risk domain", > } ] > } > > That way, clients that issue for large numbers of domains may choose to > automatically retry new-order with the problem identifiers removed. > > Thoughts? > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a114089d6bf1677055e1982ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think this is a solid proposal addressing a real need. I= 'm +1 for supporting it both in spec and in Boulder/Pebble.

Than= ks Jacob,

On= Wed, Nov 15, 2017 at 8:23 PM, Jacob Hoffman-Andrews <= jsha@eff.org> wrote:
In previous versions of ACME, t= here was sometimes a need to return
multiple errors, broken out by domain name. For instance, when issuing a certificate by making a new-cert request, the CA has to check CAA, which may fail for multiple domains. Ideally, the client should not have to
guess which identifiers (domains) failed, or engage in string parsing.
So far, this hasn't been terrible because *most* errors occur during new-authz or during validation, and so are implicitly associated with a
specific identifier.

However, in the latest spec, this problem is a lot worse. Since all
issuance starts with new-order, which can request multiple identifiers,
all attempts to issue for multiple identifiers will potentially fail for one or more of those identifiers.

Fortunately, JSON problem details provide enough flexibility for this,
with problem-specific extensions
(https://tools.ietf.org/html/rfc7807#page-4). I p= ropose we define a
field, "sub-problems", on all ACME problem types. This field woul= d
contain a list of JSON problem details, each of which may contain an
identifier. So for instance, you might receive this response from a
new-order request:

{
=C2=A0 "type": "urn:ietf:params:acme:error:malformed&qu= ot;,
=C2=A0 "detail": "Some of the identifiers requested were rej= ected",
=C2=A0 "sub-problems": [ {
=C2=A0=C2=A0=C2=A0 "identifier": { "value": "_example.com= ", "type": "dns" },
=C2=A0=C2=A0=C2=A0 "type": "urn:ietf:params:acme:error:= malformed",
=C2=A0=C2=A0=C2=A0 "value": "Invalid underscore in DNS name = \"_example.com\"",
=C2=A0 }, {
=C2=A0=C2=A0=C2=A0 "identifier": { "value": "example.net<= /a>", "type": "dns" },
=C2=A0=C2=A0=C2=A0 "type": "urn:ietf:params:acme:error:= malformed",
=C2=A0=C2=A0=C2=A0 "value": "\"example.net\" is consi= dered a high-risk domain",
=C2=A0 } ]
}

That way, clients that issue for large numbers of domains may choose to
automatically retry new-order with the problem identifiers removed.

Thoughts?

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

--001a114089d6bf1677055e1982ba-- From nobody Thu Nov 16 14:28:32 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F151271FD for ; Thu, 16 Nov 2017 14:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 Cep22OlFb3UE for ; Thu, 16 Nov 2017 14:28:29 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0545E126BF3 for ; Thu, 16 Nov 2017 14:28:28 -0800 (PST) Received: by mail-oi0-x22a.google.com with SMTP id e142so425559oih.2 for ; Thu, 16 Nov 2017 14:28:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=2/+TDxAXGuesAu2wZXabkDScQ2jgbAJjHGV2UIWucVc=; b=Z8QckPrq1PXrcH/SOm/wIlMf5mMvT+/Bin4FFeCg7+7+0ugHlGtpd4W/LEfHdG6fIt 9UFtKrCAtCBThB2G4ejBiZVfMy1KzFRbPppgNHH36QwWSOisU/de9wF4+bAVRH3B8i/s s5MHWT+UEaUVo2nqjwynxFPujjgSX/AJOhpbI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=2/+TDxAXGuesAu2wZXabkDScQ2jgbAJjHGV2UIWucVc=; b=tui5mMLSm2bUz0ZQQmd6pFM3zlJ0X8YRwJEQztzG8BKVdj6hmXgdDrl3Rz7DFbpSIQ +QPQKpndrh6uEvFRmK09wYVVOEEM/8bbYQWbvbIB07xuUHN6OvTVAiArqeyq043Dp67n k2u2DqRquTsUowF9W1jjRKV+y++/V1prtLd6K9nUlHqhasW4hoOrZtMY2bBDNerkxFLV NLow80MI8mFO8TvYH5PtsSO5ER2sdYWT/XlI4JsBt9PGGrj/t1uFnazwJtayqmWPkawM p+EXz1XzBM7ynqHWE73BeiJ1vj2yC22Vp74hPbziRLJZcSS76A/e9eKQezExtnoR5nMb 5smw== X-Gm-Message-State: AJaThX48haaoYV7BSfWajxUq/1mzFKE2n3oG6T8RS7/Wh0atIs4pIifr mnWkoG+by47W6KE4/Tkv+N7pgFB2Yw8= X-Google-Smtp-Source: AGs4zMb8UrRaVX5znSRRFQNsDtRdcVbNUUJFZvi97bBpIR0UVyPwOxFCKUKg+VNF0ma7FjdHDA2MCg== X-Received: by 10.202.228.70 with SMTP id b67mr2018709oih.283.1510871307834; Thu, 16 Nov 2017 14:28:27 -0800 (PST) Received: from ?IPv6:2600:1700:b000:9780:644d:c698:ffb2:607f? ([2600:1700:b000:9780:644d:c698:ffb2:607f]) by smtp.gmail.com with ESMTPSA id r184sm854230oia.40.2017.11.16.14.28.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 14:28:27 -0800 (PST) To: "acme@ietf.org" From: Roland Bracewell Shoemaker Message-ID: Date: Thu, 16 Nov 2017 14:28:25 -0800 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] 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: Thu, 16 Nov 2017 22:28:31 -0000 Hey all, First off I'd like to apologize for requesting an agenda item then not making it to the meeting to discuss it. It seems that while I had the right time in my calendar I managed to get the wrong day. 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. Thanks, Roland From nobody Thu Nov 16 17:28: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 46595124E15 for ; Thu, 16 Nov 2017 17:28:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 atAadFIQtUjh for ; Thu, 16 Nov 2017 17:28:56 -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 35793124239 for ; Thu, 16 Nov 2017 17:28:56 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAH1QT2B012491; Fri, 17 Nov 2017 01:28:51 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=TUt44GUiG8+uh7TopeedzCbAGCTd7iVDfJxellq8L3o=; b=iYavqXDOU+doGhUI+WGBLy3vj2PbdYu/k7tpGLRzYtWPWy0JDikS2NaNjFigAEQgNxiM XrOCZzkmM0b/4w+95SIhxj+xdAMhn4G7r9tXVmAAvasdi+T/PyTmW7ItuYBCX2pxCyzo 232nwWKAX4NECbH32K9R7nqhtiuxIHN/dwQbhKdKyF3pga/0cfTkorCDnYez2vvtUBtS F0EMLL4kMF+Ahe6I2yy638QFhzA+RJ/lacjt3FAS44sQNKQgAWhsD+p3e7pHY9/IFEac mf3y02L4BHoyFH96d0WP8pz9IywTymKJlTLUpvEMIeGAk2y0PdnfihHVN8mBm0e7Ua5j FA== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050093.ppops.net-00190b01. with ESMTP id 2e8d4bxmx0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Nov 2017 01:28:50 +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 vAH1PvDm032347; Thu, 16 Nov 2017 20:28:49 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2e7p3wutp9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 16 Nov 2017 20:28:49 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 16 Nov 2017 20:28:48 -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; Thu, 16 Nov 2017 20:28:48 -0500 From: "Salz, Rich" To: "Dale R. Worley" , "acme@ietf.org" Thread-Topic: [Acme] Resend: [Gen-art] Genart telechat review of draft-ietf-acme-acme-07] Thread-Index: AQHTXbx0+bV5Ovc0ckiynLZUwP5lqKMYHysA Date: Fri, 17 Nov 2017 01:28:48 +0000 Message-ID: References: <87d14kuuga.fsf@hobgoblin.ariadne.com> In-Reply-To: <87d14kuuga.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.147.37] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-16_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711170019 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-16_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711170019 Archived-At: Subject: Re: [Acme] Resend: [Gen-art] Genart telechat review of draft-ietf-acme-acme-07] 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, 17 Nov 2017 01:28:57 -0000 VGhhbmsgeW91IGZvciB0aGUgZGV0YWlsZWQgZmVlZGJhY2shDQoNCkFzIGFubm91bmNlZCBhdCB0 aGUgbWVldGluZyBvbiBUaHVyc2RheSwgdGhlIGVkaXRvcuKAmXMgcGxhbiBpcyB0byBhZGRyZXNz IHRoZSBtYWpvciB0ZWNobmljYWwgaXNzdWUgYW5kIHN0YXJ0IGxvb2tpbmcgYXQgeW91ciByZXZp ZXcuICBXZeKAmWxsIHB1dCBvdXQgYW5vdGhlciBkcmFmdCwgYW5kIHBlcmhhcHMgZG8gYSBsaW1p dGVkIFdHTEMgdGhhdCBmb2N1c2VzIG9uIGp1c3QgdGhlIG5vdC1wdXJlbHktZWRpdG9yaWFsIGNo YW5nZXMuDQoNCg== From nobody Fri Nov 17 08:12: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 74DE1128B90 for ; Fri, 17 Nov 2017 08:12:49 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNP7gnLaaCvJ for ; Fri, 17 Nov 2017 08:12:46 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57C58128BB6 for ; Fri, 17 Nov 2017 08:12:46 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id o130so2775892itg.0 for ; Fri, 17 Nov 2017 08:12:46 -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; bh=rjwPcavONpcBtIAVYcfwm/U9z/zj2JQfe0J7BSGd1WY=; b=uD/Cs9g7GqEXMsG87elw3nwEbBYudeGOKt/b05/2fZThxd1y67e/hxSukMp/3Eu11M 3f2X31zRsPUUglPqDzCeqiF5b17cwBDMl8MdAiwVZmpxNQAP7SLUo072tZNBjrO303n9 1CdrPaZpV6v1+cM1uI6tagneODwkE+sUklrMznv8u51PjHi7zITAb/qzO5pXSqbXVOKU Tj2/yI9CbFFGFt6TjBLRHisbIYxq7bEtvoy1fpmRll8dPUpqWDUfaqc+OCR4ClzbxMDk Ez/N/Vle1M9cB4N/I+KwiDRUAwwqNYJ661/G5gOn1AgmPTAO0hkymrseoMls7j9IUtE2 Z8sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=rjwPcavONpcBtIAVYcfwm/U9z/zj2JQfe0J7BSGd1WY=; b=sn1O4tYb1us8vWHnbWeHlDJJmf5FLvcFXJgu/AaNX3hsudPaOihWEoffrGdqOW7NOQ /FZLDe3f4g0FTAV8YL3e88mba6oQSjBvlzO/+3W8Tq9JBHAfPjHYxV4TX2Aq0KAtRJzw M59yCkGMLIKib9p7uQUK8uUq3bTi4EFjff7Pm7i5bRliEv3o1sWCRJgXevmQlJQEf9jY jCVLPnWAQd7IKn4xLB5rDylCfbR48OhRhAmNBIQT2KdD0PK6ARYGrP8l8FYLZz9+gTb1 x/tRZg/4fmaewUmt4mWjIawli/zcXwaHGi+2UOUD3N97oA0klfT4y45MOwACufM4Qr+J MKIQ== X-Gm-Message-State: AJaThX4++bu7lJh/PfUXi4q3PSIpREMNns7Zf2hXQNdnaeNULSKLSgLU cMhuMegMznzTDrfq3MOxZCeD7K6tkVcCPJjTNz8= X-Google-Smtp-Source: AGs4zMZuX4r58kwYVOYXzPEULqhWqUKDGPEl5pzcrwV4nbpvXeUXwryFPoOTMYRh6OQWOM/jnTYKymAihAZIGXcarS0= X-Received: by 10.36.173.27 with SMTP id c27mr7213408itf.138.1510935165485; Fri, 17 Nov 2017 08:12:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.176.130 with HTTP; Fri, 17 Nov 2017 08:12:45 -0800 (PST) In-Reply-To: References: From: Logan Widick Date: Fri, 17 Nov 2017 10:12:45 -0600 Message-ID: To: ACME WG Content-Type: multipart/alternative; boundary="94eb2c1fc9a4d14769055e300181" Archived-At: Subject: Re: [Acme] Allowable "tel" contacts; publishing allowed contact schemes and their ACME-specific restrictions X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 16:12:49 -0000 --94eb2c1fc9a4d14769055e300181 Content-Type: text/plain; charset="UTF-8" Or, would it be best to remove the non-mailto contacts from the examples, and add a note indicating that "mailto" is the only contact URI scheme currently supported by the ACME standards? Sincerely, Logan Widick On Wed, Oct 25, 2017 at 3:18 PM, Logan Widick wrote: > This is related to my previous "Allowable mailto contacts" thread earlier > this month. However, this is about a different type of contact, so I > decided to start a new thread. > > Although ACME servers don't have to include support for "tel" (RFC 3966) > contacts, "tel" contacts appear in multiple examples in the ACME > specification. Thus, some may try to include "tel" contact support in their > ACME server implementations. > > Although the example "tel" contacts in the ACME specification seem to > indicate a simple, narrow subset (the "global-number" with zero "par" > instances), the "tel" specification has many more possible productions. For > example, both "global-number" and "local-number" may have "par" instances > (like ";name1=value1;name2=value2") after the phone numbers. > > Assuming I understand the "local-number" specification correctly, a > "local-number" could potentially contain a pound sign ("#") for reasons > related to DTMF. If I understand the current and past URI specifications > correctly, this could be problematic. Specifically, a URI parser may put > the parts of the "local-number" after a "#" in the fragment. > > If someone wanted to implement "tel" contact support for an ACME server, > what subset of "tel" would be required? Would both "global-number" and > "local-number" instances be allowed? What restrictions would apply to > "global-number" and "local-number" instances? Which types of "par" > instances would be allowed? Extension? ISDN-subaddress? Others? > > On a more general note, I think that as ACME becomes more widely used, the > subject of what subsets of what contact URI schemes would be allowed under > ACME (as opposed to what schemes are supported by a specific ACME server, > which was a separate issue already discussed in March on the mailing list > under "Allowing clients to understand the account creation functionality > supported by a server") may come up more often. Would it be a good idea to > request the creation of an "ACME Contact Schemes Registry" like in the > ASCII art figures below? > > > > > +--------+-----------+-----------+-------------------------- > -------------------+ > | Scheme | Status | Reference | ACME Restrictions > | > +--------+-----------+-----------+-------------------------- > -------------------+ > | mailto | Mandatory | RFC 6068 | Exactly one "addr-spec" in the "to" > portion | > | | | | No "hfields" are allowed > | > | | | | [Source: "Allowable mailto contacts" > thread]| > +--------+-----------+-----------+-------------------------- > -------------------+ > | tel | Optional | RFC 3966 | [insert restrictions picked in this > thread] | > +--------+-----------+-----------+-------------------------- > -------------------+ > > Figure 1: A possible "ACME Contact Schemes Registry" table. In this > version, the ACME restrictions on the original contact scheme > specifications are stated in the table, and the original contact scheme > specification is listed as the "Reference". These relationships are > depicted graphically in Figure 2 (below). > > > > > +-----------------------+ +--------------------+ > | RFC 6068 (mailto RFC) | | RFC 3966 (tel RFC) | > +-----------------------+ +--------------------+ > > Figure 2: RFC relationships for Figure 1 > > > > > +--------+-----------+---------------------------+ > | Scheme | Status | Reference | > +--------+-----------+---------------------------+ > | mailto | Mandatory | RFC XXXX | > | | | (ACME RFC) | > | | | | > +--------+-----------+---------------------------+ > | tel | Optional | RFC YYYY | > | | | (Some RFC after RFC XXXX) | > +--------+-----------+---------------------------+ > > Figure 3: Another possible "ACME Contact Schemes Registry" table. In this > version, the "Reference" RFCs discuss the ACME-specific restrictions for > the contact schemes, and refer to the original specifications for the > contact schemes. These relationships are depicted graphically in Figure 4 > (below). > > > > > +-----------------------------+ > | ACME restrictions on mailto | > +----------+------------------+ > ^ > | > | Contains > | > +----------+----------+ +--------------+ > | RFC XXXX (ACME RFC) | References | RFC 6068 | > + +----------------> + (mailto RFC) | > | | | | > +----------+----------+ +--------------+ > ^ > | > | References > | > +----------+-------------------+ +-----------+ > | RFC YYYY | References | RFC 3966 | > + (An RFC after RFC XXXX) +----------------> + (tel RFC) | > | | | | > +----------+-------------------+ +-----------+ > ^ > | > | Contained in > | > +----------+------------------+ > | ACME Restrictions on tel | > +-----------------------------+ > > Figure 4: RFC relationships for Figure 3 version of "ACME Contact Schemes > Registry" > --94eb2c1fc9a4d14769055e300181 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Or, would it be best to remove the non-mailto contacts fro= m the examples, and add a note indicating that "mailto" is the on= ly contact URI scheme currently supported by the ACME standards?=C2=A0
=

Sincerely,=C2=A0

Logan Widick<= /div>

= On Wed, Oct 25, 2017 at 3:18 PM, Logan Widick <logan.widick@gmail.com= > wrote:
<= font face=3D"monospace, monospace">This is related to my previous "All= owable mailto contacts" thread earlier this month. However, this is ab= out a different type of contact, so I decided to start a new thread.
Although ACME servers don't have to include support for "tel"= ; (RFC 3966) contacts, "tel" contacts appear in multiple examples= in the ACME specification. Thus, some may try to include "tel" c= ontact support in their ACME server implementations.

Although the ex= ample "tel" contacts in the ACME specification seem to indicate a= simple, narrow subset (the "global-number" with zero "par&q= uot; instances), the "tel" specification has many more possible p= roductions. For example, both "global-number" and "local-num= ber" may have "par" instances (like ";name1=3Dvalue1;na= me2=3Dvalue2") after the phone numbers.

Assuming I understand t= he "local-number" specification correctly, a "local-number&q= uot; could potentially contain a pound sign ("#") for reasons rel= ated to DTMF. If I understand the current and past URI specifications corre= ctly, this could be problematic. Specifically, a URI parser may put the par= ts of the "local-number" after a "#" in the fragment.= =C2=A0

If someone wanted to implement "tel" contact suppor= t for an ACME server, what subset of "tel" would be required? Wou= ld both "global-number" and "local-number" instances be= allowed? What restrictions would apply to "global-number" and &q= uot;local-number" instances? Which types of "par" instances = would be allowed? Extension? ISDN-subaddress? Others?

On a more gene= ral note, I think that as ACME becomes more widely used, the subject of wha= t subsets of what contact URI schemes would be allowed under ACME (as oppos= ed to what schemes are supported by a specific ACME server, which was a sep= arate issue already discussed in March on the mailing list under "Allo= wing clients to understand the account creation functionality supported by = a server") may come up more often. Would it be a good idea to request = the creation of an "ACME Contact Schemes Registry" like in the AS= CII art figures below?=C2=A0




+--------+-----------+-----= ------+---------------------------------------------+
| Scheme= | Status =C2=A0 =C2=A0| Reference | ACME Restrictions=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+--------+-----------+-----------+---------------------------------------------+
| mailto | Mandatory | RFC 6068 =C2=A0| Exactly = one "addr-spec" in the "to" portion |
| =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | No "hfields" are allowed=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| [Source: &q= uot;Allowable mailto contacts" thread]|
+--------+-----------+-----= ------+---------------------------------------------+
| tel = =C2=A0 =C2=A0| Optional =C2=A0| RFC 3966 =C2=A0| [insert restrictions picke= d in this thread] |
+--------+-----------+-----------+-------------= --------------------------------+

Figure 1: A possible "ACME Contact Schemes Registry" table.= =C2=A0In this versio= n, the ACME restrictions=C2=A0on the original contact scheme specifications are stated in the t= able,=C2=A0and the o= riginal contact scheme specification is listed as the "Reference"= . These relationships are depicted graphically in Figure 2 (below).=C2=A0 = =C2=A0




+-------= ----------------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------------------+<= /div>
| RFC 6068 (mailto RFC) |=C2= =A0 =C2=A0 =C2=A0 =C2=A0 | RFC 3966 (tel RFC) |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
+-----------------------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--= ------------------+
Figure 2: RFC = relationships for Figure 1



<= font face=3D"monospace, monospace">
+--------+-----------+---------------------------+| Scheme | Status =C2=A0 =C2=A0| Reference=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+--------+-----------+------------= ---------------+
| mailto | Mandatory | RFC XXXX=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0
| =C2=A0 =C2=A0 =C2=A0 = =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | (ACME RFC)=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+--------+-----------+---------------------------+
| tel =C2=A0 =C2=A0| Optional =C2=A0| RFC YYYY= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| (Some RFC after RFC XXXX) |=C2= =A0
+--------+-----------+---------------------------+
=

Figure 3: Another possible "ACME Contact= Schemes Registry" table.=C2=A0In this version, the "Reference" RFCs discuss=C2= =A0the ACME-specific= restrictions for the contact schemes,=C2=A0and refer to the original specifications for the co= ntact schemes. These relationships are depicted graphically in Figure 4 (be= low).=C2=A0




+--= ---------------------------+
| ACME restrictions on mailto |
+----------+------------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0^
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Contains
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= |
+----------+--------= --+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------= ------+
| RFC XXXX (AC= ME RFC) |=C2=A0 =C2=A0 References=C2=A0 =C2=A0 | RFC 6068=C2=A0 =C2=A0 =C2= =A0|
+=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+------------= ----> +=C2=A0(mailto RFC)=C2=A0|=C2=A0
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+----------+----------+=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0+-------------= -+
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0^
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| References
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+----------+-------------------+=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------+
=
| RFC YYYY=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 Referenc= es=C2=A0 =C2=A0 | RFC 3966=C2=A0=C2=A0|
+=C2=A0(An RFC after RFC XXXX)=C2=A0 =C2=A0 =C2=A0 +-----= -----------> +=C2=A0(tel RFC)=C2=A0|=C2=A0
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|
+------= ----+-------------------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0=C2=A0+-----------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|=C2=A0
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Contained in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=
+----------+----------------= --+
| ACME Restri= ctions on tel=C2=A0 =C2=A0 |
+-----------------------------+

Figure 4: RFC relationships for Figure 3 version of "ACME C= ontact Schemes Registry"

--94eb2c1fc9a4d14769055e300181-- From nobody Fri Nov 17 09:17:32 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E81C12896F for ; Fri, 17 Nov 2017 09:17:30 -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 AD0waSY1lVni for ; Fri, 17 Nov 2017 09:17:27 -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 4E63D1242F5 for ; Fri, 17 Nov 2017 09:17:27 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id i38so9465486iod.2 for ; Fri, 17 Nov 2017 09:17:27 -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=348+Le+fISXThKbAtRehqgSk8T5kecdzwKPlVKshiNw=; b=XqEzeUlVxg9zIwdC0RJSNz5C56URZ8N12D49tWwQaA4X6HjTHn50WakM1PNaw6w4xi BjqEWoxTbfPGWNeUj3IA2n4N4h2r6OBe+lCYri1JNJREwbQbrAbE7MBvA6ShM7I/ET56 jBKqvWQv+QTDzxC+ewmU1AykgR27sJhKcxpvo= 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=348+Le+fISXThKbAtRehqgSk8T5kecdzwKPlVKshiNw=; b=m0OjKlWsikLoDfLDquSg0CDPV2xaw7Bxz9LHT5cak6QyThnbXLzqxP9tE60Y9GKkCC n/YIfkEymSuWPROvuE2RzPdRSk1eG/CoCgAAmWPJpOFIab6jSSS+wAC2s1pafgRwE8ur /e/wFiexvz0Ty3o+UsGFrxl7SPbEv8tkw+gpN8FbWwtw3FFnHlH80HQOyelYFDxHYSZQ 8A/ciXupty/DNKlRwVK8Pfloz9crv1EbLPpzRSBFH5Ns5KfOV89QFwFslF2invNAPjue w0u+yjuGB2DjRnhGbcffvuSR20RTzg7BiCMjSeMmhg3ARBu2GlORN2gI+aGMUxSttS9P U+6A== X-Gm-Message-State: AJaThX6aseS78+SkxDtEw9OIDITXKnW1VorDAul270A7985dRrlbOYjX P9ZXoyd53FilnRnO004TzUmGMImqtfFq2/fS4jI6MJjglz0= X-Google-Smtp-Source: AGs4zMZ2mUAtGNvDMO0rhAi+uR5L2QlhoeU55w5Z/Dc7u3Khwt+u2ZDpW8JA+ex5XYDlNq+deXhIFcIukW7yV63MUAM= X-Received: by 10.107.43.75 with SMTP id r72mr3744536ior.31.1510939045687; Fri, 17 Nov 2017 09:17:25 -0800 (PST) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.32.144 with HTTP; Fri, 17 Nov 2017 09:17:25 -0800 (PST) In-Reply-To: References: From: Daniel McCarney Date: Fri, 17 Nov 2017 12:17:25 -0500 Message-ID: To: Logan Widick Cc: ACME WG Content-Type: multipart/alternative; boundary="001a113949f0188cff055e30e9ed" Archived-At: Subject: Re: [Acme] Allowable "tel" contacts; publishing allowed contact schemes and their ACME-specific restrictions X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 17:17:30 -0000 --001a113949f0188cff055e30e9ed Content-Type: text/plain; charset="UTF-8" I would be supportive of removing non-mailto contact examples. I don't think it's accurate to say that "mailto" is the only contact scheme currently supported by the ACME standard. That isn't the case for the spec as-written today - it is the only mandatory contact scheme. I believe its been left intentionally open ended what other schemes may be supported by a server. In my mind ACME servers wishing to support `tel` should come up with their own understanding of what parts of the relevant RFCs they support and use the `unsupportedContact` and `invalidContact` errors as appropriate based on the `tel://` contacts received. I don't think there is value trying to create a subprofile of `tel` for ACME use that is defined in the ACME draft. - cpu On Fri, Nov 17, 2017 at 11:12 AM, Logan Widick wrote: > Or, would it be best to remove the non-mailto contacts from the examples, > and add a note indicating that "mailto" is the only contact URI scheme > currently supported by the ACME standards? > > Sincerely, > > Logan Widick > > On Wed, Oct 25, 2017 at 3:18 PM, Logan Widick > wrote: > >> This is related to my previous "Allowable mailto contacts" thread earlier >> this month. However, this is about a different type of contact, so I >> decided to start a new thread. >> >> Although ACME servers don't have to include support for "tel" (RFC 3966) >> contacts, "tel" contacts appear in multiple examples in the ACME >> specification. Thus, some may try to include "tel" contact support in their >> ACME server implementations. >> >> Although the example "tel" contacts in the ACME specification seem to >> indicate a simple, narrow subset (the "global-number" with zero "par" >> instances), the "tel" specification has many more possible productions. For >> example, both "global-number" and "local-number" may have "par" instances >> (like ";name1=value1;name2=value2") after the phone numbers. >> >> Assuming I understand the "local-number" specification correctly, a >> "local-number" could potentially contain a pound sign ("#") for reasons >> related to DTMF. If I understand the current and past URI specifications >> correctly, this could be problematic. Specifically, a URI parser may put >> the parts of the "local-number" after a "#" in the fragment. >> >> If someone wanted to implement "tel" contact support for an ACME server, >> what subset of "tel" would be required? Would both "global-number" and >> "local-number" instances be allowed? What restrictions would apply to >> "global-number" and "local-number" instances? Which types of "par" >> instances would be allowed? Extension? ISDN-subaddress? Others? >> >> On a more general note, I think that as ACME becomes more widely used, >> the subject of what subsets of what contact URI schemes would be allowed >> under ACME (as opposed to what schemes are supported by a specific ACME >> server, which was a separate issue already discussed in March on the >> mailing list under "Allowing clients to understand the account creation >> functionality supported by a server") may come up more often. Would it be a >> good idea to request the creation of an "ACME Contact Schemes Registry" >> like in the ASCII art figures below? >> >> >> >> >> +--------+-----------+-----------+-------------------------- >> -------------------+ >> | Scheme | Status | Reference | ACME Restrictions >> | >> +--------+-----------+-----------+-------------------------- >> -------------------+ >> | mailto | Mandatory | RFC 6068 | Exactly one "addr-spec" in the "to" >> portion | >> | | | | No "hfields" are allowed >> | >> | | | | [Source: "Allowable mailto contacts" >> thread]| >> +--------+-----------+-----------+-------------------------- >> -------------------+ >> | tel | Optional | RFC 3966 | [insert restrictions picked in this >> thread] | >> +--------+-----------+-----------+-------------------------- >> -------------------+ >> >> Figure 1: A possible "ACME Contact Schemes Registry" table. In this >> version, the ACME restrictions on the original contact scheme >> specifications are stated in the table, and the original contact scheme >> specification is listed as the "Reference". These relationships are >> depicted graphically in Figure 2 (below). >> >> >> >> >> +-----------------------+ +--------------------+ >> | RFC 6068 (mailto RFC) | | RFC 3966 (tel RFC) | >> +-----------------------+ +--------------------+ >> >> Figure 2: RFC relationships for Figure 1 >> >> >> >> >> +--------+-----------+---------------------------+ >> | Scheme | Status | Reference | >> +--------+-----------+---------------------------+ >> | mailto | Mandatory | RFC XXXX | >> | | | (ACME RFC) | >> | | | | >> +--------+-----------+---------------------------+ >> | tel | Optional | RFC YYYY | >> | | | (Some RFC after RFC XXXX) | >> +--------+-----------+---------------------------+ >> >> Figure 3: Another possible "ACME Contact Schemes Registry" table. In >> this version, the "Reference" RFCs discuss the ACME-specific >> restrictions for the contact schemes, and refer to the original >> specifications for the contact schemes. These relationships are depicted >> graphically in Figure 4 (below). >> >> >> >> >> +-----------------------------+ >> | ACME restrictions on mailto | >> +----------+------------------+ >> ^ >> | >> | Contains >> | >> +----------+----------+ +--------------+ >> | RFC XXXX (ACME RFC) | References | RFC 6068 | >> + +----------------> + (mailto RFC) | >> | | | | >> +----------+----------+ +--------------+ >> ^ >> | >> | References >> | >> +----------+-------------------+ +-----------+ >> | RFC YYYY | References | RFC 3966 | >> + (An RFC after RFC XXXX) +----------------> + (tel RFC) | >> | | | | >> +----------+-------------------+ +-----------+ >> ^ >> | >> | Contained in >> | >> +----------+------------------+ >> | ACME Restrictions on tel | >> +-----------------------------+ >> >> Figure 4: RFC relationships for Figure 3 version of "ACME Contact Schemes >> Registry" >> > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --001a113949f0188cff055e30e9ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would be supportive of removing non-mailto contact examp= les.

I don't think it's accurate to say that "mailto&q= uot; is the only contact scheme currently supported by the ACME standard. T= hat isn't the case for the spec as-written today - it is the only manda= tory contact scheme. I believe its been left intentionally open ended what = other schemes may be supported by a server.

In my mind ACME servers = wishing to support `tel` should come up with their own understanding of wha= t parts of the relevant RFCs they support and use the `unsupportedContact` = and `invalidContact` errors as appropriate based on the `tel://` contacts r= eceived. I don't think there is value trying to create a subprofile of = `tel` for ACME use that is defined in the ACME draft.

- cpu=C2=A0


On= Fri, Nov 17, 2017 at 11:12 AM, Logan Widick <logan.widick@gmail.com= > wrote:
O= r, would it be best to remove the non-mailto contacts from the examples, an= d add a note indicating that "mailto" is the only contact URI sch= eme currently supported by the ACME standards?=C2=A0

Sincerely,=C2=A0

Logan Widick

On Wed, Oct 25, 2017 at 3:18 PM, Logan Widick <= ;logan.widick@g= mail.com> wrote:
This is related to my previous= "Allowable mailto contacts" thread earlier this month. However, = this is about a different type of contact, so I decided to start a new thre= ad.

Although ACME servers don't have to include support for &quo= t;tel" (RFC 3966) contacts, "tel" contacts appear in multipl= e examples in the ACME specification. Thus, some may try to include "t= el" contact support in their ACME server implementations.

Altho= ugh the example "tel" contacts in the ACME specification seem to = indicate a simple, narrow subset (the "global-number" with zero &= quot;par" instances), the "tel" specification has many more = possible productions. For example, both "global-number" and "= ;local-number" may have "par" instances (like ";name1= =3Dvalue1;name2=3Dvalue2") after the phone numbers.

Assuming I = understand the "local-number" specification correctly, a "lo= cal-number" could potentially contain a pound sign ("#") for= reasons related to DTMF. If I understand the current and past URI specific= ations correctly, this could be problematic. Specifically, a URI parser may= put the parts of the "local-number" after a "#" in the= fragment.=C2=A0

If someone wanted to implement "tel" cont= act support for an ACME server, what subset of "tel" would be req= uired? Would both "global-number" and "local-number" in= stances be allowed? What restrictions would apply to "global-number&qu= ot; and "local-number" instances? Which types of "par" = instances would be allowed? Extension? ISDN-subaddress? Others?

On a= more general note, I think that as ACME becomes more widely used, the subj= ect of what subsets of what contact URI schemes would be allowed under ACME= (as opposed to what schemes are supported by a specific ACME server, which= was a separate issue already discussed in March on the mailing list under = "Allowing clients to understand the account creation functionality sup= ported by a server") may come up more often. Would it be a good idea t= o request the creation of an "ACME Contact Schemes Registry" like= in the ASCII art figures below?=C2=A0




+--------+-------= ----+-----------+---------------------------------------------+| Scheme | Status =C2=A0 =C2=A0| Reference | ACME Restrictions=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|
+--------+-----------+-----------+------------------= ---------------------------+
| mailto | Mandatory | RFC 6068 =C2=A0= | Exactly one "addr-spec" in the "to" portion |
| = =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | No "hfields" are allowed=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = [Source: "Allowable mailto contacts" thread]|
+--------+------= -----+-----------+---------------------------------------------+<= br>| tel =C2=A0 =C2=A0| Optional =C2=A0| RFC 3966 =C2=A0| [insert restricti= ons picked in this thread] |
+--------+-----------+-----------+----= -----------------------------------------+

Figure 1: A possible "ACME Contact Schemes Registry"= table.=C2=A0In this= version, the ACME restrictions=C2=A0on the original contact scheme specifications are stated i= n the table,=C2=A0an= d the original contact scheme specification is listed as the "Referenc= e". These relationships are depicted graphically in Figure 2 (below).= =C2=A0 =C2=A0




+= -----------------------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------------------+<= /font>
| RFC 6068 (mailto RFC= ) |=C2=A0 =C2=A0 =C2=A0 =C2=A0 | RFC 3966 (tel RFC) |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
+-----------------------+=C2=A0 =C2=A0 =C2=A0 =C2= =A0 +--------------------+

Figure = 2: RFC relationships for Figure 1




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

= Figure 3: Another possible "ACME C= ontact Schemes Registry" table.=C2=A0In this version, the "Reference" RFCs discu= ss=C2=A0the ACME-spe= cific restrictions for the contact schemes,=C2=A0and refer to the original specifications for t= he contact schemes. These relationships are depicted graphically in Figure = 4 (below).=C2=A0

<= /font>

=

| ACME restrictions on mailto |
+----------+------------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0^
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Contains
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0|
+----------+-= ---------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-= -------------+
| RFC X= XXX (ACME RFC) |=C2=A0 =C2=A0 References=C2=A0 =C2=A0 | RFC 6068=C2=A0 =C2= =A0 =C2=A0|
+=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-----= -----------> +=C2=A0(mailto RFC)=C2=A0|=C2=A0
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+----------+----------+= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0+------= --------+
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| References
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+----------+-------------------+=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------+
| RFC YYYY=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 R= eferences=C2=A0 =C2=A0 | RFC 3966=C2=A0=C2=A0|
+=C2=A0(An RFC after RFC XXXX)=C2=A0 =C2=A0 =C2= =A0 +----------------> +=C2=A0(tel RFC)=C2=A0|=C2=A0
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|
+----------+-------------------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0+-----------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|=C2=A0
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Contained in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= |
+----------+--------= ----------+
| ACM= E Restrictions on tel=C2=A0 =C2=A0 |
+-----------------------------+
=
Figure 4: RFC relationships for Figure 3 version of &quo= t;ACME Contact Schemes Registry"


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


--001a113949f0188cff055e30e9ed-- From nobody Fri Nov 17 11:32: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 1F4BA1241F5 for ; Fri, 17 Nov 2017 11:32:01 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=letsencrypt.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2XGLnon-ugg for ; Fri, 17 Nov 2017 11:31:58 -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 5FF24120454 for ; Fri, 17 Nov 2017 11:31:58 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id o130so3182961itg.0 for ; Fri, 17 Nov 2017 11:31:58 -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; bh=hlFhBvI8RFuCiU8jidUl3Zit7DbKgRzEdm5w7FV2No8=; b=DTADG5IzXcZTVLVmM2bQHGQRXh3As0/fXH1Ah8o0XxWszvpBEFgHmovLPBzGJZX2pr MkszON1dP0su9TZs72bTsIICi424vsAk5kOegoYXEJmgyclkMHe+snqeJEOeeSujNUNZ 8TkN+AbAqS5wX8T3m4MfEq5wWVmDbV7QUZWUk= 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; bh=hlFhBvI8RFuCiU8jidUl3Zit7DbKgRzEdm5w7FV2No8=; b=YKycyM9JBUKecVXhjixF9OtbfVwHb3uK+Fs2on44hzz4RZ/uj3mLAsSNV2GyLpnmUe YC7uAv0NRKX5xrqXm9Y3mwcBGLZ/fejyt4s/aVm7+dbN0AcKfHEVZ/WVcCU3ob1DpBY+ nUpFe1sg8vdeKWbueuM58JZaGvtTSk5BiSeM9d6MVWJ5NHt/FQtQTe1Twuqkdrehf9ps dU4HonKODarVeq7ouuz5ZajKpMYU7lI95OIGltLJlP7u4wGZoBVLZpKgvyenPp+H4/cl PGluM7giCIUzUBC2YgdCIBEFq167kExIL+nu27CHQO9fKULfi+Cc+c+lNDa27GJJenDE APjA== X-Gm-Message-State: AJaThX6NZbgQkFra/OwMgcehWmp+WOEZi55LjQ0G7r9LkPNrxpWq14l6 lnxQZlvIAb3W7N/Cf8P9MfrAFa5RrEOz33grX6G6QksLaCU= X-Google-Smtp-Source: AGs4zMZLFs/ZdJDS2YLF0IC9XD6jWcJ72RNnNE1atiUj+vufjilc3Y2AnaZKBKrISysJeRw0H14mDqRYFtzk92HmYNE= X-Received: by 10.36.10.73 with SMTP id 70mr7940915itw.145.1510947117557; Fri, 17 Nov 2017 11:31:57 -0800 (PST) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.32.144 with HTTP; Fri, 17 Nov 2017 11:31:57 -0800 (PST) In-Reply-To: References: From: Daniel McCarney Date: Fri, 17 Nov 2017 14:31:57 -0500 Message-ID: To: IETF ACME , Richard Barnes Content-Type: multipart/alternative; boundary="001a113f9ec437874c055e32cafd" Archived-At: Subject: Re: [Acme] Missing rationale for the Authorization "scope" field 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, 17 Nov 2017 19:32:01 -0000 --001a113f9ec437874c055e32cafd Content-Type: text/plain; charset="UTF-8" Richard: You and I are in agreement about removing scope. Nobody else has voiced any concerns after two weeks. Do you think you can merge https://github.com/ietf-wg-acme/acme/pull/349 this week? On Fri, Nov 3, 2017 at 12:26 PM, Daniel McCarney wrote: > Given that all issuance now goes through new-order, it's probably safe to >> remove this. If the client guesses wrong about what authz it needs, the >> server can tell it what else it needs to do. > > > > Sounds good to me. Here's a PR to do so: > > https://github.com/ietf-wg-acme/acme/pull/349 > > - Daniel / cpu > > On Thu, Nov 2, 2017 at 4:22 PM, Richard Barnes wrote: > >> I think the intent when we implemented it was to communicate to clients >> that an authz was only good for a single issuance, so that if a client was >> doing pre-authorization, they would know that that authorization wouldn't >> be reused. >> >> Given that all issuance now goes through new-order, it's probably safe to >> remove this. If the client guesses wrong about what authz it needs, the >> server can tell it what else it needs to do. >> >> --Richard >> >> On Thu, Nov 2, 2017 at 2:52 PM, Daniel McCarney >> wrote: >> >>> Section 7.1.4 "Authorization Objects" describes an optional "scope" >>> field. If present it must be a URI pointing to an order and the >>> authorization is considered to be valid only for that order. If no scope >>> value is present it is assumed that the authorization is valid for any >>> order. >>> >>> Looking back at the PR that introduced the "scope" field[0] and knowing >>> the current state of order based issuance I'm not clear why this field is >>> needed, or what a client could do with the scope information. Can someone >>> clarify or should this part of the spec be removed? >>> >>> The server determines as a matter of policy which authorizations are >>> required for an order and includes these in the order's `authorizations` >>> array. If part of that server policy is to treat some valid authorizations >>> as only being valid for a specific order then the server can simply not >>> include those valid authorizations in the order's authorizations array and >>> can instead create new pending authorizations for the client to solve. The >>> client doesn't need to understand authorization scope it just needs to know >>> which authorizations the server says are required and how to move these >>> authorizations to a valid state. >>> >>> Since the client can't ask for specific authorizations to be used with >>> specific orders and must react to what the server provides why is it >>> helpful to tell a client that one of the authorizations it solved won't be >>> used with future orders? >>> >>> Similarly I think the scope field interacts weirdly with >>> pre-authorization. Are all authorization objects created with >>> pre-authorization assumed to be global scope since they aren't associated >>> with an order? >>> >>> Have any ACME clients or servers implemented order scope? Let's >>> Encrypt/Boulder/Pebble have not. >>> >>> - Daniel / cpu >>> >>> [0] - https://github.com/ietf-wg-acme/acme/pull/124 >>> >>> >>> _______________________________________________ >>> Acme mailing list >>> Acme@ietf.org >>> https://www.ietf.org/mailman/listinfo/acme >>> >>> >> > --001a113f9ec437874c055e32cafd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Richard: You and I are in agreement about removing scope. = Nobody else has voiced any concerns after two weeks. Do you think you can m= erge=C2=A0https:/= /github.com/ietf-wg-acme/acme/pull/349 this week?=C2=A0

On Fri, Nov 3, 2017 at 12:2= 6 PM, Daniel McCarney <cpu@letsencrypt.org> wrote:
Given that= all issuance now goes through new-order, it's probably safe to remove = this.=C2=A0 If the client guesses wrong about what authz it needs, the serv= er can tell it what else it needs to do.


Sounds good to me. Here's a PR to do so:
https://github.com/ietf-wg-acme/acme/pull/349

- Daniel / cpu

On Thu, Nov 2, 2017 at 4:22 PM, Rich= ard Barnes <rlb@ipv.sx> wrote:
I think the intent when w= e implemented it was to communicate to clients that an authz was only good = for a single issuance, so that if a client was doing pre-authorization, the= y would know that that authorization wouldn't be reused.

=
Given that all issuance now goes through new-order, it's pro= bably safe to remove this.=C2=A0 If the client guesses wrong about what aut= hz it needs, the server can tell it what else it needs to do.
--Richard

On Thu, Nov = 2, 2017 at 2:52 PM, Daniel McCarney <cpu@letsencrypt.org> = wrote:
Section 7.1.4 "Authorizatio= n Objects" describes an optional "scope" field. If present i= t must be a URI pointing to an order and the authorization is considered to= be valid only for that order. If no scope value is present it is assumed t= hat the authorization is valid for any order.

Look= ing back at the PR that introduced the "scope" field[0] and knowi= ng the current state of order based issuance I'm not clear why this fie= ld is needed, or what a client could do with the scope information. Can som= eone clarify or should this part of the spec be removed?

The server determines as a matter of policy which authorizations are= required for an order and includes these in the order's `authorization= s` array. If part of that server policy is to treat some valid authorizatio= ns as only being valid for a specific order then the server can simply not = include those valid authorizations in the order's authorizations array = and can instead create new pending authorizations for the client to solve. = The client doesn't need to understand authorization scope it just needs= to know which authorizations the server says are required and how to move = these authorizations to a valid state.

Since the c= lient can't ask for specific authorizations to be used with specific or= ders and must react to what the server provides why is it helpful to tell a= client that one of the authorizations it solved won't be used with fut= ure orders?

Similarly I think the scope field inte= racts weirdly with pre-authorization. Are all authorization objects created= with pre-authorization assumed to be global scope since they aren't as= sociated with an order?

Have any ACME clients or s= ervers implemented order scope? Let's Encrypt/Boulder/Pebble have not.<= /div>

- Daniel / cpu



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




--001a113f9ec437874c055e32cafd-- From nobody Fri Nov 17 12:53: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 9E04D128990 for ; Fri, 17 Nov 2017 12:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYJclaZSa9Ns for ; Fri, 17 Nov 2017 12:53:49 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 460B712751F for ; Fri, 17 Nov 2017 12:53:49 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id b5so5575748itc.3 for ; Fri, 17 Nov 2017 12:53:49 -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=xhy2f3zWopVMGJz/NLPX9y8yhnOVwLO058lfJPQJjkc=; b=bFQqoJPP6cEdIpE4SUZuVNF+8Krh7P3glH+ZwKpsnAH8Zzrb47adVdxsZCfPr7T1Iq nXEskxhcNf6z0bMCp0lz6rOUtHjYKqjvCFeMRIDPiwq8OQDz/hv3Str8+/wao8yH89V+ flNbqUm0ucukWjJ/X6UxHQzOlAIhvd092Tln9WgTt5otxehKoKr0eOzeW5jipMd0CwHv gc7WRY+b8fqSCZ+Oy2mW+q/npnJ9JrodqLRnc+ziSbBTcszEIsKRulyCCkyJWFFIpqe5 aNFntrneG+IoESUvJRjP34BcGDY6QccQ7TUaCGK6NPd/+S/QDBIb5gVLbtCE0dVKIZ4s s80A== 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=xhy2f3zWopVMGJz/NLPX9y8yhnOVwLO058lfJPQJjkc=; b=cXzMRi8JN94nQHW8SSlx54keko7xzt67RQsKLMWyrW0gldYHd4DmMEnC+qN5RG2mbW Mdc3bvB56XDm+ZPqzcAUJGL2Vy0i+s9nPWExEANUAmhLIfaXRhug225Nur2QT0gN+nGt EJ2NK3xpfN1q8EOP8IS91ZJ75RR+PriE7rf9lKoGAKEJN6sYI/qoc9XajaXRCjXaey+n P/TMDgEeCiH9C4i8WhxAlDUHR86mV0p4G712gNNRuiZ42BtjEKPMBanzJOEJBxxh4Pbi e4VNVdfV1Fauz3WpN7NwGeLJRJDQBFV9tIBcFbL4ym7ZhQ3nVOpO/q7SWQT3ktC+Z6h6 xL4A== X-Gm-Message-State: AJaThX6FL0aNrRxOjFEpOx/A7By0YeZ+SWKroVdY3/pbCEwtJtTws8e3 z6J/U/+UCM3z57TFs8lQOVLQHefsU3d3fA5sWYs= X-Google-Smtp-Source: AGs4zMYLoi10y4Wi284Dau1FGmjKY3eJUVHfSFuE7CGcXGLViOOZxOsbbfbFqn0e7lrahMV7U0unfF437aQVj81x7lw= X-Received: by 10.36.173.27 with SMTP id c27mr8350758itf.138.1510952028269; Fri, 17 Nov 2017 12:53:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.176.130 with HTTP; Fri, 17 Nov 2017 12:53:47 -0800 (PST) In-Reply-To: References: From: Logan Widick Date: Fri, 17 Nov 2017 14:53:47 -0600 Message-ID: To: cpu@letsencrypt.org Cc: ACME WG Content-Type: multipart/alternative; boundary="94eb2c1fc9a4eaf526055e33ee2d" Archived-At: Subject: Re: [Acme] Allowable "tel" contacts; publishing allowed contact schemes and their ACME-specific restrictions X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 20:53:52 -0000 --94eb2c1fc9a4eaf526055e33ee2d Content-Type: text/plain; charset="UTF-8" Here is a PR to remove the "tel" contacts from the examples: https://github.com/ietf-wg-acme/acme/pull/353 In the PR, I am assuming that the ACME servers can support additional contact schemes (schemes not defined in ACME specs) but must document (somehow) what subsets of what additional schemes are supported. However, I haven't added any text indicating this assumption. I also haven't added any text indicating how the subsets of the additional contact schemes can be documented. Is this assumption correct? If so, should the assumption be documented any further in the spec? If so, what would be the best way to document this assumption further? Logan On Fri, Nov 17, 2017 at 11:17 AM, Daniel McCarney wrote: > I would be supportive of removing non-mailto contact examples. > > I don't think it's accurate to say that "mailto" is the only contact > scheme currently supported by the ACME standard. That isn't the case for > the spec as-written today - it is the only mandatory contact scheme. I > believe its been left intentionally open ended what other schemes may be > supported by a server. > > In my mind ACME servers wishing to support `tel` should come up with their > own understanding of what parts of the relevant RFCs they support and use > the `unsupportedContact` and `invalidContact` errors as appropriate based > on the `tel://` contacts received. I don't think there is value trying to > create a subprofile of `tel` for ACME use that is defined in the ACME draft. > > - cpu > > > > On Fri, Nov 17, 2017 at 11:12 AM, Logan Widick > wrote: > >> Or, would it be best to remove the non-mailto contacts from the examples, >> and add a note indicating that "mailto" is the only contact URI scheme >> currently supported by the ACME standards? >> >> Sincerely, >> >> Logan Widick >> >> On Wed, Oct 25, 2017 at 3:18 PM, Logan Widick >> wrote: >> >>> This is related to my previous "Allowable mailto contacts" thread >>> earlier this month. However, this is about a different type of contact, so >>> I decided to start a new thread. >>> >>> Although ACME servers don't have to include support for "tel" (RFC 3966) >>> contacts, "tel" contacts appear in multiple examples in the ACME >>> specification. Thus, some may try to include "tel" contact support in their >>> ACME server implementations. >>> >>> Although the example "tel" contacts in the ACME specification seem to >>> indicate a simple, narrow subset (the "global-number" with zero "par" >>> instances), the "tel" specification has many more possible productions. For >>> example, both "global-number" and "local-number" may have "par" instances >>> (like ";name1=value1;name2=value2") after the phone numbers. >>> >>> Assuming I understand the "local-number" specification correctly, a >>> "local-number" could potentially contain a pound sign ("#") for reasons >>> related to DTMF. If I understand the current and past URI specifications >>> correctly, this could be problematic. Specifically, a URI parser may put >>> the parts of the "local-number" after a "#" in the fragment. >>> >>> If someone wanted to implement "tel" contact support for an ACME server, >>> what subset of "tel" would be required? Would both "global-number" and >>> "local-number" instances be allowed? What restrictions would apply to >>> "global-number" and "local-number" instances? Which types of "par" >>> instances would be allowed? Extension? ISDN-subaddress? Others? >>> >>> On a more general note, I think that as ACME becomes more widely used, >>> the subject of what subsets of what contact URI schemes would be allowed >>> under ACME (as opposed to what schemes are supported by a specific ACME >>> server, which was a separate issue already discussed in March on the >>> mailing list under "Allowing clients to understand the account creation >>> functionality supported by a server") may come up more often. Would it be a >>> good idea to request the creation of an "ACME Contact Schemes Registry" >>> like in the ASCII art figures below? >>> >>> >>> >>> >>> +--------+-----------+-----------+-------------------------- >>> -------------------+ >>> | Scheme | Status | Reference | ACME Restrictions >>> | >>> +--------+-----------+-----------+-------------------------- >>> -------------------+ >>> | mailto | Mandatory | RFC 6068 | Exactly one "addr-spec" in the "to" >>> portion | >>> | | | | No "hfields" are allowed >>> | >>> | | | | [Source: "Allowable mailto contacts" >>> thread]| >>> +--------+-----------+-----------+-------------------------- >>> -------------------+ >>> | tel | Optional | RFC 3966 | [insert restrictions picked in this >>> thread] | >>> +--------+-----------+-----------+-------------------------- >>> -------------------+ >>> >>> Figure 1: A possible "ACME Contact Schemes Registry" table. In this >>> version, the ACME restrictions on the original contact scheme >>> specifications are stated in the table, and the original contact scheme >>> specification is listed as the "Reference". These relationships are >>> depicted graphically in Figure 2 (below). >>> >>> >>> >>> >>> +-----------------------+ +--------------------+ >>> | RFC 6068 (mailto RFC) | | RFC 3966 (tel RFC) | >>> +-----------------------+ +--------------------+ >>> >>> Figure 2: RFC relationships for Figure 1 >>> >>> >>> >>> >>> +--------+-----------+---------------------------+ >>> | Scheme | Status | Reference | >>> +--------+-----------+---------------------------+ >>> | mailto | Mandatory | RFC XXXX | >>> | | | (ACME RFC) | >>> | | | | >>> +--------+-----------+---------------------------+ >>> | tel | Optional | RFC YYYY | >>> | | | (Some RFC after RFC XXXX) | >>> +--------+-----------+---------------------------+ >>> >>> Figure 3: Another possible "ACME Contact Schemes Registry" table. In >>> this version, the "Reference" RFCs discuss the ACME-specific >>> restrictions for the contact schemes, and refer to the original >>> specifications for the contact schemes. These relationships are depicted >>> graphically in Figure 4 (below). >>> >>> >>> >>> >>> +-----------------------------+ >>> | ACME restrictions on mailto | >>> +----------+------------------+ >>> ^ >>> | >>> | Contains >>> | >>> +----------+----------+ +--------------+ >>> | RFC XXXX (ACME RFC) | References | RFC 6068 | >>> + +----------------> + (mailto RFC) | >>> | | | | >>> +----------+----------+ +--------------+ >>> ^ >>> | >>> | References >>> | >>> +----------+-------------------+ +-----------+ >>> | RFC YYYY | References | RFC 3966 | >>> + (An RFC after RFC XXXX) +----------------> + (tel RFC) | >>> | | | | >>> +----------+-------------------+ +-----------+ >>> ^ >>> | >>> | Contained in >>> | >>> +----------+------------------+ >>> | ACME Restrictions on tel | >>> +-----------------------------+ >>> >>> Figure 4: RFC relationships for Figure 3 version of "ACME Contact >>> Schemes Registry" >>> >> >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> >> > --94eb2c1fc9a4eaf526055e33ee2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here is a PR to remove the "tel" contacts from t= he examples:=C2=A0https://github.com/ietf-wg-acme/acme/pull/353=C2=A0

In the PR, I am assuming that the ACME servers can support additional cont= act schemes (schemes not defined in ACME specs) but must document (somehow)= what subsets of what additional schemes are supported. However, I haven= 9;t added any text indicating this assumption. I also haven't added any= text indicating how the subsets of the additional contact schemes can be d= ocumented.=C2=A0

Is this assumption correct? If so= , should the assumption be documented any further in the spec? If so, what = would be the best way to document this assumption further?=C2=A0
=
Logan

On Fri, Nov 17, 2017 at 11:17 AM, Daniel McCarney <cpu@= letsencrypt.org> wrote:
I would be supportive of removing non-mailto contact examples= .

I don't think it's accurate to say that "mailto"= ; is the only contact scheme currently supported by the ACME standard. That= isn't the case for the spec as-written today - it is the only mandator= y contact scheme. I believe its been left intentionally open ended what oth= er schemes may be supported by a server.

In my mind ACME servers wis= hing to support `tel` should come up with their own understanding of what p= arts of the relevant RFCs they support and use the `unsupportedContact` and= `invalidContact` errors as appropriate based on the `tel://` contacts rece= ived. I don't think there is value trying to create a subprofile of `te= l` for ACME use that is defined in the ACME draft.

- cpu=C2=A0


=
On Fri, Nov 17, 2017 at 11:12 AM, Logan Widick <lo= gan.widick@gmail.com> wrote:
Or, would it be best = to remove the non-mailto contacts from the examples, and add a note indicat= ing that "mailto" is the only contact URI scheme currently suppor= ted by the ACME standards?=C2=A0

Sincerely,=C2=A0
Logan Widick

On Wed, Oct 25, 2017 at = 3:18 PM, Logan Widick <logan.widick@gmail.com> wrote:
This is related to my previous "Allowable mailto contacts&q= uot; thread earlier this month. However, this is about a different type of = contact, so I decided to start a new thread.

Although ACME servers d= on't have to include support for "tel" (RFC 3966) contacts, &= quot;tel" contacts appear in multiple examples in the ACME specificati= on. Thus, some may try to include "tel" contact support in their = ACME server implementations.

Although the example "tel" co= ntacts in the ACME specification seem to indicate a simple, narrow subset (= the "global-number" with zero "par" instances), the &qu= ot;tel" specification has many more possible productions. For example,= both "global-number" and "local-number" may have "= ;par" instances (like ";name1=3Dvalue1;name2=3Dvalue2") afte= r the phone numbers.

Assuming I understand the "local-number&qu= ot; specification correctly, a "local-number" could potentially c= ontain a pound sign ("#") for reasons related to DTMF. If I under= stand the current and past URI specifications correctly, this could be prob= lematic. Specifically, a URI parser may put the parts of the "local-nu= mber" after a "#" in the fragment.=C2=A0

If someone w= anted to implement "tel" contact support for an ACME server, what= subset of "tel" would be required? Would both "global-numbe= r" and "local-number" instances be allowed? What restriction= s would apply to "global-number" and "local-number" ins= tances? Which types of "par" instances would be allowed? Extensio= n? ISDN-subaddress? Others?

On a more general note, I think that as = ACME becomes more widely used, the subject of what subsets of what contact = URI schemes would be allowed under ACME (as opposed to what schemes are sup= ported by a specific ACME server, which was a separate issue already discus= sed in March on the mailing list under "Allowing clients to understand= the account creation functionality supported by a server") may come u= p more often. Would it be a good idea to request the creation of an "A= CME Contact Schemes Registry" like in the ASCII art figures below?=C2= =A0




+--------+-----------+-----------+-------------= --------------------------------+
| Scheme | Status =C2=A0 =C2=A0| = Reference | ACME Restrictions=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+--------+--------= ---+-----------+---------------------------------------------+| mailto | Mandatory | RFC 6068 =C2=A0| Exactly one "addr-spec" = in the "to" portion |
| =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | No "= ;hfields" are allowed=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| [Source: "Allowable mailto contact= s" thread]|
+--------+-----------+-----------+----------------= -----------------------------+
| tel =C2=A0 =C2=A0| Optional =C2=A0= | RFC 3966 =C2=A0| [insert restrictions picked in this thread] |
+------= --+-----------+-----------+--------------------------------------= -------+

Figure 1: A possible "= ;ACME Contact Schemes Registry" table.=C2=A0In this version, the ACME restrictions=C2=A0on the original contac= t scheme specifications are stated in the table,=C2=A0and the original contact scheme specifica= tion is listed as the "Reference". These relationships are depict= ed graphically in Figure 2 (below).=C2=A0 =C2=A0




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

Figure 2: RFC relationships for Figure 1




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

= Figure 3: Another possible "ACME Contact Schemes Registry" table.= =C2=A0In this versio= n, the "Reference" RFCs discuss=C2=A0the ACME-specific restrictions for the contact s= chemes,=C2=A0and ref= er to the original specifications for the contact schemes. These relationsh= ips are depicted graphically in Figure 4 (below).=C2=A0


=

=
+-----------------------------+
| ACME restrictions= on mailto |
+--------= --+------------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0| Contains
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+----------+----------+=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--------------+
| RFC XXXX (ACME RFC) |=C2=A0 =C2=A0 Refe= rences=C2=A0 =C2=A0 | RFC 6068=C2=A0 =C2=A0 =C2=A0|
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+----------------> +=C2=A0(mailto RFC)= =C2=A0|=C2=A0
|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+----------+----------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0+--------------+
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| References
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
+----= ------+-------------------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +-----------+
| RFC YYYY=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 References=C2=A0 =C2=A0 | RFC 3966= =C2=A0=C2=A0|
+=C2=A0(= An RFC after RFC XXXX)=C2=A0 =C2=A0 =C2=A0 +----------------> +=C2=A0(te= l RFC)=C2=A0|=C2=A0
|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+----------+-------------------+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0+-= ----------+
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| Contained in
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+----------+------------------+
= | ACME Restrictions on tel=C2=A0 =C2=A0= |
+------------------= -----------+
Figure 4: RFC r= elationships for Figure 3 version of "ACME Contact Schemes Registry&qu= ot;


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



--94eb2c1fc9a4eaf526055e33ee2d-- From nobody Mon Nov 20 15:21: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 806ED12EA8D for ; Mon, 20 Nov 2017 15:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01dhhi4Cpd7P for ; Mon, 20 Nov 2017 15:21:28 -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 9B436120713 for ; Mon, 20 Nov 2017 15:21:28 -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=OlymycxdXYWCnum0gqqDVojjF5XLmUwcXFATvoSBxvI=; b=sKXq8BU6Q3FTG1GzvzUaZQ9Sv3SnQ+PgWv3i2PPEg8mjvkhT7TWQFeFOOgsdWbey8xe7lPmdBOiGmPjiTnH19mCaDKps8D1bTnM9j2UZ836JMxOA0/514myk15E5eivfPpkGxNINBLqNZ2C7iUZpSjpVs0XX27PDpBLZw33SXqs=; Received: ; Mon, 20 Nov 2017 15:19:54 -0800 To: acme@ietf.org References: <3994bc53-7a68-c1f2-4a6b-64bbfd9ea99d@eff.org> From: Jacob Hoffman-Andrews Message-ID: <6a1edb4c-4773-3805-8ea8-bb67cb90c9ea@eff.org> Date: Mon, 20 Nov 2017 15:19:57 -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: <3994bc53-7a68-c1f2-4a6b-64bbfd9ea99d@eff.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] Returning multiple errors X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 23:21:36 -0000 I've submitted a PR adding this to the spec: https://github.com/ietf-wg-acme/acme/pull/354 commit a6cc0aedf96067e8b3aaf37662785fcf8b38dd18 Author: Jacob Hoffman-Andrews Date: Mon Nov 20 15:14:29 2017 -0800 Define sub-problems. diff --git a/draft-ietf-acme-acme.md b/draft-ietf-acme-acme.md index a2c11ab..a9e3535 100644 --- a/draft-ietf-acme-acme.md +++ b/draft-ietf-acme-acme.md @@ -521,6 +521,53 @@ set to a URI other than those defined above. Servers MUST NOT use the ACME URN namespace for errors other than the standard types. Clients SHOULD display the "detail" field of all errors. +### Sub-problems + +Sometimes a CA may need to return multiple errors to a single +request. Additionally, the CA may need to attribute errors to specific +identifiers. For instance, a new-order request may contain multiple +identifiers for which the CA cannot issue. In this situation, an ACME +problem document MAY contain the "sub-problems" field, contains a JSON +array of problem documents, each of which MAY contain an "identifier" +field. If present, the "identifier" field MUST contain an ACME identifier +({{iana-identifier}}). The "identifier" field MUST NOT be present at +the top level in ACME problem documents. It can only be present in sub-problems. +Sub-problems need not all have the same type, and do not need to match the top level type. + +ACME clients may choose to use the "identifier" field as a hint that +an operation would succeed if certain identifiers were omitted. For +instance, if an order contains ten DNS identifiers, and the new-order +request returns a problem document with two sub-problems, referencing two +of those identifiers, the ACME client may choose to submit another order +containing only the eight identifiers not listed in the problem document. + +~~~~~ +HTTP/1.1 403 Forbidden +Content-Type: application/problem+json + +{ + "type": "urn:ietf:params:acme:error:malformed", + "detail": "Some of the identifiers requested were rejected", + "sub-problems": [ + { + "type": "urn:ietf:params:acme:error:malformed", + "value": "Invalid underscore in DNS name \"_example.com\"", + "identifier": { + "type": "dns", + "value": "_example.com" + } + }, + { + "type": "urn:ietf:params:acme:error:rejectedIdentifier", + "value": "This CA will not issue for \"example.net\"", + "identifier": { + "type": "dns", + "value": "example.net" + } + } + ] +} +~~~~~ # Certificate Management From nobody Mon Nov 20 20:24:36 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F50612EB28 for ; Mon, 20 Nov 2017 20:24:35 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obwic1pzJCyF for ; Mon, 20 Nov 2017 20:24:33 -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 8832412EB21 for ; Mon, 20 Nov 2017 20:24:33 -0800 (PST) Received: by mail-oi0-x231.google.com with SMTP id l138so7672861oib.7 for ; Mon, 20 Nov 2017 20:24:33 -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=HvSALOticcsP2ABbg34Atwfdqiq/YiHmSwkDuFzAv0c=; b=PjN6tvkMSfyFLWeO3Mfyv5Fa9l11hEHjhtebKHKHGMkxk7kzhDu0oah5rX+7c8AjOG B7AY34tA0Phsfs3anCtcFZJo2kSV09dAq02gasjXlM3zGg8Z/Zs3puHXfw1tQQIqVPQ7 InJmN4pumFn3xaSlSW3KN4Gi1epGSijFopXNoTn4aePZCwz1yqjc8G8MgsP9/WMSbd9m IfNjXzM4zcCt3lNppApgEeXPr6G0wfjUl68uyDgNihHLZ3Osek/3vWSH3BdoIKqGq7yg pc0lYBhqkQvBTMpjkKwyiylJ/a3ix+fLVYbKdN/YlNFXq0iS3Nc3Z4lrqo/gx0kxhrf1 ICow== 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=HvSALOticcsP2ABbg34Atwfdqiq/YiHmSwkDuFzAv0c=; b=Ac1tAuZIIfF0z4DUNpFOJqWiwNQhHdKfGigNiXmHMTh5m2nEVtmNBM6ykj2L+266A2 HvDw6vcoHe5zFT5GyQcOESySefFq0KZbivEk+8rdgt11hjo5Rrj6b7UYaFC8HYPxacST ZXmohyJHHuTfK0gbQPZzWb1NrczlnO9MNR/f54HiSihw4U2QIZjL7kH8G3LCrt16SQrN HbylP5YyuUWL7usO0r0eZ8S4GW1RA3iH8ltNI8daOJoRT8fM3sVW5M0Ip6YNCFETpyWF ghtxXfKsu2PZBQ4EA2n2I3AA/HMBXEqqVWvA1OwVMQI8hZKSqb4y5Tzlmo8O3T0842ot cn0g== X-Gm-Message-State: AJaThX7OFru7fZq6fVacdxTx1bDSgB/emFLXQvwPykPnsyb2tT3lwXS4 6jmy4g+vVOpHDONQaHrdwNNGOXygLM3P0DQaIEhQUw== X-Google-Smtp-Source: AGs4zMb5u4Fb1fjWnV7mRi+ai7Dd2+pdvky8GViQiBQ3TpB3HUja2s9L3nDMYUbE8YCc61meUhx5A1ol7Zz2UsGTwK4= X-Received: by 10.202.170.143 with SMTP id t137mr391125oie.313.1511238272832; Mon, 20 Nov 2017 20:24:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Mon, 20 Nov 2017 20:24:32 -0800 (PST) In-Reply-To: <6a1edb4c-4773-3805-8ea8-bb67cb90c9ea@eff.org> References: <3994bc53-7a68-c1f2-4a6b-64bbfd9ea99d@eff.org> <6a1edb4c-4773-3805-8ea8-bb67cb90c9ea@eff.org> From: Martin Thomson Date: Tue, 21 Nov 2017 15:24:32 +1100 Message-ID: To: Jacob Hoffman-Andrews Cc: "acme@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Acme] Returning multiple errors 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, 21 Nov 2017 04:24:35 -0000 Is this better cast as "sub" problems, or just "additional" problems? On Tue, Nov 21, 2017 at 10:19 AM, Jacob Hoffman-Andrews wrote: > I've submitted a PR adding this to the spec: > > https://github.com/ietf-wg-acme/acme/pull/354 > > commit a6cc0aedf96067e8b3aaf37662785fcf8b38dd18 > Author: Jacob Hoffman-Andrews > Date: Mon Nov 20 15:14:29 2017 -0800 > > Define sub-problems. > > diff --git a/draft-ietf-acme-acme.md b/draft-ietf-acme-acme.md > index a2c11ab..a9e3535 100644 > --- a/draft-ietf-acme-acme.md > +++ b/draft-ietf-acme-acme.md > @@ -521,6 +521,53 @@ set to a URI other than those defined above. > Servers MUST NOT use the ACME URN > namespace for errors other than the standard types. Clients SHOULD > display the > "detail" field of all errors. > > +### Sub-problems > + > +Sometimes a CA may need to return multiple errors to a single > +request. Additionally, the CA may need to attribute errors to specific > +identifiers. For instance, a new-order request may contain multiple > +identifiers for which the CA cannot issue. In this situation, an ACME > +problem document MAY contain the "sub-problems" field, contains a JSON > +array of problem documents, each of which MAY contain an "identifier" > +field. If present, the "identifier" field MUST contain an ACME identifier > +({{iana-identifier}}). The "identifier" field MUST NOT be present at > +the top level in ACME problem documents. It can only be present in > sub-problems. > +Sub-problems need not all have the same type, and do not need to match > the top level type. > + > +ACME clients may choose to use the "identifier" field as a hint that > +an operation would succeed if certain identifiers were omitted. For > +instance, if an order contains ten DNS identifiers, and the new-order > +request returns a problem document with two sub-problems, referencing two > +of those identifiers, the ACME client may choose to submit another order > +containing only the eight identifiers not listed in the problem document. > + > +~~~~~ > +HTTP/1.1 403 Forbidden > +Content-Type: application/problem+json > + > +{ > + "type": "urn:ietf:params:acme:error:malformed", > + "detail": "Some of the identifiers requested were rejected", > + "sub-problems": [ > + { > + "type": "urn:ietf:params:acme:error:malformed", > + "value": "Invalid underscore in DNS name \"_example.com\"", > + "identifier": { > + "type": "dns", > + "value": "_example.com" > + } > + }, > + { > + "type": "urn:ietf:params:acme:error:rejectedIdentifier", > + "value": "This CA will not issue for \"example.net\"", > + "identifier": { > + "type": "dns", > + "value": "example.net" > + } > + } > + ] > +} > +~~~~~ > > # Certificate Management > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme From nobody Tue Nov 21 10:56:00 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689CF126DCA for ; Tue, 21 Nov 2017 10:55:58 -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 HlvPkiKJVPP8 for ; Tue, 21 Nov 2017 10:55: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 B200B126CD6 for ; Tue, 21 Nov 2017 10:55: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=yeiEWoUmiRldU+L38MclBhUW9MfERNdml4r+g97dNFI=; b=jkY7qdfVrJS8iygNXW95U/qU1sIspIZHgiVhYSSGvH06X3fv5hxGG7jszfTE5d8Q9OSlQRssS8teNR+k/gEhTNsQ/biYkoKak5qaUMH8iGTv1aLwQ500dC0SRNTZ4+lzZqp6CiuHRWP9T/NLtp4YlofINaqYYlKeNA/zaxOY3/E=; Received: ; Tue, 21 Nov 2017 10:55:51 -0800 To: acme@ietf.org References: <3994bc53-7a68-c1f2-4a6b-64bbfd9ea99d@eff.org> <6a1edb4c-4773-3805-8ea8-bb67cb90c9ea@eff.org> From: Jacob Hoffman-Andrews Message-ID: <44b45634-2801-10ef-a8de-db66f9d4daa7@eff.org> Date: Tue, 21 Nov 2017 10:55:54 -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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] Returning multiple errors 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, 21 Nov 2017 18:55:58 -0000 On 11/20/2017 08:24 PM, Martin Thomson wrote: > Is this better cast as "sub" problems, or just "additional" problems? I think "additional" is the wrong semantic, because it implies that the first error is hoisted to the top position, so a naive client would only show the first error. Instead, there's a top-level generic error ("some identifiers were rejected"), and then there are potentially multiple errors that are part of it (_example.com, example.net). > On Tue, Nov 21, 2017 at 10:19 AM, Jacob Hoffman-Andrews wrote: >> I've submitted a PR adding this to the spec: >> >> https://github.com/ietf-wg-acme/acme/pull/354 >> >> commit a6cc0aedf96067e8b3aaf37662785fcf8b38dd18 >> Author: Jacob Hoffman-Andrews >> Date: Mon Nov 20 15:14:29 2017 -0800 >> >> Define sub-problems. >> >> diff --git a/draft-ietf-acme-acme.md b/draft-ietf-acme-acme.md >> index a2c11ab..a9e3535 100644 >> --- a/draft-ietf-acme-acme.md >> +++ b/draft-ietf-acme-acme.md >> @@ -521,6 +521,53 @@ set to a URI other than those defined above. >> Servers MUST NOT use the ACME URN >> namespace for errors other than the standard types. Clients SHOULD >> display the >> "detail" field of all errors. >> >> +### Sub-problems >> + >> +Sometimes a CA may need to return multiple errors to a single >> +request. Additionally, the CA may need to attribute errors to specific >> +identifiers. For instance, a new-order request may contain multiple >> +identifiers for which the CA cannot issue. In this situation, an ACME >> +problem document MAY contain the "sub-problems" field, contains a JSON >> +array of problem documents, each of which MAY contain an "identifier" >> +field. If present, the "identifier" field MUST contain an ACME identifier >> +({{iana-identifier}}). The "identifier" field MUST NOT be present at >> +the top level in ACME problem documents. It can only be present in >> sub-problems. >> +Sub-problems need not all have the same type, and do not need to match >> the top level type. >> + >> +ACME clients may choose to use the "identifier" field as a hint that >> +an operation would succeed if certain identifiers were omitted. For >> +instance, if an order contains ten DNS identifiers, and the new-order >> +request returns a problem document with two sub-problems, referencing two >> +of those identifiers, the ACME client may choose to submit another order >> +containing only the eight identifiers not listed in the problem document. >> + >> +~~~~~ >> +HTTP/1.1 403 Forbidden >> +Content-Type: application/problem+json >> + >> +{ >> + "type": "urn:ietf:params:acme:error:malformed", >> + "detail": "Some of the identifiers requested were rejected", >> + "sub-problems": [ >> + { >> + "type": "urn:ietf:params:acme:error:malformed", >> + "value": "Invalid underscore in DNS name \"_example.com\"", >> + "identifier": { >> + "type": "dns", >> + "value": "_example.com" >> + } >> + }, >> + { >> + "type": "urn:ietf:params:acme:error:rejectedIdentifier", >> + "value": "This CA will not issue for \"example.net\"", >> + "identifier": { >> + "type": "dns", >> + "value": "example.net" >> + } >> + } >> + ] >> +} >> +~~~~~ >> >> # Certificate Management >> >> _______________________________________________ >> 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 Nov 21 11:48: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 D904A1292F5 for ; Tue, 21 Nov 2017 11:48:42 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kelunik.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 uQl9RIabxLgx for ; Tue, 21 Nov 2017 11:48:40 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::12]) (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 4D572127873 for ; Tue, 21 Nov 2017 11:48:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1511293717; s=domk; d=kelunik.com; h=Content-Type:Cc:To:Subject:Date:From:References:In-Reply-To: MIME-Version; bh=OQjRL5B0SaouH+PApCSbwv6EiWkonPGJh2KDMUA4hko=; b=vAoN0IoR9Iq4hwvZdXWMGtiYOGObP+OjkkIxcnxCQ4PV1lQFBJzLeebJum6XJeD4jV zRQ6UPAf6tS6pRzvEe0xhM5WYD9KezSQMuQ3HTBwME3fFeATwoYJ1sWZ51IdWEPB4AmQ Hwebiuf/cjonxwYiODSIS9yqDWELeSKZ+8ZHw= X-RZG-AUTH: :IWkkfkWkbvHsXQGmRYmUo9mlsGbEv0XHBzMIJSS+jKTzde5mDb8AaBUcZiAqcA== X-RZG-CLASS-ID: mo00 Received: by mail-yb0-f176.google.com with SMTP id i126so4957672ybi.12 for ; Tue, 21 Nov 2017 11:48:37 -0800 (PST) X-Gm-Message-State: AJaThX5FjPwnXdI8cLbn5v4+FJ8sIfj9Ev+hiKVCQrDdf3JQRqUfGSM1 myDYo745kPRKj5SlTfs9uQdrA/fXxLanGz2zybU= X-Google-Smtp-Source: AGs4zMav+vgQEO4iKMEKY4q0/G5lUbVzHVRPCf5fqOxpOwWwdNPo7nD5qEDom/5PaZr+BELkorAcYUAiiuzNF9oFT/A= X-Received: by 10.37.186.200 with SMTP id a8mr11420685ybk.56.1511293716806; Tue, 21 Nov 2017 11:48:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.124.71 with HTTP; Tue, 21 Nov 2017 11:48:36 -0800 (PST) In-Reply-To: <44b45634-2801-10ef-a8de-db66f9d4daa7@eff.org> References: <3994bc53-7a68-c1f2-4a6b-64bbfd9ea99d@eff.org> <6a1edb4c-4773-3805-8ea8-bb67cb90c9ea@eff.org> <44b45634-2801-10ef-a8de-db66f9d4daa7@eff.org> From: Niklas Keller Date: Tue, 21 Nov 2017 20:48:36 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Jacob Hoffman-Andrews Cc: IETF ACME Content-Type: multipart/alternative; boundary="f403043db588248885055e837d32" Archived-At: Subject: Re: [Acme] Returning multiple errors 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, 21 Nov 2017 19:48:43 -0000 --f403043db588248885055e837d32 Content-Type: text/plain; charset="UTF-8" 2017-11-21 19:55 GMT+01:00 Jacob Hoffman-Andrews : > On 11/20/2017 08:24 PM, Martin Thomson wrote: > > Is this better cast as "sub" problems, or just "additional" problems? > > I think "additional" is the wrong semantic, because it implies that the > first error is hoisted to the top position, so a naive client would only > show the first error. Instead, there's a top-level generic error ("some > identifiers were rejected"), and then there are potentially multiple > errors that are part of it (_example.com, example.net). How about "causes"? Regards, Niklas --f403043db588248885055e837d32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
2017= -11-21 19:55 GMT+01:00 Jacob Hoffman-Andrews <jsha@eff.org>:
=
On 11/20/2017 08:24 PM, Mar= tin Thomson wrote:
> Is this better cast as "sub" problems, or just "additio= nal" problems?

I think "additional" is the wrong semantic, because it imp= lies that the
first error is hoisted to the top position, so a naive client would only show the first error. Instead, there's a top-level generic error ("= ;some
identifiers were rejected"), and then there are potentially multiple errors that are part of it (_example.com, example.net).

How about "causes"?

Regards, Ni= klas
--f403043db588248885055e837d32-- From nobody Tue Nov 21 12:37: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 B62FA129BCB for ; Tue, 21 Nov 2017 12:37:09 -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 N7PCJK18_qgv for ; Tue, 21 Nov 2017 12:37:09 -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 0200A1204DA for ; Tue, 21 Nov 2017 12:37:08 -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=o4u+M0HClLYnBFi4ALlGIPWUIznAU1pQPB9rzbpRYE8=; b=IFs1iAIzE8GQ1a7wRWo9FzmOe3J+DD8fGiBMzEP6m0F4EWgGA1Q2WnVdP9yHbBAPxb3WlnAy5lHpZu+r23TrCZqAlBaxpZHcya/tKOBK4g9vZMIQL78Xn0x9dlx+Mo6RXhQhFWlAeiKOYDEvgYm+hS3L9/E+VRPqlJ5FYvXSb9A=; Received: ; Tue, 21 Nov 2017 12:37:05 -0800 To: acme@ietf.org References: <3994bc53-7a68-c1f2-4a6b-64bbfd9ea99d@eff.org> <6a1edb4c-4773-3805-8ea8-bb67cb90c9ea@eff.org> <44b45634-2801-10ef-a8de-db66f9d4daa7@eff.org> From: Jacob Hoffman-Andrews Message-ID: <5d9acd4e-89ad-c209-bfaa-991da045f75f@eff.org> Date: Tue, 21 Nov 2017 12:37:08 -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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] Returning multiple errors 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, 21 Nov 2017 20:37:10 -0000 On 11/21/2017 11:48 AM, Niklas Keller wrote: > How about "causes"? I think this also implies more meaning than there really is. It also has the unfortunate property of being both a plural noun and a transitive verb, which could be confusing. Is there a problem with sub-problems? From nobody Tue Nov 21 16:06:17 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F03129493 for ; Tue, 21 Nov 2017 16:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sohsGjiw3Alb for ; Tue, 21 Nov 2017 16:06:14 -0800 (PST) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::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 C1CD21200F3 for ; Tue, 21 Nov 2017 16:06:14 -0800 (PST) Received: by mail-ot0-x22f.google.com with SMTP id t79so12131688ota.3 for ; Tue, 21 Nov 2017 16:06:14 -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=VlprNhc4Lo+z+APA3Hx3UoJbojCeraADWCzsLp421w8=; b=j0JBCuqgSbU7By6qilVsQs6TmD4LZE7epDLHoOCDmsMiRkzD4tH/cVZ4Y9gMNHR3k3 LOK3RydfcS5IOm4dOUBo5kKLD6ZOYpo2XkE6af1yDf5t8j86MFwyQqG2/l2EO1Ir1s5R C9Ci3GhCI1Q0U5HjbvDMotKWBpHgnNkiiy9R1k/lStBGKLMWshPncJKDsgo6OF0eOY2K 9En0dyk6UJNQYKbEgrRJYkTtPGFnVxceaKzDcGZ3bILb2wkyY5JIZuPx+Ush+ikUqC7T hcFBwwexUVxRJF1wUvxrE/6SpuRHJi/ZBLqqwAZ4v9PaMdXLKsO+IS5wlGGujmIinNQr fZPA== 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=VlprNhc4Lo+z+APA3Hx3UoJbojCeraADWCzsLp421w8=; b=UhE9NNncUaOrcAW/sq8r2eZIOOrpqQ+STfXHnX9HQgn9duAb+MqiW+hVoJGqD2gUim eaixh3AgTeynXZtdJ9yBKON2DDyn29T3dXP/zr6b2Th/wQ7bMn+imciIJpYYNxwowWHz Vttqe8w9Kj4HfNzGFPuGcuTqmTEu7IrpsY+L4lFg086ShHLnYwK1JMQhgIN08PJAgFX3 iiWicC+4c4sF5uayo86p4FbiHBvYDq7K1i5lbE13j7CGowkkFreic5dxUgLaXbVL3K2v t87qCVcHl1ZZuAo+r+CiaJep05VCD4L8Qwi7ikCb51aK/9T54o9hyBXSX25JzAjOemCs 0Hjg== X-Gm-Message-State: AJaThX4253nLmsaX6urNtDNYO9t1RiIHfEALnYWxsiZiv/ijFeKz1Wbp XVYq+sUjdnBYKk5XKNt5cJ2HmSYFJOTQMO+cwRA= X-Google-Smtp-Source: AGs4zMZSlx8mAl8G6jWMGq2kkeoefSAWFfZKb8CXGXTWX1jBAagrBrQLXnrh0aDXreQGfiIx2zkUsK+8VdaN9vgaW0w= X-Received: by 10.157.69.65 with SMTP id p1mr12614361oti.93.1511309174042; Tue, 21 Nov 2017 16:06:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Tue, 21 Nov 2017 16:06:13 -0800 (PST) In-Reply-To: <44b45634-2801-10ef-a8de-db66f9d4daa7@eff.org> References: <3994bc53-7a68-c1f2-4a6b-64bbfd9ea99d@eff.org> <6a1edb4c-4773-3805-8ea8-bb67cb90c9ea@eff.org> <44b45634-2801-10ef-a8de-db66f9d4daa7@eff.org> From: Martin Thomson Date: Wed, 22 Nov 2017 11:06:13 +1100 Message-ID: To: Jacob Hoffman-Andrews Cc: "acme@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Acme] Returning multiple errors 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, 22 Nov 2017 00:06:16 -0000 On Wed, Nov 22, 2017 at 5:55 AM, Jacob Hoffman-Andrews wrote: > On 11/20/2017 08:24 PM, Martin Thomson wrote: >> Is this better cast as "sub" problems, or just "additional" problems? > > I think "additional" is the wrong semantic, because it implies that the > first error is hoisted to the top position, so a naive client would only > show the first error. Instead, there's a top-level generic error ("some > identifiers were rejected"), and then there are potentially multiple > errors that are part of it (_example.com, example.net). I ask because your example highlighted two types of problems. That they could be aggregated doesn't seem an necessary or innate property. The difficulty with the sort of aggregation design you propose is that you need to aggregate and I don't know what the logic would be in the general case. On the other hand, additional problems are easy to accumulate and emit. They are also easy to consume, either by just doing the dumb thing and handling only the first, or by working through a list. The alternative is to provide a specific type (e.g., "urn:ietf:params:acme:error:multiple"), that says "there were multiple problems", and list the real problems in the body. The text for the specific type could be more helpful - just as in your example - or not. "sub-problems" seems like the worst of these options. From nobody Tue Nov 21 16:20:18 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E81C129BF8 for ; Tue, 21 Nov 2017 16:20:17 -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 QlLSWucqFL9p for ; Tue, 21 Nov 2017 16:20:16 -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 4D29D1200E5 for ; Tue, 21 Nov 2017 16:20:16 -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=UWNy0NpN5K/HM1TLS3Ggzh5eSFEylrTVqllw8PPfHYk=; b=AgZOCvBUcWf/W2SJS1mNRoEfPX4FOMjxZqORR2DXkvlIESBqUqMT9CHCkfB4I4NER+GwVkLwPeq84Nj00QunMiDxZX8Hw1h8g84TsR9258UkMyH4ywwyR+6lm3YuqiltE0OA8f0UXeJ3NbN3wqMpjlpU0GY/NFwxOdGyUbGY37M=; Received: ; Tue, 21 Nov 2017 16:20:12 -0800 To: acme@ietf.org References: <3994bc53-7a68-c1f2-4a6b-64bbfd9ea99d@eff.org> <6a1edb4c-4773-3805-8ea8-bb67cb90c9ea@eff.org> <44b45634-2801-10ef-a8de-db66f9d4daa7@eff.org> From: Jacob Hoffman-Andrews Message-ID: <3e45a67c-878a-0e0f-9382-00e812126670@eff.org> Date: Tue, 21 Nov 2017 16:20:11 -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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] Returning multiple errors 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, 22 Nov 2017 00:20:17 -0000 On 11/21/2017 04:06 PM, Martin Thomson wrote: > I ask because your example highlighted two types of problems. That > they could be aggregated doesn't seem an necessary or innate property. > > The difficulty with the sort of aggregation design you propose is that > you need to aggregate and I don't know what the logic would be in the > general case. On the other hand, additional problems are easy to > accumulate and emit. They are also easy to consume, either by just > doing the dumb thing and handling only the first, or by working > through a list. > > The alternative is to provide a specific type (e.g., > "urn:ietf:params:acme:error:multiple"), that says "there were multiple > problems", and list the real problems in the body. The text for the > specific type could be more helpful - just as in your example - or > not. The current text allows the CA to choose whatever error type at the top level it wants, including its own type. I think that flexibility is fine. Is your main problem that this doesn't specify a top-level "multiple" error type? > list the real problems in the body This is insufficient, because the goal is to allow clients to programmatically remove identifiers from a request. So we need some specific field in JSON. We can't have a raw list, because identifiers are objects, not strings. So we have a list of objects containing identifiers. It happens to be handy to attach a type and a value to each. > additional problems are easy to accumulate and emit. As an implementer, I find sub-problems easy and more natural than a list of problems that gets appended to. From nobody Wed Nov 22 15:39: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 7B23B126DFB for ; Wed, 22 Nov 2017 15:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFNaP4hH34Sz for ; Wed, 22 Nov 2017 15:39:38 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50133.outbound.protection.outlook.com [40.107.5.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 529AE1200F1 for ; Wed, 22 Nov 2017 15:39:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ivv/OaWIsapABLkRaKr7Mfa8oyfqXk6eXlfpf5LPp0Y=; b=HEWyX9YCq2ThK4Mx+NfYi4LdAGsWnOE75XxoudbxEAI9gk+W78fpY/vsCPt96ajWcVC+iAWPOqUhiVGDPD3XTi+03riPsMLxJ2eFMR/bzyYtXJp/LdddmepaPWf5j3Saqd30wzEVw9kxKgDHDwdBvg9fKlNNCeOPOpxsYWraJE4= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1103.eurprd07.prod.outlook.com (10.163.168.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.2; Wed, 22 Nov 2017 23:39:35 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::6021:c53d:b66d:4a61]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::6021:c53d:b66d:4a61%13]) with mapi id 15.20.0260.004; Wed, 22 Nov 2017 23:39:34 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: "acme@ietf.org" CC: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Thread-Topic: singapore draft minutes Thread-Index: AQHTY+snPsnqE3f7hkC8k8WUSc21aA== Date: Wed, 22 Nov 2017 23:39:34 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-originating-ip: [88.111.108.220] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1103; 6:CrMEpxlJpdSzXoqTYBbkehpqbxXx3pCr+FxZRucRP4rKeoPS1/WnPUZHkurpjA2X1B+iMNDvyk1F+dms6j3zekAXHHQvh311efXoylQgO2I0+szueNOjefecP0uFE4W/aYhPj4O+Wa3sGlXcDo+UjqO3yL/oEbAdObOYESYubyYrU+EYff/fNK/R5sXSXirBhCCx3NraKYf7miqmwddXvP7UnwYdUQ0Hvd0i7o/Jn3LzJ4VvoFpQW3HTaVNvFWImHQSH8ylOqcRa00aLrP0NG8/idKjzFodI9qRNZSIhhan140G4oM3R5QbHDC21JK4+ddDPwQte+I4AiSTbyShkOGiXjzGM+paQGkQH+Ju3LwQ=; 5:Ts1s6OkoMeiFNEYgk1DyozJFVWJ5mzfgeQngJjE9HC1SYf7WkkFOJg9q1n4WqYjI7SMKYtiZ3HJDCsI9r+TMNkSe3B0aA6VnBChwwz1eCG614rItvYmiR8ZGEQgH2qHTUNrHX3oSXO3rop0SZAmvojwfRO/poB26JkepY4OpCTo=; 24:9qSa/RujspoaX1V+aSMEeCGMF9Xsn+3jYjJqdIHm63khukHkMqKeWP11DCg+anVY5YT8O64JzZ8Fnz3xyeM38YgTmBgG83GY5W/7+GcoCXE=; 7:0DFbIxRPw2yK8o72nSTR16rNftvOP1y0FZAHqUbRCVcRWvN1enwmwNk8DYBuTSgoL6cLlCEQyWRvcckdi6cA7J+7cGrah/63NTF2s+qQtWQCorcvY5hDkOS+3wU4Bpnh1XgiD8cK2lP/wfih2tJe9+0slmtRjlTNLFJGp0ePfuee9aGrA4GMGxmPRk071rRXLa/e6bxQUUQpnfqRFAFDjnYSrnWNXpM1t7me38ZSEhgfZsQ0vGORhVKxI1d6veD2 x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(366004)(39860400002)(199003)(189002)(53754006)(33656002)(101416001)(99286004)(1730700003)(81156014)(478600001)(3280700002)(81166006)(105586002)(2351001)(8676002)(83506002)(14454004)(2906002)(106356001)(6506006)(82746002)(6916009)(5640700003)(5250100002)(6116002)(966005)(50986999)(54356999)(102836003)(6486002)(97736004)(4326008)(316002)(305945005)(107886003)(6436002)(7736002)(53936002)(6512007)(3846002)(58126008)(2501003)(8936002)(3480700004)(6306002)(36756003)(189998001)(2900100001)(83716003)(7116003)(25786009)(68736007)(3660700001)(86362001)(558084003)(66066001)(5660300001)(133083001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1103; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: a457612d-0f3b-422f-2ff2-08d532024998 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:VI1PR07MB1103; x-ms-traffictypediagnostic: VI1PR07MB1103: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3231022)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB1103; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB1103; x-forefront-prvs: 0499DAF22A received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: a457612d-0f3b-422f-2ff2-08d532024998 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2017 23:39:34.8514 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1103 Archived-At: Subject: [Acme] singapore draft minutes 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, 22 Nov 2017 23:39:40 -0000 SGkgYWxsLA0KDQpUaGUgZHJhZnQgbWludXRlcyBhcmUgaGVyZToNCg0KaHR0cHM6Ly9naXRodWIu Y29tL3Rob21hcy1mb3NzYXRpL2FjbWUtbWludXRlcy9ibG9iL21hc3Rlci9pZXRmLTEwMC5tZA0K DQpQbGVhc2UgY2hlY2sgaWYgdGhleSBhcmUgT0sgKElJUkMgSSBtaXNzZWQgYSBjb3VwbGUgb2Yg bmFtZXMpLg0KDQpJZiB5b3UgaGF2ZSBjb3JyZWN0aW9ucyBvciBhZGRpdGlvbnMgdG8gbWFrZSwg cGxlYXNlIHByb3ZpZGUgUFJzLg0KDQpDaGVlcnMsIHRoYW5rcw0KDQo= From nobody Mon Nov 27 12:04: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 0CD5B128854 for ; Mon, 27 Nov 2017 12:04:33 -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 KwX_qhXDgQzU for ; Mon, 27 Nov 2017 12:04:31 -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 9D7011274D2 for ; Mon, 27 Nov 2017 12:04:31 -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:MIME-Version:Date:Message-ID:Subject:From:To; bh=qD+PmlHmxw/UWdg9P/lCagP7t9mvvsiKtr+5eyadIT0=; b=3QMsVGVOXO65RNhMrNn+jsupmWPOfKmzgXVIddcE4wtw/Mo06bSGU3diaWNinzHZQdajc8ikrKtG+EbmYMUGfT7Pud+jPlrOXy4c3l3RCaDxchXKxtf31F0ar9jJQELnG5XrBHz4jgBrhVvyM1bcW9jyQ60IgQddqjAjJfbblzo=; Received: ; Mon, 27 Nov 2017 12:04:27 -0800 To: "acme@ietf.org" From: Jacob Hoffman-Andrews Message-ID: Date: Mon, 27 Nov 2017 12:04:31 -0800 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-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Acme] Landing PR#342 (proactive issuance with identifier-first) X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 20:04:33 -0000 Hi all, Daniel McCarney's been working on PR#342, which changes the new-order flow to take a list of identifiers instead of a CSR, and to be finalized with a CSR: https://github.com/ietf-wg-acme/acme/pull/342. We've had some back-and-forth on the list about this, versus CSR-first, versus CSR-first-and-last. There was some further discussion at IETF 100 (minutes: https://github.com/thomas-fossati/acme-minutes/blob/master/ietf-100.md), and we hummed to accept PR 342 over the alternatives. If there's anyone here who couldn't make it to the meeting and would like to raise strenuous objections, please speak up now, otherwise we'll incorporate that change. Thanks, Jacob From nobody Tue Nov 28 02:38:32 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFF81200F3; Tue, 28 Nov 2017 02:38:29 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpiOuuJZO4hG; Tue, 28 Nov 2017 02:38:23 -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 52E70124BE8; Tue, 28 Nov 2017 02:38:23 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id r68so797614wmr.3; Tue, 28 Nov 2017 02:38:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=pjGs+A205wWurz8xUPR2vRv9smUrsv4RRYHB1pMm0M8=; b=mVh5APJpOZx7P96vorPJ6ncgxJ332E+YQwr9q5Ji1/NqBU3Kiur90Xcva8q5WoK6Jp vwYujD7xVMTD02rOnA7OHmmLeaVwxQx3LeXjMwe2qwEe6KMXiIPQ6bq02O41g1vsY4KP 2HQ7MhYcPfCqFLreyYuJZSs3ZIdK5LKsJSOEdnh4gXHIQaC4cu8TGK0h352LiGa4F7sn AppNW5W+AltMiwrpt/GqxgXbWtuqFnFyRBaAKIoiYCXEGG0uwpKacQ8XxPbpwzQnqXPZ GC8FzxOTrVGiVEXEGIGtzZXgy21V7V5oFbbQkrCzT2/5Iwc2KD6q/r7ftNYnUDgnB9Fu aVwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=pjGs+A205wWurz8xUPR2vRv9smUrsv4RRYHB1pMm0M8=; b=VlhZ8WPP5H5dJCq2fDhwBo7R6UAVpGY7N0d08i7O3n0XzFjcYGPnONio3VbdDk4CxO cciXArdLhPmlox8eAsU8TNgOhfsEBPK/Kq37Mp/hQsD3+Z1Xplur4IhoH6LBeHwUdO1H t3JW7SAAZT+kTQQB3I3iFdto3sZoeRNabyjfpeBO6c4W/ZHc7Qia2Gfl48BdCFZ+ClPm FL1JoBkdhgKhQQynpL1RvpsH9x37JOn8LQjs9x+rONW+nid4YDmh1AmSyG0WdF54a3xt ATkK2ncdgLOdYweuCLTAfx2PEE+IYj82CKKCZBydoTgn+YsfSbPAXt3XBlbI9+HnH0bS aSBA== X-Gm-Message-State: AJaThX5oyU27ldIvWxGcmxtM8XnDR+rvru672pfC8xL9EyP8eHDKB2PQ RXqpYJe5IVItS5GCAIkee1jfmQ== X-Google-Smtp-Source: AGs4zMY0IwQhntI8dpTu0JJ2XMTzXICRdJCjdaPPpXUmeXaBGc/ZJeT6QcgfSEuhr1uTKbAwjyYJaA== X-Received: by 10.80.215.158 with SMTP id w30mr1946414edi.81.1511865501589; Tue, 28 Nov 2017 02:38:21 -0800 (PST) Received: from ?IPv6:2003:74:cf3f:7155:88c:94fb:c791:d5c7? (p2003000653148A55088C94FBC791D5C7.dip0.t-ipconnect.de. [2003:6:5314:8a55:88c:94fb:c791:d5c7]) by smtp.googlemail.com with ESMTPSA id g3sm17378119edi.66.2017.11.28.02.38.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Nov 2017 02:38:20 -0800 (PST) From: Martin Stiemerling To: acme@ietf.org Cc: tsv-art@ietf.org Message-ID: Date: Tue, 28 Nov 2017 11:38:19 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Acme] TSV-ART review of draft-ietf-acme-acme-08 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, 28 Nov 2017 10:38:30 -0000 Hi all, I've reviewed this document as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-art@… if you reply to or forward this review. Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Editorials: - Abstract says "DISCLAIMER:...": This should be removed before publication or there is an issue with the intended status of Standards Track. - A nit, but: section 7.3.4 uses http instead of https in the example: "instance": "http://example.com/agreement/?token=W8Ih3PswD-8" All other instances use https. Technicals: - Section 8.2. Retrying challenges Any guidance on what "some times" means? At least in terms of a time scale, e.g., seconds, minutes, hours? Thanks for the clearly written document! Regards, Martin Stiemerling From nobody Tue Nov 28 10:05:24 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BC9124239 for ; Tue, 28 Nov 2017 10:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYMfphE74AqJ for ; Tue, 28 Nov 2017 10:05:20 -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 3384912420B for ; Tue, 28 Nov 2017 10:05:20 -0800 (PST) Received: by mail-wr0-x235.google.com with SMTP id o2so943946wro.5 for ; Tue, 28 Nov 2017 10:05: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=bMPQ38Pv9DU9/0MUVVBYZLq6ZIScs3QtOz9RxwrzbrU=; b=qtDIMBbwbK4s8jYhjYDcyf09r3lPXgdmCSytIcHYsjCWdmd44pN4LBFJMg7kGSSjws iwRX2tIbX/8pqNfOf+LYMv5wMY7P3BfZ5qMt8BWYoAU3l1svWwOUSIqIf8Oz/XIca747 n85P12z7v/GmCTWECk/sRmIDnpSrSpZZDgiXJPhslLjm4vpa3j4r+Pr8IKwpeAHkgx97 7YL6Pcz2LdcfeTgRICbvZvIJq/29hhusRZCzbQWw5/eTgOn1o5oo4HAkrQq+MKGArc0u ol49SzpChzlMUTT2WM7FvBm+Hcw4GcHkD90IjZn681cu267O6xeL1HjLMzzx47MPnjVn LGwA== 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=bMPQ38Pv9DU9/0MUVVBYZLq6ZIScs3QtOz9RxwrzbrU=; b=n3+U9VuLlk2mek6hpW1ykVOsM14c2IY2m82qBnwKrIxPiMTtrFrIp12yBgY9FshL21 FIvPZOFTuPmCtQ0CI7jU1X6iKQlMd8C3pQcO/DJ+WXJt0UsaPqWcw9uHT7lcpbrQcXDa 4INgC1sjbcyuOUcuU3zYzHakZ36V7HQUZDPlOxlZho6R0InzLmGxpX4k8sFGB8mJwB80 4ZxQb6RtZW0Gj/WSyTcbIBYPP508U0sMMxP9FahMHvqendIgcceY32FPcp1QiYgLZfCj fvP1GOrN8ku/Jcf4T4jwwNB4N7Os3+y9RWVQNXzBjU/QBkoWSTtykD6W+xEtLQIPYUSr lkhg== X-Gm-Message-State: AJaThX59cZRVz9hlFsiGkTao1S+KpkkDbVYCBA3j/AuMshKfUSpjxZRp eq6FjkvSb5bc3BcLvwvg5QrhnBr3KOyuU//pic/zcg== X-Google-Smtp-Source: AGs4zMakKbZAbkx+7ZflxHstbIRUs0Ic782lVhVzfluK0/yTVHIvuLqIsPlbYrCg5lp8eCErKnwKtQhw2uW4uJ4ebes= X-Received: by 10.223.176.27 with SMTP id f27mr37751256wra.105.1511892318194; Tue, 28 Nov 2017 10:05:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.167.74 with HTTP; Tue, 28 Nov 2017 10:05:17 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Tue, 28 Nov 2017 13:05:17 -0500 Message-ID: To: Jacob Hoffman-Andrews Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a1141adb690a010055f0edcb5" Archived-At: Subject: Re: [Acme] Landing PR#342 (proactive issuance with identifier-first) 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, 28 Nov 2017 18:05:22 -0000 --001a1141adb690a010055f0edcb5 Content-Type: text/plain; charset="UTF-8" I think this is fine to land now. It's not my favorite approach, but there's clear consensus. I filed Issue #356 [1] to track the lost functionality here, and how we might want to add it back. https://github.com/ietf-wg-acme/acme/issues/356 On Mon, Nov 27, 2017 at 3:04 PM, Jacob Hoffman-Andrews wrote: > Hi all, > > Daniel McCarney's been working on PR#342, which changes the new-order > flow to take a list of identifiers instead of a CSR, and to be finalized > with a CSR: https://github.com/ietf-wg-acme/acme/pull/342. We've had > some back-and-forth on the list about this, versus CSR-first, versus > CSR-first-and-last. There was some further discussion at IETF 100 > (minutes: > https://github.com/thomas-fossati/acme-minutes/blob/master/ietf-100.md), > and we hummed to accept PR 342 over the alternatives. > > If there's anyone here who couldn't make it to the meeting and would > like to raise strenuous objections, please speak up now, otherwise we'll > incorporate that change. > > Thanks, > Jacob > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a1141adb690a010055f0edcb5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think this is fine to land now.=C2=A0 It's not = my favorite approach, but there's clear consensus.=C2=A0 I filed Issue = #356 [1] to track the lost functionality here, and how we might want to add= it back.


O= n Mon, Nov 27, 2017 at 3:04 PM, Jacob Hoffman-Andrews <= ;jsha@eff.org> wrote:
Hi all,

Daniel McCarney's been working on PR#342, which changes the new-order flow to take a list of identifiers instead of a CSR, and to be finalized with a CSR: https://github.com/ietf-wg-acme/acme= /pull/342. We've had
some back-and-forth on the list about this, versus CSR-first, versus
CSR-first-and-last. There was some further discussion at IETF 100
(minutes:
https://github.com/thomas-fossati/acme-minutes/blob/master/ietf-100.md),
and we hummed to accept PR 342 over the alternatives.

If there's anyone here who couldn't make it to the meeting and woul= d
like to raise strenuous objections, please speak up now, otherwise we'l= l
incorporate that change.

Thanks,
Jacob

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

--001a1141adb690a010055f0edcb5-- From nobody Tue Nov 28 10:08:17 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C89126DED for ; Tue, 28 Nov 2017 10:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 8aKS1sO4QIHY for ; Tue, 28 Nov 2017 10:08:15 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE6B812420B for ; Tue, 28 Nov 2017 10:08:14 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id l141so1342007wmg.1 for ; Tue, 28 Nov 2017 10:08:14 -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=ARdV3QN2/Ng/m6MmXytsv0162iy4nBgr7Lp/V6ZRSzs=; b=Si57aCKFBSxn15Qg5PsEGfndQeygxzyZYhAi9P5tvp41NKJ9IZoTHeqZbLOfOFd2nk E9XgNdkYqTXAjZ1/U1RwZ7BotpCx+Rgug7KclxWPfkJgPfhsgIWvX1P86q1YpxjXcIKQ t9PeCnZHHrhkMWF2Ajj/Iq1iZObUWStttX7qwrJG4+/qtGPCoZw38JdBzAt5L1A3e14V lsCnRkIWpDFtv33AHGRxx8oufNnrHIPOJDeac6RxZPfo7vVsT/7tloJOjmiMksTPICeK 00Dixt44Yy26gfi5EjiZ4LI5oNvYw1JI9MjiBu5SSubG3bDuDOtOUd7WmLPArvwsX6BL DbeA== 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=ARdV3QN2/Ng/m6MmXytsv0162iy4nBgr7Lp/V6ZRSzs=; b=YcDNkgHQKIPLMhgN7v2wslvQM+wvdxRbDHxBORWfhI2TkpR9r4TbEOecB0iD9m3AFA byQ67SqhQFj5Nph3oZ0FQZZDcERjtYGU78uzMT/9cj8h2MeG+oHdZtyC06t0aCKyNTw1 0zKUM764JugDNWpUMK6mtgISa4Q0AGsI1dfO01NF31Y+OnBk9T0mpZWMM4mqEp1t9giF IZZqEfhEiGvGkZ45tEY6gB4nZPy1f5HSS+oWda1ZmuZDHNmi2O5q9XmnqTTzjNVrwEt7 EnfQELWY3C+UvFndS8J8yEWEb3JS13lmlzC0ZW48Tntr2NFoq2KTm1NBoOUW5YelmK4Z wgNA== X-Gm-Message-State: AJaThX4zqArLBj6MVRyKpXUJ5J5YV7S6y0DsLvTcGIjnHwF69LTvHaSD y8VndHYDYghUpasI+XfJUnmDvYiOl9I/L2V6oJOLPw== X-Google-Smtp-Source: AGs4zMYvW9QX/Y+4mIC1DWc68lizavdVYq78U63U/vIw5ccwzN2tldOSgz/KAjSfapHFX8KtYLrm0FWbrUfSnyV7/8w= X-Received: by 10.28.183.132 with SMTP id h126mr407006wmf.17.1511892493098; Tue, 28 Nov 2017 10:08:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.167.74 with HTTP; Tue, 28 Nov 2017 10:08:12 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Tue, 28 Nov 2017 13:08:12 -0500 Message-ID: To: Jacob Hoffman-Andrews Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a1148f4a6fd78f4055f0ee682" Archived-At: Subject: Re: [Acme] Landing PR#342 (proactive issuance with identifier-first) 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, 28 Nov 2017 18:08:16 -0000 --001a1148f4a6fd78f4055f0ee682 Content-Type: text/plain; charset="UTF-8" Using my editor's prerogative, I went ahead and merged this PR. On Tue, Nov 28, 2017 at 1:05 PM, Richard Barnes wrote: > I think this is fine to land now. It's not my favorite approach, but > there's clear consensus. I filed Issue #356 [1] to track the lost > functionality here, and how we might want to add it back. > > https://github.com/ietf-wg-acme/acme/issues/356 > > On Mon, Nov 27, 2017 at 3:04 PM, Jacob Hoffman-Andrews > wrote: > >> Hi all, >> >> Daniel McCarney's been working on PR#342, which changes the new-order >> flow to take a list of identifiers instead of a CSR, and to be finalized >> with a CSR: https://github.com/ietf-wg-acme/acme/pull/342. We've had >> some back-and-forth on the list about this, versus CSR-first, versus >> CSR-first-and-last. There was some further discussion at IETF 100 >> (minutes: >> https://github.com/thomas-fossati/acme-minutes/blob/master/ietf-100.md), >> and we hummed to accept PR 342 over the alternatives. >> >> If there's anyone here who couldn't make it to the meeting and would >> like to raise strenuous objections, please speak up now, otherwise we'll >> incorporate that change. >> >> Thanks, >> Jacob >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> > > --001a1148f4a6fd78f4055f0ee682 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Using my editor's prerogative, I went ahead and merged= this PR.=C2=A0

On Tue, Nov 28, 2017 at 1:05 PM, Richard Barnes = <rlb@ipv.sx> wrote:
I think t= his is fine to land now.=C2=A0 It's not my favorite approach, but there= 's clear consensus.=C2=A0 I filed Issue #356 [1] to track the lost func= tionality here, and how we might want to add it back.


On Mon, Nov 27, 2017 at 3:04 PM, Jacob Hoff= man-Andrews <jsha@eff.org> wrote:
Hi all,

Daniel McCarney's been working on PR#342, which changes the new-order flow to take a list of identifiers instead of a CSR, and to be finalized with a CSR: https://github.com/ietf-wg-acme/acme= /pull/342. We've had
some back-and-forth on the list about this, versus CSR-first, versus
CSR-first-and-last. There was some further discussion at IETF 100
(minutes:
https://github.com/thomas-foss= ati/acme-minutes/blob/master/ietf-100.md),
and we hummed to accept PR 342 over the alternatives.

If there's anyone here who couldn't make it to the meeting and woul= d
like to raise strenuous objections, please speak up now, otherwise we'l= l
incorporate that change.

Thanks,
Jacob

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


--001a1148f4a6fd78f4055f0ee682-- From nobody Tue Nov 28 10:19:46 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A246128954 for ; Tue, 28 Nov 2017 10:19:44 -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 1NWg6ggPtFlD for ; Tue, 28 Nov 2017 10:19:42 -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 1F5D61279E5 for ; Tue, 28 Nov 2017 10:19:42 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id x129so804872iod.13 for ; Tue, 28 Nov 2017 10:19:42 -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=hVBRSpEhWn0DyFA9LSrg9h05pkFCdSPQBbdWI9+mtIg=; b=Effmjqyyng8uB3eXM0V+8Rme9GJIq3qVWZ7FCSoQ5iBVc36mTpqr4EcU08dDxhWd6N 4y2f1mQV2AsrMMJc5eroNmPgxocPDXGrMPq9YVHddWSbImwrYPRlPsCcLBJKzxksoU5v 31ipt/v5JvoSYzSimBdYiDyksSz6X2380qTwo= 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=hVBRSpEhWn0DyFA9LSrg9h05pkFCdSPQBbdWI9+mtIg=; b=OVsQdYYrXjsg0hCFTINAGtCuz5Dw6RqGFY/hsfgeDgCNfd9oKjUR0jtJ6WAAGKZqEo bOjo2n3WyAz+WlhFb9oeBYLscRwiUfX1hVGIVZhcItP8s6JCoIZ96ZUmGoLqMpREk49n Z0C3a/s3ESE6GcacrFntsajY4QEsU3O6yqk1CH1EpLypJywS2C80onS8Klr+eY7QsnCG z0+sDEKbdvDQTlmBkOq+0j3FVVu3yE85eSaZ9eZo19TDVR7/mA8jWnWYHQadEl2fqPJ3 kvEtqN+6w9c5sJBa1d6+plMypzP1WYNr452N0e1LEBGbZH3XNwrDKwNKqSwtUl1Q+PXm poHg== X-Gm-Message-State: AJaThX7DfHxjWFvDTHpzDjcbEpSbM6GVhwbqM8WYxN4LMd3iZvqCoGgX R4uHXMOcaqqmt3SyMOrhGAWE/eBcHAafQ8Uf5HtDcn4H X-Google-Smtp-Source: AGs4zMbxchQn4ODO8lnrWwCfPEdV63r81YJEnGXO/tyJzfQioXOV4BfRYxQhzyM0QuYUeD+9l7P4AYUJY8Xj7pDa4EI= X-Received: by 10.107.33.207 with SMTP id h198mr30594ioh.167.1511893181286; Tue, 28 Nov 2017 10:19:41 -0800 (PST) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.17.28 with HTTP; Tue, 28 Nov 2017 10:19:40 -0800 (PST) In-Reply-To: References: From: Daniel McCarney Date: Tue, 28 Nov 2017 13:19:40 -0500 Message-ID: To: Richard Barnes Cc: Jacob Hoffman-Andrews , "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a1140a3e8027ead055f0f10dc" Archived-At: Subject: Re: [Acme] Landing PR#342 (proactive issuance with identifier-first) 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, 28 Nov 2017 18:19:44 -0000 --001a1140a3e8027ead055f0f10dc Content-Type: text/plain; charset="UTF-8" > > I filed Issue #356 [1] to track the lost functionality here, and how we > might want to add it back. >From #356: " In making that change, we dropped support for certain legacy back-end > APIs that require a CSR before issuing challenges" Which legacy back-end APIs are you referring to? I recall many weeks ago you thought a specific commercial CA and a specific certificate re-seller required CSR in new-order but both confirmed off-list they did not. It's frustrating to see continued resistance on the back of constraints imposed by vague legacy systems without name. Where are the users/maintainers of these systems to express their concerns at the perceived "drop of support" to the working group directly? - Daniel / cpu On Tue, Nov 28, 2017 at 1:05 PM, Richard Barnes wrote: > I think this is fine to land now. It's not my favorite approach, but > there's clear consensus. I filed Issue #356 [1] to track the lost > functionality here, and how we might want to add it back. > > https://github.com/ietf-wg-acme/acme/issues/356 > > On Mon, Nov 27, 2017 at 3:04 PM, Jacob Hoffman-Andrews > wrote: > >> Hi all, >> >> Daniel McCarney's been working on PR#342, which changes the new-order >> flow to take a list of identifiers instead of a CSR, and to be finalized >> with a CSR: https://github.com/ietf-wg-acme/acme/pull/342. We've had >> some back-and-forth on the list about this, versus CSR-first, versus >> CSR-first-and-last. There was some further discussion at IETF 100 >> (minutes: >> https://github.com/thomas-fossati/acme-minutes/blob/master/ietf-100.md), >> and we hummed to accept PR 342 over the alternatives. >> >> If there's anyone here who couldn't make it to the meeting and would >> like to raise strenuous objections, please speak up now, otherwise we'll >> incorporate that change. >> >> Thanks, >> Jacob >> >> _______________________________________________ >> 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 > > --001a1140a3e8027ead055f0f10dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0I = filed Issue #356 [1] to track the lost functionality here, and how we might= want to add it back.

From #356:

" In making that change, we droppe= d support for certain legacy back-end APIs that require a CSR before issuin= g challenges"

Which legacy back-end APIs are you = referring to? I recall many weeks ago you thought a specific commercial CA = and a specific certificate re-seller required CSR in new-order but both con= firmed off-list they did not.

It's frustrating to see continued = resistance on the back of constraints imposed by vague legacy systems witho= ut name. Where are the users/maintainers of these systems to express their = concerns at the perceived "drop of support" to the working group = directly?

- Daniel / cpu

=

On Tue, Nov 28, 2= 017 at 1:05 PM, Richard Barnes <rlb@ipv.sx> wrote:
I think this is fine to land now.= =C2=A0 It's not my favorite approach, but there's clear consensus.= =C2=A0 I filed Issue #356 [1] to track the lost functionality here, and how= we might want to add it back.


On Mon, Nov 27, 2017 at 3:04 PM, Jacob Hoffman-Andrews <jsha@eff.org> wrote:
Hi all,

Daniel McCarney's been working on PR#342, which changes the new-order flow to take a list of identifiers instead of a CSR, and to be finalized with a CSR: https://github.com/ietf-wg-acme/acme= /pull/342. We've had
some back-and-forth on the list about this, versus CSR-first, versus
CSR-first-and-last. There was some further discussion at IETF 100
(minutes:
https://github.com/thomas-foss= ati/acme-minutes/blob/master/ietf-100.md),
and we hummed to accept PR 342 over the alternatives.

If there's anyone here who couldn't make it to the meeting and woul= d
like to raise strenuous objections, please speak up now, otherwise we'l= l
incorporate that change.

Thanks,
Jacob

_______________________________________________
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


--001a1140a3e8027ead055f0f10dc-- From nobody Tue Nov 28 10:23:32 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1C0128954 for ; Tue, 28 Nov 2017 10:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ZNeR_-2QiApz for ; Tue, 28 Nov 2017 10:23:26 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35323127444 for ; Tue, 28 Nov 2017 10:23:26 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id f140so1307910wmd.2 for ; Tue, 28 Nov 2017 10:23:26 -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=s/bMSyMu3GSGg0Y2/JuW5k2FSgCIsuiJg590m8xTepo=; b=MyIkmvCrF6/0mZMuMNC8+hvtvbJhZ+ELor/pH+bd5RRI2Us+NOtciKYdzTq7gd5d9r sMVq89tyXQSHTN/8JHOXjo8Mokk70kQODzAVp2xXdl5+z1NPmi4SBpFSFVZd83/rsq83 omcwEWL6xOTw8+I8UoQKnJlIaZBSIPoJWd2MJbEDbaf8CqmPKKHyUInOvJb2EKOSSfZb fauoMSPaZsJkgC9GDedGyW9c2GVY9ROwcNDYzBoDVeN0I3Tcpw5qhYO844iys8pR837r l8TwZjbxywnaKegsRU3gdYBEw9TmKQX4yDM53hjvQdMxg+5EWEO51lBon7fuz5TwSmTB ciog== 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=s/bMSyMu3GSGg0Y2/JuW5k2FSgCIsuiJg590m8xTepo=; b=sI5W0EOc3NQGY2Q2xL2SMObmxEjbMHplNKFQn0oZaiLsjXPvc5TUGgSqJdLFKkMWcg +r2XrBuanJ/pvyM5SEM73wGDLHz5duqIPKxok5/aUva6b4+RhI+uwCYmvV136Obx4hfR 1kWauc3VRzEq4x0q7zjeDOmSWP51kT7xpNT+kgA40CO7gX6wkaCwySCm9oQq3+u+GOv2 lF9iVwsQsyBh8+3o2UYKF7OiHoQVeIuoEc8IBx4vgcAM60g0QlBQj8NXZYM/z6fgSOgw ozTH47tUs4ZMU516rvqkFNyfuL7hzl92u+VuenbF5OA66Beq4p9qRAiDgV3ZHH18qT/3 7I5w== X-Gm-Message-State: AJaThX5q1tYSoOUL3yAnbf2ILKpLNWhlsfqyFVLnBzos3Lo+Or2M4E1X Zj8veamgFVH2ZpbnRViOP8r1BGJdw7KLSvIjqG/nXQ== X-Google-Smtp-Source: AGs4zMYxcSF0RoAxns2xlaaVckJR98ff/JpivH6YrqxDGYa5I/J++dzAxd9Oz/D3YPxyar0T8rI41lt2pf2QjKhPBkg= X-Received: by 10.28.212.74 with SMTP id l71mr400043wmg.33.1511893404457; Tue, 28 Nov 2017 10:23:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.167.74 with HTTP; Tue, 28 Nov 2017 10:23:23 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Tue, 28 Nov 2017 13:23:23 -0500 Message-ID: To: Daniel McCarney Cc: Jacob Hoffman-Andrews , "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a1146987a4fd21b055f0f1d90" Archived-At: Subject: Re: [Acme] Landing PR#342 (proactive issuance with identifier-first) 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, 28 Nov 2017 18:23:30 -0000 --001a1146987a4fd21b055f0f1d90 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 28, 2017 at 1:19 PM, Daniel McCarney wrote: > I filed Issue #356 [1] to track the lost functionality here, and how we >> might want to add it back. > > > From #356: > > " In making that change, we dropped support for certain legacy back-end >> APIs that require a CSR before issuing challenges" > > > Which legacy back-end APIs are you referring to? I recall many weeks ago > you thought a specific commercial CA and a specific certificate re-seller > required CSR in new-order but both confirmed off-list they did not. > > It's frustrating to see continued resistance on the back of constraints > imposed by vague legacy systems without name. Where are the > users/maintainers of these systems to express their concerns at the > perceived "drop of support" to the working group directly? > Dude, it's just a tracking issue, assigned to the Defer milestone. It's not blocking any work here. The canonical example for me here is SSLMate [1], which takes a CSR up front, I'm told because the back-ends it uses require it. Andrew Ayer, who maintains SSLMate, is on this list, and might be able to provide further insight. But like I said, this is not blocking anything for the base spec any more. It's just a possible extension if someone shows up and asks for the feature. --Richard [1] https://sslmate.com/help/api/rest > > - Daniel / cpu > > > On Tue, Nov 28, 2017 at 1:05 PM, Richard Barnes wrote: > >> I think this is fine to land now. It's not my favorite approach, but >> there's clear consensus. I filed Issue #356 [1] to track the lost >> functionality here, and how we might want to add it back. >> >> https://github.com/ietf-wg-acme/acme/issues/356 >> >> On Mon, Nov 27, 2017 at 3:04 PM, Jacob Hoffman-Andrews >> wrote: >> >>> Hi all, >>> >>> Daniel McCarney's been working on PR#342, which changes the new-order >>> flow to take a list of identifiers instead of a CSR, and to be finalized >>> with a CSR: https://github.com/ietf-wg-acme/acme/pull/342. We've had >>> some back-and-forth on the list about this, versus CSR-first, versus >>> CSR-first-and-last. There was some further discussion at IETF 100 >>> (minutes: >>> https://github.com/thomas-fossati/acme-minutes/blob/master/ietf-100.md), >>> and we hummed to accept PR 342 over the alternatives. >>> >>> If there's anyone here who couldn't make it to the meeting and would >>> like to raise strenuous objections, please speak up now, otherwise we'll >>> incorporate that change. >>> >>> Thanks, >>> Jacob >>> >>> _______________________________________________ >>> 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 >> >> > --001a1146987a4fd21b055f0f1d90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Nov 28, 2017 at 1:19 PM, Daniel McCarney <= cpu@letsencrypt.or= g> wrote:
=C2=A0I filed Issue #356 [1] to track the lost functionali= ty here, and how we might want to add it back.

= >From #356:

" = In making that change, we dropped support for certain legacy back-end APIs = that require a CSR before issuing challenges"

Whi= ch legacy back-end APIs are you referring to? I recall many weeks ago you t= hought a specific commercial CA and a specific certificate re-seller requir= ed CSR in new-order but both confirmed off-list they did not.

It'= ;s frustrating to see continued resistance on the back of constraints impos= ed by vague legacy systems without name. Where are the users/maintainers of= these systems to express their concerns at the perceived "drop of sup= port" to the working group directly?

Dude, it's just a tracking issue, assigned to the Defe= r milestone.=C2=A0 It's not blocking any work here.

<= /div>
The canonical example for me here is SSLMate [1], which takes a C= SR up front, I'm told because the back-ends it uses require it.=C2=A0 A= ndrew Ayer, who maintains SSLMate, is on this list, and might be able to pr= ovide further insight.

But like I said, this is no= t blocking anything for the base spec any more.=C2=A0 It's just a possi= ble extension if someone shows up and asks for the feature.
<= br>
--Richard




On Tue, Nov 28, 2017 at 1:05 PM, Richard Bar= nes <r= lb@ipv.sx> wrote:
I think= this is fine to land now.=C2=A0 It's not my favorite approach, but the= re's clear consensus.=C2=A0 I filed Issue #356 [1] to track the lost fu= nctionality here, and how we might want to add it back.

<= /div>

On Mon, Nov 27, 2017 at 3:04 PM, Jacob Hoffman-Andrews <jsha@eff.or= g> wrote:
https://github.com/ietf-wg-acme/acme= /pull/342. We've had
some back-and-forth on the list about this, versus CSR-first, versus
CSR-first-and-last. There was some further discussion at IETF 100
(minutes:
https://github.com/thomas-foss= ati/acme-minutes/blob/master/ietf-100.md),
and we hummed to accept PR 342 over the alternatives.

If there's anyone here who couldn't make it to the meeting and woul= d
like to raise strenuous objections, please speak up now, otherwise we'l= l
incorporate that change.

Thanks,
Jacob

_______________________________________________
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



--001a1146987a4fd21b055f0f1d90-- From nobody Tue Nov 28 10:28:14 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3C9128B37 for ; Tue, 28 Nov 2017 10:28:12 -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 GejUSvnNc41L for ; Tue, 28 Nov 2017 10:28:09 -0800 (PST) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4A93126CE8 for ; Tue, 28 Nov 2017 10:28:09 -0800 (PST) Received: by mail-it0-x22a.google.com with SMTP id p139so903352itb.1 for ; Tue, 28 Nov 2017 10:28: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=s2BV5FrCZ2C35svhrOgCAUJQjSe0wt79xt0PH8WcbGw=; b=JGkQFAADO1FyyB1hlkRImIlwui3Pc80vGL07YKn80BmYTBOoXNhlyvwLMJS7gie6BL vtlEyED8dSXgV1TT/vJFoCCnytKw9rgb3L/jdgUxueGu5e46OJNncGcsqm0rcBRdSfKb 00hCh55vJgu4IHNT1jPukGa9F2ZFtCSJMNZi8= 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=s2BV5FrCZ2C35svhrOgCAUJQjSe0wt79xt0PH8WcbGw=; b=je3GJhlSCR7m3W/ojLAxLoZ5+L/2nJp1B5LRFqDMdVhDQ5EXG25J5CwxavqC0Jws2i nTlNmwWBr5Km1xUM15GXfbVkIKquwyQ216E01u5BlxLaF74cFqG9wFysjQtOFLcxPgtY IUXDG8lxYchNUDJBxRmlKXOL6QeBXhJkMmvqNkxeNpclYY4Ba0ODlOWdHsyZjfZbwI6y ecmutSNqx8CmZp/S9CGwPtS7fqfNTSd3GPRznsd1Y+y/+2jMPAjh5rMxI6GuV2/AeFkI FpiyxT+8U6tQXDfn8spybi53BQu4bEU9kzKc5hC1QC1/uakjXGXhLL/Mugm6fSQ3+mFm +r2w== X-Gm-Message-State: AJaThX7w9Ea5rYXQOpZpfsrdRDuh3eD8xi0bSLJ3rGJHr7lYI8H7WHQR mIID/0wsUi8zHSQqDg0XnHOAmrQhMAHs0r2dh9brWg== X-Google-Smtp-Source: AGs4zMblDvRvD+xyciPWxX1Z8aOQDtlDXxv2gHaQtP/gxrTcGUiU5sX1VE0fpBwtiTRQd3787YWHtUdM+sgwH7oU1xQ= X-Received: by 10.36.26.193 with SMTP id 184mr3691791iti.53.1511893688872; Tue, 28 Nov 2017 10:28:08 -0800 (PST) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.17.28 with HTTP; Tue, 28 Nov 2017 10:28:08 -0800 (PST) In-Reply-To: References: From: Daniel McCarney Date: Tue, 28 Nov 2017 13:28:08 -0500 Message-ID: To: Richard Barnes Cc: Jacob Hoffman-Andrews , "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a1143ec7443a66b055f0f2e47" Archived-At: Subject: Re: [Acme] Landing PR#342 (proactive issuance with identifier-first) 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, 28 Nov 2017 18:28:12 -0000 --001a1143ec7443a66b055f0f2e47 Content-Type: text/plain; charset="UTF-8" > > The canonical example for me here is SSLMate [1], which takes a CSR up > front, I'm told because the back-ends it uses require it. Andrew Ayer, who > maintains SSLMate, is on this list, and might be able to provide further > insight. SSLMate/Andrew are the reseller I recall confirming could accommodate #342 without needing a CSR in new-order. I hope Andrew can clarify if I'm remembering incorrectly. On Tue, Nov 28, 2017 at 1:23 PM, Richard Barnes wrote: > > > On Tue, Nov 28, 2017 at 1:19 PM, Daniel McCarney > wrote: > >> I filed Issue #356 [1] to track the lost functionality here, and how we >>> might want to add it back. >> >> >> From #356: >> >> " In making that change, we dropped support for certain legacy back-end >>> APIs that require a CSR before issuing challenges" >> >> >> Which legacy back-end APIs are you referring to? I recall many weeks ago >> you thought a specific commercial CA and a specific certificate re-seller >> required CSR in new-order but both confirmed off-list they did not. >> >> It's frustrating to see continued resistance on the back of constraints >> imposed by vague legacy systems without name. Where are the >> users/maintainers of these systems to express their concerns at the >> perceived "drop of support" to the working group directly? >> > > Dude, it's just a tracking issue, assigned to the Defer milestone. It's > not blocking any work here. > > The canonical example for me here is SSLMate [1], which takes a CSR up > front, I'm told because the back-ends it uses require it. Andrew Ayer, who > maintains SSLMate, is on this list, and might be able to provide further > insight. > > But like I said, this is not blocking anything for the base spec any > more. It's just a possible extension if someone shows up and asks for the > feature. > > --Richard > > > [1] https://sslmate.com/help/api/rest > > > >> >> - Daniel / cpu >> >> >> On Tue, Nov 28, 2017 at 1:05 PM, Richard Barnes wrote: >> >>> I think this is fine to land now. It's not my favorite approach, but >>> there's clear consensus. I filed Issue #356 [1] to track the lost >>> functionality here, and how we might want to add it back. >>> >>> https://github.com/ietf-wg-acme/acme/issues/356 >>> >>> On Mon, Nov 27, 2017 at 3:04 PM, Jacob Hoffman-Andrews >>> wrote: >>> >>>> Hi all, >>>> >>>> Daniel McCarney's been working on PR#342, which changes the new-order >>>> flow to take a list of identifiers instead of a CSR, and to be finalized >>>> with a CSR: https://github.com/ietf-wg-acme/acme/pull/342. We've had >>>> some back-and-forth on the list about this, versus CSR-first, versus >>>> CSR-first-and-last. There was some further discussion at IETF 100 >>>> (minutes: >>>> https://github.com/thomas-fossati/acme-minutes/blob/master/ietf-100.md >>>> ), >>>> and we hummed to accept PR 342 over the alternatives. >>>> >>>> If there's anyone here who couldn't make it to the meeting and would >>>> like to raise strenuous objections, please speak up now, otherwise we'll >>>> incorporate that change. >>>> >>>> Thanks, >>>> Jacob >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> > --001a1143ec7443a66b055f0f2e47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The cano= nical example for me here is SSLMate [1], which takes a CSR up front, I'= ;m told because the back-ends it uses require it.=C2=A0 Andrew Ayer, who ma= intains SSLMate, is on this list, and might be able to provide further insi= ght.

SSLMate/Andrew are the reseller I recall confirmi= ng could accommodate #342 without needing a CSR in new-order. I hope Andrew= can clarify if I'm remembering incorrectly.



On Tue, N= ov 28, 2017 at 1:23 PM, Richard Barnes <rlb@ipv.sx> wrote:

<= br>
On Tue, Nov 28, 2017 at 1:19= PM, Daniel McCarney <cpu@letsencrypt.org> wrote:
=C2=A0I filed Issue #356 [1] to track the lost functionality here, = and how we might want to add it back.

From #356= :

" In making= that change, we dropped support for certain legacy back-end APIs that requ= ire a CSR before issuing challenges"

Which legacy= back-end APIs are you referring to? I recall many weeks ago you thought a = specific commercial CA and a specific certificate re-seller required CSR in= new-order but both confirmed off-list they did not.

It's frustr= ating to see continued resistance on the back of constraints imposed by vag= ue legacy systems without name. Where are the users/maintainers of these sy= stems to express their concerns at the perceived "drop of support"= ; to the working group directly?

Dude, it's just a tracking issue, assigned to the Defer = milestone.=C2=A0 It's not blocking any work here.

The canonical example for me here is SSLMate [1], which takes a CSR= up front, I'm told because the back-ends it uses require it.=C2=A0 And= rew Ayer, who maintains SSLMate, is on this list, and might be able to prov= ide further insight.

But like I said, this is not = blocking anything for the base spec any more.=C2=A0 It's just a possibl= e extension if someone shows up and asks for the feature.
--Richard



=C2=A0

- Daniel / cpu


On Tue, Nov 28, 2017 at 1:05 PM, Richard Barnes <rlb@ipv.s= x> wrote:
I think this is fine to land now.=C2=A0 It's not my favorite appr= oach, but there's clear consensus.=C2=A0 I filed Issue #356 [1] to trac= k the lost functionality here, and how we might want to add it back.


On Mon, = Nov 27, 2017 at 3:04 PM, Jacob Hoffman-Andrews <jsha@eff.org> wro= te:
Hi all,

Daniel McCarney's been working on PR#342, which changes the new-order flow to take a list of identifiers instead of a CSR, and to be finalized with a CSR: https://github.com/ietf-wg-acme/acme= /pull/342. We've had
some back-and-forth on the list about this, versus CSR-first, versus
CSR-first-and-last. There was some further discussion at IETF 100
(minutes:
https://github.com/thomas-foss= ati/acme-minutes/blob/master/ietf-100.md),
and we hummed to accept PR 342 over the alternatives.

If there's anyone here who couldn't make it to the meeting and woul= d
like to raise strenuous objections, please speak up now, otherwise we'l= l
incorporate that change.

Thanks,
Jacob

_______________________________________________
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




--001a1143ec7443a66b055f0f2e47-- From nobody Tue Nov 28 10:44:17 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C52128D40 for ; Tue, 28 Nov 2017 10:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 KisIssbev5fp for ; Tue, 28 Nov 2017 10:44:08 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36958128D0F for ; Tue, 28 Nov 2017 10:44:08 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id 64so1403855wme.3 for ; Tue, 28 Nov 2017 10:44:08 -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=N2ElsQRuD+MkN7SRpSAAUCPEMR+fbMrTigyNw3keDcg=; b=yz/mk/Hef0UOGBfyqpqNdwoDgS0jKmUZZhBK5IAcwMtL/WlS/pBKmYqOvumZyIiSAy Srcpm3eEwgMH7X0LnOezPWYm3Ij7953Gx4h41mZiHJNhb/xosm+pN+Y1TfqIXg56XB1g aAqMlhGI2qpIBYq2mGI76qWfLEBYkSFNWnNXJyrl2oKCJbbPpJ0qAV1LYkc0dUtKBqw9 h8QWTDyq+zapqghr/NkF6Dak8odFZcuF42zsYqRUsIfWWINJ0sgoMl82E6Moc0fP3bAx vJX+BQQDdDfQHeLxFjZJXiY4Q2qTvdUPpdbAiKreQPNIgA4KGtcJmQSV69sma+0F2wZP io+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=N2ElsQRuD+MkN7SRpSAAUCPEMR+fbMrTigyNw3keDcg=; b=ZDG+AIWddHBMpOUVH2rvsx7NEvmq4lB4Li71n5HO1a7zcM9BTFbMh5c/5yj+SuOyxF Y36vt8BVm1OoVGgbpxz9Hn06h4oMl5VW6X6FFkKspJVYjTLTZYstt5eLb8Wp8QtmYB7Y 0F77CnB8OudFzlTGQ87lMfdatFDyaUm8YZ7a2xhR70WIr+z9HRu3+AEcaQnVn/nY6zyF UhBgUFwDVsBGpNslFOhRlN7LQqW8n9QapwylVBsTJzVZeQNrLxnMciED4ppHseyzdQnh oqI8RyXd2hQ/4hNB/dEIfL2r+rbA4eI1OjEjw1+dxRBd87thIS29wUcmiN/GzPLDGQQG MOEw== X-Gm-Message-State: AJaThX6asZScqESUZw9byDFbWBiFLBwmWiridD600O9Zx3QcIzceqHdG a0BdiwGWH9wJpJCssuUBxfancQshes/G/yEFiKe0Mw== X-Google-Smtp-Source: AGs4zMZ2B6H7lM73KuF9RU3SPUF47dSckdF7ttnDn3RL4QUWqtAk9wcG92+RhHJxaTbm9l7ZvvvyKWNk0Xwi2wMbaCQ= X-Received: by 10.28.113.71 with SMTP id m68mr531765wmc.1.1511894646631; Tue, 28 Nov 2017 10:44:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.167.74 with HTTP; Tue, 28 Nov 2017 10:44:05 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Tue, 28 Nov 2017 13:44:05 -0500 Message-ID: To: Martin Stiemerling Cc: "acme@ietf.org" , tsv-art@ietf.org Content-Type: multipart/alternative; boundary="001a11478b0c59e94a055f0f670c" Archived-At: Subject: Re: [Acme] TSV-ART review of draft-ietf-acme-acme-08 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, 28 Nov 2017 18:44:10 -0000 --001a11478b0c59e94a055f0f670c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the review, Martin. I've posted responses in a PR, along with a couple of other minor fixes: https://github.com/ietf-wg-acme/acme/pull/357 On Tue, Nov 28, 2017 at 5:38 AM, Martin Stiemerling wrote: > Hi all, > > I've reviewed this document as part of the transport area review team's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the > document's authors for their information and to allow them to address any > issues raised. When done at the time of IETF Last Call, the authors shoul= d > consider this review together with any other last-call comments they > receive. Please always CC tsv-art@=E2=80=A6 if you reply to or forward th= is > review. > > Summary: > This draft is basically ready for publication, but has nits that should b= e > fixed before publication. > > Editorials: > - Abstract says "DISCLAIMER:...": > This should be removed before publication or there is an issue with the > intended status of Standards Track. > > - A nit, but: section 7.3.4 uses http instead of https in the example: > "instance": "http://example.com/agreement/?token=3DW8Ih3PswD-8" > All other instances use https. > > > Technicals: > > - Section 8.2. Retrying challenges > Any guidance on what "some times" means? At least in terms of a time > scale, e.g., seconds, minutes, hours? > > > Thanks for the clearly written document! > > Regards, > > Martin Stiemerling > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a11478b0c59e94a055f0f670c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review, Martin.=C2=A0 I've posted = responses in a PR, along with a couple of other minor fixes:


On Tue, Nov 28, 2017 at 5:3= 8 AM, Martin Stiemerling <mls.ietf@gmail.com> wrote:
Hi all,

I've reviewed this document as part of the transport area review team&#= 39;s ongoing effort to review key IETF documents. These comments were writt= en primarily for the transport area directors, but are copied to the docume= nt's authors for their information and to allow them to address any iss= ues raised. When done at the time of IETF Last Call, the authors should con= sider this review together with any other last-call comments they receive. = Please always CC tsv-art@=E2=80=A6 if you reply to or forward this review.<= br>
Summary:
This draft is basically ready for publication, but has nits that should be = fixed before publication.

Editorials:
- Abstract says "DISCLAIMER:...":
This should be removed before publication or there is an issue with the int= ended status of Standards Track.

- A nit, but: section 7.3.4 uses http instead of https in the example:
"instance": "http://example.com/agr= eement/?token=3DW8Ih3PswD-8"
All other instances use https.


Technicals:

- Section 8.2. Retrying challenges
Any guidance on what "some times" means? At least in terms of a t= ime scale, e.g., seconds, minutes, hours?


Thanks for the clearly written document!

Regards,

=C2=A0 Martin Stiemerling

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

--001a11478b0c59e94a055f0f670c-- From nobody Tue Nov 28 12:57: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 9953812773A for ; Tue, 28 Nov 2017 12:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 jPVOZN4dqvwR for ; Tue, 28 Nov 2017 12:57:35 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B175120227 for ; Tue, 28 Nov 2017 12:57:34 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id 9so2148040wme.4 for ; Tue, 28 Nov 2017 12:57:34 -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; bh=+lpDpXStYkGj3nP1UFLCCbmqW7wiB6af504a9PVO6Ac=; b=ul8nZH1Z1VENjV/kmxNc/67r/Jm7aD0/oHdNVLWfmxMq2G9upZ6LncfpQRxuR6EM7w Uw0EOBI/HTBR8gVEMeduDuazvz+OCs1c9KrRNK4N2Vw1Z1wckOT3inXxRQu9PKckPQ+O SOPDvwY7+RcxZuevYDvlDzqhnYEpkc1NmupM0LIrAdKVWjZC69MPWq74WZ9ktnWLahKV Yha7BZz/7yZr9FYfOur0Vd9zxUe4nQF/S0Zc9j1jlLHJOSb4F/8dpsg/l7ckKhN0/jem ZbEn+pxo8I/6PWwPs6wZ627PCc54t9TCkWyyD2xPBnfFHTmmpPSLGsqZyO4PSnITfr9t tWGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=+lpDpXStYkGj3nP1UFLCCbmqW7wiB6af504a9PVO6Ac=; b=lMGKPfmo74ZXnAd8r2JbhhHQjGv66XThLBfgqasLkdRJWLuKbJvzkzN3K4sznLvtql QAYRFiIXAtFGwwNwUGfYTX1jfUeig6zJtAjhSyTaPed0zgtUVEPWiDXPxk/sUc15KP9D gy3F4GzH6ZD9nSs1d/O0CVFaZuqHS1o/yqgHUpTIQyt5iRZf365ZKMFQb7LwKHN4mwFY ACX42dfP5WOJKv0c8+Y3eJ73JFv4CMyX4W6zZqaeKU2tbvh4qwn2sALyeSYPOJE/Nnpt FHICEJHQrtfkR2rtKm9WDnTpSTFVoEI1vN/lTf71L5qBkRdUfKl+05R4yBc+zU8IR3TD 4JTQ== X-Gm-Message-State: AJaThX6nE663DeMTiazauE4vCUndXWHm6WR4i0jOTiKKO8r+tN7uDHVL h2rHHt0HDCqFcDT4c20H11uRt49Rjn96qf8XYzEiXg== X-Google-Smtp-Source: AGs4zMazAHIMBZMQDS/4M1e4q5N0T96lPANJS5eYdsKrYrbit2m76I+QGI4Rv74kN/npag9mbG8fL5kKcmTK6CJGleY= X-Received: by 10.28.175.8 with SMTP id y8mr460914wme.21.1511902652091; Tue, 28 Nov 2017 12:57:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.167.74 with HTTP; Tue, 28 Nov 2017 12:57:31 -0800 (PST) In-Reply-To: References: <87d14kuuga.fsf@hobgoblin.ariadne.com> From: Richard Barnes Date: Tue, 28 Nov 2017 15:57:31 -0500 Message-ID: To: "Dale R. Worley" , "acme@ietf.org" , Alissa Cooper Content-Type: multipart/alternative; boundary="001a11444ab283680c055f1144e9" Archived-At: Subject: Re: [Acme] Resend: [Gen-art] Genart telechat review of draft-ietf-acme-acme-07] 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, 28 Nov 2017 20:57:41 -0000 --001a11444ab283680c055f1144e9 Content-Type: text/plain; charset="UTF-8" Re-adding the list / AD. On Tue, Nov 28, 2017 at 3:51 PM, Richard Barnes wrote: > Hi Dale, > > Thanks for the detailed review. I've posted updates in a PR for your > review: > > https://github.com/ietf-wg-acme/acme/pull/358 > > FWIW, these sorts of detailed comments will get addressed much more > quickly if they are submitted in PR form. > > Responses inline below, tagged with [RLB]. > > --Richard > > > > > On Tue, Nov 14, 2017 at 9:49 PM, Dale R. Worley > wrote: > > > > From: Dale Worley > To: > Date: Tue, 24 Oct 2017 18:55:40 -0700 > Archived-At: xI8YgzTpDS5KXRBaR0app5ynoQA> > Subject: [Gen-art] Genart telechat review of draft-ietf-acme-acme-07 > Cc: draft-ietf-acme-acme.all@ietf.org, acme@ietf.org, ietf@ietf.org > > Reviewer: Dale Worley > Review result: On the Right Track > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed by > the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > . > > Document: draft-ietf-acme-acme-07 > Reviewer: Dale R. Worley > Review Date: 2017-10-24 > IETF LC End Date: 2017-09-14 > IESG Telechat date: 2017-10-26 > > Summary: > > This draft is on the right track but has open issues, described in the > review. > > My general impression is that this is a sound piece of work, and > apparently one that satisfies a serious practical need. But this > draft has a large number of open issues, and really needs a careful, > thorough clean-up pass. And until that's done, it's not clear what > genuine problems might be lurking. > > I haven't put in the time I would have liked to, so some of the issues > I've detected might prove to be nonexistent. A lot of these issues > are simply English usage. The structure of the exposition needs to be > improved, including pulling the specialized vocabulary into a > glossary, providing overviews of processes whose multiple details are > discussed, etc. Some issues are technical slips, like missing > required fields in HTTP messages. Some seem to be more substantial > technical issues -- What is the versioning and extensibility system? > What are the requirements on POST operations that effectively carry no > more information than that the operation happens? And one question -- > the terms of service agreement -- seems to brush into legal > territory. The number and variety of these minor problems suggests > that the whole work needs to be thought through more carefully before > being frozen. > > Within that context, I will not attempt to sort these items into > categories or rate them on importance, but just list them in order by > parts of the text that they relate to. And note that a number of > these items are mentioned relative to only one of several places in > the text they apply to. > > ---------------------------------------------------------------------- > > There's a lot of talk about accounts, but no overview of the lifecycle > of an account. Compare to the presentation of the overview of the > lifecycle of a certificate request. > > There should be blanket policies on whether and where non-standard > fields can be included by both client and server. > > Also, there ought to be versioning of Acme itself. > > Abstract > > Certificates in PKI using X.509 (PKIX) are used for a number of > purposes, the most significant of which is the authentication of > domain names. > > I'm no expert here, but it seems to me that "the authentication of > domain names" is not correct -- only actors can be authenticated. I > think the accurate phrasing is "the authentication of servers (TLS, > HTTPS, etc.) which act on behalf of domain names". (This would be a > minor matter in the body, especially if this elision was universally > used in the field, but an abstract should require little context.) > > Ditto for the first paragraph of section 1. > > > [RLB] This is standard usage, and it seems to me that all of the > alternatives are less clear. > > > > > DISCLAIMER: This is a work in progress draft of ACME and has not yet > had a thorough security analysis. > > I assume that this is going to be removed once this document is > published as an RFC. If the RFC hadn't had a thorough security > analysis, there would be no value in publishing it as an RFC. However > there is no attached statement indicating when this statement is to be > removed. What is actually going on here? > > > [RLB] This is a legacy of earlier versions. Proposed for removal in #357 > > https://github.com/ietf-wg-acme/acme/pull/357 > > > > Table of Contents > > 6.4. Replay protection > 6.4.2. "nonce" (Nonce) JWS header parameter > 6.5. Rate limits > > These section titles aren't capitalized the same way as the other > section titles. > > > [RLB] Fixed. Also, "Threat model". > > > > > 1. Introduction > > Existing Web PKI certificate authorities tend to run on a set of ad > hoc protocols for certificate issuance and identity verification. > > s/run on/use/? > > > [RLB] Done. > > > > a typical user experience is something like: > > I think you want to broaden this to "a typical protocol is". That > doesn't change things much, because the user is one endpoint of the > protocol. But you don't want to de-emphasize what the CA does, > either. (I reflexively think of this as a protocol problem, whereas > the authors probably reflexively think of this as a user experience > problem.) > > > [RLB] The problem with the legacy "protocol" is that it is not automated, > which implies a bad UX, which implies that security doesn't scale. I don't > think a change is needed here. > > > > * Put a CA-provided challenge at a DNS location corresponding to > the target domain. > > What does "corresponding to" mean? I think you want "in a DNS record > for the target domain". > > > [RLB] Done. > > > > * Receive CA challenge at a (hopefully) administrator-controlled > email address corresponding to the domain and then respond to > it on the CA's web page. > > s/CA challenge/CA-provided challenge/ for parallelism. > > > [RLB] Done. > > > s/corresponding to the domain/within the domain/? > > > [RLB] No, "corresponding to", e.g., via WHOIS. > > > > It seems that there should be an item between the third and fourth > items: > > o The CA makes the newly issued certificate accessible to the > user (via the CA's web site? via e-mail?) > > > [RLB] Disagree, not substantive to the UX story. > > > > > -- > > This document describes an extensible framework for automating the > issuance and domain validation procedure, thereby allowing servers > and infrastructural software to obtain certificates without user > interaction. Use of this protocol should radically simplify the > deployment of HTTPS and the practicality of PKIX authentication for > other protocols based on Transport Layer Security (TLS) [RFC5246]. > > I think you need some background on why this matters. In the naive > default model, someone wants to set up a web server and needs to > obtain a certificate. Yes, this will require 1 to 3 hours, but it's a > one-time cost over the life of the web site. And I doubt that getting > one's self plugged into the Acme system of a CA will take *less* time. > > > [RLB] The "set up a web server" model accounts for a vanishingly small > portion of the web these days; most things run on hosting providers. And > several hosting providers are already using earlier versions of ACME to > enable "one-click" or "zero-click" HTTPS for hosted sites. > > Even for the self-hosting crowd, there are multiple web servers now that > provide instant HTTPS using ACME. > > https://www.youtube.com/watch?v=nk4EWHvvZtI > https://letsencrypt.org/2017/10/17/acme-support-in-apache-httpd.html > > > > Your model seems to be an operator that wants to set up many servers > that are authenticatable to many different identities, with each > identity being initially vouched for by the same operator. But this > suggests that the multiple identities are third parties that are in > some way subordinate or derived identities to the operator's identity, > either "departments" within one entity, or customers of a vendor. > > In particular, how does Acme work relative to the case where a service > provider claims it is setting up a web site for a third party? > > [RLB] This distinction is never made in practice. For example, the CDN > for example.com is indistinguishable from example.com from the vantage > point of a client or CA. Where some separation is desired, see > https://tools.ietf.org/html/draft-ietf-acme-star > > > [ruminations deleted] I think you need to underline that this only > handles the DV case, and not the OV and EV cases. > > [RLB] This is not true. The "external account binding" feature lets you > associate OV/EV authorizations with an ACME account, allowing the issuance > of EV certificates via ACME. And if you look back through the list > archives, there are multiple CAs that have said they intend to deploy it in > this way. > > > On the first > reading, I overlooked the bit about "automating the issuance and > domain validation procedure", and immediately started wondering how > Acme prevents a service provider from generating bogus web servers for > third parties, and thinking it doesn't. But I reflexively think of > certificates in terms of OV rather than DV. I suspect many readers > also make this assumption. > > 2. Deployment Model and Operator Experience > > The guiding use case for ACME is obtaining certificates for websites > (HTTPS [RFC2818]). > > You probably want to emphasize "obtaining domain validation-type > certificates ". > > [RLB] No. See above. > > > Prior to ACME, when deploying an HTTPS server, an operator typically > > This is the first use of "operator", so you probably want to say "the > server operator". > > [RLB] Done. > > > o The ACME client prompts the operator for the intended domain > name(s) that the web server is to stand for. > > Probably want to say "The operator's ACME client" to make it clear > that the client is working for/controlled by/attached to/located at > the operator. > > [RLB] Done. > > > o In the background, the ACME client contacts the CA and requests > that it issue a certificate for the intended domain name(s). > > It seems that all of the remaining steps are "in the background", as > they can run to completion without operator intervention. So I think > you want to emphasize "In the background" as an assertion about the > remaining steps as a group. > > [RLB] Disagree. > > > o The CA verifies that the client controls the requested domain > name(s). > > "here a miracle happens" -- I think you want to flesh this out or > provide a reference to the previous discussion, and especially > emphasize that the Internet operations are carried out by the Acme > client. E.g., "The ACME client proves to the CA that the operator > controls the domain by one of the above-described methods." But maybe > I'm being too fussy about the words "controls the requested domain > name(s)". > > > [RLB] Done. > > > o Once the CA is satisfied, the certificate is issued > > There's no point using the passive when the subject has already been > used in the sentence: "Once the CA is satisfied, it issues the > certificate". > > [RLB] Done. > > > In this way, it would be nearly as easy to deploy with a CA-issued > certificate as with a self-signed certificate. > > As someone who detests setting up yet another account for yet another > web site, I would like you to modify this to, "once the operator has > an ACME relationship with one or more CAs, it would be nearly ...". > > [Check how much work the operator needs to get his ACME client > connected to a CA. If this is easy, emphasize it in the intro, as > it's a major virtue of ACME!] > > [RLB] Disagree. (Well, I agree that it's a major virtue of ACME. I > disagree that a text change is needed.) > > > 3. Terminology > > The two main roles in ACME are "client" and "server". The ACME > client uses the protocol to ... > > An ACME client is represented by an "account key pair". The client > uses the private key ... > > These two paragraphs contain two sentences of terminology definition > and two paragraphs of setting up the structure of the ACME > client/server system. That's not a bad thing, but it's more than > simply "Terminology". > > Conversely, there's a lot of terminology in this draft that isn't > defined here. Probably foremost is "operator", but there should also > be some explanation of the use of "response" when that is used to > describe an HTTP *request*. > > One approach would be to move most of these two paragraphs into the > beginning of section 4, and then expanding section 3 to include > various terms that might not be familiar to people not fully involved > in certificate-issuance procedures. > > [RLB] Disagree. > > > The server uses the public key to verify the > authenticity and integrity of messages from the client. > > What information is given to the server by authenticating the request > using the public key? One possibility is that the server only needs > to know that two requests came from "the same" Acme client, in which > case all it needs to check is that both were signed by the same key. > But if the key conveys identity information to the server, how is that > managed? That should be described (or referenced) at the very > beginning of the protocol description, as that is the first action of > the Acme protocol, setting up the client and connecting it to the CA. > > [RLB] This is all specified in the account management sections below. > > > In many ways, ACME functions much like a traditional CA, > > I think you mean, "In many ways, an ACME server functions ...". > > [RLB] Done. > > > ACME allows a client to request certificate management actions using > a set of JavaScript Object Notation (JSON) messages carried over > HTTPS. In many ways, ACME functions much like a traditional CA, in > which a user creates an account, requests a certificate, and proves > control of the domains in that certificate in order for the CA to > sign the requested certificate. > > The first sentence of this paragraph should go after the part about > setting up the client/server relationship. The second sentence is > actually overview for all of section 4 and should stay at the > beginning of the section. > > [RLB] Disagree. > > > The server then validates the challenges to check that the client > has accomplished them. > > You may want to say "validates the responses to the challenges". (I'm > from an environment where the phrase "challenge/response" is used a > lot.) > > [RLB] Done. > > > the server will issue the requested certificate and make it > available to the client. > > If the Acme protocol can actually carry the certificate to the client, > you probably want to make that clear in this sentence. "and send it > to the client"? > > [RLB] Disagree. > > > Order > Signature -------> > > Required > <------- > Authorizations > > I assume that messages from the server are also signed. (How is the > client to authenticate that it is talking to the server it thinks it's > talking to?) I'd say, "the server's signatures also ought to be > shown", but at this level of detail, I probably prefer that the > signatures not be shown, as they seem to cause me visual clutter. > > [RLB] As is detailed below, the server's responses are authenticated using > HTTPS server authentication. > > > This chart seems to leave out a lot of steps. Perhaps: > > Order -------> > > <------- Required > Authorizations > > [Perform response actions.] > > Response Notification -------> > > [Verify response > actions.] > > <------- > Certificate > > [RLB] Disagree. > > > 6.2. Request Authentication > > * "jwk" (JSON Web Key, only for requests to new-account and > revoke-cert resources) > > For new-account requests, and for revoke-cert requests authenticated > by certificate key, there MUST be a "jwk" field. > > These two requirements don't appear to be the same. > > [RLB] These are not inconsistent. The first says that the MUST only > applies for those two request types, and the second reiterates that the > MUST applies for those two request types. > > > If the client sends a JWS signed with an algorithm that the server > does not support, then the server MUST return an error with status > code 400 (Bad Request) and type > "urn:ietf:params:acme:error:badSignatureAlgorithm". > > This is hard to understand until the type field is introduced below. > (The type field doesn't seem to be a standard feature of JWS.) Easier > wold be > > If the client sends a JWS signed with an algorithm that the server > does not support, then the server MUST return an error document > with status > code 400 (Bad Request) and > "urn:ietf:params:acme:error:badSignatureAlgorithm" in the "type" > field. > > [RLB] Disagree. > > > 6.3. Request URL Integrity > > As noted in Section 6.2 above, all ACME request objects carry a > "url" > header parameter in their protected header. > > Actually, section 6.2 calls it a "field". You should use consistent > terminology, particularly given that in the context of HTTP, the term > "header" has a special meaning. (What is the general usage in JWS > discussions?) > > [RLB] JWS also has a header, in fact two headers, a "protected" and > "unprotected" headers. The contents of these headers are called "header > parameters". This section is consistent with this usage. > > > Except for the directory resource, all ACME resources are addressed > with URLs provided to the client by the server. For these > resources, > the client MUST set the "url" header parameter to the exact string > provided by the server (rather than performing any re-encoding on > the > URL). The server SHOULD perform the corresponding string equality > check, configuring each resource with the URL string provided to > clients and having the resource check that requests have the same > string in their "url" header parameter. > > This is awkwardly phrased. Perhaps: > > Except for the directory resource, all ACME resources are addressed > with URLs provided to the client by the server. When addressing > these resources, the client MUST set the "url" header parameter to > the exact string provided by the server (rather than performing any > re-encoding on the URL). Conversely, the server MUST provide > clients with the URLs by which the resources can be addressed > through the server, and it SHOULD verify that the "url" header > parameter the client provides when accessing a resource is the same > string as the server provides clients for that resource. > > [RLB] Done (slightly differently). > > > 6.3.1. "url" (URL) JWS header parameter > > Perhaps the last two paragraphs of section 6.3 should be moved into > this section. > > This text is not as exact as I'd like. What does "to which this JWS > object is directed" mean? Do you mean "The request that contains this > object is not valid unless the HTTP request URL is exactly the same > string as the value of this header parameter." And the phrase "be a > string representing the URL" is extremely dangerous. Remember that a > URL *is* a string, and if you mess with character encodings or the > like, you get a *different* URL, albeit one that some process might > consider "equivalent" to the original URL for some purposes. > > I'm not up to date on HTTP, but there are some complications regarding > what the "request URI" of a request is; it's not always just the value > of the "request-URI" field of the request-line. There's probably a > set terminology for this concept; it would be wise to align with it. > > [RLB] There are a fair number of ambiguities around URLs. This WG has > tried to steer clear of them in the context of ACME using the string > comparison text above. For this header parameter, the specific semantic of > the string will be application-dependent, as with many other JWS fields. > > > 6.4. Replay protection > > In order to protect ACME resources from any possible replay attacks, > > Could this be shortened to "In order to protect ACME resources from > replay attacks, ..."? > > [RLB] Disagree. > > > Every JWS sent by an ACME client MUST include, in its protected > header, > > It's vague here what "JWS" means as an unqualified noun. I suspect, > "JWS object", but some other uses suggest that there is a larger JWS > construct within which the "object" is the "payload". In any case, > the terminology should be brought into alignment with the JWS > standard(s). > > [RLB] As noted above, this is standard JWS usage. > > > It's not clear why the nonces are provided in the Replay-Nonce header > rather than being provided in the JWS response. Compare when the > client sends the nonce, when it is provide inside the JWS object. > Indeed, this seems to be a layering violation -- the nonce is sent by > the server in a header, but sent by the client in the JWS. It would > be cleaner to send the nonce in both directions in a header, or send > it in both directions in the JWS. Perhaps the standard JWS > practice is to do it this way -- but the existence of section 6.4.1 > suggests otherwise. > > [RLB] Response bodies are not JWS objects. It's true that there is some > asymmetry here, but it has not been a problem in for deployments in > practice. > > > It might be worth noting that it is acceptable for the server to > "expire" unused nonces by not accepting nonces that were provided in > responses too far in the past. (Assuming you want to allow it.) > Since a client is required to retry requests that are rejected due to > nonce failure, and that retry is expected to be done promptly, this > behavior does not cause protocol failure. As written, this section > suggests that a server MUST NOT reject a request as long as the nonce > is valid, regardless of how long ago the nonce was issued. > > [RLB] There is no requirement at all that a server accept any given nonce, > only that it must NOT accept some nonces. > > > 6.4.1. Replay-Nonce > > This section reads very awkwardly. I think the intention is to > provide a specification of the Reply-Nonce header field that stands > alone. But it is a specification only in regard to the syntax of the > field, not the semantics. OTOH, the first sentence of the section > seems to be trying to describe the semantics of the field, which is > confusing since it is nowhere near complete. If you want to say > "generally, this field is to provide nonces that clients can use to > uniquely identify requests" you want to be careful to qualify it with > some statement that the exact usage is described in other > specifications. Wording this correctly could get awkward. > > [RLB] The semantics are described in the previous section. > > > The phrase "unique to each message" isn't clear with regard to scope. > Is it like SIP Call-Ids, which are unique over all space and time? Or > just unique over the history of the server? > > The language is not as clear as I'd like about where it appears. > Better to say "The server provides this header field in responses to > carry a server-generated nonce to the client..." and "The Replay-Nonce > header field MUST only be carried in HTTP response messages." > > [RLB] Disagree. > > > 6.4.2. "nonce" (Nonce) JWS header parameter > > Again, this section hints at but does not specify the semantics of the > datum. > > [RLB] As above, the semantics are application-specific. > > > > 6.5. Rate limits > > Creation of resources can be rate limited to ensure fair usage and > prevent abuse. Once the rate limit is exceeded, the server MUST > respond with an error with the type > "urn:ietf:params:acme:error:rateLimited". Additionally, the server > SHOULD send a "Retry-After" header indicating when the current > request may succeed again. If multiple rate limits are in place, > that is the time where all rate limits allow access again for the > current request with exactly the same parameters. > > This is written as of rate limiting is some sort of global correctness > property -- which can't be reduced to any property observable by > either client or server. The first sentence doesn't even state that > it's the *server* that can limit rates! Better is to clarify the > intentions and roles of the various actors: > > A server MAY limit the rate at which it accepts various requests > from various clients, e.g., to ensure fair usage and prevent abuse. > If a server desires to postpone submission of a particular request, > it MUST respond with an error with the type > "urn:ietf:params:acme:error:rateLimited". Additionally, the server > SHOULD [I can't see a reason why this isn't MUST] include a > "Retry-After" header indicating the time interval after which all > limitations the server is currently applying to this request will > permit processing of this request. Different requests (even if from > the same client) may be subject to different rate limits; the > Retry-After value gives no information about other requests. > > [RLB] Added "by servers" > > > -- > > In addition to the human readable "detail" field of the error > response, the server MAY send one or multiple tokens in the "Link" > header pointing to documentation about the specific hit rate limits > using the "urn:ietf:params:acme:documentation" relation. > > What does "token" mean here? From context, I think you mean > "link-value" (after RFC 5988), or better, "URI". > > [RLB] Changed "tokens" to "link relations" (after RFC 8288) > > > Also, the value "urn:ietf:params:acme:documentation" doesn't seem to > be placed in the IANA registry described in section 9.6. > > [RLB] Changed to use the standard "help" link relation type. > > > 6.6. Errors > > this document defines the > following standard tokens for use in the "type" field (within the > "urn:ietf:params:acme:error:" namespace): > > This isn't correct terminology. The namespace of these URNs is > "ietf". Part of the problem is that there isn't a standardized term > for the parts of a URN that are separated by colons, despite that > almost all URN namespaces use colons as major separators. I think > this version is both correct and readable: > > ... this document defines the following standard URIs for use in > the "type" field (where each listed token is appended to > "urn:ietf:params:acme:error:" to make the URI): > > +-----------------------+----------------------------------- > --------+ > | Token | Description > | > +-----------------------+----------------------------------- > --------+ > | badCSR | The CSR is unacceptable (e.g., due to a > | > | | short key) > | > > [RLB] Disagree. The nuances of URN terminology are not relevant to interop > here. > > > -- > > This list is not exhaustive. The server MAY return errors whose > "type" field is set to a URI other than those defined above. > Servers > MUST NOT use the ACME URN [RFC3553] namespace for errors other than > the standard types. > > "namespace" isn't really correct here, but I think "sub-namespace" is. > > [RLB] Disagree, as above. > > > Clients SHOULD display the "detail" field of all errors. > > s/display/display to the user/ > > [RLB] Disagree. > > > 7.1. Resources > > Each > function is listed in a directory along with its corresponding URL, > so clients only need to be configured with the directory URL. > > s/a directory/the directory resource/ > > [RLB] Disagree. > > > The "up" link relation from "cert" to the CA chain is not shown in the > figure. The "index" link relation isn't shown at all, though that > couldn't be shown easily. You might want to note that in some way in > the paragraph before the figure. > > [RLB] Disagree. > > > | Submit an order | POST new-order | 201 -> order | > > When I first read this, I was unclear what an "order" is. It turns > out that it is a request for a certificate. E.g., > > o Order resources, representing an account's requests to issue > certificates (Section 7.1.3) > > You might want to either move toward the nomenclature "request a > certificate" or more heavily emphasize "order" in the text. If you > enlarge section 2 to cover all the specialized terminology, putting an > entry in it for "order" would be helpful. > > [RLB] Disagree. > > > There are quite a number of example request responses that do not > contain the "index" link header. > > [RLB] This seems unlikely to lead to interop failure. > > > The figure does not show the key-change resource. > > [RLB] Done. > > > 7.1.1. Directory > > whose fields names are drawn from the following table > > s/fields names/field names/ > > [RLB] Done. > > > +-------------+--------------------+ > | Field | URL in value | > +-------------+--------------------+ > | new-nonce | New nonce | > | | | > | new-account | New account | > | | | > | new-order | New order | > | | | > | new-authz | New authorization | > | | | > | revoke-cert | Revoke certificate | > | | | > | key-change | Key change | > +-------------+--------------------+ > > In this table, one of the "URL in value" items is a predicate > (verb-object), which makes sense; one is a noun phrase naming an > action; and four are noun phrases (which are objects of an implied > "get" or "obtain"). I suggest rephrasing the items into predicates > directly telling what the URL does, e.g., "request new nonce", "change > key". > > [RLB] Disagree. > > > There is no constraint on the actual URL of the directory except > that > > "actual" is probably superfluous here. > > [RLB] Done. > > > The following metadata items are defined, all of which are OPTIONAL: > > It would probably be wise to allow servers to include non-standard > metadata items. > > [RLB] There is nothing forbidding it. > > > HTTP/1.1 200 OK > Content-Type: application/json > > This should be preceded by something like "An example response to a > directory GET is:". I suggest providing some sort of direct > description of each example, and it would help to show requests and > responses together. (But perhaps the RFC Editor thinks that unlabeled > examples are OK if the context makes their purpose clear enough.) > > [RLB] I think the purpose is clear enough from context. > > > 7.1.2. Account Objects > > contact (optional, array of string): An array of URLs that the > server can use to contact the client for issues related to this > account. For example, the server may wish to notify the client > about server-initiated revocation or certificate expiration. > > Strictly, you want "URIs" here, as tel:, sip:, and mailto: URIs are > not URLs [RFC 6068]. > > [RLB] There is long-standing consensus in the WG to use "URL" instead of > "URI" in this document, because it is more commonly used, and because the > exact line between URIs and URLs in not clear. For example, the WHATWG URL > spec does consider the examples you cite to be URLs. > > > 7.1.2.1. Orders List > > How long does an order URL remain valid? The particular URLs in the > example suggests that the order URLs are valid only as long as the set > of orders doesn't change. > > [RLB] The semantics here are the same as for an Amazon or Google search > results page. If the underlying data set changes, then the list provided > when dereferencing the URL will also change. No stability guarantees. > > > A larger question is whether order objects are ever purged from the > orders list? > > [RLB] Up to the server, subject to the guidance in this section. > > > Indeed, these questions can be generalized -- Can the server ever > purge resources, invalidating the URLs that pointed to them? What > sort of assurances can the client rely on? > > [RLB] What sort of assurances do you imagine the client needs? > > > 7.1.3. Order Objects > > For final > orders, the authorizations that were completed. > > What is a "final" order? The term "final" is used in a number of > places, with possibly slightly different meanings, and needs to be > properly defined. > > [RLB] Clarified, "(in the "valid" or "invalid" state)" > > > 7.1.4. Authorization Objects > > status (required, string): The status of this authorization. > Possible values are: "pending", "processing", "valid", "invalid" > and "revoked". > > It might be worth spelling out here what these states mean, as this is > the definition of this field of the authorization object. > > [RLB] These are described elsewhere with better context. > > > If this field is absent, then > the CA MUST consider this authorization valid for all orders > until > the authorization expires. > > There doesn't seem to be an "expired" status, so how can an > authorization expire? > > [RLB] This field has since been deleted. > > > For final authorizations it contains the > challenges that were successfully completed. > > What is a "final" authorization? > > [RLB] Clarified, "(in the "valid" or "invalid" state)" > > > Section 8 describes a set of challenges for domain name validation. > > Section 8 is about challenges generally; really the challenges for > domain name validation are sections 8.4 to 8.6. Perhaps they should > be grouped into a subsection and this sentence should point to that? > > [RLB] Disagree. The "and some other stuff" is implicit. > > > 7.3. Account Creation > > If the server wishes to present the client with terms under which > the > ACME service is to be used, it MUST indicate the URL where such > terms > can be accessed in the "terms-of-service" subfield of the "meta" > field in the directory object, and the server MUST reject > new-account > requests that do not have the "terms-of-service-agreed" set to > "true". Clients SHOULD NOT automatically agree to terms by default. > Rather, they SHOULD require some user interaction for agreement to > terms. > > I note that there seems to be no recording of when the account was > created, i.e., *when* the terms of service was agreed to. Since the > content behind the terms of service URL can change unpredictably, > noting that the terms of service were agreed to is meaningless unless > there is some fixation of the time of agreement. > > [RLB] Servers are welcome to log this information if they see fit. > > > an error of type "invalidContact". > > The wording of the text is inconsistent (or just unclear) whether > error types are give as full URNs or just the last component. > > [RLB] Errors are always provided as full URNs, as required by RFC 7807. > Add a clarification to the "Errors" section. > > > 7.3.4. Changes of Terms of Service > > The problem document returned with the error MUST also include an > "instance" field, indicating a URL that the client should direct a > human user to visit in order for instructions on how to agree to the > terms. > > This seems inconsistent with section 7.3, as the client can agree to > the terms of service when creating an account within Acme, but changes > in terms seem to require going out-of-band to agree to the new terms > of service. > > [RLB] The decision of the WG was that this was the correct trade-off given > that re-agreement is almost never needed. > > > Given that this could become a legal matter, it seems like a lot of > care and thought should be put in on this. Ideally, a good lawyer > should be consulted on this. > > [RLB] It's not the IETF's job to make legal decisions, just to make > mechanisms that work for participants. Several CAs weighed in to say this > mechanism was OK with them. > > > HTTP/1.1 403 Forbidden > Replay-Nonce: IXVHDyxIRGcTE0VSblhPzw > Link: ;rel="terms- > of-service" > Content-Type: application/problem+json > Content-Language: en > > The various examples don't seem to be indented consistently. Although > I expect the RFC Editor will clean that up. > > [RLB] As do I. > > > 7.3.5. External Account Binding > > This can be used to an ACME account with an > existing account in a non-ACME system, such as a CA customer > database. > > There's a word missing after "This can be used to". > > [RLB] This is fixed in https://github.com/ietf-wg-acme/acme/pull/357 > > > The server MAY require a value to be present for the "external- > account-binding" field. > > It would help the reader recover the context by starting this with, > "In an account creation request,". > > [RLB] Done. > > > To enable ACME account binding, a CA needs to provision the ACME > client with a MAC key and a key identifier. > > You might want to annotate this, "by some means outside the scope of > this document", or "presumably as part of establishing the external > account". And I would use "provide" rather than "provision" -- > "provision" suggests to me that there is a specific provisioning > process that will be defined. > > [RLB] Done. > > > What is a "MAC key"? I think you mean that any account binding must > be represented by a key pair for the external account, and the private > key of that pair is the "MAC key". > > OTOH, this may be inconveniently heavy-weight for real-world use -- I > would expect the CA to simply provide a secret associated with the > external account. (Or is that what a "MAC key" is?) > > [RLB] A MAC key is a key used to compute Message Authentication Codes, > i.e., a symmetric secret. > > > The ACME client then computes a binding JWS to indicate the external > account's approval of the ACME account key. > > This isn't quite correct. Perhaps > > The ACME client then computes a binding JWS to indicate that that > the client, the owner of the external account, approves of the ACME > account key. > > Or is that "the client, on behalf of the owner of the external > account"? > > [RLB] Changed to "external account holder's approval" > > -- > > MUST reflect value of the "external-account-binding" field > > s/reflect value/reflect the value/ > > [RLB] Done. > > > 7.3.6. Account Key Roll-over > > The client then encapsulates the key-change object in a JWS, signed > with the requested new account key (i.e., the key matching the > "newKey" value). > > The outer JWS MUST meet the normal requirements for an ACME JWS (see > Section 6.2). The inner JWS MUST meet the normal requirements, with > the following exceptions: > > Some detail is being left out. I think that the JWS described in the > first of these paragraphs becomes the "inner JWS" of the next > paragraph. But exactly how that nesting is to be performed doesn't > seem to be described. > > [RLB] Added some clarification. > > > 3. Check that the JWS protected header of the inner JWS has a "jwk" > field. > > Is the generation of the "jwk" field specified in the text anywhere? > > [RLB] It's just a public key generated by the client. Added a > clarification that "jwk" is REQUIRED in the inner JWS. > > > 7.4. Applying for Certificate Issuance > > then the > server MUST proactively issue the requested certificate and provide > a > URL for it in the "certificate" field of the order. > > I'm not sure that "proactively" has a specific meaning. I think you > can just s/proactively issue/issue/ and capture the desired meaning -- > the server doesn't have to issue a certificate instantly, but it > cannot delay. > > [RLB] This has been replaced in https://github.com/ietf-wg- > acme/acme/pull/342 > > > The status of the order will indicate what action the > client should take: > > This list is part of the definition of the order object, and should be > put in section 7.1.3. > > [RLB] Disagree. > > > 7.4.1. Pre-Authorization > > In some cases, a CA running an ACME server might have a completely > external, non-ACME process for authorizing a client to issue for an > identifier. > > I'm not sure that "client" is a proper subject for "issue". Perhaps > you mean "for authorizing a client to be issued certificate(s) for an > identifier". > > [RLB] Changed "issue" to "request issuance for" > > > 7.4.2. Downloading the Certificate > > A certificate resource represents a single, immutable certificate. > If the client wishes to obtain a renewed certificate, the client > initiates a new order process to request one. > > Though I think you want to add what you really mean, namely that the > new certificate will be fetched from a different URL. > > [RLB] Disagree. > > > 7.5. Identifier Authorization > > The server may declare > that an authorization is only valid for a specific order by setting > the "scope" field of the authorization to the URL for that order. > > "scope" isn't shown in the figure in section 7.1. > > [RLB] "scope" has been deleted https://github.com/ietf-wg- > acme/acme/pull/349 > > > 7.5.1. Responding to Challenges > > The server is said to "finalize" the authorization when it has > > Despite the existence of a section titled "Terminology", very little > of the terminology created for this document is listed there. > > [RLB] Disagree. > > > 8. Identifier Validation Challenges > > Each challenge must describe: > > This isn't right; a challenge doesn't describe anything. But the > descriptions of the challenge types include various information, etc. > > [RLB] Changed to "The definition of a new type of challenge" > > > status (required, string): The status of this authorization. > Possible values are: "pending", "valid", and "invalid". > > I think you mean "the status of this challenge". But you might mean > "the status of the authorization containing this challenge". > > [RLB] Typo. Done. > > > validated (optional, string): The time at which this challenge was > completed by the server > > I'm not sure in what sense you mean "completed by", since it's the > client that does the completing. I think you mean "the time at which > the server recognized that the challenge was completed". > > [RLB] Changed to "The time at which the server considered this challenge > complete" > > > The server can limit the size > of this object by limiting the number of times it will retry a > challenge. > > Rather, "the number of times it will permit the client to retry a > challenge". Actually, the semantics of this field probably depends on > the pattern of the actions by which the challenge is satisfied, and so > may be dependent on the challenge type. > > [RLB] Changed to "try to validate a challenge" > > > If the > server sets a challenge's "status" to "invalid", it SHOULD also > include the "error" field to help the client diagnose why the > challenge failed. > > Presumably, 'the "errors" field'. > > [RLB] Done. > > > Also, section 8.2, "The server MUST add an entry to the "errors" field > in the challenge after each failed validation query.", suggests that > the server MUST include the "errors" field, not just SHOULD include. > > [RLB] Suggests, but does not imply. A server could invalidate a challenge > just because it feels like it. > > > > 8.1. Key Authorizations > > A key authorization is a string that expresses > a domain holder's authorization for a specified key to satisfy a > specified challenge, by concatenating the token for the challenge > with a key fingerprint, separated by a "." character: > > key-authz = token || '.' || base64url(JWK_Thumbprint(accountKey)) > > In what way does a key authorization indicate something about a > "domain holder"? The k.a. includes the token (presumably from the > challenge object) and a computation based on an account's (private) > key, so it includes information from the account holder. > > Or do you mean that "in the challenge, a token will be sent by the > server that only the domain holder will be able to receive, and as > part of the account holder's response to the challenge, it composes a > key authorization string"? > > Really, I doubt that this is understandable without first explaining > the general model of challenge/response that the challenge types > defined here use, and that model doesn't seem to be described > anywhere. I think it would be very helpful if that model was > presented first, before the specific challenge types that use that > model. > > Alternatively, you could just describe this as an abstract operation > on strings, > > key-authz(token, accountKey) = > token || '.' || base64url(JWK_Thumbprint(accountKey)) > > and leave defining its semantics to where key-authz() is used. > > [RLB] Disagree. > > > The "JWK_Thumbprint" step indicates the computation specified in > [RFC7638], using the SHA-256 digest [FIPS180-4]. As noted in JWA > [RFC7518] any prepended zero octets in the JWK object MUST be > stripped before doing the computation. > > The second sentence seems to be unclear. Is the "JWK object" the > output of "JWK_Thumbprint(accountKey)"? If so, why isn't it called > "the JWK_Thumbprint object"? And the significance of "prepended zero > octets" is unclear; RFC 7518 does not include the word "prepend", so > presumably does not specify any prepending. I suspect you mean that > some stage of the processing of RFC 7518 is modified by stripping > initial zero octets from some string, but such octets wouldn't be > described as "prepended". > > [RLB] This is a minor issue with RSA keys, where sometimes integers have > zeros prepended to make clear that they're positive. Changed to "any > prepended zero octets in the fields of a JWK object". > > > 8.2. Retrying Challenges > > Clients can explicitly request a retry by re-sending their response > to a challenge in a new POST request (with a new nonce, etc.). > > Again, this makes sense only under the assumption that satisfying a > challenge has certain data-flow patterns, in that (apparently) the > client must send a "response" and then -- well, it's not entirely > clear what "a retry" is. You really need to lay out this pattern -- > and the names you use for the actions within it -- before you specify > the details of how clients and servers can perform it. > > [RLB] Disagree. > > > In order to avoid > denial-of-service attacks via client-initiated retries, servers > SHOULD rate-limit such requests. > > There are two uses of "request" in the preceding sentence -- which of > them is being rate-limited? > > [RLB] The noun "request" appears twice, but referencing the same action. > > > 8.3. HTTP Challenge > > With HTTP validation, the client in an ACME transaction proves its > control over a domain name by proving that for that domain name it > can provision resources to be returned by an HTTP server. > > Better, "by proving that it can provision resources that are returned > by > an HTTP server accessible using a URL whose host is that domain name". > > [RLB] Done. > > > type (required, string): The string "http-01" > > You don't actually say that these two fields are part of HTTP > challenge objects. > > [RLB] Disagree. > > > It MUST NOT contain any characters outside the base64url > alphabet, > including padding characters ("="). > > This could be read two ways; are the padding characters part of "the > base64url alphabet", or are they part of "characters outside the > base64url alphabet"? Perhaps: > > It MUST NOT contain any characters that are outside the > base64url alphabet, or padding characters ("="). > > or > > It MUST NOT contain any characters that are outside the > base64url alphabet (including padding characters ("=")). > > Maybe better would be "It must contain only characters in the > base64url alphabet including/excluding padding characters("=")." > > Actually, this is just ugly to specify using English, because it's > really hard to say it without using two negatives in one sentence, and > making clear what the scope of each negative is. I think the best > approach is to rely on the fact that RFC 7515 section 2 clearly > defines that "=" is *not* in the base64url alphabet: > > It MUST NOT contain any characters that are not in the base64url > alphabet. > > If someone complains this is unclear, add separate sentence saying > that following RFC 7515 section 2, "=" is not in the base64url > alphabet. > > [RLB] Done. > > > The value of the resource MUST be the ASCII representation of the > key authorization. > > Given that the key authorization is an ASCII string, it's not clear > what its "ASCII representation" is. > > [RLB] Given that some systems do not use UTF-8 as their string encoding > (e.g., JavaScript uses UTF-16), it doesn't hurt to re-emphasize this. > > The client's response to this challenge indicates its agreement to > this challenge by sending the server the key authorization covering > the challenge's token and the client's account key. > > I think you mean, "The client responds to this challenge by POSTing an > update to the challenge object, adding a "keyAuthorization" field > containing the key authorization derived from the challenge's token > and the client's account key." > > [RLB] Changed "this challenge" to "the validation request" > > > 1. Construct a URL by populating the URL template [RFC6570] > "http://{domain}/.well-known/acme-challenge/{token}", where: * > the domain field is set to the domain name being verified; and * > the token field is set to the token in the challenge. > > What do the "*" mean? > > [RLB] Those are supposed to be bullets. Reformatted. > > > 8.5. DNS Challenge > > The record provisioned to the DNS is the base64url encoding of this > digest. > > This doesn't make sense, as a DNS record is not a string per se. > However, the next two sentences make clear what the DNS record should > be. > > [RLB] Changed "is" to "contains" > > > _acme-challenge.example.org. 300 IN TXT "gfj9Xq...Rg85nM" > > It's not clear where "gfj9Xq...Rg85nM" came from, as it's supposed to > be a SHA-256 digest. Though the previous paragraph doesn't specify > how the digest is to be represented; in parallel to earlier > discussion, lower-case hexadecimal seems to be assumed. > > [RLB] No, as it says just above this, it is the base64url encoding of the > digest. > > > 8.6. Out-of-Band Challenge > > the client indicates this by sending a simple > acknowledgment response to the server. > > The text doesn't describe what a "simple acknowledgements response" > is. > > However, the other challenge types involve what seem to be parallel > acknowledgment responses that are required to contain copies of token > values, though in none of these cases does the POST carry any actual > information other than the fact that the POST was made to the > particular URL. What is the reason for this inconsistency? For that > matter, why does the payload of the response for this challenge > contain a "type" field? > > [RLB] This has been simplified in https://github.com/ietf-wg- > acme/acme/pull/357 > > > Perhaps there is something I don't understand about these POSTs which > seem to convey no information other than triggering the server to take > some action with regard to the target resource. > > [RLB] Sometimes you don't need any more information! :) It's still > important for these to be POSTs, though, so that they're authenticated. > > > 9.1. MIME Type: application/pem-certificate-chain > > The "Media Types" registry should be updated with the following > additional value: > > IMO it's better to phrase this, "The following entry should be added > to the "Media Types" registry:". I like to use "update" only for > operations that modify existing entries. > > [RLB] Disagree. > > > File should contain one or more certificates encoded as PEM > according > to RFC 7468 [RFC7468]. > > "should contain"? I think you want to say "File contains". Actually, > "File must consist of ...". > > [RLB] Changed to "contains" > > > "encoded as PEM" seems to be undefined by RFC 7468. Perhaps "encoded > using PEM textual encoding according to RFC 7468" is meant. > > [RLB] Done. > > > 9.6. URN Sub-namespace for ACME (urn:ietf:params:acme) > > I don't see how this specifies that this registry is connected with > the the registry (ACME Error Types, section 9.7.3) which provides the > final component of "urn:ietf:params:acme:*" URNs. I suspect you want > the "Repository" datum in this section to state that it points to the > registry created per section 9.7.3. > > [RLB] There is already a request for the RFC editor to "replace URL-TBD > with the URL assigned by IANA for registries of ACME parameters" > > 9.7. New Registries > > Is there a registry for fields in authorization objects? > > [RLB] Added one. > > 9.7.4. Resource Types > > Are there entries for "new-nonce" and "new-authz"? > > [RLB] Done. > > [END] > > > > --001a11444ab283680c055f1144e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Re-adding the list / AD.

On Tue, Nov 28, 2017 at 3:51 PM, Richard = Barnes <rlb@ipv.sx> wrote:
Hi Dale,

Thanks for the detailed review.=C2=A0 I've p= osted updates in a PR for your review:

https://github.com/ietf-wg-<= wbr>acme/acme/pull/358

FWIW, these sorts of detailed comments wi= ll get addressed much more quickly if they are submitted in PR form.
Responses inline below, tagged with [RLB].

--Richard




On Tue, Nov 14, 2017 at 9:49 PM, Dale R. Worley <= ;worley@ariadne.com= > wrote:



=C2=A0=C2=A0=C2=A0 From: Dale Worley <worley@ariadne.com= >
=C2=A0=C2=A0=C2=A0 To: <gen-art@ietf.org>
=C2=A0=C2=A0=C2=A0 Date: Tue, 24 = Oct 2017 18:55:40 -0700
=C2=A0=C2=A0=C2=A0 Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/xI= 8YgzTpDS5KXRBaR0app5ynoQA>
=C2=A0=C2=A0=C2=A0 Subject: [Gen-art] = Genart telechat review of draft-ietf-acme-acme-07
=C2=A0=C2=A0=C2=A0 Cc:= dra= ft-ietf-acme-acme.all@ietf.org, acme@ietf.org, ietf@ietf.org

=C2=A0=C2=A0=C2=A0 Reviewer: Dale Worl= ey
=C2=A0=C2=A0=C2=A0 Review result: On the Right Track

=C2=A0=C2= =A0=C2=A0 I am the assigned Gen-ART reviewer for this draft.=C2=A0 The Gene= ral Area
=C2=A0=C2=A0=C2=A0 Review Team (Gen-ART) reviews all IETF docum= ents being processed by
=C2=A0=C2=A0=C2=A0 the IESG for the IETF Chair.= =C2=A0 Please wait for direction from your
=C2=A0=C2=A0=C2=A0 document s= hepherd or AD before posting a new version of the draft.

=C2=A0=C2= =A0=C2=A0 For more information, please see the FAQ at
=C2=A0=C2=A0=C2=A0= <https://wiki.tools.ietf.org/area/gen/wiki/GenArtfaq>= ;.

=C2=A0=C2=A0=C2=A0 Document:=C2=A0 draft-ietf-acme-acme-07
=C2= =A0=C2=A0=C2=A0 Reviewer:=C2=A0 Dale R. Worley
=C2=A0=C2=A0=C2=A0 Review= Date:=C2=A0 2017-10-24
=C2=A0=C2=A0=C2=A0 IETF LC End Date:=C2=A0 2017-= 09-14
=C2=A0=C2=A0=C2=A0 IESG Telechat date:=C2=A0 2017-10-26

=C2= =A0=C2=A0=C2=A0 Summary:

=C2=A0=C2=A0=C2=A0 This draft is on the rig= ht track but has open issues, described in the
=C2=A0=C2=A0=C2=A0 review= .

=C2=A0=C2=A0=C2=A0 My general impression is that this is a sound p= iece of work, and
=C2=A0=C2=A0=C2=A0 apparently one that satisfies a ser= ious practical need.=C2=A0 But this
=C2=A0=C2=A0=C2=A0 draft has a large= number of open issues, and really needs a careful,
=C2=A0=C2=A0=C2=A0 t= horough clean-up pass.=C2=A0 And until that's done, it's not clear = what
=C2=A0=C2=A0=C2=A0 genuine problems might be lurking.

=C2=A0= =C2=A0=C2=A0 I haven't put in the time I would have liked to, so some o= f the issues
=C2=A0=C2=A0=C2=A0 I've detected might prove to be none= xistent.=C2=A0 A lot of these issues
=C2=A0=C2=A0=C2=A0 are simply Engli= sh usage.=C2=A0 The structure of the exposition needs to be
=C2=A0=C2=A0= =C2=A0 improved, including pulling the specialized vocabulary into a
=C2= =A0=C2=A0=C2=A0 glossary, providing overviews of processes whose multiple d= etails are
=C2=A0=C2=A0=C2=A0 discussed, etc.=C2=A0 Some issues are tech= nical slips, like missing
=C2=A0=C2=A0=C2=A0 required fields in HTTP mes= sages.=C2=A0 Some seem to be more substantial
=C2=A0=C2=A0=C2=A0 technic= al issues -- What is the versioning and extensibility system?
=C2=A0=C2= =A0=C2=A0 What are the requirements on POST operations that effectively car= ry no
=C2=A0=C2=A0=C2=A0 more information than that the operation happen= s?=C2=A0 And one question --
=C2=A0=C2=A0=C2=A0 the terms of service agr= eement -- seems to brush into legal
=C2=A0=C2=A0=C2=A0 territory.=C2=A0 = The number and variety of these minor problems suggests
=C2=A0=C2=A0=C2= =A0 that the whole work needs to be thought through more carefully before=C2=A0=C2=A0=C2=A0 being frozen.

=C2=A0=C2=A0=C2=A0 Within that co= ntext, I will not attempt to sort these items into
=C2=A0=C2=A0=C2=A0 ca= tegories or rate them on importance, but just list them in order by
=C2= =A0=C2=A0=C2=A0 parts of the text that they relate to.=C2=A0 And note that = a number of
=C2=A0=C2=A0=C2=A0 these items are mentioned relative to onl= y one of several places in
=C2=A0=C2=A0=C2=A0 the text they apply to.
=C2=A0=C2=A0=C2=A0 ----------------------------------------------= ------------------------

=C2=A0=C2=A0=C2=A0 There's a lot o= f talk about accounts, but no overview of the lifecycle
=C2=A0=C2=A0=C2= =A0 of an account.=C2=A0 Compare to the presentation of the overview of the=
=C2=A0=C2=A0=C2=A0 lifecycle of a certificate request.

=C2=A0=C2= =A0=C2=A0 There should be blanket policies on whether and where non-standar= d
=C2=A0=C2=A0=C2=A0 fields can be included by both client and server.
=C2=A0=C2=A0=C2=A0 Also, there ought to be versioning of Acme itself.=

=C2=A0=C2=A0=C2=A0 Abstract

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Certificates in PKI using X.509 (PKIX) are used for a number of
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 purposes, the most significant of whic= h is the authentication of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 domain n= ames.

=C2=A0=C2=A0=C2=A0 I'm no expert here, but it seems to me = that "the authentication of
=C2=A0=C2=A0=C2=A0 domain names" i= s not correct -- only actors can be authenticated.=C2=A0 I
=C2=A0=C2=A0= =C2=A0 think the accurate phrasing is "the authentication of servers (= TLS,
=C2=A0=C2=A0=C2=A0 HTTPS, etc.) which act on behalf of domain names= ".=C2=A0 (This would be a
=C2=A0=C2=A0=C2=A0 minor matter in the bo= dy, especially if this elision was universally
=C2=A0=C2=A0=C2=A0 used i= n the field, but an abstract should require little context.)

=C2=A0= =C2=A0=C2=A0 Ditto for the first paragraph of section 1.


<= /div>[RLB] This is standard usage, and it seems to me that all of the alter= natives are less clear.

=C2=A0


=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 DISCLAIMER: This is a work in progress draft of= ACME and has not yet
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 had a thoroug= h security analysis.

=C2=A0=C2=A0=C2=A0 I assume that this is going = to be removed once this document is
=C2=A0=C2=A0=C2=A0 published as an R= FC.=C2=A0 If the RFC hadn't had a thorough security
=C2=A0=C2=A0=C2= =A0 analysis, there would be no value in publishing it as an RFC.=C2=A0 How= ever
=C2=A0=C2=A0=C2=A0 there is no attached statement indicating when t= his statement is to be
=C2=A0=C2=A0=C2=A0 removed.=C2=A0 What is actuall= y going on here?


[RLB] This is a legacy of earlier versio= ns.=C2=A0 Proposed for removal in #357

https://github.com/ietf-wg-<= wbr>acme/acme/pull/357



=C2=A0=C2=A0=C2= =A0 Table of Contents

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 6.4= .=C2=A0 Replay protection
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 6.4= .2.=C2=A0 "nonce" (Nonce) JWS header parameter
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 6.5.=C2=A0 Rate limits

=C2=A0=C2=A0=C2= =A0 These section titles aren't capitalized the same way as the other=C2=A0=C2=A0=C2=A0 section titles.


[RLB] Fixed.=C2=A0 A= lso, "Threat model".

=C2=A0


= =C2=A0=C2=A0=C2=A0 1.=C2=A0 Introduction

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Existing Web PKI certificate authorities tend to run on a set of = ad
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 hoc protocols for certificate is= suance and identity verification.

=C2=A0=C2=A0=C2=A0 s/run on/use/?<= br>

[RLB] Done.

=C2=A0

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a typical user experience is something like:=

=C2=A0=C2=A0=C2=A0 I think you want to broaden this to "a typi= cal protocol is".=C2=A0 That
=C2=A0=C2=A0=C2=A0 doesn't change = things much, because the user is one endpoint of the
=C2=A0=C2=A0=C2=A0 = protocol.=C2=A0 But you don't want to de-emphasize what the CA does,=C2=A0=C2=A0=C2=A0 either.=C2=A0 (I reflexively think of this as a protoco= l problem, whereas
=C2=A0=C2=A0=C2=A0 the authors probably reflexively t= hink of this as a user experience
=C2=A0=C2=A0=C2=A0 problem.)

[RLB] The problem with the legacy "protocol" is that it = is not automated, which implies a bad UX, which implies that security doesn= 't scale.=C2=A0 I don't think a change is needed here.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 *=C2=A0 Put a CA-provided challenge at a DNS location correspondi= ng to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 the target domain.

=C2=A0=C2=A0=C2=A0 What does "corresp= onding to" mean?=C2=A0 I think you want "in a DNS record
=C2= =A0=C2=A0=C2=A0 for the target domain".


[RLB] Done.<= span class=3D"">

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 *=C2=A0 Receive CA challenge at a (hopefully) administra= tor-controlled
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 email address corresponding to the domain and then respond = to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 it on the CA's web page.

=C2=A0=C2=A0=C2=A0 s/CA challenge/C= A-provided challenge/ for parallelism.


[RLB] Done.
=C2=A0

=C2=A0=C2=A0=C2=A0 s/corresponding to the domai= n/within the domain/?


[RLB] No, "corresponding to&qu= ot;, e.g., via WHOIS.

=C2=A0

=C2=A0=C2=A0=C2= =A0 It seems that there should be an item between the third and fourth
= =C2=A0=C2=A0=C2=A0 items:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= o=C2=A0 The CA makes the newly issued certificate accessible to the
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 user (via the CA's web site?=C2= =A0 via e-mail?)


[RLB] Disagree, not substantive to the U= X story.

=C2=A0


=C2=A0=C2=A0=C2=A0 --
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This document describes an extens= ible framework for automating the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 i= ssuance and domain validation procedure, thereby allowing servers
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and infrastructural software to obtain certi= ficates without user
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 interaction.= =C2=A0 Use of this protocol should radically simplify the
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 deployment of HTTPS and the practicality of PKIX a= uthentication for
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 other protocols b= ased on Transport Layer Security (TLS) [RFC5246].

=C2=A0=C2=A0=C2=A0= I think you need some background on why this matters.=C2=A0 In the naive=C2=A0=C2=A0=C2=A0 default model, someone wants to set up a web server an= d needs to
=C2=A0=C2=A0=C2=A0 obtain a certificate.=C2=A0 Yes, this will= require 1 to 3 hours, but it's a
=C2=A0=C2=A0=C2=A0 one-time cost o= ver the life of the web site.=C2=A0 And I doubt that getting
=C2=A0=C2= =A0=C2=A0 one's self plugged into the Acme system of a CA will take *le= ss* time.


[RLB] The "set up a web server" model= accounts for a vanishingly small portion of the web these days; most thing= s run on hosting providers.=C2=A0 And several hosting providers are already= using earlier versions of ACME to enable "one-click" or "ze= ro-click" HTTPS for hosted sites.

Even for the self-hosting cro= wd, there are multiple web servers now that provide instant HTTPS using ACM= E.

https://www.youtube.com/watch?v=3Dnk4EWHvvZtI
https://letsencrypt.org/2017/10/17/acme-support-in-= apache-httpd.html

=C2=A0

=C2=A0=C2= =A0=C2=A0 Your model seems to be an operator that wants to set up many serv= ers
=C2=A0=C2=A0=C2=A0 that are authenticatable to many different identi= ties, with each
=C2=A0=C2=A0=C2=A0 identity being initially vouched for = by the same operator.=C2=A0 But this
=C2=A0=C2=A0=C2=A0 suggests that th= e multiple identities are third parties that are in
=C2=A0=C2=A0=C2=A0 s= ome way subordinate or derived identities to the operator's identity,=C2=A0=C2=A0=C2=A0 either "departments" within one entity, or c= ustomers of a vendor.

=C2=A0=C2=A0=C2=A0 In particular, how does Acm= e work relative to the case where a service
=C2=A0=C2=A0=C2=A0 provider = claims it is setting up a web site for a third party?

[RLB] T= his distinction is never made in practice.=C2=A0 For example, the CDN for <= a href=3D"http://example.com" target=3D"_blank">example.com is indistin= guishable from example.com= from the vantage point of a client or CA.=C2=A0 Where some separation = is desired, see https://tools.ietf.org/html/draft-ietf-acme-star


=C2=A0=C2=A0=C2=A0 [ruminations deleted] I t= hink you need to underline that this only
=C2=A0=C2=A0=C2=A0 handles the= DV case, and not the OV and EV cases.
=C2=A0=C2=A0 =C2=A0
[RL= B] This is not true.=C2=A0 The "external account binding" feature= lets you associate OV/EV authorizations with an ACME account, allowing the= issuance of EV certificates via ACME.=C2=A0 And if you look back through t= he list archives, there are multiple CAs that have said they intend to depl= oy it in this way.

=C2=A0=C2=A0 =C2=A0
=C2=A0=C2= =A0=C2=A0 On the first
=C2=A0=C2=A0=C2=A0 reading, I overlooked the bit = about "automating the issuance and
=C2=A0=C2=A0=C2=A0 domain valida= tion procedure", and immediately started wondering how
=C2=A0=C2=A0= =C2=A0 Acme prevents a service provider from generating bogus web servers f= or
=C2=A0=C2=A0=C2=A0 third parties, and thinking it doesn't.=C2=A0 = But I reflexively think of
=C2=A0=C2=A0=C2=A0 certificates in terms of O= V rather than DV.=C2=A0 I suspect many readers
=C2=A0=C2=A0=C2=A0 also m= ake this assumption.

=C2=A0=C2=A0=C2=A0 2.=C2=A0 Deployment Model an= d Operator Experience

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The guidi= ng use case for ACME is obtaining certificates for websites
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 (HTTPS [RFC2818]).

=C2=A0=C2=A0=C2=A0 You p= robably want to emphasize "obtaining domain validation-type
=C2=A0= =C2=A0=C2=A0 certificates ".

[RLB] No.=C2=A0 See above.<= span class=3D"">


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Prior to A= CME, when deploying an HTTPS server, an operator typically

=C2=A0=C2= =A0=C2=A0 This is the first use of "operator", so you probably wa= nt to say "the
=C2=A0=C2=A0=C2=A0 server operator".

[RLB] Done.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 o=C2=A0 The ACME client prompts the operator for the intended domain=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 name(s) that the= web server is to stand for.

=C2=A0=C2=A0=C2=A0 Probably want to say= "The operator's ACME client" to make it clear
=C2=A0=C2= =A0=C2=A0 that the client is working for/controlled by/attached to/located = at
=C2=A0=C2=A0=C2=A0 the operator.

[RLB] Done.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 o=C2=A0 In the backg= round, the ACME client contacts the CA and requests
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that it issue a certificate for the in= tended domain name(s).

=C2=A0=C2=A0=C2=A0 It seems that all of the r= emaining steps are "in the background", as
=C2=A0=C2=A0=C2=A0 = they can run to completion without operator intervention.=C2=A0 So I think<= br>=C2=A0=C2=A0=C2=A0 you want to emphasize "In the background" a= s an assertion about the
=C2=A0=C2=A0=C2=A0 remaining steps as a group.<= br>
[RLB] Disagree.


=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 o=C2=A0 The CA verifies that the client controls the = requested domain
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = name(s).

=C2=A0=C2=A0=C2=A0 "here a miracle happens" -- I = think you want to flesh this out or
=C2=A0=C2=A0=C2=A0 provide a referen= ce to the previous discussion, and especially
=C2=A0=C2=A0=C2=A0 emphasi= ze that the Internet operations are carried out by the Acme
=C2=A0=C2=A0= =C2=A0 client.=C2=A0 E.g., "The ACME client proves to the CA that the = operator
=C2=A0=C2=A0=C2=A0 controls the domain by one of the above-desc= ribed methods."=C2=A0 But maybe
=C2=A0=C2=A0=C2=A0 I'm being to= o fussy about the words "controls the requested domain
=C2=A0=C2=A0= =C2=A0 name(s)".


[RLB] Done.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 o=C2=A0 Once the CA is satisfied,= the certificate is issued

=C2=A0=C2=A0=C2=A0 There's no point u= sing the passive when the subject has already been
=C2=A0=C2=A0=C2=A0 us= ed in the sentence:=C2=A0 "Once the CA is satisfied, it issues the
= =C2=A0=C2=A0=C2=A0 certificate".

[RLB] Done.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In this way, it woul= d be nearly as easy to deploy with a CA-issued
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 certificate as with a self-signed certificate.

=C2=A0= =C2=A0=C2=A0 As someone who detests setting up yet another account for yet = another
=C2=A0=C2=A0=C2=A0 web site, I would like you to modify this to,= "once the operator has
=C2=A0=C2=A0=C2=A0 an ACME relationship wit= h one or more CAs, it would be nearly ...".

=C2=A0=C2=A0=C2=A0 = [Check how much work the operator needs to get his ACME client
=C2=A0=C2= =A0=C2=A0 connected to a CA.=C2=A0 If this is easy, emphasize it in the int= ro, as
=C2=A0=C2=A0=C2=A0 it's a major virtue of ACME!]

[RLB] Disagree.=C2=A0 (Well, I agree that it's a major virtue of ACME= .=C2=A0 I disagree that a text change is needed.)

<= br>=C2=A0=C2=A0=C2=A0 3.=C2=A0 Terminology

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 The two main roles in ACME are "client" and "se= rver".=C2=A0 The ACME
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 client u= ses the protocol to ...

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 An ACME= client is represented by an "account key pair".=C2=A0 The client=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 uses the private key ...

= =C2=A0=C2=A0=C2=A0 These two paragraphs contain two sentences of terminolog= y definition
=C2=A0=C2=A0=C2=A0 and two paragraphs of setting up the str= ucture of the ACME
=C2=A0=C2=A0=C2=A0 client/server system.=C2=A0 That&#= 39;s not a bad thing, but it's more than
=C2=A0=C2=A0=C2=A0 simply &= quot;Terminology".

=C2=A0=C2=A0=C2=A0 Conversely, there's a= lot of terminology in this draft that isn't
=C2=A0=C2=A0=C2=A0 defi= ned here.=C2=A0 Probably foremost is "operator", but there should= also
=C2=A0=C2=A0=C2=A0 be some explanation of the use of "respons= e" when that is used to
=C2=A0=C2=A0=C2=A0 describe an HTTP *reques= t*.

=C2=A0=C2=A0=C2=A0 One approach would be to move most of these t= wo paragraphs into the
=C2=A0=C2=A0=C2=A0 beginning of section 4, and th= en expanding section 3 to include
=C2=A0=C2=A0=C2=A0 various terms that = might not be familiar to people not fully involved
=C2=A0=C2=A0=C2=A0 in= certificate-issuance procedures.

[RLB] Disagree.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The server uses the = public key to verify the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 authentici= ty and integrity of messages from the client.

=C2=A0=C2=A0=C2=A0 Wha= t information is given to the server by authenticating the request
=C2= =A0=C2=A0=C2=A0 using the public key?=C2=A0 One possibility is that the ser= ver only needs
=C2=A0=C2=A0=C2=A0 to know that two requests came from &q= uot;the same" Acme client, in which
=C2=A0=C2=A0=C2=A0 case all it = needs to check is that both were signed by the same key.
=C2=A0=C2=A0=C2= =A0 But if the key conveys identity information to the server, how is that<= br>=C2=A0=C2=A0=C2=A0 managed?=C2=A0 That should be described (or reference= d) at the very
=C2=A0=C2=A0=C2=A0 beginning of the protocol description,= as that is the first action of
=C2=A0=C2=A0=C2=A0 the Acme protocol, se= tting up the client and connecting it to the CA.

[RLB] This i= s all specified in the account management sections below.<= br>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In many ways, ACME function= s much like a traditional CA,

=C2=A0=C2=A0=C2=A0 I think you mean, &= quot;In many ways, an ACME server functions ...".

[RLB] = Done.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ACME= allows a client to request certificate management actions using
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a set of JavaScript Object Notation (JSON) m= essages carried over
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 HTTPS.=C2=A0 I= n many ways, ACME functions much like a traditional CA, in
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 which a user creates an account, requests a certif= icate, and proves
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 control of the do= mains in that certificate in order for the CA to
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 sign the requested certificate.

=C2=A0=C2=A0=C2=A0 T= he first sentence of this paragraph should go after the part about
=C2= =A0=C2=A0=C2=A0 setting up the client/server relationship.=C2=A0 The second= sentence is
=C2=A0=C2=A0=C2=A0 actually overview for all of section 4 a= nd should stay at the
=C2=A0=C2=A0=C2=A0 beginning of the section.
[RLB] Disagree.


=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 The server then validates the challenges to check that the = client
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 has accomplished them.
=C2=A0=C2=A0=C2=A0 You may want to say "validates the responses to t= he challenges".=C2=A0 (I'm
=C2=A0=C2=A0=C2=A0 from an environme= nt where the phrase "challenge/response" is used a
=C2=A0=C2= =A0=C2=A0 lot.)

[RLB] Done.


=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the server will issue the requested certi= ficate and make it
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 available to the= client.

=C2=A0=C2=A0=C2=A0 If the Acme protocol can actually carry = the certificate to the client,
=C2=A0=C2=A0=C2=A0 you probably want to m= ake that clear in this sentence.=C2=A0 "and send it
=C2=A0=C2=A0=C2= =A0 to the client"?

[RLB] Disagree.
=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Order
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Signature=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --= ----->
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Required
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 <-------=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Authorizations

=C2=A0=C2=A0=C2=A0 I assume tha= t messages from the server are also signed.=C2=A0 (How is the
=C2=A0=C2= =A0=C2=A0 client to authenticate that it is talking to the server it thinks= it's
=C2=A0=C2=A0=C2=A0 talking to?)=C2=A0 I'd say, "the s= erver's signatures also ought to be
=C2=A0=C2=A0=C2=A0 shown", = but at this level of detail, I probably prefer that the
=C2=A0=C2=A0=C2= =A0 signatures not be shown, as they seem to cause me visual clutter.
[RLB] As is detailed below, the server's responses are authent= icated using HTTPS server authentication.


=C2= =A0=C2=A0=C2=A0 This chart seems to leave out a lot of steps.=C2=A0 Perhaps= :

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Order=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 ------->

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <-------=C2= =A0 Required Authorizations

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [Perform response actions.]

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Response= Notification=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ------->
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= [Verify response actions.]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <-= ------=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Certificate

[RLB] Disagree.


= =C2=A0=C2=A0=C2=A0 6.2.=C2=A0 Request Authentication

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0 "jwk" (JSON Web K= ey, only for requests to new-account and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 revoke-cert resources)

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For new-account requests, and for revo= ke-cert requests authenticated
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 by c= ertificate key, there MUST be a "jwk" field.

=C2=A0=C2=A0= =C2=A0 These two requirements don't appear to be the same.

[RLB] These are not inconsistent.=C2=A0 The first says that the MUST only= applies for those two request types, and the second reiterates that the MU= ST applies for those two request types.


=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the client sends a JWS signed with an alg= orithm that the server
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 does not sup= port, then the server MUST return an error with status
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 code 400 (Bad Request) and type
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 "urn:ietf:params:acme:error:badSignatureAlgori= thm".

=C2=A0=C2=A0=C2=A0 This is hard to understand until the t= ype field is introduced below.
=C2=A0=C2=A0=C2=A0 (The type field doesn&= #39;t seem to be a standard feature of JWS.)=C2=A0 Easier
=C2=A0=C2=A0= =C2=A0 wold be

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the client se= nds a JWS signed with an algorithm that the server
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 does not support, then the server MUST return an error docu= ment with status
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 code 400 (Bad Requ= est) and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "urn:ietf:params:acme= :error:badSignatureAlgorithm" in the "type" field.
<= br>[RLB] Disagree.


=C2=A0=C2=A0=C2=A0 6.= 3.=C2=A0 Request URL Integrity

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = As noted in Section 6.2 above, all ACME request objects carry a "url&q= uot;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 header parameter in their prot= ected header.

=C2=A0=C2=A0=C2=A0 Actually, section 6.2 calls it a &q= uot;field".=C2=A0 You should use consistent
=C2=A0=C2=A0=C2=A0 term= inology, particularly given that in the context of HTTP, the term
=C2=A0= =C2=A0=C2=A0 "header" has a special meaning.=C2=A0 (What is the g= eneral usage in JWS
=C2=A0=C2=A0=C2=A0 discussions?)

[RLB]= JWS also has a header, in fact two headers, a "protected" and &q= uot;unprotected" headers.=C2=A0 The contents of these headers are call= ed "header parameters".=C2=A0 This section is consistent with thi= s usage.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 E= xcept for the directory resource, all ACME resources are addressed
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 with URLs provided to the client by the s= erver.=C2=A0 For these resources,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 t= he client MUST set the "url" header parameter to the exact string=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 provided by the server (rather tha= n performing any re-encoding on the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= URL).=C2=A0 The server SHOULD perform the corresponding string equality=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 check, configuring each resource with= the URL string provided to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 clients= and having the resource check that requests have the same
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 string in their "url" header parameter.<= br>
=C2=A0=C2=A0=C2=A0 This is awkwardly phrased.=C2=A0 Perhaps:

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Except for the directory resource, all= ACME resources are addressed
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 with = URLs provided to the client by the server.=C2=A0 When addressing
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 these resources, the client MUST set the &qu= ot;url" header parameter to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 th= e exact string provided by the server (rather than performing any
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 re-encoding on the URL).=C2=A0 Conversely, t= he server MUST provide
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 clients with= the URLs by which the resources can be addressed
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 through the server, and it SHOULD verify that the "url= " header
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 parameter the client = provides when accessing a resource is the same
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 string as the server provides clients for that resource.
[RLB] Done (slightly differently).


=C2= =A0=C2=A0=C2=A0 6.3.1.=C2=A0 "url" (URL) JWS header parameter
=
=C2=A0=C2=A0=C2=A0 Perhaps the last two paragraphs of section 6.3 shoul= d be moved into
=C2=A0=C2=A0=C2=A0 this section.

=C2=A0=C2=A0=C2= =A0 This text is not as exact as I'd like.=C2=A0 What does "to whi= ch this JWS
=C2=A0=C2=A0=C2=A0 object is directed" mean?=C2=A0 Do y= ou mean "The request that contains this
=C2=A0=C2=A0=C2=A0 object i= s not valid unless the HTTP request URL is exactly the same
=C2=A0=C2=A0= =C2=A0 string as the value of this header parameter."=C2=A0 And the ph= rase "be a
=C2=A0=C2=A0=C2=A0 string representing the URL" is = extremely dangerous.=C2=A0 Remember that a
=C2=A0=C2=A0=C2=A0 URL *is* a= string, and if you mess with character encodings or the
=C2=A0=C2=A0=C2= =A0 like, you get a *different* URL, albeit one that some process might
= =C2=A0=C2=A0=C2=A0 consider "equivalent" to the original URL for = some purposes.

=C2=A0=C2=A0=C2=A0 I'm not up to date on HTTP, bu= t there are some complications regarding
=C2=A0=C2=A0=C2=A0 what the &qu= ot;request URI" of a request is; it's not always just the value=C2=A0=C2=A0=C2=A0 of the "request-URI" field of the request-lin= e.=C2=A0 There's probably a
=C2=A0=C2=A0=C2=A0 set terminology for t= his concept; it would be wise to align with it.

[RLB] There a= re a fair number of ambiguities around URLs.=C2=A0 This WG has tried to ste= er clear of them in the context of ACME using the string comparison text ab= ove.=C2=A0 For this header parameter, the specific semantic of the string w= ill be application-dependent, as with many other JWS fields.


=C2=A0=C2=A0=C2=A0 6.4.=C2=A0 Replay protection

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In order to protect ACME resources from any = possible replay attacks,

=C2=A0=C2=A0=C2=A0 Could this be shortened = to "In order to protect ACME resources from
=C2=A0=C2=A0=C2=A0 repl= ay attacks, ..."?

[RLB] Disagree.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Every JWS sent by an ACME client= MUST include, in its protected
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 hea= der,

=C2=A0=C2=A0=C2=A0 It's vague here what "JWS" mea= ns as an unqualified noun.=C2=A0 I suspect,
=C2=A0=C2=A0=C2=A0 "JWS= object", but some other uses suggest that there is a larger JWS
= =C2=A0=C2=A0=C2=A0 construct within which the "object" is the &qu= ot;payload".=C2=A0 In any case,
=C2=A0=C2=A0=C2=A0 the terminology = should be brought into alignment with the JWS
=C2=A0=C2=A0=C2=A0 standar= d(s).

[RLB] As noted above, this is standard JWS usage.


=C2=A0=C2=A0=C2=A0 It's not clear why the nonces= are provided in the Replay-Nonce header
=C2=A0=C2=A0=C2=A0 rather than = being provided in the JWS response.=C2=A0 Compare when the
=C2=A0=C2=A0= =C2=A0 client sends the nonce, when it is provide inside the JWS object.=C2=A0=C2=A0=C2=A0 Indeed, this seems to be a layering violation -- the no= nce is sent by
=C2=A0=C2=A0=C2=A0 the server in a header, but sent by th= e client in the JWS.=C2=A0 It would
=C2=A0=C2=A0=C2=A0 be cleaner to sen= d the nonce in both directions in a header, or send
=C2=A0=C2=A0=C2=A0 i= t in both directions in the JWS.=C2=A0 Perhaps the standard JWS
=C2=A0= =C2=A0=C2=A0 practice is to do it this way -- but the existence of section = 6.4.1
=C2=A0=C2=A0=C2=A0 suggests otherwise.

[RLB] Respons= e bodies are not JWS objects.=C2=A0 It's true that there is some asymme= try here, but it has not been a problem in for deployments in practice.


=C2=A0=C2=A0=C2=A0 It might be worth noting that i= t is acceptable for the server to
=C2=A0=C2=A0=C2=A0 "expire" = unused nonces by not accepting nonces that were provided in
=C2=A0=C2=A0= =C2=A0 responses too far in the past.=C2=A0 (Assuming you want to allow it.= )
=C2=A0=C2=A0=C2=A0 Since a client is required to retry requests that a= re rejected due to
=C2=A0=C2=A0=C2=A0 nonce failure, and that retry is e= xpected to be done promptly, this
=C2=A0=C2=A0=C2=A0 behavior does not c= ause protocol failure.=C2=A0 As written, this section
=C2=A0=C2=A0=C2=A0= suggests that a server MUST NOT reject a request as long as the nonce
= =C2=A0=C2=A0=C2=A0 is valid, regardless of how long ago the nonce was issue= d.

[RLB] There is no requirement at all that a server accept = any given nonce, only that it must NOT accept some nonces.=


=C2=A0=C2=A0=C2=A0 6.4.1.=C2=A0 Replay-Nonce

=C2=A0=C2= =A0=C2=A0 This section reads very awkwardly.=C2=A0 I think the intention is= to
=C2=A0=C2=A0=C2=A0 provide a specification of the Reply-Nonce header= field that stands
=C2=A0=C2=A0=C2=A0 alone.=C2=A0 But it is a specifica= tion only in regard to the syntax of the
=C2=A0=C2=A0=C2=A0 field, not t= he semantics.=C2=A0 OTOH, the first sentence of the section
=C2=A0=C2=A0= =C2=A0 seems to be trying to describe the semantics of the field, which is<= br>=C2=A0=C2=A0=C2=A0 confusing since it is nowhere near complete.=C2=A0 If= you want to say
=C2=A0=C2=A0=C2=A0 "generally, this field is to pr= ovide nonces that clients can use to
=C2=A0=C2=A0=C2=A0 uniquely identif= y requests" you want to be careful to qualify it with
=C2=A0=C2=A0= =C2=A0 some statement that the exact usage is described in other
=C2=A0= =C2=A0=C2=A0 specifications.=C2=A0 Wording this correctly could get awkward= .

[RLB] The semantics are described in the previous section.<= span class=3D"">


=C2=A0=C2=A0=C2=A0 The phrase "unique to e= ach message" isn't clear with regard to scope.
=C2=A0=C2=A0=C2= =A0 Is it like SIP Call-Ids, which are unique over all space and time?=C2= =A0 Or
=C2=A0=C2=A0=C2=A0 just unique over the history of the server?
=C2=A0=C2=A0=C2=A0 The language is not as clear as I'd like about = where it appears.
=C2=A0=C2=A0=C2=A0 Better to say "The server prov= ides this header field in responses to
=C2=A0=C2=A0=C2=A0 carry a server= -generated nonce to the client..." and "The Replay-Nonce
=C2= =A0=C2=A0=C2=A0 header field MUST only be carried in HTTP response messages= ."

[RLB] Disagree.


=C2=A0=C2= =A0=C2=A0 6.4.2.=C2=A0 "nonce" (Nonce) JWS header parameter
=C2=A0=C2=A0=C2=A0 Again, this section hints at but does not specify the = semantics of the
=C2=A0=C2=A0=C2=A0 datum.

[RLB] As above,= the semantics are application-specific.



= =C2=A0=C2=A0=C2=A0 6.5.=C2=A0 Rate limits

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Creation of resources can be rate limited to ensure fair usage= and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 prevent abuse.=C2=A0 Once the = rate limit is exceeded, the server MUST
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 respond with an error with the type
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 "urn:ietf:params:acme:error:rateLimited".=C2=A0 Ad= ditionally, the server
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SHOULD send = a "Retry-After" header indicating when the current
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 request may succeed again.=C2=A0 If multiple ra= te limits are in place,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that is the= time where all rate limits allow access again for the
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 current request with exactly the same parameters.
=
=C2=A0=C2=A0=C2=A0 This is written as of rate limiting is some sort of = global correctness
=C2=A0=C2=A0=C2=A0 property -- which can't be red= uced to any property observable by
=C2=A0=C2=A0=C2=A0 either client or s= erver.=C2=A0 The first sentence doesn't even state that
=C2=A0=C2=A0= =C2=A0 it's the *server* that can limit rates!=C2=A0 Better is to clari= fy the
=C2=A0=C2=A0=C2=A0 intentions and roles of the various actors:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A server MAY limit the rate at wh= ich it accepts various requests
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fro= m various clients, e.g., to ensure fair usage and prevent abuse.
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If a server desires to postpone submission o= f a particular request,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 it MUST res= pond with an error with the type
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 &q= uot;urn:ietf:params:acme:error:rateLimited".=C2=A0 Additionally, = the server
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SHOULD [I can't see = a reason why this isn't MUST] include a
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 "Retry-After" header indicating the time interval after= which all
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 limitations the server i= s currently applying to this request will
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 permit processing of this request.=C2=A0 Different requests (even if= from
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the same client) may be subje= ct to different rate limits; the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Re= try-After value gives no information about other requests.

[RLB] Added "by servers"


=C2=A0=C2= =A0=C2=A0 --

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In addition to the= human readable "detail" field of the error
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 response, the server MAY send one or multiple tokens in = the "Link"
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 header pointin= g to documentation about the specific hit rate limits
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 using the "urn:ietf:params:acme:documentation&= quot; relation.

=C2=A0=C2=A0=C2=A0 What does "token" mean = here?=C2=A0 From context, I think you mean
=C2=A0=C2=A0=C2=A0 "link= -value" (after RFC 5988), or better, "URI".

[R= LB] Changed "tokens" to "link relations" (after RFC 828= 8)


=C2=A0=C2=A0=C2=A0 Also, the value "urn= :ietf:params:acme:documentation" doesn't seem to
=C2=A0=C2= =A0=C2=A0 be placed in the IANA registry described in section 9.6.

<= /span>[RLB] Changed to use the standard "help" link relation type= .


=C2=A0=C2=A0=C2=A0 6.6.=C2=A0 Errors

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this document defines the
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 following standard tokens for use in the "= type" field (within the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "= urn:ietf:params:acme:error:" namespace):

=C2=A0=C2=A0=C2=A0 Thi= s isn't correct terminology.=C2=A0 The namespace of these URNs is
= =C2=A0=C2=A0=C2=A0 "ietf".=C2=A0 Part of the problem is that ther= e isn't a standardized term
=C2=A0=C2=A0=C2=A0 for the parts of a UR= N that are separated by colons, despite that
=C2=A0=C2=A0=C2=A0 almost a= ll URN namespaces use colons as major separators.=C2=A0 I think
=C2=A0= =C2=A0=C2=A0 this version is both correct and readable:

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 ... this document defines the following standard U= RIs for use in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the "type"= field (where each listed token is appended to
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 "urn:ietf:params:acme:error:" to make the URI):
<= br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-----------------------+-----= --------------------------------------+
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | Token=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Description=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +----------------= -------+-------------------------------------------+
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 | badCSR=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | The CSR is unacceptab= le (e.g., due to a=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | short key)=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

[RLB] Disagree. The = nuances of URN terminology are not relevant to interop here.


=C2=A0=C2=A0=C2=A0 --

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 This list is not exhaustive.=C2=A0 The server MAY return errors whos= e
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "type" field is set to = a URI other than those defined above.=C2=A0 Servers
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 MUST NOT use the ACME URN [RFC3553] namespace for errors= other than
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the standard types.
=
=C2=A0=C2=A0=C2=A0 "namespace" isn't really correct here,= but I think "sub-namespace" is.

[RLB] Disagree, as= above.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Cl= ients SHOULD display the "detail" field of all errors.

=C2= =A0=C2=A0=C2=A0 s/display/display to the user/

[RLB] Disagree= .


=C2=A0=C2=A0=C2=A0 7.1.=C2=A0 Resources
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Each
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 function is listed in a directory along with its corresponding UR= L,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 so clients only need to be confi= gured with the directory URL.

=C2=A0=C2=A0=C2=A0 s/a directory/the d= irectory resource/

[RLB] Disagree.

=C2=A0=C2=A0=C2=A0 The "up" link relation from "cert"= to the CA chain is not shown in the
=C2=A0=C2=A0=C2=A0 figure.=C2=A0 Th= e "index" link relation isn't shown at all, though that
= =C2=A0=C2=A0=C2=A0 couldn't be shown easily.=C2=A0 You might want to no= te that in some way in
=C2=A0=C2=A0=C2=A0 the paragraph before the figur= e.

[RLB] Disagree.


=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Submit an order=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 | POST new-order=C2=A0=C2=A0 | 201 -> order=C2=A0= =C2=A0 |

=C2=A0=C2=A0=C2=A0 When I first read this, I was unclear wh= at an "order" is.=C2=A0 It turns
=C2=A0=C2=A0=C2=A0 out that i= t is a request for a certificate.=C2=A0 E.g.,

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 o=C2=A0 Order resources, representing an account's requ= ests to issue
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cer= tificates (Section 7.1.3)

=C2=A0=C2=A0=C2=A0 You might want to eithe= r move toward the nomenclature "request a
=C2=A0=C2=A0=C2=A0 certif= icate" or more heavily emphasize "order" in the text.=C2=A0 = If you
=C2=A0=C2=A0=C2=A0 enlarge section 2 to cover all the specialized= terminology, putting an
=C2=A0=C2=A0=C2=A0 entry in it for "order&= quot; would be helpful.

[RLB] Disagree.
<= br>
=C2=A0=C2=A0=C2=A0 There are quite a number of example request respo= nses that do not
=C2=A0=C2=A0=C2=A0 contain the "index" link h= eader.

[RLB] This seems unlikely to lead to interop failure.<= span class=3D"">


=C2=A0=C2=A0=C2=A0 The figure does not show the= key-change resource.

[RLB] Done.

=C2=A0=C2=A0=C2=A0 7.1.1.=C2=A0 Directory

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 whose fields names are drawn from the following table

= =C2=A0=C2=A0=C2=A0 s/fields names/field names/

[RLB] Done.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 +-------------+--------------------+
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Field=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | URL in value=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-------------+-----------= ---------+
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 | new-nonce=C2=A0=C2=A0 | New nonce=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | new-account | New account=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | new-order=C2=A0=C2=A0= | New order=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | new-authz=C2=A0=C2=A0 | New authorization=C2=A0 |
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 | revoke-cert | Revoke certificate |
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | key-change=C2= =A0 | Key change=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-------------+-----= ---------------+

=C2=A0=C2=A0=C2=A0 In this table, one of the &= quot;URL in value" items is a predicate
=C2=A0=C2=A0=C2=A0 (verb-ob= ject), which makes sense; one is a noun phrase naming an
=C2=A0=C2=A0=C2= =A0 action; and four are noun phrases (which are objects of an implied
= =C2=A0=C2=A0=C2=A0 "get" or "obtain").=C2=A0 I suggest = rephrasing the items into predicates
=C2=A0=C2=A0=C2=A0 directly telling= what the URL does, e.g., "request new nonce", "change
= =C2=A0=C2=A0=C2=A0 key".

[RLB] Disagree.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 There is no constraint on= the actual URL of the directory except that

=C2=A0=C2=A0=C2=A0 &quo= t;actual" is probably superfluous here.

[RLB] Done.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The following = metadata items are defined, all of which are OPTIONAL:

=C2=A0=C2=A0= =C2=A0 It would probably be wise to allow servers to include non-standard=C2=A0=C2=A0=C2=A0 metadata items.

[RLB] There is nothing f= orbidding it.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 HTTP/1.1 200 OK
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Content-Type: a= pplication/json

=C2=A0=C2=A0=C2=A0 This should be preceded by someth= ing like "An example response to a
=C2=A0=C2=A0=C2=A0 directory GET= is:".=C2=A0 I suggest providing some sort of direct
=C2=A0=C2=A0= =C2=A0 description of each example, and it would help to show requests and<= br>=C2=A0=C2=A0=C2=A0 responses together.=C2=A0 (But perhaps the RFC Editor= thinks that unlabeled
=C2=A0=C2=A0=C2=A0 examples are OK if the context= makes their purpose clear enough.)

[RLB] I think the purpose= is clear enough from context.


=C2=A0=C2=A0=C2= =A0 7.1.2.=C2=A0 Account Objects

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 contact (optional, array of string):=C2=A0 An array of URLs that the=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server can use to c= ontact the client for issues related to this
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 account.=C2=A0 For example, the server may wish= to notify the client
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 about server-initiated revocation or certificate expiration.

= =C2=A0=C2=A0=C2=A0 Strictly, you want "URIs" here, as tel:, sip:,= and mailto: URIs are
=C2=A0=C2=A0=C2=A0 not URLs [RFC 6068].

[RLB] There is long-standing consensus in the WG to use "URL"= instead of "URI" in this document, because it is more commonly u= sed, and because the exact line between URIs and URLs in not clear.=C2=A0 F= or example, the WHATWG URL spec does consider the examples you cite to be U= RLs.


=C2=A0=C2=A0=C2=A0 7.1.2.1.=C2=A0 Orders L= ist

=C2=A0=C2=A0=C2=A0 How long does an order URL remain valid?=C2= =A0 The particular URLs in the
=C2=A0=C2=A0=C2=A0 example suggests that = the order URLs are valid only as long as the set
=C2=A0=C2=A0=C2=A0 of o= rders doesn't change.

[RLB] The semantics here are the sa= me as for an Amazon or Google search results page.=C2=A0 If the underlying = data set changes, then the list provided when dereferencing the URL will al= so change.=C2=A0 No stability guarantees.


=C2= =A0=C2=A0=C2=A0 A larger question is whether order objects are ever purged = from the
=C2=A0=C2=A0=C2=A0 orders list?

[RLB] Up to the s= erver, subject to the guidance in this section.

=C2=A0=C2=A0=C2=A0 Indeed, these questions can be generalized -- Can the s= erver ever
=C2=A0=C2=A0=C2=A0 purge resources, invalidating the URLs tha= t pointed to them?=C2=A0 What
=C2=A0=C2=A0=C2=A0 sort of assurances can = the client rely on?

[RLB] What sort of assurances do you imag= ine the client needs?


=C2=A0=C2=A0=C2=A0 7.1.3.= =C2=A0 Order Objects

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 For final
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 orders, the authorizations that were completed.

=C2=A0=C2=A0=C2= =A0 What is a "final" order?=C2=A0 The term "final" is = used in a number of
=C2=A0=C2=A0=C2=A0 places, with possibly slightly di= fferent meanings, and needs to be
=C2=A0=C2=A0=C2=A0 properly defined.
[RLB] Clarified, "(in the "valid" or "inva= lid" state)"


=C2=A0=C2=A0=C2=A0 7.1.4= .=C2=A0 Authorization Objects

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 s= tatus (required, string):=C2=A0 The status of this authorization.
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Possible values are: "= ;pending", "processing", "valid", "invalid&qu= ot;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and "rev= oked".

=C2=A0=C2=A0=C2=A0 It might be worth spelling out here w= hat these states mean, as this is
=C2=A0=C2=A0=C2=A0 the definition of t= his field of the authorization object.

[RLB] These are descri= bed elsewhere with better context.


=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If this field is absent, then=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the CA MUST conside= r this authorization valid for all orders until
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the authorization expires.

=C2=A0=C2= =A0=C2=A0 There doesn't seem to be an "expired" status, so ho= w can an
=C2=A0=C2=A0=C2=A0 authorization expire?

[RLB] Th= is field has since been deleted.


=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 For final authorizations it cont= ains the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 challeng= es that were successfully completed.

=C2=A0=C2=A0=C2=A0 What is a &q= uot;final" authorization?

[RLB] Clarified, "(in the= "valid" or "invalid" state)"
=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 8 describes a set of c= hallenges for domain name validation.

=C2=A0=C2=A0=C2=A0 Section 8 i= s about challenges generally; really the challenges for
=C2=A0=C2=A0=C2= =A0 domain name validation are sections 8.4 to 8.6.=C2=A0 Perhaps they shou= ld
=C2=A0=C2=A0=C2=A0 be grouped into a subsection and this sentence sho= uld point to that?

[RLB] Disagree.=C2=A0 The "and some o= ther stuff" is implicit.


=C2=A0=C2=A0=C2= =A0 7.3.=C2=A0 Account Creation

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= If the server wishes to present the client with terms under which the
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ACME service is to be used, it MUST in= dicate the URL where such terms
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 can= be accessed in the "terms-of-service" subfield of the "meta= "
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 field in the directory objec= t, and the server MUST reject new-account
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 requests that do not have the "terms-of-service-agreed" se= t to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "true".=C2=A0 Client= s SHOULD NOT automatically agree to terms by default.
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Rather, they SHOULD require some user interaction for ag= reement to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 terms.

=C2=A0=C2= =A0=C2=A0 I note that there seems to be no recording of when the account wa= s
=C2=A0=C2=A0=C2=A0 created, i.e., *when* the terms of service was agre= ed to.=C2=A0 Since the
=C2=A0=C2=A0=C2=A0 content behind the terms of se= rvice URL can change unpredictably,
=C2=A0=C2=A0=C2=A0 noting that the t= erms of service were agreed to is meaningless unless
=C2=A0=C2=A0=C2=A0 = there is some fixation of the time of agreement.

[RLB] Server= s are welcome to log this information if they see fit.
=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 an error of type "invalid= Contact".

=C2=A0=C2=A0=C2=A0 The wording of the text is inconsi= stent (or just unclear) whether
=C2=A0=C2=A0=C2=A0 error types are give = as full URNs or just the last component.

[RLB] Errors are alw= ays provided as full URNs, as required by RFC 7807.=C2=A0 Add a clarificati= on to the "Errors" section.


=C2=A0=C2= =A0=C2=A0 7.3.4.=C2=A0 Changes of Terms of Service

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 The problem document returned with the error MUST als= o include an
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "instance" f= ield, indicating a URL that the client should direct a
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 human user to visit in order for instructions on how = to agree to the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 terms.

=C2= =A0=C2=A0=C2=A0 This seems inconsistent with section 7.3, as the client can= agree to
=C2=A0=C2=A0=C2=A0 the terms of service when creating an accou= nt within Acme, but changes
=C2=A0=C2=A0=C2=A0 in terms seem to require = going out-of-band to agree to the new terms
=C2=A0=C2=A0=C2=A0 of servic= e.

[RLB] The decision of the WG was that this was the correct= trade-off given that re-agreement is almost never needed.=


=C2=A0=C2=A0=C2=A0 Given that this could become a legal matter,= it seems like a lot of
=C2=A0=C2=A0=C2=A0 care and thought should be pu= t in on this.=C2=A0 Ideally, a good lawyer
=C2=A0=C2=A0=C2=A0 should be = consulted on this.

[RLB] It's not the IETF's job to m= ake legal decisions, just to make mechanisms that work for participants.=C2= =A0 Several CAs weighed in to say this mechanism was OK with them.


=C2=A0=C2=A0=C2=A0=C2=A0 HTTP/1.1 403 Forbidden
=C2= =A0=C2=A0=C2=A0=C2=A0 Replay-Nonce: IXVHDyxIRGcTE0VSblhPzw
=C2=A0=C2=A0= =C2=A0=C2=A0 Link: <https://example.com/acme/terms/2017-6-02>;re= l=3D"terms-of-service"
=C2=A0=C2=A0=C2=A0=C2=A0 Content-T= ype: application/problem+json
=C2=A0=C2=A0=C2=A0=C2=A0 Content-Language:= en

=C2=A0=C2=A0=C2=A0 The various examples don't seem to be ind= ented consistently.=C2=A0 Although
=C2=A0=C2=A0=C2=A0 I expect the RFC E= ditor will clean that up.

[RLB] As do I.
=

=C2=A0=C2=A0=C2=A0 7.3.5.=C2=A0 External Account Binding

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This can be used to an ACME account with = an
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 existing account in a non-ACME s= ystem, such as a CA customer
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 databa= se.

=C2=A0=C2=A0=C2=A0 There's a word missing after "This c= an be used to".

[RLB] This is fixed in https://github.c= om/ietf-wg-acme/acme/pull/357


=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The server MAY require a value to be present= for the "external-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 account-bi= nding" field.

=C2=A0=C2=A0=C2=A0 It would help the reader recov= er the context by starting this with,
=C2=A0=C2=A0=C2=A0 "In an acc= ount creation request,".

[RLB] Done.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 To enable ACME account bindin= g, a CA needs to provision the ACME
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= client with a MAC key and a key identifier.

=C2=A0=C2=A0=C2=A0 You = might want to annotate this, "by some means outside the scope of
= =C2=A0=C2=A0=C2=A0 this document", or "presumably as part of esta= blishing the external
=C2=A0=C2=A0=C2=A0 account".=C2=A0 And I woul= d use "provide" rather than "provision" --
=C2=A0=C2= =A0=C2=A0 "provision" suggests to me that there is a specific pro= visioning
=C2=A0=C2=A0=C2=A0 process that will be defined.

[RLB] Done.


=C2=A0=C2=A0=C2=A0 What is a "= ;MAC key"?=C2=A0 I think you mean that any account binding must
=C2= =A0=C2=A0=C2=A0 be represented by a key pair for the external account, and = the private
=C2=A0=C2=A0=C2=A0 key of that pair is the "MAC key&quo= t;.

=C2=A0=C2=A0=C2=A0 OTOH, this may be inconveniently heavy-weight= for real-world use -- I
=C2=A0=C2=A0=C2=A0 would expect the CA to simpl= y provide a secret associated with the
=C2=A0=C2=A0=C2=A0 external accou= nt.=C2=A0 (Or is that what a "MAC key" is?)

[RLB] A= MAC key is a key used to compute Message Authentication Codes, i.e., a sym= metric secret.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 The ACME client then computes a binding JWS to indicate the external=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 account's approval of the ACME= account key.

=C2=A0=C2=A0=C2=A0 This isn't quite correct.=C2=A0= Perhaps

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The ACME client then c= omputes a binding JWS to indicate that that
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 the client, the owner of the external account, approves of the AC= ME
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 account key.

=C2=A0=C2=A0= =C2=A0 Or is that "the client, on behalf of the owner of the external<= br>=C2=A0=C2=A0=C2=A0 account"?

[RLB] Changed to "e= xternal account holder's approval"

=C2=A0= =C2=A0=C2=A0 --

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MUST reflect va= lue of the "external-account-binding" field

=C2=A0=C2=A0= =C2=A0 s/reflect value/reflect the value/

[RLB] Done.


=C2=A0=C2=A0=C2=A0 7.3.6.=C2=A0 Account Key Roll-over<= br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The client then encapsulates th= e key-change object in a JWS, signed
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 with the requested new account key (i.e., the key matching the
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "newKey" value).

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The outer JWS MUST meet the normal requireme= nts for an ACME JWS (see
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 6.= 2).=C2=A0 The inner JWS MUST meet the normal requirements, with
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the following exceptions:

=C2=A0=C2= =A0=C2=A0 Some detail is being left out.=C2=A0 I think that the JWS describ= ed in the
=C2=A0=C2=A0=C2=A0 first of these paragraphs becomes the "= ;inner JWS" of the next
=C2=A0=C2=A0=C2=A0 paragraph.=C2=A0 But exa= ctly how that nesting is to be performed doesn't
=C2=A0=C2=A0=C2=A0 = seem to be described.

[RLB] Added some clarification.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3.=C2=A0 Check th= at the JWS protected header of the inner JWS has a "jwk"
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 field.

=C2= =A0=C2=A0=C2=A0 Is the generation of the "jwk" field specified in= the text anywhere?

[RLB] It's just a public key generate= d by the client.=C2=A0 Added a clarification that "jwk" is REQUIR= ED in the inner JWS.


=C2=A0=C2=A0=C2=A0 7.4.=C2= =A0 Applying for Certificate Issuance

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 then the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server MUST proacti= vely issue the requested certificate and provide a
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 URL for it in the "certificate" field of the orde= r.

=C2=A0=C2=A0=C2=A0 I'm not sure that "proactively" = has a specific meaning.=C2=A0 I think you
=C2=A0=C2=A0=C2=A0 can just s/= proactively issue/issue/ and capture the desired meaning --
=C2=A0=C2=A0= =C2=A0 the server doesn't have to issue a certificate instantly, but it=
=C2=A0=C2=A0=C2=A0 cannot delay.

[RLB] This has been repl= aced in https://github.com/ietf-wg-acme/acme/pull/342


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The status of the or= der will indicate what action the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 c= lient should take:

=C2=A0=C2=A0=C2=A0 This list is part of the defin= ition of the order object, and should be
=C2=A0=C2=A0=C2=A0 put in secti= on 7.1.3.

[RLB] Disagree.


=C2=A0= =C2=A0=C2=A0 7.4.1.=C2=A0 Pre-Authorization

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 In some cases, a CA running an ACME server might have a comple= tely
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 external, non-ACME process for= authorizing a client to issue for an
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 identifier.

=C2=A0=C2=A0=C2=A0 I'm not sure that "clien= t" is a proper subject for "issue".=C2=A0 Perhaps
=C2=A0= =C2=A0=C2=A0 you mean "for authorizing a client to be issued certifica= te(s) for an
=C2=A0=C2=A0=C2=A0 identifier".

[RLB] Ch= anged "issue" to "request issuance for"


=C2=A0=C2=A0=C2=A0 7.4.2.=C2=A0 Downloading the Certificate
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A certificate resource represents= a single, immutable certificate.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= f the client wishes to obtain a renewed certificate, the client
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 initiates a new order process to request one= .

=C2=A0=C2=A0=C2=A0 Though I think you want to add what you really = mean, namely that the
=C2=A0=C2=A0=C2=A0 new certificate will be fetched= from a different URL.

[RLB] Disagree.

=C2=A0=C2=A0=C2=A0 7.5.=C2=A0 Identifier Authorization

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The server may declare
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 that an authorization is only valid for a specific order= by setting
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the "scope" f= ield of the authorization to the URL for that order.

=C2=A0=C2=A0=C2= =A0 "scope" isn't shown in the figure in section 7.1.

= [RLB] "scope" has been deleted https://github.com/ietf-wg= -acme/acme/pull/349


=C2=A0=C2=A0=C2=A0= 7.5.1.=C2=A0 Responding to Challenges

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 The server is said to "finalize" the authorization when= it has

=C2=A0=C2=A0=C2=A0 Despite the existence of a section titled= "Terminology", very little
=C2=A0=C2=A0=C2=A0 of the terminol= ogy created for this document is listed there.

[RLB] Disagree= .


=C2=A0=C2=A0=C2=A0 8.=C2=A0 Identifier Valida= tion Challenges

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Each challenge = must describe:

=C2=A0=C2=A0=C2=A0 This isn't right; a challenge = doesn't describe anything.=C2=A0 But the
=C2=A0=C2=A0=C2=A0 descript= ions of the challenge types include various information, etc.

[RLB] Changed to "The definition of a new type of challenge"


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 status (requi= red, string):=C2=A0 The status of this authorization.
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Possible values are: "pending&quo= t;, "valid", and "invalid".

=C2=A0=C2=A0=C2=A0 I= think you mean "the status of this challenge".=C2=A0 But you mig= ht mean
=C2=A0=C2=A0=C2=A0 "the status of the authorization contain= ing this challenge".

[RLB] Typo.=C2=A0 Done.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 validated (optional,= string):=C2=A0 The time at which this challenge was
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 completed by the server

=C2=A0= =C2=A0=C2=A0 I'm not sure in what sense you mean "completed by&quo= t;, since it's the
=C2=A0=C2=A0=C2=A0 client that does the completin= g.=C2=A0 I think you mean "the time at which
=C2=A0=C2=A0=C2=A0 the= server recognized that the challenge was completed".

[R= LB] Changed to "The time at which the server considered this challenge= complete"


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 The server can limit the size
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of this object by limiting the numb= er of times it will retry a
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 challenge.

=C2=A0=C2=A0=C2=A0 Rather, "the number = of times it will permit the client to retry a
=C2=A0=C2=A0=C2=A0 challen= ge".=C2=A0 Actually, the semantics of this field probably depends on=C2=A0=C2=A0=C2=A0 the pattern of the actions by which the challenge is s= atisfied, and so
=C2=A0=C2=A0=C2=A0 may be dependent on the challenge ty= pe.

[RLB] Changed to "try to validate a challenge"<= span class=3D"">


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server sets a challenge's "st= atus" to "invalid", it SHOULD also
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 include the "error" field to help the client diag= nose why the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 challenge failed.
<= br>=C2=A0=C2=A0=C2=A0 Presumably, 'the "errors" field'.
[RLB] Done.


=C2=A0=C2=A0=C2=A0 Als= o, section 8.2, "The server MUST add an entry to the "errors"= ; field
=C2=A0=C2=A0=C2=A0 in the challenge after each failed validation= query.", suggests that
=C2=A0=C2=A0=C2=A0 the server MUST include = the "errors" field, not just SHOULD include.

[RLB] = Suggests, but does not imply.=C2=A0 A server could invalidate a challenge j= ust because it feels like it.



=C2=A0=C2= =A0=C2=A0 8.1.=C2=A0 Key Authorizations

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 A key authorization is a string that expresses
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 a domain holder's authorization for a specified k= ey to satisfy a
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 specified challenge= , by concatenating the token for the challenge
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 with a key fingerprint, separated by a "." character= :

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 key-authz =3D token || '.= ' || base64url(JWK_Thumbprint(accountKey))

=C2=A0=C2=A0=C2= =A0 In what way does a key authorization indicate something about a
=C2= =A0=C2=A0=C2=A0 "domain holder"?=C2=A0 The k.a. includes the toke= n (presumably from the
=C2=A0=C2=A0=C2=A0 challenge object) and a comput= ation based on an account's (private)
=C2=A0=C2=A0=C2=A0 key, so it = includes information from the account holder.

=C2=A0=C2=A0=C2=A0 Or = do you mean that "in the challenge, a token will be sent by the
=C2= =A0=C2=A0=C2=A0 server that only the domain holder will be able to receive,= and as
=C2=A0=C2=A0=C2=A0 part of the account holder's response to = the challenge, it composes a
=C2=A0=C2=A0=C2=A0 key authorization string= "?

=C2=A0=C2=A0=C2=A0 Really, I doubt that this is understandab= le without first explaining
=C2=A0=C2=A0=C2=A0 the general model of chal= lenge/response that the challenge types
=C2=A0=C2=A0=C2=A0 defined here = use, and that model doesn't seem to be described
=C2=A0=C2=A0=C2=A0 = anywhere.=C2=A0 I think it would be very helpful if that model was
=C2= =A0=C2=A0=C2=A0 presented first, before the specific challenge types that u= se that
=C2=A0=C2=A0=C2=A0 model.

=C2=A0=C2=A0=C2=A0 Alternativel= y, you could just describe this as an abstract operation
=C2=A0=C2=A0=C2= =A0 on strings,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 key-authz(token= , accountKey) =3D
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 token || '.' || base64url(JWK_Thumbprint(accountKey))
=C2=A0=C2=A0=C2=A0 and leave defining its semantics to where key-auth= z() is used.

[RLB] Disagree.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The "JWK_Thumbprint" step i= ndicates the computation specified in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 [RFC7638], using the SHA-256 digest [FIPS180-4].=C2=A0 As noted in JWA<= br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [RFC7518] any prepended zero octets= in the JWK object MUST be
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 stripped= before doing the computation.

=C2=A0=C2=A0=C2=A0 The second sentenc= e seems to be unclear.=C2=A0 Is the "JWK object" the
=C2=A0=C2= =A0=C2=A0 output of "JWK_Thumbprint(accountKey)"?=C2=A0 If so, wh= y isn't it called
=C2=A0=C2=A0=C2=A0 "the JWK_Thumbprint object= "?=C2=A0 And the significance of "prepended zero
=C2=A0=C2=A0= =C2=A0 octets" is unclear; RFC 7518 does not include the word "pr= epend", so
=C2=A0=C2=A0=C2=A0 presumably does not specify any prepe= nding.=C2=A0 I suspect you mean that
=C2=A0=C2=A0=C2=A0 some stage of th= e processing of RFC 7518 is modified by stripping
=C2=A0=C2=A0=C2=A0 ini= tial zero octets from some string, but such octets wouldn't be
=C2= =A0=C2=A0=C2=A0 described as "prepended".

[RLB] Thi= s is a minor issue with RSA keys, where sometimes integers have zeros prepe= nded to make clear that they're positive.=C2=A0 Changed to "any pr= epended zero octets in the fields of a JWK object".

=C2=A0=C2=A0=C2=A0 8.2.=C2=A0 Retrying Challenges

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Clients can explicitly request a retry by re= -sending their response
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to a challe= nge in a new POST request (with a new nonce, etc.).

=C2=A0=C2=A0=C2= =A0 Again, this makes sense only under the assumption that satisfying a
= =C2=A0=C2=A0=C2=A0 challenge has certain data-flow patterns, in that (appar= ently) the
=C2=A0=C2=A0=C2=A0 client must send a "response" an= d then -- well, it's not entirely
=C2=A0=C2=A0=C2=A0 clear what &quo= t;a retry" is.=C2=A0 You really need to lay out this pattern --
=C2= =A0=C2=A0=C2=A0 and the names you use for the actions within it -- before y= ou specify
=C2=A0=C2=A0=C2=A0 the details of how clients and servers can= perform it.

[RLB] Disagree.


=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In order to avoid
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 denial-of-service attacks via client-initiated retries, = servers
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SHOULD rate-limit such requ= ests.

=C2=A0=C2=A0=C2=A0 There are two uses of "request" i= n the preceding sentence -- which of
=C2=A0=C2=A0=C2=A0 them is being ra= te-limited?

[RLB] The noun "request" appears twice,= but referencing the same action.


=C2=A0=C2=A0= =C2=A0 8.3.=C2=A0 HTTP Challenge

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 With HTTP validation, the client in an ACME transaction proves its
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 control over a domain name by proving = that for that domain name it
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 can pr= ovision resources to be returned by an HTTP server.

=C2=A0=C2=A0=C2= =A0 Better, "by proving that it can provision resources that are retur= ned by
=C2=A0=C2=A0=C2=A0 an HTTP server accessible using a URL whose ho= st is that domain name".

[RLB] Done.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type (required, string):=C2= =A0 The string "http-01"

=C2=A0=C2=A0=C2=A0 You don't = actually say that these two fields are part of HTTP
=C2=A0=C2=A0=C2=A0 c= hallenge objects.

[RLB] Disagree.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 It MUST NOT contain= any characters outside the base64url alphabet,
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 including padding characters ("=3D"= ;).

=C2=A0=C2=A0=C2=A0 This could be read two ways; are the padding = characters part of "the
=C2=A0=C2=A0=C2=A0 base64url alphabet"= , or are they part of "characters outside the
=C2=A0=C2=A0=C2=A0 ba= se64url alphabet"?=C2=A0 Perhaps:

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 It MUST NOT contain any characters that are out= side the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 base64ur= l alphabet, or padding characters ("=3D").

=C2=A0=C2=A0=C2= =A0 or

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 It MUS= T NOT contain any characters that are outside the
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 base64url alphabet (including padding cha= racters ("=3D")).

=C2=A0=C2=A0=C2=A0 Maybe better would be= "It must contain only characters in the
=C2=A0=C2=A0=C2=A0 base64u= rl alphabet including/excluding padding characters("=3D")."<= br>
=C2=A0=C2=A0=C2=A0 Actually, this is just ugly to specify using Engl= ish, because it's
=C2=A0=C2=A0=C2=A0 really hard to say it without u= sing two negatives in one sentence, and
=C2=A0=C2=A0=C2=A0 making clear = what the scope of each negative is.=C2=A0 I think the best
=C2=A0=C2=A0= =C2=A0 approach is to rely on the fact that RFC 7515 section 2 clearly
= =C2=A0=C2=A0=C2=A0 defines that "=3D" is *not* in the base64url a= lphabet:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 It M= UST NOT contain any characters that are not in the base64url
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 alphabet.

=C2=A0=C2=A0= =C2=A0 If someone complains this is unclear, add separate sentence saying=C2=A0=C2=A0=C2=A0 that following RFC 7515 section 2, "=3D" is = not in the base64url
=C2=A0=C2=A0=C2=A0 alphabet.

[RLB] Do= ne.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The va= lue of the resource MUST be the ASCII representation of the
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 key authorization.

=C2=A0=C2=A0=C2=A0 Given= that the key authorization is an ASCII string, it's not clear
=C2= =A0=C2=A0=C2=A0 what its "ASCII representation" is.

[RLB] Given that some systems do not use UTF-8 as their string encoding (e= .g., JavaScript uses UTF-16), it doesn't hurt to re-emphasize this.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The client's = response to this challenge indicates its agreement to
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 this challenge by sending the server the key authorizati= on covering
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the challenge's tok= en and the client's account key.

=C2=A0=C2=A0=C2=A0 I think you = mean, "The client responds to this challenge by POSTing an
=C2=A0= =C2=A0=C2=A0 update to the challenge object, adding a "keyAuthorizatio= n" field
=C2=A0=C2=A0=C2=A0 containing the key authorization derive= d from the challenge's token
=C2=A0=C2=A0=C2=A0 and the client's= account key."

[RLB] Changed "this challenge" = to "the validation request"


=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 1.=C2=A0 Construct a URL by populating the URL = template [RFC6570]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 "http://{domain}/.well-known/acme-challenge/{token}&quo= t;, where: *
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 the domain field is set to the domain name being verified; and *
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the token field i= s set to the token in the challenge.

=C2=A0=C2=A0=C2=A0 What do the = "*" mean?

[RLB] Those are supposed to be bullets.= =C2=A0 Reformatted.


=C2=A0=C2=A0=C2=A0 8.5.=C2= =A0 DNS Challenge

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The record pr= ovisioned to the DNS is the base64url encoding of this
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 digest.

=C2=A0=C2=A0=C2=A0 This doesn't ma= ke sense, as a DNS record is not a string per se.
=C2=A0=C2=A0=C2=A0 How= ever, the next two sentences make clear what the DNS record should
=C2= =A0=C2=A0=C2=A0 be.

[RLB] Changed "is" to "con= tains"


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 _acme-c= hallenge.example.org. 300 IN TXT "gfj9Xq...Rg85nM"

=C2= =A0=C2=A0=C2=A0 It's not clear where "gfj9Xq...Rg85nM" came f= rom, as it's supposed to
=C2=A0=C2=A0=C2=A0 be a SHA-256 digest.=C2= =A0 Though the previous paragraph doesn't specify
=C2=A0=C2=A0=C2=A0= how the digest is to be represented; in parallel to earlier
=C2=A0=C2= =A0=C2=A0 discussion, lower-case hexadecimal seems to be assumed.

[RLB] No, as it says just above this, it is the base64url encoding of = the digest.


=C2=A0=C2=A0=C2=A0 8.6.=C2=A0 Out-o= f-Band Challenge

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the client ind= icates this by sending a simple
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ack= nowledgment response to the server.

=C2=A0=C2=A0=C2=A0 The text does= n't describe what a "simple acknowledgements response"
=C2= =A0=C2=A0=C2=A0 is.

=C2=A0=C2=A0=C2=A0 However, the other challenge = types involve what seem to be parallel
=C2=A0=C2=A0=C2=A0 acknowledgment= responses that are required to contain copies of token
=C2=A0=C2=A0=C2= =A0 values, though in none of these cases does the POST carry any actual=C2=A0=C2=A0=C2=A0 information other than the fact that the POST was made = to the
=C2=A0=C2=A0=C2=A0 particular URL.=C2=A0 What is the reason for t= his inconsistency?=C2=A0 For that
=C2=A0=C2=A0=C2=A0 matter, why does th= e payload of the response for this challenge
=C2=A0=C2=A0=C2=A0 contain = a "type" field?

[RLB] This has been simplified in <= a href=3D"https://github.com/ietf-wg-acme/acme/pull/357" target=3D"_blank">= https://github.com/ietf-wg-acme/acme/pull/357
=

=C2=A0=C2=A0=C2=A0 Perhaps there is something I don't understan= d about these POSTs which
=C2=A0=C2=A0=C2=A0 seem to convey no informati= on other than triggering the server to take
=C2=A0=C2=A0=C2=A0 some acti= on with regard to the target resource.

[RLB] Sometimes you do= n't need any more information! :)=C2=A0 It's still important for th= ese to be POSTs, though, so that they're authenticated.


=C2=A0=C2=A0=C2=A0 9.1.=C2=A0 MIME Type: application/pem-certi= ficate-chain

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The "Med= ia Types" registry should be updated with the following
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 additional value:

=C2=A0=C2=A0=C2=A0 IMO= it's better to phrase this, "The following entry should be added<= br>=C2=A0=C2=A0=C2=A0 to the "Media Types" registry:".=C2=A0= I like to use "update" only for
=C2=A0=C2=A0=C2=A0 operations= that modify existing entries.

[RLB] Disagree.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 File should contain one = or more certificates encoded as PEM according
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 to RFC 7468 [RFC7468].

=C2=A0=C2=A0=C2=A0 "should = contain"?=C2=A0 I think you want to say "File contains".=C2= =A0 Actually,
=C2=A0=C2=A0=C2=A0 "File must consist of ...".
[RLB] Changed to "contains"

=
=C2=A0=C2=A0=C2=A0 "encoded as PEM" seems to be undefined by = RFC 7468.=C2=A0 Perhaps "encoded
=C2=A0=C2=A0=C2=A0 using PEM textu= al encoding according to RFC 7468" is meant.

[RLB] Done.=


=C2=A0=C2=A0=C2=A0 9.6.=C2=A0 URN Sub-namespac= e for ACME (urn:ietf:params:acme)

=C2=A0=C2=A0=C2=A0 I don't see= how this specifies that this registry is connected with
=C2=A0=C2=A0=C2= =A0 the the registry (ACME Error Types, section 9.7.3) which provides the=C2=A0=C2=A0=C2=A0 final component of "urn:ietf:params:acme:*" = URNs.=C2=A0 I suspect you want
=C2=A0=C2=A0=C2=A0 the "Repository&q= uot; datum in this section to state that it points to the
=C2=A0=C2=A0= =C2=A0 registry created per section 9.7.3.

[RLB] There is alr= eady a request for the RFC editor to "replace URL-TBD with the URL ass= igned by IANA for registries of ACME parameters"
<= br>=C2=A0=C2=A0=C2=A0 9.7.=C2=A0 New Registries

=C2=A0=C2=A0=C2=A0 I= s there a registry for fields in authorization objects?

[RLB]= Added one.

=C2=A0=C2=A0=C2=A0 9.7.4.=C2=A0 Resourc= e Types

=C2=A0=C2=A0=C2=A0 Are there entries for "new-nonce&quo= t; and "new-authz"?

[RLB] Done.

=C2=A0=C2=A0= =C2=A0 [END]




--001a11444ab283680c055f1144e9-- From nobody Tue Nov 28 13:07:09 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF47E1243FE for ; Tue, 28 Nov 2017 13:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DG1W8DoGBhO9 for ; Tue, 28 Nov 2017 13:07:06 -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 B03A4124205 for ; Tue, 28 Nov 2017 13:07:05 -0800 (PST) Received: by mail-wr0-x233.google.com with SMTP id o2so1418819wro.5 for ; Tue, 28 Nov 2017 13:07:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=DtrguitvXIZHlm5AoE4LZZYhWBvgxxgAU+L2p2bL3Kc=; b=PSwAVeuFUjHDVKhwj64mFJsKg7aaHNlXWp0gEBkgWBdXMnC9PiSMGwCVYn5AkJO9eL zCF4S2hSHBVBZkFkBnIEMIeu1Z/QYaTvh0+JCVWBTwFt31WQtuEiNvymn83gAtJTuDjf fobu9gBochKIZ6vEJIvT2i4ZLqB7X1e10DXtv/ZqgOvyjWxaFY3XhwnjnGVgfuLZRdAf l6ZpQAdB999tdhDCXgPwVSbW5JCMfPONkJVs9KyxON/LFogzEuaY6lJYM3YJ66j/KJeQ HDGa/AgmoTjyLN7U+Jyu/9xIkw7FQhhGD4AxSmuQIlX2jfsvWzsteC/aNVkQRgsFY5sv 5orQ== 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=DtrguitvXIZHlm5AoE4LZZYhWBvgxxgAU+L2p2bL3Kc=; b=GCxXNHSfB4Gc7Wtglk6T4zIyjNGnZNmXykPGf93jynzQSNvTcVt2vdjywtVvlu8taf Ms8MmzosENZ/cwU3T8AciV/tUqPXm0P/TVp7ajNGKc+f5LNZFLTH00pcSimrA4KRsivo ubiMhQtHGO0aT3p9FDRhd9yxZBftEXevpJijqMCYJAUqIwGXaGC2GyGBhGEemW5bSPMG Q5/FEm0WHOa9wgfsY5j5NG7W7HLEPPoYp/vfRmr8Ff/5skxc3ox0YdfmTZec+repdpN5 yr8+mhqA09uimixmo2jarXinvgGofJeI8z0j0sADpDbe7qECaGPbygooPFQNE/resBJL IcKQ== X-Gm-Message-State: AJaThX43kkj2Ng4muvxBhjAqtngxdVSBKEilWBiStZSMIgmqi8wO7eKj X9OJM1msdmmbVfUBwe5dO+0fswvEcNNeLOVmDAp+0tcSOp4= X-Google-Smtp-Source: AGs4zMYFzKF8grnmk7vFK5vp7036gobCWOnJdHdQOvyDTRjkUQdjx+ja9reGO3bHByVuyOlg7okHl4+M15ywTU7aIEQ= X-Received: by 10.223.133.68 with SMTP id 62mr352473wrh.243.1511903223949; Tue, 28 Nov 2017 13:07:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.167.74 with HTTP; Tue, 28 Nov 2017 13:07:03 -0800 (PST) From: Richard Barnes Date: Tue, 28 Nov 2017 16:07:03 -0500 Message-ID: To: "acme@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0d0d5e99430b055f116699" Archived-At: Subject: [Acme] Clarifications around external account binding 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, 28 Nov 2017 21:07:08 -0000 --94eb2c0d0d5e99430b055f116699 Content-Type: text/plain; charset="UTF-8" Hey all, I just posted a PR adding a "meta" field and an error code that allow a CA to enforce external account binding: https://github.com/ietf-wg-acme/acme/pull/359 This is a pretty minor change, but I think it will make some use cases flow better. Please chime in if you think this is a bad idea. --Richard --94eb2c0d0d5e99430b055f116699 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

I just posted a PR = adding a "meta" field and an error code that allow a CA to enforc= e external account binding:


This is a pretty minor change, but I th= ink it will make some use cases flow better.=C2=A0 Please chime in if you t= hink this is a bad idea.

--Richard
--94eb2c0d0d5e99430b055f116699-- From nobody Wed Nov 29 06:56:18 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 3201A1243F6; Wed, 29 Nov 2017 06:56:16 -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.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151196737615.7956.14904245271990593124@ietfa.amsl.com> Date: Wed, 29 Nov 2017 06:56:16 -0800 Archived-At: Subject: [Acme] I-D Action: draft-ietf-acme-star-02.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 14:56:16 -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 : Support for Short-Term, Automatically-Renewed (STAR) Certificates in Automated Certificate Management Environment (ACME) Authors : Yaron Sheffer Diego Lopez Oscar Gonzalez de Dios Antonio Agustin Pastor Perales Thomas Fossati Filename : draft-ietf-acme-star-02.txt Pages : 19 Date : 2017-11-29 Abstract: Public-key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an attacker. However the revocation process is often unreliable. An alternative to revocation is issuing a sequence of certificates, each with a short validity period, and terminating this sequence upon compromise. This memo proposes an ACME extension to enable the issuance of short- term and automatically renewed (STAR) certificates. [RFC Editor: please remove before publication] While the draft is being developed, the editor's version can be found at https://github.com/yaronf/I-D/tree/master/STAR. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-acme-star/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-acme-star-02 https://datatracker.ietf.org/doc/html/draft-ietf-acme-star-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-star-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Nov 29 07:51:32 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47759127843 for ; Wed, 29 Nov 2017 07:51:31 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CqBeWm_0Mqr for ; Wed, 29 Nov 2017 07:51:29 -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 4CD961277BB for ; Wed, 29 Nov 2017 07:51:29 -0800 (PST) Received: by mail-wr0-x22f.google.com with SMTP id k61so3820834wrc.4 for ; Wed, 29 Nov 2017 07:51:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Kr3Gk2XOQFt5SO5qgnZplDEchklfvCjhVCXJyZ1opEc=; b=rFkt12kFS30kgr+4BtbugqRN2k8vzk1KcqZIe1iFJY0vTGHEmRQxaAx2e8dYJHlvpt kCF6ZnTOT6nAViJCoS2iydVooh+dPAqEPPuuEP/mHlfYmUux4LjuAJFRHoFygigOTGkK e7VCZZ6CU7h5tZqPHnnn0A46tQgK8ZcTSYpzmmTc7P5D56ZsT4KFEE791R7GZtaZBIAc vfWBoN/wQRg+i3sJ8gWma/6kKSEzMbaIW9HR/xYj9wmaoU71ijBztUIdrz1HWDvf1Fk2 LArLSdEPkKEsrXCuqM1pdzLQt7CaRZrLwTMYCOmsJ0dPntOxQkGm1ATpZovdJ8xlhCCS UUhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Kr3Gk2XOQFt5SO5qgnZplDEchklfvCjhVCXJyZ1opEc=; b=klBqhaTWeTMMfCuAQn5YTc+JveLDeRt67Cw0+Y+N6Vx3KKFBCMKdrYlEreIIaVHhz0 qCIVjVseGQ9s5fF/xOSilrCr89ziOtXU7lKHQTLZW+GZ89YwSvCwSeoaHfF4NYW8g6VQ /HpQgzMQUFAVlKvmLfBryweDIdUXvfnGU+k0MHKJ1nH7sFIsTDjlQvN1vdV3N9pzqvLE dIcmZJu6bS6vBarAxcPx8jJ6pgB/UhRWSnzfKzu6anLJK9SgPmZ3tGo27fE3FJpyr9L6 2PzEozvqdz4+ZJLzegZLM8V8t5rvaPomeFF4hCv5Vmgaag59i+salSfTwnO/NfjmiFk0 pPvQ== X-Gm-Message-State: AJaThX6ave6fWw5Z3px07pdNNAdnAYy2Kfo5K8V2fLbezDmK1uFM5zNU c+a0EPvDGQmlM6sL6HOISEA+EWhx X-Google-Smtp-Source: AGs4zMai2RdCB8PsijJJ09cVVM5ys+C8tLJDyBFu668t7anR82eNaEz1YDAeBtLT+MP9EcJQIP9nGQ== X-Received: by 10.223.150.118 with SMTP id c51mr2585750wra.202.1511970687440; Wed, 29 Nov 2017 07:51:27 -0800 (PST) Received: from [172.18.129.55] (bzq-202-11.red.bezeqint.net. [212.179.202.11]) by smtp.gmail.com with ESMTPSA id m64sm2015508wmb.10.2017.11.29.07.51.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Nov 2017 07:51:26 -0800 (PST) References: <151196737633.7956.8450755732703663633.idtracker@ietfa.amsl.com> To: "acme@ietf.org" From: Yaron Sheffer X-Forwarded-Message-Id: <151196737633.7956.8450755732703663633.idtracker@ietfa.amsl.com> Message-ID: <2d2ceb57-cc1e-28fe-149e-729dfb158d18@gmail.com> Date: Wed, 29 Nov 2017 17:51:25 +0200 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: <151196737633.7956.8450755732703663633.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Acme] Fwd: New Version Notification for draft-ietf-acme-star-02.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 15:51:31 -0000 We just published a new version of the draft, based on inputs from the Singapore meeting. Main changes: - Discovery of STAR capabilities via the directory object - Use the more generic term Identifier Owner (IdO) instead of Domain Name Owner (DNO) - More precision about what goes in the order - Clarify server side behavior on cancellation Thanks, Yaron -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-acme-star-02.txt Date: Wed, 29 Nov 2017 06:56:16 -0800 From: internet-drafts@ietf.org To: Oscar Gonzalez de Dios , Yaron Sheffer , Thomas Fossati , Oscar de Dios , Diego Lopez , Antonio Agustin Pastor Perales , Antonio Pastor A new version of I-D, draft-ietf-acme-star-02.txt has been successfully submitted by Yaron Sheffer and posted to the IETF repository. Name: draft-ietf-acme-star Revision: 02 Title: Support for Short-Term, Automatically-Renewed (STAR) Certificates in Automated Certificate Management Environment (ACME) Document date: 2017-11-29 Group: acme Pages: 19 URL: https://www.ietf.org/internet-drafts/draft-ietf-acme-star-02.txt Status: https://datatracker.ietf.org/doc/draft-ietf-acme-star/ Htmlized: https://tools.ietf.org/html/draft-ietf-acme-star-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-acme-star-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-star-02 Abstract: Public-key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an attacker. However the revocation process is often unreliable. An alternative to revocation is issuing a sequence of certificates, each with a short validity period, and terminating this sequence upon compromise. This memo proposes an ACME extension to enable the issuance of short- term and automatically renewed (STAR) certificates. [RFC Editor: please remove before publication] While the draft is being developed, the editor's version can be found at https://github.com/yaronf/I-D/tree/master/STAR. 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. The IETF Secretariat From nobody Wed Nov 29 09:23:32 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1A2127B57 for ; Wed, 29 Nov 2017 09:23:30 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIWlAiM-8L1o for ; Wed, 29 Nov 2017 09:23:29 -0800 (PST) Received: from thomson.beanwood.com (thomson.beanwood.com [18.220.42.202]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79EE6127867 for ; Wed, 29 Nov 2017 09:23:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1511976208; bh=plfYTTDvP7QOH8xVcZ2wKsoTo7NwTcOqftBK1dzARKA=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=NYIH6ziP3kg6eZIvbvEU7LmHEewoOmV/IHm2KtRT80WR/SGM+ZaHlBN3eNdQy9vIh nvQAY/61rGJ4JU4HgiCcxWRI6QSWMtmlZdDVrI1iqBUKgEU+nbMlaef0TRgfmw1N61 YuneG0+INu+F8QaPsnGpnqRnMrMLLm7pw0AFxSz5SwDtHruT0j2+iE5PDSBtVBYJvF wtb2r3os6ztuhRh5hdskWe0pKt+2uFMaRr1+fNBqE7GPg8bBryLOd/a8BKrSQjsJOr 9QFbCh5xfJLyQVY8Dhjj2xQGHvf1O4REHCRqsTkn2hFMgSYZaVcnpS21ysSShixyts 1IwFtxh83om8Q== Date: Wed, 29 Nov 2017 09:23:27 -0800 From: Andrew Ayer To: cpu@letsencrypt.org Cc: Richard Barnes , "acme@ietf.org" , Jacob Hoffman-Andrews Message-Id: <20171129092327.b32c6debdd999b911ca1a27a@andrewayer.name> In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] Landing PR#342 (proactive issuance with identifier-first) 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, 29 Nov 2017 17:23:31 -0000 On Tue, 28 Nov 2017 13:28:08 -0500 Daniel McCarney wrote: > > > > The canonical example for me here is SSLMate [1], which takes a CSR > > up front, I'm told because the back-ends it uses require it. > > Andrew Ayer, who maintains SSLMate, is on this list, and might be > > able to provide further insight. > > > SSLMate/Andrew are the reseller I recall confirming could accommodate > #342 without needing a CSR in new-order. I hope Andrew can clarify if > #I'm > remembering incorrectly. You are remembering correctly. To recap what I said off-list, removing the CSR from new-order wouldn't work if a CA wanted to extend ACME to add non-standard challenges that were derived from the CSR. If a CA is only going to use the standard challenges, then I don't see a problem. SSLMate isn't going to use non-standard challenges, so I'm fine moving the CSR to finalize and removing it from new-order. Regards, Andrew From nobody Wed Nov 29 09:43: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 C00A2126CC4 for ; Wed, 29 Nov 2017 09:43:05 -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 KCVWeFcQ0VzC for ; Wed, 29 Nov 2017 09:43:04 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 438A3120726 for ; Wed, 29 Nov 2017 09:43:04 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id i40so5378221qti.8 for ; Wed, 29 Nov 2017 09:43:04 -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=GEzcCTIa/3JJn08+Jbws6IuHQWn19j8vjPDld9aeVfY=; b=jIj5BwDyEt4hiemvvNPH7ySxXXX86jmW8LG+Z6p9lJQ8cVOjNQGotC2l5GySE72ib5 oMqS1YxKkMMq3EZKidohNXegCiZF3sL+y66fDGfsDqwGO9Pr/QXHch9V6CpS8gbrY5Jh buajB3m7lRYYVZx1viD4YlsqRiFAkE2/YNPafrGDTc54D3uQeNn7yMsrk/aduDY0grQ4 6aRf7v4i9cj5CkHvov+DC7xFwZgnHKpxC9fiEOh81Si/8j5/s72/KJ8tJWiDIBdZWvHD C3B55E2All5VnY1Q8dtcrjRvILHQP6aZqHlEA1Lu4paMxTfgf029PhA2Zmiq9Dbh72tt tfjA== 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=GEzcCTIa/3JJn08+Jbws6IuHQWn19j8vjPDld9aeVfY=; b=WAKaek1+x8uFyaQvVXCI/8S80UGwUpiJOa6QyRClTfdX/OEZch87L2RU3nfiy1mDVT XmrkY9CkgbE2HwBBUZF/2XhxjW06FuaCLaIQIUzQy1u+urTs2U8WM1FvyCDmMU1njVTN uKwLntZcdnKVsaN09uNzi3WFcqpDNNjuKAn7QloxhC6GuvhVvllbTZfV8ICoPEsn8In/ 0K9Ualoe9HyyDSj7N/PFAyb3PIBT7izngxbJqbtiFuIqhvAeFFTAXwiydU4bXL3lw3rw 7FrGMOthX6qJsoB+u/4YJ2zswumuviO2Sy9Ee03L3yF9clzF9ClM1MOGP+OqjD52iR/P EjcA== X-Gm-Message-State: AJaThX5XdnMdy4iFYUuKU7RTKQ4awBh4MU1Crsk35gaVKE7mzbmhxVSJ dQ7zYRxy81Ba5p5Elj5nIEJyGQtWb0AwG2ltK7s= X-Google-Smtp-Source: AGs4zMa5eKcxu7Unuts2e7fPcbrYVPF3mM//thxY4XrGg8wNoptEWIaQQd7Vp/XJ2F3bDQJEwgscT5UDQ73Q/DnQ0qU= X-Received: by 10.200.27.76 with SMTP id p12mr5977042qtk.310.1511977383433; Wed, 29 Nov 2017 09:43:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.39.72 with HTTP; Wed, 29 Nov 2017 09:43:02 -0800 (PST) In-Reply-To: <20171129092327.b32c6debdd999b911ca1a27a@andrewayer.name> References: <20171129092327.b32c6debdd999b911ca1a27a@andrewayer.name> From: Mary Barnes Date: Wed, 29 Nov 2017 11:43:02 -0600 Message-ID: To: Andrew Ayer Cc: cpu@letsencrypt.org, Richard Barnes , "acme@ietf.org" , Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary="94eb2c122b70d91a87055f22aa36" Archived-At: Subject: Re: [Acme] Landing PR#342 (proactive issuance with identifier-first) 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, 29 Nov 2017 17:43:05 -0000 --94eb2c122b70d91a87055f22aa36 Content-Type: text/plain; charset="UTF-8" My comments below [MB]. Regards, Mary On Wed, Nov 29, 2017 at 11:23 AM, Andrew Ayer wrote: > On Tue, 28 Nov 2017 13:28:08 -0500 > Daniel McCarney wrote: > > > > > > > The canonical example for me here is SSLMate [1], which takes a CSR > > > up front, I'm told because the back-ends it uses require it. > > > Andrew Ayer, who maintains SSLMate, is on this list, and might be > > > able to provide further insight. > > > > > > SSLMate/Andrew are the reseller I recall confirming could accommodate > > #342 without needing a CSR in new-order. I hope Andrew can clarify if > > #I'm > > remembering incorrectly. > > You are remembering correctly. > > To recap what I said off-list, removing the CSR from new-order wouldn't > work if a CA wanted to extend ACME to add non-standard challenges that > were derived from the CSR. If a CA is only going to use the standard > challenges, then I don't see a problem. SSLMate isn't going to use > non-standard challenges, so I'm fine moving the CSR to finalize and > removing it from new-order. > > Regards, > Andrew > [MB] With what we have in place right now for SHAKEN (based on STIR), we are using non-standard challenges based on the TNAuthList in the CSR. This may change with the development of the generic token challenge mechanism, but this is another example of the need for this mechanism.[/MB] > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --94eb2c122b70d91a87055f22aa36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My comments below [MB].

Regards,
<= div>Mary

On We= d, Nov 29, 2017 at 11:23 AM, Andrew Ayer <agwa@andrewayer.name><= /span> wrote:
On Tue, 28= Nov 2017 13:28:08 -0500
Daniel McCarney <cpu@letsencrypt.= org> wrote:

> >
> > The canonical example for me here is SSLMate [1], which takes a C= SR
> > up front, I'm told because the back-ends it uses require it.<= br> > > Andrew Ayer, who maintains SSLMate, is on this list, and might be=
> > able to provide further insight.
>
>
> SSLMate/Andrew are the reseller I recall confirming could accommodate<= br> > #342 without needing a CSR in new-order. I hope Andrew can clarify if<= br> > #I'm
> remembering incorrectly.

You are remembering correctly.

To recap what I said off-list, removing the CSR from new-order wouldn't=
work if a CA wanted to extend ACME to add non-standard challenges that
were derived from the CSR.=C2=A0 If a CA is only going to use the standard<= br> challenges, then I don't see a problem.=C2=A0 SSLMate isn't going t= o use
non-standard challenges, so I'm fine moving the CSR to finalize and
removing it from new-order.

Regards,
Andrew

[MB] With what we have in place = right now for SHAKEN (based on STIR), we are using non-standard challenges = based on the TNAuthList in the CSR.=C2=A0 This may change with the developm= ent of the generic token challenge mechanism, but this is another example o= f the need for this mechanism.[/MB]

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

--94eb2c122b70d91a87055f22aa36-- From nobody Wed Nov 29 09:48:32 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3AA212869B for ; Wed, 29 Nov 2017 09:48:30 -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 OyXw7ZPgzbmF for ; Wed, 29 Nov 2017 09:48:29 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC875120726 for ; Wed, 29 Nov 2017 09:48:28 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id b76so7647567wmg.1 for ; Wed, 29 Nov 2017 09:48:28 -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=ZadIXfS3Wsew5Xuo+tk0YdRXl5yaFZt6KyMaK4klbHs=; b=YL9n/RwGfT74Fyh+t0/ebPCam8G46FF2b/df+QVDMaPobf+UqTBmDkKGrhFkpCRpeh d6cx4GUmXXiNLzlKu+Vtly8nOnlYLsWVs+rxicLx+K+At2jn87e+stU/8ALEPKkJUs0D eQuM98FSLgI4DO2upsS+knydhaIT5nLBvVIkxdl3P9haaMu5WRasra4pE1lXBfTR1CUo pZ2isdGjPhLXeq1bOwY/ZPzg/Boi0E4+VKJL9bc84GtOZSiPemHf3T61mdW32/EPwZ2c gL7c+THhht1zUwymcmwBWzecp303Hy+jG0CQ30Gj/CqqOfZXvAjhFCnMtde5jbD4VSqT 3XBw== 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=ZadIXfS3Wsew5Xuo+tk0YdRXl5yaFZt6KyMaK4klbHs=; b=XsY7HFQVjFtpHbgNyXO5UX03zaKaC0ERdyb0joeC1au/Eia74q5Cd/9L9XV6TY8DUY jzOBOSSEx8mWP6Ap4nZagkUcNH469tYD9Jym4A6sV2UVzil1ooM/hWD2vpTqzB9S11b3 wYeZP9Y94rAca1bw1Ebgl0ZEQpceEnprzc9pTY27APjlFsxtYYN5R7spXp0UJBBEUT3J PC0AONHnVTMpzmfMqasvDo+uWg94nuJt831w7sxG6EEBvHVWnHPCMTPM8hLVVdU756lr zHW6fDB2U3Hlg4PEjFlhKPoiL85mcWMc4dyDXUYjIpiJSJghQeMWwRR70hC0glZ6h3w5 8H2g== X-Gm-Message-State: AJaThX5Qg4UFloNBW0HtAPthJRUjae1jOekDKUIVMl2KM4Mm561zlyDH X1HZ4P/QZnJ/O32AIpIzVD6LYPTHSpe9bfERntsUaw== X-Google-Smtp-Source: AGs4zMbFa9J+iOI5J5wm7jJwxQJTibqphV0C+jDKCPm6INNAVh6SgHmeJEHh2a1xJfylcyZlb6CG2aLmLNtrF/eMERM= X-Received: by 10.28.212.74 with SMTP id l71mr2889380wmg.33.1511977707255; Wed, 29 Nov 2017 09:48:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.167.74 with HTTP; Wed, 29 Nov 2017 09:48:26 -0800 (PST) In-Reply-To: References: <20171129092327.b32c6debdd999b911ca1a27a@andrewayer.name> From: Richard Barnes Date: Wed, 29 Nov 2017 12:48:26 -0500 Message-ID: To: Mary Barnes Cc: Andrew Ayer , Daniel McCarney , "acme@ietf.org" , Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary="001a1146987a26775e055f22beca" Archived-At: Subject: Re: [Acme] Landing PR#342 (proactive issuance with identifier-first) 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, 29 Nov 2017 17:48:31 -0000 --001a1146987a26775e055f22beca Content-Type: text/plain; charset="UTF-8" On Wed, Nov 29, 2017 at 12:43 PM, Mary Barnes wrote: > My comments below [MB]. > > Regards, > Mary > > On Wed, Nov 29, 2017 at 11:23 AM, Andrew Ayer > wrote: > >> On Tue, 28 Nov 2017 13:28:08 -0500 >> Daniel McCarney wrote: >> >> > > >> > > The canonical example for me here is SSLMate [1], which takes a CSR >> > > up front, I'm told because the back-ends it uses require it. >> > > Andrew Ayer, who maintains SSLMate, is on this list, and might be >> > > able to provide further insight. >> > >> > >> > SSLMate/Andrew are the reseller I recall confirming could accommodate >> > #342 without needing a CSR in new-order. I hope Andrew can clarify if >> > #I'm >> > remembering incorrectly. >> >> You are remembering correctly. >> >> To recap what I said off-list, removing the CSR from new-order wouldn't >> work if a CA wanted to extend ACME to add non-standard challenges that >> were derived from the CSR. If a CA is only going to use the standard >> challenges, then I don't see a problem. SSLMate isn't going to use >> non-standard challenges, so I'm fine moving the CSR to finalize and >> removing it from new-order. >> >> Regards, >> Andrew >> > > [MB] With what we have in place right now for SHAKEN (based on STIR), we > are using non-standard challenges based on the TNAuthList in the CSR. This > may change with the development of the generic token challenge mechanism, > but this is another example of the need for this mechanism.[/MB] > It's perfectly fine to use non-standard challenges, as long as they can be derived from the "identifiers" array added in #342. It's only if you needed some other component of the CSR (e.g., the public key) in the challenge that you would have an issue. --Richard --001a1146987a26775e055f22beca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 29, 2017 at 12:43 PM, Mary Barnes <mary.ietf.barn= es@gmail.com> wrote:
My comments below [MB].

Regards,
Ma= ry

On Wed, Nov 29, 2017 at 11:23 AM, Andrew Ayer <agwa@andrewa= yer.name> wrote:
On= Tue, 28 Nov 2017 13:28:08 -0500
Daniel McCarney <cpu@letsencrypt.org> wrote:

> >
> > The canonical example for me here is SSLMate [1], which takes a C= SR
> > up front, I'm told because the back-ends it uses require it.<= br> > > Andrew Ayer, who maintains SSLMate, is on this list, and might be=
> > able to provide further insight.
>
>
> SSLMate/Andrew are the reseller I recall confirming could accommodate<= br> > #342 without needing a CSR in new-order. I hope Andrew can clarify if<= br> > #I'm
> remembering incorrectly.

You are remembering correctly.

To recap what I said off-list, removing the CSR from new-order wouldn't=
work if a CA wanted to extend ACME to add non-standard challenges that
were derived from the CSR.=C2=A0 If a CA is only going to use the standard<= br> challenges, then I don't see a problem.=C2=A0 SSLMate isn't going t= o use
non-standard challenges, so I'm fine moving the CSR to finalize and
removing it from new-order.

Regards,
Andrew

[MB] With what we ha= ve in place right now for SHAKEN (based on STIR), we are using non-standard= challenges based on the TNAuthList in the CSR.=C2=A0 This may change with = the development of the generic token challenge mechanism, but this is anoth= er example of the need for this mechanism.[/MB]

It's perfectly fine to use non-stand= ard challenges, as long as they can be derived from the "identifiers&q= uot; array added in #342.=C2=A0 It's only if you needed some other comp= onent of the CSR (e.g., the public key) in the challenge that you would hav= e an issue.

--Richard
--001a1146987a26775e055f22beca-- From nobody Wed Nov 29 11:57:33 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769BA1241F3 for ; Wed, 29 Nov 2017 11:57:31 -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 U19c3ZYVCh3u for ; Wed, 29 Nov 2017 11:57:29 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 17F90128DF3 for ; Wed, 29 Nov 2017 11:57:28 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id k19so5919041qtj.6 for ; Wed, 29 Nov 2017 11:57:28 -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=qDRSGIZ+O9bUj0tx77gioAdtRxfMNvIwQZ7qfKJ2puo=; b=m+VBr6q1bo5rCec/xrkLgN6pKmzvJrMD4KdqEeNYwImeIXCrx13OcL+eh5qijhwZ9r 0G4I9GX9MytxiBFoaqKUPYlOv+OpLkBtFrOQW2bbZm4CejiPv236kAAjqN6c8ZwvaPtk 5dvrQElDZrNP4blHvS+/3u3paC//1NfHU6JXji5jumnX6y/HseRZ0/8D53HDgq8dtfeo Es6b+i3jfnNkbnPediOQUyWqmF6aLqdj86eyNlEwKROXUav2eCClqOMXiJkczBJGSzg6 S7UU7+cVl3YnB04mTgO9Jv4YpXMiMEL9/6SZSeC8XX1nMDKfg1bZZ83StN4sVZcOESr0 buVA== 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=qDRSGIZ+O9bUj0tx77gioAdtRxfMNvIwQZ7qfKJ2puo=; b=BQOvEWPBE4km8FNzT8bC/Ce4rHTFJmJgFJ0poprwnaTWILFvWDjP4MQ5eHxvPq6rHe 0WPQTySdo2x9fR0+VK8s+VxkS44Bg/AJyQtdG5Ol+Cue9spdg+6QiMBEjMsgmgXf1rEA v5t+YXjh9azJHPzGVlb8bV0tp6BBSYSWwG4DH7kKDi8jIQMTg/CRdm+27+ppDDSv5u9v kGq0X3pIK2OXJgL7Ss1bK6zcG+WeAEHn2WCMjLz7iSGAFRZ5zfbqT9kxCGCs9pSkHdPw NOpCFcYfg4Iqzu0pABrVhMDdrN4dLAnJtaGeMEOCJjfX5hCo7OPfI9+AT0be7qpmnD9/ zgpg== X-Gm-Message-State: AKGB3mLycEpeL7AZMcbMsezwv86OehHyZUHPtDW8t3PT8CIlhcDYn8tr g1JYeHV3ZzWj87svFhr3dXiPxw9dR9rVkCO4m4w= X-Google-Smtp-Source: AGs4zMaNYByA4FeWMfTCyOy4mw04+oEPtGLXhgNaaS9aGqqK2ISqTrNL03wF8cUNmpG45FEfKI2sLw7F9ibDgKe4zcs= X-Received: by 10.200.45.89 with SMTP id o25mr13658qta.227.1511985447128; Wed, 29 Nov 2017 11:57:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.39.72 with HTTP; Wed, 29 Nov 2017 11:57:26 -0800 (PST) In-Reply-To: References: <20171129092327.b32c6debdd999b911ca1a27a@andrewayer.name> From: Mary Barnes Date: Wed, 29 Nov 2017 13:57:26 -0600 Message-ID: To: Richard Barnes Cc: Andrew Ayer , Daniel McCarney , "acme@ietf.org" , Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary="001a113e319a7b50a7055f248b4e" Archived-At: Subject: Re: [Acme] Landing PR#342 (proactive issuance with identifier-first) 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, 29 Nov 2017 19:57:31 -0000 --001a113e319a7b50a7055f248b4e Content-Type: text/plain; charset="UTF-8" Got it - thanks for the clarification (now I just need to start updating IPNNI docs ;) On Wed, Nov 29, 2017 at 11:48 AM, Richard Barnes wrote: > > > On Wed, Nov 29, 2017 at 12:43 PM, Mary Barnes > wrote: > >> My comments below [MB]. >> >> Regards, >> Mary >> >> On Wed, Nov 29, 2017 at 11:23 AM, Andrew Ayer >> wrote: >> >>> On Tue, 28 Nov 2017 13:28:08 -0500 >>> Daniel McCarney wrote: >>> >>> > > >>> > > The canonical example for me here is SSLMate [1], which takes a CSR >>> > > up front, I'm told because the back-ends it uses require it. >>> > > Andrew Ayer, who maintains SSLMate, is on this list, and might be >>> > > able to provide further insight. >>> > >>> > >>> > SSLMate/Andrew are the reseller I recall confirming could accommodate >>> > #342 without needing a CSR in new-order. I hope Andrew can clarify if >>> > #I'm >>> > remembering incorrectly. >>> >>> You are remembering correctly. >>> >>> To recap what I said off-list, removing the CSR from new-order wouldn't >>> work if a CA wanted to extend ACME to add non-standard challenges that >>> were derived from the CSR. If a CA is only going to use the standard >>> challenges, then I don't see a problem. SSLMate isn't going to use >>> non-standard challenges, so I'm fine moving the CSR to finalize and >>> removing it from new-order. >>> >>> Regards, >>> Andrew >>> >> >> [MB] With what we have in place right now for SHAKEN (based on STIR), we >> are using non-standard challenges based on the TNAuthList in the CSR. This >> may change with the development of the generic token challenge mechanism, >> but this is another example of the need for this mechanism.[/MB] >> > > It's perfectly fine to use non-standard challenges, as long as they can be > derived from the "identifiers" array added in #342. It's only if you > needed some other component of the CSR (e.g., the public key) in the > challenge that you would have an issue. > > --Richard > --001a113e319a7b50a7055f248b4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Got it - thanks for the clarification (now I just need to = start updating IPNNI docs ;)=C2=A0

On Wed, Nov 29, 2017 at 11:48 AM, Richard Barnes <rlb@ipv.= sx> wrote:


On Wed, Nov 29, 2017 at 12:43 PM, Mary Barnes = <mary.ie= tf.barnes@gmail.com> wrote:
My comments below [MB].

Regards,
=
Mary

On Wed, Nov 29, 2017 at 11:23 AM, A= ndrew Ayer <agwa@andrewayer.name> wrote:
On Tue, 28 Nov 2017 13:28:08 -0500
Daniel McCarney <cpu@letsencrypt.org> wrote:

> >
> > The canonical example for me here is SSLMate [1], which takes a C= SR
> > up front, I'm told because the back-ends it uses require it.<= br> > > Andrew Ayer, who maintains SSLMate, is on this list, and might be=
> > able to provide further insight.
>
>
> SSLMate/Andrew are the reseller I recall confirming could accommodate<= br> > #342 without needing a CSR in new-order. I hope Andrew can clarify if<= br> > #I'm
> remembering incorrectly.

You are remembering correctly.

To recap what I said off-list, removing the CSR from new-order wouldn't=
work if a CA wanted to extend ACME to add non-standard challenges that
were derived from the CSR.=C2=A0 If a CA is only going to use the standard<= br> challenges, then I don't see a problem.=C2=A0 SSLMate isn't going t= o use
non-standard challenges, so I'm fine moving the CSR to finalize and
removing it from new-order.

Regards,
Andrew

[MB] With what we ha= ve in place right now for SHAKEN (based on STIR), we are using non-standard= challenges based on the TNAuthList in the CSR.=C2=A0 This may change with = the development of the generic token challenge mechanism, but this is anoth= er example of the need for this mechanism.[/MB]

It's perfectly fine to u= se non-standard challenges, as long as they can be derived from the "i= dentifiers" array added in #342.=C2=A0 It's only if you needed som= e other component of the CSR (e.g., the public key) in the challenge that y= ou would have an issue.

--Richard

--001a113e319a7b50a7055f248b4e-- From nobody Thu Nov 30 08:03: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 75609127B31 for ; Thu, 30 Nov 2017 08:03:10 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=letsencrypt.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ml4MhWA82dM3 for ; Thu, 30 Nov 2017 08:03:08 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6623A1200FC for ; Thu, 30 Nov 2017 08:03:08 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id s19so8064743ioa.1 for ; Thu, 30 Nov 2017 08:03:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:reply-to:from:date:message-id:subject:to; bh=OjwmbYehpx03az4YlX3AGfbAtecFiFvKIniDF7roOCQ=; b=IgAaYYjJMAgT0VyKP82qDyHIZmIVwovn+ZE5pq3Ni0D9nP9hh0+yoU2IlwPeiedRfi gjZOmPkgA7KkC4mUthgLAkGGs6+jiFUK1yVNM/mJsqSuxikeXQFZkfY7Jr+1UoUVsNCP 0/SI+g8wfnyeq0L8ps/+6wS6q9RDBaPaa/0Sg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=OjwmbYehpx03az4YlX3AGfbAtecFiFvKIniDF7roOCQ=; b=Bya4pncZqoZGXtsyWCTWD4S1W8d+l7sFOJ/13tf3x12caKvcuSI0eh+6d5xKXrZ5eT OsWwgRz0lpgIB0os2/dR2IMldW2ltTE3q6s2C5nMCY0iLAeUwDPKDaOHREl07AJWMdsQ gLrJtzisf7611qtzdBnMl/fEiqYUmXQr/K/bbiDdzDIbR6cfLL7TXrVG7c1//XYdAI4F ZF3bDnOTKm33LNaSh8Tnw3O//NpTwanSEh48tG0E+t57xVqohsz8qRgMeUNCzQHSwNH3 hYJ6Uj66f39lNL4g5wriDhJ6H4O7WZeHB5Yr9Xd2ZMrChTz2hQSRXf0PkXGmPgOSK+0z neiA== X-Gm-Message-State: AJaThX5sX3RJ9MCcnxQdbkQ/S2EZjtUhGchHTBRW8bceVhQZoTqgGdeQ Z0HcQXkLBSXuVxvKFDMnH89kJaJqdrI4uVHKx6WbusWtfXE= X-Google-Smtp-Source: AGs4zMbn7eVVEz/GIyL2zpcZBYRKEN2QSl1opCTHI8uRuJC1ifWfKGGu8B0HdVIiGIK79CLIz6MnKgVFdeifFNdFMhM= X-Received: by 10.107.170.40 with SMTP id t40mr8826568ioe.73.1512057786910; Thu, 30 Nov 2017 08:03:06 -0800 (PST) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.17.28 with HTTP; Thu, 30 Nov 2017 08:03:06 -0800 (PST) From: Daniel McCarney Date: Thu, 30 Nov 2017 11:03:06 -0500 Message-ID: To: IETF ACME Content-Type: multipart/alternative; boundary="001a1142d86e4507d9055f35634a" Archived-At: Subject: [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: Thu, 30 Nov 2017 16:03:10 -0000 --001a1142d86e4507d9055f35634a Content-Type: text/plain; charset="UTF-8" Hi folks, In a previous thread[0] surveying ACME implementations two commercial CAs (BuyPass and DigiCert) outlined that their ACME integrations use external account binding but **not** the Out-of-Band (OOB) challenge type. As Clint from DigiCert points out[1] having a binding with an external account enables access to the full context of any non-ACME authorizations/challenges the CA requires through existing systems. Overall, the OOB challenge type: * has no server implementations * has no client implementations * has no dependent use-cases presented to the WG * offers a subset of what external account binding already offers Removing it from the draft seems like a sensible decision to me. If there is demand (& accompanying client/server implementations) the challenge type could easily be re-added in a follow-up work. - Daniel / cpu [0] https://mailarchive.ietf.org/arch/msg/acme/oFPXvSnocJZorYiR8Tj6cYbA_wY [1] https://mailarchive.ietf.org/arch/msg/acme/COZ3xDpBTTvgmbbEc8fLDnu0Onw [2] https://github.com/ietf-wg-acme/acme/pull/360 --001a1142d86e4507d9055f35634a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

In a previous thre= ad[0] surveying ACME implementations two commercial CAs (BuyPass and DigiCe= rt) outlined that their ACME integrations use external account binding but = **not** the Out-of-Band (OOB) challenge type.

As C= lint from DigiCert points out[1] having a binding with an external account = enables access to the full context of any non-ACME authorizations/challenge= s the CA requires through existing systems.

Overal= l, the OOB challenge type:
* has no server implementations
<= div>* has no client implementations
* has no dependent use-cases = presented to the WG
* offers a subset of what external account bi= nding already offers

Removing it from the draft se= ems like a sensible decision to me. If there is demand (& accompanying = client/server implementations) the challenge type could easily be re-added = in a follow-up work.

- Daniel / cpu

=

--001a1142d86e4507d9055f35634a-- From nobody Thu Nov 30 08:42: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 86ADC1200B9 for ; Thu, 30 Nov 2017 08:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0W8uKzQ0iQ3M for ; Thu, 30 Nov 2017 08:42:14 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9BB7127876 for ; Thu, 30 Nov 2017 08:42:13 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAUGfH1I019225; Thu, 30 Nov 2017 16:42:12 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=HGVwL3CALOULkc2mV7S5jrQu8U5cGi5HzAcPWRvSgdo=; b=Pf7WcGaU/RhDP2A2EXWOo2l1ikOOXmS/bbnnkoIZFzXbH3C0V1FZZL1DH2mQgYTRTUm0 De10ObFmFwJY1GUxW3GXczkoFqv5IknrB3ip+pEdSNVBnGOAL332F+l1uZr7lS3rc7sn NOClofwWoduGY16ta4g1SjLuURoI0EFDmzxvBYdMNie+kjR96XypgdTfQr6IW5ha9hUu SOq1hgkTFOgkPCov/bS2H7eD8rEPf6z6iWYZIdMWBoQT1yT87qi53eCbjVWOgE5QMm3i 2EvKhicRDfH7jXlgXRYLh4Yxe6WDneshMnALcUGD9XUJ/Fwx9dgoqNB08aIWuk67e6MD ig== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050096.ppops.net-00190b01. with ESMTP id 2egvrdrwqd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Nov 2017 16:42:12 +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 vAUGfENh032649; Thu, 30 Nov 2017 11:42:11 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2ef4qywgsx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 30 Nov 2017 11:42:11 -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; Thu, 30 Nov 2017 11:42:10 -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; Thu, 30 Nov 2017 11:42:11 -0500 From: "Salz, Rich" To: "cpu@letsencrypt.org" , IETF ACME Thread-Topic: [Acme] Removing OOB Challenge Type Thread-Index: AQHTafS8lPPPxlZRcEOAfxnjrU0qI6MtdD0A Date: Thu, 30 Nov 2017 16:42:11 +0000 Message-ID: <0F612577-86CE-4E86-B95C-01C0FF82BDA7@akamai.com> References: 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.40.211] Content-Type: multipart/alternative; boundary="_000_0F61257786CE4E86B95C01C0FF82BDA7akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-30_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711300218 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-30_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711300218 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: Thu, 30 Nov 2017 16:42:15 -0000 --_000_0F61257786CE4E86B95C01C0FF82BDA7akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RG9lcyBhbnlvbmUgZGlzYWdyZWUgd2l0aCBEYW5pZWzigJlzIHJlYXNvbmluZz8gIElmIHNvLCBw bGVhc2Ugc3BlYWsgdXAgYmVmb3JlIG5leHQgRnJpZGF5Lg0KDQpEYW5pZWwsIHBsZWFzZSBkbyBu b3QgbWVyZ2UgdGhpcyB1bnRpbCB3ZSBkZXRlcm1pbmUgV0cgY29uc2Vuc3VzLg0K --_000_0F61257786CE4E86B95C01C0FF82BDA7akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0 ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvZXMgYW55b25lIGRpc2FncmVl IHdpdGggRGFuaWVs4oCZcyByZWFzb25pbmc/Jm5ic3A7IElmIHNvLCBwbGVhc2Ugc3BlYWsgdXAg YmVmb3JlIG5leHQgRnJpZGF5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EYW5pZWwsIHBsZWFz ZSBkbyBub3QgbWVyZ2UgdGhpcyB1bnRpbCB3ZSBkZXRlcm1pbmUgV0cgY29uc2Vuc3VzLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0F61257786CE4E86B95C01C0FF82BDA7akamaicom_-- From nobody Thu Nov 30 09:25: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 05F18129411 for ; Thu, 30 Nov 2017 09:25:00 -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 7rf1cAgHd8Qi for ; Thu, 30 Nov 2017 09:24:59 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 088841293E9 for ; Thu, 30 Nov 2017 09:24:58 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id x129so8294770iod.13 for ; Thu, 30 Nov 2017 09:24:58 -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=z5bSyCSHax/LJ0ik+d+Ev0mwTNsdqCRNztDXcpU0z/k=; b=Ij8LkJV6r0vT6mZH7oou8PmE14TkavuQwFLFUFzjYmp5efhbWhJcyzOOZGSBcTb4wB ocacU0F9I8n80QI/QSTfjhHie04Qk2EtIJTBQtG/TfGwKBgNfgmUhk5gLjManYkKVAgz G+kMpTm80xx1X/ewqIDUWXcKJ9S4BmGyfpw90= 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=z5bSyCSHax/LJ0ik+d+Ev0mwTNsdqCRNztDXcpU0z/k=; b=cN8D36BhKSKj8vrGoG0V2yTrhTnLenJFF7okRC2UFnMyA7oh613cQ+/vQ3Ne9hxe9b 76hM0wmVu106ctTNu5gMVKPYAxz2hXWJWELUIUpJa4j1RK6cw9air/rwkDxPbig1yHuX XbxJKrSSksrL+/yTVYe2YG/ni2SeT14CbyXY2o8AZvothESasSRavgaAxZvSUhPFMezj myTeu40qwWAkGpy5CNQI2px83tZ5rDNqyLV8v8H6Hfh0nvFyXEJBnJV4iJ9ZNA+2yDss DFN0bs7DoFjd0C5Kv/haqg2eJbiGxcu3q7wb0/PvFM4w3C9c5HlD9YLCS2tchFleSNEE 1G7A== X-Gm-Message-State: AKGB3mIL3minNBdRLHOFXqZqwXzkzbcSeK7G0u5nHny1BlU6+921I9LN 2h8Nv6flu4ebCruciPpCeo14uz7iHoFqKnKmszuRnA== X-Google-Smtp-Source: AGs4zMbVJ1drcKK/0Xf6q7lYKuxwVrkzNyEjWSbA6Lzwf3LnElHC6gXdZzd3wW8w6JOqfKj8wiE6P8J2FgA5AJq0/0c= X-Received: by 10.107.37.139 with SMTP id l133mr640162iol.89.1512062698297; Thu, 30 Nov 2017 09:24:58 -0800 (PST) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.17.28 with HTTP; Thu, 30 Nov 2017 09:24:57 -0800 (PST) In-Reply-To: <0F612577-86CE-4E86-B95C-01C0FF82BDA7@akamai.com> References: <0F612577-86CE-4E86-B95C-01C0FF82BDA7@akamai.com> From: Daniel McCarney Date: Thu, 30 Nov 2017 12:24:57 -0500 Message-ID: To: "Salz, Rich" Cc: IETF ACME Content-Type: multipart/alternative; boundary="001a11405dfe02b215055f3688a5" 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: Thu, 30 Nov 2017 17:25:00 -0000 --001a11405dfe02b215055f3688a5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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 spea= k up > before next Friday. > > > > Daniel, please do not merge this until we determine WG consensus. > --001a11405dfe02b215055f3688a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0Daniel, please = do not merge this until we determine WG consensus

Of course :-) I do= n't have any merge privileges!

<= /div>

On Thu, Nov 30, 2017 at 11:42 AM, Salz, Rich <rsalz@akamai.com><= /span> 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.


--001a11405dfe02b215055f3688a5-- From nobody Thu Nov 30 09:39:48 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2E61287A5 for ; Thu, 30 Nov 2017 09:39:46 -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 EkT4IP8gSpqo for ; Thu, 30 Nov 2017 09:39:45 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13CA91286B2 for ; Thu, 30 Nov 2017 09:39:45 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id 33so9790362qtv.1 for ; Thu, 30 Nov 2017 09:39:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kkOxekVPp3BaCjMgu6xJFzv1JHYKJ6osEVV127NhQJk=; b=vf/u258CzdTqF0WzOslpD+NaTCJkXwkUXBrxqekDX/izbEqHEYcV5SMC0H/L+7MEpG g5XqhOiVfRcUzmYCiG7tal2Xy9nJ1d7PqQOzcSjAkjARDuQRT0Pot0wyiyn3ksss2jKG 5RaPYOkFYAIN/73+ZQ8fQWt5UZfcyDluOBqhAg7zykWoE10Ovz0ouNaasaOiCvTJl333 uQxYy/3Stq9mJZlScDg0suLoQJxW32Azqu5qc74Rxb3WQree8+76ev3Ek0bJaOYQWZZ3 xk8I9ItY5r5+VrnBU1zz9umrEC0slyIl6UNpBLJgjQLRDfmWDl6jm2zSWM61oBjhrNdD 7PLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kkOxekVPp3BaCjMgu6xJFzv1JHYKJ6osEVV127NhQJk=; b=XSwjwhBTz1DO3QZLazP8ElhMPj6A4oJU/IKtN1bGZ2X5v02IRomZBTHUi4Eu2FeGcC UYEWhlp1FaEkxq3ykeFDd6G5qBoZbYgPYh6aX7QKHlz8eaUA+/E39rnz4YaKcMclgN8g Ca7Z0dbo50rjEbQeJizRU84e/qSlmRllTyL9ww4VU1oe7bMouWjrskYAXHUZQ+ZtALh/ 2/wP1dEefCtKYXsr2U30AmIiI2TfcMPXSJnC+8XyqszKm6kXh/vYD0t+gkZVhMqbD2oG 63t72C9pVFtCjt3KdCyJB4bgOv119YhT8rr6XI/Hw+/AdVUCJHRMapU09+bGyHqAUQpE R5tA== X-Gm-Message-State: AKGB3mLRgI4FF7VwnhipKrBNf7AmZ//dInvXXDCyvD2OApkrlEbjlO/E RJsyJG/s44jjDIrd3iTD9huvgrLAC836SSvLGjY= X-Google-Smtp-Source: AGs4zMYwwVS5uxzaxubu7yM/Tj/pbQehoVrPt1WtWbTKu5THAd8IQHS73o814Kk7zu2emnz3usm8jzlS5sqNmcF8b0U= X-Received: by 10.237.62.4 with SMTP id l4mr4615063qtf.331.1512063584059; Thu, 30 Nov 2017 09:39:44 -0800 (PST) MIME-Version: 1.0 References: <0F612577-86CE-4E86-B95C-01C0FF82BDA7@akamai.com> In-Reply-To: From: Clint Wilson Date: Thu, 30 Nov 2017 17:39:32 +0000 Message-ID: To: cpu@letsencrypt.org Cc: "Salz, Rich" , IETF ACME Content-Type: multipart/alternative; boundary="001a1140e474ce4541055f36bc55" 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: Thu, 30 Nov 2017 17:39:47 -0000 --001a1140e474ce4541055f36bc55 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 spe= ak 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 > --001a1140e474ce4541055f36bc55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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 me= antime. As Daniel notes, it's straightforward to add it back if needed.=


On Thu, Nov 30, 2017, 10:25= AM Daniel McCarney <cpu@letsencr= ypt.org> wrote:
>=C2=A0Daniel, 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 <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.


_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
--001a1140e474ce4541055f36bc55-- From nobody Thu Nov 30 10:23:37 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DAB129442 for ; Thu, 30 Nov 2017 10:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrKFBxFdkSMG for ; Thu, 30 Nov 2017 10:23:33 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 687A6128E19 for ; Thu, 30 Nov 2017 10:23:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=jO6Y69pwKUrr9fXngO0v0rYLhqKdXTqkVlnBcZ5TpRg=; b=VhgKH2Lv10YfY9icMsm0s6X1qpZPPFgkSNv58cYE16WoY19E9m1vdmQrrjh/Gd7qNaUWZkM514Y6z4nKoX2D6eUfEoV+93FTV73DyN3uCEi1TAszf/1Uu+UG5CFs4m6M92kEvS8ydvvBr+yJrVFiB57zMp5EGiAqkLrrAK/XLxg=; Received: ; Thu, 30 Nov 2017 10:22:54 -0800 To: Clint Wilson , cpu@letsencrypt.org Cc: "Salz, Rich" , IETF ACME References: <0F612577-86CE-4E86-B95C-01C0FF82BDA7@akamai.com> From: Jacob Hoffman-Andrews Message-ID: <6c002b3f-8018-45f8-64dd-1bbb2d2918d2@eff.org> Date: Thu, 30 Nov 2017 10:22:56 -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: Content-Type: multipart/alternative; boundary="------------87F4441298621CE2F16118FC" Content-Language: en-US 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: Thu, 30 Nov 2017 18:23:36 -0000 This is a multi-part message in MIME format. --------------87F4441298621CE2F16118FC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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’s 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 --------------87F4441298621CE2F16118FC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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 <cpu@letsencrypt.org> 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 <rsalz@akamai.com> wrote:

Does anyone disagree with Daniel’s 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

--------------87F4441298621CE2F16118FC-- From nobody Thu Nov 30 12:58:24 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279641294CF for ; Thu, 30 Nov 2017 12:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xr0HrTHzwP9G for ; Thu, 30 Nov 2017 12:58:20 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2101294C7 for ; Thu, 30 Nov 2017 12:58:20 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id d16so9007905iob.4 for ; Thu, 30 Nov 2017 12:58:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=KjmOFu1uJmJ21/E2FIG+ecT2cQ8WVNxpnX2io932ObM=; b=GRLvwOWbOkNhYUGERxiuFAQQcjCYkwkSK+bNFGp2uWT40rXjv9OI6k0LzgURf1Wzkz cniiKTDgL0mwQ5r0HJk2wJavmWQsyhmkxgqzCVW+OPmzuFkJo2NCMPnezib6CvsOfJRm jGW1xK5+2KvFXqvL6wM29b/npNCk7axpO5vq8S/jDP++xXVF4/HnYv7MdMFrsDjb3XBt DodQfFpjh4TcEWROLVBKSXc+Z+U8DrtG5lNn+Fl+mlcMJSW7pdc97qaRWQ3YDTGCqRZl TIrO/i6ZKTnPBFVsMNK/dsKkCfoVg29C2/jt0Q3mz0w+XLQnlhax6Vts+4pgFNARVTCo 9zJA== 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=KjmOFu1uJmJ21/E2FIG+ecT2cQ8WVNxpnX2io932ObM=; b=sa108KAZu3jV0LaRg5SRLF9a5xA4BkM3zn4x4il8l8+p12Xu7yWJrY2eD2UPYh4B6q eQJB1pRhgYHgtRbko7KSlLNmxG/SxHXmnSA+PjuaTUu6HpSQQFCJFmbuWcBPgGRVsMa/ T9l0g9CH0Ersd6Yshyap4rvlrKSTJd7tljqKBp87ShnfX15OgkNZ7TRtcxF7nOJr/P3M 0D95CkwriAaejZiZYILoy7kPvdS3dby482mIc1aIhwDWiiAAmgNjYgeypdThSuQxfKIA 2n4KIL52FsqTQqTAJf3QD6mFzXSyv2FaHZxZFEaOF/TzhHFCVZyg0/Def1YJ2TEq9+U2 FkoA== X-Gm-Message-State: AJaThX5/vBOYBm6JEcr3K2g/EPjtvsArhV3fkMOGCHSaRSo7rEgX4Ebs h6yhkb/18Qwdrj39jwojxBuo/VoyTE1tFk8fwPStoA== X-Google-Smtp-Source: AGs4zMZKmvV2DS1zhXUCF59j2h1M/W9MxQo0cDtTyQ80npAV7hQororw0hGE/nJWc7rrzNJ/NAG7JE2M3ZNqDt5WgkE= X-Received: by 10.107.136.229 with SMTP id s98mr9914496ioi.294.1512075499262; Thu, 30 Nov 2017 12:58:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.176.130 with HTTP; Thu, 30 Nov 2017 12:58:18 -0800 (PST) From: Logan Widick Date: Thu, 30 Nov 2017 14:58:18 -0600 Message-ID: To: ACME WG Content-Type: multipart/alternative; boundary="001a113ed55c01d83e055f398355" Archived-At: Subject: [Acme] Question about the new finalizeURL approach, and the order object format after finalizeURL 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, 30 Nov 2017 20:58:22 -0000 --001a113ed55c01d83e055f398355 Content-Type: text/plain; charset="UTF-8" In the new finalizeURL approach to orders, do order objects need to contain a CSR after a user attempted to finalize the order, or after the order is finalized? Would the CA have to store the CSR after it's posted, or after the certificate is issued? >From the text, I assume that the body of the finalizeURL is a POST containing an ACME JWS message whose payload is a JSON object with the "csr" field. Is that correct? What would this POST look like? I'm asking these questions because I haven't been able to find an example of the finalizeURL POST in the draft ( https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md), and because I see "csr" fields in some of the order objects. I've created a branch of my fork of the GitHub repository ( https://github.com/uhhhh2/acme/tree/remove-csr-fields-from-order-and-add-example-finalize-post) with my understanding of the new finalizeURL POST. Specifically, in this branch, I am assuming that the CSR is not stored as part of the order. I am also assuming that the finalizeURL POST is an ACME JWS message whose payload is a JSON object with the "csr" field (which is in the same base64url format it was in before finalizeURL was introduced). Am I understanding the finalizeURL correctly? Sincerely, Logan Widick --001a113ed55c01d83e055f398355 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In the new finalizeURL approach to orders, do order object= s need to contain a CSR after a user attempted to finalize the order, or af= ter the order is finalized? Would the CA have to store the CSR after it'= ;s posted, or after the certificate is issued?=C2=A0

Fro= m the text, I assume that the body of the finalizeURL is a POST containing = an ACME JWS message whose payload is a JSON object with the "csr"= field. Is that correct? What would this POST look like?

I'm asking these questions because I haven't been able to fi= nd an example of the finalizeURL POST in the draft (https://githu= b.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md), and becau= se I see "csr" fields in some of the order objects.=C2=A0

I've created a branch of my fork of the GitHub reposi= tory (https://github.com/uhhhh2/acme/tree/r= emove-csr-fields-from-order-and-add-example-finalize-post) with my unde= rstanding of the new finalizeURL POST. Specifically, in this branch, I am a= ssuming that the CSR is not stored as part of the order. I am also assuming= that the finalizeURL POST is an ACME JWS message whose payload is a JSON o= bject with the "csr" field (which is in the same base64url format= it was in before finalizeURL was introduced). Am I understanding the final= izeURL correctly?=C2=A0

Sincerely,=C2=A0

Logan Widick

--001a113ed55c01d83e055f398355-- From nobody Thu Nov 30 13:02: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 CFA411294D4 for ; Thu, 30 Nov 2017 13:01: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 f98me08W-kCI for ; Thu, 30 Nov 2017 13:01:56 -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 D7756126CBF for ; Thu, 30 Nov 2017 13:01:56 -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=gfW+TxXLkwJ6LZzYfw6kWYGODObqHmycHaC/MjSjM1w=; b=iM1n9kyYQQtPnwVYTaKWuB7WjQVG7wLlZArtpHsSRXDtR3krRp9DMDl7857OlAjvNHFx+mWPYp3PvJJ+iQjY1v/YlUx+kPFISikdjb3bWXVbQsEc6A3ws6w8eRmJModiKIv9qYXPEBIGW8I3nXAcAbGoD7IKwPE9dki/zRK/kmw=; Received: ; Thu, 30 Nov 2017 13:01:52 -0800 To: Logan Widick , ACME WG References: From: Jacob Hoffman-Andrews Message-ID: Date: Thu, 30 Nov 2017 13:01:56 -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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Acme] Question about the new finalizeURL approach, and the order object format after finalizeURL 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, 30 Nov 2017 21:01:58 -0000 On 11/30/2017 12:58 PM, Logan Widick wrote: > In the new finalizeURL approach to orders, do order objects need to > contain a CSR after a user attempted to finalize the order, or after > the order is finalized? Would the CA have to store the CSR after it's > posted, or after the certificate is issued? Good question. Previously, we expected that the CA had to store the CSR because it would need the public key in order to issue. With finalizeURL, we can get rid of that requirement. CAs are required to record CSRs in their audit logs, but there is no formal requirement to keep them in an online database. So my preference would be to remove the "csr" field from order objects, since it doesn't serve any purpose. Other thoughts? From nobody Thu Nov 30 14:25:50 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E76C12711B for ; Thu, 30 Nov 2017 14:25:49 -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 MIL8aIOBMxvH for ; Thu, 30 Nov 2017 14:25:46 -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 AAF0C127010 for ; Thu, 30 Nov 2017 14:25:46 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id q15so9250374ioh.2 for ; Thu, 30 Nov 2017 14:25:46 -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=M3TMTUQxSNM3facwGFbsvRWUA8vZi9RxXZqYPtbl3Aw=; b=bnL8vI9Pf2M3Y4+s7Wc6YvJ9J3rDo3VOJNojooOOvHXXNR5edanqPZXLMAYBK5PZHI 2V/k2Y2l1fM09aOfTSd3q0SPdrZ5Txg7q8ltPdb0QPloquug9Qo+A4qtCio4uL+yHwq1 0OC88Xd4kU+TId0DjKtj9lJ0VSsaXZoPEjVjE= 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=M3TMTUQxSNM3facwGFbsvRWUA8vZi9RxXZqYPtbl3Aw=; b=KFpfrmaHhHoBMxtdJqm57u6deuuxjmaubXYfllcpd9Kv9Pacn9QjzxMc4DdmH4zdWj mEpdG77Yro6EZegOhTq5TrjzQKGbKHcGpSYaGrWfC3SWskQgGL7/fL2BD3Kf2NEkirmv 6zEsVsndup4aiy21/qeo/9V/iUPvrh+iDtt0g1YBuyUBWQJ9i9ZsIAw5mPHHwOGk9vbH W/wtD6Geh/3a1g7MTqcVWL2fUyn1fsBLZ2ykoBhtp5z9wKZqvNYgwfjGR6ihNR7mohgv xVSA8sQdz7c6ep9zAZOzhoE8tngsE/lCPkmZXS3y2Pfy0YjbPEHHIan8ic9u201pyvXq 0J9w== X-Gm-Message-State: AKGB3mIVBKwRNi8tNf+/Wd+Ggv62cyQQo2fP9FWMuQr5k33GW8YnnI8k 9ARWerq08l+q3SckypJYqDUQ4z7yowfdDWbyhvwqkA== X-Google-Smtp-Source: AGs4zMYuVcONh7e/5/N8cv4RpsmVvXlz/0FRQkF6I23QeTRjWX4Hlft7CPCRGAcGXJCAHl+cHjEbzwMBBF9UPVcAj34= X-Received: by 10.107.37.139 with SMTP id l133mr1700127iol.89.1512080745965; Thu, 30 Nov 2017 14:25:45 -0800 (PST) MIME-Version: 1.0 Reply-To: cpu@letsencrypt.org Received: by 10.107.17.28 with HTTP; Thu, 30 Nov 2017 14:25:45 -0800 (PST) In-Reply-To: References: From: Daniel McCarney Date: Thu, 30 Nov 2017 17:25:45 -0500 Message-ID: To: Jacob Hoffman-Andrews Cc: Logan Widick , ACME WG Content-Type: multipart/alternative; boundary="001a11405dfebc428b055f3abbf6" Archived-At: Subject: Re: [Acme] Question about the new finalizeURL approach, and the order object format after finalizeURL 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, 30 Nov 2017 22:25:49 -0000 --001a11405dfebc428b055f3abbf6 Content-Type: text/plain; charset="UTF-8" > > So my preference would be to remove the "csr" field from order objects, > since it doesn't serve any purpose. I agree. I don't think it makes sense to echo it back to the client that sent it. +1 to removing. On Thu, Nov 30, 2017 at 4:01 PM, Jacob Hoffman-Andrews wrote: > On 11/30/2017 12:58 PM, Logan Widick wrote: > > In the new finalizeURL approach to orders, do order objects need to > > contain a CSR after a user attempted to finalize the order, or after > > the order is finalized? Would the CA have to store the CSR after it's > > posted, or after the certificate is issued? > Good question. Previously, we expected that the CA had to store the CSR > because it would need the public key in order to issue. With > finalizeURL, we can get rid of that requirement. CAs are required to > record CSRs in their audit logs, but there is no formal requirement to > keep them in an online database. So my preference would be to remove the > "csr" field from order objects, since it doesn't serve any purpose. > > Other thoughts? > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --001a11405dfebc428b055f3abbf6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0So my preference would be to remove the=C2= =A0"csr" field from order= objects, since it doesn't serve any purpose.
<= br>I agree. I don't think it makes sense to echo it back to the client = that sent it. +1 to removing.

On Thu, Nov 30, 2017 at 4:01 PM, Jacob Hoffman-Andr= ews <jsha@eff.org> wrote:
On 11/30/2017 12:58 PM, Logan Widick wrote:
> In the new finalizeURL approach to orders, do order objects need to > contain a CSR after a user attempted to finalize the order, or after > the order is finalized? Would the CA have to store the CSR after it= 9;s
> posted, or after the certificate is issued?
Good question. Previously, we expected that the CA had to store the = CSR
because it would need the public key in order to issue. With
finalizeURL, we can get rid of that requirement. CAs are required to
record CSRs in their audit logs, but there is no formal requirement to
keep them in an online database. So my preference would be to remove the "csr" field from order objects, since it doesn't serve any pu= rpose.

Other thoughts?

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

--001a11405dfebc428b055f3abbf6-- From nobody Thu Nov 30 14:34:30 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D54912952E for ; Thu, 30 Nov 2017 14:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 969AFmKqYzY1 for ; Thu, 30 Nov 2017 14:34:27 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B3D1129503 for ; Thu, 30 Nov 2017 14:34:22 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id g75so470981wme.0 for ; Thu, 30 Nov 2017 14:34:22 -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=vBzmC/6gw3iexXjODFDLNY5I4zLHNEYdkEeMZWBqVwg=; b=Po+SbhjkDYRzAblwdUK6D+vgqhFBOcmznYF74sc/xtqZoJz36BiZGBHWitVd3P++ZT VZ1y3Cg2j1l7x7ap1FKKK9CU2p78G9WmhvaVofhEYtMu1+Gdxte7YS3H4+OZC4ZLmCKj uNeb910+UDAKLoZTTt7vYJXkodmqsfeO9whw2ENKeGETrv0dMX/YpyArh9xkpo4eULxc FTM7egu9UTsA20IOJEcPIIv+fKqgCRmuXiDjSMYLlns9MUaCmOHRjMZn7+hAUySVXRcJ AdxJFu7bRB9ZbLb7FQT+CpreUMxqVD7Wvh4s/f1PwJF7DJtuLJ76z4iLvpCj0nzBihkI baVA== 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=vBzmC/6gw3iexXjODFDLNY5I4zLHNEYdkEeMZWBqVwg=; b=kTVvu3KTizMkHLPdIgSpLeslNGJ3UKEqsCEN+a3k78xWsEAcrz02AgrRM2bCUGIVBP l74csAbYo89Rcbxf8+9VKOnzUKlfs5WgGx8s+317Pf1WZi/b35wQiRrfQbozwVy76NF4 nM3bjaVQkcSWq2ql+Jp8Ya5NXEgO2XOJzVLpzAYJbOURucklqZ9XaQTR8VwkdIqklB7O b4s8qC9YA2kx3YlzFR98giF1N/d7t6ernuJw+k26qlKDBnDHjmf/r0bHLAn0Sw+XVIng 5v5E44S5Zuu/DAZhpRwBiRdMb3NBHGoZWjruvaGEDSevYYzHw98oodqCNu9FZ8eamKdv Mcig== X-Gm-Message-State: AKGB3mKUUYxxCSSX5PmwouInkhGC/EgRSrmqKTTAvE4Da9TZuwob+Jqj d82I5F+fgSLf+x2GyNWXPinl5yXO7Bf9N6pKdgnX3Q== X-Google-Smtp-Source: AGs4zMY/DK0gbBt8MgkKsqJqLYmMXKXMb6TkoEuy5r5k0ds1Oy8Ei6bEvLNiBzFIEP1pze6DlN2EqV7jdjG0Xq+clHE= X-Received: by 10.28.127.197 with SMTP id a188mr3143380wmd.138.1512081260450; Thu, 30 Nov 2017 14:34:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.167.74 with HTTP; Thu, 30 Nov 2017 14:34:19 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Thu, 30 Nov 2017 17:34:20 -0500 Message-ID: To: Daniel McCarney Cc: Jacob Hoffman-Andrews , Logan Widick , ACME WG Content-Type: multipart/alternative; boundary="001a11423e8e66ac4d055f3adaa3" Archived-At: Subject: Re: [Acme] Question about the new finalizeURL approach, and the order object format after finalizeURL 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, 30 Nov 2017 22:34:29 -0000 --001a11423e8e66ac4d055f3adaa3 Content-Type: text/plain; charset="UTF-8" I would like to keep it around. Part of the idea of the order and authorization objects is to provide some possibility of accounting for how a certificate was issued. Removing the "csr" would remove some of that transparency. As Jacob points out, CAs are already required to keep around CSRs in audit logs. On Thu, Nov 30, 2017 at 5:25 PM, Daniel McCarney wrote: > So my preference would be to remove the "csr" field from order objects, >> since it doesn't serve any purpose. > > > I agree. I don't think it makes sense to echo it back to the client that > sent it. +1 to removing. > > On Thu, Nov 30, 2017 at 4:01 PM, Jacob Hoffman-Andrews > wrote: > >> On 11/30/2017 12:58 PM, Logan Widick wrote: >> > In the new finalizeURL approach to orders, do order objects need to >> > contain a CSR after a user attempted to finalize the order, or after >> > the order is finalized? Would the CA have to store the CSR after it's >> > posted, or after the certificate is issued? >> Good question. Previously, we expected that the CA had to store the CSR >> because it would need the public key in order to issue. With >> finalizeURL, we can get rid of that requirement. CAs are required to >> record CSRs in their audit logs, but there is no formal requirement to >> keep them in an online database. So my preference would be to remove the >> "csr" field from order objects, since it doesn't serve any purpose. >> >> Other thoughts? >> >> _______________________________________________ >> 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 > > --001a11423e8e66ac4d055f3adaa3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would like to keep it around.=C2=A0 Part of the ide= a of the order and authorization objects is to provide some possibility of = accounting for how a certificate was issued.=C2=A0 Removing the "csr&q= uot; would remove some of that transparency.

As Ja= cob points out, CAs are already required to keep around CSRs in audit logs.=

O= n Thu, Nov 30, 2017 at 5:25 PM, Daniel McCarney <cpu@letsencrypt.org= > wrote:
=C2=A0So my preference would be to remove the=C2=A0"csr" field from order obje= cts, since it doesn't serve any purpose.

I agree. I don't think it makes sense to echo it back to the clien= t that sent it. +1 to removing.

On Thu, N= ov 30, 2017 at 4:01 PM, Jacob Hoffman-Andrews <jsha@eff.org> wrot= e:
On 11/30/2017 12:58 PM, Logan Wi= dick wrote:
> In the new finalizeURL approach to orders, do order objects need to > contain a CSR after a user attempted to finalize the order, or after > the order is finalized? Would the CA have to store the CSR after it= 9;s
> posted, or after the certificate is issued?
Good question. Previously, we expected that the CA had to store the = CSR
because it would need the public key in order to issue. With
finalizeURL, we can get rid of that requirement. CAs are required to
record CSRs in their audit logs, but there is no formal requirement to
keep them in an online database. So my preference would be to remove the "csr" field from order objects, since it doesn't serve any pu= rpose.

Other thoughts?

_______________________________________________
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


--001a11423e8e66ac4d055f3adaa3-- From nobody Thu Nov 30 14:43: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 9A5E4127010 for ; Thu, 30 Nov 2017 14:43:50 -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 k54qezhuz2Cq for ; Thu, 30 Nov 2017 14:43: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 84A25124205 for ; Thu, 30 Nov 2017 14:43: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:Cc:To:Subject; bh=nGwFuKFGtd+B8Ffk6LZeyfGM/OGHSM0KANXZGumnxFg=; b=o5PC0UGSW7zZWffNVR7klmPHVAf3npsj4Ciiv28BA75KWYMVsjqDfxGyMA/cKYbNJwqKgpHYp6FvZTX+DhWVleXukhkpTaW2UeefjoZ3JXGzyLHVwfKR5pMTJhf+LRraalbQLA54ARCuxxLijqJugpDd24ujf8YczLNK9vdJE4Y=; Received: ; Thu, 30 Nov 2017 14:43:32 -0800 To: Richard Barnes , Daniel McCarney Cc: Logan Widick , ACME WG References: From: Jacob Hoffman-Andrews Message-ID: <9ee4ba58-0b63-b388-07de-157d0093ebd3@eff.org> Date: Thu, 30 Nov 2017 14:43:36 -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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Acme] Question about the new finalizeURL approach, and the order object format after finalizeURL 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, 30 Nov 2017 22:43:50 -0000 On 11/30/2017 02:34 PM, Richard Barnes wrote: > As Jacob points out, CAs are already required to keep around CSRs in > audit logs. You missed an important nuance: CAs are not required to keep around CSRs in an online database for live querying on the web. It is much more expensive to store a CSR in a performant database than a rarely-accessed log. From nobody Thu Nov 30 14:53:49 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C22127010 for ; Thu, 30 Nov 2017 14:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 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, RCVD_IN_MSPIKE_H2=-2.8, 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=digicert.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 T7L_MCNdiD7v for ; Thu, 30 Nov 2017 14:53:46 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.15]) (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 AF06D12009C for ; Thu, 30 Nov 2017 14:53:46 -0800 (PST) Received: from [216.82.249.212] by server-15.bemta-12.messagelabs.com id EE/B3-12629-9FB802A5; Thu, 30 Nov 2017 22:53:45 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTf0xTVxTHe997fX0YHlxfQc4qCqszMhMa0Bl riBGJxsaERWLiH0gyX+WNNvQXfdWgyaT+WFSqRIIitDjEH3N2/hbRmrExcHOyJdNi/IGRzUAk VKuOyVSYbn29+Ou/zz3f7zn3nJtzOVqIsjpOqvRIbodo07MTmFuZrXOyR3yZxTlbgkZjcLDIe PWhxth4/QVr7N81Qhn31MzPV5seDQ+qTSH/XY3p0KEXlKnutJ8xBRv/YJepi9VWh9lZuUptGd o7yrh8BZX9J/ysF3UtqEYTOAY/puBo8LxGOQi4joL2nj6aHC4h6K7rYqpRAsfiHLjRfpmqRhy Xgp3QUpughGlcAJdOhSmFtbFwqPtlnFOwCzra/mQJfwrPA8MahRk8HaI7zqgV5nEJnBrpiJcX 8HcU3I8sVjgB58HBvpdxP8KT4Fn3MYrclQa9A81xBpwC9679yhJOhaH+V2rCGRDuva0hPAXCz T6kzAK4UwN3bo+NJxjgXG0UKbMALoSnwzzxfI3gl0g7Q+IzoXa0iNjL4VXrwfHUPNjcNsgSfx cNLZF6hgjpsP+4jybCP2rY2vNwfLJS2B3sZMk0JbDvb8JarIO717ejXehj/zvD+WP5NG5G8O3 hAOWPv9JEuNI4wBBTNlz8voMmnAHno03jnAcNoz+yhD+E3b57GsJz4MFPf6H9iAuiLFlyr5Xc 2bNzDGa3tczisYtWW3Zu7iyDXZJlsUyyiWbZsNppP4NiS1elUqELaOy/wk70AUfpU/nwisxiI cnsLF1nEWXLZ+41NknuROkcpwdeiC2nMNEtlUmVn1ttsc19LQOXqE/hj1bHZF52iXbZWkakbj Sba2rv/Zfi7jc+8NIC43A6JF0af1axYsVqWeN4U+j1LwijKTotj1QqlZDoktx2q+d9PYLSOKT X8uuVKolWh+fNfZFYK1SsFeuRDKUVj/hW0nmRP+nG2i/Lq9j8eZ9sWlL7+xNKV7Nu6fqti0uc h0cGelqTuw588yh9e9uMSc8sRamBsMG3sd5bnkwNhaZVoIWlVxK3ZC3X3+lrqal5frJ+72/JS ZejTbnU1c2Tb5q1G4rm/tzkda0cq1jUEPhiRUXVD6GdDQX9F1Pz528TvsqyBKZ+FFLpGdki5s 6k3bL4P566LEwABAAA X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-9.tower-219.messagelabs.com!1512082421!195875678!1 X-Originating-IP: [216.32.180.53] X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11721 invoked from network); 30 Nov 2017 22:53:41 -0000 Received: from mail-by2nam03lp0053.outbound.protection.outlook.com (HELO NAM03-BY2-obe.outbound.protection.outlook.com) (216.32.180.53) by server-9.tower-219.messagelabs.com with AES256-SHA256 encrypted SMTP; 30 Nov 2017 22:53:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pKIvgeUEt1cqIkDf1F1qdQj/RZlgN05kAIzhpHOkKqE=; b=rzHn3xEw1CjbdxeirC1HLumiIC/0gmHv6QOw7l5nmNrgKYf5VkD6/BcRyUyF4243v4+RtsgKXQV/GOEClP2gUsu0zREMvlaCa+wfhiuruRgpdIddN/53jO3hiMxi0Nk/gy5frxkz/QuNs2Xg8yggO5hNN/m2YeNAtABNiQd9u4M= Received: from DM5PR14MB1289.namprd14.prod.outlook.com (10.173.132.19) by DM5PR14MB1290.namprd14.prod.outlook.com (10.173.132.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.5; Thu, 30 Nov 2017 22:53:39 +0000 Received: from DM5PR14MB1289.namprd14.prod.outlook.com ([10.173.132.19]) by DM5PR14MB1289.namprd14.prod.outlook.com ([10.173.132.19]) with mapi id 15.20.0282.006; Thu, 30 Nov 2017 22:53:39 +0000 From: Tim Hollebeek To: Jacob Hoffman-Andrews , Richard Barnes , "Daniel McCarney" CC: Logan Widick , ACME WG Thread-Topic: [Acme] Question about the new finalizeURL approach, and the order object format after finalizeURL Thread-Index: AQHTah3/iqSb2epgtkKxiB6gTxNxmqMtaK0AgAAXa4CAAAJlAIAAApcAgAAAOOA= Date: Thu, 30 Nov 2017 22:53:39 +0000 Message-ID: References: <9ee4ba58-0b63-b388-07de-157d0093ebd3@eff.org> In-Reply-To: <9ee4ba58-0b63-b388-07de-157d0093ebd3@eff.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [67.137.52.8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR14MB1290; 6:k0e50WXx1iMYgDnpQ05fb851tikKx/lu0LkKda5YwzRqaErCWszyAHM5mnL01jFUdlCH8fNi2XAR6tWpiKCpt4bIe2WDQEb35Q0V0pdgjZuQIw87bXlD+Q9YaED46w+itVcDPb9gIt8aDxXKto1WyC0W153FG4ne0+eAfMXCLhfRwI6YQ4epi9aB9TtdlGbxwgBH45qJhrUfCtCOuGmHzLStYRIxzMPOOvFbM5JAxuXtHwYqV/TOpg7qPXsByWu+kkNMl3MTewhx0vj5C487uZ7m5i4tQvn2+HIWCVRX4am9PLt+QyvkDUYf/0EDyW0BGaBKc1WjKoc1l9kRmDbvDZRLi3tkMA1mRoDKsLHQufw=; 5:KLmK0PgmR5GIFraGvYVvnmxzCF4zqh9ZplxOTu9fI6uiqtzGRAQ+ulKw7QlbXX306aPlJvsACFgqsh1fWULb11CxCNAc0w2VyOGK77udv9Or4bgRaFfNIvV1ECeG+digX3OwrdhRzF//B1RzR47TmeXRsrWJ6pyAs9ggDfHa4xg=; 24:I4LUD0Pv2XjrtKdjFKkHIs7ZOehJ4Jw8UuOM/xfLYXcxrhfjsB7zAeHF10v3xL2jL0DjOffEwv1CGli1e8UOMUY2nat6GL1ONLWicIEmkTU=; 7:yqYdyUnsJ+py6a8f0KFim7XjPYfDXm6xRwCql26oz2zUsKhtj/h5aaYn0sBfPYJwnb3/z81s4nEbGZXbmbBTjx+WGP4J3oiP2hKykw6k6ZUCIfxoY77KH9jkMH+FI/pGmy35DdkphM9iZrKHQ6/jTr6BMMpSMyuV194PyXQh2P9G8T0+q9FRPibVGVo4gNMKZqPN6IwnzaXS56OKuLVGDvwdY6aJsieQv+mko5Z6ZgPf8Bt5DOykzSrlwE8ZsXj5 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 17c21ae6-572a-43cc-b672-08d53845328f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4603075)(4627115)(201702281549075)(5600026)(4604075)(2017052603286)(49563074); SRVR:DM5PR14MB1290; x-ms-traffictypediagnostic: DM5PR14MB1290: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(209352067349851); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(8121501046)(5005006)(3002001)(3231022)(10201501046)(93006095)(93001095)(6041248)(2016111802025)(20161123560025)(20161123558100)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6043046)(6072148)(201708071742011); SRVR:DM5PR14MB1290; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR14MB1290; x-forefront-prvs: 05079D8470 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(366004)(199003)(189002)(13464003)(24454002)(86362001)(99936001)(3280700002)(3660700001)(2906002)(105586002)(106356001)(33656002)(101416001)(66066001)(6436002)(966005)(77096006)(6506006)(55016002)(53936002)(9686003)(6306002)(316002)(99286004)(189998001)(229853002)(14454004)(7736002)(74316002)(305945005)(53546010)(110136005)(54906003)(478600001)(93886005)(4326008)(39060400002)(6246003)(81156014)(81166006)(8676002)(8936002)(7696005)(68736007)(54356011)(2900100001)(25786009)(6116002)(102836003)(3846002)(2950100002)(97736004)(5660300001)(76176011); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR14MB1290; H:DM5PR14MB1289.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0390_01D369F3.62BAE020" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 17c21ae6-572a-43cc-b672-08d53845328f X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2017 22:53:39.3564 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR14MB1290 Archived-At: Subject: Re: [Acme] Question about the new finalizeURL approach, and the order object format after finalizeURL 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, 30 Nov 2017 22:53:48 -0000 ------=_NextPart_000_0390_01D369F3.62BAE020 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit My recollection from various CA/Browser discussions is that CAs are *not* actually required to keep around CSRs. Am I wrong? Most CAs do, because it is the easiest way to log proof of possession of the private key, and because it is useful for a variety of other auditing activities, but other methods are possible, in principle. In fact, I'm struggling to even find that requirement --- 3.2.1 is empty in the latest copy of the BRs. CSRs are only mentioned in an obscure footnote about potential methods for calculating Request Tokens. -Tim -----Original Message----- From: Acme [mailto:acme-bounces@ietf.org] On Behalf Of Jacob Hoffman-Andrews Sent: Thursday, November 30, 2017 3:44 PM To: Richard Barnes ; Daniel McCarney Cc: Logan Widick ; ACME WG Subject: Re: [Acme] Question about the new finalizeURL approach, and the order object format after finalizeURL On 11/30/2017 02:34 PM, Richard Barnes wrote: > As Jacob points out, CAs are already required to keep around CSRs in > audit logs. You missed an important nuance: CAs are not required to keep around CSRs in an online database for live querying on the web. It is much more expensive to store a CSR in a performant database than a rarely-accessed log. _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme ------=_NextPart_000_0390_01D369F3.62BAE020 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTcxMTMwMjI1MzM3WjAvBgkqhkiG9w0BCQQxIgQg1I+4H5S3gCStyXTkkYIL0s0ZkYNL gru4XlZG6387XmkwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAAYnnXnUiwtC70nP+FiAJDkRMTYDSYzgKuqbLth0TcT40HBEfQDg77F4uABKmYZRPGl3mQAj zV5twtulMVgeo9ZMqlSDsvGSt50S38Id05cCexCIC7b1SSZBVOpm8/GQH4k8Q/cDb7PujlLpKFgJ hK9K31/0u7HkHJWsny6VlP5hTKDhT0dR81kcpiCcxZ1PXZWBcxD7HlZ6yuOckfTTtmbJ5b/KJ+zR OkO45sIhF97RWXf840vhS3DV+n3zRgKyM8OiHfGH0A9a1FSEMogxBI44xePOnjxO5s1ajw9BJA8I V0D/QRaLZLsRn3nUvtnFW3ZxziYcOa3JYQmEBrJEjLQAAAAAAAA= ------=_NextPart_000_0390_01D369F3.62BAE020-- From nobody Thu Nov 30 14:58:21 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97DA2126B6D for ; Thu, 30 Nov 2017 14:58:20 -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 W5s5tL-G-aRH for ; Thu, 30 Nov 2017 14:58:19 -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 AF8F812009C for ; Thu, 30 Nov 2017 14:58:19 -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=ew0vWutIgmy8PGyjT7JwzbvxkLNgVwXNtttzewP6Tmc=; b=rJ5L7fUgmVJw5TCnzvCqCZzu4GlbQUTVY+soHZg6UKM0s9aM+mtiUlw1xLOirO4MdUR5YLUXcwrXUH+WmijnG1n/nT0Xexv2WAscEE+psqK/tmccsjZC2Qiz3tvzJnHx3CQlVzfEz2e60IbAOSldjphsqh2ZVA4RtgG83HMvIj4=; Received: ; Thu, 30 Nov 2017 14:58:15 -0800 To: Tim Hollebeek , Richard Barnes , Daniel McCarney Cc: Logan Widick , ACME WG References: <9ee4ba58-0b63-b388-07de-157d0093ebd3@eff.org> From: Jacob Hoffman-Andrews Message-ID: <698d3172-c0bc-5c6e-a6a7-7afc0d54915c@eff.org> Date: Thu, 30 Nov 2017 14:58:18 -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: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Acme] Question about the new finalizeURL approach, and the order object format after finalizeURL 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, 30 Nov 2017 22:58:20 -0000 On 11/30/2017 02:53 PM, Tim Hollebeek wrote: > My recollection from various CA/Browser discussions is that CAs are *not* > actually required to keep around CSRs. Am I wrong? I may be misremembering. I thought they were required to log proof of the subscriber's possession of the private key, but you're right that 3.2.1 is empty. So, even more reason to not make this required! From nobody Thu Nov 30 15:08: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 00D53126B6D for ; Thu, 30 Nov 2017 15:08:03 -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, 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=andrewayer.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrSB-30s2wot for ; Thu, 30 Nov 2017 15:08:01 -0800 (PST) Received: from thompson.beanwood.com (thompson.beanwood.com [IPv6:2600:1f14:a46:c400:6107:163e:4681:134e]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E0DF12009C for ; Thu, 30 Nov 2017 15:08:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1512083280; bh=sUWBqGoMuVy30GJiR5c4MqESNw2/pKOvpUaOTAhJ+9o=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=DqvlIud2G5yIF6JnnVASMKy8JJyjpuiHQFK3BVYDSzr/2B8GwXm2bGtShzWL9PqI8 ZAGniRl71CR5xHtTdCxF5irOfYXq+JPdOWViiLezL930H0u89JhxfNgogFwPg8W2bE RMbiWVBU6EqYC53KFJPi/oj5GQBPczfeU9NZF0encXuoZhkFk/l5h+1TcOBL8J4X80 lOFGH9F6Mr/fOUinv1ZVokgBNV6z1LLcoN3hMPXfu/tHd3uPM8msIa0G4Fw93DAR+m cTdmSQcrne2ZEEjzpm5M0qUvvAQtfD/mcsAt06+RZELUDrBar0toMWEq11heYmzocT EbiT55hCc1g8A== Date: Thu, 30 Nov 2017 15:07:59 -0800 From: Andrew Ayer To: Jacob Hoffman-Andrews Cc: Clint Wilson , cpu@letsencrypt.org, "Salz, Rich" , IETF ACME Message-Id: <20171130150759.f92dc9a717e92296bf7356a1@andrewayer.name> In-Reply-To: <6c002b3f-8018-45f8-64dd-1bbb2d2918d2@eff.org> References: <0F612577-86CE-4E86-B95C-01C0FF82BDA7@akamai.com> <6c002b3f-8018-45f8-64dd-1bbb2d2918d2@eff.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Thu, 30 Nov 2017 23:08:03 -0000 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. >=20 > 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: > > > > >=C2=A0Daniel, 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?=C2=A0 If = so, please > > speak up before next Friday. > > > > =C2=A0 > > > > 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 >=20