Hi Brendan, Bas,
On 30/04/2024 05:17, Brendan McMillion wrote:
It seems like, with or without this extension, the path is still the
same: you'd need to force a browser to ship with a government-issued
CA installed. Nothing about this makes that easier. It /is/ somewhat
nice to already have a way to signal that a given client does/doesn't
support the government CA -- but you could just as easily do this with
a simple extension from the private range, so I'm not sure that was a
big blocker.
On 30/04/2024 09:13, Bas Westerbaan wrote:
No need for a new extension: a government can use a specific signature
algorithm for that (say, a national flavour of elliptic curve, or a
particular PQ/T hybrid).
Of course this is possible in theory, there are no standards police, but
this argument overlooks the gargantuan technical and economic costs of
deploying this kind of private extension. You'd need to convince a
diverse population of implementers on both the client and server side to
adopt and enable your thing. This draft if widely implemented as-is
would effectively solve that problem for governments by removing a huge
architectural roadblock. This is the power of the IETF and why decisions
about what TLS extensions to adopt are important. Mark Nottingham has a
longer piece <https://www.mnot.net/blog/2023/11/01/regulators> on this
view.
On 30/04/2024 05:17, Brendan McMillion wrote:
On the other hand, this draft solves a number of existing security
issues, by allowing more rapid distrust of failed CAs,
Can you expand on how this draft enables the more rapid distrust of
failed CAs?
The roadblock to faster distrust has always been how quickly subscribers
of the failed CA are able to migrate. ACME makes this process much
easier, but still requires server operators to reconfigure their ACME
clients. This draft doesn't improve that situation.
An effective technique long-used by Microsoft and Mozilla when
distrusting CAs is to ship a distrust-certs-issued-after signal rather
than an immediate distrust of all issued certificates. This allows
server operators to gradually migrate in line with their usual schedule
of certificate renewals rather than forcing a flag day on the world. I
understand that at least one further major root program is looking at
supporting the same feature.
by allowing clients to signal support for short-lived certificates, etc.
I'm confused by this remark. Are there clients which would tolerate a
certificate if only it had a longer lifetime? Is there any circumstance
in which you would have both a long-life and short-life certificate
available, and you would prefer to serve the long-life cert?
Best,
Dennis
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
