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 [email protected] https://www.ietf.org/mailman/listinfo/acme
