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