W3C home > Mailing lists > Public > public-xg-webid@w3.org > April 2011

wikileaks certs, ICANN, DNS, and DANE. using ldap to parallel a DANE zone

From: peter williams <home_pw@msn.com>
Date: Wed, 20 Apr 2011 17:53:13 -0700
Message-ID: <SNT143-ds20CEA524566071B65A365292920@phx.gbl>
To: <public-xg-webid@w3.org>
"Both of these technologies should help bring about  an increasingly secure
Web, whilst avoiding the dystopia of excessive centralization" says the bard
in the paper.


DANE centralizes - in DNS. Just like ICANN centralized naming authority (in
some US commerce committee, which holds special power over ICANN), and the
top level roots are centralized (in VeriSign/NetworkSolutions, on the
territory of the USA). You cannot have it both ways. Stuffing a self-signed
cert is de-centralized; but if you counter-sign it using a zone-delegation
system that is hierarchical, its STILL centralized. No amount of spin will
change this reality, to engineers interested in survivability and
resilience, etc.


Remember, a huge amount of work went on to DECOUPLE certs from name servers
(otherwise we could have had a signed directory response do what DANE does.
about 25 years ago).


One of the nice things about DANE, though, is that it legitimizes ldaps. If
the logic of DANE makes it fine for a DNS zone authority to counter-sign a
self-signed cert for a "domain-cert_, its equally legitimate for an ldap
authority under a self-appointed zone (dc=com, dc=us -  run by someone
called "peter") to also store a self-signed cert - named identically to the
domain-name used by DANE for the same self-signed cert, in the public DNS
tree. Then,  one lets the SSL cert(s) of the ldaps endpoint(s) speak as a
counter-signature (just as does a DNSSec signature that chains up
hierarchically to a top-level zone controlled CENTRALLY, by US vendors by
and large).


Did I say wikileaks, yet , this week? How quickly we forget, how the
tentacles of control work through the naming and DNS system - something that
did NOT impact the wikileaks SSL certs (note).




Received on Thursday, 21 April 2011 05:10:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:44 UTC