On Fri, Jul 19, 2024 at 8:58 PM 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? > >From my perspective, this draft does solve just one problem: how a server chooses a certificate to use that it knows the client will trust. I had a similar reaction the first time I read the Trust Expressions draft. Trust Anchor IDs ( https://www.ietf.org/archive/id/draft-beck-tls-trust-anchor-ids-00.html) is a simpler to understand mechanism that solves the same problem in a different way. > > > 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
