--- 1/draft-ietf-openpgp-rfc2440bis-07.txt 2006-02-05 00:55:38.000000000 +0100 +++ 2/draft-ietf-openpgp-rfc2440bis-08.txt 2006-02-05 00:55:38.000000000 +0100 @@ -1,23 +1,23 @@ Network Working Group Jon Callas Category: INTERNET-DRAFT PGP Corporation -draft-ietf-openpgp-rfc2440bis-07.txt +draft-ietf-openpgp-rfc2440bis-08.txt Expires Sep 2003 Lutz Donnerhacke March 2003 IN-Root-CA Individual Network e.V. Hal Finney Network Associates Rodney Thayer OpenPGP Message Format - draft-ietf-openpgp-rfc2440bis-07.txt + draft-ietf-openpgp-rfc2440bis-08.txt Copyright 2003 by The Internet Society. All Rights Reserved. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -107,105 +107,106 @@ 4.2.2.3. Five-Octet Lengths 15 4.2.2.4. Partial Body Lengths 15 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 20 5.2.3. Version 4 Signature Packet Format 23 - 5.2.3.1. Signature Subpacket Specification 24 + 5.2.3.1. Signature Subpacket Specification 23 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.5. Issuer 26 - 5.2.3.6. Key expiration time 27 + 5.2.3.6. Key expiration time 26 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.11.Exportable Certification 27 5.2.3.12.Revocable 28 5.2.3.13.Trust signature 28 - 5.2.3.14.Regular expression 29 + 5.2.3.14.Regular expression 28 5.2.3.15.Revocation key 29 5.2.3.16.Notation Data 29 5.2.3.17.Key server preferences 30 5.2.3.18.Preferred key server 30 - 5.2.3.19.Primary user id 30 + 5.2.3.19.Primary User ID 30 5.2.3.20.Policy URL 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.24.Features 33 5.2.3.25.Signature Target 33 5.2.4. Computing Signatures 34 5.2.4.1. Subpacket Hints 35 5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) 35 5.4. One-Pass Signature Packets (Tag 4) 36 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.2. Public Subkey Packet (Tag 14) 37 5.5.1.3. Secret Key Packet (Tag 5) 37 5.5.1.4. Secret Subkey Packet (Tag 7) 37 - 5.5.2. Public Key Packet Formats 38 + 5.5.2. Public Key Packet Formats 37 5.5.3. Secret Key Packet Formats 39 5.6. Compressed Data Packet (Tag 8) 41 5.7. Symmetrically Encrypted Data Packet (Tag 9) 41 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 42 - 5.9. Literal Data Packet (Tag 11) 43 + 5.9. Literal Data Packet (Tag 11) 42 5.10. Trust Packet (Tag 12) 43 5.11. User ID Packet (Tag 13) 43 - 5.12. User Attribute Packet (Tag 17) 44 + 5.12. User Attribute Packet (Tag 17) 43 5.12.1. The Image Attribute Subpacket 44 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 45 - 5.14. Modification Detection Code Packet (Tag 19) 47 + 5.14. Modification Detection Code Packet (Tag 19) 46 6. Radix-64 Conversions 47 6.1. An Implementation of the CRC-24 in "C" 48 6.2. Forming ASCII Armor 48 - 6.3. Encoding Binary in Radix-64 51 + 6.3. Encoding Binary in Radix-64 50 6.4. Decoding Radix-64 52 6.5. Examples of Radix-64 52 - 6.6. Example of an ASCII Armored Message 53 + 6.6. Example of an ASCII Armored Message 52 7. Cleartext signature framework 53 - 7.1. Dash-Escaped Text 54 + 7.1. Dash-Escaped Text 53 8. Regular Expressions 54 9. Constants 55 9.1. Public Key Algorithms 55 9.2. Symmetric Key Algorithms 55 9.3. Compression Algorithms 56 9.4. Hash Algorithms 56 10. Packet Composition 56 10.1. Transferable Public Keys 56 10.2. OpenPGP Messages 58 10.3. Detached Signatures 58 - 11. Enhanced Key Formats 59 - 11.1. Key Structures 59 - 11.2. Key IDs and Fingerprints 60 - 12. Notes on Algorithms 61 - 12.1. Symmetric Algorithm Preferences 61 + 11. Enhanced Key Formats 58 + 11.1. Key Structures 58 + 11.2. Key IDs and Fingerprints 59 + 12. Notes on Algorithms 60 + 12.1. Symmetric Algorithm Preferences 60 12.2. Other Algorithm Preferences 61 - 12.2.1. Compression Preferences 62 + 12.2.1. Compression Preferences 61 12.2.2. Hash Algorithm Preferences 62 12.3. Plaintext 62 - 12.4. RSA 63 + 12.4. RSA 62 12.5. Elgamal 63 12.6. DSA 64 12.7. Reserved Algorithm Numbers 64 12.8. OpenPGP CFB mode 64 13. Security Considerations 65 14. Implementation Nits 67 - 15. Authors and Working Group Chair 69 - 16. References 70 - 17. Full Copyright Statement 72 + 15. Authors and Working Group Chair 68 + 16. References 69 + 17. References (Non-Normative) 70 + 18. Full Copyright Statement 71 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 RFC2440, "OpenPGP Message Format", which itself replaces RFC 1991, "PGP Message Exchange Formats." 1.1. Terms @@ -703,43 +704,45 @@ 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 (of one of the three types -- one octet, two-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 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. + 4.2.3. Packet Length Examples These examples show ways that new-format packets might encode the packet lengths. 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. 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. 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 @@ -830,28 +833,28 @@ 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 some data. The most common signatures are a signature of a file or a - block of text, and a signature that is a certification of a user ID. + block of text, and a signature that is a certification of a User ID. Two versions of signature packets are defined. Version 3 provides basic signature information, while version 4 provides an expandable format with subpackets that can specify more information about the signature. PGP 2.6.x only accepts version 3 signatures. - Implementations MUST accept V3 signatures. Implementations SHOULD + Implementations SHOULD accept V3 signatures. Implementations SHOULD generate V4 signatures. Implementations MAY generate a V3 signature that can be verified by PGP 2.6.x. Note that if an implementation is creating an encrypted and signed 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 @@ -870,27 +873,27 @@ 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 - owner of the key is in fact the person described by the user ID. + owner of the key is in fact the person described by the User ID. Note that all PGP "key signatures" are this type of certification. 0x11: Persona certification of a User ID and Public Key packet. The issuer of this certification has not done any verification - of the claim that the owner of this key is the user ID + of the claim that the owner of this key is the User ID 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. @@ -924,36 +927,39 @@ 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 + This signature revokes an earlier User ID certification signature (signature class 0x10 through 0x13) or direct-key signature (0x1F). It should be issued by the same key that issued the revoked signature or an authorized revocation key. The signature should have a later creation date than the signature it revokes. 0x40: Timestamp signature. This signature is only meaningful for the timestamp contained in it. - 0x50: Notary signature. + 0x50: Third-Party Confirmation signature. This signature is a signature over some other OpenPGP signature - packet. It is a notary seal on the signed data. Note that a - notary signature SHOULD include a Signature Target subpacket to - give easy identification. + packet(s). It is a notary seal on the signed data. A third-party + signature SHOULD include Signature Target subpacket(s) to give + easy identification. Note that we really do mean SHOULD. There + are plausible uses for this (such a a blind party that only sees + the signature, not the key nor source document) that cannot + include a target subpacket. 5.2.2. Version 3 Signature Packet Format The body of a version 3 Signature Packet contains: - One-octet version number (3). - One-octet length of following hashed material. MUST be 5. - One-octet signature type. @@ -1002,55 +1008,47 @@ 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 hexadecimal representations for the currently defined hash algorithms are: - - MD2: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02 - - MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05 - RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01 - SHA-1: 0x2B, 0x0E, 0x03, 0x02, 0x1A - 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: - - MD2: 1.2.840.113549.2.2 - - MD5: 1.2.840.113549.2.5 - RIPEMD-160: 1.3.36.3.2.1 - SHA-1: 1.3.14.3.2.26 - 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: - MD2: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86, - 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02, 0x05, 0x00, - 0x04, 0x10 - 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 @@ -1158,28 +1157,27 @@ 9 = key expiration time 10 = placeholder for backward compatibility 11 = preferred symmetric algorithms 12 = revocation key 16 = issuer key ID 20 = notation data 21 = preferred hash algorithms 22 = preferred compression algorithms 23 = key server preferences 24 = preferred key server - 25 = primary user id + 25 = primary User ID 26 = policy URL 27 = key flags - 28 = signer's user id + 28 = signer's User ID 29 = reason for revocation 30 = features 31 = signature target - 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 evaluator SHOULD consider the signature to be in error. @@ -1192,57 +1190,57 @@ 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 behave in a polite manner to respect the wishes of those users who do implement these preferences. 5.2.3.2. Signature Subpacket Types A number of subpackets are currently defined. Some subpackets apply to the signature itself and some are attributes of the key. - Subpackets that are found on a self-signature are placed on a user - id certification made by the key itself. Note that a key may have - more than one user id, and thus may have more than one + Subpackets that are found on a self-signature are placed on a User + ID certification made by the key itself. Note that a key may have + more than one User ID, and thus may have more than one self-signature, and differing subpackets. A subpacket may be found either in the hashed or unhashed subpacket sections of a signature. If a subpacket is not hashed, then the information in it cannot be considered definitive because it is not part of the signature proper. 5.2.3.3. Notes on Self-Signatures A self-signature is a binding signature made by the key the signature refers to. There are three types of self-signatures, the certification signatures (types 0x10-0x13), the direct-key signature (type 0x1f), and the subkey binding signature (type 0x18). For - certification self-signatures, each user ID may have a + certification self-signatures, each User ID may have a self-signature, and thus different subpackets in those self-signatures. For subkey binding signatures, each subkey in fact has a self-signature. Subpackets that appear in a certification self-signature apply to the username, and subpackets that appear in 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 Triple-DES. 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, - then algorithm of the default user id of the key provides the + then algorithm of the default User ID of the key provides the default 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 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 address, etc. Revoking a binding signature effectively retires that subkey. Revoking a direct-key signature cancels that signature. Please see the "Reason for Revocation" subpacket below for more relevant detail. @@ -1371,24 +1369,23 @@ 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 (null-terminated regular expression) - 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 + 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) Authorizes the specified key to issue revocation signatures for this @@ -1462,35 +1459,36 @@ the key holder requests that this key only be modified or updated by the key holder or an administrator of the key server. This is found only on a self-signature. 5.2.3.18. Preferred key server (String) This is a URL of a key server that the key holder prefers be used - for updates. Note that keys with multiple user ids can have a - preferred key server for each user id. Note also that since this is + for updates. Note that keys with multiple User IDs can have a + preferred key server for each User ID. Note also that since this is a URL, the key server can actually be a copy of the key retrieved by ftp, http, finger, etc. -5.2.3.19. Primary user id +5.2.3.19. Primary User ID (1 octet, Boolean) - This is a flag in a user id's self signature that states whether - this user id is the main user id for this key. It is reasonable for + + This is a flag in a User ID's self signature that states whether + this User ID is the main User ID for this key. It is reasonable for an implementation to resolve ambiguities in preferences, etc. by - referring to the primary user id. If this flag is absent, its value - is zero. If more than one user id in a key is marked as primary, the + referring to the primary User ID. If this flag is absent, its value + is zero. If more than one User ID in a key is marked as primary, the implementation may resolve the ambiguity in any way it sees fit, but - it is RECOMMENDED that priority be given to the user ID with the + it is RECOMMENDED that priority be given to the User ID with the most recent self-signature. When appearing on a self-signature on a User ID packet, this subpacket applies only to User ID packets. When appearing on a self-signature on a User Attribute packet, this subpacket applies only to User Attribute packets. That is to say, there are two different and independent "primaries" - one for User IDs, and one for User Attributes. 5.2.3.20. Policy URL @@ -1544,21 +1542,21 @@ The "split key" (0x10) and "group key" (0x80) flags are placed on a self-signature only; they are meaningless on a certification signature. They SHOULD be placed only on a direct-key signature (type 0x1f) or a subkey signature (type 0x18), one that refers to the key the flag applies to. 5.2.3.22. Signer's User ID (String) - This subpacket allows a keyholder to state which user id is + This subpacket allows a keyholder to state which User ID is responsible for the signing. Many keyholders use a single key for different purposes, such as business communications as well as personal communications. This subpacket allows such a keyholder to state which of their roles is making a signature. This subpacket is not appropriate to use to refer to a User Attribute packet. 5.2.3.23. Reason for Revocation @@ -1583,21 +1581,21 @@ of the subpacket is the length of the reason string plus one. 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 superceded 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 SHOULD include an 0x20 subpacket. 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 no longer is a part of validity calculations. 5.2.3.24. Features @@ -1624,25 +1622,27 @@ If an implementation implements any of the defined features, it SHOULD implement the features subpacket, too. In the case of Modification Detection, an implementation may freely infer this feature from other suitable implementation-dependent mechanisms. 5.2.3.25. Signature Target (1 octet PK algorithm, 1 octet hash algorithm, N octets hash) + This subpacket identifies a specific target signature that a signature refers to. For revocation signatures, this subpacket provides explicit designation of which signature is being revoked. - For a notary or timestamp signature, this designates what signature - is signed. All arguments are an identifier of that target signature. + For a third-party or timestamp signature, this designates what + signature is signed. All arguments are an identifier of that target + signature. The N octets of hash data MUST be the size of the hash of the signature. For example, a target signature with a SHA-1 hash MUST have 20 octets of hash data. 5.2.4. Computing Signatures All signatures are formed by producing a hash over the signature data, and then using the resulting hash in the signature algorithm. @@ -1651,29 +1651,34 @@ For standalone signatures, this is a null string. When a signature is made over a key, the hash data starts with the octet 0x99, followed by a two-octet length of the key, and then body of the key packet. (Note that this is an old-style packet header for a key packet with two-octet length.) A subkey signature (type 0x18) then hashes the subkey, using the same format as the main key (also using 0x99 as the first octet). Key revocation signatures (types 0x20 and 0x28) hash only the key being revoked. - A certification signature (type 0x10 through 0x13) hashes the user - id being bound to the key into the hash context after the above + When a signature is made over a signature, the hash data starts with + the octet 0x88, followed by the four-octet length of the signature, + and then the body of the signature packet. (Note that this is an + old-style packet header for a signature packet with the + length-of-length set to zero). + + A certification signature (type 0x10 through 0x13) hashes the User + ID being bound to the key into the hash context after the above data. A V3 certification hashes the contents of the name packet, without any header. A V4 certification hashes the constant 0xb4 for - user ID certifications or the constant 0xd1 for User Attribute - certifications (which are old-style packet headers with the - length-of-length set to zero), followed by a four-octet number - giving the length of the user ID or User Attribute data, and then - the User ID or User Attribute data. + User ID certifications or the constant 0xd1 for User Attribute + certifications, followed by a four-octet number giving the length of + the User ID or User Attribute data, and then the User ID or User + Attribute data. Once the data body is hashed, then a trailer is hashed. A V3 signature hashes five octets of the packet body, starting from the signature type field. This data is the signature type, followed by the four-octet signature time. A V4 signature hashes the packet body starting from its first field, the version number, through the end of the hashed subpacket data. Thus, the fields hashed are the signature version, the signature type, the public key algorithm, the hash algorithm, the hashed subpacket length, and the hashed subpacket body. @@ -1683,24 +1688,20 @@ big-endian number that is the length of the hashed data from the signature packet (note that this number does not include these final six octets. After all this has been hashed, the resulting hash field is used in the signature algorithm, and placed at the end of the signature packet. 5.2.4.1. Subpacket Hints - An implementation SHOULD put the two mandatory subpackets, creation - time and issuer, as the first subpackets in the subpacket list, - simply to make it easier for the implementer to find them. - It is certainly possible for a signature to contain conflicting information in subpackets. For example, a signature may contain multiple copies of a preference or multiple expiration times. In most cases, an implementation SHOULD use the last subpacket in the signature, but MAY use any conflict resolution scheme that makes more sense. Please note that we are intentionally leaving conflict resolution to the implementer; most conflicts are simply syntax errors, and the wishy-washy language here allows a receiver to be generous in what they accept, while putting pressure on a creator to be stingy in what they generate. @@ -1831,68 +1832,62 @@ includes the secret key material after all the public key fields. 5.5.1.4. Secret Subkey Packet (Tag 7) 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 2 packets are identical in - format to Version 3 packets, but are generated by PGP 2.5 or before. - V2 packets are deprecated and they MUST NOT be generated. - - PGP 5.0 introduced version 4 packets, with new fields and semantics. - PGP 2.6.x will not accept key-material packets with versions - greater than 3. + 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. An - implementation MAY generate a V3 key to ensure interoperability with - old software; note, however, that V4 keys correct some security - deficiencies in V3 keys. These deficiencies are described below. An - implementation MUST NOT create a V3 key with a public key algorithm - other than RSA. + 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. 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. - A one-octet number denoting the public key algorithm of this key - A series of multi-precision integers comprising the key material: - a multiprecision integer (MPI) of RSA public modulus n; - an MPI of RSA public encryption exponent e. - V3 keys SHOULD only be used for backward compatibility because of - 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, which increases the 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 fingerprints. + 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, which increases the + 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 + fingerprints. 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: - A one-octet version number (4). - A four-octet number denoting the time that the key was created. - A one-octet number denoting the public key algorithm of this key - A series of multi-precision integers comprising the key material. This algorithm-specific portion is: @@ -2138,21 +2133,21 @@ 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 data that is intended to represent the name and email address of the key holder. By convention, it includes an RFC822 mail name, but there are no restrictions on its content. The packet length in the header specifies the length of - the user id. If it is text, it is encoded in UTF-8. + the User ID. If it is text, it is encoded in UTF-8. 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 (by convention) 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 Attribute packet may be used anywhere that a User ID packet may be used. @@ -2185,22 +2180,22 @@ (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 header. Note that unlike other multi-byte 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. Also note that this is the same encoding used for - signature subpackets + 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 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 @@ -2658,30 +2652,37 @@ Current message digest names are described below with the algorithm IDs. 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. The message - digest is computed using the cleartext itself, not the dash escaped - form. + recognizing armor headers of the cleartext itself. An implementation + MAY dash escape any line, SHOULD dash escape lines commencing "From + " (note the 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 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, and tabs, 0x09) at the end of any line is ignored when the cleartext signature is calculated. 8. Regular Expressions A regular expression is zero or more branches, separated by '|'. It matches anything that matches one of the branches. A branch is zero or more pieces, concatenated. It matches a match for the first, followed by a match for the second, etc. @@ -2743,22 +2744,22 @@ 9.2. Symmetric Key Algorithms ID Algorithm -- --------- 0 - Plaintext or unencrypted data 1 - IDEA [IDEA] 2 - Triple-DES (DES-EDE, [SCHNEIER] - 168 bit key derived from 192) 3 - CAST5 (128 bit key, as per RFC2144) 4 - Blowfish (128 bit key, 16 rounds) [BLOWFISH] - 5 - SAFER-SK128 (13 rounds) [SAFER] - 6 - Reserved for DES/SK + 5 - Reserved + 6 - Reserved 7 - AES with 128-bit key [AES] 8 - AES with 192-bit key 9 - AES with 256-bit key 10 - Twofish with 256-bit key [TWOFISH] 100 to 110 - Private/Experimental algorithm. Implementations MUST implement Triple-DES. Implementations SHOULD implement AES-128 and CAST5. Implementations that interoperate with PGP 2.6 or earlier need to support IDEA, as that is the only symmetric cipher those versions use. Implementations MAY implement @@ -2776,32 +2777,31 @@ Implementations MUST implement uncompressed data. Implementations SHOULD implement ZIP. Implementations MAY implement ZLIB. 9.4. Hash Algorithms ID Algorithm Text Name -- --------- ---- ---- 1 - MD5 "MD5" 2 - SHA-1 "SHA1" 3 - RIPE-MD/160 "RIPEMD160" - 4 - Reserved for double-width SHA (experimental, - obviated) - 5 - MD2 "MD2" - 6 - Reserved for TIGER/192 "TIGER192" - 7 - Reserved for HAVAL (5 pass, 160-bit) "HAVAL-5-160" + 4 - Reserved + 5 - Reserved + 6 - Reserved + 7 - Reserved 8 - SHA256 "SHA256" 9 - SHA384 "SHA384" 10 - SHA512 "SHA512" 100 to 110 - Private/Experimental algorithm. - Implementations MUST implement SHA-1. Implementations SHOULD - implement MD5. + Implementations MUST implement SHA-1. Implementations MAY implement + other algorithms. 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. 10.1. Transferable Public Keys @@ -2831,23 +2830,23 @@ packets provides the identity of the owner of this public key. If there are multiple User ID packets, this corresponds to multiple means of identifying the same unique individual user; for example, a user may have more than one email address, and construct a User ID for each one. Immediately following each User ID packet, there are zero or more signature packets. Each signature packet is calculated on the immediately preceding User ID packet and the initial Public Key packet. The signature serves to certify the corresponding public key - and user ID. In effect, the signer is testifying to his or her + and User ID. In effect, the signer is testifying to his or her belief that this public key belongs to the user identified by this - user ID. + User ID. 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. @@ -2918,41 +2917,40 @@ 11.1. Key Structures The format of an OpenPGP V3 key is as follows. Entries in square brackets are optional and ellipses indicate repetition. RSA Public Key [Revocation Self Signature] User ID [Signature ...] [User ID [Signature ...] ...] - Each signature certifies the RSA public key and the preceding user - ID. The RSA public key can have many user IDs and each user ID can + Each signature certifies the RSA public key and the preceding User + ID. The RSA public key can have many User IDs and each User ID can have many signatures. The format of an OpenPGP V4 key that uses two public keys is similar except that the other keys are added to the end as 'subkeys' of the primary key. Primary-Key [Revocation Self Signature] [Direct Key Self 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 V4 is preferred, of - course. + signature may be in either V3 or V4 format, but SHOULD be V4. 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 key that has a main key and subkeys, 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. @@ -2964,22 +2962,22 @@ 11.2. Key IDs and Fingerprints 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. - A V4 fingerprint is the 160-bit SHA-1 hash of the one-octet Packet - Tag, followed by the two-octet packet length, followed by the entire + 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: 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) @@ -3194,24 +3193,20 @@ algorithm. These are marked in the Public Algorithms section as "(reserved for)". The reserved public key algorithms, Elliptic Curve (18), ECDSA (19), and X9.42 (21) do not have the necessary parameters, parameter order, or semantics defined. The reserved symmetric key algorithm, DES/SK (6), does not have semantics defined. - The reserved hash algorithms, TIGER192 (6), and HAVAL-5-160 (7), do - not have OIDs. The reserved algorithm number 4, reserved for a - double-width variant of SHA1, is not presently defined. - 12.8. OpenPGP CFB mode OpenPGP does symmetric encryption using a variant of Cipher Feedback Mode (CFB mode). This section describes the procedure it uses in detail. This mode is what is used for Symmetrically Encrypted Data Packets; the mechanism used for encrypting secret key material is similar, but described in those sections above. 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 @@ -3282,20 +3277,25 @@ * Certain operations in this specification involve the use of random numbers. An appropriate entropy source should be used to generate these numbers. See RFC 1750. * The MD5 hash algorithm has been found to have weaknesses (pseudo-collisions in the compress function) that make some people deprecate its use. They consider the SHA-1 algorithm better. + * 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 + 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 @@ -3379,51 +3379,36 @@ 14. Implementation Nits This section is a collection of comments to help an implementer, particularly with an eye to backward compatibility. Previous implementations of PGP are not OpenPGP-compliant. Often the differences are small, but small differences are frequently more vexing than large differences. Thus, this is a non-comprehensive list of potential problems and gotchas for a developer who is trying to be backward-compatible. - * PGP 5.x does not accept V4 signatures for anything other than - key material. - - * PGP 5.x does not recognize the "five-octet" lengths in - new-format headers or in signature subpacket lengths. - - * PGP 5.0 rejects an encrypted session key if the key size differs - from the S2K symmetric algorithm. This is a bug in its - validation function. - - * PGP 5.0 does not handle multiple one-pass signature headers and - trailers. Signing one will compress the one-pass signed literal - and prefix a V3 signature instead of doing a nested one-pass - signature. + * The IDEA algorithm is patented, and yet it is required for PGP + 2.x interoperability. It is also the defacto preferred algorithm + for a V3 key with a V3 self-signature (or no self-signature). * When exporting a private key, PGP 2.x generates the header "BEGIN PGP SECRET KEY BLOCK" instead of "BEGIN PGP PRIVATE KEY BLOCK". All previous versions ignore the implied data type, and look directly at the packet data type. - * In a clear-signed signature, PGP 5.0 will figure out the correct - hash algorithm if there is no "Hash:" header, but it will reject - a mismatch between the header and the actual algorithm used. The - "standard" (i.e. Zimmermann/Finney/et al.) version of PGP 2.x - rejects the "Hash:" header and assumes MD5. There are a number - of enhanced variants of PGP 2.6.x that have been modified for - SHA-1 signatures. + * PGP 2.0 through 2.5 generated V2 Public Key Packets. These are + identical to the deprecated V3 keys except for the version + number. An implementation may accept or reject them as it sees + fit. - * PGP 5.0 can read an RSA key in V4 format, but can only recognize - it with a V3 key id, and can properly use only a V3 format RSA - key. + * PGP 2.6.x will not accept key-material packets with versions + greater than 3. * Neither PGP 5.x nor PGP 6.0 recognize Elgamal Encrypt and Sign keys. They only handle Elgamal Encrypt-only keys. * There are many ways possible for two keys to have the same key 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 @@ -3436,27 +3421,26 @@ "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. 15. Authors and Working Group Chair The working group can be contacted via the current chair: - John W. Noerenberg, II - Qualcomm, Inc - 6455 Lusk Blvd - San Diego, CA 92131 USA - Email: jwn2@qualcomm.com - Tel: +1 (619) 658-3510 - + Derek Atkins + IHTFP Consulting, Inc. + 6 Farragut Ave + Somerville, MA 02144 USA + Email: derek@ihtfp.com + Tel: +1 617 623 3745 The principal authors of this draft are: Jon Callas Email: jon@callas.org Tel: +1 (408) 448-6801 Lutz Donnerhacke IKS GmbH Wildenbruchstr. 15 @@ -3484,123 +3468,120 @@ 16. References [AES] Advanced Encryption Standards Questions and Answers - [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 - - [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 - [DONNERHACKE] Donnerhacke, L., et. al, "PGP263in - an improved - international version of PGP", ftp://ftp.iks- - jena.de/mitarb/lutz/crypt/software/pgp/ - [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. [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 [ISO10646] ISO/IEC 10646-1:1993. International Standard -- Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. [JFIF] JPEG File Interchange Format (Version 1.02). Eric Hamilton, C-Cube Microsystems, Milpitas, CA, September 1, 1992. + [RFC1641] Goldsmith, D. and M. Davis, "Using Unicode with + MIME", RFC 1641, July 1994. + + [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format + Specification version 1.3.", RFC 1951, May 1996. + + [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC + 2144, May 1997. + + [RFC2279] Yergeau., F., "UTF-8, a transformation format of + Unicode and ISO 10646", RFC 2279, January 1998. + + [RFC2437] B. Kaliski and J. Staddon, " PKCS #1: RSA + Cryptography Specifications Version 2.0", + RFC 2437, October 1998. + + [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) + + [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 + international version of PGP", ftp://ftp.iks- + jena.de/mitarb/lutz/crypt/software/pgp/ + [MENEZES] Alfred Menezes, Paul van Oorschot, and Scott + Vanstone, "Handbook of Applied Cryptography," CRC + Press, 1996. + [JKS02] Kahil Jallad, Jonathan Katz, Bruce Schneier "Implementation of Chosen-Ciphertext Attacks against PGP and GnuPG" http://www.counterpane.com/pgp-attack.html - [MENEZES] Alfred Menezes, Paul van Oorschot, and Scott - Vanstone, "Handbook of Applied Cryptography," CRC - Press, 1996. [RFC822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [RFC1423] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, October 1993. - [RFC1641] Goldsmith, D. and M. Davis, "Using Unicode with - MIME", RFC 1641, July 1994. - [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. - [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format - Specification version 1.3.", RFC 1951, May 1996. - [RFC1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC 1983, August 1996. [RFC1991] Atkins, D., Stallings, W. and P. Zimmermann, "PGP Message Exchange Formats", RFC 1991, August 1996. [RFC2045] Borenstein, N. and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies.", RFC 2045, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997. - [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC - 2144, May 1997. - - [RFC2279] Yergeau., F., "UTF-8, a transformation format of - Unicode and ISO 10646", RFC 2279, January 1998. - - [RFC2437] B. Kaliski and J. Staddon, " PKCS #1: RSA - Cryptography Specifications Version 2.0", - RFC 2437, October 1998. - [RFC3156] M. Elkins, D. Del Torto, R. Levien, T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001. - [SAFER] Massey, J.L. "SAFER K-64: One Year Later", B. - Preneel, editor, Fast Software Encryption, Second - International Workshop (LNCS 1008) pp212-241, - Springer-Verlag 1995 - - [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. Full Copyright Statement +18. Full Copyright Statement Copyright 2003 by The Internet Society. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing