merkle_tree_sha256 TrustAnchors mean different things in different contexts

[davidben]

In the context of a BikeshedCertificate, (issuer, 1000) means this certificate is part of batch 1000 in the specified CA.

In the context of trust anchor negotiation (the RP's trust anchor list, the list of aliases), it refers to a whole window. That is, if window_size is 100, sending (issuer, 1000) means you are advertising (issuer, 901) through (issuer, 1000).

This works out, but it's a little weird. Maybe we should just allocate two different ProofType codepoints, with the second one referring to the whole window?

[davidben]

I've also started informally saying "aliases" now but the draft says "additional trust anchors". Also something to fix as we refine the negotiation story.

[nharper]

It seems that the TrustAnchor struct is used in 3 distinct places (in the BikeshedCertificate, in the RP's store identifying which certs it accepts, and sent in the TrustAnchors TLS extension). This would be clearer if at least the last use case is separated out. In the BikeshedCertificate, the TrustAnchor appears to be the correct structure. In the RP's store, a list of TrustAnchors can be simplified to an issuer_id and a range of batch_numbers (though this is an implementation detail). When negotiating the use of Merkle Tree certificates, the RP needs to communicate a list of (issuer_id, batch_number range), which can be optimized as a list of (issuer_id, latest batch_number). While (issuer_id, latest batch_number) has the same format as a TrustAnchor, is is semantically different and could be improved upon in the spec by calling it something else.

[davidben]

Yeah, I think that'd make sense. I think, when I'd originally written it, I was thinking:

• RPs advertising (issuer_id, 1000) means they support (issuer_id, 1000), which is a true statement
• If an RP supports 1000, it also supports 900..1000. (Or you can think of it as supporting 0..1000 and then throwing out all the expired ones.)
• The subscriber/CA know this fact and so, they'll accept larger batch numbers in lieu of their current one, up to window size
• RPs know that subscriber/CA knows this, so they choose not to advertise the other 99 values they also support, because you're not obligated to list everything you support, only to support everything you list.

But this is pretty confusing, so it probably makes sense to explicitly treat these as aliases.

[davidben]

Really all this is an artifact of me, at the very last minute, switching from begrudgingly conceding that the subscriber has to know something about the structure of merkle_tree_sha256 TrustAnchors (this 1000 implies 900..1000 property) to, at the least minute, realizing you can model this with the CA handling you a pile of aliases and then scribbling that in without thinking about it too hard! :-D

But it's pretty annoying that the CA has to list out hundreds of aliases, so maybe we actually should have some notion of versioned things in the generic structure anyway...