On Wed, Jul 6, 2016 at 2:38 PM, Jacob Hoffman-Andrews <j...@eff.org> wrote:
> I think the general concept is good, and if we go this route I agree
> that it should replace new-authz. However, I think there are significant
> details to be worked out, and Eric's feedback is good. I don't want to
> rush this into the spec because we have a document deadline coming up.
>
Agreed that we shouldn't rush this, but I do want to go ahead and get
something in a draft so we can have some more detailed discussion.
> I'd rather take the time to discuss it further and flesh it out better.
> And my apologies for letting this sit so long.
>
> Some more specific feedback:
>
> I think problem documents aren't the right tool for the precondition
> response, and 412 isn't the right status code. Requesting a certificate
> and getting a list of preconditions is an expected, normal thing, not an
> error. Let's split out the "ask for preconditions" step from the "I'm
> done" step. Something like:
>
> POST /acme/submit-csr
> 201 Created
> Location: /acme/requests/123
>
> GET /acme/requests/123
> {
> requirements: [
> { type: authz, url: ..., status: completed },
> { type: authz, url: ..., status: pending },
> ]
> }
>
> ... fulfill the requirements ...
>
> POST /acme/finalize-csr
>
> This avoids the loop that Eric describes, and makes it easy to see what
> still needs to be done. It also means that issuing a certificate for
> which all authz's are already validated follows the same flow as issuing
> one where they are not. You submit the CSR, get back a request object
> with all members "completed", and go on to post to the finalize-csr
> resource.
>
I think this pattern is generally sensible. It moves us closer to what
SSLMate does today, where you "create a certificate object" (basically
register a CSR), then "buy" (== issue) the certificate.
https://sslmate.com/help/api/rest#cookbook
It's a little unfortunate that this imposes an extra RTT for clients that
are already authorized. I guess we can land a first iteration that always
requires the client to finalize after submitting, then consider whether we
want to have a one-step process.
> Your example structure has a precondition of type registration. I think
> we shouldn't treat registration as a precondition that can be returned
> from submit-csr. Instead, it should be as it stands today - you must
> register before you can submit any authenticated ACME requests. So we
> should remove that example precondition.
>
That wasn't my intent. Rather, I wanted the CA to be able to say, e.g.,
"you have to provide a contact". Does that much seem useful?
> More generally, if we're going to support preconditions with type other
> than authz, we should have a more specific design for how they're going
> to work. For instance, in the payment case, how does the client find out
> when payment has been completed?
>
That's up to the out-of-band system. I feel pretty strongly that we need
this out-of-band thing, and we need it to be flexible. It's the escape
valve for whatever else CAs might need to do before ACME does everything
they need. For example, with OOB, you could move over your issuance stuff
(use new-reg / new-cert), but still use your old, web-based forms for
validating possession of domains.
--Richard
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
