Dear all,
It seems that I have missed some updated info about the following TLS WG
document.
Hybrid key exchange in TLS 1.3
draft-ietf-tls-hybrid-design-09
https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
I thought that it was the main approach for TLS PQ migration. However, it ha
On Thu, Apr 4, 2024 at 7:38 PM Mike Bishop wrote:
> Ekr, can I ask you to clarify this a little? I fully agree that extensions
> to TLS which support a particular application-layer protocol should be done
> in that protocol’s working group unless and until it’s demonstrated that
> many unrelated
Ekr, can I ask you to clarify this a little? I fully agree that extensions to
TLS which support a particular application-layer protocol should be done in
that protocol’s working group unless and until it’s demonstrated that many
unrelated applications will need something similar. (At which point
The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'The SSLKEYLOGFILE Format for TLS'
as Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive
Ah, I wonder what the motivation was for it being a MUST rather than a
SHOULD.
That still leaves open sending a private use value - which would allow
you to de-conflict with others uses.
On 04/04/2024 17:11, Jonathan Hoyland wrote:
Hi Dennis,
RFC 7250 Section 4.1 says:
If the client has no
Hi Dennis,
RFC 7250 Section 4.1 says:
If the client has no remaining certificate types to send in
the client hello, other than the default X.509 type, it MUST omit the
client_certificate_type extension in the client hello.
That seems to explicitly exclude sending the single entry 0 to me.
Hi Jonathan,
My reading of RFC 7250 is the same as Mohits. Although the RFC talks
about raw public keys and a new codepoint for them, it is building on
RFC 6091 which defined a similar extension and the X509 codepoint.
It seems fine for you to send the client_certificate_type extension with
> Internet-Draft draft-ietf-tls-tls12-frozen-00.txt is now available. It is a
work item of the Transport Layer Security (TLS) WG of the IETF.
This was just a post-adoption publication to avoid expiry. No changes yet.
___
TLS mailing list
TLS@ietf.org
h
Hi Andrea,
Thanks for sharing the info.
Could you say a bit more about your IoT use case?
Ciao
Hannes
-Original Message-
From: TLS On Behalf Of Andrea Vesco
Sent: Donnerstag, 4. April 2024 10:53
To: tls@ietf.org
Subject: [TLS] I-D on TLS authentication with VC
L. Perugini and I have w
Hi all,
Thanks for the feedback here.
With respect to RFC 7250, as I mentioned earlier on list, there seen to be
two issues. First it changes the semantics of the extension slightly, and
second the RFC explicitly excludes x.509 certs.
IIUC the semantics of the extension are "I have a weird clien
L. Perugini and I have written an I-D on the use of Verifiable Credentials
[1][2] as an additional authentication mode in TLS. We presented the I-D to
the ALLDISPATCH WG during IETF119 and the outcome was to explore the potential
interest of the TLS WG. The I-D proposes to add (i) a new Certifi
11 matches
Mail list logo
