This line of argument isn't really useful. No matter what we specify here,
clients can choose to only implement a part of the spec. (There are TLS
clients that only do RSA.) Our responsibility here isn't to make sure that
there's nothing a client can skip, it's to make sure that a client that
wants to implement the whole spec can.
This change meets that bar. The behavior specified for the client is clear
and implementable:
if (directory['new-authz']) {
// do pre-auth if you want to
}
// do new-app
Given that, I think we should go ahead and land this change.
--Richard
On Tue, Aug 9, 2016 at 9:09 PM, Jacob Hoffman-Andrews <[email protected]> wrote:
> 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.
>
> _______________________________________________
> Acme mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/acme
>
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
