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

[Hannes Tschofenig <[e-mail]>]

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