Subject: Re: [keyassure] publishing the public key

From: Paul Wouters <[email-masked]>
Date: Mon, 14 Feb 2011 11:37:43 -0500 (EST)

On Tue, 15 Feb 2011, Peter Gutmann wrote:

>> If you want to help writing a bare public key TLS variant, please contact me.
>
> There is no such thing as a "bare public key".  Public keys have complex
> composite structures, and to encode that you need something like ASN.1 (unless
> you want to invent your own format, which is going to make things even
> uglier).  At this point you're duplicating a significant chunk of ASN.1-
> parsing code outside the certificate code that would normally handle it.  This
> does not seem like a good direction to go in.

The public key's type and raw blob will be obtained from DNSSEC, so
this is no longer required to be conveyed to the client from the server
via a PKIX certificate or other ASN.1 structures. No other certificate
information is desired.

Perhaps some other mode is required if the client needs to be
authenticated by the server, but the use we are talking about here is
for unauthenticated clients, eg the currently deployed "https" mode
without user certs/credentials.

Paul

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 19 Feb 2011 14:15:35 +1300

[Several of my posts didn't make it to the list, these are re-posts of earlier
 messages]

Henry Story <[email-masked]> writes:

>In draft-dane-04 [1] one can currently only publish either a signature or a
>certificate in the DNS. That is the only allowed formats of the resource
>record are as specified in section 2.2
>
>[...]
>
>Why not publish the only piece of the certificate that is important in public
>key cryptography: the public key.

Whatever format gets used, could we restrict things to just a single form, or
at most two forms?  At the moment we've got two types of certs, two hashes of
certs, and a raw public key (or, most likely, two of them).  In practice
there's going to be some de facto standard that everyone uses (e.g. SHA-1
hashes of certs for "fingerprints", which every browser seems to support even
though there isn't even a standard specifying them), and adding a whole pile
of formats is going to reduce interoperability or (more likely) lead to
implementors ignoring all but whatever ends up as the de facto standard.  I'd
use the cert fingerprint (which is already the de facto universal identifier)
as a MUST and leave the rest as options.  TLS already requires that you send
the full cert, TLS implementations already generate a cert fingerprint, so all
that's left to implement besides (shudder) the res_query() lookup is a
memcmp().

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 19 Feb 2011 14:24:03 +1300

Henry Story <[email-masked]> writes:

>And I think Browser Vendors will be very keen to implement this, as well as
>DNSSEC of course, given the terrible state of DNS.

Have any browser vendors actually expressed this opinion?  Given their well-
established track record of responding with PKI-me-harder in response to
existing PKI problems, are you sure they're going to rush to embrace this?

(Don't get me wrong, I think it's a really neat idea, I just can't see browser
vendors embracing it, given their current track record).

Peter.