Subject: [Acme] Increase the idempotency of the protocol

From: Hugo Landau <[email-masked]>
Date: Tue, 29 Dec 2015 21:36:57 +0000

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.).

---

From: Niklas Keller <[email-masked]>
Date: Wed, 30 Dec 2015 12:11:55 +0100

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

> _______________________________________________
> Acme mailing list
> [email-masked]
> 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