[conspire] CA signed certs, and not CA signed ... PGP/GPG cross-signed? ... Firefox CertificateWatch extension ...

[Rick Moen]

Correcting and adding an afterthought or two:

> Also, alas, possibly a somewhat utopian one.  And here's why I say that:
> 
> The Web of Trust (WoT) model exemplified by PGP / gpg works great,
> provided participants are motivated and are willing to participate in 
> keysignings, so that they have credible trust paths they can use to 
> vet people and things they know personally.
                             ^^^^^^^^^^^^^^^

Make that '_don't_ know personally'.

(There have been more than the usual number of typos, sentences with
missing words, and in rare cases sentences going off in the weeds and
never emerging.  Fortunately, I have the Martian Death Flu to blame, and 
not incipient Global Village Idiot status.)



> So, getting to the point, _even_ if we get a pervasive browser plug-in
> that makes WoT attestation of SSL certs seamless, most people would get
> failure to find a trust path, most of the time.  And so the value
> proposition would be non-obvious except to us people with
> (metaphorically) low T'so Numbers, i.e., people who actually participate
> in keysignings, hence actually have trust paths.

This situation isn't necessarily hopeless.  It just requires some good
systems thinking, and some realism about adoption by the general public.

Imagine this:  Instead of seeking to junk the PKI scheme entirely, we
phase in measures to tame PKI partially (CertificateWatch, Convergence)
and promote the idea of an SSL-cert trust metric under user control.
In that case, alternative attestation paths like that of Monkeysphere
Project can _at the user's option_ be assigned some fraction of the
local trust weighting.  Or not.

That idea came to mind by analogy:  In the world of SMTP mail servers,
we have the notion of programmatically estimated 'spamicity'.  My
system's MTA uses the local SpamAssassin daemon as framework for
consulting a variety of DNS blocklists, SPF, (in the future) DKIM, 
and any other spam-metrics tool I deemed worth consulting.  In each 
case, the tool SpamAssassin's spamd consults reports back data, and
spamd decided based on my scaling decision how much to adjust the
current arriving mail's estimated spamicity up or down.  After each 
tool has been consulted, spamd reports back to Exim4 (the MTA) a
composite spamicity score.  Exim4 adds that to the results of its own
rulesets, and determines whether or not to accept the arriving mail.

Analogously, a user might give greater or lesser weight to a
Monkeysphere Project trustability number, alongside the opinion of the
PKI infrastructure.  User would need to decide what default number 
applies when Monkeysphere Project cannot find a trust path.  And maybe
other schemes can be likewise included and given weights.

I don't know how practical that is, and (as always) it's easy to talk
ideas without bothering to implement them, but showstopper problems
sometimes emerge when someone actually tries.  But it's a model that
could be explored, for whatever that's worth.