Hi Rich, Have you read the second draft (draft-beck-trust-anchor-ids)? I think it's conceptually much simpler overall and is hopefully easier to wrap one's head around. There's no JSON structure or relying party / root program split or anything.
The complexity of trust expressions doesn't come from the scope of the mechanism, or any of the things being discussed in this thread. It's simply the result of us trying to engineer around versioning lists of things. Somehow the server needs to correctly interpret ClientHellos from clients that are newer than its certificate, despite trust stores adding and removing CAs over time. That means needing to establish invariants across versions and rules for how both sides work with those invariants. That design, in turn, came from a desire to minimize server operator burden above all else. In most TLS ecosystems, there are far fewer root programs and CAs than server operators. So keeping the communication flow unchanged for server operators (static blob of data from the CA that one can deterministically interpret) is valuable. But the cost of doing so was to introduce a lot of coordination between root programs and CAs. Those entities are fewer and already need to coordinate, but it does sadly make the complete picture more complex. The other draft makes different tradeoffs in the course of solving the same problem. (As they are the same problem, most of the discussions of the goals and their implications are the same). It increases the server operator burden (a DNS extension in an ideal deployment), but we then remove this messy notion of "trust stores" and some of the limitations it implies on what the client can express. The overall system is simpler and, I think, much easier to understand. At the end of the day, the immediate problem both drafts target is quite simple: arrange for the server to pick a certificate path from one of the CAs that the client trusts. It's the same as every other parameter negotiation problem in TLS. You're right to observe we have a broad range of use cases in mind for this problem. However those come from the problem being solved, not individual pieces of the solution. Trust anchor negotiation problem is *the* essential problem when TLS intersects with PKIs. Removing use cases isn't going to simplify the mechanism. Indeed I think this is exactly the sign of targeting the right problem: a single primitive with a simple goal that is naturally applicable to a broad range of use cases in the problem space. (Cf how cipher suite negotiation can be used for a broad range of TLS transitions, or TCP's stream abstraction fits many protocols.) Hope that helps, David On Fri, Jul 19, 2024, 23:58 Salz, Rich <rsalz=40akamai....@dmarc.ietf.org> wrote: > > - I've read it before. I the main issue is that it says "trusted" a > lot. > > > > Yeah, kinda snippy but not necessarily wrong. > > > > I’m a little skeptical of approaches that solve an entire problem space > with one architecture. I’m more skeptical of enough people having the > ability to read and understand the semantics of several pages of JSON > object descriptions. I know I got MEGO[1] a copule of times while reading > it. > > > > Can we simplify things and solve just one problem? > > > > For example, in some off-line discuissions others have mentioned that with > PQ signatures being so big, there are policy decisions that clients might > want to enforce – do you need SCT’s? Do you want OCSP stapling? Maybe it > will be worthwhile to just think about what kind hybrid/PQ policies clients > will want to express? > > > > [1] https://www.collinsdictionary.com/dictionary/english/mego > > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
