Hi acme@, As mentioned in today's meeting, there are a few aspects of the current ACME Renewal Info draft that I'd like feedback on. The current draft is at https://www.ietf.org/archive/id/draft-aaron-acme-ari-01.html, and the source is at https://github.com/aarongable/draft-acme-ari. Of course all notes and feedback outside these specific Open Questions is also greatly appreciated.
1) Getting client to recheck ARI quickly and regularly This is tracked as https://github.com/aarongable/draft-acme-ari/issues/13 The -01 ARI draft specifies that ARI responses must come with a `Retry-After` header, and that clients should check ARI again after the Retry-After period has passed. This matches the semantics of the Retry-After header as specified in RFC7231. However, this does nothing to suggest that the client should check in again as soon as possible after the retry-after period has passed. For example, a cron-based ACME client that wakes up once every 24 hours would be fully compliant with an ACME server whose Retry-After header specifies 6 hours. We would like to have the document specify that clients should check in on a regular, server-controlled basis. The ideas we've had so far are: a) Include a "next check-in window" in the renewalInfo response, alongside the existing suggestedWindow b) Include a "polling period" in the server's directory (either by making the new `renewalInfo` key map to an object with both the base url and the polling period; or by including it as a new key in the directory's meta object) c) Another header? Is there another HTTP header that provides the semantics we want? d) Leave it as-in, and just specify that the client should check in within a certain amount of time after the Retry-After header. I'm currently leaning towards (b), including the polling period in the ACME directory meta section, but am open to other ideas and discussion. 2) Considering inclusion of a "this has been renewed" callback endpoint This is tracked as https://github.com/aarongable/draft-acme-ari/issues/15 One of the motivating use-cases for this protocol extension is the "business continuity in spite of revocation" case: a CA that is about to revoke a certificate could, the next time that cert's subscriber's client polls the ARI endpoint, inform the client that it should renew right away. Then the client could replace the cert as normal, and the original could be revoked without any disruption to the subscriber. However, if a cert contains multiple identifiers as SANs, identifying when a cert has been renewed becomes difficult. What if the client decides to request two new certs, each with half of the identifiers? What if the client no longer cares about one of the identifiers, and requests one cert with N-1 names? It is easy to imagine even messier cases. Therefore it would be useful for the client to be able to inform the server "Thanks for telling me I should renew this cert; I have no completed that task to my own satisfaction", so that the server can then go ahead and revoke the cert, knowing it will not cause any disruption by doing so. One idea to implement this would be for the client to POST to the same resource url as it polls for renewalInfo, with the body being a signed JWT containing a single "renewalComplete=true" as the body. The server would only accept this if the POST were signed by the same account key as originally ordered the cert. 3) Whether or not using SHA1 in constructing the URL is a good idea This is tracked as https://github.com/aarongable/draft-acme-ari/issues/16 and https://github.com/aarongable/draft-acme-ari/issues/17 During the meeting there were some comments regarding the suitability of SHA1 for hashing the Issuer Name and Issuer Key when constructing the renewalInfo URL. Points in favor of SHA1 include: - No need for a cryptographic hash in this case - Widely and readily available in all ACME client environments - Matches the RFC5019 "Lightweight OCSP Profile" spec Points against SHA1 include: - Slower than some other non-cryptographic hashes - Prevents libraries from dropping SHA1 support entirely - Using something else likely also pushes us towards allowing algorithm flexibility (as OCSP does), which introduces additional complexity I currently believe that sticking with SHA1 is the best path forward, but am very interested in further comments and discussion. Thanks again for all of the discussion so far, Aaron
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
