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

[Jacob Hoffman-Andrews]

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.

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

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

[Andriy Mahats]

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:c...@letsencrypt.org]
Sent: fredag 10. november 2017 15:03
To: Richard Barnes <r...@ipv.sx>
Cc: Ilari Liusvaara <ilariliusva...@welho.com>; Brad Warren <b...@eff.org>; 
Hugo Landau <hlan...@devever.net>; IETF ACME <acme@ietf.org>
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:

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 
<r...@ipv.sx<mailto:r...@ipv.sx>> 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 
<c...@letsencrypt.org<mailto:c...@letsencrypt.org>> wrote:

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

[Ilari Liusvaara]

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

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

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

[Daniel McCarney]

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

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

[Richard Barnes]

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 

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

[Daniel McCarney]

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
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Ilari Liusvaara]

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

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

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

[Eric Rescorla]

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 <
> ilariliusva...@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 

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

[Daniel McCarney]

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

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

[Richard Barnes]

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 

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

[Daniel McCarney]

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

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

[Richard Barnes]

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 <
 ilariliusva...@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 

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

[Brad Warren]

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

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

[Richard Barnes]

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 <
>>> ilariliusva...@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

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

[Daniel McCarney]

>
> 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 <
>> ilariliusva...@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

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

[Daniel McCarney]

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

Can you expand on "annoying"?

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

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

- cpu

On Tue, Oct 24, 2017 at 10:17 AM, Ilari Liusvaara 
wrote:

> On Tue, Oct 24, 2017 at 02:45:01PM +0100, Hugo Landau wrote:
> >
> > The ACME protocol should permit CAs to implement policy as far as is
> > reasonably practicable with regard to the workflows around which the
> > protocol is organised. Providing the CSR up-front allows the CA to
> > predicate order processing on aspects of that CSR, both with regard to
> > the present protocol and any future extensions, both now and in the
> > future in ways that we can and cannot foresee. I don't think it's
> > appropriate to defer giving critical information to the CA until the
> > last minute due to a resource utilisation concern which LE has already
> > proven capable of dealing with, especially when the whole point of the
> > order flow in the first place was to provide more flexibility for CAs to
> > institute policy.
>
> Example: Suppose that CAA-PKP got added (restrict issuance on SPKI
> key). Implementing that without knowing the public key at validation
> time is annoying.
>
> As to why one would want something like that, it would allow limiting
> trust on certficiate management system without deploying something as
> dangerous as HPKP.
>
>
>
> -Ilari
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Daniel McCarney]

Hi Hugo,

Providing the CSR up-front allows the CA to predicate order processing on
> aspects of that CSR, both with regard to the present protocol and any
> future extensions, both now and in the future in ways that we can and
> cannot foresee. I don't think it's appropriate to defer giving critical
> information to the CA until the last minute due to a resource utilisation
> concern which LE has already proven capable of dealing with


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

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

- cpu


On Tue, Oct 24, 2017 at 9:45 AM, Hugo Landau  wrote:

> My thoughts:
>
> - Requiring an explicit action against the order after the fulfilment of
> authorizations to cause issuance seems fine to me.
>
> - I think moving the submission of the CSR to the end of this process is
> a mistake.
>
> The ACME protocol should permit CAs to implement policy as far as is
> reasonably practicable with regard to the workflows around which the
> protocol is organised. Providing the CSR up-front allows the CA to
> predicate order processing on aspects of that CSR, both with regard to
> the present protocol and any future extensions, both now and in the
> future in ways that we can and cannot foresee. I don't think it's
> appropriate to defer giving critical information to the CA until the
> last minute due to a resource utilisation concern which LE has already
> proven capable of dealing with, especially when the whole point of the
> order flow in the first place was to provide more flexibility for CAs to
> institute policy.
>
> A possible compromise would be to require the CSR to be submitted both
> on new-order and on finalization, but that's quite clumsy.
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Ilari Liusvaara]

On Tue, Oct 24, 2017 at 05:17:32PM +0300, Ilari Liusvaara wrote:
> On Tue, Oct 24, 2017 at 02:45:01PM +0100, Hugo Landau wrote:
> > 
> > The ACME protocol should permit CAs to implement policy as far as is
> > reasonably practicable with regard to the workflows around which the
> > protocol is organised. Providing the CSR up-front allows the CA to
> > predicate order processing on aspects of that CSR, both with regard to
> > the present protocol and any future extensions, both now and in the
> > future in ways that we can and cannot foresee. I don't think it's
> > appropriate to defer giving critical information to the CA until the
> > last minute due to a resource utilisation concern which LE has already
> > proven capable of dealing with, especially when the whole point of the
> > order flow in the first place was to provide more flexibility for CAs to
> > institute policy.
> 
> Example: Suppose that CAA-PKP got added (restrict issuance on SPKI
> key). Implementing that without knowing the public key at validation
> time is annoying.
> 
> As to why one would want something like that, it would allow limiting
> trust on certficiate management system without deploying something as
> dangerous as HPKP.
> 

Specifically, this would be a top-level CAA property that is satisfied
by certificate request having SubjectPublicKeyInfo matching at least
one of the listed hashes.

The contents of property consist of one or more hash=hasval pairs,
where hash is a hash function (unknown ones are ignored) and hashval is
base64-encoded hash of the SPKI.

There is no max-age, as the restriction is not sticky and thus can be
replaced quickly if needed. It can be signed using DNSSEC as usual.

Example:

foo.example.net IN CAA 128 pin 
"sha256=AIPH49+A9F1e650YMzRPJG9OkBA0F24Mwa5ru5ZmsCo=,sha256=FmbTUrJD2lBK8H501MKenwkFg+639r/x6eZp22qUd/I="

This property is satisfied only by requests containing
SubjectPublicKeyInfo key with either SHA-256 hash of

0083c7e3df80f45d5eeb9d1833344f246f4e901034176e0cc1ae6bbb9666b02a or
1666d352b243da504af07e74d4c29e9f090583eeb7f6bff1e9e669db6a9477f2.


The usecase is as follows:

Suppose certificate management system runs with the least authority.
If it  gets compromised, the attacker can not aquire the private keys.
However, he can abuse its authority to solve challenges for his own
keypairs. The end result is attacker getting  maliscous certificates
he controls the private key for. The account keypair does not help,
since it can be abused too.

However, if the public keys one can get certificates are restricted,
the attacker can not aquire useful certificates, as he can not
specify his own keypairs for the certifciate, nor get the private key
for any of the whitelisted keypairs.

Similar attacks could be also mounted on some other least-authority
components of the whole system, components that could be at even
higher risk of compromise.


The current solution to this usecase is the HPKP. However, HPKP is
known to be difficult to deploy, quite of a footgun and worst of all
is being deprecated. Expect-CT will not even begin to solve it. A
partial solution would be to use CAA to restrict issuance to CAs that
either do not support automation, or support "vanity CAAs" with
corresponding restrictions.


-Ilari

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

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

[Ilari Liusvaara]

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

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

[Hugo Landau]

My thoughts:

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

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

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

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

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

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

[Daniel McCarney]

Hi again,

Richard: Do you have any subsequent thoughts now that Roland and myself
have given feedback on your proposed changes and why we still prefer the
suggestions I made initially?

Andrew's original support of proactive issuance was the most constructive
vote for why that behaviour was preferred during the initial discussion
period. Given that his support is now withdrawn and Roland and Jacob have
voiced support for my proposal I feel like we are approaching consensus.
There has not been any arguments made for the benefit of proactive issuance.

Boulder is beginning implementation of my proposed specification update and
I feel the best way to minimize Rich Salz's concerns about cycle disruption
is to resolve this thread quickly.

Thanks all,

On Tue, Sep 26, 2017 at 1:34 PM, Andrew Ayer  wrote:

> FWIW, I previously expressed support for proactive issuance because
> I thought it would lay the groundwork for a better renewal process,
> especially for short-lived certificates.  However, this idea never
> gained traction and the other necessary bits weren't added.  Instead,
> STAR seems to be handling this use case.
>
> Therefore, I no longer see a compelling reason for proactive issuance.
> If it's causing problems it should be removed.  I also agree with Roland
> that issuing upon an unauthenticated GET request is a bad idea.
>
> Regards,
> Andrew
>
> ___
> 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

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

[Andrew Ayer]

FWIW, I previously expressed support for proactive issuance because 
I thought it would lay the groundwork for a better renewal process,
especially for short-lived certificates.  However, this idea never
gained traction and the other necessary bits weren't added.  Instead,
STAR seems to be handling this use case.

Therefore, I no longer see a compelling reason for proactive issuance.
If it's causing problems it should be removed.  I also agree with Roland
that issuing upon an unauthenticated GET request is a bad idea.

Regards,
Andrew

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

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

[Daniel McCarney]

I've proposed a first cut at implementing the changes I described in my
original post as an ACME PR https://github.com/ietf-wg-acme/acme/pull/342



On Fri, Sep 22, 2017 at 7:19 PM, Roland Bracewell Shoemaker <
rol...@letsencrypt.org> wrote:

> Broad points:
>
> I understand that this group has been moving towards standardization for
> a while but I really think that attempting to fix these issues with
> creative readings of the existing language and minimal editorial changes
> is asking for trouble and return trips to the WG in the future when
> these band-aids turn out to not be fully thought out or themselves
> introduce new problems.
>
> These issues have come up during, as far as I'm aware, the only full-fat
> implementation of the current version of this specification and that
> implementation itself is maybe only 40-50% done. Assuming that these
> will be the only issues that are discovered seems to be, again, asking
> for trouble.
>
> Comments on the proposed fixes:
>
> 1. Causing issuance really seems like it should be required to be an
> authorized action, allowing this to happen by a GET allows anyone who is
> able to determine the order URL to cause issuance to happen.
> Implementing this behavior, even if not explicitly defined in the
> specification, will almost definitely lead to users relying on it
> (Hyrum's Law) which again will be a problem if another user is able to
> simply send of a handful of GETs and cause another users certificate to
> be issued.
>
> 2. Unless another implementer comes along this would mean that the only
> existing implementation of the current specification before
> standardization would not be implementing a major section of this
> document. At this point why not just go back to the -03/-04 draft
> new-authz flow. As Daniel has already pointed out this also completely
> breaks one of the major reasons to use the new-order flow: policy based
> authorization creation. How would a CA indicate that a user _may not_
> need an authorization for www.example.com when issuing for example.com
> or that they require a specific set of authorizations when issuing for
> *.example.com?
>
> Like I said at the start these band-aid editorial fixes seem to just
> create another set of problems that cannot themselves be solved with
> further minor editorial  changes.
>
> On 09/21/2017 11:40 AM, Richard Barnes wrote:
> > I talked a bit with Daniel about this off-list. Here's a summary of
> > where we got to:
> >
> > 1. In the current "new-order" flow, the server doesn't *really* have to
> > be proactive -- instead of updating an order object when an authz
> > changes state, it can wait to update/issue until the client polls for
> > the order object, indicating that it's actually interested in having a
> > certificate.  That doesn't alleviate the pain of storing the CSR, but it
> > at least avoids the expense of finding affected orders and issuing in
> > cases where the client abandons the order.  If we think this approach is
> > OK, I would propose that we revise the document to make clear that it is
> > OK.  What do folks think?  Daniel noted that there might be some issues
> > with GET idempotency here, but I don't think this actually makes GET
> > non-idempotent.
> >
> > 2. Some CAs might want to support only the "new-authz" flow, i.e., never
> > allow a "new-order" request if the relevant authorizations haven't
> > already been done.  It seems like this could be addressed in a pretty
> > straightforward manner just by defining a new error code (say
> > "preauthRequired") that the server can return in this case.
> >
> > Personally, it seems to me that if we make the clarification (1) and add
> > the error code (2) described here, that would address the pain points
> > Daniel raises, without a whole lot of new mechanism.  I'm not really
> > seeing much additional value to be had from an explicit "ok issue now"
> > request (vs. the GET poll).
> >
> > --Richard
> >
> >
> >
> > On Wed, Sep 20, 2017 at 1:22 PM, Richard Barnes  > > wrote:
> >
> > Hey Daniel,
> >
> > Thanks for the input.  I can see why you might be feeling some pain
> > here, but I'm not sure the proposed solution is quite right.
> >
> > Note that ACME already has the "new-authorization" flow, which does
> > pretty much exactly what you're proposing.  The only difference is
> > that instead of authorizations being created all at once in response
> > to a "new-cert" request, they're created individually by the
> > client.  But it's ultimately the same number of RTTs (authz fetch ~
> > new-authz) -- or rather, one fewer in the new-authz case because
> > there's no new-cert request.  To what degree would your problem be
> > solved simply by having the affected integrators move over to that
> flow?
> >
> > I can sympathize that the new-order flow might not be suitable for
> > all use cases.  Maybe it would be useful to write down some 

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

[Daniel McCarney]

RE: #1 - this does help, but will require changing the spec to clarify. The
current wording does not support this behaviour and cleary indicates the
server MUST issue for any order that has been satisfied.

RE: #2 - a CA relying on the new-authz flow to avoid the cost of accepting
a CSR up front would never be able to use the new-order flow to give the
client authorizations they didn't ask for or they are back to accepting
CSRs for orders that may never complete. That's why we need a new error to
return to reject new-order requests that aren't fully pre-authorized. If
the largest ACME CAs will not implement new-order as described outside of
pre-authorization why have it at all? Who will implement it?

The primary failing of #2 is that it causes those CAs to lose one
substantial benefit to the new-order flow that I would like to keep:
allowing for policy-based decisions on the CA side to influence which
authorizations are required. Without this property we will further have to
update the specification for wildcard issuance. The current spec doesn't
permit asking for authorizations for wildcard identifiers with new-authz so
you'd need some way of asking the server for a wildcard identifier and have
it respond with an authorization for something completely different (An
authorization for some wildcard resource say with a  DNS-01 challenge for
the base domain).

I agree that this is a late change but we are nearing the last chance we
have to address what I see as a fairly significant point of complication in
the protocol.  I note that no one has proposed any reasons why proactive
issuance must remain since this thread was restarted except that it is the
status-quo and we want to minimize change.

I am not in favour of the suggestions from Richard so far and would like to
hear more about why my proposal is not suitable. Richard's changes are
smaller but leave protocol complication and prevent large CAs from enjoying
the benefits of the new-order flow. My proposal addresses the problems and
leaves a simpler protocol without features that will not be used by large
providers.

We have to change the specification no matter whether my proposals or
Richards are taken so why not make changes that will result in the clearest
protocol with the least amount of cruft few are likely to implement?

- Daniel





On Thu, Sep 21, 2017 at 2:40 PM, Richard Barnes  wrote:

> I talked a bit with Daniel about this off-list. Here's a summary of where
> we got to:
>
> 1. In the current "new-order" flow, the server doesn't *really* have to be
> proactive -- instead of updating an order object when an authz changes
> state, it can wait to update/issue until the client polls for the order
> object, indicating that it's actually interested in having a certificate.
> That doesn't alleviate the pain of storing the CSR, but it at least avoids
> the expense of finding affected orders and issuing in cases where the
> client abandons the order.  If we think this approach is OK, I would
> propose that we revise the document to make clear that it is OK.  What do
> folks think?  Daniel noted that there might be some issues with GET
> idempotency here, but I don't think this actually makes GET non-idempotent.
>
> 2. Some CAs might want to support only the "new-authz" flow, i.e., never
> allow a "new-order" request if the relevant authorizations haven't already
> been done.  It seems like this could be addressed in a pretty
> straightforward manner just by defining a new error code (say
> "preauthRequired") that the server can return in this case.
>
> Personally, it seems to me that if we make the clarification (1) and add
> the error code (2) described here, that would address the pain points
> Daniel raises, without a whole lot of new mechanism.  I'm not really seeing
> much additional value to be had from an explicit "ok issue now" request
> (vs. the GET poll).
>
> --Richard
>
>
>
> On Wed, Sep 20, 2017 at 1:22 PM, Richard Barnes  wrote:
>
>> Hey Daniel,
>>
>> Thanks for the input.  I can see why you might be feeling some pain here,
>> but I'm not sure the proposed solution is quite right.
>>
>> Note that ACME already has the "new-authorization" flow, which does
>> pretty much exactly what you're proposing.  The only difference is that
>> instead of authorizations being created all at once in response to a
>> "new-cert" request, they're created individually by the client.  But it's
>> ultimately the same number of RTTs (authz fetch ~ new-authz) -- or rather,
>> one fewer in the new-authz case because there's no new-cert request.  To
>> what degree would your problem be solved simply by having the affected
>> integrators move over to that flow?
>>
>> I can sympathize that the new-order flow might not be suitable for all
>> use cases.  Maybe it would be useful to write down some thoughts on which
>> use cases are best addressed by which flows.
>>
>> --Richard
>>
>>
>>
>> On Tue, Sep 19, 2017 at 12:26 PM, Daniel McCarney 

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

[Martin Thomson]

On Fri, Sep 22, 2017 at 4:40 AM, Richard Barnes  wrote:
> Daniel noted that there might be some issues with GET idempotency here, but
> I don't think this actually makes GET non-idempotent.

It's still idempotent, because doing the GET twice has the same effect
as doing it once.  You are concerned about the GET no longer being
safe.  That is, it is no longer side-effect free.

It is OK to do things in response to a GET as long as the server owns
the consequences.  Servers frequently log GET requests, which isn't
safe or even idempotent, but servers do it because there is an
advantage to them that exceeds the costs.  As long as clients aren't
held accountable for these side-effects, it's OK.

Or, you could consider the resource to have been updated at some point
in the past as though the authorization triggered proactive issuance,
but it's just that the GET has taken a little while to "find" the
updated state.  Think of it as a lazy load, or maybe an extreme case
of the server cache needing to be populated.

If you like, we could also dive into whether this specific type of
request is safe to send in 0-RTT, but I don't have the brain cells for
that right now.

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

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

[Salz, Rich]

If the suggestion is fine with Daniel, I think editorial clarification and a 
new error code can be added without disrupting the  cycle and I am strongly in 
favor of that.

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

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

[Richard Barnes]

I talked a bit with Daniel about this off-list. Here's a summary of where
we got to:

1. In the current "new-order" flow, the server doesn't *really* have to be
proactive -- instead of updating an order object when an authz changes
state, it can wait to update/issue until the client polls for the order
object, indicating that it's actually interested in having a certificate.
That doesn't alleviate the pain of storing the CSR, but it at least avoids
the expense of finding affected orders and issuing in cases where the
client abandons the order.  If we think this approach is OK, I would
propose that we revise the document to make clear that it is OK.  What do
folks think?  Daniel noted that there might be some issues with GET
idempotency here, but I don't think this actually makes GET non-idempotent.

2. Some CAs might want to support only the "new-authz" flow, i.e., never
allow a "new-order" request if the relevant authorizations haven't already
been done.  It seems like this could be addressed in a pretty
straightforward manner just by defining a new error code (say
"preauthRequired") that the server can return in this case.

Personally, it seems to me that if we make the clarification (1) and add
the error code (2) described here, that would address the pain points
Daniel raises, without a whole lot of new mechanism.  I'm not really seeing
much additional value to be had from an explicit "ok issue now" request
(vs. the GET poll).

--Richard



On Wed, Sep 20, 2017 at 1:22 PM, Richard Barnes  wrote:

> Hey Daniel,
>
> Thanks for the input.  I can see why you might be feeling some pain here,
> but I'm not sure the proposed solution is quite right.
>
> Note that ACME already has the "new-authorization" flow, which does pretty
> much exactly what you're proposing.  The only difference is that instead of
> authorizations being created all at once in response to a "new-cert"
> request, they're created individually by the client.  But it's ultimately
> the same number of RTTs (authz fetch ~ new-authz) -- or rather, one fewer
> in the new-authz case because there's no new-cert request.  To what degree
> would your problem be solved simply by having the affected integrators move
> over to that flow?
>
> I can sympathize that the new-order flow might not be suitable for all use
> cases.  Maybe it would be useful to write down some thoughts on which use
> cases are best addressed by which flows.
>
> --Richard
>
>
>
> On Tue, Sep 19, 2017 at 12:26 PM, Daniel McCarney 
> wrote:
>
>> Hi folks,
>>
>> Just over a year ago in a thread titled "Proactive vs On-Finalization
>> Certificate Issuance"[0] we reached the consensus on the question of
>> whether to
>> issue a certificate "on-finalization" or "proactively" with the
>> conclusion to
>> standardize on proactive issuance.
>>
>> Implementation experience shows that proactive issuance is slow in
>> practice. An
>> order can be associated with many authorizations and an authorization can
>> be
>> associated with many orders. This interacts poorly with optimizations
>> Let's
>> Encrypt has developed from in-the-field experience with ACME and it is
>> difficult
>> to rate-limit effectively. I propose that we return to the
>> on-finalization style
>> approach and that we provide the CSR during finalization..
>>
>> ## Issues with proactive issuance
>>
>> ### Authorization Reuse
>>
>> Proactive issuance requires that when an authorization is switched to a
>> valid
>> state by the result of a challenge update that we find the associated
>> orders and
>> iterate each order's authorizations to see if all of the authorizations
>> are
>> valid and issuance can occur.
>>
>> Let's Encrypt reuses existing authorizations[1][2] whenever possible, as
>> encouraged by ACME. This has been of huge value in reducing resource
>> consumption
>> (both in terms of database storage and challenge/API requests). Many
>> clients
>> create pending authorizations they do not finalize and similarly re-create
>> pending authorizations for identifiers that the account already has valid
>> authorizations for. Unchecked this leads to significant database growth
>> and
>> resource consumption, even with aggressive rate-limits[3].
>>
>> The combination of authorization reuse and proactive issuance means a
>> given
>> authorization can be associated with many orders. This necessitates an
>> expensive
>> many-to-many query at each authorization update to see if any associated
>> orders are now complete.
>>
>> One possible workaround is a rate-limit that would constrain the number of
>> orders an authorization can be associated with. However establishing the
>> value
>> of the limit to both reduce server-side load & also effectively support
>> Let's
>> Encrypt's large-volume integrators and their issuance patterns is
>> challenging.
>>
>> ### CSR-first new-order flow
>>
>> To support proactive issuance the CA also needs to have the CSR for the
>> order
>> at-hand when 

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

[Richard Barnes]

Hey Daniel,

Thanks for the input.  I can see why you might be feeling some pain here,
but I'm not sure the proposed solution is quite right.

Note that ACME already has the "new-authorization" flow, which does pretty
much exactly what you're proposing.  The only difference is that instead of
authorizations being created all at once in response to a "new-cert"
request, they're created individually by the client.  But it's ultimately
the same number of RTTs (authz fetch ~ new-authz) -- or rather, one fewer
in the new-authz case because there's no new-cert request.  To what degree
would your problem be solved simply by having the affected integrators move
over to that flow?

I can sympathize that the new-order flow might not be suitable for all use
cases.  Maybe it would be useful to write down some thoughts on which use
cases are best addressed by which flows.

--Richard



On Tue, Sep 19, 2017 at 12:26 PM, Daniel McCarney 
wrote:

> Hi folks,
>
> Just over a year ago in a thread titled "Proactive vs On-Finalization
> Certificate Issuance"[0] we reached the consensus on the question of
> whether to
> issue a certificate "on-finalization" or "proactively" with the conclusion
> to
> standardize on proactive issuance.
>
> Implementation experience shows that proactive issuance is slow in
> practice. An
> order can be associated with many authorizations and an authorization can
> be
> associated with many orders. This interacts poorly with optimizations Let's
> Encrypt has developed from in-the-field experience with ACME and it is
> difficult
> to rate-limit effectively. I propose that we return to the on-finalization
> style
> approach and that we provide the CSR during finalization..
>
> ## Issues with proactive issuance
>
> ### Authorization Reuse
>
> Proactive issuance requires that when an authorization is switched to a
> valid
> state by the result of a challenge update that we find the associated
> orders and
> iterate each order's authorizations to see if all of the authorizations are
> valid and issuance can occur.
>
> Let's Encrypt reuses existing authorizations[1][2] whenever possible, as
> encouraged by ACME. This has been of huge value in reducing resource
> consumption
> (both in terms of database storage and challenge/API requests). Many
> clients
> create pending authorizations they do not finalize and similarly re-create
> pending authorizations for identifiers that the account already has valid
> authorizations for. Unchecked this leads to significant database growth and
> resource consumption, even with aggressive rate-limits[3].
>
> The combination of authorization reuse and proactive issuance means a given
> authorization can be associated with many orders. This necessitates an
> expensive
> many-to-many query at each authorization update to see if any associated
> orders are now complete.
>
> One possible workaround is a rate-limit that would constrain the number of
> orders an authorization can be associated with. However establishing the
> value
> of the limit to both reduce server-side load & also effectively support
> Let's
> Encrypt's large-volume integrators and their issuance patterns is
> challenging.
>
> ### CSR-first new-order flow
>
> To support proactive issuance the CA also needs to have the CSR for the
> order
> at-hand when checking each authorization in case issuance can proceed. The
> `new-order` request that creates the order therefore carries the full CSR
> that
> was previously delivered by the "certificate finalize" message.
>
> We see users create many more authorizations than they are able to finalize
> successfully. With the legacy "new-cert" flow our authorization reuse
> dramatically helped reduce the DB space used up by authorizations that will
> never lead to issuance because no CSR is stored until all identifiers are
> validated.
>
> With the new-order flow we have to accept and store a full CSR before
> handing
> back authorizations to the client. Reuse of authorizations does not
> prevent the
> DB bloat that will occur from users submitting new order requests and not
> fulfilling them. The CSR contains a full public key and is one of the
> single
> largest contributors to DB disk space usage. Addressing this will require
> another strict rate limit on outstanding new-orders and is again difficult
> to
> “dial-in” in to both prevent excessive resource consumption and also
> maintain
> the ability for big integrators to process large-scale issuance using our
> API.
>
> # Proposed Change
>
> I believe we should change the `new-order` endpoint to not accept a full
> CSR but
> to instead accept a list of identifiers that the ACME client wishes to
> authenticate & issue for. Authorizations can be created and returned for
> those
> domains as happens today.
>
> The order resource should be changed to have a “finalizeURL” field which
> provides the client a URL to POST a CSR to indicate that the CA should
> issue the
> certificate. Proactive 

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

[Jacob Hoffman-Andrews]

On 09/19/2017 01:34 PM, Logan Widick wrote:
> Would it be possible to extract the key and identifiers from the CSR,
> add the key  to the database if it doesn't already exist, find or
> create the authorizations for the identifiers, not store the CSR, and
> then assemble the certificate from the (valid) authorizations and key
> later?
Note that the size of the CSR for an RSA key is about half from the
signature, and half from the key. So extracting the key would only save
the size of the signature, about half. Also, this wouldn't solve the
more important problem, the overhead of reviewing all authzs on all
related orders on finalizing each authz, when an order may have a
hundred or more authzs.

I support Daniel's proposal.

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

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

[Ilari Liusvaara]

On Tue, Sep 19, 2017 at 03:34:50PM -0500, Logan Widick wrote:
> Would it be possible to extract the key and identifiers from the CSR, add
> the key  to the database if it doesn't already exist, find or create the
> authorizations for the identifiers, not store the CSR, and then assemble
> the certificate from the (valid) authorizations and key later?

Most CSRs have fresh keys that are never reused (thanks to forced key-
rotation[1] in most ACME clients).

> Alternatively, could one get rid of the CSRs altogether, and have the
> new-order be a nested JWS? The inner JWS would be signed by the key that
> goes on the certificate and would contain everything required to generate
> the certificate (identifiers, requested dates if applicable, etc.). The
> outer JWS would be signed by the ACME account key and link the inner JWS to
> the ACME account.

Using the private key to sign a JWS is cryptographically very much non-
kosher.

Also, some systems can emit CSRs for non-exportable key. With those,
you are SoL unless you can send a CSR to the CA.

> What goes in a CSR or certificate that can't be reconstructed later?

For Let's Encrypt, AFAIK the only things in CSR that matter are:

- Requested domains
- Public key
- Signature (to verify proof-of-possession).


[1] Even if the client has mode that does not rotate the keys, that
mode is in most of the clients somehow crippled, so it does not
actually work well.




-Ilari

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

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

[Logan Widick]

Would it be possible to extract the key and identifiers from the CSR, add
the key  to the database if it doesn't already exist, find or create the
authorizations for the identifiers, not store the CSR, and then assemble
the certificate from the (valid) authorizations and key later?

Alternatively, could one get rid of the CSRs altogether, and have the
new-order be a nested JWS? The inner JWS would be signed by the key that
goes on the certificate and would contain everything required to generate
the certificate (identifiers, requested dates if applicable, etc.). The
outer JWS would be signed by the ACME account key and link the inner JWS to
the ACME account.

What goes in a CSR or certificate that can't be reconstructed later?

Logan

On Sep 19, 2017 2:26 PM, "Daniel McCarney"  wrote:

Hi folks,

Just over a year ago in a thread titled "Proactive vs On-Finalization
Certificate Issuance"[0] we reached the consensus on the question of
whether to
issue a certificate "on-finalization" or "proactively" with the conclusion
to
standardize on proactive issuance.

Implementation experience shows that proactive issuance is slow in
practice. An
order can be associated with many authorizations and an authorization can be
associated with many orders. This interacts poorly with optimizations Let's
Encrypt has developed from in-the-field experience with ACME and it is
difficult
to rate-limit effectively. I propose that we return to the on-finalization
style
approach and that we provide the CSR during finalization..

## Issues with proactive issuance

### Authorization Reuse

Proactive issuance requires that when an authorization is switched to a
valid
state by the result of a challenge update that we find the associated
orders and
iterate each order's authorizations to see if all of the authorizations are
valid and issuance can occur.

Let's Encrypt reuses existing authorizations[1][2] whenever possible, as
encouraged by ACME. This has been of huge value in reducing resource
consumption
(both in terms of database storage and challenge/API requests). Many clients
create pending authorizations they do not finalize and similarly re-create
pending authorizations for identifiers that the account already has valid
authorizations for. Unchecked this leads to significant database growth and
resource consumption, even with aggressive rate-limits[3].

The combination of authorization reuse and proactive issuance means a given
authorization can be associated with many orders. This necessitates an
expensive
many-to-many query at each authorization update to see if any associated
orders are now complete.

One possible workaround is a rate-limit that would constrain the number of
orders an authorization can be associated with. However establishing the
value
of the limit to both reduce server-side load & also effectively support
Let's
Encrypt's large-volume integrators and their issuance patterns is
challenging.

### CSR-first new-order flow

To support proactive issuance the CA also needs to have the CSR for the
order
at-hand when checking each authorization in case issuance can proceed. The
`new-order` request that creates the order therefore carries the full CSR
that
was previously delivered by the "certificate finalize" message.

We see users create many more authorizations than they are able to finalize
successfully. With the legacy "new-cert" flow our authorization reuse
dramatically helped reduce the DB space used up by authorizations that will
never lead to issuance because no CSR is stored until all identifiers are
validated.

With the new-order flow we have to accept and store a full CSR before
handing
back authorizations to the client. Reuse of authorizations does not prevent
the
DB bloat that will occur from users submitting new order requests and not
fulfilling them. The CSR contains a full public key and is one of the single
largest contributors to DB disk space usage. Addressing this will require
another strict rate limit on outstanding new-orders and is again difficult
to
“dial-in” in to both prevent excessive resource consumption and also
maintain
the ability for big integrators to process large-scale issuance using our
API.

# Proposed Change

I believe we should change the `new-order` endpoint to not accept a full
CSR but
to instead accept a list of identifiers that the ACME client wishes to
authenticate & issue for. Authorizations can be created and returned for
those
domains as happens today.

The order resource should be changed to have a “finalizeURL” field which
provides the client a URL to POST a CSR to indicate that the CA should
issue the
certificate. Proactive issuance should be removed outright.

This will address both the problem of scanning existing many-to-many orders
& their authorizations as well as the db bloat that will occur from
front-loading the delivery of the CSR.

It may be tempting to leave proactive issuance as an optional feature but
this
will require maintaining the 

[Acme] Revisiting Proactive Issuance & new-order CSR

[Daniel McCarney]

Hi folks,

Just over a year ago in a thread titled "Proactive vs On-Finalization
Certificate Issuance"[0] we reached the consensus on the question of
whether to
issue a certificate "on-finalization" or "proactively" with the conclusion
to
standardize on proactive issuance.

Implementation experience shows that proactive issuance is slow in
practice. An
order can be associated with many authorizations and an authorization can be
associated with many orders. This interacts poorly with optimizations Let's
Encrypt has developed from in-the-field experience with ACME and it is
difficult
to rate-limit effectively. I propose that we return to the on-finalization
style
approach and that we provide the CSR during finalization..

## Issues with proactive issuance

### Authorization Reuse

Proactive issuance requires that when an authorization is switched to a
valid
state by the result of a challenge update that we find the associated
orders and
iterate each order's authorizations to see if all of the authorizations are
valid and issuance can occur.

Let's Encrypt reuses existing authorizations[1][2] whenever possible, as
encouraged by ACME. This has been of huge value in reducing resource
consumption
(both in terms of database storage and challenge/API requests). Many clients
create pending authorizations they do not finalize and similarly re-create
pending authorizations for identifiers that the account already has valid
authorizations for. Unchecked this leads to significant database growth and
resource consumption, even with aggressive rate-limits[3].

The combination of authorization reuse and proactive issuance means a given
authorization can be associated with many orders. This necessitates an
expensive
many-to-many query at each authorization update to see if any associated
orders are now complete.

One possible workaround is a rate-limit that would constrain the number of
orders an authorization can be associated with. However establishing the
value
of the limit to both reduce server-side load & also effectively support
Let's
Encrypt's large-volume integrators and their issuance patterns is
challenging.

### CSR-first new-order flow

To support proactive issuance the CA also needs to have the CSR for the
order
at-hand when checking each authorization in case issuance can proceed. The
`new-order` request that creates the order therefore carries the full CSR
that
was previously delivered by the "certificate finalize" message.

We see users create many more authorizations than they are able to finalize
successfully. With the legacy "new-cert" flow our authorization reuse
dramatically helped reduce the DB space used up by authorizations that will
never lead to issuance because no CSR is stored until all identifiers are
validated.

With the new-order flow we have to accept and store a full CSR before
handing
back authorizations to the client. Reuse of authorizations does not prevent
the
DB bloat that will occur from users submitting new order requests and not
fulfilling them. The CSR contains a full public key and is one of the single
largest contributors to DB disk space usage. Addressing this will require
another strict rate limit on outstanding new-orders and is again difficult
to
“dial-in” in to both prevent excessive resource consumption and also
maintain
the ability for big integrators to process large-scale issuance using our
API.

# Proposed Change

I believe we should change the `new-order` endpoint to not accept a full
CSR but
to instead accept a list of identifiers that the ACME client wishes to
authenticate & issue for. Authorizations can be created and returned for
those
domains as happens today.

The order resource should be changed to have a “finalizeURL” field which
provides the client a URL to POST a CSR to indicate that the CA should
issue the
certificate. Proactive issuance should be removed outright.

This will address both the problem of scanning existing many-to-many orders
& their authorizations as well as the db bloat that will occur from
front-loading the delivery of the CSR.

It may be tempting to leave proactive issuance as an optional feature but
this
will require maintaining the CSR in the new-order and I also believe that
having
two very distinct methods of issuance will complicate the client ecosystem
and
returns us to the question of how to determine which will occur that
spawned the
original "Proactive vs On-finalization Certificate Issuance"
thread[0].

[0] https://mailarchive.ietf.org/arch/msg/acme/0lVmGl8e-rmSH0x7ycDW5dj6GAY
[1] https://community.letsencrypt.org/t/upcoming-api-changes/17947
[2]
https://community.letsencrypt.org/t/automatic-recycling-of-pending-authorizations/41321
[3] https://letsencrypt.org/docs/rate-limits/
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme