Re: [TLS] draft-ietf-tls-oob-pubkey-09: client auth, but no client key

Hi Hauke,

with the draft-ietf-tls-oob-pubkey specification the TLS client has a 
way to indicate what certificate types it supports. As such, the TLS 
server knows what certificates it can ask for before sending the 
certificate request message.

Hence, the situation that the client receives a certificate request but 
doesn't actually have a certificate cannot really happen (unless in a 
failure situation). In that case I believe the suitable error response 
by the TLS client would be the one you described from RFC 5246.

Maybe it is worthwhile to point this out in the document to have this 
error case clearly described?

On 09/30/2013 04:51 PM, Hauke Mehrtens wrote:
> RFC 5246 7.4.6 "Client Certificate" says:
>
>        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.
>
> How should a client act when raw public keys are used and the server
> requests client authentication, but there is no public key or no
> suitable public key?
>
> Not adding client_certificate_type to the ClientHello is not enough,
> because this could also indicate that the client supports client
> authentication with X.509 certificates.
>
> I would send an empty client certificate handshake message and no
> certificate verify message and the server should decide, like it is
> specified for X.509 certificates in RFC 5246 7.4.6.

By 'empty' you mean that the certificate_list structure has a length of 
zero (similarly as it is defined in RFC 5246)?

Ciao
Hannes

>
> Hauke
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>