[conspire] Offering GPG/PGP Workshop at CABAL

[Rick Moen]

Quoting Daniel Gimpelevich (daniel at gimpelevich.san-francisco.ca.us):

> I am not in any way disputing that to be the current state of affairs.
> PhilZ said: "An argument could be made that as a matter of solidarity with
> the rest of the population you should encrypt your email."[1] If this is
> to be accomplished with PGP/GPG, the entire "rest of the population" must
> be participants in the web of trust. I investigated this possibility a
> couple of years ago, and found the OpenPGP functionality in the GPG
> software thoroughly incapable of such an endeavor. PKI does not appear to
> have this limitation. The fact that no PKI model is used for widespread
> e-mail encryption among the masses cannot in any way negate the fact that
> such a thing is not only possible and simple, but also imperative, nor the
> fact that such a thing falls well outside the potential of PGP. Sure,
> getting people to become part of anything like that is not something
> that's reasonable to expect, but the existence of the technical means for
> it is obvious, and appears to me to be limited to PKI exclusively.

It's a worthwhile dream.  Building a GnuPG-based (or even PGP-based) web
of trust is, as you say, hard slogging at best and, as things stand, 
damned unlikely to ever catch on among the general computing population.

Having personally wrestled GnuPG into submission for my own use a number
of years ago, I was astonished at how utterly user-hostile it was and
remains, even by the standards of Unix command-line crypto utilities.
(That's one of the reasons I wrote my lecture notes, to compensate in
part.)   To this day, I can't reliably remember most of its basic
command functions, and keep having to pore through its manpage.

The "rest of the population" aren't going to be able to deal with that,
though they might be able to deal with standardised interfaces called
from other programs (e-mail programs dealing with it directly, and/or 
Gnu Privacy Assistant[1] and the like).  

It's worth discussing what any PKI (Public Key Infrastructure,
http://en.wikipedia.org/wiki/Public_key_infrastructure)
implementation buys you as an advantage -- and you're quite right that
it's considerable -- and what the cost is.  CAcert is a reasonable
example, because they're doing about as well as a non-profit attempt at
PKI infrastructure _could_ do.

Any PKI system requires one or more CA (Certificate Authority) to
testify to (certify) the ownership of keys by various people and hosts
they pertain to -- process their applications for new keys and
revocations of old keys, verify identities of applicants,
cryptographically sign their keys, and maintain the integrity of the
process and the secrecy of the CA root certificate's private key.

One point to note is that it's a much more palatable model for
end-users:  The CA says a key is good and belongs to Joe Shmo, so,
unless you have some special reason to distrust the CA, it really does
represent Mr. Shmo.  End of story; no convoluted keysignings required.
(This assumes the user's software knows about the CA, a point we'll
return to, below.)

Another point to note is that the infrastructure requires effort that is
inherently not spread evenly across the users of PKI services, but, to
the contrary, cannot help but land squarely on the group or individuals
who operate the CA(s).  A CA can _try_ to spread some portion of the
work over onto the users:  CAcert attempts to do this, to some degree,
through the notion of "Assurers" who've earned 100 points being able to
physically verify additional users (a nice Tom Sawyer whitewashing plan 
:-> ), and the scheme sort-of works even though they're remained
a non-profit corporation and don't charge money for certs.

The problem is that there's only so much you can do within a centralised
service bureau with non-zero administrative overhead and no revenues,
_and_ that there are important things you cannot accomplish with zero
budget.  On the former point, I estimate that CAcert cannot grow very
big[2] without collapsing from staff burnout (not everything can be
automated) and from bandwidth/machine costs and legal exposure (not
everything can be done without funds).  On the latter point, getting 
CAcert's root certificate into commodity Web browsers has so far proven
impossible, because the publishers of _most_ such browsers expect to get
paid for accepting them, and even Mozilla has so far refused.  

The most recent reason cited by the Mozilla people is telling:  CAcert
was continuing to fail an audit of its management structure according to
agreed-upon criteria, and, I gather, this simply requires a lot of staff
time and effort that hadnn't been available -- i.e., they're a small
zero-budget nonprofit having to take care of a lot of big tasks
(https://bugzilla.mozilla.org/show_bug.cgi?id=215243#c158).[3]

So, the promise of CAcert as a well-intentioned and well-run PKI
authority lies in the fact that it introduces centralised administration
of key attestation.  The drawbacks are inherent in that same fact.  Both
the promise and the drawbacks will become more pronounced if it attempts
to scale up -- which I predict would, in fact, cause its collapse if
that were to happen (unless it changes its nature and starts becoming a
for-money venture, in which case it's just another Thawte/Verisign).

By contrast, the verified PGP "strong set" (http://pgp.cs.uu.nl/plot/)
is currently a bit smaller than the total number of "verified users"
(whatever that means) CAcert says it services, but there is no
bottleneck for scaling at any single point (only a rather excessively
geeky technological burden on each individual participant.[4]  And I'm
guessing that PGP/GnuPG keys are, on average, a good bit more useful,
but that's just my guess.

If I prove to be wrong about CAcert and PKI's Achilles heel, nobody
could possibly be more delighted about that than I, by the way!


[1] Untried by yrs. truly.  http://www.gnupg.org/gpa.html and
http://wald.intevation.org/projects/gpa/

[2] The present claimed 200,000 verified users is a notable
accomplishment, which I assume combines S/MIME users and those 
responsible for X.509 certificates and the like.  However, that's a drop
in the bucket compared to what would be required to be a significant PKI 
relative to "the rest of the population" of computer users.

Please note, by the way, that CAcert-attested SSL certificates are
considered extremely weak, because, being "robot signed" by automated
scripts that mail back automated certs to anyone who controls
hostmaster@[domain] or a similar account, they are (1) not actually 
verified as particularly legitimate and (2) stripped of all identifying
information except the CommonName field (domain name or submitter's
e-mail address). 

[3] Several Linux and one BSD distro include the CAcert root certificate
anyway, thus making it available in Mozilla apps as packaged downstream,
but most distros do not.

[4] Not that using CAcert's S/MIME certificates in e-mail is exactly a
bed of roses, either.  See, for example:
http://steffenpingel.de/news/archive/2006/feb/27/using-cacert-certificates-with-kmail-on-debian/
And your recipients typically will not be able to verify your cert,
either, because, guess what?  The CAcert root certificate's
non-inclusion in (most) distros and MUA software, once again.