I support moving forward with this document.
On Wed, 25 Oct 2023 at 04:49, Andrei Popov
wrote:
>
> Hi TLS,
>
>
>
> We would like to re-introduce
> https://datatracker.ietf.org/doc/draft-davidben-tls13-pkcs1/
>
> (it’s intended for the TLS WG and the Standards track, despite what the
> document
On Fri, Oct 27, 2023 at 2:07 PM Benjamin Kaduk wrote:
> On Tue, Oct 24, 2023 at 10:12:56PM -0400, David Benjamin wrote:
> >Additionally I want to emphasize that, because of the negotiation
> order
> >between versions and client certificates, there is no way to do an
> >incremental tra
On Tue, Oct 24, 2023 at 10:12:56PM -0400, David Benjamin wrote:
>Additionally I want to emphasize that, because of the negotiation order
>between versions and client certificates, there is no way to do an
>incremental transition here. Saying deployments stick with 1.2 not only
>impa
Some changes from the last time this was posted:
- Apparently we got early codepoint allocation for this and I forgot about
it? Anyway the allocated codepoints are now in the draft.
- We've crisped up the motivation a bit.
One thing I'll call out is that the previous discussion mentioned one could
This is similar to the case when a server is unable to use its RSA key to
sign with PSS passing (my slides for TLS WG in 2015
https://www.ietf.org/proceedings/94/slides/slides-94-tls-4.pdf , presented
by Eric), but instead this is about client keys/signatures.
I don't have a stake in this currentl
Hi TLS,
We would like to re-introduce
https://datatracker.ietf.org/doc/draft-davidben-tls13-pkcs1/
(it's intended for the TLS WG and the Standards track, despite what the
document says at the top; we'll fix it as soon as the submission tool reopens).
In the course of TLS 1.3 deployment, it beca
