Some brief proposals for how to make the OpenPGP encryption standard more widely used (by alaric)
The OpenPGP standard isn't perfect, but it's good enough - and it's sufficiently widespread (in geek circles) already that it might be possible to push it into widespread usage.
Here are some ideas on things we could do to push it beyond the realm of geeks emailling each other to become a more pervasive security infrastructure.
Applications need to be more aware of it
If not building encryption support in, at least make it easier to do so.
- Blog software can (either natively or via plugin) recognise when the raw text of a posting or comment is clearsigned, and replace the PGP SIGNED MESSAGE header/footer with just a link to the raw text when displaying as HTML, so the HTML is not marred but the raw source can be obtained and the signature checked.
- Mail clients should seamlessly support signing/encryption
- Address books (including organisational directory servers) should handle carrying public keys for contacts.
- Detached signatures in the filesystem should be made invisible, but the file they are signatures of should show a marker on the icon or whatever showing its signature status (green for signed by a trusted key, red for a bad signature, yellow for signed by an untrusted key). Files with embedded signatures should be automatically and transparently 'unwrapped' so their contents are accessible, and otherwise displayed as described. If a signed file is modified, then the signature should be removed; and if the file was signed by a private key we have available, or if the file is marked in some metadata to always be signed, or if the user opts to sign every file created by default, a new signature should be made automatically on file modification.
- Anything that deals with files of any kind (not just on filesystems; emails, attachments, files fetched via HTTP, etc) should understand encryption and signing. They should automatically unwrap the contents of files that have embedded signatures, they should spot signatures placed alongside and automatically remove them if the file is modified, and when presented with encrypted files they should attempt to decrypt them transparently if a suitable private key is available.
It should be easier to embed into apps
GPGME is a start, but it's a bit clunky. More advanced key management stuff doesn't seem to be possible through it, from what I've seen, although I've not actually checked the docs. Keeping gpg in a child process has security advantages, but what's the latency like? We really want to be able to fork off a single process and reuse it. Then we could, for instance, have a lightweight way to ask a user for their passphrase once, then keep it (or their decrypted private key) in the child so that the parent application process can continue to encrypt or sign messages with it at very low latency, either until the process dies or with a fixed expiry / inactivity timeout, to enable PGP encryption/signing to be used in protocols as well as large-scale batch jobs like files.
There need to be key management systems that make good the claim of being more general than X.509
X.509 is a popular model with many organisations because its centralised certification model is just what they want. OpenPGP can, of course, do that too, being a more general model, but you have to 'do it by hand' by setting up trusted certificating keys and all that. This style of operation, being quite common, should be better supported.
- Public certificate authorities, the keys of which are widely distributed, that will (for a fee or whatever) sign a key in the name of your limited company / legal individual name / etc.
- Software to centrally manage keys for organisations. Issues keypairs (keeping a copy of the private key in escrow), issuing signatures on those keypairs from a central 'CA' key, keeping the keyservers up to date, revoking everything when a user is removed, handling periodic key renewals, etc. Handling encryption/signing at the network periphery (eg, in the mail server) rather than on end-user desktops (central points are easier to secure, and if you trust the access control to the mail server on the internal network, then you don't need encryption within it.).
There should be more specific kinds of signature
Signing a key has well-defined semantics - the signature specifies your level of trust in the mapping between that key and a UID.
But what does signing a file mean? That you wrote the file, single-handedly? That you assembled the file, possibly with contributions from others, but being finally responsible for it? That you believe the contents of the file to be 'true'? That you've merely seen the file, and are acting as a notary/timestamp service?
Some automated processes require their input files to be signed as a way of communicating that a suitably authorised person wants the process to happen (eg, release processes). Which is a very specific meaning of the signature.
This is a bit lame.
Therefore, I think we need a new kind of signature, which lets you make statements about what the signature means.
- I believe the contents of the file to be factually wrong (an anti-signature!)
- I have some confidence that the contents of this file are true
- I have reasonable confidence that the contents of this file are true
- I have great confidence that the contents of this file are true
- I have absolute confidence that the contents of this file are true
Any subtler definitions can be handled in RDF rather than complicating things any more - make a statement about the file in RDF ("The file 'foo.pdf' with SHA1 checksum 19129031290239801290 has been approved for publication") then sign the RDF with "I have absolute confidence that the contents of this file are true".
While we're adding new things to the OpenPGP spec, it'd be lovely to have a new UID type that contains a FOAF-style mboxsha1sum, so that the email address isn't harvestable by spammers and for easy interoperation with RDF. Just a thought.
There needs to be publicity and training campaigns
- Public key encryption isn't hard (the maths is, but the ideas aren't). It just needs to be properly explained, and better terminology.
- The meaning of a signature on a key needs to be made clear ("I assert that I have done quite careful checking that the key 0xF13192F2 belongs to David Smith (Dave.Smith@st.com) - signed by Alaric B. Snell Pym (0x7371086A), on 2008-07-26,").
- There should be better GUIs for key management that make more sense to inexperienced users.
Crypto / security | alaric | 
Mon 28th Jul 2008 11:32 pm
Subscribe
By Edward Barrow, Tue 26th Aug 2008 @ 11:09 am
"PKE isn't hard: it just needs to be properly explained, and better terminology". Agreed.
imo, the phrase "public key" itself is confusing. Instinctively, how can a public key that everybody has possibly be secure? The solution - Use the word "lock" instead: Need to lock a document to send to me? Use a copy of my lock - here's one (a padlock icon would make sense in a gui). I've got the master key that unlocks all these padlocks.
There's also huge potential to be had in linking social networks into webs of trust: e.g. facebook groups whose members have signed each other's locks/public keys; or on something like facebook, though less broken, you don't get to be my friend unless we can sign each other's locks.
By gpbarnett, Wed 2nd Sep 2009 @ 5:43 pm
Exactly right! ALL mail clients should have built in systems. currently with GPG I can use a central system for both mail clients, but T-bird makes key management a snap, but Mail has zero ability internally to handle key, but playing with them together still make little sense. This article was exactly how i felt, and is right on with users who don't venture to far into the OS, but who, back in the day, had a solid grasp on UNIX, and can see the total lack of personal protective devices in softwar, for a predictably wired world. get with it developers.