Happy birthday, RFC8555! I've thought frequently about the idea of an ACME-bis over the last few years. I have a note going since at least 2022 which I occasionally add new ideas to, and I've had a few offline conversations with others about their wishlists. At the end of the day, I think only two of the changes I'd like to make are backwards-incompatible:
1. All URLs (new-order, authorizations, challenges, finalize, etc) should be constructable just from the ACME server's root path and an ID, rather than requiring the Directory to list all the top-level endpoints, and for order objects to list all the authorization and certificate URLs. To the best of my understanding, the ACME API URLs are completely unspecified due to an overly-strict reading of an older IETF best-practice which said that RFCs should not mandate path structure on servers. But it turns out that, as long as the server gets to pick the root path however it wants, it's totally fine to mandate structure below that root path. We should do so. 2. I think it is unfortunate that the finalize request includes a CSR. This requires ACME client implementations to have x509/ASN.1/DER encoding capabilities, and incentivizes server implementations to take the lazy route (copying values straight from the CSR to the issued certificate) instead of being very careful and intentional with the values in the issued cert. The only advantages of the CSR are that it acts as a container for the pubkey, and that it can carry additional information (such as requests for extensions) that the server might honor. Both of these can be replaced by, in my opinion, cleaner mechanisms. Everything else that I'd love to include in an ACME-bis could be done as add-on documents without obsoleting 8555 itself: 3. Profile advertisement in the Directory, and profile selection in the new-order request. (Unless we wanted to replace the current notBefore/notAfter fields, in which case this also becomes a backwards-incompatible change.) 4. Presenting the desired pubkey at new-order time, and implementing true proof-of-control via the same authorization/challenge system as ACME provides for other information (identifiers) to be included in the certificate. (Notably, using the challenge system for this also allows for demonstrating proof of control over KEM pubkeys which cannot produce traditional signatures, which may be important in the post-quantum cryptography era.) As for incorporating other existing documents (such as TLS-ALPN-01, ACME-IP, ACME CAA, etc), I'm truly not sure what the best practice is. I think they should probably be left as-is as long as they're compatible with a hypothetical ACME-bis, and incorporated directly into ACME-bis if they would become incompatible with it. (For example, ACME-IP could be left untouched, as it simply registers a new identifier type, while RFC 9115 ACME Delegated Certificates would likely need to be updated due to its heavy reliance on the CSR.) Thanks for starting this discussion! Aaron On Mon, Mar 11, 2024 at 2:08 PM Rob Stradling <rob= 40sectigo....@dmarc.ietf.org> wrote: > RFC8555 was published [1] 5 years ago today! > > Just thinking aloud, 'cos I'm curious what folks here think... > At what point might it make sense to start work on an 8555-bis? > > There's a fairly long list of Errata [2]: 10 Verified, 5 Reported, and 4 > Held for Document Update. > > Would it make sense for an 8555-bis document to incorporate and obsolete > any of the "add-on" RFCs / I-Ds, such as RFC8738, that have been published > since RFC8555? Or, conversely, would it be preferable to not do that? > > With 5 years of deployment experience behind us, have any "missing" > features in RFC8555 been identified that would be best addressed by > updating the core specification (i.e., in an 8555-bis document) rather than > by writing new "add-on" I-Ds? Or, conversely, are "add-on" I-Ds always the > preferred approach? (The "missing" feature that immediately springs to my > mind is "profiles" [3]). > > > [1] > https://mailarchive.ietf.org/arch/msg/rfc-dist/25pD6Za_dVkXMbJwyPhBJR6nIlo/ > [2] https://www.rfc-editor.org/errata_search.php?rfc=8555 > [3] > https://mailarchive.ietf.org/arch/msg/acme/BLVAayrTrUCegT4s2twci3Q2BY8/ > > -- > Rob Stradling > Senior Research & Development Scientist > Sectigo Limited > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
