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

[Robert Cragie <[e-mail]>]

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

On 13/07/2012 12:44 PM, Hannes Tschofenig wrote:
> 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
>