Definition[]
Open Pretty Good Privacy (OpenPGP) is
| “ | [a] protocol defined in IETF RFCs 2440 and 3156 for encrypting messages and creating certificates using public key cryptography. Most mail clients do not support OpenPGP by default; instead, third-party plug-ins can be used in conjunction with the mail clients. OpenPGP uses a "web of trust" model for key management, which relies on users for management and control, making it unsuitable for medium to large implementations.[1] | ” |
| “ | [RFC 3156] [RFC 4880] is an alternative proposed Internet standard for digitally signing and encrypting email. OpenPGP is an adaption of the message format implemented by the Pretty Good Privacy (PGP) email encryption system that was first released in 1991.[2] | ” |
Overview[]
Whereas the PGP formats were never formally specified, OpenPGP specifies open, royalty-free formats for encryption keys, signatures, and messages. Today the most widely used implementation of OpenPGP is Gnu Privacy Guard (gpg), an open source command-line program that runs on many platforms. Most desktop and web-based applications that allow users to send and receive OpenPGP-encrypted mail rely on gpg as the actual cryptographic engine.
OpenPGP provides similar functionality as S/MIME, with two significant differences:
- Key Certification: Whereas X.509 certificates are issued by Certificate Authorities (or local agencies that have been delegated authority by a CA to issue certificates), users generate their own OpenPGP public and private keys and then solicit signatures for their public keys from individuals or organizations to which they are known. Whereas X.509 certificates can be signed by a single party, OpenPGP public keys can be signed by any number of parties. Whereas X.509 certificates are trusted if there is a valid PKIX chain to a trusted root, an OpenPGP public key is trusted if it is signed by another OpenPGP public key that is trusted by the recipient. This is called the "Web-of-Trust."
- Key Distribution: OpenPGP does not include the sender’s public key with each message, so it is necessary for recipients to of OpenPGP-messages to separately obtain the sender’s public key in order to verify the message. Many organizations post OpenPGP keys on SSL-protected websites: people who wish to verify digital signatures or send these organizations encrypted mail need to manually download these keys and add them to their OpenPGP clients. Keys may also be registered with the OpenPGP "public key servers." OpenPGP "public key servers" are computers that maintain a database of PGP public keys organized by email address. Anyone may post a public key to the OpenPGP key servers, and that public key may contain any email address. There is no vetting of OpenPGP keys, so it is trivial for an attacker to submit a fraudulent certificate. Such certificates can provide a legitimate name and an incorrect email address, possibly tricking sender into using it to send mail to an attacker instead of (or addition to) the intended recipient. Alternatively, spoofed certificates can have a legitimate name and email address, and a fraudulent key, causing the sender to encrypt a message so that it cannot be read by the intended recipient but can be read by the attacker.
In theory the Web-of-Trust minimizes the problems of the key servers—an OpenPGP user can simply download all of the keys associated with a particular email address and use the Web of Trust to decide which keys to Trust. Because Web-of-Trust supports arbitrary validation geometries, it allows both the top-down certification geometry of X.509 as well as peer-to-peer approaches. In practice, users find this process confusing, and the Web-of-Trust has not seen widespread adoption.
Like S/MIME, one of the biggest hurdles of deploying OpenPGP has been the need for users to create certificates in advance and the difficulty of obtaining the certificate of another user in order to send an encrypted message. However, in OpenPGP this difficulty impacts both digital signatures and encryption, since OpenPGP messages do not include the sender's digital certificate in the signature.
References[]
- ↑ NIST Special Publication 800-45, Glossary, at A-2.
- ↑ NIST Special Publication 800-177, at 10.
Source[]
- "Overview" section: NIST Special Publication 800-177, at 10-11.