Re: [Acme] Pre-authorization approach

[Jacob Hoffman-Andrews <[e-mail]>]

On 08/09/2016 05:27 PM, Andrew Ayer wrote:
> This means that clients can't rely on the server offering this
> endpoint.  Although there is a risk of half-baked implementations
> assuming all servers support it, it seems unlikely that many would make
> this mistake.  All clients have to go through the new-app workflow
> anyways, and it's easier to just let the server create authorizations for
> you.

I disagree that the risk of half-baked clients. Experience shows that if
something works, some clients will do it, and will break if it's not
available.

This is exacerbated by the fact that the new-authz flow most closely
matches the flow currently implemented in Boulder and used by existing
ACME clients. So the reasonable and safe thing for a client maintainer
to do would be to keep using new-authz if Let's Encrypt continues to
offer it.

I think the only way to make sure the ecosystem of ACME clients is
actually interoperable with servers that don't implement new-authz is
for Let's Encrypt not to implement new-authz in its next API revision.
Which is reasonable, but it means that EKR's issue goes unaddressed.