--- /dev/null
+[[!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]]