[TLS] draft-ietf-tls-oob-pubkey: My summary
Hannes Tschofenig <hannes.tschofenig@gmx.net> Thu, 12 July 2012 07:54 UTC
Return-Path: <hannes.tschofenig@gmx.net>
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 0187021F875A for <tls@ietfa.amsl.com>; Thu, 12 Jul 2012 00:54:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.429
X-Spam-Level:
X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 jU1Uf4sZ8wMU for <tls@ietfa.amsl.com>; Thu, 12 Jul 2012 00:54:19 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id DFAF921F8759 for <tls@ietf.org>; Thu, 12 Jul 2012 00:54:18 -0700 (PDT)
Received: (qmail invoked by alias); 12 Jul 2012 07:54:49 -0000
Received: from unknown (EHLO [10.255.128.232]) [194.251.119.201] by mail.gmx.net (mp070) with SMTP; 12 Jul 2012 09:54:49 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18netw6/Dsneo97R8OqyhzcBJ8fgqRo00fHbLH39b KjbMRCslVls43p
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 12 Jul 2012 10:54:48 +0300
Message-Id: <213AE838-274D-4809-B841-CCCC51C7B3CD@gmx.net>
To: tls@ietf.org, IETF CoRE <core@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
Cc: OAuth WG <oauth@ietf.org>
Subject: [TLS] draft-ietf-tls-oob-pubkey: My summary
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: Thu, 12 Jul 2012 07:54:20 -0000
Hi Erk, Hi Robert, Hi Nikos, thanks for your quick response. Here is an attempt to summarize your input. -------- I use three types of indications in the message exchange below for improved clarity, namely: (a) 'cert-receive=(value-1, value-2, ..., value-n)' with the meaning: "I accept certificate of the following types (value-1, ..., value-n) if you send them to me." The list is ordered by preference. (b) 'cert-send=(value-1, value-2, ..., value-n)' with the meaning: "I could send you certificate of the following types (value-1, ..., value-n) if you ask." The list is ordered by preference. (c) cert-info=(value) with the meaning: "The certificate payload in this message contains a certificate of the following type". I) Server uses Raw Public Keys (client authentication happens at some other layer) (the DANE use case) client_hello, cert-receive=(Raw, X.509) // (1) cert-send=() -> // (2) <- server_hello, cert-info=(Raw),// (3) certificate, // (4) server_key_exchange, server_hello_done client_key_exchange, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data Legend: (1) Client accepts to receive two types of certificates, preferring raw public keys. (2) The client does not have a raw public key nor an X.509 certificate for client authentication. (3) The server decides to sends his raw public key and indicates this in the cert-info field. (4) The certificate payload contains the raw public key. II) Client and Server use Raw Public Keys (the smart object use case - CORE working group) client_hello, cert-receive=(Raw) // (1) cert-send=(Raw) -> // (2) <- server_hello, cert-info=(Raw),// (3) certificate, // (4) certificate_request, // (5) cert-receive=(Raw) // (6) server_key_exchange, server_hello_done cert-info=(Raw), // (7) certificate, // (8) client_key_exchange, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data Legend: (1) Client accepts to receive raw public keys. (2) The client does have a raw public key for client authentication. (3) The server decides to sends his raw public key and indicates this in the cert-info field. (4) The certificate payload contains the raw public key. (5) The server wants to use client authentication and and sends a cert-request. (6) The certificate request asks for a certificate of type 'raw' (knowing that the client supports it from (2)). (7) The client indicates that the certificate payload contains a raw public key (8) Here is the payload of the certificate itself. III) Hybrid Scenario (the OAuth Holder-of-the-Key Use case) client_hello, cert-receive=(X.509, Raw) // (1) cert-send=(Raw) -> // (2) <- server_hello, cert-info=(X.509),// (3) certificate, // (4) certificate_request, // (5) cert-receive=(Raw) // (6) server_key_exchange, server_hello_done cert-info=(Raw), // (7) certificate, // (8) client_key_exchange, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data Legend: (1) Client accepts to receive X.509 certs and raw public keys, in this order of preference. (Could also be X.509 only in this example) (2) The client does have a raw public key for client authentication. (3) The server decides to sends his X.509 cert and indicates this in the cert-info field. (4) The certificate payload contains the X.509 cert. (5) The server wants to use client authentication and sends a cert-request. (6) The certificate request asks for a certificate of type 'raw' (knowing that the client supports it from (2)). (7) The client indicates that the certificate payload contains a raw public key. (8) Here is the payload of the certificate itself. -------- Do these indications clarify the semantic? I personally believe so. Ciao Hannes
- [TLS] draft-ietf-tls-oob-pubkey: My summary Hannes Tschofenig
- Re: [TLS] draft-ietf-tls-oob-pubkey: My summary Robert Cragie
- Re: [TLS] draft-ietf-tls-oob-pubkey: My summary Hannes Tschofenig
- Re: [TLS] draft-ietf-tls-oob-pubkey: My summary Robert Cragie