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

[Hannes Tschofenig <[e-mail]>]

Hi Nikos, 

thanks for the response. 

On Jul 11, 2012, at 6:16 PM, Nikos Mavrogiannopoulos wrote:

> On 07/11/2012 12:56 PM, Hannes Tschofenig wrote:
> 
>> Hi all, 
>> 
>> draft-ietf-tls-oob-pubkey specifies a new TLS certificate type for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) for use with out-of-band public key validation.
>> 
>> Here is the latest draft: 
>> http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-03
>> 
>> I would be great to get your feedback on an open issue that concerns the semantic of the exchange. I believe there are three use cases we would like to support with this work. Below, I provide high level message exchanges to explain those: 
>> I) Server uses Raw Public Keys (client authentication happens at some other layer)
> 
> 
> If you don't need a client certificate or public key, you don't send a
> certificate request.

You mean: If the server does not want any client authentication then it does not send a certificate request. 
If that's what you mean then I agree with you. 

But in this scenario the server provides the raw public key. 


> 
>> II) Client and Server use Raw Public Keys
>> (the smart object use case - CORE working group)
> 
> 
> Your draft already covers that case.

That's what I thought but Paul had a different understanding. 

It is not quite clear what the semantic of the cert_type="RawPublicKey" in the client hello message is. 

> 
>> II) Hybrid Scenario
> 
>> (the OAuth Holder-of-the-Key Use case)
> 
> (server X.509 certificate, client raw public key)
Yes. 

> 
> I see two options. 1. You overload the ClientCertificateType of the
> certificate request with a raw_rsa_sign that does what you intend.

I currently had taken the route that I use an extension to indicate what stuff is in the certificate payload. 
It seems that RFC 6091 and the recently submitted OBC had chosen the same approach. 

> 2.
> You create a new extension that modifies the format of the certificate
> request to include an explicit certificate format.

Of course the existing certificate format cannot (and should not) be changed. 
One could put an additional marker into the cert payload that makes it easy for the client and the server to differentiate the content of the payload.  

In the implementation I put together for the smart object security workshop I just used the the cert_type to determine what the content of the cert is and I didn't had to take additional steps. 

(Maybe I am making this too complicated and it is in fact trivial to differentiate the two payload types.) 

Ciao
Hannes

> 
> regards,
> Nikos