Re: [keyassure] Bare keys again

[Paul Hoffman <[e-mail]>]

On Mar 20, 2011, at 5:40 PM, Paul Wouters wrote:

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

No, not at all. Please see draft-ietf-dane-protocol-06, where Jakob and I go into this in detail, including quoting from the PKIX standard.

> Isn't a self-signed certificate a CA?

Not unless it sets the right bits; again, see the current draft.

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

...which is not what RFC 6066 is talking about.

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

How do you get this from Section 7.4.2 of RFC 5246? Many sentences in that section indicate that the server must send its PKIX certificate. I believe the only way around that is to define a certificate type of "bare key".

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

Not and be compatible with TLS 1.2, I believe.

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

We fully disagree about what the TLS 1.2 spec says. I'm happy to be wrong about this if folks in the TLS WG agree with you, but your interpretation seems novel, to say the least. I understand you not wanting to spend the effort to do this properly with an extension to TLS; however, this WG cannot just say that we don't care about the requirements in TLS 1.2.

--Paul Hoffman