Subject: [core] draft-ietf-tls-oob-pubkey: My summary

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 12 Jul 2012 10:54:48 +0300

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

---

From: Robert Cragie <[email-masked]>
Date: Thu, 12 Jul 2012 13:57:39 +0100

Hi Hannes,

The only one thing I am not sure about is the necessity for cert-send. 
This is because traditionally the server makes the decision on whether 
to request a certificate from the client and would not know a priori 
whether the client supports it. That's not to say it isn't a good idea 
though.

On that basis, I would modify the exchange slightly - see below.

Robert

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

                           <-  server_hello,
                               cert-info=Raw, // (2)
                               certificate, // (3)
                               server_key_exchange,
                               server_hello_done

client_key_exchange,
change_cipher_spec,
finished                  ->

                           <- change_cipher_spec,
                              finished

Legend:

(1) The client accepts reception of X.509 certs and raw public keys, 
preferring raw public keys.
(2) The server decides to sends his raw public key and indicates this in 
the cert-info field.
(3) The server 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)

                           <-  server_hello,
                               cert-info=Raw,// (2)
                               certificate, // (3)
                               certificate_request, // (4)
                               cert-receive=(Raw) // (5)
                               server_key_exchange,
                               server_hello_done

cert-info=Raw, // (6)
certificate, // (7)
client_key_exchange,
change_cipher_spec,
finished                  ->

                           <- change_cipher_spec,
                              finished

Legend:

(1) The client accepts reception of raw public keys.
(2) The server decides to sends his raw public key and indicates this in 
the cert-info field.
(3) The server certificate payload contains the raw public key.
(4) The server wants to use client authentication and and sends a 
certificate-request.
(5) The server accepts reception of raw public keys.
(6) The client indicates that the certificate payload contains a raw 
public key.
(7) The client certificate payload contains the raw public key.

client_hello,
cert-receive=(X.509, Raw) -> // (1)

                           <-  server_hello,
                               cert-info=X.509,// (2)
                               certificate, // (3)
                               certificate_request, // (4)
                               cert-receive=(Raw) // (5)
                               server_key_exchange,
                               server_hello_done

cert-info=Raw, // (6)
certificate, // (7)
client_key_exchange,
change_cipher_spec,
finished                  ->

                           <- change_cipher_spec,
                              finished

Legend:

(1) Client accepts to receive X.509 certs and raw public keys, 
preferring X.509 certs. (Could also be X.509 only in this example)
(2) The server decides to sends his X.509 cert and indicates this in the 
cert-info field.
(3) The server certificate payload contains the X.509 cert.
(4) The server wants to use client authentication and sends a 
certificate-request.
(5) The server accepts reception of raw public keys.
(6) The client indicates that the certificate payload contains a raw 
public key.
(7) The client certificate payload contains the raw public key.

On 12/07/2012 8:54 AM, Hannes Tschofenig wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Jul 2012 14:44:29 +0300

Hi Robert, 

I am not changing the paradigm that the server asks the client for a certificate. It still does. 

What I had proposed is to include information that allows the server to ask for something that the client actually has given that we now include support for different certificate types, a feature that was not previously available. 

So, in your example below a client cannot say that he has a raw public key for client authentication but not an X.509 certificate. 

Ciao
Hannes

On Jul 12, 2012, at 3:57 PM, Robert Cragie wrote:

> Hi Hannes,
> 
> The only one thing I am not sure about is the necessity for cert-send. This is because traditionally the server makes the decision on whether to request a certificate from the client and would not know a priori whether the client supports it. That's not to say it isn't a good idea though.
> 
> (b) 'cert-info=value' with the meaning: "The certificate payload in this message contains a certificate of the following type".
> 
> (1) The client accepts reception of X.509 certs and raw public keys, preferring raw public keys.
> (2) The server decides to sends his raw public key and indicates this in the cert-info field.
> (2) The server decides to sends his raw public key and indicates this in the cert-info field.
> (4) The server wants to use client authentication and and sends a certificate-request.
> (6) The client indicates that the certificate payload contains a raw public key.
> (1) Client accepts to receive X.509 certs and raw public keys, preferring X.509 certs. (Could also be X.509 only in this example)
> (2) The server decides to sends his X.509 cert and indicates this in the cert-info field.
> (4) The server wants to use client authentication and sends a certificate-request.
> (6) The client indicates that the certificate payload contains a raw public key.

---

From: Robert Cragie <[email-masked]>
Date: Fri, 13 Jul 2012 15:06:38 +0100

Hi Hannes,

Agreed, but you are changing the knowledge the server has prior to the 
request; I was simply questioning whether this was necessary. The server 
can present a list of certificate types it accepts and the client 
chooses one, so it is the same mechanism as the client uses initially 
when (implicitly) requesting a certificate from the server (according to 
cipher suite) and thus more balanced.

Robert