Re: [Acme] Increase the idempotency of the protocol

[Niklas Keller <[e-mail]>]

2015-12-29 22:36 GMT+01:00 Hugo Landau <[e-mail]>:

> While developing a client, one minor consideration was remembering for
> which hostnames authorizations have been obtained. My client remembers
> the expiry date of authorizations so that it can avoid unnecessarily
> requesting authorizations which have already been obtained.
>
> A general princple of my client is to keep as little state as possible,
> on the grounds that where state isn't kept, state can't get messed up.
> Where state is kept, there is an implicit hierarchy of normativity, so
> that derived state is subsidiary to normative state, and is wherever
> possible inferred at runtime rather than being stored.
>
> The 'new account' flow is idempotent in the sense that it can be done
> safely if an account has already been registered. It would be highly
> desirable for this idempotency to be extended to authorization creation.
> Possibly even some thought could be put into idempotency for certificate
> and revocation requests.
>
> Essentially, I propose that a client be able to include an expiry time
> in a new authorization request. If a valid authorization for the given
> hostname exists and which expires on or after the given time, a redirect
> should be returned for that authorization in much the same way that an
> attempt to register an existing account does. (This expiry time never
> influences the validity period of an authorization.)
>
> Requests which do not include an expiry time can be considered
> equivalent to requests with a default expiry time. That default expiry
> time could be NOW+5m (a choice made under the assumption that no client
> will take more than 5 minutes to request a certificate), or +INFINITY
> (i.e., an unsatisfiable value resulting in a new authorization always
> being created; this preserves compatibility with existing clients).
>
> Certificate requests could be made idempotent by recommending or
> requiring servers to redirect to existing certificates when a CSR is
> submitted to the server which it has already seen. Servers could
> implement this by storing CSRs or hashes of them.
>
> To summarise, the protocol could be rendered significantly more
> idempotent with only minor, non-breaking changes. This is a win for
> robustess and reduces the chances of repeated requests and corresponding
> unnecessary loads on a CA. This would be especially desirable for
> certificate requests which exert the most significant cryptographic load
> on a CA (HSMs, OCSP signing, etc.).
>
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
>

There's already another way to do something like this, I proposed to make
those two mandatory instead of optional:
https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md#registration-objects
(authorizations and certificates keys).

I think having a redirect there is another good addition and also protects
against multi-issuance and resource waste.

Regards, Niklas