On 23/05/2024 17:41, David Benjamin wrote:
On Thu, May 23, 2024 at 11:09 AM Dennis Jackson
<ietf=40dennis-jackson...@dmarc.ietf.org> wrote
This is something that I believe David Benjamin and the other
draft authors, and I all agree on. You and Nick seem to have
misunderstood either the argument or the draft.
David Benjamin, writing on behalf of Devon and Bob as well:
By design, a multi-certificate model removes the ubiquity
requirement for a trust anchor to be potentially useful for a
server operator.
[...]
Server operators, once software is in place, not needing to be
concerned about new trust expressions or changes to them. The
heavy lifting is between the root program and the CA.
From the Draft (Section 7):
Subscribers SHOULD use an automated issuance process where the CA
transparently provisions multiple certification paths, without
changes to subscriber configuration.
The CA can provision whatever chains it likes without the
operator's involvement. These chains do not have to be trusted by
any clients. This is a centralized mechanism which allows one
party (the CA) to ship multiple chains of its choice to all of its
subscribers. This obviously has beneficial use cases, but there
are also cases where this can be abused.
Hi Dennis,
Since you seem to be trying to speak on my behalf, I'm going to go
ahead and correct this now. This is not true. I think you have
misunderstood how this extension works. [...]
Hi David,
The certification chains issued to the server by the CA comes tagged
with a list of trust stores its included in. The named trust stores are
completely opaque to the server. These chains and names may not be
trusted by any client nor approved by any server, they are issued solely
by the CA as opaque labels. These chains sit on the server and will not
be used unless a client connects with the right trust store label but
obviously can easily be scanned for by anyone looking to check how
pervasively deployed the alternate trust store is.
Do you dispute any part of that? Most of what you wrote went off on a
completely different tangent.
Of course, whether this property (whether servers can usefully
pre-deploy not-yet-added trust anchors), which trust expressions does
not have, even matters boils to whether a root program would
misinterpret availability in servers as a sign of CA trustworthiness,
when those two are clearly unrelated to each other.
Again, my primary concern here is not around the behavior of individual
root stores, this is not relevant to the concern I'm trying to
communicate to you. I know folks from all of the major root stores have
great faith in their judgement and technical acumen.
My concern is that Trust Expressions upsets a fragile power balance
which exists outside of the individual root stores. There is an eternal
war between governments pushing to take control of root stores and the
security community pushing back. This battle happens in parliaments and
governments, between lawmakers and officials, not within root stores and
their individual judgement largely does not matter to this war. The
major advantages we as the security community have today are that:
a) These attempts to take control for surveillance are nakedly
obvious to the local electorate because crappy domestic roots have no
legitimate purpose because they can never achieve any real adoption.
b) If a root store were to bow to pressure and let in a root CA
used for interception, every other country has an interest in preventing
that. An international WebPKI means that we are either all secure, or
all insecure, together.
Trust Expressions, though intended to solve completely different
problems, will accidentally eradicate both of these advantages. Firstly,
it provides a nice on ramp for a new domestic trust store, mostly
through the negotiation aspect but also through the CA pre-distribution.
Secondly, by enabling fragmentation along geographic boundaries whilst
maintaining availability of websites. Without Trust Expressions, we
cannot balkanize TLS. With Trust Expressions, we can and we know people
who want to (not anyone in this thread).
If you still do not understand this wider context within which all of
our work sits, I do not think further discussion between you and I is
going to help matters.
I would suggest we focus our discussion on the use cases of Trust
Expressions and how exactly it would work in practice - these concerns I
shared earlier in the thread are solely technical and operational and
you and I might be able to make better progress towards a common
understanding.
Best,
Dennis
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
