Thanks for the thoughts!
> To that end, perhaps it's most useful to focus in on the post-quantum
case, as I think that's the one that the WG finds most compelling.
That's certainly not the use case I find most compelling. It's one among a
class of PKI scenarios, just as PQ is not the only reason
Well, the other thing about HSTS is that it's specified to be only "for web
sites" It is right in the first sentence.
"This specification defines a mechanism enabling web sites..."
I asked about this with regard to ACME, and they told me to get lost. Fine
(also kind of funny), but we need to be c
On Sat, Feb 1, 2025 at 10:02 AM Eric Rescorla wrote:
> Starting a new thread to keep it off the adoption call thread.
>
> I'm still forming my opinion on this topic. To that end, perhaps it's
> most useful to focus in on the post-quantum case, as I think that's
> the one that the WG finds most co
On 04/02/2025 14:10, Bas Westerbaan wrote:
I just sketched one with a signal in the certificate. You point out
some valid deployment challenges, but they're far from disqualifying
the approach from the start, and we should give the general direction
a chance.
Always worth exploring new directi
>
> 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
> speak
> 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
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
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
