On 30/04/2024 22:33, Brendan McMillion wrote:
This doesn't apply in case we're distrusting a CA because it's
failed. In 9.1 we're rotating keys. As I laid out in my initial
mail, we can already sign the new root with the old root to enable
rotation. There's no size impact to up-to-date clients using
intermediate suppression or abridged certs.
The approach you describe requires the cooperation of the CA, in
signing the new root with the old root. My understanding is that CAs
(especially CAs in trouble with their root program) are often
uncooperative or absentee.
I think one of the two of us is confused. You indicated section 9.1
which explicit describes key rotation where the operator is staying the
same but switching to new keys which is what I responded to. If instead
you're talking about kicking out a CA for bad behaviour, this draft
doesn't really help as I pointed out earlier.
It also requires the CA's customers to go through a full issuance
cycle before they get certificates with the new root, which could take
over a year, during which time the compromised root will still need to
be trusted.
The distrust-after mechanism I mentioned doesn't require trusting the
compromised root during the transition time. SCTs enable us to pin the
valid certificate set to a fixed point in time.
This draft is substantially better than that. It normalizes websites
having multiple certificates from different CAs. In a future world
with widespread adoption of Trust Expressions and ACME, a root could
be distrusted immediately without warning and nothing would break
because websites would transparently switch to their alternate CA.
This deployment model is completely unrealistic and even if it were
practical, would be achieved with ACME alone without trust expressions.
This is predicated on the assumption that either the vast majority of
websites will configure their ACME client with multiple CAs or that the
distrusted CA actively provision replacement certificates from an
alternative CA. It's unclear why websites will want to maintain an
account with a CA they are not actively using for the extremely rare
event that their primary will be distrusted over-night. Alternately,
it's unclear why a CA would cooperate in its removal, they have
literally zero incentive to make their own removal easier.
Let's assuming for a moment we could a) get most of the world to use
ACME (a worthy but challenging goal) and b) get them to configure
multiple CAs and receive multiple certificates. We don't need trust
expressions to be able to do quick rotations - because we don't ever
want to use the old CA. It's just a case of swapping to the new one.
There's no need for negotiation.
During the very very long period in which this is being incrementally
deployed by clients and servers, Trust Expressions is still
substantially better than the approach you describe because it creates
the possibility for clients to negotiate away from a compromised CA
where possible (i.e., even if a website operator has taken no action
but presents multiple certificates, a client can choose a certificate
with a non-compromised root).
This is a repeat of the same point. It's a fantasy to expect that
website operators are going to establish accounts with multiple CAs on
the off chance of a catastrophic distrust. It is literally twice as much
work. In terms of the what the distrust is actually trying to achieve,
we actively want folks to stop using bad certificates from the bad CA
and in that sense, the pain is an essential part of the process in
improving security for everyone.
Again, as a reminder, distrust-after based on SCT dates largely
eliminates the need for overnight distrust decisions. We can already
remove bad CAs gracefully without having to trust them during their
deprecation period.
As has been mentioned, it takes a very long time for TLS extensions to
gain adoption by a broad set of client implementations, server
implementations, and website operators. If we built an extension that
just said "I have an accurate clock, you can send me short-lived
certificates" then it would need adoption by client implementations,
server implementations, and website operators, and this would take a
long time. Trust Expressions creates a happy path where 1.) clients
indicate support for a feature by trusting a fancy new CA, and 2.)
website operators support that feature simply by configuring their
ACME client to get a certificate from that CA. Changing the server
implementation isn't necessary. This happy path seems quite nice and
useful to me
There's a few huge problems with this:
1) Most of the interesting things we want to do require changes to
server implementations, so this doesn't help much.
2) It's extremely questionable that CAs should have the power to
reconfigure servers without the server operator actively opting in.
3) One of the extremely questionable acts that a CA might be
incentivised to do is provision a certificate chain from a domestic
government operated CA alongside the intended one. Helpfully bypassing
the need to convince website operators to use them.
This 3rd problem is exactly what I've been highlighting. If you're
trying to build a domestic government controlled PKI, you run into a
huge adoption challenge:
* No website wants to change to use your government controlled PKI,
because the user's don't support it and the rest of the world won't
ever have it, so the site is effectively blocked.
* There's no legitimate reason for a user to want to install the
government controlled root, because there's no sites that are using.
This draft very neatly solves that challenge. You can provision a large
number of sites with the government cert chain with little work. You
don't even need consent if you use the CA method as you described. Those
sites remain available to both local and international visitors so they
don't really mind unless they're the kind of site with strong opinions
about internet privacy. You can start to push your domestic users onto
using your domestic root store with the argument that a) its locally
supervised so its great and b) loads of local sites already support it.
Later, you have the latitude to start misbehaving or blocking traffic
that doesn't advertise your root store.
Reading between the lines, you seem like a person who would not
ordinarily be in favour of trusting CAs with TLS configuration
decisions, or making it easier to spin up a CA and so increasing the
number of trusted CAs in the world, or having a fragmented PKI along
national borders. This draft directly enables all three and you've yet
to identify an feature that Trust Expressions actually delivers that
isn't already available through simpler, already deployed, means.
On Tue, Apr 30, 2024 at 8:38 AM Dennis Jackson
<ietf=40dennis-jackson...@dmarc.ietf.org> wrote:
As mentioned above, we have such an extension already insofar as
indicating support for Delegated Credentials means indicating a
desire for a very short credential lifetime and an acceptance of
the clock skew risks.
Given how little use its seen, I don't know that its a good
motivation for Trust Expressions.
On 30/04/2024 16:33, Eric Rescorla wrote:
On Tue, Apr 30, 2024 at 8:29 AM Watson Ladd
<watsonbl...@gmail.com> wrote:
On Tue, Apr 30, 2024 at 8:25 AM Eric Rescorla <e...@rtfm.com>
wrote:
>
>
> On the narrow point of shorter lifetimes, I don't think the
right way to advertise that you have an accurate clock is to
advertise that you support some set of root certificates.
>
> If we want to say that, we should have an extension that
actually says you have an accurate clock.
That says you *think* you have an accurate clock.
Quite so. However, if servers gate the use of some kind of
short-lived credential
on a client signal that the client thinks it has an accurate
clock (however that
signal is encoded) and the clients are frequently wrong about
that, we're going
to have big problems.
-Ekr
Sincerely,
Watson
--
Astra mortemque praestare gradatim
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
