On Wed, Jul 6, 2016 at 8:01 AM, Richard Barnes <[email protected]> wrote:
> In preparation for the impending draft deadline, I'm trying to finalize
> close this out. It seems like there's some positive reaction to the
> "revise the flow" idea, so I wanted to make a concrete proposal:
>
> 1. Add a section specifying the order of operations for the client:
> - Register if you haven't done so before
> - Send a new-cert request
> - Get back preconditions; satisfy them
> - Retry the new-cert request
>
I have the same concerns about this that I had in B-A. This seems to put
the client in a position of having to continuously fulfill new requirements
without any guarantee that it will ever lead to success. That seems bad.
-Ekr
> 2. Remove the new-authz URL
>
> Obviously (1) could make for some slightly complicated state management on
> the CA side in some cases, if the CA needs to carry any state between the
> first new-cert request and the second. But it seems like this can be
> managed, e.g., by carrying state in the authz URLs or the authorizations
> themselves. And it is technically possible to do it entirely statelessly.
>
> Removing the new-authz URL isn't strictly necessary. You could leave it
> there as an optional service ("if new-cert in directory {...}"), but
> removing it seems more in the spirit of Langley's "have one joint and keep
> it well oiled" principle. And while it's a hard breaking change, CAs can
> migrate gradually by leaving it on for a while.
>
> Obviously, the deadline is coming up quickly, so it would be great to get
> feedback today-ish. It's not critical that we get all the comments now; we
> can discuss between now and the meeting. This is just a non-trivial bit of
> work, so I wanted to sanity check before I embarked on it.
>
> Thanks,
> --Richard
>
>
>
> On Fri, May 6, 2016 at 3:19 PM, Richard Barnes <[email protected]> wrote:
>
>> Hey all,
>>
>> Just posted a PR with a sketch of the "precondition" idea that we
>> discussed at the F2F in Buenos Aires:
>>
>> https://github.com/ietf-wg-acme/acme/pull/124
>>
>> This change seems pretty simple, and I think it lets us hit a few pain
>> points:
>>
>> * Wildcards: Just send the CSR in and let the CA tell you what to validate
>>
>> * Payment: Specify an "out-of-band" precondition
>>
>> * CA issuance flows: If the CA won't tell you how to authorize until you
>> send in a CSR, this now lets the ACME server lead the client to do
>> authorization after the new-cert request comes in.
>>
>> We may need a little more machinery here, e.g., to be able to have the
>> new-authz endpoint say "that's not going to work directly, just request the
>> cert". We may even want to just revise the flow, so that instead of
>> reg-authz-cert, the default order is reg-cert-authz-cert.
>>
>> But I thought I'd go ahead and send this first pass out for feedback.
>>
>> What do people think?
>>
>> Thanks,
>> --Richard
>>
>
>
> _______________________________________________
> Acme mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/acme
>
>
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
