[TLS]Re: Trust Anchor Negotiation Surveillance Concerns and Risks

[Nick Harper <[e-mail]>]

On Fri, Jul 19, 2024 at 8:58 PM Salz, Rich <rsalz=
[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>