> I think HSTS provides the basis for a more effective solution. It needs
only to be extended with a single additional bit ("Enforce use of PQ
signatures") and it's already well-understood by website operators.
Managing the preload list is a bit unpleasant for browsers, but strictly
speaking the pr
Hi,
I made the following two PRs to remove paywalled normative references.
Paywalled crypto specifications is a cybersecurity risk. People should not have
to pay to implement or analyze TLS 1.3.
Editorial updates to references #1369
https://github.com/tlswg/tls13-spec/pull/1369
Remove normativ
Hi,
The datatracker says this draft has been in state "AD
Evaluation::Revised I-D Needed" for 109 days.
This is about the N-th time this draft has moved at
glacial pace in the coming up on 6.5 years since the WG
-00 draft. With due respect to the author-set, IMO, that
qualifies as "not good eno
Not addressing your main question, I'd like to refine your sketched
migration path for PQ certificates.
On the negative side, I think it's not clear whether we'll reach 4 (clients
stop advertising traditoinal algs) when the CRQC arrives: there could well
be sufficiently many servers that don't sup
On Mon, Feb 3, 2025 at 5:53 AM Dennis Jackson wrote:
> On 01/02/2025 18:00, Eric Rescorla wrote:
>
> > 2. It allows clients to safely force the server to offer a PQ chain
> >even if the client actually is type (3). Normally it wouldn't be
> >safe to only advertise PQ algorithms in signatu
On 01/02/2025 18:00, Eric Rescorla wrote:
2. It allows clients to safely force the server to offer a PQ chain
even if the client actually is type (3). Normally it wouldn't be
safe to only advertise PQ algorithms in signature_algorithms, but
if the server advertises a PQ TA, then the cli
