Landmark-relative certs can be built directly from the CA issuance log

[lukevalenta]

We'll probably want to have support for clients to fetch landmark-relative certificates directly from the ACME server (#203, #207), but it's also worth documenting that clients can construct landmark-relative certs for themselves (while also doing "re-anchoring") by directly fetching tiles from the CA issuance log.

(This is a followup to #207 (comment) and some other conversations.)

[ilaril]

Some (subtle) details in doing that:

• Determining the landmark interval the certificate is in.
• Determining the landmark number for the interval.
• Determining ID aliases for the landmark.
• Handling of generation bump while the certificate is valid (while AP can assume RP keeps all valid certificates if there is no generation bump, the generation bump case can be different).

If landmarks are recorded in the tree (I expect that some RPs need be able to verify landmarks), that could be used for the first two. The last one could be handled by having maximum active landmark count, and clearing the interval on generation bump. I do not have ideas for the third.

[lukevalenta]

• Determining the landmark interval the certificate is in.
• Determining the landmark number for the interval.

The AP can construct the landmark-relative cert from a standalone certificate and landmark sequence as described in https://www.ietf.org/archive/id/draft-ietf-plants-merkle-tree-certs-04.html#section-6.3.4 (plus #251).

For a tlog-based log, the landmark sequence will be served at <CA prefix URL>/<log number>/landmarks as described in https://github.com/davidben/C2SP/blob/mtc-tlog/mtc-tlog.md#serving-issuance-logs.

I haven't written it up yet, but the ACME server would need to provide at least <CA prefix URL> (and perhaps the URLs for 1 or 2 mirrors of the CA log) in order for RPs to be able to fetch tiles from <CA prefix URL>/<log number>/tile/...>. Note that log number is embedded in the corresponding standalone cert's serial number.

• Determining ID aliases for the landmark.

Assuming this is referring to the landmark's trust anchor ID, what's needed (from Section 8.2.1) are:

• The CA ID: AP gets it from the standalone cert's issuer
• The log number N: AP gets it from the standalone cert's log number (first 16 bits of serial number)
• The landmark number L: AP gets it from the standalone cert's index in the issuance log (last 48 bits of serial number) and the landmark sequence

Handling of generation bump while the certificate is valid

If the log generation's data is no longer available from the CA or its mirrors (e.g., due to catastrophic data loss), the AP will fail to fetch (presumably with 4xx or 5xx HTTP errors) the data needed to construct the landmark-relative cert and will need to gracefully handle that, presumably by initiating a new certificate order with the ACME server after some amount of retrying. Do you imagine that an ACME server could handle this differently?

If landmarks are recorded in the tree (I expect that some RPs need be able to verify landmarks)...

Note that the landmark sequence is not hashed into the tree, but served as separate auxiliary data. From Section 6.3.1: "If landmarks are allocated incorrectly... there are no security consequences, but some older certificates may fail to validate."

The last one could be handled by having maximum active landmark count, and clearing the interval on generation bump.

I believe the current draft for how to run MTC in the tlog-* ecosystem addresses this: https://github.com/davidben/C2SP/blob/mtc-tlog/mtc-tlog.md. Each issuance log (corresponding to a single log number) publishes its own landmark sequence.

[lukevalenta]

C2SP/C2SP#269 is an attempt to write this down in the mtc-tlog doc. Reviews welcome!