On Sat, Feb 04, 2023 at 07:25:31PM +0100, Achim Kraus wrote:
> My interpretation of RFC5246, 7.4.6 Client Certificate
>
> https://www.rfc-editor.org/rfc/rfc5246.html#section-7.4.6
>
> "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."
>
> covers RFC7250 as well. That section doesn't say something about
> the certificate type and so in my interpretation it applies general
> to all certificate types, including RPK.
>
> So, even if RPK is negotiated for the client, the client complies
> to RFC5246, 7.4.6 sending a empty list in order to indicate, that
> "no suitable certificate is available".
The apparent issue with that interpretation, is that strictly speaking,
when the certificate type is RPK, there is no list length (it lives only
in the X.509 variant of the structure), all we have is an RPK length.
There's a conflict between TLS 1.2 and RFC7250, that is only properly
resolved in TLS 1.3. What is the sensible/interoperable strategy for
TLS 1.2?
FWIW, here's what "tshark" thinks of an empty RPK in the client
Certificate message:
Transport Layer Security
TLSv1.2 Record Layer: Handshake Protocol: Certificate
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 7
Handshake Protocol: Certificate
Handshake Type: Certificate (11)
Length: 3
Certificate Length: 0
[Expert Info (Warning/Protocol): Vector length 0 is smaller than
minimum 1]
[Vector length 0 is smaller than minimum 1]
[Severity level: Warning]
[Group: Protocol]
Certificate: 1603030025
BER Error: Sequence expected but class:UNIVERSAL(0) Primitive
tag:22 was unexpected
[Expert Info (Warning/Malformed): BER Error: Sequence expected
but class:UNIVERSAL(0) Primitive tag:22 was unexpected]
[BER Error: Sequence expected but class:UNIVERSAL(0) Primitive
tag:22 was unexpected]
[Severity level: Warning]
I'd, of course, prefer if 0-length were generally interpreted as RPK
absence even in TLS 1.2, but I am not sure that'll interoperate well,
or what if anything can/should be done about that.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
