[TLS]Re: Trust Expressions Update

[Dennis Jackson <[e-mail]>]

On 21/07/2024 18:09, Kyle Nekritz wrote:

> Do you see differences with trust negotiation, or in the specific negotiation mechanisms that are being proposed? Or would you have similar concerns if, say, we didn't already have named group negotiation, and were discussing adding that right now?

My concerns are about deploying a mechanism for negotiating which 
certificate the server sends that can scale to the divergent 
requirements of many different parties.

Right now, servers are pretty much forced into choosing between being 
available on the WebPKI or being available on some other PKI. There are 
limited mechanisms which do allow servers to select alternative 
certificates (e.g. based on the client's IP or which interface it is 
accessing in corporate environments), but these mechanisms cannot be 
used at scale without causing massive incidental breakage without some 
signal from the client as to which server certs it trusts.

Trust Expression's 'fixes' that restriction and allows servers to 
participate in multiple PKIs simultaneously. Importantly, Trust Labels 
are not limited to some fixed set like signature_algorithms registered 
with IANA. Trust Expression's design requires that TLS libraries accept 
any trust_label conveyed by the CA via the provisioned certificate chains.

Trust labels are basically opaque user-agent strings which can negotiate 
arbitrary things about the contents of the certificate message in TLS. 
This makes it easy for good actors like Chrome to deploy a new 
experiment or new security policies via a new trust label, but also 
empower actors trying to establish their own PKIs with less noble 
intentions (explained further in [1]).

Does that clarify the technical difference between introducing something 
like Trust Expressions and other more limited negotiation mechanisms?

Best, Dennis

[1] 
https://github.com/dennisjackson/trust-negotiation-comments/blob/main/concerns-and-risks.md#root-programs-and-mass-surveillance