getting past centralization of webid in DNSSec

One of the arguments I hear, is that CAs can be made irrelevant when the DNS
naming authority takes on the role of binding a name to a key. This will
help webid, therefore - getting things beyond the assurance limits being
encountered today as browser-based trust anchoring systems show their age,
under the scale that https is used today.

 

Poor arguments are made to support this point (based on conventions like:
CAs and trust anchoring as seen in browsers can only be used in the
piss-poor manner of today, and IETF's PKIX specified constraints don't
work). The poor arguments fail to take into consideration that things are
piss-poor because of the quality of implementation and level of profile
interoperability testing, by unmotivated vendors. Constraints don't "work"
mostly, because half the browser just don't implement them. This is a world
in which one fails the exam by not turning up to the testing center before
the door closes. Poor rhetoricians then blame the exam system, itself!

 

In Webid land, I see a political compromise coming about, in this space.
But, something has to give, as always.

 

First, I don't mind DNSsec (or stuffing an old DER-encoded self-signed cert
in an RR, so DNSsec countersigns the blob). Its just a counter-signature
scheme, like 10 others. What I mind is the impact on resilience,
survivability, and control - if one centralizes the counter-signing
apparatus. One simply has to shout "wikileaks" - to remember what happens
when the DNS is manipulated by powers that be. Things disappear, globally
(until the resilience features are properly used). With CAs being offline
from naming authorities and DNS, this doesnt happen with X.509 certs - BY
DESIGN. Obviously, some national security authorities (working on 1960s
assumptions about who should have crypto) would like certs to disappear from
the public space, just like DNS records.

 

If we endorse counter-signing by DNS, we need a political re-balancing - to
disrupt the downsides of DNS on resilience metrics.

 

I like what Kingsley your group is doing, in allowing resolvable webids of
the form "https://uriburner.com/?uri=<webid>. This indirection allows
uriburner to resolve the authority in the https URI, within <webid>.
uriburner may not bother with the DNS or DNSsec as the basis for testing the
name. It may use its own replicated store of domain-name -> Ip address
mappings. It's a counter-signing authority, perhaps using the
counter-signatures of DNSsec but deciding for itself when (and when not) to
project forward the naming authorities opinion to the consumer.

 

I can see webid resolvers working with a world of DNSsec and specifically
not DNSsec - to retain survivability elements from the CA world design for
commodity-class browsers. I can imagine queries I issue, as webid consuming
resource server, that ask: tell me how the webid validates in several
validation models: (i) the assumption that DNSsec is authoritative for
domain-names, and (ii) tell me under non DNS-Sec assumptions about the
authoritiveness of domain-names.

 

One might be tempted to say: well doesn't that centralize validation (using
n scheme) in the uriburners of the world- thus centralizing (and making them
easy subversion points, impacting huge populations a la wikileaks)?

 

Yes! until we recall that our self-signed certs have multiple SANs, enabling
the consuming relying party to be hint-directed to multiple uriburners.
Assuming some independence of these validation authorities, it makes it hard
to subvert all of them, on a subversion directed at a particular record (a
la wikileaks, and US orders on DNS providers). 

 

This means giving up (for https webid) the notion that "only" direct URIs
are proper. We have to legitimatize proxy naming of webids, so as to
re-balance the downsides of DNS and DNSsec concerning the wider goals of
survivability, resilience and provider autonomy, that motivated the design
of the current browser-based CA system for name/key bindings (and despite
all the whining, works very well).