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

I don't know why you (and I say you, as I don't know anyone else who argues
for it) ties the brand of webid to DANE. Perhaps there are meetings I don't
know about? One should be aware of lots of political history here, as the
telcos in the ENUM space vie for the same power - using DNS more
intelligently for key management than simple signed RRs. One might want to
understand ENUM, and the issue of private ENUM (the ability to run a walled
garden DNS cache, walled off to assure it against poisoning). Comodo looks
like a fun little company, but is not the heavy weight in the space.

 

Now, I understand the general motive: for a public identifier space, you
want/need the authority field of the URI to be assured, as that underpins
the denotational semantics of the class resolver (given a class name in the
foaf card), and the de-referencing of the resource identifiers to and from
the foaf card. If the endpoint providing the proof of identifier control can
be spoofed, webid is useless. If the resource server uses a cache of triples
for the evidence binding the key to the identifier that is untrusted (or
poisoned), webid is useless. (For useless, perhaps read "unassured",
professionally.) These issues don't get any discussion in the paper (aside
from implying the underlying issues with authority, by reference to DANE).

 

Without giving the game away, state the assurance limits - as assumptions.
Imply that there is a parallel assurance argument, in addition to the
functional benefits based on the protocol.

 

For commodity systems, for low cost, folks will accept quite low assurance
(think real estate) assuming that compensating control system apply to make
up for lack of assurance in information systems (think real estate, where
one *insures* against error in the title record, uses credit reference to
uderping the financial note, and one bases public trust on the notary's
personal identifications.and affadavits). What most matters is resilience,
that is. If the entire MLS web system in the US went down for a week there
would be a lot of whining (before the manual system kicks back in, as
designed, and the trillion dollar cash flow .keeps flowing!). We didn't
allow that economy/flow to become dependent on IT, the internet, or "being
online"- by design. When you are running a system critical to a trillion
dollar cash flow, you *have* to focus as a security engineer on the
assurances - dependencies, resilience, survivability.

 

If we can speak a little to these topics, it will be say something to that
crowd of American identity types (who are probably pre-selected to get them
onboard with the US national id program, which will coordinate such
assurance topics). 

 

 

From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
On Behalf Of Henry Story
Sent: Thursday, April 21, 2011 1:54 AM
To: peter williams
Cc: public-xg-webid@w3.org
Subject: Re: wikileaks certs, ICANN, DNS, and DANE. using ldap to parallel a
DANE zone

 

 

On 21 Apr 2011, at 02:53, peter williams wrote:





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

 

It is not as centralised as it appears, as I argues a few weeks ago on this
list in the thread "Certificate Authorities under increasing spotlight"

 

http://lists.w3.org/Archives/Public/public-xg-webid/2011Mar/0126.html

 

So on that view DNSsec is as (de)centralised as CAs.

 

But I'll add a twist to the paper.





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

 

 

 

 

 

Social Web Architect
http://bblfish.net/