What's the Let's Encrypt URL?

Issuance Tech
41

In that case I would urge to call the meta-directory something different than "directory" :wink:

Also, that would mean a addendum to the ACME protocol would need to be written and that probably would mean a different RFC et cetera.

42

You mean something like "index"? :wink:

43

Somewhat intentionally. There was some strong discussion on the ACME mailing list as we approached finalization of the spec. Some folks (like me) wanted to call the finalized version of the spec "ACMEv2." More experienced IETF folks said "there's no ACMEv1 and ACMEv2; there are just draft versions of ACME, and ACME (i.e. what became RFC 8555)." From a purely pragmatic standpoint, Let's Encrypt's acme-v02 endpoint implements RFC 8555, and acme-v01 endpoint implements something that is close to a variety of draft versions; the main separation is the move from new-authz / new-cert to new-order / finalize.

Directory URLs

By the way, some folks were talking earlier in this thread about the niceness of ACME being configured by a single directory URL that has links to all the different endpoints. There's another way to solve this problem, exemplified by CT. Logs are configured by a root URL, and all endpoints are at known fixed paths relative to that.

For instance, if a log URL is https://example.com/mylog, you know to send add-chain requests to https://example.com/mylog/ct/v1/add-chain. You also know to set get-entries requests to https://example.com/mylog/ct/v1/get-entries. I like this style of API design, but there was a document in the IETF, BCP 190 (aka RFC 7320), that has long been interpreted to forbid it (BCP stands for Best Common Practice).

Anyhow, this issue came up during work on CT v2. The CT authors were asked to switch to a directory style like ACME, or a templating style like some other RFCs. I made a case that the common interpretation of RFC 7320 was too restrictive, and managed to convince folks! Mark Nottingham, the original author, did some revisions and made RFC 8820. That became the new BCP 190, and CT-style APIs are now allowed!

BCP 190 is dead, long live BCP 190!