Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR

From: Richard Barnes <[email-masked]>
Date: Wed, 1 Nov 2017 12:13:58 -0400

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 <[email-masked]>
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 <[email-masked]> wrote:
>
>>
>>
>> On Mon, Oct 30, 2017 at 10:15 AM, Daniel McCarney <[email-masked]>
>> 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 <
>>> [email-masked]> 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
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/acme
>>>
>>>
>>
>

---

From: Brad Warren <[email-masked]>
Date: Wed, 1 Nov 2017 15:12:01 -0700

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:
> 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,
> 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.
>
> <https://github.com/ietf-wg-acme/acme/pull/342>
>
>
>
>
>
> On Mon, Oct 30, 2017 at 3:48 PM, Daniel McCarney <[email-masked]
> <mailto:[email-masked]>> 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 <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>
>
>         On Mon, Oct 30, 2017 at 10:15 AM, Daniel McCarney
>         <[email-masked] <mailto:[email-masked]>> 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.
>
>             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.
>
>             On Tue, Oct 24, 2017 at 10:17 AM, Ilari Liusvaara
>             <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>                 > order flow in the first place was to provide more
>                 flexibility for CAs to
>                 > institute policy.
>
>             [email-masked] <mailto:[email-masked]>
>             <https://www.ietf.org/mailman/listinfo/acme>
>
>
>
>
>
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 1 Nov 2017 22:10:07 -0400

On Wed, Nov 1, 2017 at 6:12 PM, Brad Warren <[email-masked]> wrote:

> 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.
>
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 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
>>>>> > order flow in the first place was to provide more flexibility for
>>>>> CAs to
>>>>> > institute policy.
>>>>>
> Acme mailing [email-masked]://www.ietf.org/mailman/listinfo/acme
>
>
>

---

From: Daniel McCarney <[email-masked]>
Date: Thu, 2 Nov 2017 09:51:07 -0400

>
> 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

---

From: Richard Barnes <[email-masked]>
Date: Thu, 2 Nov 2017 10:15:44 -0400

On Thu, Nov 2, 2017 at 9:51 AM, Daniel McCarney <[email-masked]> wrote:

> * Client A creates an order with CSR_1, covering "example.com", using
> CPU's ACME   CA
> * Client A sends CSR_1 covering "example.com" to finalize their order.
> Oops - it's affected by RIVESTKEYBLEED and is rejected.
> 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

>> 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,
>>>>> Implementing that without knowing the public key at validation time
>>>>> is annoying.
>>>>>

---

From: Daniel McCarney <[email-masked]>
Date: Thu, 2 Nov 2017 10:29:58 -0400

>
> - 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 ]

> 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 <[email-masked]> wrote:

>> 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.
>>
>> * Client A sends CSR_1 again 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.
>>
> - 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
>>>> 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
>>>>> On Mon, Oct 30, 2017 at 10:15 AM, Daniel McCarney <[email-masked]
>>>>> > 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?
>>>>>
>>>>>
>>>>>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 2 Nov 2017 07:31:32 -0700

> verify that the second CSR is the same.  Since we should require that.

This seems like a great opportunity for defects.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 2 Nov 2017 18:18:33 +0200

> 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: Daniel McCarney <[email-masked]>
Date: Wed, 8 Nov 2017 09:05:16 -0500

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

---

From: Richard Barnes <[email-masked]>
Date: Thu, 9 Nov 2017 17:18:35 -0500

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 <[email-masked]> wrote:

>> 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.
>
>
> 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?
>
> [1] - https://mailarchive.ietf.org/arch/msg/acme/KEB3sLRswTT3m_X
> IbZSW52r3lxM/?qid=abcabbc372443fbe31c952558aa3392f
> On Thu, Nov 2, 2017 at 12:18 PM, Ilari Liusvaara <[email-masked]
> > wrote:
>

---

From: Daniel McCarney <[email-masked]>
Date: Fri, 10 Nov 2017 09:03:03 -0500

> 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 <[email-masked]> wrote:

>> 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
>> 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.
>>
>> 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.
>>
>> On Thu, Nov 2, 2017 at 12:18 PM, Ilari Liusvaara <

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 10 Nov 2017 17:13:06 +0200

> 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: Daniel McCarney <[email-masked]>
Date: Fri, 10 Nov 2017 10:42:05 -0500

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

---

From: Andriy Mahats <[email-masked]>
Date: Fri, 10 Nov 2017 21:06:07 +0000

Hi all

I am not responsing to latest message in thread currently (Daniels reply to Ilari) because it lost the content to which I would like to refer.

I would prefer the third approach suggested by Richard - authorizationFirst.
In that approach in case the authorizationFirst happened, the server can provide authorizations to be fulfilled
without binding them to some order – so no order is allocated at this step (just as it is in new-authz of v1).
Next, after client fulfilled the authorizations and places new-order then it can be issued (just like new-cert of v1)

In identifiers+CSR: the new-order would create an orderId and after that provide the client with links to authorizations to be fulfilled.

Personally I prefer the authorizationFirst. It is from one side simpler, more similar to v1 way and also seems to be less resource demanding on server.

Since identifiers+CSR approach would need to create/go through all authorizations on new-order step and later on finalization at once.
Also in cases when clients are unable to fulfill the order it will still stay in the db

Regards,
Andriy

From: Daniel McCarney [mailto:[email-masked]]
Sent: fredag 10. november 2017 15:03
To: Richard Barnes <[email-masked]>
Cc: Ilari Liusvaara <[email-masked]>; Brad Warren <[email-masked]>; Hugo Landau <[email-masked]>; IETF ACME <[email-masked]>
Subject: Re: [Acme] Revisiting Proactive Issuance & new-order CSR

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:

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 <[email-masked]<mailto:[email-masked]>> 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

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

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 <[email-masked]<mailto:[email-masked]>> 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/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 <[email-masked]<mailto:[email-masked]>> wrote:

-Ilari

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 13 Nov 2017 18:11:49 -0800

On 11/09/2017 02:18 PM, Richard Barnes wrote:
> (identifiers+CSR because of legacy issues; CSR+CSR because of
> fragility), here's one last attempt at a different approach:

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.