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

Hannes Tschofenig <> Fri, 18 October 2013 09:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6478B21F9D7C for <>; Fri, 18 Oct 2013 02:05:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Aonxa-zdBp20 for <>; Fri, 18 Oct 2013 02:05:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7BA3221F995A for <>; Fri, 18 Oct 2013 02:05:48 -0700 (PDT)
Received: from [] ([]) by (mrgmx102) with ESMTPSA (Nemesis) id 0MATlG-1VR0Nt08CY-00Bfz9 for <>; Fri, 18 Oct 2013 11:05:47 +0200
Message-ID: <>
Date: Fri, 18 Oct 2013 11:06:17 +0200
From: Hannes Tschofenig <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Hauke Mehrtens <>,
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:HRSREQMpvMmRF4V398Hs/ZotjKgZ3GI+sHSFjpTRAxQyIihJ5Oz uAl6ZLu3cbDM+rWQYvTyUfwMxcZWKvSgKJnJDeZL4tZ6KbO2fgXtIOhy52GlNH5lA4tNN5x xKNbHK+NM995+bHl2QPMPjeCOsSwSlHC8e2UplAassBaK9rA58vcpe9waISTkS28Vss+XkC o1BBOAn0dpkP2NBCgHEYg==
Subject: Re: [TLS] draft-ietf-tls-oob-pubkey-09: client auth, but no client key
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 18 Oct 2013 09:05:58 -0000

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)?


> Hauke
> _______________________________________________
> TLS mailing list