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

[Eric Rescorla <[e-mail]>]

On Wed, Jul 11, 2012 at 8:57 AM, Hannes Tschofenig
<[e-mail]> wrote:
> 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?

Sure, the indication of what you want to do versus what you want the other side
to do seems poentially separable.


>>
>>> 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.

Well, the basic state of TLS clients is that they support X.509. And of
course servers are allowed to ignore unknown extensions, so there is
always some chance that you will just get an X.509 cert anyway.


>>> 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?

What do you mean? There are only like 50 other ways to verify raw public keys,
starting with fingerprints. The indication here seems to be "if you send me a
raw key I will do something sensible"



>>>                          <-  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.

Well, what the client can say is "I would accept a raw key if you sent
it" and "I could send you a raw key
if you asked", right?



>> 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).

OK.



>>> 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.

Sure, I have no problem with "the certificate message contains the following"

-Ekr