search

davidben / merkle-tree-certs

Other
9 stars 2 forks source link

Split subject_info into ~ and abridged_subject_info #77

Open bwesterb opened 10 months ago

bwesterb commented 10 months ago

GH #76

davidben commented 10 months ago

Sorry, I realized https://github.com/davidben/merkle-tree-certs/issues/76#issuecomment-1759724011 was probably ambiguous. I meant I think the it's useful to have a logical separation between the TLS-specific TLSSubjectInfo format and the (so far) SubjectType-agnostic MTC format. E.g. it means you can define a new SubjectType without having to update every MTC implementation.

Though it does mean the log doesn't tell you everyone's key types. Dunno how much to weigh that. WDYT?

bwesterb commented 10 months ago

E.g. it means you can define a new SubjectType without having to update every MTC implementation.

I don't quite follow. The difference is that with this change, you need an up-to-date implementation to abridge an assertion.

TSes and monitors don't abridge (they only deal with already abridged assertions); CAs shouldn't deal with subjects they don't support; and subscribers don't care about subjects they don't support. That leaves the relying party: it can't verify the proof in a BikeshedCertificate without being updated. Does that matter though: presently it can, but what use is that proof if part of the statement proven (subject) is not understood anyway.

davidben commented 10 months ago

Ah that's true. The TS doesn't actually care. Still, imagine if you're using a BikeshedCertificate verifier from the OS or so. Or even if not from the OS, some separate library. A SubjectType-agnostic abridging process would mean you can freely introduce new subject types (i.e. new protocols) without any fuss.

As an analogy, we don't need to patch our X.509 verifiers to introduce new EKUs. (Although EKUs are kind of a mess for other reasons, so new protocols tend not to make new ones. That's not great for cross-protocol purposes. Would be nice to avoid those reuse pressures.)

bwesterb commented 10 months ago

Still, imagine if you're using a BikeshedCertificate verifier from the OS or so.

Fair point. The user can pass an AbridgedMerkleTreeCertificate defined in the obvious way though.

Note that we do have to change the OS certificate API to support MTC, as the relying party needs to fetch the latest available batches for negotiation. Thus we have some extra flexibility there if you don't like abridging the cert.

A different path is to split SubjectInfo in two in a different place. Have a HiddenTLSSubjectInfo, and a TransparentTLSSubjectInfo. Then we define a (unabridged) SubjectInfo as a pair of them, and an AbridgedSubjectInfo as the hash of the former, and the full info of the latter. Conceptually this is elegant, but it feels like unnecessary complexity and is messy to present.

davidben commented 10 months ago

Right, so I guess the question is how much of a big deal is it that the whole SubjectInfo gets hashed right now. If it's not that big of a deal (we just lose the key type), just hashing the whole thing is most straightforward.

This is roughly analogous to whether you hash the whole SPKI in X.509 or just the BIT STRING inside it.

bwesterb commented 10 months ago

It'd be nice to be able to track the transition to PQ (see also #38 for the "if you understand PQ, don't trust this extension"), but it's not a blocker. I'm worried it's premature to assume we'll never want transparency on any part of the subject.