Cosigner negotiation

[lukevalenta]

RPs might have disjoint sets of cosigners, so we should have cosigner negotiation in the TLS handshake to allow APs to send only the required cosignatures in standalone certificates.

(I didn't see an existing ticket tracking this yet.)

[bwesterb]

Cf. tlswg/tls-trust-anchor-ids#54

[ilaril]

Furthermore, log cosigners can be rotated, which can cause certificates to be unusable. And if cosigners can have group identifiers, certificates can be unusable due to not having any supported algorithms.

[davidben]

@ilaril I think you may be assuming a very different model of cosigner than is actually is in MTC.

First, the cosigner definition includes the signature algorithm. This is not like X.509 where one signer can be used with multiple algorithms. You cannot trust a cosigner without supporting that signature algorithm. That means saying "I support cosigner X" includes "I support X's signature algorithm". Indeed the individual cosignatures in the certificate don't even specify the signature algorithm. This is intentional. If you know the cosigner, you know the signature algorithm and can verify the signature. If you don't, you ignore the cosignature and don't care what it was.

If a system were to rotate cosigners, the expectations is it would make a new one but continue to have the old one sign it. (Rotation is about switching which one new RPs trust.) Cosigners act like SCTs. You collect as many of them as you need, based on the union of the RPs you need to support. RPs ignore the ones that don't want. Of course, sending extra ones uses bytes, but...

1. In the long run, hopefully landmark-relative certificates will be used most of the time, reducing the size pressure on the slow path.

2. Unlike SCTs, we didn't embed them in the TBSCertificate. They are in the signature field and malleable. When we talk about cosigner negotiation, we mean designing a way for the server to optionally (remember sending them all works) delete the ones the RP doesn't want.

Now, ideally we would just have cosigner negotiation. But until we do, we can always lean on how CT operates. Every CT-enforcing client in the Web PKI today shuts off CT enforcement if it's config is more than 10 weeks stale. That bounds how old of clients you have to union in your SCT collection.

Analogously, until we have a clear cosigner negotiation story, every transparency-enforcing client in an MTC PKI should shut off non-CA cosigner enforcement when too stale. That gives you a similar bound.

Is this ideal? No, it makes it hard to use a lot of the full operational flexibility of MTC cosigners. And shutting off transparency enforcement on a timer is terrible. That's why we have issues open for cosigner negotiation. But it's what CT is experienced with today. We pay a horrible RP shut-off timer, but that makes it much much more bounded than the CA-level problem.

Once cosigner negotiation is designed, we can remove the staleness check in clients that implement their part of it, because now you can collect negotiable cosigs for those clients. We'll need to design that transition when it comes, accounting for old and new servers, but since it always works to send all of them, I think we can ensure things keep working.

[davidben]

(Re group IDs, I plan to update that PR to explain what's going on there a bit better but am on a plane right now. I suspect we're not talking about the same thing.)

[ilaril]

@ilaril I think you may be assuming a very different model of cosigner than is actually is in MTC.

I actually have two different models of cosigners. I think one is what the MTC model looks in practice, and the other is very different from it.

First, the cosigner definition includes the signature algorithm. This is not like X.509 where one signer can be used with multiple algorithms. You cannot trust a cosigner without supporting that signature algorithm.

Yes, trusting individual cosigner implies supporting its algorithm. But trusting group of cosigners does not.

If a system were to rotate cosigners, the expectations is it would make a new one but continue to have the old one sign it. (Rotation is about switching which one new RPs trust.)

I would expect the old cosigner to be eventually dropped. Draft-ietf-plants-merkle-tree-certs-02 says "until relying parties are all updated" (I think that is rather optimistic).

Now, ideally we would just have cosigner negotiation. But until we do, we can always lean on how CT operates. Every CT-enforcing client in the Web PKI today shuts off CT enforcement if it's config is more than 10 weeks stale. That bounds how old of clients you have to union in your SCT collection.

That kind of thing does not help if RP has missed complete primary log key rotation.

Is this ideal? No, it makes it hard to use a lot of the full operational flexibility of MTC cosigners. And shutting off transparency enforcement on a timer is terrible. That's why we have issues open for cosigner negotiation. But it's what CT is experienced with today. We pay a horrible RP shut-off timer, but that makes it much much more bounded than the CA-level problem.

I do not think why CT can do that applies to MTC.

Once cosigner negotiation is designed, we can remove the staleness check in clients that implement their part of it, because now you can collect negotiable cosigs for those clients. We'll need to design that transition when it comes, accounting for old and new servers, but since it always works to send all of them, I think we can ensure things keep working.

I think the biggest issue here is that MTC is poor match to the TAI model. Cosigner negotiation without constraints looks fairly easy problem (even if one throws in some complications). But in TAI model, it looks crazy hard.

[davidben]

Yes, trusting individual cosigner implies supporting its algorithm. But trusting group of cosigners does not.

I mean, trust a group of cosigners does not imply anything right now. The group stuff is barely written down at all, and how it might apply to cosigner negotiation is definitely not yet written down. :-)

Cosigner negotiation, because we can start with the CT-like approach, is I think mostly a problem for later. I do very much want it solved and have random half-baked thoughts on it, but they're only half-baked and I have limited bandwidth. Though it sounds like you're very interested in this, and have some thoughts, so this is great!

The groups thing was mostly targeting:

• Condensing the ID space for negotiating landmark-relative certificates (no cosigners to worry about)
• Reducing and perhaps eliminating the need for the DNS scheme, when looking at specifically lists of trust anchors

In both of these, I don't see why we'd treat a group of trust anchors vs individual ones as dramatically different. It's still the case that you shouldn't compress with a group unless you (more-or-less) support everything in group. I say more-or-less because there's some room for sloppiness with the retry scheme, but I also don't think it's a good idea to lean on it too much. New signature algorithms also just don't get added that often. We change the keys we trust much more often.

Between all that, I wouldn't expect there to be much need to add separate constraints.

I would expect the old cosigner to be eventually dropped. Draft-ietf-plants-merkle-tree-certs-02 says "until relying parties are all updated" (I think that is rather optimistic).

It is indeed optimistic. I expect this "until" to be quite long for most PKIs. (Though not all! Some PKIs have very up-to-date RPs.)

But, in the meantime, MTC lets you sign with both keys for basically as long as you like. The security value of rotating keys is to change what the RP trusts, and this is sufficient to do that. Yes, the CA has to do a little more work to sign with both keys in parallel, but there is no security cost to just signing both for a very long time. That "until" is only there to acknowledge that, yeah, at some point folks will eventually abandon the old RPs.

The draft mentions all this because this is interesting new capability, relative to today's story where we basically do not rotate root keys ever. That doesn't mean CAs are expected to quickly stop signing with both keys, or that we want to rotate so frequently that you build up a bunch of them. There's still a cost, especially before the ecosystem can drop the unnecessary keys. Would we use it instead of just getting everyone to negotiate at the level of CAs? 🤷

That kind of thing [CT's stale client behavior] does not help if RP has missed complete primary log key rotation.

Right, like I said, that was just about the non-CA cosigners. But this reduces the problem to just the primary signature, which makes it look more like the regular X.509 picture. (We'd been talking elsewhere about how MTC and regular X.509 actually are here.) MTC gives you the added option of signing with both keys, but otherwise all the same solutions as before apply.

I do not think why CT can do that applies to MTC.

Oh? Perhaps I'm missing something. What aspect are you concerned about? SCTs and MTC non-CA cosignatures seem quite analogous to me. (Of course one should not shut off enforcement of the CA cosignature!) Certainly, when we think about the relying party policies, they've been basically analogous.

If anything, the MTC ones seem more robust because mirrors and witnesses are simpler to run than CT logs. A lot of failures that would sink a CT logs today are moved to the CA side and can just bump a log generation (once that's written down...). We also wouldn't need to shard the cosigners by year, like we do with CT logs today.

I think the biggest issue here is that MTC is poor match to the TAI model. Cosigner negotiation without constraints looks fairly easy problem (even if one throws in some complications). But in TAI model, it looks crazy hard.

Oh? What is your easy proposal? What do you think is a poor match? This sounds like we're talking about our mental versions of various unwritten ideas. It'd certainly be a lot less confusing for me to talk about more concrete things. 😆

[ilaril]

Yes, trusting individual cosigner implies supporting its algorithm. But trusting group of cosigners does not.

I mean, trust a group of cosigners does not imply anything right now. The group stuff is barely written down at all, and how it might apply to cosigner negotiation is definitely not yet written down. :-)

Well, it might be a bad idea after all.

Cosigner negotiation, because we can start with the CT-like approach, is I think mostly a problem for later. I do very much want it solved and have random half-baked thoughts on it, but they're only half-baked and I have limited bandwidth. Though it sounds like you're very interested in this, and have some thoughts, so this is great!

Unfortunately, those start at model different from TAI.

* Reducing and perhaps eliminating the need for the DNS scheme, when looking at specifically lists of trust anchors

I do not think that is possible, unfortunately.

In both of these, I don't see why we'd treat a group of trust anchors vs individual ones as dramatically different. It's still the case that you shouldn't compress with a group unless you (more-or-less) support everything in group.

With sufficient data, AP can filter by signature_algorithms_cert.

I would expect the old cosigner to be eventually dropped. Draft-ietf-plants-merkle-tree-certs-02 says "until relying parties are all updated" (I think that is rather optimistic).

It is indeed optimistic. I expect this "until" to be quite long for most PKIs. (Though not all! Some PKIs have very up-to-date RPs.)

Well, it would be fine for algorithm updates, as those can drag for really long. I think the last major one took a decade. :-)

That kind of thing [CT's stale client behavior] does not help if RP has missed complete primary log key rotation.

Right, like I said, that was just about the non-CA cosigners. But this reduces the problem to just the primary signature, which makes it look more like the regular X.509 picture. (We'd been talking elsewhere about how MTC and regular X.509 actually are here.) MTC gives you the added option of signing with both keys, but otherwise all the same solutions as before apply.

I think the added capabilities of MTC here are most interesting in context of algorithm updates.

If anything, the MTC ones seem more robust because mirrors and witnesses are simpler to run than CT logs. A lot of failures that would sink a CT logs today are moved to the CA side and can just bump a log generation (once that's written down...). We also wouldn't need to shard the cosigners by year, like we do with CT logs today.

MTC can be very robust. Robust enough to not even need generations.

I think the biggest issue here is that MTC is poor match to the TAI model. Cosigner negotiation without constraints looks fairly easy problem (even if one throws in some complications). But in TAI model, it looks crazy hard.

Oh? What is your easy proposal? What do you think is a poor match? This sounds like we're talking about our mental versions of various unwritten ideas. It'd certainly be a lot less confusing for me to talk about more concrete things. 😆

In the simplest version: List of cosigners to filter. And one can throw various stuff on top. And it is poor match, since TAI is essentially single-axis, but MTC has two (logs and cosigners).

[davidben]

In the simplest version: List of cosigners to filter. And one can throw various stuff on top. And it is poor match, since TAI is essentially single-axis, but MTC has two (logs and cosigners).

Ah sure. That doesn't capture things like, maybe I only needed two of the three matches. But that might be a good enough for an upper bound.

The other (half-baked) direction I'd been musing on was to give names for policies, tell the AP "this policy is satisfied by this set, this by this set, etc", and if you don't have a match, eh we just send them all, or fall back to some other upper bound like what you described above.

[ilaril]

"various stuff on top" includes things like partitioning the set plus required partition count. One could represent 2 primary cosigners plus 2 out of 11 independent sets of secondaries in 8 bytes.

[ilaril]

Now that there can be only one CA co-signer, I would estimate that typical transparency policy could be compressed to something like 100-120 bytes (with majority of that space taken by known co-signer IDs).