Hi TLS folks, (I was not sure about the preferred cross-posting etiquette, so I haven't CC'd plants@ here yet. Instead, I'll send plants@ an email pointing to this thread right after this one. Figured, if I guessed wrong, it’s always easier to merge threads than to split them back apart.)
For folks who haven’t been following, there is a new PLANTS <https://datatracker.ietf.org/group/plants/about/> WG, formed to have a grand time sharing plant puns—wait, sorry, let me try that again... For folks who haven’t been following, there is a new PLANTS <https://datatracker.ietf.org/group/plants/about/> WG, formed to solve a problem at the intersection of certificates, transparency systems, and post-quantum. It was dispatched from the Merkle Tree Certificates <https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/> (MTC) work that actually was first presented here three years ago <https://datatracker.ietf.org/meeting/116/materials/slides-116-tls-merkle-tree-certificates-00>! Though it has evolved significantly since then. These slides <https://datatracker.ietf.org/meeting/124/materials/slides-124-plants-solution-space-and-dispatched-work-00> from the BoF are probably a good place to start. The WG has just adopted draft-ietf-plants-merkle-tree-certs as a starting point. This is all quite new (and obviously I’m just speaking for myself and not the group), but as there is some overlap with TLS, I figure it’s better to start conversations sooner than later: One key part of the draft is negotiating whether to send the default “standalone certificate”, or a more optimized “landmark certificate”. Landmark certificates need to signal whether the relying party has prior knowledge of a given “landmark”. Happily, landmark numbers fit neatly into the RELATIVE-OID scheme of Trust Anchor IDs. Having some hand in both, this is not a coincidence. :-) This would work even better with one tweak. (We left this out of the original Trust Anchor IDs draft because it was harder to motivate without MTC.) https://github.com/tlswg/tls-trust-anchor-ids/issues/62 Landmarks are slightly structured. A relying party will be configured with a range of landmarks spanning some snapshot of currently unexpired certificates (say landmarks 100 to 200). This means if you support landmark 200, you also support 199, 198, 197, etc. Incorporating that lets TLS negotiate this more efficiently. The MTC draft contains a sketch of a TAI extension to do this. I’ve applied it to the TAI draft as a PR here: https://github.com/tlswg/tls-trust-anchor-ids/pull/104 The idea is to statically configure (via the CA or ACME server) with each certificate a set of “additional IDs” that also match it. We’d use the same CertificatePropertyList format that we use to configure the main ID. This lets us encode schemes where one ID can imply multiple trust anchors, like landmark 200 implying the landmarks below it. In applications that use this, relying parties can then send a smaller set of IDs to convey the same information. The extension can be used in MTCs like this: https://www.ietf.org/archive/id/draft-ietf-plants-merkle-tree-certs-02.html#section-8.2 The proposal is more general though. As before, the observation is that upgrading server software across an ecosystem is expensive, particularly for servers operated not by major players. Hence, the preference for flexible schemes that we can invest in once and reuse. (E.g. if someone wants one number to represent landmarks from multiple CAs, it's possible to encode this here. Though there are challenges regarding whether one unreachable CA can knock out the optimization for all, so I'm not sure if that's actually wise.) Thoughts? David
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
