[TLS] Fwd: WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

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 <achimkraus@gmx.net>
An: Martin Thomson <mt@lowentropy.net>, 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&doc_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