RE: self-signed certificates in DANE

>From a secure communications design standpoint, the design is flawed. It no
longer treats the client cert  actually sent (optionally) in the TLS record
layer as a hint (which is its role), but as a mandatory control mechanism.
This forces information leakage, from channel, to cert, to validation
source. 

The DANE text requires the validation agent to confirm that a message FROM
the client (the client cert in the client cert msg) confirms against the
hash/fingerprint thereof in the DNS RR. This makes the cert (a) mandatory
for presence on the wire, (b) mandatory for authenticity of the pubkey, (c)
vector for information leakage about who associates with who
(cryptographically). Its denies a tenet of RFC1422, that allows 2 CAs to
certify one pubkey (as a counterweight to political control over keys, and
facilitates DR and survivability)

I hope they don't do this (but I suspect they will, for "national" crypto
political reasons).

A military designers ensures the cert indicates to the cert discovery module
merely a hint - the requirement concerning how/where to look for evidence
for the public key. Should the cert discovery provider choose NOT to use
that cert but an alternative EE cert whose path that ends up authenticating
the same pubkey, SSL goes forward. SSL and cert discovery/closure are
ORTHOGONAL




-----Original Message-----
From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
On Behalf Of Henry Story
Sent: Wednesday, March 23, 2011 5:33 AM
To: WebID XG
Subject: self-signed certificates in DANE

Dane has a section now on self-signed certificates

  http://tools.ietf.org/html/draft-ietf-dane-protocol-06#section-2.3

I think it is going in the direction we would like: to make it easy for web
sites to create self signed certs for their services. But I am not sure.

	Henry

Social Web Architect
http://bblfish.net/

Received on Wednesday, 23 March 2011 16:59:40 UTC