[OAUTH-WG] draft-ietf-tls-oob-pubkey: My summary

[Hannes Tschofenig <[e-mail]>]

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