new class of https endpoint. go try it (on Windows). may work on windows/mac combo desktop, even for mozilla. Comparison with DANE

> > In the QuickExec box, you'll need to type:

> 

> >     !listen 4444 hostname

> 

> > Where 4444 is the port that you would like to establish a secure 

> > listener on, and hostname is the hostname of the certificate that 

> > you would like to return when clients connect to the server. Of 

> > course, you'll need to install the Fiddler root certificate on the 

> > client in question to avoid certificate error pages.

 

Fiddlertool.com

 

This is a server (a proxy endpoint, in fact) with a self-hosting-centric
cert minting capability for the https server endpoint. The endpoint gets
distinct keying from the proxy endpoint (that supports classical corporate
"interception" goals, per the web architecture). Given config, the endpoint
mints its own cert-based identity, chaining to a trust anchor the operator
distributes to browser instances (using admin privileges, or with user
consent if required via the web). The browser experience is identical to
using bergi's endpoint today (which projects CAcert trust anchor, largely
despised by the vendors of browsers - though Tunisian dictators are accepted
fine.). The trust anchor does NOT need to declare v3 extensions mandating
servers cert declare themselves as such (and browsers don't thus require
them to, given this policy assigned to trust anchors). The cert the endpoint
mints for itself can thus double as your client cert as pure crypto doesn't
care about endpoint roles, knowing nothing of server/client role
distinctions (this is a commercial notion, designed to segment market for $$
or to project governance/control regimes)

 

There is nothing new here, technically; its just some convention busting. So
long are the conventions held, many who are unware of history think of them
as "fact," historically inevitable (they are not, but the arguments are
similar to keeping racism against black folk for 200 years.). Using the
scheme is analogous to buying a classical server cert from VeriSign which is
3 chain element long including the end-entity/leaf cert specific to you; and
then using the certified signing key not to host a SSL server (per the
contract) but now sign a new "extra" cert you generate (without the
authority of the CA) that is used on your endpoint.

 

The extra cert is "not authoritative" in the VeriSign case, as the chain
elements convey to relying parties (browser makers) rules in the v3
extensions that define a state of non-authoritativeness of ANY such cert,
born out of wedlock - that the policy of the VeriSigns of the world
typically define as invalid. Being invalid, there is legal contract
violation, typically. One has made a "using" of the branded VeriSign cert
that is unlawful (under the contract). Usual copyright and trademark abuse
claims can be made against you, to bring you into compliance (and pay for
the "damages"). It's the usual corporate control story.with a crypto twist.

 

In the case of DANE world where one has a sequence of signed zones instead
of a sequence of signed certs from the cert world, it's like registraterin a
name for a zone for one's own RRs - where the hierarchically-superior DNS
authority (Comodo etc) denies YOU technically and legally the ability to
host/sign subordinate zones, or your choosing. But, you do so anyways. Its
then up to the verifier of a CHAIN of DNS zone signatures to know that the
subordinate zone (bearing your DANE self-signed X.509 certs, perhaps) is NOT
"authoritative". This invalidates the zone closure from the centralized DNS
root (US surely), and will no doubt get you a take-down notice from the
CA/Zone Administrator (VeriSign, Comodo etc). In the wikileaks type case,
the enabling record in the DNS will just disappear, of course, when some
politician makes a phone call to a friend..