Re: [TLS] draft-ietf-tls-oob-pubkey: The Open Issue

Nikos Mavrogiannopoulos <nmav@gnutls.org> Wed, 11 July 2012 15:16 UTC

Return-Path: <n.mavrogiannopoulos@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E385C21F867A for <tls@ietfa.amsl.com>; Wed, 11 Jul 2012 08:16:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id br4CwwLKbRje for <tls@ietfa.amsl.com>; Wed, 11 Jul 2012 08:16:11 -0700 (PDT)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C0D2721F8679 for <tls@ietf.org>; Wed, 11 Jul 2012 08:16:07 -0700 (PDT)
Received: by eekd4 with SMTP id d4so466436eek.31 for <tls@ietf.org>; Wed, 11 Jul 2012 08:16:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=GNCF1gfrKZYUMH2OopZXy4EZjlbjV5D62sFAWMBEJMU=; b=U8tiNyat1jnCQIDa5ynoBaM1HcoLU1UxMORsivjU5dy98jRJBg6I0kbTsgwjokIvqn KI7ld+4cx+pBx6vpZlsvjE1FmuhJ/hmPrgFwRah/loMP01ESzZ4gGPKKi/57P2G5A3QV aWXDWMtE5K3jd55GrKI5QbVCEQVKm+DffsB+3EGgi0V7IVSNOvKmmBYk4pfBK/TbPH6p UXkovwVooVTTD6EQHj8JPlruL51RV2LE2NJo9wCzpUecNEh+Rv/eiUGZ0BmBAC0qZesn 7lczn7eJ572TTb7XmQMO3ahUw7dEei+uDsJors3jz4TcjlUi2+Bhlmz57O2iNP0i3X/g SsJA==
Received: by 10.14.119.3 with SMTP id m3mr11630444eeh.204.1342019797804; Wed, 11 Jul 2012 08:16:37 -0700 (PDT)
Received: from [10.100.2.17] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id y54sm6720185eef.10.2012.07.11.08.16.36 (version=SSLv3 cipher=OTHER); Wed, 11 Jul 2012 08:16:36 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <4FFD98D4.1090000@gnutls.org>
Date: Wed, 11 Jul 2012 17:16:36 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4
MIME-Version: 1.0
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
References: <1CA8C4CB-1FD8-4498-9988-41B6334F58FD@gmx.net>
In-Reply-To: <1CA8C4CB-1FD8-4498-9988-41B6334F58FD@gmx.net>
X-Enigmail-Version: 1.4.1
OpenPGP: id=96865171
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-oob-pubkey: The Open Issue
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Jul 2012 15:16:12 -0000

On 07/11/2012 12:56 PM, Hannes Tschofenig wrote:

> Hi all, 
> 
> draft-ietf-tls-oob-pubkey specifies a new TLS certificate type for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) for use with out-of-band public key validation.
> 
> Here is the latest draft: 
> http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-03
> 
> I would be great to get your feedback on an open issue that concerns the semantic of the exchange. I believe there are three use cases we would like to support with this work. Below, I provide high level message exchanges to explain those: 
> I) Server uses Raw Public Keys (client authentication happens at some other layer)


If you don't need a client certificate or public key, you don't send a
certificate request.

> II) Client and Server use Raw Public Keys
> (the smart object use case - CORE working group)


Your draft already covers that case.

> II) Hybrid Scenario

> (the OAuth Holder-of-the-Key Use case)

(server X.509 certificate, client raw public key)

I see two options. 1. You overload the ClientCertificateType of the
certificate request with a raw_rsa_sign that does what you intend. 2.
You create a new extension that modifies the format of the certificate
request to include an explicit certificate format.

regards,
Nikos