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

Martin Rex <> Tue, 02 August 2011 20:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6DF6D21F8634 for <>; Tue, 2 Aug 2011 13:10:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.943
X-Spam-Status: No, score=-9.943 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QbkgZPI19N0L for <>; Tue, 2 Aug 2011 13:10:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9025021F85FF for <>; Tue, 2 Aug 2011 13:10:19 -0700 (PDT)
Received: from by (26) with ESMTP id p72KA7Lu015110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Aug 2011 22:10:07 +0200 (MEST)
From: Martin Rex <>
Message-Id: <>
Date: Tue, 02 Aug 2011 22:10:07 +0200
In-Reply-To: <> from "Nikos Mavrogiannopoulos" at Jul 28, 11 11:42:25 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
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: Tue, 02 Aug 2011 20:10:20 -0000

Nikos Mavrogiannopoulos wrote:
> 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?

I find the idea of extending rfc6091 with a new certificate type
for raw keys more appealing that a completely new TLS extension.

I also prefer the server key to part of the full TLS handshake, so that
the situation "client doesn't trust server key" or "client expected
different server key" can be reliably distinguished from other reasons
of a Finished message verification failure.