Re: [TLS] draft-ietf-tls-oob-pubkey: The Open Issue

[Hannes Tschofenig <[e-mail]>]

Hi Ekr, 

thanks for your quick response. 

When we started the work we just copied the functionality from RFC 6091 and that RFC defined a new "cert_type" extension. 
As it turns out RFC 6091 didn't IMHO clearly specify the semantic of the value in the cert type.

There are various scenarios, as described below. 

For example, when a client sends a cert_type="raw-key, x509" does this mean it can raw public keys for client authentication and it is OK to receive an X.509 for server authentication? Does it want to receive also a raw public key from the server when the server supports it? 

> 
>> I) Server uses Raw Public Keys (client authentication happens at some other layer)
>> (the DANE use case)
>> 
>> client_hello,
>> raw-public-key-indicator="Server, when you send me your raw public key?
> 
> Is your suggestion that this is indicating ":I would not support X.509?

There has to be a way to indicate what is supported. The rest is not supported. 

> 
> 
>> I support this out-of-band key validation using DANE." ->
> 
> Wait, who said anything about indicating DANE here? The agreed upon
> indication was
> "I would support a public key", nothing about DANE.
> 
> 
What happens if the client supports raw public keys but does not support the out-of-band validation using DNSSEC? 
While I wasn't really suggesting to provide the way to say "I want to use DANE" I see problems for interoperability here. 


> 
>>                          <-  server_hello,
>>                              raw-public-key="OK. The certificate structure below contains my raw public key.",
>>                              certificate, // with raw public key inside
>>                              server_key_exchange,
>>                              server_hello_done
>> 
>> client_key_exchange,
>> change_cipher_spec,
>> finished                  ->
>> 
>>                          <- change_cipher_spec,
>>                             finished
>> 
>> Application Data        <------->     Application Data
>> 
>> 
>> II) Client and Server use Raw Public Keys
>> (the smart object use case - CORE working group)
>> 
>> client_hello,
>> raw-public-key="Server, please send me your raw public key and I will then send you mine. Are you OK processing my raw public key for client authentication?" ->
> 
> This is not a semantic associated with the client. In TLS the server
> requests client auth. At most the client could say "I could
> send you a raw public key for auth if you asked for it"

The important thing here is the indication that both the server and the client are able to process and accept raw public keys. 


> 
> 
>>                          <-  server_hello,
>>                              raw-public-key="Below you find my raw public key and please send me your raw public key for client
>>                                                           authentication",
>>                              certificate, // raw public key
>>                              server_key_exchange,
>>                              certificate_request,
>>                              server_hello_done
>> 
>> certificate, // with client's raw public key
>> client_key_exchange,
>> certificate_verify,
>> change_cipher_spec,
>> finished                  ->
>> 
>>                          <- change_cipher_spec,
>>                             finished
>> 
>> Application Data        <------->     Application Data
>> 
>> 
>> II) Hybrid Scenario
>> (the OAuth Holder-of-the-Key Use case)
>> 
>> client_hello,
>> raw-public-key="I would like to use my raw public key for client authentication with OAuth. I also process X.509 for server-side authentication." ->
> 
> As above.
> 
> 
>>                          <-  server_hello,
>>                              raw-public-key="Please send me your raw public key.
> 
> This is in certreq, no?

I should have rather written. The certreq is asking for your raw public key since you said you support raw public keys (but you have may other certificate types). 

> 
> 
>> I use X.509 for server-side authentication",
> 
> Why would this need an indication?

I believe the problem is that we have to provide a way for the client to figure out what is in the certificate extension. In the raw public key case we only dump the SubjectPublicKeyInfo structure into the Certificate payload. 

We make it easier for the client to parse the content of the structure. 

Right? 



> 
>>                              certificate,  // with X.509 cert.
>>                              server_key_exchange,
>>                              certificate_request,
>>                              server_hello_done
>> 
>> certificate, // with client's raw public key
>> client_key_exchange,
>> certificate_verify,
>> change_cipher_spec,
>> finished                  ->
>> 
>>                          <- change_cipher_spec,
>>                             finished
>> 
>> Application Data        <------->     Application Data
>> --------
>> 
>> QUESTION: Are these all the message exchanges we need? Are there some problems with the exchanges?
>> 


Ciao
Hannes