Re: [keyassure] Bare keys again

[Paul Wouters <[e-mail]>]

On Mon, 21 Mar 2011, Matt McCutchen wrote:

>>     -  "pre_agreed": no CA root key identity supplied.
>
> "pre_agreed" stands for a set of one or more trust anchors that is
> already known to the other side in the context of a particular
> deployment.  Hence, bandwidth is saved by not sending identifiers for
> the trust anchors.

which is the case of the TLS client has gotten the public key from DNS using
DANE. But it does not matter how the client obtained the trust. The client
is telling the server it has all the required trust anchors, and that the
server can ommit sending them over. That is exactly what the option is meant
to do.

I can see how we would want the TLS client behaviour to be written down in a
standards document, and I am more then happy to do so. But adding a new
TLS client/server extension is silly. it would have the exact same semantics
as "pre_agreed", as I don't think we would want to state that the "new pre-agreed"
can only be used if the client has used DANE to validate the key. This is like
writing separate laws for email spam and fax spam....

> Using "pre_agreed" to tell the server it can skip
> sending a certificate chain is not envisioned by RFC 6066.

On the contrary, that is *exactly* what the goal of 6066 is. It specifies as
reason "memory starved clients" and "reducing bandwidth", but why is that
list treated as an exclusive list?

>> The only thing that is different here is that I am using a client contraint
>> that is different from the examples listed at the start of section 6.
>
> What is different is that the server does not send a certificate chain.

Which is exactly what happens on a TLS client preloaded with the root CA of the
server, in a low memory or low bandwidth situation sending the "pre_agreed"
option. Just because for bare public keys the client has a different format (or
method) of getting that information should be irrelevant to 6066.

Paul