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