Re: [keyassure] Bare keys again

[Eric Rescorla <[e-mail]>]

On Mon, Mar 21, 2011 at 1:39 PM, Paul Wouters <[e-mail]> wrote:
> 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.

There's a difference between end-entity certificates and trust anchors, and the
RFC 6066 text simply does not say that you can omit the EE cert.


> That is exactly what the option is meant
> to do.

I'm not sure it makes sense to get into questions of textual hermeneutics here,
but I don't recall anyone suggesting the omission of the EE cert while this
draft was under discussion, so I don't think this assertion is very convincing.


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

In my opinion this is what would be required, and that document would need to
be standardized by the TLS WG.


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

That's for the TLS WG to decide.


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

See above.

-Ekr