Re: [Acme] Happy Birthday ACME!

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.com@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
>