Re: [keyassure] Bare keys again

[Paul Wouters <[e-mail]>]

On Sun, 20 Mar 2011, Paul Hoffman wrote:

> The definition in RFC 6066 for pre-agreed is "no CA root key identity supplied".  Later in the section it says "The option to include no CA root keys is included to allow the client to indicate possession of some pre-defined set of CA root keys." Note the use of "CA root key" in both of those.

Yes. The predefined set of (required) CA root keys is the empty set. But whether
it is a preloaded set from Versign or a preloaded set from Komodo, or a preloaded
empty set is irrelevant to the server receiving a TLS trusted_ca_keys extended option.

>> This means we will want to add bare public key into this draft, as it
>> is the only document that would require changes for bare public key to work.
>
> If you want to add bare CA keys, that's fine, but I suspect that you actually want to add bare end entity keys, and RFC 6066 doesn't allow that.

That difference is muddy anyway, isn't it? Isn't a self-signed certificate a CA?

> If you are truly interested in bare CA keys, we can make that change if the WG wants. However, I have heard no interest in bare CA keys from anyone (including you) before today; all of the discussion of bare keys was for end entity keys. For that, I believe you actually need to write an extension to TLS.

We are talking about end entity keys.

The client sends its hello message saying "I have all the CA root trust
anchors I need from pre-agreement".  Whether that means it got information
from DNSSEC/DANE or elsewhere does not matter. What matters is, is that
the client can start the TLS handshake without the server sending any
PKIX certs.

It can already accomplish this without using trusted_ca_keys, or if the
server does not support the 6066 extension to supress sending its CA
cert chain(s).

Whether the client does this because it is "memory starved" (as per 6066)
or because it obtained trust in the server pubkey via another set of
non-CA trust anchors does not really matter. All the server needs to
know is that it can ommit sending a giant blob of PKIX to the client.

The *only* thing needed for bare public keys to work is that the client
does the DNS lookup for the bare key using DANE. No TLS protocol change
is needed. Therefor, all we need is a method for specifying bare public
keys in DNS, for which my previous email proposed a structure.

Yes, we could make a TLS extension for "public_key" that works like server_name,
or we could extend server_name to take a new type "public_key", but there
is simply no need for such an extension, as the server does not need this
information and cannot do anyting with this information that is not already
covered with trusted_ca_keys.

Paul