Hi ACME folks, (I wasn’t sure about cross-posting etiquette, so I haven't CC'd plants@ here. Rather, I’ll point plants@ to this thread shortly. Figure it’s always easier to merge threads than to split them.)
For folks who haven’t been following, we have a new PLANTS <https://datatracker.ietf.org/group/plants/about/> WG! It’s definitely not just an excuse to make plant puns. The WG recently adopted Merkle Tree Certificates <https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/> (MTC) as a starting point. This is all quite early (and obviously I’m just speaking for myself and not the group), but there is some overlap with ACME and I figure it's better to start conversations sooner than later. The draft has an initial pass at how to put them together here. Happily, it seems ACME is already rich enough to express what MTC needs, with fairly minimal additions/guidance: https://www.ietf.org/archive/id/draft-ietf-plants-merkle-tree-certs-02.html#name-acme-extensions Some context: These slides <https://datatracker.ietf.org/meeting/124/materials/slides-124-plants-solution-space-and-dispatched-work-00> from the BoF are a good starting point for how MTC works. The ACME interaction is that, for each certificate request, an MTC CA returns two certificates: a “standalone certificate” (large, immediate, generally usable) and a “landmark certificate” (small, delayed, not generally usable, optional). The CA... 1. Validates the certificate request. 2. Appends the information to a log, signs it, etc. This step constitutes issuance. 3. Constructs a standalone certificate that serves as proof of this issuance. 4. Waits some time (hours) for a “landmark” to be allocated. 5. Constructs a landmark certificate that serves as an alternate proof of this same issuance. MTC wants a way to configure ACME to deliver both certificates (one immediately and one that the ACME client can optionally retrieve later, after some delay), along with any metadata needed for the TLS server (etc) to select between the two. The current proposal is to use ACME's existing alternate URLs feature, modeling the delay with the HTTP Retry-After header from RFC 9110. (Another option is to make multiple orders. That would let us model the delay with the "processing" status, but since it’s one validation and issuance event, one order + alternate URLs seemed a better fit.) Thoughts? Is this a good approach to using ACME? David PS: This is not directly part of the Profile Sets proposal. I’m quite behind on my inbox and need to follow-up on that! :-) For MTC, the two certs correspond to one issuance event and are renewed together, so I think we want only one order. Though the problem space is definitely related and perhaps my initial guess at one or both was wrong!
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
