On Thu, Jul 9, 2020 at 6:01 AM Ryan Sleevi wrote:
>
>
> On Thu, Jul 9, 2020 at 8:30 AM Ilari Liusvaara
> wrote:
>
>> On Wed, Jul 08, 2020 at 08:03:40PM +0200, Sebastian Nielsen wrote:
>> > Couldn’t it be done in the way that the ACME server creates a nonce.
>>
>> I am not sure why the client non
I would be extremely uncomfortable specifying a mechanism like this. It
would be a large divergence from the existing ACME specification, and would
create significant traps for implementers to fall into. Specifically this
would break assumptions in most existing implementations, principally that
an
>>ACME protocol is not meant to proceed to CSR sending until after all
names are validated. Breaking that would cause implementation
problems.
Thats why there should be 2 validation types, so a client who support the new
"skip ahead" validation type would know that it only needs to request o
On Thu, Jul 9, 2020 at 8:30 AM Ilari Liusvaara
wrote:
> On Wed, Jul 08, 2020 at 08:03:40PM +0200, Sebastian Nielsen wrote:
> > Couldn’t it be done in the way that the ACME server creates a nonce.
>
> I am not sure why the client nonce is there. And I can not quickly find
> any discussion about cr
On Wed, Jul 08, 2020 at 08:03:40PM +0200, Sebastian Nielsen wrote:
> Couldn’t it be done in the way that the ACME server creates a nonce.
I am not sure why the client nonce is there. And I can not quickly find
any discussion about cryptographic reasons.
It could be for hash strenthening. However,
Reviewer: Peter Yee
Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more in
