RE: [keyassure] publishing the public key

You are back to focusing on formats, not "webby" control properties. Focus
on the social control properties, not FORMATS!  Leave formats to IETF, they
are good at it. They are not good at webbiness.

 

 

Reasons for interest of WebID

=============================

 

Here are a few reasons for my interest in DANE, which does not get to
answering the bare public key part of your question, but I'll just use it to
frame my recent contribution.

 

1. DANE should make it easy for the self signed https end points that are
currently 3 times more numerous than CA signed https end points to be
authenticated by browsers. Those browsers will no longer need then to
display ugly warnings messages that users are now taught to bypass. This is
good for https, for security and so for WebID

 

Those warnings are there to ensure the home user knows to find an authority
to speak for the keys (since there is none, per se, being self-signed).
Beware, the web is not friendly! (Its full of phishers and spoofers, being
an open platform representative of human nature.)

 

But, do not remove the warnings ALWAYS, for ANY and ALL self-signed certs
(requiring that self-signed certs be registered with DANE and DNS
authorities). If you impose a registration obligaiton, the whole
"subversive" element of self-signed certs goes out of the window. One is
back to: only if "authorized" by a zone signer (playing the role of CA) can
one deploy a crypto-powered server usable by the public. This is a step
backwards (though I know some billion dollar agencies lobbying for exactly
this.)

 

One has gone FROM a web world where the individual is empowered to be one's
own authority and federate it with some private group TO one in which one is
now always subservient to some master (the telco, the post office, the ICANN
zone authority, the evil PKI hierarchy..)

 

You've thrown the baby out with the bath water by making it "easy", if you
put self-signed certs in this control regime that REQUIRES registration.

 

I have absolutely no expectation that ICANN-governed zone signers building
on the likes of DANE will allow just any old self-signed cert to be signed
and distributed as a trust anchor. I see it acting like the old RFC 1422 era
IPRA was supposed to act. Only those who meet trust criteria X Y and Z (and
have 2 million dollars) will be entitled to access the "public"
infrastructure (see how CAB works). Oh you don't have 2 million dollars, or
insurance equivalent? Sorry no access. Go to the back of the bus, and act
submissive.

 

A better scheme is a refinement of the one the web already has. If the
self-signed cert can  be shown to have DANE-keyassurance from an ICANN zone
authority, then the warning can be avoided (key-assure's .sig is just a
third-party cert in drag, and the zone authority is just a third party CA in
drag, swapping some format around to modernize things a bit). 

 

If no ICAAN-registered zone authority is found (which is just a root key
list in drag), the warning is presented, as today. By default, one should
see the warning, and be able accept it (to easily bypass the ICANN control
system, if so desired).

 

This an improvement on today, that doesn't re-enslave crypto and doesn't
re-impose the public PKI hierarchy (without denying its value, for those who
opt in). It allows another civil public entity (ICANN and its network of
authorized zone signers) to add valuable assurances - using DNS and zone
authorities. It's just a RFC 1422-era "policy CA" infrastructure, again in
drag. And, there is nothing wrong with it, providing its not mandatory (at
the ISP) or discriminatory (at the browser). This is what you have to watch
for.

 

The real test is going to be this. If the self-signed cert is placed in a
walled garden DNS using zones that are not ICANN governed (but still
signed), we can test if browser settings still allow the individual to
easily set whether or not these "federated" (non ICANN-governed) zone
authorities are locally trusted (think IE trust zones). If so, then just as
today, the warning can be abandoned for these locally-0trusted zones - just
as it is not shown for ICANN-zones offering .sig RRs. Then we know the
platforms are open, actually emancipating, and not replacing one control
regime with another the hidden bias regime that leverages social segregation
(at the browser) and compartmented access to public resources (at the ISP).