Re: [keyassure] publishing the public key

[Paul Wouters <[e-mail]>]

On Mon, 14 Feb 2011, Scott Schmit wrote:

> <snip bandwidth considerations, etc>
>
> People keep saying that, but I don't think it's true. This is always an
> option:
>
> In some order:
> * Client looks up bare key in DNS
> * Client connects to TLS service, TLS service sends cert/cert chain

Why does TLS service have to send cert/cert chain? The client already has
all it needs to know, the bare public key and the DNSSEC validation asserting
the key is validated for use.

> Then, instead of comparing the key/hash of key to the whole cert, the
> client picks out the public key and compares them (or their hashes).  If
> they match, use the cert as before.

the problem is if cert now contains a CN=www.paypal.com. Browser vendors do
not want to ever display information that has no been validated, and for
DANE public keys, none of the certificate is validated. This is why its
better not to drag in these things to begin with.

> There are problems with this approach, but I'd rather the conversation
> not stop with "it's impossible to put bare keys in DNS until TLS
> supports it directly!" Instead, I'd prefer we discuss the problems that
> a bare key approach would need to deal with. I suspect most of them are
> at least related to the question of what cert fields to pay attention
> to.

I'd be in favour of this, though I also understand people don't want to add
types for vapourware.

> Some issues that would need to be understood/resolved:
> * the bare key doesn't tell you anything about the algorithm it's for
> (or how to interpret it, really)

The RRTYPE would need to tell you. Currently, we only have the "hash type"
(section 2.2) though that could perhaps be expanded to also contain the public key type.
Or alternatively, we add another field similar to how DNSKEY describes the
key algorithm (and possibly using the same values)

> * a hacker could potentially alter the certificate in some unexpected
> way (usually only affects EE certs if the TA certs are well-protected)
> from what the service owner expected -- whether this matters depends on
> what you were getting out of the other cert fields.

This is why "bare public key" has no PKIX container.

Paul