From W3C Wiki
Digital signature technology so clearly solves so many security problems. Why isn't it ubiquitously deployed?
It's 2004 now, and popular mail clients are starting to support secure email out-of-the-box. But evolution misleads users about when to trust signed mail. (Likewise Apple OS X Mail, I think.) John Udell writes about How to forge an S/MIME signature, that is, how outlook and other popular mailers overstate the authenticity of signed mail.
The Writing user interfaces chapter of the gpg manual says In their human factors study, only four out of twelve test subjects managed to correctly send encrypted email to their team members, and three out of twelve emailed the secret without encryption.
With spyware rampant, how are folks supposed to keep their secret keys and passphrases secret? How do I keep from losing my key if I can't back it up? Losing sole possession of your private key is catastrophic, says the GPG manual. Next, how can we expect folks to understand when it's safe to sign a key? It's really quite subtle.
ssh works pretty well. But how often do you swat away warnings about host keys changing? I wish I could interact with ssh-agent from python programs. sshAuth.py almost works, but not quite.
SSL is pretty much ubiquitously deployed. Verisign and a few other certificate authorities (which ones? research mozilla psm source code?) have their keys distributed in pretty much all the browsers, and millions of sites buy certificates from them. There is a concentration of power, which leads to the inevitable abuses, but it's not rampant. Independent certificate authorities are doable; the hassle is low enough to keep the certificate authorities somewhat honest but high enough that few communities bother.
The PITA factor for client certificates is so high that deployment is limited to intranets (as far as DanConnolly can tell; anybody know better/different?).
The CPU cost of doing SSL is quite high, I understand. Oh for digest auth (RFC2617) deployment. It should be a crime to do cleartext paswords. Sigh.
OK, it looks like we'll have a PathCross event around XML 2004. How about getting some experience with the state-of-the-art in trusted communications by having a little keysigning party?
First step, install the relevant software. Of course, this is a catch-22: how can
you be sure you've got the right software? check signatures, of course; but how
do you check signatures? sigh. A "Checking Package Integrity?" article
in the Debian Weekly News - July 16th, 2002
discusses the use of apt-check-sigs
which will check the The Debian Chain of Trust
once you put the ftpmaster's key
in pace ala
GET http://ftp-master.debian.org/ziyi_key_2002.asc | gpg --import
gpg --export 1DB114E0 >~/.gnupg/trustedkeys.gpg .
Boy is that software hard to use! The diagnostics are horrible.
You must select at least one user ID. Well, how the heck do I do that?!?
I read the gpg manual a long time ago (back when it was phil Z's PGP manual, I think) but I found myself going all the way back there today to be sure of some things.
Next generate a key and all that. It turns out I made one back at the 2002 Web Conference; it was set to expire in 2005, so I was going to throw it away and make a new one, but KjetilK told me I could change the exipration date. It turns out I can change the name and comment too. just what are people signing when they sign my key? gotta transcribe it to N3 to grok it.
LinkMe: swapt/doc/trust, XML signature spec
Alternate wire formats (not just S-expressions). We are in the early stages of adding support for SPKI/XML. -- JSDSI 28 September 2004. Hmm... perhaps suggestive of a deployment vector for the semantic web trust layer.
PGP User's Guide, Volume I: Essential Topics 11 Oct 94. Philip Zimmermann Maintained and copyrighted 1996. by Josko Orsulic (Josko.Orsulic@fer.hr)