Thx David. The spirit of the draft is clearer now.
ACK about the miscalculated signature. I was counting the sig in the signed
window, but indeed that does not take place with every connection.
I think I understand your point about delegating trust. You basically say that
if we could have an ac
Richard, yes, you git it right.
From: Richard Barnes
Date: Tuesday, March 21, 2023 at 4:32 PM
To: Blumenthal, Uri - 0553 - MITLL
Cc: tls@ietf.org
Subject: Re: [TLS] Resurrect AuthKEM?
Hi Uri,
Just to be clear, the AuthKEM draft you mean is this one?
https://datatracker.ietf.org/doc/draft-celi
Hi Uri,
Just to be clear, the AuthKEM draft you mean is this one?
https://datatracker.ietf.org/doc/draft-celi-wiggers-tls-authkem/
Assuming that's the case, in case anyone else is confused (as I was), the
"AuthKEM" here does not refer to a KEM implementing the AuthEncap/AuthDecap
interface from
I’m surprised to see that there isn’t much (isn’t any?) discussion of the
AuthKEM draft.
It seems pretty obvious that with the advent of PQ algorithms, the sheer sizes
of signatures and public keys would make {cDm}TLS existing authentication and
key exchange impractical in bandwidth-constra
On Tue, Mar 21, 2023 at 8:01 AM Hubert Kario wrote:
> On Monday, 20 March 2023 19:54:24 CET, David Benjamin wrote:
> > I don't think flattening is the right way to look at it. See my
> > other reply for a discussion about flattening, and how this does
> > a bit more than that. (It also handles SC
On Monday, 20 March 2023 19:54:24 CET, David Benjamin wrote:
I don't think flattening is the right way to look at it. See my
other reply for a discussion about flattening, and how this does
a bit more than that. (It also handles SCTs.)
As for RFC 7924, in this context you should think of it as
