Hi Dennis, thanks for your feedback.
First, you mention the issue of the possible requirement of key escrow; we
don’t feel that trust expressions make this any more or less of a threat to
the ecosystem. Were a government to require sites to escrow private keys,
it would not matter who signed them since the escrow agent would be in
possession of those private keys, and they or anyone else they give the
private key to would be in the position to compromise connections using
these keys. We hope we can set this point aside as orthogonal to the
remaining bulk of your objections.
Second, there seems to be a concern surrounding trust expressions making it
easier for root stores to diverge due to the multi-certificate model. Trust
stores already diverge today. As you’re likely aware, there are very good
reasons that root programs do not coordinate on trust decisions, so this is
not something that will change in the foreseeable future.
As root programs diverge, subscribers are (often unwittingly) forced to
choose which clients to break as they try to stay within the intersection.
This conflict also impacts root programs by pressuring against trust
changes. The users whose security would benefit from those changes
ultimately bear this cost. We don’t think that a resigned acceptance of the
sharp edges of the status quo is a compelling reason to continue forgoing
trust anchor agility, especially when we are faced with the need to
radically change the entire landscape to accommodate PQC’s large
signatures. In practice, we also don’t think this plays out such that the
long tail of clients are dragged along into security by browsers and other
modern clients. Instead, the state of the art is held back by the long tail.
The multi-certificate model empowers subscribers with the optional ability
to support divergent client trust if they choose to. As an example, one
root program could adopt new post quantum roots and provide immediate
protection for their users without waiting for the slowest or
least-resourced client/browser vendor to follow suit. Other root programs
and their clients would be unaffected by this change and could roll out the
same change on a different timeline or opt for a different approach
altogether.
By design, a multi-certificate model removes the ubiquity requirement for a
trust anchor to be potentially useful for a server operator. Your concern
seems to be that this could be a way for governments to coerce one root
program to include specific trust anchors and increase mass surveillance.
This is an outcome that root programs, including both Chrome and Mozilla,
have fought against for many years and will continue to do so. This has
been a motivating force behind technologies like certificate transparency,
which enables detection and response to this kind of behavior (and would
continue to exist in some form regardless of trust expressions). I think we
are in agreement with the severity of these hypothetical scenarios, but
strongly disagree at the causality you are drawing between the existence of
a negotiation mechanism and this dystopian end state. In particular,
surveillance requires targeted clients to somehow trust an incorrect key
for a server. If the attacker’s CA is trusted by a client, it can already
sign bad keys. Surveillance only requires inclusion in the root store, it
does not matter whether the attacker’s CA was also useful for server
operators. Signing the correct key for a server does not help the attacker.
This is why we did not add this as a risk to the draft, however we are
happy to add a broader discussion of implications of root program
divergence to a future version.
Looking at the things we believe trust expressions does bring to the table
to improve the security of relying parties:
-
The ability for PKIs to transition to newer root keys, instead of
waiting for ubiquitous adoption of a replacement by all root programs.
-
The ability for TLS certificate selection to be robust enough that
selection can occur entirely within the TLS library and server software.
Server operators can safely add certificates for new algorithms, without
compatibility risks that some client supports the new algorithm, but not
the particular trust anchor.
-
The ability to deploy PKI improvements without conflicts from differing
requirements and schedules in individual root programs and very old clients.
-
The ability to support everything else that does not use trust
expressions, even old devices that can not / will not update, without
impacting relying parties that wish to move ahead faster.
-
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.
-
The ability for server operators seamlessly to deploy certificates from
multiple CAs for redundancy, or to straddle disparate ecosystems.
We acknowledg
