Too fast.
Very sorry, it is already linked to that thread.
Weitergeleitete Nachricht
Betreff: Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and
draft-ietf-tls-rfc8447bis
Datum: Wed, 5 Apr 2023 10:47:11 +0200
Von: Achim Kraus
An: Martin Thomson , tls@ietf.org
Let me try to link this thread to the similar question raised during the
implementation of RPK in openssl.
https://mailarchive.ietf.org/arch/msg/tls/9rXQFjYhAS0z-ZJleMVUgWmvhAA/
My personal "favorite interpretation" of
RFC5246 7.4.6. Client Certificate
is to stick to that definition there regardless of the certificate type,
which isn't mentioned there.
"If no suitable certificate is available,
the client MUST send a certificate message containing no
certificates. That is, the certificate_list structure has a
length of zero."
Means: no xYz (e.g. RPK) certificate results in an empty list (3x 0x00).
From the other thread, there seems to be also other certificate types,
which defined this different, but for all, which starts with a 3-bytes
length, the "empty list" will do it.
best regards
Achim
Am 05.04.23 um 08:02 schrieb Martin Thomson:
I mentioned this to Ekr off-list, but I thought I would add one more thing.
What did we conclude about a client that refuses to provide a raw public key
when asked by a server? Are we in a position to change the minimum length from
1 to 0 in the response? The thread didn't really end with a solid conclusion,
other than a note from Ilari indicating that maybe a zero length RPK would be
OK in some libraries.
See: https://mailarchive.ietf.org/arch/msg/tls/9rXQFjYhAS0z-ZJleMVUgWmvhAA/
On Thu, Mar 30, 2023, at 15:59, Martin Thomson wrote:
https://author-tools.ietf.org/diff?doc_1=rfc8446_2=draft-ietf-tls-rfc8446bis-07
might be helpful to others.
I opened a few issues, but the TLS 1.3 revision is very much ready to
be published.
For the 8447 revision, I found that our decision to remove the
definition of the fields for each registry to be difficult. The draft
lists changes, so now this document is no longer an easy reference for
how to register TLS extension bits. Not a big deal and I don't want to
ask the authors to flip flop here, but I wanted to flag it.
On Wed, Mar 29, 2023, at 10:00, Christopher Wood wrote:
As mentioned during yesterday's meeting, this email starts the working
group last call for "The Transport Layer Security (TLS) Protocol
Version 1.3" and "IANA Registry Updates for TLS and DTLS” I-Ds, located
here:
- https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis
- https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis
The WG Last Call will end on April 18, 2023.
Please review the documents and submit issues or pull requests via the
GitHub repositories, which can be found at:
- https://github.com/tlswg/tls13-spec
- https://github.com/tlswg/rfc8447bis
Alternatively, you can also send your comments to tls@ietf.org.
Thanks,
Chris
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
