draft-ietf-openpgp-rfc2440bis-15.txt   draft-ietf-openpgp-rfc2440bis-16.txt 
Network Working Group Jon Callas Network Working Group Jon Callas
Category: INTERNET-DRAFT PGP Corporation Category: INTERNET-DRAFT PGP Corporation
draft-ietf-openpgp-rfc2440bis-15.txt draft-ietf-openpgp-rfc2440bis-16.txt
Expires April 2006 Lutz Donnerhacke Expires October 2006 Lutz Donnerhacke
October 2005 April 2006
Obsoletes: 1991, 2440 Hal Finney Obsoletes: 1991, 2440 Hal Finney
PGP Corporation PGP Corporation
David Shaw
Rodney Thayer Rodney Thayer
OpenPGP Message Format OpenPGP Message Format
draft-ietf-openpgp-rfc2440bis-15.txt draft-ietf-openpgp-rfc2440bis-16.txt
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
IPR Claim Notice IPR Claim Notice
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Status of this Memo Status of this Memo
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as reference
reference material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
IANA Considerations IANA Considerations
This document defines many tag values, yet it doesn't describe a This document defines many tag values, yet it doesn't describe a
skipping to change at page 3, line 54 skipping to change at page 3, line 54
4.2.3. Packet Length Examples 16 4.2.3. Packet Length Examples 16
4.3. Packet Tags 16 4.3. Packet Tags 16
5. Packet Types 17 5. Packet Types 17
5.1. Public-Key Encrypted Session Key Packets (Tag 1) 17 5.1. Public-Key Encrypted Session Key Packets (Tag 1) 17
5.2. Signature Packet (Tag 2) 18 5.2. Signature Packet (Tag 2) 18
5.2.1. Signature Types 18 5.2.1. Signature Types 18
5.2.2. Version 3 Signature Packet Format 21 5.2.2. Version 3 Signature Packet Format 21
5.2.3. Version 4 Signature Packet Format 23 5.2.3. Version 4 Signature Packet Format 23
5.2.3.1. Signature Subpacket Specification 24 5.2.3.1. Signature Subpacket Specification 24
5.2.3.2. Signature Subpacket Types 25 5.2.3.2. Signature Subpacket Types 25
5.2.3.3. Notes on Self-Signatures 25 5.2.3.3. Notes on Self-Signatures 26
5.2.3.4. Signature creation time 26 5.2.3.4. Signature creation time 27
5.2.3.5. Issuer 27 5.2.3.5. Issuer 27
5.2.3.6. Key expiration time 27 5.2.3.6. Key expiration time 27
5.2.3.7. Preferred symmetric algorithms 27 5.2.3.7. Preferred symmetric algorithms 27
5.2.3.8. Preferred hash algorithms 27 5.2.3.8. Preferred hash algorithms 27
5.2.3.9. Preferred compression algorithms 27 5.2.3.9. Preferred compression algorithms 27
5.2.3.10.Signature expiration time 27 5.2.3.10.Signature expiration time 28
5.2.3.11.Exportable Certification 28 5.2.3.11.Exportable Certification 28
5.2.3.12.Revocable 28 5.2.3.12.Revocable 28
5.2.3.13.Trust signature 28 5.2.3.13.Trust signature 29
5.2.3.14.Regular expression 29 5.2.3.14.Regular expression 29
5.2.3.15.Revocation key 29 5.2.3.15.Revocation key 29
5.2.3.16.Notation Data 29 5.2.3.16.Notation Data 30
5.2.3.17.Key server preferences 30 5.2.3.17.Key server preferences 30
5.2.3.18.Preferred key server 30 5.2.3.18.Preferred key server 31
5.2.3.19.Primary User ID 31 5.2.3.19.Primary User ID 31
5.2.3.20.Policy URI 31 5.2.3.20.Policy URI 31
5.2.3.21.Key Flags 31 5.2.3.21.Key Flags 31
5.2.3.22.Signer's User ID 32 5.2.3.22.Signer's User ID 32
5.2.3.23.Reason for Revocation 32 5.2.3.23.Reason for Revocation 33
5.2.3.24.Features 33 5.2.3.24.Features 33
5.2.3.25.Signature Target 34 5.2.3.25.Signature Target 34
5.2.3.26.Embedded Signature 34 5.2.3.26.Embedded Signature 34
5.2.4. Computing Signatures 34 5.2.4. Computing Signatures 34
5.2.4.1. Subpacket Hints 35 5.2.4.1. Subpacket Hints 35
5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) 36 5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) 36
5.4. One-Pass Signature Packets (Tag 4) 37 5.4. One-Pass Signature Packets (Tag 4) 37
5.5. Key Material Packet 37 5.5. Key Material Packet 37
5.5.1. Key Packet Variants 37 5.5.1. Key Packet Variants 38
5.5.1.1. Public Key Packet (Tag 6) 37 5.5.1.1. Public Key Packet (Tag 6) 38
5.5.1.2. Public Subkey Packet (Tag 14) 38 5.5.1.2. Public Subkey Packet (Tag 14) 38
5.5.1.3. Secret Key Packet (Tag 5) 38 5.5.1.3. Secret Key Packet (Tag 5) 38
5.5.1.4. Secret Subkey Packet (Tag 7) 38 5.5.1.4. Secret Subkey Packet (Tag 7) 38
5.5.2. Public Key Packet Formats 38 5.5.2. Public Key Packet Formats 38
5.5.3. Secret Key Packet Formats 40 5.5.3. Secret Key Packet Formats 40
5.6. Compressed Data Packet (Tag 8) 41 5.6. Compressed Data Packet (Tag 8) 42
5.7. Symmetrically Encrypted Data Packet (Tag 9) 42 5.7. Symmetrically Encrypted Data Packet (Tag 9) 42
5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 43 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 43
5.9. Literal Data Packet (Tag 11) 43 5.9. Literal Data Packet (Tag 11) 43
5.10. Trust Packet (Tag 12) 44 5.10. Trust Packet (Tag 12) 44
5.11. User ID Packet (Tag 13) 44 5.11. User ID Packet (Tag 13) 44
5.12. User Attribute Packet (Tag 17) 44 5.12. User Attribute Packet (Tag 17) 45
5.12.1. The Image Attribute Subpacket 45 5.12.1. The Image Attribute Subpacket 45
5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 46 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 46
5.14. Modification Detection Code Packet (Tag 19) 47 5.14. Modification Detection Code Packet (Tag 19) 48
6. Radix-64 Conversions 48 6. Radix-64 Conversions 48
6.1. An Implementation of the CRC-24 in "C" 49 6.1. An Implementation of the CRC-24 in "C" 49
6.2. Forming ASCII Armor 49 6.2. Forming ASCII Armor 49
6.3. Encoding Binary in Radix-64 51 6.3. Encoding Binary in Radix-64 52
6.4. Decoding Radix-64 52 6.4. Decoding Radix-64 53
6.5. Examples of Radix-64 53 6.5. Examples of Radix-64 53
6.6. Example of an ASCII Armored Message 53 6.6. Example of an ASCII Armored Message 54
7. Cleartext signature framework 54 7. Cleartext signature framework 54
7.1. Dash-Escaped Text 54 7.1. Dash-Escaped Text 55
8. Regular Expressions 55 8. Regular Expressions 55
9. Constants 55 9. Constants 56
9.1. Public Key Algorithms 56 9.1. Public Key Algorithms 56
9.2. Symmetric Key Algorithms 56 9.2. Symmetric Key Algorithms 56
9.3. Compression Algorithms 57 9.3. Compression Algorithms 57
9.4. Hash Algorithms 57 9.4. Hash Algorithms 57
10. Packet Composition 57 10. Packet Composition 58
10.1. Transferable Public Keys 57 10.1. Transferable Public Keys 58
10.2. OpenPGP Messages 59 10.2. Transferable Secret Keys 59
10.3. Detached Signatures 59 10.3. OpenPGP Messages 59
10.4. Detached Signatures 60
11. Enhanced Key Formats 60 11. Enhanced Key Formats 60
11.1. Key Structures 60 11.1. Key Structures 60
11.2. Key IDs and Fingerprints 60 11.2. Key IDs and Fingerprints 61
12. Notes on Algorithms 61 12. Notes on Algorithms 62
12.1. Symmetric Algorithm Preferences 61 12.1. Symmetric Algorithm Preferences 62
12.2. Other Algorithm Preferences 62 12.2. Other Algorithm Preferences 63
12.2.1. Compression Preferences 62 12.2.1. Compression Preferences 63
12.2.2. Hash Algorithm Preferences 63 12.2.2. Hash Algorithm Preferences 64
12.3. Plaintext 63 12.3. Plaintext 64
12.4. RSA 63 12.4. RSA 64
12.5. DSA 63 12.5. DSA 64
12.6. Elgamal 64 12.6. Elgamal 65
12.7. Reserved Algorithm Numbers 64 12.7. Reserved Algorithm Numbers 65
12.8. OpenPGP CFB mode 64 12.8. OpenPGP CFB mode 65
13. Security Considerations 65 13. Security Considerations 67
14. Implementation Nits 68 14. Implementation Nits 70
15. Authors' Addresses 69 15. Authors' Addresses 70
16. References (Normative) 70 16. References (Normative) 71
17. References (Non-Normative) 72 17. References (Informative) 73
18. Full Copyright Statement 72 18. Full Copyright Statement 74
1. Introduction 1. Introduction
This document provides information on the message-exchange packet This document provides information on the message-exchange packet
formats used by OpenPGP to provide encryption, decryption, signing, formats used by OpenPGP to provide encryption, decryption, signing,
and key management functions. It is a revision of RFC 2440, "OpenPGP and key management functions. It is a revision of RFC 2440, "OpenPGP
Message Format", which itself replaces RFC 1991, "PGP Message Message Format", which itself replaces RFC 1991, "PGP Message
Exchange Formats." Exchange Formats."
1.1. Terms 1.1. Terms
skipping to change at page 10, line 29 skipping to change at page 10, line 29
3.6. Keyrings 3.6. Keyrings
A keyring is a collection of one or more keys in a file or database. A keyring is a collection of one or more keys in a file or database.
Traditionally, a keyring is simply a sequential list of keys, but Traditionally, a keyring is simply a sequential list of keys, but
may be any suitable database. It is beyond the scope of this may be any suitable database. It is beyond the scope of this
standard to discuss the details of keyrings or other databases. standard to discuss the details of keyrings or other databases.
3.7. String-to-key (S2K) specifiers 3.7. String-to-key (S2K) specifiers
String-to-key (S2K) specifiers are used to convert passphrase String-to-key (S2K) specifiers are used to convert passphrase
strings into symmetric-key encryption/decryption keys. They are strings into symmetric-key encryption/decryption keys. They are used
used in two places, currently: to encrypt the secret part of private in two places, currently: to encrypt the secret part of private keys
keys in the private keyring, and to convert passphrases to in the private keyring, and to convert passphrases to encryption
encryption keys for symmetrically encrypted messages. keys for symmetrically encrypted messages.
3.7.1. String-to-key (S2K) specifier types 3.7.1. String-to-key (S2K) specifier types
There are three types of S2K specifiers currently supported, and There are three types of S2K specifiers currently supported, and
some reserved values: some reserved values:
ID S2K Type ID S2K Type
-- --- ---- -- --- ----
0 Simple S2K 0 Simple S2K
1 Salted S2K 1 Salted S2K
2 Illegal value 2 Reserved value
3 Iterated and Salted S2K 3 Iterated and Salted S2K
100 to 110 Private/Experimental S2K 100 to 110 Private/Experimental S2K
These are described as follows: These are described as follows:
3.7.1.1. Simple S2K 3.7.1.1. Simple S2K
This directly hashes the string to produce the key data. See below This directly hashes the string to produce the key data. See below
for how this hashing is done. for how this hashing is done.
skipping to change at page 12, line 43 skipping to change at page 12, line 43
3.7.2.1. Secret key encryption 3.7.2.1. Secret key encryption
An S2K specifier can be stored in the secret keyring to specify how An S2K specifier can be stored in the secret keyring to specify how
to convert the passphrase to a key that unlocks the secret data. to convert the passphrase to a key that unlocks the secret data.
Older versions of PGP just stored a cipher algorithm octet preceding Older versions of PGP just stored a cipher algorithm octet preceding
the secret data or a zero to indicate that the secret data was the secret data or a zero to indicate that the secret data was
unencrypted. The MD5 hash function was always used to convert the unencrypted. The MD5 hash function was always used to convert the
passphrase to a key for the specified cipher algorithm. passphrase to a key for the specified cipher algorithm.
For compatibility, when an S2K specifier is used, the special value For compatibility, when an S2K specifier is used, the special value
255 is stored in the position where the hash algorithm octet would 254 or 255 is stored in the position where the hash algorithm octet
have been in the old data structure. This is then followed would have been in the old data structure. This is then followed
immediately by a one-octet algorithm identifier, and then by the S2K immediately by a one-octet algorithm identifier, and then by the S2K
specifier as encoded above. specifier as encoded above.
Therefore, preceding the secret data there will be one of these Therefore, preceding the secret data there will be one of these
possibilities: possibilities:
0: secret data is unencrypted (no pass phrase) 0: secret data is unencrypted (no pass phrase)
255 or 254: followed by algorithm octet and S2K specifier 255 or 254: followed by algorithm octet and S2K specifier
Cipher alg: use Simple S2K algorithm using MD5 hash Cipher alg: use Simple S2K algorithm using MD5 hash
This last possibility, the cipher algorithm number with an implicit This last possibility, the cipher algorithm number with an implicit
skipping to change at page 15, line 24 skipping to change at page 15, line 24
A one-octet Body Length header encodes a length of from 0 to 191 A one-octet Body Length header encodes a length of from 0 to 191
octets. This type of length header is recognized because the one octets. This type of length header is recognized because the one
octet value is less than 192. The body length is equal to: octet value is less than 192. The body length is equal to:
bodyLen = 1st_octet; bodyLen = 1st_octet;
4.2.2.2. Two-Octet Lengths 4.2.2.2. Two-Octet Lengths
A two-octet Body Length header encodes a length of from 192 to 8383 A two-octet Body Length header encodes a length of from 192 to 8383
octets. It is recognized because its first octet is in the range octets. It is recognized because its first octet is in the range 192
192 to 223. The body length is equal to: to 223. The body length is equal to:
bodyLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192 bodyLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192
4.2.2.3. Five-Octet Lengths 4.2.2.3. Five-Octet Lengths
A five-octet Body Length header consists of a single octet holding A five-octet Body Length header consists of a single octet holding
the value 255, followed by a four-octet scalar. The body length is the value 255, followed by a four-octet scalar. The body length is
equal to: equal to:
bodyLen = (2nd_octet << 24) | (3rd_octet << 16) | bodyLen = (2nd_octet << 24) | (3rd_octet << 16) |
skipping to change at page 15, line 55 skipping to change at page 15, line 55
from 1 to 1,073,741,824 (2 to the 30th power). It is recognized by from 1 to 1,073,741,824 (2 to the 30th power). It is recognized by
its one octet value that is greater than or equal to 224, and less its one octet value that is greater than or equal to 224, and less
than 255. The partial body length is equal to: than 255. The partial body length is equal to:
partialBodyLen = 1 << (1st_octet & 0x1f); partialBodyLen = 1 << (1st_octet & 0x1f);
Each Partial Body Length header is followed by a portion of the Each Partial Body Length header is followed by a portion of the
packet body data. The Partial Body Length header specifies this packet body data. The Partial Body Length header specifies this
portion's length. Another length header (one octet, two-octet, portion's length. Another length header (one octet, two-octet,
five-octet, or partial) follows that portion. The last length header five-octet, or partial) follows that portion. The last length header
in the packet MUST NOT be a partial Body Length header. Partial in the packet MUST NOT be a partial Body Length header. Partial Body
Body Length headers may only be used for the non-final parts of the Length headers may only be used for the non-final parts of the
packet. packet.
It might also be encoded in the following octet stream: 0xEF, first
32768 octets of data; 0xE1, next two octets of data; 0xE0, next one
octet of data; 0xF0, next 65536 octets of data; 0xC5, 0xDD, last
1693 octets of data. This is just one possible encoding, and many
variations are possible on the size of the Partial Body Length
headers, as long as a regular Body Length header encodes the last
portion of the data.
Note also that the last Body Length header can be a zero-length Note also that the last Body Length header can be a zero-length
header. header.
An implementation MAY use Partial Body Lengths for data packets, be An implementation MAY use Partial Body Lengths for data packets, be
they literal, compressed, or encrypted. The first partial length they literal, compressed, or encrypted. The first partial length
MUST be at least 512 octets long. Partial Body Lengths MUST NOT be MUST be at least 512 octets long. Partial Body Lengths MUST NOT be
used for any other packet types. used for any other packet types.
4.2.3. Packet Length Examples 4.2.3. Packet Length Examples
skipping to change at page 16, line 36 skipping to change at page 16, line 28
A packet with length 100 may have its length encoded in one octet: A packet with length 100 may have its length encoded in one octet:
0x64. This is followed by 100 octets of data. 0x64. This is followed by 100 octets of data.
A packet with length 1723 may have its length coded in two octets: A packet with length 1723 may have its length coded in two octets:
0xC5, 0xFB. This header is followed by the 1723 octets of data. 0xC5, 0xFB. This header is followed by the 1723 octets of data.
A packet with length 100000 may have its length encoded in five A packet with length 100000 may have its length encoded in five
octets: 0xFF, 0x00, 0x01, 0x86, 0xA0. octets: 0xFF, 0x00, 0x01, 0x86, 0xA0.
It might also be encoded in the following octet stream: 0xEF, first
32768 octets of data; 0xE1, next two octets of data; 0xE0, next one
octet of data; 0xF0, next 65536 octets of data; 0xC5, 0xDD, last
1693 octets of data. This is just one possible encoding, and many
variations are possible on the size of the Partial Body Length
headers, as long as a regular Body Length header encodes the last
portion of the data.
Please note that in all of these explanations, the total length of Please note that in all of these explanations, the total length of
the packet is the length of the header(s) plus the length of the the packet is the length of the header(s) plus the length of the
body. body.
4.3. Packet Tags 4.3. Packet Tags
The packet tag denotes what type of packet the body holds. Note that The packet tag denotes what type of packet the body holds. Note that
old format headers can only have tags less than 16, whereas new old format headers can only have tags less than 16, whereas new
format headers can have tags as great as 63. The defined tags (in format headers can have tags as great as 63. The defined tags (in
decimal) are: decimal) are:
skipping to change at page 17, line 22 skipping to change at page 17, line 22
19 -- Modification Detection Code Packet 19 -- Modification Detection Code Packet
60 to 63 -- Private or Experimental Values 60 to 63 -- Private or Experimental Values
5. Packet Types 5. Packet Types
5.1. Public-Key Encrypted Session Key Packets (Tag 1) 5.1. Public-Key Encrypted Session Key Packets (Tag 1)
A Public-Key Encrypted Session Key packet holds the session key used A Public-Key Encrypted Session Key packet holds the session key used
to encrypt a message. Zero or more Encrypted Session Key packets to encrypt a message. Zero or more Encrypted Session Key packets
(either Public-Key or Symmetric-Key) may precede a Symmetrically (either Public-Key or Symmetric-Key) may precede a Symmetrically
Encrypted Data Packet, which holds an encrypted message. The Encrypted Data Packet, which holds an encrypted message. The message
message is encrypted with the session key, and the session key is is encrypted with the session key, and the session key is itself
itself encrypted and stored in the Encrypted Session Key packet(s). encrypted and stored in the Encrypted Session Key packet(s). The
The Symmetrically Encrypted Data Packet is preceded by one Symmetrically Encrypted Data Packet is preceded by one Public-Key
Public-Key Encrypted Session Key packet for each OpenPGP key to Encrypted Session Key packet for each OpenPGP key to which the
which the message is encrypted. The recipient of the message finds message is encrypted. The recipient of the message finds a session
a session key that is encrypted to their public key, decrypts the key that is encrypted to their public key, decrypts the session key,
session key, and then uses the session key to decrypt the message. and then uses the session key to decrypt the message.
The body of this packet consists of: The body of this packet consists of:
- A one-octet number giving the version number of the packet type. - A one-octet number giving the version number of the packet type.
The currently defined value for packet version is 3. The currently defined value for packet version is 3.
- An eight-octet number that gives the key ID of the public key - An eight-octet number that gives the key ID of the public key
that the session key is encrypted to. If the session key is that the session key is encrypted to. If the session key is
encrypted to a subkey then the key ID of this subkey is used encrypted to a subkey then the key ID of this subkey is used
here instead of the key ID of the primary key. here instead of the key ID of the primary key.
skipping to change at page 18, line 13 skipping to change at page 18, line 13
- MPI of Elgamal (Diffie-Hellman) value g**k mod p. - MPI of Elgamal (Diffie-Hellman) value g**k mod p.
- MPI of Elgamal (Diffie-Hellman) value m * y**k mod p. - MPI of Elgamal (Diffie-Hellman) value m * y**k mod p.
The value "m" in the above formulas is derived from the session key The value "m" in the above formulas is derived from the session key
as follows. First the session key is prefixed with a one-octet as follows. First the session key is prefixed with a one-octet
algorithm identifier that specifies the symmetric encryption algorithm identifier that specifies the symmetric encryption
algorithm used to encrypt the following Symmetrically Encrypted Data algorithm used to encrypt the following Symmetrically Encrypted Data
Packet. Then a two-octet checksum is appended which is equal to the Packet. Then a two-octet checksum is appended which is equal to the
sum of the preceding session key octets, not including the algorithm sum of the preceding session key octets, not including the algorithm
identifier, modulo 65536. This value is then encoded as described identifier, modulo 65536. This value is then encoded as described in
in PKCS-1 block encoding EME-PKCS1-v1_5 [RFC2437] to form the "m" PKCS-1 block encoding EME-PKCS1-v1_5 [RFC2437] to form the "m" value
value used in the formulas above. used in the formulas above.
Note that when an implementation forms several PKESKs with one Note that when an implementation forms several PKESKs with one
session key, forming a message that can be decrypted by several session key, forming a message that can be decrypted by several
keys, the implementation MUST make new PKCS-1 encoding for each key. keys, the implementation MUST make a new PKCS-1 encoding for each
key.
An implementation MAY accept or use a Key ID of zero as a "wild An implementation MAY accept or use a Key ID of zero as a "wild
card" or "speculative" Key ID. In this case, the receiving card" or "speculative" Key ID. In this case, the receiving
implementation would try all available private keys, checking for a implementation would try all available private keys, checking for a
valid decrypted session key. This format helps reduce traffic valid decrypted session key. This format helps reduce traffic
analysis of messages. analysis of messages.
5.2. Signature Packet (Tag 2) 5.2. Signature Packet (Tag 2)
A signature packet describes a binding between some public key and A signature packet describes a binding between some public key and
skipping to change at page 18, line 52 skipping to change at page 18, line 53
message that is encrypted to a V3 key, it is reasonable to create a message that is encrypted to a V3 key, it is reasonable to create a
V3 signature. V3 signature.
5.2.1. Signature Types 5.2.1. Signature Types
There are a number of possible meanings for a signature, which are There are a number of possible meanings for a signature, which are
specified in a signature type octet in any given signature. See specified in a signature type octet in any given signature. See
section 5.2.4, "Computing Signatures," for detailed information on section 5.2.4, "Computing Signatures," for detailed information on
how to compute and verify signatures of each type. how to compute and verify signatures of each type.
There are a number of possible meanings for a signature, which may
be indicated in a signature type octet in any given signature.
Please note that the vagueness of these meanings is not a flaw, but
a feature of the system. Because OpenPGP places final authority for
validity upon the receiver of a signature, it may be that one
signer's casual act might be more rigorous than some other
authority's positive act.
These meanings are: These meanings are:
0x00: Signature of a binary document. 0x00: Signature of a binary document.
This means the signer owns it, created it, or certifies that it This means the signer owns it, created it, or certifies that it
has not been modified. has not been modified.
0x01: Signature of a canonical text document. 0x01: Signature of a canonical text document.
This means the signer owns it, created it, or certifies that it This means the signer owns it, created it, or certifies that it
has not been modified. The signature is calculated over the has not been modified. The signature is calculated over the text
text data with its line endings converted to <CR><LF>. data with its line endings converted to <CR><LF>.
0x02: Standalone signature. 0x02: Standalone signature.
This signature is a signature of only its own subpacket This signature is a signature of only its own subpacket
contents. It is calculated identically to a signature over a contents. It is calculated identically to a signature over a
zero-length binary document. Note that it doesn't make sense to zero-length binary document. Note that it doesn't make sense to
have a V3 standalone signature. have a V3 standalone signature.
0x10: Generic certification of a User ID and Public Key packet. 0x10: Generic certification of a User ID and Public Key packet.
The issuer of this certification does not make any particular The issuer of this certification does not make any particular
assertion as to how well the certifier has checked that the assertion as to how well the certifier has checked that the
skipping to change at page 19, line 34 skipping to change at page 19, line 43
specified. specified.
0x12: Casual certification of a User ID and Public Key packet. 0x12: Casual certification of a User ID and Public Key packet.
The issuer of this certification has done some casual The issuer of this certification has done some casual
verification of the claim of identity. verification of the claim of identity.
0x13: Positive certification of a User ID and Public Key packet. 0x13: Positive certification of a User ID and Public Key packet.
The issuer of this certification has done substantial The issuer of this certification has done substantial
verification of the claim of identity. verification of the claim of identity.
Please note that the vagueness of these certification claims is
not a flaw, but a feature of the system. Because OpenPGP places
final authority for validity upon the receiver of a
certification, it may be that one authority's casual
certification might be more rigorous than some other authority's
positive certification. These classifications allow a
certification authority to issue fine-grained claims.
Most OpenPGP implementations make their "key signatures" as 0x10 Most OpenPGP implementations make their "key signatures" as 0x10
certifications. Some implementations can issue 0x11-0x13 certifications. Some implementations can issue 0x11-0x13
certifications, but few differentiate between the types. certifications, but few differentiate between the types.
0x18: Subkey Binding Signature 0x18: Subkey Binding Signature
This signature is a statement by the top-level signing key that This signature is a statement by the top-level signing key that
indicates that it owns the subkey. This signature is calculated indicates that it owns the subkey. This signature is calculated
directly on the subkey itself, not on any User ID or other directly on the primary key and subkey, and not on any User ID
packets. A signature that binds a signing subkey SHOULD have an or other packets. A signature that binds a signing subkey MUST
embedded signature subpacket in this binding signature which have an embedded signature subpacket in this binding signature
contains a 0x19 signature made by the signing subkey on the which contains a 0x19 signature made by the signing subkey on
primary key. the primary key and subkey.
0x19 Primary Key Binding Signature 0x19 Primary Key Binding Signature
This signature is a statement by a signing subkey, indicating This signature is a statement by a signing subkey, indicating
that it is owned by the primary key. This signature is that it is owned by the primary key and subkey. This signature
calculated directly on the primary key itself, and not on any is calculated the same way as a 0x18 signature: directly on the
User ID or other packets. primary key and subkey, and not on any User ID or other packets.
0x1F: Signature directly on a key 0x1F: Signature directly on a key
This signature is calculated directly on a key. It binds the This signature is calculated directly on a key. It binds the
information in the signature subpackets to the key, and is information in the signature subpackets to the key, and is
appropriate to be used for subpackets that provide information appropriate to be used for subpackets that provide information
about the key, such as the revocation key subpacket. It is also about the key, such as the revocation key subpacket. It is also
appropriate for statements that non-self certifiers want to make appropriate for statements that non-self certifiers want to make
about the key itself, rather than the binding between a key and about the key itself, rather than the binding between a key and
a name. a name.
0x20: Key revocation signature 0x20: Key revocation signature
The signature is calculated directly on the key being revoked. The signature is calculated directly on the key being revoked. A
A revoked key is not to be used. Only revocation signatures by revoked key is not to be used. Only revocation signatures by the
the key being revoked, or by an authorized revocation key, key being revoked, or by an authorized revocation key, should be
should be considered valid revocation signatures. considered valid revocation signatures.
0x28: Subkey revocation signature 0x28: Subkey revocation signature
The signature is calculated directly on the subkey being The signature is calculated directly on the subkey being
revoked. A revoked subkey is not to be used. Only revocation revoked. A revoked subkey is not to be used. Only revocation
signatures by the top-level signature key that is bound to this signatures by the top-level signature key that is bound to this
subkey, or by an authorized revocation key, should be considered subkey, or by an authorized revocation key, should be considered
valid revocation signatures. valid revocation signatures.
0x30: Certification revocation signature 0x30: Certification revocation signature
This signature revokes an earlier User ID certification This signature revokes an earlier User ID certification
skipping to change at page 21, line 49 skipping to change at page 21, line 49
Algorithm Specific Fields for DSA signatures: Algorithm Specific Fields for DSA signatures:
- MPI of DSA value r. - MPI of DSA value r.
- MPI of DSA value s. - MPI of DSA value s.
The signature calculation is based on a hash of the signed data, as The signature calculation is based on a hash of the signed data, as
described above. The details of the calculation are different for described above. The details of the calculation are different for
DSA signature than for RSA signatures. DSA signature than for RSA signatures.
The hash h is PKCS-1 padded exactly the same way as for the above
described RSA signatures.
With RSA signatures, the hash value is encoded as described in With RSA signatures, the hash value is encoded as described in
PKCS-1 section 9.2.1 encoded using PKCS-1 encoding type PKCS-1 section 9.2.1 encoded using PKCS-1 encoding type
EMSA-PKCS1-v1_5 [RFC2437]. This requires inserting the hash value EMSA-PKCS1-v1_5 [RFC2437]. This requires inserting the hash value as
as an octet string into an ASN.1 structure. The object identifier an octet string into an ASN.1 structure. The object identifier for
for the type of hash being used is included in the structure. The the type of hash being used is included in the structure. The
hexadecimal representations for the currently defined hash hexadecimal representations for the currently defined hash
algorithms are: algorithms are:
- MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05 - MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05
- RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01 - RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01
- SHA-1: 0x2B, 0x0E, 0x03, 0x02, 0x1A - SHA-1: 0x2B, 0x0E, 0x03, 0x02, 0x1A
- SHA224: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04
- SHA256: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01 - SHA256: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01
- SHA384: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02 - SHA384: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02
- SHA512: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03 - SHA512: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03
The ASN.1 OIDs are: The ASN.1 OIDs are:
- MD5: 1.2.840.113549.2.5 - MD5: 1.2.840.113549.2.5
- RIPEMD-160: 1.3.36.3.2.1 - RIPEMD-160: 1.3.36.3.2.1
- SHA-1: 1.3.14.3.2.26 - SHA-1: 1.3.14.3.2.26
- SHA224: 2.16.840.1.101.3.4.2.4
- SHA256: 2.16.840.1.101.3.4.2.1 - SHA256: 2.16.840.1.101.3.4.2.1
- SHA384: 2.16.840.1.101.3.4.2.2 - SHA384: 2.16.840.1.101.3.4.2.2
- SHA512: 2.16.840.1.101.3.4.2.3 - SHA512: 2.16.840.1.101.3.4.2.3
The full hash prefixes for these are: The full hash prefixes for these are:
MD5: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86, MD5: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86,
0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00,
0x04, 0x10 0x04, 0x10
RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24, RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24,
0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14 0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14
SHA-1: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E, SHA-1: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E,
0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14 0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14
SHA224: 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04, 0x05,
0x00, 0x04, 0x1C
SHA256: 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, SHA256: 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05,
0x00, 0x04, 0x20 0x00, 0x04, 0x20
SHA384: 0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, SHA384: 0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05,
0x00, 0x04, 0x30 0x00, 0x04, 0x30
SHA512: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, SHA512: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05,
0x00, 0x04, 0x40 0x00, 0x04, 0x40
DSA signatures MUST use hashes with a size of 160 bits, to match q,
the size of the group generated by the DSA key's generator value. DSA signatures MUST use hashes that are equal in size to the number
The hash function result is treated as a 160 bit number and used of bits of q, the group generated by the DSA key's generator value.
If the output size of the chosen hash is larger than the number of
bits of q, the hash result is truncated to fit by taking the number
of leftmost bits equal to the number of bits of q. This (possibly
truncated) hash function result is treated as a number and used
directly in the DSA signature algorithm. directly in the DSA signature algorithm.
5.2.3. Version 4 Signature Packet Format 5.2.3. Version 4 Signature Packet Format
The body of a version 4 Signature Packet contains: The body of a version 4 Signature Packet contains:
- One-octet version number (4). - One-octet version number (4).
- One-octet signature type. - One-octet signature type.
skipping to change at page 24, line 13 skipping to change at page 24, line 23
signature are described in a section below. signature are described in a section below.
5.2.3.1. Signature Subpacket Specification 5.2.3.1. Signature Subpacket Specification
A subpacket data set consists of zero or more signature subpackets. A subpacket data set consists of zero or more signature subpackets.
In signature packets the subpacket data set is preceded by a In signature packets the subpacket data set is preceded by a
two-octet scalar count of the length in octets of all the two-octet scalar count of the length in octets of all the
subpackets. A pointer incremented by this number will skip over the subpackets. A pointer incremented by this number will skip over the
subpacket data set. subpacket data set.
Each subpacket consists of a subpacket header and a body. The Each subpacket consists of a subpacket header and a body. The header
header consists of: consists of:
- the subpacket length (1, 2, or 5 octets) - the subpacket length (1, 2, or 5 octets)
- the subpacket type (1 octet) - the subpacket type (1 octet)
and is followed by the subpacket specific data. and is followed by the subpacket specific data.
The length includes the type octet but not this length. Its format The length includes the type octet but not this length. Its format
is similar to the "new" format packet header lengths, but cannot is similar to the "new" format packet header lengths, but cannot
have partial body lengths. That is: have partial body lengths. That is:
skipping to change at page 25, line 19 skipping to change at page 25, line 30
31 = signature target 31 = signature target
32 = embedded signature 32 = embedded signature
100 to 110 = internal or user-defined 100 to 110 = internal or user-defined
An implementation SHOULD ignore any subpacket of a type that it does An implementation SHOULD ignore any subpacket of a type that it does
not recognize. not recognize.
Bit 7 of the subpacket type is the "critical" bit. If set, it Bit 7 of the subpacket type is the "critical" bit. If set, it
denotes that the subpacket is one that is critical for the evaluator denotes that the subpacket is one that is critical for the evaluator
of the signature to recognize. If a subpacket is encountered that of the signature to recognize. If a subpacket is encountered that is
is marked critical but is unknown to the evaluating software, the marked critical but is unknown to the evaluating software, the
evaluator SHOULD consider the signature to be in error. evaluator SHOULD consider the signature to be in error.
An evaluator may "recognize" a subpacket, but not implement it. The An evaluator may "recognize" a subpacket, but not implement it. The
purpose of the critical bit is to allow the signer to tell an purpose of the critical bit is to allow the signer to tell an
evaluator that it would prefer a new, unknown feature to generate an evaluator that it would prefer a new, unknown feature to generate an
error than be ignored. error than be ignored.
Implementations SHOULD implement "preferences" and the "reason for Implementations SHOULD implement "preferences" and the "reason for
revocation" subpackets. Note, however, that if an implementation revocation" subpackets. Note, however, that if an implementation
chooses not to implement some of the preferences, it is required to chooses not to implement some of the preferences, it is required to
skipping to change at page 26, line 17 skipping to change at page 26, line 31
the subkey self-signature apply to the subkey. Lastly, subpackets on the subkey self-signature apply to the subkey. Lastly, subpackets on
the direct-key signature apply to the entire key. the direct-key signature apply to the entire key.
Implementing software should interpret a self-signature's preference Implementing software should interpret a self-signature's preference
subpackets as narrowly as possible. For example, suppose a key has subpackets as narrowly as possible. For example, suppose a key has
two usernames, Alice and Bob. Suppose that Alice prefers the two usernames, Alice and Bob. Suppose that Alice prefers the
symmetric algorithm CAST5, and Bob prefers IDEA or TripleDES. If the symmetric algorithm CAST5, and Bob prefers IDEA or TripleDES. If the
software locates this key via Alice's name, then the preferred software locates this key via Alice's name, then the preferred
algorithm is CAST5, if software locates the key via Bob's name, then algorithm is CAST5, if software locates the key via Bob's name, then
the preferred algorithm is IDEA. If the key is located by key ID, the preferred algorithm is IDEA. If the key is located by key ID,
the algorithm of the primary User ID of the key provides the default the algorithm of the primary User ID of the key provides the
symmetric algorithm. preferred symmetric algorithm.
Revoking a self-signature or allowing it to expire has a semantic Revoking a self-signature or allowing it to expire has a semantic
meaning that varies with the signature type. Revoking the meaning that varies with the signature type. Revoking the
self-signature on a User ID effectively retires that user name. The self-signature on a User ID effectively retires that user name. The
self-signature is a statement, "My name X is tied to my signing key self-signature is a statement, "My name X is tied to my signing key
K" and is corroborated by other users' certifications. If another K" and is corroborated by other users' certifications. If another
user revokes their certification, they are effectively saying that user revokes their certification, they are effectively saying that
they no longer believe that name and that key are tied together. they no longer believe that name and that key are tied together.
Similarly, if the user themselves revokes their self-signature, it Similarly, if the user themselves revokes their self-signature, it
means the user no longer goes by that name, no longer has that email means the user no longer goes by that name, no longer has that email
skipping to change at page 27, line 30 skipping to change at page 27, line 41
a self-signature. a self-signature.
5.2.3.7. Preferred symmetric algorithms 5.2.3.7. Preferred symmetric algorithms
(array of one-octet values) (array of one-octet values)
Symmetric algorithm numbers that indicate which algorithms the key Symmetric algorithm numbers that indicate which algorithms the key
holder prefers to use. The subpacket body is an ordered list of holder prefers to use. The subpacket body is an ordered list of
octets with the most preferred listed first. It is assumed that only octets with the most preferred listed first. It is assumed that only
algorithms listed are supported by the recipient's software. algorithms listed are supported by the recipient's software.
Algorithm numbers in section 9. This is only found on a Algorithm numbers are in section 9. This is only found on a
self-signature. self-signature.
5.2.3.8. Preferred hash algorithms 5.2.3.8. Preferred hash algorithms
(array of one-octet values) (array of one-octet values)
Message digest algorithm numbers that indicate which algorithms the Message digest algorithm numbers that indicate which algorithms the
key holder prefers to receive. Like the preferred symmetric key holder prefers to receive. Like the preferred symmetric
algorithms, the list is ordered. Algorithm numbers are in section 9. algorithms, the list is ordered. Algorithm numbers are in section 9.
This is only found on a self-signature. This is only found on a self-signature.
skipping to change at page 28, line 40 skipping to change at page 28, line 52
addition to an exported key, then this situation can arise. addition to an exported key, then this situation can arise.
Some implementations do not represent the interest of a single user Some implementations do not represent the interest of a single user
(for example, a key server). Such implementations always trim local (for example, a key server). Such implementations always trim local
certifications from any key they handle. certifications from any key they handle.
5.2.3.12. Revocable 5.2.3.12. Revocable
(1 octet of revocability, 0 for not, 1 for revocable) (1 octet of revocability, 0 for not, 1 for revocable)
Signature's revocability status. Packet body contains a Boolean Signature's revocability status. Packet body contains a Boolean flag
flag indicating whether the signature is revocable. Signatures that indicating whether the signature is revocable. Signatures that are
are not revocable have any later revocation signatures ignored. not revocable have any later revocation signatures ignored. They
They represent a commitment by the signer that he cannot revoke his represent a commitment by the signer that he cannot revoke his
signature for the life of his key. If this packet is not present, signature for the life of his key. If this packet is not present,
the signature is revocable. the signature is revocable.
5.2.3.13. Trust signature 5.2.3.13. Trust signature
(1 octet "level" (depth), 1 octet of trust amount) (1 octet "level" (depth), 1 octet of trust amount)
Signer asserts that the key is not only valid, but also trustworthy, Signer asserts that the key is not only valid, but also trustworthy,
at the specified level. Level 0 has the same meaning as an ordinary at the specified level. Level 0 has the same meaning as an ordinary
validity signature. Level 1 means that the signed key is asserted validity signature. Level 1 means that the signed key is asserted to
to be a valid trusted introducer, with the 2nd octet of the body be a valid trusted introducer, with the 2nd octet of the body
specifying the degree of trust. Level 2 means that the signed key is specifying the degree of trust. Level 2 means that the signed key is
asserted to be trusted to issue level 1 trust signatures, i.e. that asserted to be trusted to issue level 1 trust signatures, i.e. that
it is a "meta introducer". Generally, a level n trust signature it is a "meta introducer". Generally, a level n trust signature
asserts that a key is trusted to issue level n-1 trust signatures. asserts that a key is trusted to issue level n-1 trust signatures.
The trust amount is in a range from 0-255, interpreted such that The trust amount is in a range from 0-255, interpreted such that
values less than 120 indicate partial trust and values of 120 or values less than 120 indicate partial trust and values of 120 or
greater indicate complete trust. Implementations SHOULD emit values greater indicate complete trust. Implementations SHOULD emit values
of 60 for partial trust and 120 for complete trust. of 60 for partial trust and 120 for complete trust.
5.2.3.14. Regular expression 5.2.3.14. Regular expression
skipping to change at page 29, line 26 skipping to change at page 29, line 38
Used in conjunction with trust signature packets (of level > 0) to Used in conjunction with trust signature packets (of level > 0) to
limit the scope of trust that is extended. Only signatures by the limit the scope of trust that is extended. Only signatures by the
target key on User IDs that match the regular expression in the body target key on User IDs that match the regular expression in the body
of this packet have trust extended by the trust signature subpacket. of this packet have trust extended by the trust signature subpacket.
The regular expression uses the same syntax as the Henry Spencer's The regular expression uses the same syntax as the Henry Spencer's
"almost public domain" regular expression package. A description of "almost public domain" regular expression package. A description of
the syntax is found in a section below. the syntax is found in a section below.
5.2.3.15. Revocation key 5.2.3.15. Revocation key
(1 octet of class, 1 octet of algid, 20 octets of fingerprint) (1 octet of class, 1 octet of PK algorithm ID, 20 octets of
fingerprint)
Authorizes the specified key to issue revocation signatures for this Authorizes the specified key to issue revocation signatures for this
key. Class octet must have bit 0x80 set. If the bit 0x40 is set, key. Class octet must have bit 0x80 set. If the bit 0x40 is set,
then this means that the revocation information is sensitive. Other then this means that the revocation information is sensitive. Other
bits are for future expansion to other kinds of authorizations. This bits are for future expansion to other kinds of authorizations. This
is found on a self-signature. is found on a self-signature.
If the "sensitive" flag is set, the keyholder feels this subpacket If the "sensitive" flag is set, the keyholder feels this subpacket
contains private trust information that describes a real-world contains private trust information that describes a real-world
sensitive relationship. If this flag is set, implementations SHOULD sensitive relationship. If this flag is set, implementations SHOULD
skipping to change at page 30, line 8 skipping to change at page 30, line 21
This subpacket describes a "notation" on the signature that the This subpacket describes a "notation" on the signature that the
issuer wishes to make. The notation has a name and a value, each of issuer wishes to make. The notation has a name and a value, each of
which are strings of octets. There may be more than one notation in which are strings of octets. There may be more than one notation in
a signature. Notations can be used for any extension the issuer of a signature. Notations can be used for any extension the issuer of
the signature cares to make. The "flags" field holds four octets of the signature cares to make. The "flags" field holds four octets of
flags. flags.
All undefined flags MUST be zero. Defined flags are: All undefined flags MUST be zero. Defined flags are:
First octet: 0x80 = human-readable. This note value is text, a First octet: 0x80 = human-readable. This note value is text.
note from one person to another, and need
not have meaning to software.
Other octets: none. Other octets: none.
Notation names are arbitrary strings encoded in UTF-8. They reside Notation names are arbitrary strings encoded in UTF-8. They reside
two name spaces: The IETF name space and the user name space. two name spaces: The IETF name space and the user name space.
The IETF name space is registered with IANA. These names MUST NOT The IETF name space is registered with IANA. These names MUST NOT
contain the "@" character (0x40). This this is a tag for the user contain the "@" character (0x40). This this is a tag for the user
name space. name space.
Names in the user name space consist of a UTF-8 string tag followed Names in the user name space consist of a UTF-8 string tag followed
skipping to change at page 33, line 29 skipping to change at page 33, line 37
An implementation SHOULD implement this subpacket, include it in all An implementation SHOULD implement this subpacket, include it in all
revocation signatures, and interpret revocations appropriately. revocation signatures, and interpret revocations appropriately.
There are important semantic differences between the reasons, and There are important semantic differences between the reasons, and
there are thus important reasons for revoking signatures. there are thus important reasons for revoking signatures.
If a key has been revoked because of a compromise, all signatures If a key has been revoked because of a compromise, all signatures
created by that key are suspect. However, if it was merely created by that key are suspect. However, if it was merely
superseded or retired, old signatures are still valid. If the superseded or retired, old signatures are still valid. If the
revoked signature is the self-signature for certifying a User ID, a revoked signature is the self-signature for certifying a User ID, a
revocation denotes that that user name is no longer in use. Such a revocation denotes that that user name is no longer in use. Such a
revocation SHOULD include an 0x20 subpacket. revocation SHOULD include an 0x20 code.
Note that any signature may be revoked, including a certification on Note that any signature may be revoked, including a certification on
some other person's key. There are many good reasons for revoking a some other person's key. There are many good reasons for revoking a
certification signature, such as the case where the keyholder leaves certification signature, such as the case where the keyholder leaves
the employ of a business with an email address. A revoked the employ of a business with an email address. A revoked
certification is no longer a part of validity calculations. certification is no longer a part of validity calculations.
5.2.3.24. Features 5.2.3.24. Features
(N octets of flags) (N octets of flags)
skipping to change at page 38, line 37 skipping to change at page 38, line 45
A Secret Subkey packet (tag 7) is the subkey analog of the Secret A Secret Subkey packet (tag 7) is the subkey analog of the Secret
Key packet, and has exactly the same format. Key packet, and has exactly the same format.
5.5.2. Public Key Packet Formats 5.5.2. Public Key Packet Formats
There are two versions of key-material packets. Version 3 packets There are two versions of key-material packets. Version 3 packets
were first generated by PGP 2.6. Version 4 keys first appeared in were first generated by PGP 2.6. Version 4 keys first appeared in
PGP 5.0, and are the preferred key version for OpenPGP. PGP 5.0, and are the preferred key version for OpenPGP.
OpenPGP implementations SHOULD create keys with version 4 format. V3 OpenPGP implementations MUST create keys with version 4 format. V3
keys are deprecated; an implementation SHOULD NOT generate a V3 key, keys are deprecated; an implementation MUST NOT generate a V3 key,
but MAY accept it. An implementation MUST NOT create a V3 key with a but MAY accept it.
public key algorithm other than RSA.
A version 3 public key or public subkey packet contains: A version 3 public key or public subkey packet contains:
- A one-octet version number (3). - A one-octet version number (3).
- A four-octet number denoting the time that the key was created. - A four-octet number denoting the time that the key was created.
- A two-octet number denoting the time in days that this key is - A two-octet number denoting the time in days that this key is
valid. If this number is zero, then it does not expire. valid. If this number is zero, then it does not expire.
skipping to change at page 39, line 14 skipping to change at page 39, line 21
- a multiprecision integer (MPI) of RSA public modulus n; - a multiprecision integer (MPI) of RSA public modulus n;
- an MPI of RSA public encryption exponent e. - an MPI of RSA public encryption exponent e.
V3 keys are deprecated. They contain three weaknesses in them. V3 keys are deprecated. They contain three weaknesses in them.
First, it is relatively easy to construct a V3 key that has the same First, it is relatively easy to construct a V3 key that has the same
key ID as any other key because the key ID is simply the low 64 bits key ID as any other key because the key ID is simply the low 64 bits
of the public modulus. Secondly, because the fingerprint of a V3 key of the public modulus. Secondly, because the fingerprint of a V3 key
hashes the key material, but not its length, there is an increased hashes the key material, but not its length, there is an increased
opportunity for fingerprint collisions. Third, there are minor opportunity for fingerprint collisions. Third, there are weaknesses
weaknesses in the MD5 hash algorithm that make developers prefer in the MD5 hash algorithm that make developers prefer other
other algorithms. See below for a fuller discussion of key IDs and algorithms. See below for a fuller discussion of key IDs and
fingerprints. fingerprints.
V2 keys are identical to the deprecated V3 keys except for the V2 keys are identical to the deprecated V3 keys except for the
version number. An implementation MUST NOT generate them and may version number. An implementation MUST NOT generate them and MAY
accept or reject them as it sees fit. accept or reject them as it sees fit.
The version 4 format is similar to the version 3 format except for The version 4 format is similar to the version 3 format except for
the absence of a validity period. This has been moved to the the absence of a validity period. This has been moved to the
signature packet. In addition, fingerprints of version 4 keys are signature packet. In addition, fingerprints of version 4 keys are
calculated differently from version 3 keys, as described in section calculated differently from version 3 keys, as described in section
"Enhanced Key Formats." "Enhanced Key Formats."
A version 4 packet contains: A version 4 packet contains:
skipping to change at page 41, line 50 skipping to change at page 42, line 5
encrypted in CFB mode, including the MPI bitcount prefix. encrypted in CFB mode, including the MPI bitcount prefix.
The two-octet checksum that follows the algorithm-specific portion The two-octet checksum that follows the algorithm-specific portion
is the algebraic sum, mod 65536, of the plaintext of all the is the algebraic sum, mod 65536, of the plaintext of all the
algorithm-specific octets (including MPI prefix and data). With V3 algorithm-specific octets (including MPI prefix and data). With V3
keys, the checksum is stored in the clear. With V4 keys, the keys, the checksum is stored in the clear. With V4 keys, the
checksum is encrypted like the algorithm-specific data. This value checksum is encrypted like the algorithm-specific data. This value
is used to check that the passphrase was correct. However, this is used to check that the passphrase was correct. However, this
checksum is deprecated; an implementation SHOULD NOT use it, but checksum is deprecated; an implementation SHOULD NOT use it, but
should rather use the SHA-1 hash denoted with a usage octet of 254. should rather use the SHA-1 hash denoted with a usage octet of 254.
The reason for this is that there are some attacks on the private The reason for this is that there are some attacks that involve
key that can undetectably modify the secret key. Using a SHA-1 hash undetectably modifying the secret key.
prevents this.
5.6. Compressed Data Packet (Tag 8) 5.6. Compressed Data Packet (Tag 8)
The Compressed Data packet contains compressed data. Typically, this The Compressed Data packet contains compressed data. Typically, this
packet is found as the contents of an encrypted packet, or following packet is found as the contents of an encrypted packet, or following
a Signature or One-Pass Signature packet, and contains a literal a Signature or One-Pass Signature packet, and contains a literal
data packet. data packet.
The body of this packet consists of: The body of this packet consists of:
skipping to change at page 42, line 26 skipping to change at page 42, line 33
how messages are formed. how messages are formed.
ZIP-compressed packets are compressed with raw RFC 1951 DEFLATE ZIP-compressed packets are compressed with raw RFC 1951 DEFLATE
blocks. Note that PGP V2.6 uses 13 bits of compression. If an blocks. Note that PGP V2.6 uses 13 bits of compression. If an
implementation uses more bits of compression, PGP V2.6 cannot implementation uses more bits of compression, PGP V2.6 cannot
decompress it. decompress it.
ZLIB-compressed packets are compressed with RFC 1950 ZLIB-style ZLIB-compressed packets are compressed with RFC 1950 ZLIB-style
blocks. blocks.
BZip2-compressed packets are compressed using the BZip2 algorithm.
5.7. Symmetrically Encrypted Data Packet (Tag 9) 5.7. Symmetrically Encrypted Data Packet (Tag 9)
The Symmetrically Encrypted Data packet contains data encrypted with The Symmetrically Encrypted Data packet contains data encrypted with
a symmetric-key algorithm. When it has been decrypted, it contains a symmetric-key algorithm. When it has been decrypted, it contains
other packets (usually a literal data packet or compressed data other packets (usually a literal data packet or compressed data
packet, but in theory other Symmetrically Encrypted Data Packets or packet, but in theory other Symmetrically Encrypted Data Packets or
sequences of packets that form whole OpenPGP messages). sequences of packets that form whole OpenPGP messages).
The body of this packet consists of: The body of this packet consists of:
skipping to change at page 42, line 48 skipping to change at page 43, line 6
The symmetric cipher used may be specified in an Public-Key or The symmetric cipher used may be specified in an Public-Key or
Symmetric-Key Encrypted Session Key packet that precedes the Symmetric-Key Encrypted Session Key packet that precedes the
Symmetrically Encrypted Data Packet. In that case, the cipher Symmetrically Encrypted Data Packet. In that case, the cipher
algorithm octet is prefixed to the session key before it is algorithm octet is prefixed to the session key before it is
encrypted. If no packets of these types precede the encrypted data, encrypted. If no packets of these types precede the encrypted data,
the IDEA algorithm is used with the session key calculated as the the IDEA algorithm is used with the session key calculated as the
MD5 hash of the passphrase, though this use is deprecated. MD5 hash of the passphrase, though this use is deprecated.
The data is encrypted in CFB mode, with a CFB shift size equal to The data is encrypted in CFB mode, with a CFB shift size equal to
the cipher's block size. The Initial Vector (IV) is specified as the cipher's block size. The Initial Vector (IV) is specified as all
all zeros. Instead of using an IV, OpenPGP prefixes a string of zeros. Instead of using an IV, OpenPGP prefixes a string of length
length equal to the block size of the cipher plus two to the data equal to the block size of the cipher plus two to the data before it
before it is encrypted. The first block-size octets (for example, 8 is encrypted. The first block-size octets (for example, 8 octets for
octets for a 64-bit block length) are random, and the following two a 64-bit block length) are random, and the following two octets are
octets are copies of the last two octets of the IV. For example, in copies of the last two octets of the IV. For example, in an 8 octet
an 8 octet block, octet 9 is a repeat of octet 7, and octet 10 is a block, octet 9 is a repeat of octet 7, and octet 10 is a repeat of
repeat of octet 8. In a cipher of length 16, octet 17 is a repeat of octet 8. In a cipher of length 16, octet 17 is a repeat of octet 15
octet 15 and octet 18 is a repeat of octet 16. As a pedantic and octet 18 is a repeat of octet 16. As a pedantic clarification,
clarification, in both these examples, we consider the first octet in both these examples, we consider the first octet to be numbered
to be numbered 1. 1.
After encrypting the first block-size-plus-two octets, the CFB state After encrypting the first block-size-plus-two octets, the CFB state
is resynchronized. The last block-size octets of ciphertext are is resynchronized. The last block-size octets of ciphertext are
passed through the cipher and the block boundary is reset. passed through the cipher and the block boundary is reset.
The repetition of 16 bits in the random data prefixed to the message The repetition of 16 bits in the random data prefixed to the message
allows the receiver to immediately check whether the session key is allows the receiver to immediately check whether the session key is
incorrect. See the Security Considerations section for hints on the incorrect. See the Security Considerations section for hints on the
proper use of this "quick check." proper use of this "quick check."
skipping to change at page 43, line 28 skipping to change at page 43, line 38
An experimental version of PGP used this packet as the Literal An experimental version of PGP used this packet as the Literal
packet, but no released version of PGP generated Literal packets packet, but no released version of PGP generated Literal packets
with this tag. With PGP 5.x, this packet has been re-assigned and is with this tag. With PGP 5.x, this packet has been re-assigned and is
reserved for use as the Marker packet. reserved for use as the Marker packet.
The body of this packet consists of: The body of this packet consists of:
- The three octets 0x50, 0x47, 0x50 (which spell "PGP" in UTF-8). - The three octets 0x50, 0x47, 0x50 (which spell "PGP" in UTF-8).
Such a packet MUST be ignored when received. It may be placed at Such a packet MUST be ignored when received. It may be placed at the
the beginning of a message that uses features not available in PGP beginning of a message that uses features not available in PGP 2.6.x
2.6.x in order to cause that version to report that newer software in order to cause that version to report that newer software is
is necessary to process the message. necessary to process the message.
5.9. Literal Data Packet (Tag 11) 5.9. Literal Data Packet (Tag 11)
A Literal Data packet contains the body of a message; data that is A Literal Data packet contains the body of a message; data that is
not to be further interpreted. not to be further interpreted.
The body of this packet consists of: The body of this packet consists of:
- A one-octet field that describes how the data is formatted. - A one-octet field that describes how the data is formatted.
skipping to change at page 44, line 42 skipping to change at page 44, line 51
implementation. implementation.
Trust packets SHOULD NOT be emitted to output streams that are Trust packets SHOULD NOT be emitted to output streams that are
transferred to other users, and they SHOULD be ignored on any input transferred to other users, and they SHOULD be ignored on any input
other than local keyring files. other than local keyring files.
5.11. User ID Packet (Tag 13) 5.11. User ID Packet (Tag 13)
A User ID packet consists of UTF-8 text that is intended to A User ID packet consists of UTF-8 text that is intended to
represent the name and email address of the key holder. By represent the name and email address of the key holder. By
convention, it includes an RFC 2822 mail name, but there are no convention, it includes an RFC 2822 mail name-addr, but there are no
restrictions on its content. The packet length in the header restrictions on its content. The packet length in the header
specifies the length of the User ID. specifies the length of the User ID.
5.12. User Attribute Packet (Tag 17) 5.12. User Attribute Packet (Tag 17)
The User Attribute packet is a variation of the User ID packet. It The User Attribute packet is a variation of the User ID packet. It
is capable of storing more types of data than the User ID packet is capable of storing more types of data than the User ID packet
which is limited to text. Like the User ID packet, a User Attribute which is limited to text. Like the User ID packet, a User Attribute
packet may be certified by the key owner ("self-signed") or any packet may be certified by the key owner ("self-signed") or any
other key owner who cares to certify it. Except as noted, a User other key owner who cares to certify it. Except as noted, a User
skipping to change at page 45, line 32 skipping to change at page 45, line 42
The only currently defined subpacket type is 1, signifying an image. The only currently defined subpacket type is 1, signifying an image.
An implementation SHOULD ignore any subpacket of a type that it does An implementation SHOULD ignore any subpacket of a type that it does
not recognize. Subpacket types 100 through 110 are reserved for not recognize. Subpacket types 100 through 110 are reserved for
private or experimental use. private or experimental use.
5.12.1. The Image Attribute Subpacket 5.12.1. The Image Attribute Subpacket
The image attribute subpacket is used to encode an image, presumably The image attribute subpacket is used to encode an image, presumably
(but not required to be) that of the key owner. (but not required to be) that of the key owner.
The image attribute subpacket begins with an image header. The The image attribute subpacket begins with an image header. The first
first two octets of the image header contain the length of the image two octets of the image header contain the length of the image
header. Note that unlike other multi-octet numerical values in this header. Note that unlike other multi-octet numerical values in this
document, due to an historical accident this value is encoded as a document, due to an historical accident this value is encoded as a
little-endian number. The image header length is followed by a little-endian number. The image header length is followed by a
single octet for the image header version. The only currently single octet for the image header version. The only currently
defined version of the image header is 1, which is a 16 octet image defined version of the image header is 1, which is a 16 octet image
header. The first three octets of a version 1 image header are thus header. The first three octets of a version 1 image header are thus
0x10 0x00 0x01. 0x10 0x00 0x01.
The fourth octet of a version 1 image header designates the encoding The fourth octet of a version 1 image header designates the encoding
format of the image. The only currently defined encoding format is format of the image. The only currently defined encoding format is
the value 1 to indicate JPEG. Image format types 100 through 110 the value 1 to indicate JPEG. Image format types 100 through 110 are
are reserved for private or experimental use. The rest of the reserved for private or experimental use. The rest of the version 1
version 1 image header is made up of 12 reserved octets, all of image header is made up of 12 reserved octets, all of which MUST be
which MUST be set to 0. set to 0.
The rest of the image subpacket contains the image itself. As the The rest of the image subpacket contains the image itself. As the
only currently defined image type is JPEG, the image is encoded in only currently defined image type is JPEG, the image is encoded in
the JPEG File Interchange Format (JFIF), a standard file format for the JPEG File Interchange Format (JFIF), a standard file format for
JPEG images. [JFIF] JPEG images. [JFIF]
An implementation MAY try and determine the type of an image by An implementation MAY try and determine the type of an image by
examination of the image data if it is unable to handle a particular examination of the image data if it is unable to handle a particular
version of the image header or if a specified encoding format value version of the image header or if a specified encoding format value
is not recognized. is not recognized.
skipping to change at page 46, line 34 skipping to change at page 46, line 44
For example, an implementation might infer from the use of a cipher For example, an implementation might infer from the use of a cipher
such as AES or Twofish that a user supports this feature. It might such as AES or Twofish that a user supports this feature. It might
place in the unhashed portion of another user's key signature a place in the unhashed portion of another user's key signature a
features subpacket. It might also present a user with an opportunity features subpacket. It might also present a user with an opportunity
to regenerate their own self-signature with a features subpacket. to regenerate their own self-signature with a features subpacket.
This packet contains data encrypted with a symmetric-key algorithm This packet contains data encrypted with a symmetric-key algorithm
and protected against modification by the SHA-1 hash algorithm. When and protected against modification by the SHA-1 hash algorithm. When
it has been decrypted, it will typically contain other packets it has been decrypted, it will typically contain other packets
(often literal data packets or compressed data packets). The last (often a literal data packet or compressed data packet). The last
decrypted packet in this packet's payload MUST be a Modification decrypted packet in this packet's payload MUST be a Modification
Detection Code packet. Detection Code packet.
The body of this packet consists of: The body of this packet consists of:
- A one-octet version number. The only currently defined value is - A one-octet version number. The only currently defined value is
1. 1.
- Encrypted data, the output of the selected symmetric-key cipher - Encrypted data, the output of the selected symmetric-key cipher
operating in Cipher Feedback mode with shift amount equal to the operating in Cipher Feedback mode with shift amount equal to the
block size of the cipher (CFB-n where n is the block size). block size of the cipher (CFB-n where n is the block size).
The symmetric cipher used MUST be specified in a Public-Key or The symmetric cipher used MUST be specified in a Public-Key or
Symmetric-Key Encrypted Session Key packet that precedes the Symmetric-Key Encrypted Session Key packet that precedes the
Symmetrically Encrypted Data Packet. In either case, the cipher Symmetrically Encrypted Data Packet. In either case, the cipher
algorithm octet is prefixed to the session key before it is algorithm octet is prefixed to the session key before it is
encrypted. encrypted.
The data is encrypted in CFB mode, with a CFB shift size equal to The data is encrypted in CFB mode, with a CFB shift size equal to
the cipher's block size. The Initial Vector (IV) is specified as the cipher's block size. The Initial Vector (IV) is specified as all
all zeros. Instead of using an IV, OpenPGP prefixes an octet string zeros. Instead of using an IV, OpenPGP prefixes an octet string to
to the data before it is encrypted. The length of the octet string the data before it is encrypted. The length of the octet string
equals the block size of the cipher in octets, plus two. The first equals the block size of the cipher in octets, plus two. The first
octets in the group, of length equal to the block size of the octets in the group, of length equal to the block size of the
cipher, are random; the last two octets are each copies of their 2nd cipher, are random; the last two octets are each copies of their 2nd
preceding octet. For example, with a cipher whose block size is 128 preceding octet. For example, with a cipher whose block size is 128
bits or 16 octets, the prefix data will contain 16 random octets, bits or 16 octets, the prefix data will contain 16 random octets,
then two more octets, which are copies of the 15th and 16th octets, then two more octets, which are copies of the 15th and 16th octets,
respectively. Unlike the Symmetrically Encrypted Data Packet, no respectively. Unlike the Symmetrically Encrypted Data Packet, no
special CFB resynchronization is done after encrypting this prefix special CFB resynchronization is done after encrypting this prefix
data. See OpenPGP CFB Mode below for more details. data. See OpenPGP CFB Mode below for more details.
The repetition of 16 bits in the random data prefixed to the message The repetition of 16 bits in the random data prefixed to the message
allows the receiver to immediately check whether the session key is allows the receiver to immediately check whether the session key is
incorrect. incorrect.
The plaintext of the data to be encrypted is passed through the The plaintext of the data to be encrypted is passed through the
SHA-1 hash function, and the result of the hash is appended to the SHA-1 hash function, and the result of the hash is appended to the
plaintext in a Modification Detection Code packet. The input to the plaintext in a Modification Detection Code packet. The input to the
hash function includes the prefix data described above; it includes hash function includes the prefix data described above; it includes
all of the plaintext, and then also includes two octets of values all of the plaintext, and then also includes two octets of values
0xD3, 0x14. These represent the encoding of a Modification 0xD3, 0x14. These represent the encoding of a Modification Detection
Detection Code packet tag and length field of 20 octets. Code packet tag and length field of 20 octets.
The resulting hash value is stored in a Modification Detection Code The resulting hash value is stored in a Modification Detection Code
packet which MUST use the two octet encoding just given to represent packet which MUST use the two octet encoding just given to represent
its tag and length field. The body of the MDC packet is the 20 its tag and length field. The body of the MDC packet is the 20 octet
octet output of the SHA-1 hash. output of the SHA-1 hash.
The Modification Detection Code packet is appended to the plaintext The Modification Detection Code packet is appended to the plaintext
and encrypted along with the plaintext using the same CFB context. and encrypted along with the plaintext using the same CFB context.
During decryption, the plaintext data should be hashed with SHA-1, During decryption, the plaintext data should be hashed with SHA-1,
including the prefix data as well as the packet tag and length field including the prefix data as well as the packet tag and length field
of the Modification Detection Code packet. The body of the MDC of the Modification Detection Code packet. The body of the MDC
packet, upon decryption, is compared with the result of the SHA-1 packet, upon decryption, is compared with the result of the SHA-1
hash. hash.
skipping to change at page 48, line 46 skipping to change at page 48, line 56
structures. The OpenPGP standard specifies one such printable structures. The OpenPGP standard specifies one such printable
encoding scheme to ensure interoperability. encoding scheme to ensure interoperability.
OpenPGP's Radix-64 encoding is composed of two parts: a base64 OpenPGP's Radix-64 encoding is composed of two parts: a base64
encoding of the binary data, and a checksum. The base64 encoding is encoding of the binary data, and a checksum. The base64 encoding is
identical to the MIME base64 content-transfer-encoding [RFC2045]. identical to the MIME base64 content-transfer-encoding [RFC2045].
The checksum is a 24-bit CRC converted to four characters of The checksum is a 24-bit CRC converted to four characters of
radix-64 encoding by the same MIME base64 transformation, preceded radix-64 encoding by the same MIME base64 transformation, preceded
by an equals sign (=). The CRC is computed by using the generator by an equals sign (=). The CRC is computed by using the generator
0x864CFB and an initialization of 0xB704CE. The accumulation is 0x864CFB and an initialization of 0xB704CE. The accumulation is done
done on the data before it is converted to radix-64, rather than on on the data before it is converted to radix-64, rather than on the
the converted data. A sample implementation of this algorithm is in converted data. A sample implementation of this algorithm is in the
the next section. next section.
The checksum with its leading equal sign MAY appear on the first The checksum with its leading equal sign MAY appear on the first
line after the Base64 encoded data. line after the Base64 encoded data.
Rationale for CRC-24: The size of 24 bits fits evenly into printable Rationale for CRC-24: The size of 24 bits fits evenly into printable
base64. The nonzero initialization can detect more errors than a base64. The nonzero initialization can detect more errors than a
zero initialization. zero initialization.
6.1. An Implementation of the CRC-24 in "C" 6.1. An Implementation of the CRC-24 in "C"
skipping to change at page 49, line 48 skipping to change at page 50, line 4
Concatenating the following data creates ASCII Armor: Concatenating the following data creates ASCII Armor:
- An Armor Header Line, appropriate for the type of data - An Armor Header Line, appropriate for the type of data
- Armor Headers - Armor Headers
- A blank (zero-length, or containing only whitespace) line - A blank (zero-length, or containing only whitespace) line
- The ASCII-Armored data - The ASCII-Armored data
- An Armor Checksum - An Armor Checksum
- The Armor Tail, which depends on the Armor Header Line. - The Armor Tail, which depends on the Armor Header Line.
An Armor Header Line consists of the appropriate header line text An Armor Header Line consists of the appropriate header line text
surrounded by five (5) dashes ('-', 0x2D) on either side of the surrounded by five (5) dashes ('-', 0x2D) on either side of the
header line text. The header line text is chosen based upon the header line text. The header line text is chosen based upon the type
type of data that is being encoded in Armor, and how it is being of data that is being encoded in Armor, and how it is being encoded.
encoded. Header line texts include the following strings: Header line texts include the following strings:
BEGIN PGP MESSAGE BEGIN PGP MESSAGE
Used for signed, encrypted, or compressed files. Used for signed, encrypted, or compressed files.
BEGIN PGP PUBLIC KEY BLOCK BEGIN PGP PUBLIC KEY BLOCK
Used for armoring public keys Used for armoring public keys
BEGIN PGP PRIVATE KEY BLOCK BEGIN PGP PRIVATE KEY BLOCK
Used for armoring private keys Used for armoring private keys
skipping to change at page 50, line 33 skipping to change at page 50, line 41
BEGIN PGP SIGNATURE BEGIN PGP SIGNATURE
Used for detached signatures, OpenPGP/MIME signatures, and Used for detached signatures, OpenPGP/MIME signatures, and
cleartext signatures. Note that PGP 2.x uses BEGIN PGP MESSAGE cleartext signatures. Note that PGP 2.x uses BEGIN PGP MESSAGE
for detached signatures. for detached signatures.
Note that all these Armor Header Lines are to consist of a complete Note that all these Armor Header Lines are to consist of a complete
line. That is to say, there is always a line ending preceding the line. That is to say, there is always a line ending preceding the
starting five dashes, and following the ending five dashes. The starting five dashes, and following the ending five dashes. The
header lines, therefore, MUST start at the beginning of a line, and header lines, therefore, MUST start at the beginning of a line, and
MUST NOT have text following them on the same line. These line MUST NOT have text other than whitespace following them on the same
endings are considered a part of the Armor Header Line for the line. These line endings are considered a part of the Armor Header
purposes of determining the content they delimit. This is Line for the purposes of determining the content they delimit. This
particularly important when computing a cleartext signature (see is particularly important when computing a cleartext signature (see
below). below).
The Armor Headers are pairs of strings that can give the user or the The Armor Headers are pairs of strings that can give the user or the
receiving OpenPGP implementation some information about how to receiving OpenPGP implementation some information about how to
decode or use the message. The Armor Headers are a part of the decode or use the message. The Armor Headers are a part of the
armor, not a part of the message, and hence are not protected by any armor, not a part of the message, and hence are not protected by any
signatures applied to the message. signatures applied to the message.
The format of an Armor Header is that of a key-value pair. A colon The format of an Armor Header is that of a key-value pair. A colon
(':' 0x38) and a single space (0x20) separate the key and value. (':' 0x38) and a single space (0x20) separate the key and value.
OpenPGP should consider improperly formatted Armor Headers to be OpenPGP should consider improperly formatted Armor Headers to be
corruption of the ASCII Armor. Unknown keys should be reported to corruption of the ASCII Armor. Unknown keys should be reported to
the user, but OpenPGP should continue to process the message. the user, but OpenPGP should continue to process the message.
Note that some transport methods are sensitive to line length. While
there is a limit of 76 characters for the Radix-64 data (section
6.3), there is no limit to the length of Armor Headers. Care should
be taken that the Armor Headers are short enough to survive
transport. One way to do this is to repeat an Armor Header key
multiple times with different values for each so that no one line is
overly long.
Currently defined Armor Header Keys are: Currently defined Armor Header Keys are:
- "Version", that states the OpenPGP implementation and version - "Version", that states the OpenPGP implementation and version
used to encode the message. used to encode the message.
- "Comment", a user-defined comment. OpenPGP defines all text to - "Comment", a user-defined comment. OpenPGP defines all text to
be in UTF-8. A comment may be any UTF-8 string. However, the be in UTF-8. A comment may be any UTF-8 string. However, the
whole point of armoring is to provide seven-bit-clean data. whole point of armoring is to provide seven-bit-clean data.
Consequently, if a comment has characters that are outside the Consequently, if a comment has characters that are outside the
US-ASCII range of UTF, they may very well not survive transport. US-ASCII range of UTF, they may very well not survive transport.
- "MessageID", a 32-character string of printable characters. The - "MessageID", a 32-character string of printable characters. The
string must be the same for all parts of a multi-part message string must be the same for all parts of a multi-part message
that uses the "PART X" Armor Header. MessageID strings should that uses the "PART X" Armor Header. MessageID strings should be
be unique enough that the recipient of the mail can associate unique enough that the recipient of the mail can associate all
all the parts of a message with each other. A good checksum or the parts of a message with each other. A good checksum or
cryptographic hash function is sufficient. cryptographic hash function is sufficient.
The MessageID SHOULD NOT appear unless it is in a multi-part The MessageID SHOULD NOT appear unless it is in a multi-part
message. If it appears at all, it MUST be computed from the message. If it appears at all, it MUST be computed from the
finished (encrypted, signed, etc.) message in a deterministic finished (encrypted, signed, etc.) message in a deterministic
fashion, rather than contain a purely random value. This is to fashion, rather than contain a purely random value. This is to
allow the legitimate recipient to determine that the MessageID allow the legitimate recipient to determine that the MessageID
cannot serve as a covert means of leaking cryptographic key cannot serve as a covert means of leaking cryptographic key
information. information.
skipping to change at page 52, line 55 skipping to change at page 53, line 20
has two zero-value bits added to it, and is processed as above. has two zero-value bits added to it, and is processed as above.
A pad character (=) is added to the output. A pad character (=) is added to the output.
3. The last data group has 8 bits (1 octet). The first 6-bit group 3. The last data group has 8 bits (1 octet). The first 6-bit group
is processed as above. The second (incomplete) data group has is processed as above. The second (incomplete) data group has
four zero-value bits added to it, and is processed as above. Two four zero-value bits added to it, and is processed as above. Two
pad characters (=) are added to the output. pad characters (=) are added to the output.
6.4. Decoding Radix-64 6.4. Decoding Radix-64
Any characters outside of the base64 alphabet are ignored in
Radix-64 data. Decoding software must ignore all line breaks or
other characters not found in the table above.
In Radix-64 data, characters other than those in the table, line In Radix-64 data, characters other than those in the table, line
breaks, and other white space probably indicate a transmission breaks, and other white space probably indicate a transmission
error, about which a warning message or even a message rejection error, about which a warning message or even a message rejection
might be appropriate under some circumstances. might be appropriate under some circumstances. Decoding software
must ignore all white space.
Because it is used only for padding at the end of the data, the Because it is used only for padding at the end of the data, the
occurrence of any "=" characters may be taken as evidence that the occurrence of any "=" characters may be taken as evidence that the
end of the data has been reached (without truncation in transit). No end of the data has been reached (without truncation in transit). No
such assurance is possible, however, when the number of octets such assurance is possible, however, when the number of octets
transmitted was a multiple of three and no "=" characters are transmitted was a multiple of three and no "=" characters are
present. present.
6.5. Examples of Radix-64 6.5. Examples of Radix-64
skipping to change at page 54, line 4 skipping to change at page 54, line 18
6.6. Example of an ASCII Armored Message 6.6. Example of an ASCII Armored Message
-----BEGIN PGP MESSAGE----- -----BEGIN PGP MESSAGE-----
Version: OpenPrivacy 0.99 Version: OpenPrivacy 0.99
yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS
vBSFjNSiVHsuAA== vBSFjNSiVHsuAA==
=njUN =njUN
-----END PGP MESSAGE----- -----END PGP MESSAGE-----
Note that this example is indented by two spaces.
Note that this example has extra indenting; an actual armored
message would have no leading whitespace.
7. Cleartext signature framework 7. Cleartext signature framework
It is desirable to sign a textual octet stream without ASCII It is desirable to sign a textual octet stream without ASCII
armoring the stream itself, so the signed text is still readable armoring the stream itself, so the signed text is still readable
without special software. In order to bind a signature to such a without special software. In order to bind a signature to such a
cleartext, this framework is used. (Note that RFC 3156 defines cleartext, this framework is used. (Note that this framework is not
another way to sign cleartext messages for environments that support intended to be reversible. RFC 3156 defines another way to sign
MIME.) cleartext messages for environments that support MIME.)
The cleartext signed message consists of: The cleartext signed message consists of:
- The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a - The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a
single line, single line,
- One or more "Hash" Armor Headers, - One or more "Hash" Armor Headers,
- Exactly one empty line not included into the message digest, - Exactly one empty line not included into the message digest,
skipping to change at page 54, line 41 skipping to change at page 55, line 8
algorithm(s) are used for the signature. If there are no such algorithm(s) are used for the signature. If there are no such
headers, MD5 is used. If MD5 is the only hash used, then an headers, MD5 is used. If MD5 is the only hash used, then an
implementation MAY omit this header for improved V2.x compatibility. implementation MAY omit this header for improved V2.x compatibility.
If more than one message digest is used in the signature, the "Hash" If more than one message digest is used in the signature, the "Hash"
armor header contains a comma-delimited list of used message armor header contains a comma-delimited list of used message
digests. digests.
Current message digest names are described below with the algorithm Current message digest names are described below with the algorithm
IDs. IDs.
An implementation SHOULD add a line break after the cleartext, but
MAY omit it if the cleartext ends with a line break. This is for
visual clarity.
7.1. Dash-Escaped Text 7.1. Dash-Escaped Text
The cleartext content of the message must also be dash-escaped. The cleartext content of the message must also be dash-escaped.
Dash escaped cleartext is the ordinary cleartext where every line Dash escaped cleartext is the ordinary cleartext where every line
starting with a dash '-' (0x2D) is prefixed by the sequence dash '-' starting with a dash '-' (0x2D) is prefixed by the sequence dash '-'
(0x2D) and space ' ' (0x20). This prevents the parser from (0x2D) and space ' ' (0x20). This prevents the parser from
recognizing armor headers of the cleartext itself. An implementation recognizing armor headers of the cleartext itself. An implementation
MAY dash escape any line, SHOULD dash escape lines commencing "From" MAY dash escape any line, SHOULD dash escape lines commencing "From"
followed by a space, and MUST dash escape any line commencing in a followed by a space, and MUST dash escape any line commencing in a
dash. The message digest is computed using the cleartext itself, not dash. The message digest is computed using the cleartext itself, not
the dash escaped form. the dash escaped form.
As with binary signatures on text documents, a cleartext signature As with binary signatures on text documents, a cleartext signature
is calculated on the text using canonical <CR><LF> line endings. is calculated on the text using canonical <CR><LF> line endings. The
The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP
SIGNATURE-----' line that terminates the signed text is not SIGNATURE-----' line that terminates the signed text is not
considered part of the signed text. considered part of the signed text.
When reversing dash-escaping, an implementation MUST strip the When reversing dash-escaping, an implementation MUST strip the
string "- " if it occurs at the beginning of a line, and SHOULD warn string "- " if it occurs at the beginning of a line, and SHOULD warn
on "-" and any character other than a space at the beginning of a on "-" and any character other than a space at the beginning of a
line. line.
Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at
the end of any line is removed when the cleartext signature is the end of any line is removed when the cleartext signature is
skipping to change at page 57, line 33 skipping to change at page 57, line 51
1 - MD5 "MD5" 1 - MD5 "MD5"
2 - SHA-1 [FIPS180] "SHA1" 2 - SHA-1 [FIPS180] "SHA1"
3 - RIPE-MD/160 "RIPEMD160" 3 - RIPE-MD/160 "RIPEMD160"
4 - Reserved 4 - Reserved
5 - Reserved 5 - Reserved
6 - Reserved 6 - Reserved
7 - Reserved 7 - Reserved
8 - SHA256 [FIPS180] "SHA256" 8 - SHA256 [FIPS180] "SHA256"
9 - SHA384 [FIPS180] "SHA384" 9 - SHA384 [FIPS180] "SHA384"
10 - SHA512 [FIPS180] "SHA512" 10 - SHA512 [FIPS180] "SHA512"
11 - SHA224 [FIPS180] "SHA224"
100 to 110 - Private/Experimental algorithm. 100 to 110 - Private/Experimental algorithm.
Implementations MUST implement SHA-1. Implementations MAY implement Implementations MUST implement SHA-1. Implementations MAY implement
other algorithms. other algorithms. MD5 is deprecated.
10. Packet Composition 10. Packet Composition
OpenPGP packets are assembled into sequences in order to create OpenPGP packets are assembled into sequences in order to create
messages and to transfer keys. Not all possible packet sequences messages and to transfer keys. Not all possible packet sequences are
are meaningful and correct. This section describes the rules for meaningful and correct. This section describes the rules for how
how packets should be placed into sequences. packets should be placed into sequences.
10.1. Transferable Public Keys 10.1. Transferable Public Keys
OpenPGP users may transfer public keys. The essential elements of a OpenPGP users may transfer public keys. The essential elements of a
transferable public key are: transferable public key are:
- One Public Key packet - One Public Key packet
- Zero or more revocation signatures - Zero or more revocation signatures
skipping to change at page 58, line 42 skipping to change at page 59, line 11
Within the same section as the User ID packets, there are zero or Within the same section as the User ID packets, there are zero or
more User Attribute packets. Like the User ID packets, a User more User Attribute packets. Like the User ID packets, a User
Attribute packet is followed by zero or more signature packets Attribute packet is followed by zero or more signature packets
calculated on the immediately preceding User Attribute packet and calculated on the immediately preceding User Attribute packet and
the initial Public Key packet. the initial Public Key packet.
User Attribute packets and User ID packets may be freely intermixed User Attribute packets and User ID packets may be freely intermixed
in this section, so long as the signatures that follow them are in this section, so long as the signatures that follow them are
maintained on the proper User Attribute or User ID packet. maintained on the proper User Attribute or User ID packet.
After the User ID or Attribute packets there may be one or more After the User ID or Attribute packets there may be zero or more
Subkey packets. In general, subkeys are provided in cases where the Subkey packets. In general, subkeys are provided in cases where the
top-level public key is a signature-only key. However, any V4 key top-level public key is a signature-only key. However, any V4 key
may have subkeys, and the subkeys may be encryption-only keys, may have subkeys, and the subkeys may be encryption-only keys,
signature-only keys, or general-purpose keys. V3 keys MUST NOT have signature-only keys, or general-purpose keys. V3 keys MUST NOT have
subkeys. subkeys.
Each Subkey packet must be followed by one Signature packet, which Each Subkey packet MUST be followed by one Signature packet, which
should be a subkey binding signature issued by the top level key. should be a subkey binding signature issued by the top level key.
For subkeys that can issue signatures, the subkey binding signature For subkeys that can issue signatures, the subkey binding signature
must contain an embedded signature subpacket with a primary key MUST contain an embedded signature subpacket with a primary key
binding signature (0x19) issued by the subkey on the top level key. binding signature (0x19) issued by the subkey on the top level key.
Subkey and Key packets may each be followed by a revocation Subkey and Key packets may each be followed by a revocation
Signature packet to indicate that the key is revoked. Revocation Signature packet to indicate that the key is revoked. Revocation
signatures are only accepted if they are issued by the key itself, signatures are only accepted if they are issued by the key itself,
or by a key that is authorized to issue revocations via a revocation or by a key that is authorized to issue revocations via a revocation
key subpacket in a self-signature by the top level key. key subpacket in a self-signature by the top level key.
Transferable public key packet sequences may be concatenated to Transferable public key packet sequences may be concatenated to
allow transferring multiple public keys in one operation. allow transferring multiple public keys in one operation.
10.2. OpenPGP Messages 10.2. Transferable Secret Keys
OpenPGP users may transfer secret keys. The format of a transferable
secret key is the same as a transferable public key except that
secret key and secret subkey packets are used instead of the public
key and public subkey packets. Implementations SHOULD include
self-signatures on any user IDs and subkeys, as this allows for a
complete public key to be automatically extracted from the
transferable secret key. Implementations MAY choose to omit the
self-signatures, especially if a transferable public key accompanies
the transferable secret key.
10.3. OpenPGP Messages
An OpenPGP message is a packet or sequence of packets that An OpenPGP message is a packet or sequence of packets that
corresponds to the following grammatical rules (comma represents corresponds to the following grammatical rules (comma represents
sequential composition, and vertical bar separates alternatives): sequential composition, and vertical bar separates alternatives):
OpenPGP Message :- Encrypted Message | Signed Message | OpenPGP Message :- Encrypted Message | Signed Message |
Compressed Message | Literal Message. Compressed Message | Literal Message.
Compressed Message :- Compressed Data Packet. Compressed Message :- Compressed Data Packet.
skipping to change at page 59, line 49 skipping to change at page 60, line 31
Signed Message :- Signature Packet, OpenPGP Message | Signed Message :- Signature Packet, OpenPGP Message |
One-Pass Signed Message. One-Pass Signed Message.
In addition, decrypting a Symmetrically Encrypted Data Packet or a In addition, decrypting a Symmetrically Encrypted Data Packet or a
Symmetrically Encrypted Integrity Protected Data Packet as well as Symmetrically Encrypted Integrity Protected Data Packet as well as
decompressing a Compressed Data packet must yield a valid OpenPGP decompressing a Compressed Data packet must yield a valid OpenPGP
Message. Message.
10.3. Detached Signatures 10.4. Detached Signatures
Some OpenPGP applications use so-called "detached signatures." For Some OpenPGP applications use so-called "detached signatures." For
example, a program bundle may contain a file, and with it a second example, a program bundle may contain a file, and with it a second
file that is a detached signature of the first file. These detached file that is a detached signature of the first file. These detached
signatures are simply a signature packet stored separately from the signatures are simply a signature packet stored separately from the
data that they are a signature of. data that they are a signature of.
11. Enhanced Key Formats 11. Enhanced Key Formats
11.1. Key Structures 11.1. Key Structures
skipping to change at page 60, line 36 skipping to change at page 61, line 19
Primary-Key Primary-Key
[Revocation Self Signature] [Revocation Self Signature]
[Direct Key Signature...] [Direct Key Signature...]
User ID [Signature ...] User ID [Signature ...]
[User ID [Signature ...] ...] [User ID [Signature ...] ...]
[User Attribute [Signature ...] ...] [User Attribute [Signature ...] ...]
[[Subkey [Binding-Signature-Revocation] [[Subkey [Binding-Signature-Revocation]
Primary-Key-Binding-Signature] ...] Primary-Key-Binding-Signature] ...]
A subkey always has a single signature after it that is issued using A subkey always has a single signature after it that is issued using
the primary key to tie the two keys together. This binding the primary key to tie the two keys together. This binding signature
signature may be in either V3 or V4 format, but SHOULD be V4. may be in either V3 or V4 format, but SHOULD be V4. Subkeys that can
issue signatures MUST have a V4 binding signature due to the
REQUIRED embedded primary key binding signature.
In the above diagram, if the binding signature of a subkey has been In the above diagram, if the binding signature of a subkey has been
revoked, the revoked key may be removed, leaving only one key. revoked, the revoked key may be removed, leaving only one key.
In a V4 key, the primary key MUST be a key capable of certification. In a V4 key, the primary key MUST be a key capable of certification.
The subkeys may be keys of any other type. There may be other The subkeys may be keys of any other type. There may be other
constructions of V4 keys, too. For example, there may be a constructions of V4 keys, too. For example, there may be a
single-key RSA key in V4 format, a DSA primary key with an RSA single-key RSA key in V4 format, a DSA primary key with an RSA
encryption key, or RSA primary key with an Elgamal subkey, etc. encryption key, or RSA primary key with an Elgamal subkey, etc.
skipping to change at page 61, line 12 skipping to change at page 61, line 50
For a V3 key, the eight-octet key ID consists of the low 64 bits of For a V3 key, the eight-octet key ID consists of the low 64 bits of
the public modulus of the RSA key. the public modulus of the RSA key.
The fingerprint of a V3 key is formed by hashing the body (but not The fingerprint of a V3 key is formed by hashing the body (but not
the two-octet length) of the MPIs that form the key material (public the two-octet length) of the MPIs that form the key material (public
modulus n, followed by exponent e) with MD5. Note that both V3 keys modulus n, followed by exponent e) with MD5. Note that both V3 keys
and MD5 are deprecated. and MD5 are deprecated.
A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99,
followed by the two-octet packet length, followed by the entire followed by the two-octet packet length, followed by the entire
Public Key packet starting with the version field. The key ID is Public Key packet starting with the version field. The key ID is the
the low order 64 bits of the fingerprint. Here are the fields of low order 64 bits of the fingerprint. Here are the fields of the
the hash material, with the example of a DSA key: hash material, with the example of a DSA key:
a.1) 0x99 (1 octet) a.1) 0x99 (1 octet)
a.2) high order length octet of (b)-(f) (1 octet) a.2) high order length octet of (b)-(f) (1 octet)
a.3) low order length octet of (b)-(f) (1 octet) a.3) low order length octet of (b)-(f) (1 octet)
b) version number = 4 (1 octet); b) version number = 4 (1 octet);
c) time stamp of key creation (4 octets); c) time stamp of key creation (4 octets);
d) algorithm (1 octet): 17 = DSA (example); d) algorithm (1 octet): 17 = DSA (example);
skipping to change at page 62, line 4 skipping to change at page 62, line 43
fingerprints. fingerprints.
Finally, the key ID and fingerprint of a subkey are calculated in Finally, the key ID and fingerprint of a subkey are calculated in
the same way as for a primary key, including the 0x99 as the first the same way as for a primary key, including the 0x99 as the first
octet (even though this is not a valid packet ID for a public octet (even though this is not a valid packet ID for a public
subkey). subkey).
12. Notes on Algorithms 12. Notes on Algorithms
12.1. Symmetric Algorithm Preferences 12.1. Symmetric Algorithm Preferences
The symmetric algorithm preference is an ordered list of algorithms The symmetric algorithm preference is an ordered list of algorithms
that the keyholder accepts. Since it is found on a self-signature, that the keyholder accepts. Since it is found on a self-signature,
it is possible that a keyholder may have different preferences. For it is possible that a keyholder may have multiple, different
example, Alice may have TripleDES only specified for preferences. For example, Alice may have TripleDES only specified
"alice@work.com" but CAST5, Blowfish, and TripleDES specified for for "alice@work.com" but CAST5, Blowfish, and TripleDES specified
"alice@home.org". Note that it is also possible for preferences to for "alice@home.org". Note that it is also possible for preferences
be in a subkey's binding signature. to be in a subkey's binding signature.
Since TripleDES is the MUST-implement algorithm, if it is not Since TripleDES is the MUST-implement algorithm, if it is not
explicitly in the list, it is tacitly at the end. However, it is explicitly in the list, it is tacitly at the end. However, it is
good form to place it there explicitly. Note also that if an good form to place it there explicitly. Note also that if an
implementation does not implement the preference, then it is implementation does not implement the preference, then it is
implicitly a TripleDES-only implementation. implicitly a TripleDES-only implementation.
An implementation MUST NOT use a symmetric algorithm that is not in An implementation MUST NOT use a symmetric algorithm that is not in
the recipient's preference list. When encrypting to more than one the recipient's preference list. When encrypting to more than one
recipient, the implementation finds a suitable algorithm by taking recipient, the implementation finds a suitable algorithm by taking
the intersection of the preferences of the recipients. Note that the the intersection of the preferences of the recipients. Note that the
MUST-implement algorithm, TripleDES, ensures that the intersection MUST-implement algorithm, TripleDES, ensures that the intersection
is not null. The implementation may use any mechanism to pick an is not null. The implementation may use any mechanism to pick an
algorithm in the intersection. algorithm in the intersection.
If an implementation can decrypt a message that a keyholder doesn't If an implementation can decrypt a message that a keyholder doesn't
have in their preferences, the implementation SHOULD decrypt the have in their preferences, the implementation SHOULD decrypt the
message anyway, but MUST warn the keyholder that the protocol has message anyway, but MUST warn the keyholder that the protocol has
been violated. (For example, suppose that Alice, above, has software been violated. For example, suppose that Alice, above, has software
that implements all algorithms in this specification. Nonetheless, that implements all algorithms in this specification. Nonetheless,
she prefers subsets for work or home. If she is sent a message she prefers subsets for work or home. If she is sent a message
encrypted with IDEA, which is not in her preferences, the software encrypted with IDEA, which is not in her preferences, the software
warns her that someone sent her an IDEA-encrypted message, but it warns her that someone sent her an IDEA-encrypted message, but it
would ideally decrypt it anyway.) would ideally decrypt it anyway.
12.2. Other Algorithm Preferences 12.2. Other Algorithm Preferences
Other algorithm preferences work similarly to the symmetric Other algorithm preferences work similarly to the symmetric
algorithm preference, in that they specify which algorithms the algorithm preference, in that they specify which algorithms the
keyholder accepts. There are two interesting cases that other keyholder accepts. There are two interesting cases that other
comments need to be made about, though, the compression preferences comments need to be made about, though, the compression preferences
and the hash preferences. and the hash preferences.
12.2.1. Compression Preferences 12.2.1. Compression Preferences
skipping to change at page 63, line 55 skipping to change at page 64, line 42
subpacket in a signature is a much better way to express the same subpacket in a signature is a much better way to express the same
idea, and generalizes it to all algorithms. An implementation SHOULD idea, and generalizes it to all algorithms. An implementation SHOULD
NOT create such a key, but MAY interpret it. NOT create such a key, but MAY interpret it.
An implementation SHOULD NOT implement RSA keys of size less than An implementation SHOULD NOT implement RSA keys of size less than
1024 bits. 1024 bits.
12.5. DSA 12.5. DSA
An implementation SHOULD NOT implement DSA keys of size less than An implementation SHOULD NOT implement DSA keys of size less than
1024 bits. Note that present DSA is limited to a maximum of 1024 bit 1024 bits. It MUST NOT implement a DSA signature with a q size of
keys, which are recommended for long-term use. Also, DSA keys MUST less than 160 bits. DSA keys MUST also be a multiple of 64 bits,
be an even multiple of 64 bits long. and the q size MUST be a multiple of 8 bits. The Digital Signature
Standard (DSS) [FIPS186] specifies that DSA be used in one of the
following ways:
* 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384 or
SHA-512 hash
* 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384 or SHA-512
hash
* 2048-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash
* 3072-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash
The above key and q size pairs were chosen to best balance the
strength of the key with the strength of the hash. Implementations
SHOULD use one of the above key and q size pairs when generating DSA
keys. If DSS compliance is desired, one of the specified SHA hashes
must be used as well. [FIPS186] is the ultimate authority on DSS,
and should be consulted for all questions of DSS compliance.
Note that earlier versions of this standard only allowed a 160-bit q
with no truncation allowed, so earlier implementations may not be
able to handle signatures with a different q size or a truncated
hash.
12.6. Elgamal 12.6. Elgamal
An implementation SHOULD NOT implement Elgamal keys of size less An implementation SHOULD NOT implement Elgamal keys of size less
than 1024 bits. than 1024 bits.
12.7. Reserved Algorithm Numbers 12.7. Reserved Algorithm Numbers
A number of algorithm IDs have been reserved for algorithms that A number of algorithm IDs have been reserved for algorithms that
would be useful to use in an OpenPGP implementation, yet there are would be useful to use in an OpenPGP implementation, yet there are
skipping to change at page 64, line 46 skipping to change at page 66, line 8
In the description below, the value BS is the block size in octets In the description below, the value BS is the block size in octets
of the cipher. Most ciphers have a block size of 8 octets. The AES of the cipher. Most ciphers have a block size of 8 octets. The AES
and Twofish have a block size of 16 octets. Also note that the and Twofish have a block size of 16 octets. Also note that the
description below assumes that the IV and CFB arrays start with an description below assumes that the IV and CFB arrays start with an
index of 1 (unlike the C language, which assumes arrays start with a index of 1 (unlike the C language, which assumes arrays start with a
zero index). zero index).
OpenPGP CFB mode uses an initialization vector (IV) of all zeros, OpenPGP CFB mode uses an initialization vector (IV) of all zeros,
and prefixes the plaintext with BS+2 octets of random data, such and prefixes the plaintext with BS+2 octets of random data, such
that octets BS+1 and BS+2 match octets BS-1 and BS. It does a CFB that octets BS+1 and BS+2 match octets BS-1 and BS. It does a CFB
"resync" after encrypting those BS+2 octets. resynchronization after encrypting those BS+2 octets.
Thus, for an algorithm that has a block size of 8 octets (64 bits), Thus, for an algorithm that has a block size of 8 octets (64 bits),
the IV is 10 octets long and octets 7 and 8 of the IV are the same the IV is 10 octets long and octets 7 and 8 of the IV are the same
as octets 9 and 10. For an algorithm with a block size of 16 octets as octets 9 and 10. For an algorithm with a block size of 16 octets
(128 bits), the IV is 18 octets long, and octets 17 and 18 replicate (128 bits), the IV is 18 octets long, and octets 17 and 18 replicate
octets 15 and 16. Those extra two octets are an easy check for a octets 15 and 16. Those extra two octets are an easy check for a
correct key. correct key.
Step by step, here is the procedure: Step by step, here is the procedure:
skipping to change at page 65, line 25 skipping to change at page 66, line 37
4. FR is loaded with C[1] through C[BS]. 4. FR is loaded with C[1] through C[BS].
5. FR is encrypted to produce FRE, the encryption of the first BS 5. FR is encrypted to produce FRE, the encryption of the first BS
octets of ciphertext. octets of ciphertext.
6. The left two octets of FRE get xored with the next two octets of 6. The left two octets of FRE get xored with the next two octets of
data that were prefixed to the plaintext. This produces C[BS+1] data that were prefixed to the plaintext. This produces C[BS+1]
and C[BS+2], the next two octets of ciphertext. and C[BS+2], the next two octets of ciphertext.
7. (The resync step) FR is loaded with C[3] through C[BS+2]. 7. (The resynchronization step) FR is loaded with C[3] through
C[BS+2].
8. FR is encrypted to produce FRE. 8. FR is encrypted to produce FRE.
9. FRE is xored with the first BS octets of the given plaintext, 9. FRE is xored with the first BS octets of the given plaintext,
now that we have finished encrypting the BS+2 octets of prefixed now that we have finished encrypting the BS+2 octets of prefixed
data. This produces C[BS+3] through C[BS+(BS+2)], the next BS data. This produces C[BS+3] through C[BS+(BS+2)], the next BS
octets of ciphertext. octets of ciphertext.
10. FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18 10. FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18
for an 8-octet block). for an 8-octet block).
skipping to change at page 66, line 13 skipping to change at page 67, line 27
generate these numbers. See RFC 1750. generate these numbers. See RFC 1750.
* The MD5 hash algorithm has been found to have weaknesses, with * The MD5 hash algorithm has been found to have weaknesses, with
collisions found in a number of cases. MD5 is deprecated for use collisions found in a number of cases. MD5 is deprecated for use
in OpenPGP. Implementations MUST NOT generate new signatures in OpenPGP. Implementations MUST NOT generate new signatures
using MD5 as a hash function. They MAY continue to consider old using MD5 as a hash function. They MAY continue to consider old
signatures that used MD5 as valid. signatures that used MD5 as valid.
* SHA384 requires the same work as SHA512. In general, there are * SHA384 requires the same work as SHA512. In general, there are
few reasons to use it -- you need a situation where one needs few reasons to use it -- you need a situation where one needs
more security than SHA256, but do not want to have the 512-bit more security than SHA256, but does not want to have the 512-bit
data length. data length.
* Many security protocol designers think that it is a bad idea to * Many security protocol designers think that it is a bad idea to
use a single key for both privacy (encryption) and integrity use a single key for both privacy (encryption) and integrity
(signatures). In fact, this was one of the motivating forces (signatures). In fact, this was one of the motivating forces
behind the V4 key format with separate signature and encryption behind the V4 key format with separate signature and encryption
keys. If you as an implementer promote dual-use keys, you should keys. If you as an implementer promote dual-use keys, you should
at least be aware of this controversy. at least be aware of this controversy.
* The DSA algorithm will work with any 160-bit hash, but it is * The DSA algorithm will work with any hash, but is sensitive to
sensitive to the quality of the hash algorithm, if the hash the quality of the hash algorithm. Verifiers should be aware
algorithm is broken, it can leak the secret key. The Digital that even if the signer used a strong hash, an attacker could
Signature Standard (DSS) specifies that DSA be used with SHA-1. have modified the signature to use a weak one. Only signatures
RIPEMD-160 is considered by many cryptographers to be as strong. using acceptably strong hash algorithms should be accepted as
An implementation should take care which hash algorithms are valid.
used with DSA, as a weak hash can not only allow a signature to
be forged, but could leak the secret key. * As OpenPGP combines many different asymmetric, symmetric, and
hash algorithms, each with different measures of strength, care
should be taken that the weakest element of an OpenPGP message
is still sufficiently strong for the purpose at hand. While
consensus about the the strength of a given algorithm may
evolve, NIST Special Publication 800-57 [SP800-57] recommends
the following list of equivalent strengths:
Asymmetric | Hash | Symmetric
key size | size | key size
------------+--------+-----------
1024 160 80
2048 224 112
3072 256 128
7680 384 192
15360 512 256
* There is a somewhat-related potential security problem in * There is a somewhat-related potential security problem in
signatures. If an attacker can find a message that hashes to the signatures. If an attacker can find a message that hashes to the
same hash with a different algorithm, a bogus signature same hash with a different algorithm, a bogus signature
structure can be constructed that evaluates correctly. structure can be constructed that evaluates correctly.
For example, suppose Alice DSA signs message M using hash For example, suppose Alice DSA signs message M using hash
algorithm H. Suppose that Mallet finds a message M' that has the algorithm H. Suppose that Mallet finds a message M' that has the
same hash value as M with H'. Mallet can then construct a same hash value as M with H'. Mallet can then construct a
signature block that verifies as Alice's signature of M' with signature block that verifies as Alice's signature of M' with
H'. However, this would also constitute a weakness in either H H'. However, this would also constitute a weakness in either H
or H' or both. Should this ever occur, a revision will have to or H' or both. Should this ever occur, a revision will have to
be made to this document to revise the allowed hash algorithms. be made to this document to revise the allowed hash algorithms.
* If you are building an authentication system, the recipient may * If you are building an authentication system, the recipient may
specify a preferred signing algorithm. However, the signer would specify a preferred signing algorithm. However, the signer would
be foolish to use a weak algorithm simply because the recipient be foolish to use a weak algorithm simply because the recipient
requests it. requests it.
* Some of the encryption algorithms mentioned in this document * Some of the encryption algorithms mentioned in this document
have been analyzed less than others. For example, although have been analyzed less than others. For example, although CAST5
CAST5 is presently considered strong, it has been analyzed less is presently considered strong, it has been analyzed less than
than TripleDES. Other algorithms may have other controversies TripleDES. Other algorithms may have other controversies
surrounding them. surrounding them.
* In late summer 2002, Jallad, Katz, and Schneier published an * In late summer 2002, Jallad, Katz, and Schneier published an
interesting attack on the OpenPGP protocol and some of its interesting attack on the OpenPGP protocol and some of its
implementations [JKS02]. In this attack, the attacker modifies a implementations [JKS02]. In this attack, the attacker modifies a
message and sends it to a user who then returns the erroneously message and sends it to a user who then returns the erroneously
decrypted message to the attacker. The attacker is thus using decrypted message to the attacker. The attacker is thus using
the user as a random oracle, and can often decrypt the message. the user as a random oracle, and can often decrypt the message.
Compressing data can ameliorate this attack. The incorrectly Compressing data can ameliorate this attack. The incorrectly
skipping to change at page 68, line 26 skipping to change at page 69, line 52
public-key encrypted. In this case, the quick check is not public-key encrypted. In this case, the quick check is not
needed as the public key encryption of the session key should needed as the public key encryption of the session key should
guarantee that it is the right session key. In other cases, the guarantee that it is the right session key. In other cases, the
implementation should use the quick check with care. implementation should use the quick check with care.
On the one hand, there is a danger to using it if there is a On the one hand, there is a danger to using it if there is a
random oracle that can leak information to an attacker. In random oracle that can leak information to an attacker. In
plainer language, there is a danger to using the quick check if plainer language, there is a danger to using the quick check if
timing information about the check can be exposed to an timing information about the check can be exposed to an
attacker, particularly via an automated service that allows attacker, particularly via an automated service that allows
rapidly repeated queries rapidly repeated queries.
On the other hand, it is inconvenient to the user to be informed On the other hand, it is inconvenient to the user to be informed
that they typed in the wrong passphrase only after a petabyte of that they typed in the wrong passphrase only after a petabyte of
data is decrypted. There are many cases in cryptographic data is decrypted. There are many cases in cryptographic
engineering where the implementer must use care and wisdom, and engineering where the implementer must use care and wisdom, and
this is one. this is one.
14. Implementation Nits 14. Implementation Nits
This section is a collection of comments to help an implementer, This section is a collection of comments to help an implementer,
skipping to change at page 69, line 22 skipping to change at page 70, line 48
material, but different fingerprints (and thus key IDs). Perhaps material, but different fingerprints (and thus key IDs). Perhaps
the most interesting is an RSA key that has been "upgraded" to the most interesting is an RSA key that has been "upgraded" to
V4 format, but since a V4 fingerprint is constructed by hashing V4 format, but since a V4 fingerprint is constructed by hashing
the key creation time along with other things, two V4 keys the key creation time along with other things, two V4 keys
created at different times, yet with the same key material will created at different times, yet with the same key material will
have different fingerprints. have different fingerprints.
* If an implementation is using zlib to interoperate with PGP 2.x, * If an implementation is using zlib to interoperate with PGP 2.x,
then the "windowBits" parameter should be set to -13. then the "windowBits" parameter should be set to -13.
* PGP 2.6.X and 5.0 do not trim trailing whitespace from a * The 0x19 back signatures were not required for signing subkeys
"canonical text" signature. They only remove it from cleartext until relatively recently. Consquently, there may be keys in the
signatures. These signatures are not OpenPGP compliant -- wild that do not have these back signatures. Implementing
OpenPGP requires trimming the whitespace. If you wish to software may handle these keys as it sees fit.
interoperate with PGP 2.6.X or PGP 5, you may wish to accept
these non-compliant signatures.
15. Authors' Addresses 15. Authors' Addresses
The working group can be contacted via the current chair: The working group can be contacted via the current chair:
Derek Atkins Derek Atkins
IHTFP Consulting, Inc. IHTFP Consulting, Inc.
6 Farragut Ave 6 Farragut Ave
Somerville, MA 02144 USA Somerville, MA 02144 USA
Email: derek@ihtfp.com Email: derek@ihtfp.com
skipping to change at page 70, line 4 skipping to change at page 71, line 26
Lutz Donnerhacke Lutz Donnerhacke
IKS GmbH IKS GmbH
Wildenbruchstr. 15 Wildenbruchstr. 15
07745 Jena, Germany 07745 Jena, Germany
EMail: lutz@iks-jena.de EMail: lutz@iks-jena.de
Hal Finney Hal Finney
Email: hal@finney.org Email: hal@finney.org
David Shaw
Email: dshaw@jabberwocky.com
Rodney Thayer Rodney Thayer
Email: rodney@tillerman.to Email: rodney@tillerman.to
This memo also draws on much previous work from a number of other This memo also draws on much previous work from a number of other
authors who include: Derek Atkins, Charles Breed, Dave Del Torto, authors who include: Derek Atkins, Charles Breed, Dave Del Torto,
Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Raph Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Ben
Levien, Colin Plumb, Will Price, David Shaw, William Stallings, Mark Laurie, Raph Levien, Colin Plumb, Will Price, David Shaw, William
Weaver, and Philip R. Zimmermann. Stallings, Mark Weaver, and Philip R. Zimmermann.
16. References (Normative) 16. References (Normative)
[AES] Advanced Encryption Standards Questions and Answers [AES] Advanced Encryption Standards Questions and Answers
<http://csrc.nist.gov/encryption/aes/round2/ <http://csrc.nist.gov/encryption/aes/round2/
aesfact.html> aesfact.html>
<http://csrc.nist.gov/encryption/aes/round2/ <http://csrc.nist.gov/encryption/aes/round2/
r2algs.html#Rijndael> r2algs.html#Rijndael>
skipping to change at page 70, line 27 skipping to change at page 72, line 4
aesfact.html> aesfact.html>
<http://csrc.nist.gov/encryption/aes/round2/ <http://csrc.nist.gov/encryption/aes/round2/
r2algs.html#Rijndael> r2algs.html#Rijndael>
[BLOWFISH] Schneier, B. "Description of a New Variable-Length [BLOWFISH] Schneier, B. "Description of a New Variable-Length
Key, 64-Bit Block Cipher (Blowfish)" Fast Software Key, 64-Bit Block Cipher (Blowfish)" Fast Software
Encryption, Cambridge Security Workshop Proceedings Encryption, Cambridge Security Workshop Proceedings
(December 1993), Springer-Verlag, 1994, pp191-204 (December 1993), Springer-Verlag, 1994, pp191-204
<http://www.counterpane.com/bfsverlag.html> <http://www.counterpane.com/bfsverlag.html>
[BZ2] J. Seward, jseward@acm.org, "The Bzip2 and libbzip2 [BZ2] J. Seward, jseward@acm.org, "The Bzip2 and libbzip2
home page" home page" <http://www.bzip.org/>
<http://sources.redhat.com/bzip2/>
[ELGAMAL] T. Elgamal, "A Public-Key Cryptosystem and a [ELGAMAL] T. Elgamal, "A Public-Key Cryptosystem and a
Signature Scheme Based on Discrete Logarithms," Signature Scheme Based on Discrete Logarithms,"
IEEE Transactions on Information Theory, v. IT-31, IEEE Transactions on Information Theory, v. IT-31,
n. 4, 1985, pp. 469-472. n. 4, 1985, pp. 469-472.
[FIPS180] Secure Hash Signature Standard (SHS) (FIPS PUB [FIPS180] Secure Hash Signature Standard (SHS) (FIPS PUB
180-2). 180-2).
<http://csrc.nist.gov/publications/fips/ <http://csrc.nist.gov/publications/fips/
fips180-2/fips180-2withchangenotice.pdf> fips180-2/fips180-2withchangenotice.pdf>
[FIPS186] Digital Signature Standard (DSS) (FIPS PUB 186-2). [FIPS186] Digital Signature Standard (DSS) (FIPS PUB 186-2).
<http://csrc.nist.gov/publications/fips/fips186-2/ <http://csrc.nist.gov/publications/fips/fips186-2/
fips186-2-change1.pdf> fips186-2-change1.pdf>
FIPS 186-3 describes keys greater than 1024 bits.
The latest draft is at:
<http://csrc.nist.gov/publications/drafts/
fips_186-3/Draft-FIPS-186-3%20_March2006.pdf>
[HAC] Alfred Menezes, Paul van Oorschot, and Scott [HAC] Alfred Menezes, Paul van Oorschot, and Scott
Vanstone, "Handbook of Applied Cryptography," CRC Vanstone, "Handbook of Applied Cryptography," CRC
Press, 1996. Press, 1996.
<http://www.cacr.math.uwaterloo.ca/hac/> <http://www.cacr.math.uwaterloo.ca/hac/>
[IDEA] Lai, X, "On the design and security of block [IDEA] Lai, X, "On the design and security of block
ciphers", ETH Series in Information Processing, ciphers", ETH Series in Information Processing,
J.L. Massey (editor), Vol. 1, Hartung-Gorre Verlag J.L. Massey (editor), Vol. 1, Hartung-Gorre Verlag
Knostanz, Technische Hochschule (Zurich), 1992 Knostanz, Technische Hochschule (Zurich), 1992
skipping to change at page 72, line 5 skipping to change at page 73, line 38
"MIME Security with OpenPGP", RFC 3156, "MIME Security with OpenPGP", RFC 3156,
August 2001. August 2001.
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition:
protocols, algorithms, and source code in C", 1996. protocols, algorithms, and source code in C", 1996.
[TWOFISH] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C. [TWOFISH] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C.
Hall, and N. Ferguson, "The Twofish Encryption Hall, and N. Ferguson, "The Twofish Encryption
Algorithm", John Wiley & Sons, 1999. Algorithm", John Wiley & Sons, 1999.
17. References (Non-Normative) 17. References (Informative)
[BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal [BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal
signatures without knowing the secret key," signatures without knowing the secret key,"
Eurocrypt 96. Note that the version in the Eurocrypt 96. Note that the version in the
proceedings has an error. A revised version is proceedings has an error. A revised version is
available at the time of writing from available at the time of writing from
<ftp://ftp.inf.ethz.ch/pub/publications/papers/ti <ftp://ftp.inf.ethz.ch/pub/publications/papers/ti
/isc/ElGamal.ps> /isc/ElGamal.ps>
[DONNERHACKE] Donnerhacke, L., et. al, "PGP263in - an improved [DONNERHACKE] Donnerhacke, L., et. al, "PGP263in - an improved
skipping to change at page 72, line 35 skipping to change at page 74, line 17
CFB Mode Encryption As Used By OpenPGP," IACR CFB Mode Encryption As Used By OpenPGP," IACR
ePrint Archive: Report 2005/033, 8 Feb 2005 ePrint Archive: Report 2005/033, 8 Feb 2005
http://eprint.iacr.org/2005/033 http://eprint.iacr.org/2005/033
[RFC1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC [RFC1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC
1983, August 1996. 1983, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997. Requirement Level", BCP 14, RFC 2119, March 1997.
[SP800-57] NIST Special Publication 800-57, Recommendation on
Key Management
<http://csrc.nist.gov/publications/nistpubs/
800-57/SP800-57-Part1.pdf>
<http://csrc.nist.gov/publications/nistpubs/
800-57/SP800-57-Part2.pdf>
18. Full Copyright Statement 18. Full Copyright Statement
Copyright (C) 2005 by The Internet Society. Copyright (C) 2006 by The Internet Society.
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 110 change blocks. 
248 lines changed or deleted 334 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/