Closed davidben closed 3 weeks ago
Based on TLSWG feedback, we're going to proceed with draft-beck-tls-trust-anchor-ids over draft-davidben-tls-trust-expr, so now this tracks rebasing over the other one. I believe the things to do are:
issuer_id
with the same OID-based construction used by trust anchor IDs. However, that does not name an individual trust anchor but takes the entire OID arcTrustAnchor
structure in BikeshedCertificate
with a TrustAnchorIdentifier
from draft-beck. Unlike X.509, there is need to communicate the trust anchor ID in CertificatePropertyList
. The subscriber is assumed to understand the BikeshedCertificate
structure and can parse it out. (X.509 only needs it because its native issuer field is horrible.)trust_anchors
extension in this document and just reference draft-beck. Much of the supporting musing on deployment can also probably go.The ACME bits may also need thought, but I think we leave that for later and just drop in a TODO. draft-beck has an ACME extension, but MTC's long issuance times complicate matters.
I presume we'd only want the client to send the trust anchor of the latest batch it has — and not all batches it trusts?
Hmm. I think we'd effectively have to depend on the DNS advertisement because otherwise it's too large. I guess, yeah, we will lose the goofy thing we did here where one trust anchor ID secretly aliases a bunch of others concurrently. I'm thinking we tentatively just lose it and take a DNS dependency, and then we can always add it back later.
I'll leave a little TODO for it.
I'll leave a little TODO for it.
Also will file a bug in the other repo to track this.
We can probably also trim the now redundant text around multi-certificate deployment models.