Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt

Nikos Mavrogiannopoulos <> Thu, 28 July 2011 21:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5923721F8BF1 for <>; Thu, 28 Jul 2011 14:42:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z+01Tp7utIEG for <>; Thu, 28 Jul 2011 14:42:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 20EB921F8BCE for <>; Thu, 28 Jul 2011 14:42:28 -0700 (PDT)
Received: by wwe5 with SMTP id 5so1976261wwe.13 for <>; Thu, 28 Jul 2011 14:42:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=hE+cuDqnB6Kf/suYQWu/CNwUKVZpBKGJ2hSl6QpdNd8=; b=ImDDovI9Muc4E2jlgw7r36ZompArar4+8kC4DnowyKAR7rYQbPCtlxSF4SWbzXdOMC jsgttnK56SBNRPYB4BNmT/OlNeyptpKr5wb1ZC9PlTKyUYXtWmDNp+9I12fmD3CKNbnS nj3fJ+eHL+OeDrHw168bdkH5SWwba9T+n/5Ng=
Received: by with SMTP id s15mr610398wbz.68.1311889347831; Thu, 28 Jul 2011 14:42:27 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id h1sm997348wee.1.2011. (version=SSLv3 cipher=OTHER); Thu, 28 Jul 2011 14:42:26 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <>
Message-ID: <>
Date: Thu, 28 Jul 2011 23:42:25 +0200
From: Nikos Mavrogiannopoulos <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.2
OpenPGP: id=96865171
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt
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: Thu, 28 Jul 2011 21:42:30 -0000

On 07/28/2011 08:01 PM, Paul Wouters wrote:

>> The trusted_ca_keys TLS extension itself is a simple/lightweight 
>> extension in that it does _not_ modify the syntax or semantics of 
>> any other TLS handshake messages (besides the TLS extensions 
>> container in ClientHello and ServerHello).
> trusted_ca_keys changes sending the CA bundle with EE-cert PKIX blob
>  with only the EE-cert PKIX blob. I am proposing to send only the 
> subjectPublicKeyInfo PKIx blob. It's not different a change of 
> semantics.
>> In TLS WG we definitely need to keep an eye on TLS extension not 
>> duplicating each other resulting in conflicts an interop problems.
> Hency my method that is suitable not just for DANE, but for any 
> non-PKIX out of band authentication.

I see two use-cases here. One is to be able to send raw public keys
(whether a certificate has been communicated out-of-band seems pretty
irrelevant), and the other to reduce bandwidth and (possibly
round-trips) by not sending any certificates, either because they have
been cached or because they are obtained out-of-band.

I think of those of two distinct issues, but before going and
solving them check whether it is worth the effort.
draft-ietf-tls-cached-info tried to solve the bandwidth
problem, but as far as I know it has never been implemented.

The other goal of yours of sending raw public keys might as
well be solved by defining a new certificate type RAW in the
certificateType registry defined in RFC6091 and send anything you like
in the "Certificate" message. You don't need WG consensus to do that.
But do you really have a use case that makes all that effort
worthwhile? Why would others be interested into implementing
the RAW keys you are proposing?