Re: [TLS] draft-ietf-tls-oob-pubkey: My summary

[Robert Cragie <[e-mail]>]

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

Application Data        <------->     Application Data

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

Application Data        <------->     Application Data


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.

III) Hybrid Scenario (the OAuth Holder-of-the-Key Use case)

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

Application Data        <------->     Application Data

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:
> 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 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>