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
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
