From 39e7b914fae5d5024580470669e19acc10eb79c4 Mon Sep 17 00:00:00 2001 From: "W. Trevor King" Date: Sat, 14 May 2011 08:50:26 -0400 Subject: [PATCH] Add PGP post. --- posts/PGP.mdwn | 78 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 78 insertions(+) create mode 100644 posts/PGP.mdwn diff --git a/posts/PGP.mdwn b/posts/PGP.mdwn new file mode 100644 index 0000000..15281c8 --- /dev/null +++ b/posts/PGP.mdwn @@ -0,0 +1,78 @@ +[[!meta title="Pretty good privacy"]] + +[PGP][] is a protocol for signing and encrypting email. It has been +widely used in the tech community since its creation by Phil +Zimmermann in 1991. Sadly, it doesn't seem to have spread deeply into +the general community. + +Anyhow, I was confused about the difference between PGP, PGP/MIME, +OpenPGP and [S/MIME][], so I did a little RFC reading: + +* [RFC 5581][] (Camellia symmetric block cipher in OpenPGP, updates RFC 4880) +* [RFC 4880][] (OpenPGP, obsoletes RFCs 1991 and 2440) +* [RFC 3156][] (OpenPGP and RFC 1847, updates RFC 2015) +* [RFC 2440][] (OpenPGP (PGP 5.x, the successor to 2.6.x), builds on RFC 1991) +* [RFC 2015][] (Using PGP with RFC 1847, builds on RFC 1848) +* [RFC 1991][] (PGP version 2.6.x) +* [RFC 1848][] (MIME Object Security Services (MOSS)) +* [RFC 1847][] (multipart/signed and multipart/encrypted) + +Summary: + +* PGP is the encryption protocol (RFCs 1991, 2440, 4880, and 5581). +* Over the years, packaging PGP-encrypted email has undergone several + changes: + 1. Include the encrypted body as plain/text. + 2. PGP/MIME: separate body and signature using MIME (RFC 2015). + 3. OpenPGP: minor changes for packaging more recent PGP protocols + (RFC 3156). +* S/MIME is a parallel effort which uses an alternate key system + ([CMS][]) based on certificates (similar to SSL/TLS with [X.509][] + certificates and certificate authorities). + +The main difference between using OpenPGP and S/MIME is in how you +decide to trust other people's keys. With OpenPGP, there is a [web of +trust][wot] in which you manually decide how much trust to assign to +each key. Possible trust levels include + +* unknown: you haven't made a judgement about the owner. +* none: the owner is known to improperly sign other keys. +* marginal: the owner knows what she's doing. +* full: the owner's signature is as good as your own (analagous to a + Certificate Authority). + +To validate a key K using the web of trust, it must satisfy two +conditions: + +1. it is signed by enough valid keys, meaning + * you have signed it personally, + * it has been signed by one fully trusted key, or + * it has been signed by three (configurable) marginally trusted keys; and +2. the path of signed keys leading from K back to you is five + (configurable) steps or shorter. + +See the [GPG manual][gpg-trust] for more details. + +The certificate authority system in web-of-trust terms is a system in +which you fully trust a number of root certificates and all the +decisions they make about delegating signing authority. You can also +explicity accept other keys (e.g. when connecting to an HTTPS server +with a self-signed key). + + +[PGP]: http://en.wikipedia.org/wiki/Pretty_Good_Privacy +[S/MIME]: http://en.wikipedia.org/wiki/S/MIME +[RFC 5581]: http://tools.ietf.org/html/rfc5581 +[RFC 4880]: http://tools.ietf.org/html/rfc4880 +[RFC 3156]: http://tools.ietf.org/html/rfc3156 +[RFC 2440]: http://tools.ietf.org/html/rfc2440 +[RFC 2015]: http://tools.ietf.org/html/rfc2015 +[RFC 1991]: http://tools.ietf.org/html/rfc1991 +[RFC 1848]: http://tools.ietf.org/html/rfc1848 +[RFC 1847]: http://tools.ietf.org/html/rfc1847 +[CMS]: http://en.wikipedia.org/wiki/Cryptographic_Message_Syntax +[X.509]: http://en.wikipedia.org/wiki/X.509 +[wot]: http://en.wikipedia.org/wiki/Web_of_trust +[gpg-trust]: http://www.gnupg.org/gph/en/manual.html#AEN335 + +[[!tag tags/linux]] -- 2.26.2