On Sat, 6 Aug 2016 10:36:55 -0700
Jacob Hoffman-Andrews <[email protected]> wrote:
> So I think we should take the conservative approach and roll back the
> new-application flow for now.
I think the application flow should stay. Many CAs, including the ones
that SSLMate abstracts over, tie authorizations to specific CSRs, so
SSLMate can't implement an ACME frontend without the application flow.
There's also a security reason to prefer CSR-tied authorizations
over account-tied authorizations: if you'd like to authorize a third party
to obtain a certificate on your behalf, being able to grant authorization
for only a single, specific certificate request is preferable to
granting carte blanche authorization to issue certificates for an
identifier.
I don't think there's a risk of interoperability problems if the
protocol supports both applications and new-authz. All clients will
need to support both applications and authorizations in any case. The
only difference in workflow is whether the authorization is retrieved by
POSTing to the new-authz endpoint, or by GETing a URL specified in the
application object.
There's one more reason to keep applications: if the CSR field is
mutable, applications provide a powerful abstraction to manage a
certificate over its entire lifetime, including across SAN changes and
renewals, as I discussed here:
https://www.ietf.org/mail-archive/web/acme/current/msg01160.html
Regards,
Andrew
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
