2015-12-29 22:36 GMT+01:00 Hugo Landau <[email protected]>: > 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 >
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
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
