--- 1/draft-ietf-openpgp-rfc2440bis-19.txt 2007-04-03 01:12:15.000000000 +0200 +++ 2/draft-ietf-openpgp-rfc2440bis-20.txt 2007-04-03 01:12:15.000000000 +0200 @@ -4,21 +4,21 @@ Expires September 2007 Lutz Donnerhacke Obsoletes: 1991, 2440 Hal Finney PGP Corporation David Shaw Rodney Thayer OpenPGP Message Format - draft-ietf-openpgp-rfc2440bis-19 + draft-ietf-openpgp-rfc2440bis-20 Status of this Memo 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -94,67 +94,67 @@ 4.2.2. New-Format Packet Lengths 15 4.2.2.1. One-Octet Lengths 16 4.2.2.2. Two-Octet Lengths 16 4.2.2.3. Five-Octet Lengths 16 4.2.2.4. Partial Body Lengths 16 4.2.3. Packet Length Examples 17 4.3. Packet Tags 17 5. Packet Types 18 5.1. Public-Key Encrypted Session Key Packets (Tag 1) 18 5.2. Signature Packet (Tag 2) 19 - 5.2.1. Signature Types 19 + 5.2.1. Signature Types 20 5.2.2. Version 3 Signature Packet Format 22 5.2.3. Version 4 Signature Packet Format 24 5.2.3.1. Signature Subpacket Specification 25 - 5.2.3.2. Signature Subpacket Types 26 + 5.2.3.2. Signature Subpacket Types 27 5.2.3.3. Notes on Self-Signatures 27 5.2.3.4. Signature creation time 28 5.2.3.5. Issuer 28 5.2.3.6. Key expiration time 28 5.2.3.7. Preferred symmetric algorithms 28 5.2.3.8. Preferred hash algorithms 28 - 5.2.3.9. Preferred compression algorithms 28 + 5.2.3.9. Preferred compression algorithms 29 5.2.3.10.Signature expiration time 29 5.2.3.11.Exportable Certification 29 - 5.2.3.12.Revocable 29 + 5.2.3.12.Revocable 30 5.2.3.13.Trust signature 30 5.2.3.14.Regular expression 30 5.2.3.15.Revocation key 30 5.2.3.16.Notation Data 31 - 5.2.3.17.Key server preferences 31 + 5.2.3.17.Key server preferences 32 5.2.3.18.Preferred key server 32 5.2.3.19.Primary User ID 32 5.2.3.20.Policy URI 32 - 5.2.3.21.Key Flags 32 - 5.2.3.22.Signer's User ID 33 + 5.2.3.21.Key Flags 33 + 5.2.3.22.Signer's User ID 34 5.2.3.23.Reason for Revocation 34 - 5.2.3.24.Features 34 + 5.2.3.24.Features 35 5.2.3.25.Signature Target 35 5.2.3.26.Embedded Signature 35 - 5.2.4. Computing Signatures 35 - 5.2.4.1. Subpacket Hints 36 + 5.2.4. Computing Signatures 36 + 5.2.4.1. Subpacket Hints 37 5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) 37 5.4. One-Pass Signature Packets (Tag 4) 38 - 5.5. Key Material Packet 38 + 5.5. Key Material Packet 39 5.5.1. Key Packet Variants 39 5.5.1.1. Public Key Packet (Tag 6) 39 5.5.1.2. Public Subkey Packet (Tag 14) 39 5.5.1.3. Secret Key Packet (Tag 5) 39 5.5.1.4. Secret Subkey Packet (Tag 7) 39 5.5.2. Public Key Packet Formats 39 5.5.3. Secret Key Packet Formats 41 5.6. Compressed Data Packet (Tag 8) 43 5.7. Symmetrically Encrypted Data Packet (Tag 9) 43 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 44 5.9. Literal Data Packet (Tag 11) 44 5.10. Trust Packet (Tag 12) 45 - 5.11. User ID Packet (Tag 13) 45 + 5.11. User ID Packet (Tag 13) 46 5.12. User Attribute Packet (Tag 17) 46 5.12.1. The Image Attribute Subpacket 46 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 47 5.14. Modification Detection Code Packet (Tag 19) 50 6. Radix-64 Conversions 50 6.1. An Implementation of the CRC-24 in "C" 51 6.2. Forming ASCII Armor 51 6.3. Encoding Binary in Radix-64 54 6.4. Decoding Radix-64 55 6.5. Examples of Radix-64 55 @@ -169,58 +169,58 @@ 9.4. Hash Algorithms 59 10. IANA Considerations 60 10.1. New String-to-Key specifier types 60 10.2. New Packets 60 10.2.1. User Attribute Types 60 10.2.1.1.Image Format Subpacket Types 60 10.2.2. New Signature Subpackets 61 10.2.2.1.Signature Notation Data Subpackets 61 10.2.2.2.Key Server Preference Extensions 61 10.2.2.3.Key Flags Extensions 61 - 10.2.2.4.Reason For Revocation Extensions 61 + 10.2.2.4.Reason For Revocation Extensions 62 10.2.2.5.Implementation Features 62 10.2.3. New Packet Versions 62 10.3. New Algorithms 62 - 10.3.1. Public Key Algorithms 62 + 10.3.1. Public Key Algorithms 63 10.3.2. Symmetric Key Algorithms 63 10.3.3. Hash Algorithms 63 10.3.4. Compression Algorithms 63 10.4. Private or Experimental Parameters 63 - 10.5. Extension of the MDC System 63 + 10.5. Extension of the MDC System 64 10.6. Meta-Considerations 64 - 11. Packet Composition 64 + 11. Packet Composition 65 11.1. Transferable Public Keys 65 11.2. Transferable Secret Keys 66 11.3. OpenPGP Messages 66 11.4. Detached Signatures 67 12. Enhanced Key Formats 67 12.1. Key Structures 67 12.2. Key IDs and Fingerprints 68 13. Notes on Algorithms 69 13.1. PKCS#1 Encoding In OpenPGP 69 - 13.1.1. EME-PKCS1-v1_5-ENCODE 69 + 13.1.1. EME-PKCS1-v1_5-ENCODE 70 13.1.2. EME-PKCS1-v1_5-DECODE 70 - 13.1.3. EMSA-PKCS1-v1_5 70 - 13.2. Symmetric Algorithm Preferences 71 + 13.1.3. EMSA-PKCS1-v1_5 71 + 13.2. Symmetric Algorithm Preferences 72 13.3. Other Algorithm Preferences 72 13.3.1. Compression Preferences 72 13.3.2. Hash Algorithm Preferences 73 13.4. Plaintext 73 13.5. RSA 73 - 13.6. DSA 73 + 13.6. DSA 74 13.7. Elgamal 74 13.8. Reserved Algorithm Numbers 74 - 13.9. OpenPGP CFB mode 74 + 13.9. OpenPGP CFB mode 75 14. Security Considerations 76 15. Implementation Nits 79 16. Authors' Addresses 80 - 17. References (Normative) 80 + 17. References (Normative) 81 18. References (Informative) 82 19. Full Copyright Statement 83 20. Intellectual Property 84 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 @@ -433,21 +433,21 @@ 3.3. Key IDs A Key ID is an eight-octet scalar that identifies a key. Implementations SHOULD NOT assume that Key IDs are unique. The section, "Enhanced Key Formats" below describes how Key IDs are formed. 3.4. Text Unless otherwise specified, the character set for text is the UTF-8 - [RFC2279] encoding of Unicode [ISO10646]. + [RFC3629] encoding of Unicode [ISO10646]. 3.5. Time fields A time field is an unsigned four-octet number containing the number of seconds elapsed since midnight, 1 January 1970 UTC. 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 @@ -845,22 +845,23 @@ - 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 in Section 12.1 to form the "m" - value used in the formulas above. + PKCS#1 block encoding EME-PKCS1-v1_5 in Section 12.1 of RFC 3447 to + form the "m" value used in the formulas above. See Section 13.1 of + this document for notes on OpenPGP's use of PKCS#1. 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 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 @@ -1032,26 +1033,26 @@ - 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 signatures than for 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 as described in section 12.1. 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: + PKCS#1 section 9.2.1 of RFC 3447 encoded using PKCS#1 encoding type + EMSA-PKCS1-v1_5 as described in section 12.1 of RFC 3447. 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 @@ -2096,21 +2094,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. + BZip2-compressed packets are compressed using the BZip2 [BZ2] + 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: @@ -2725,27 +2725,24 @@ 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 Input data: 0x14fb9c03d97e Hex: 1 4 f b 9 c | 0 3 d 9 7 e - 8-bit: 00010100 11111011 10011100 | 00000011 11011001 - 11111110 - 6-bit: 000101 001111 101110 011100 | 000000 111101 100111 - 111110 + 8-bit: 00010100 11111011 10011100 | 00000011 11011001 11111110 + 6-bit: 000101 001111 101110 011100 | 000000 111101 100111 111110 Decimal: 5 15 46 28 0 61 37 62 Output: F P u c A 9 l + - Input data: 0x14fb9c03d9 Hex: 1 4 f b 9 c | 0 3 d 9 8-bit: 00010100 11111011 10011100 | 00000011 11011001 pad with 00 6-bit: 000101 001111 101110 011100 | 000000 111101 100100 Decimal: 5 15 46 28 0 61 36 pad with = Output: F P u c A 9 k = Input data: 0x14fb9c03 Hex: 1 4 f b 9 c | 0 3 @@ -2922,36 +2918,36 @@ 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 any other algorithm. 9.3. Compression Algorithms ID Algorithm -- --------- 0 - Uncompressed - 1 - ZIP (RFC 1951) - 2 - ZLIB (RFC 1950) + 1 - ZIP [RFC 1951] + 2 - ZLIB [RFC 1950] 3 - BZip2 [BZ2] 100 to 110 - Private/Experimental algorithm. Implementations MUST implement uncompressed data. Implementations SHOULD implement ZIP. Implementations MAY implement any other algorithm. 9.4. Hash Algorithms ID Algorithm Text Name -- --------- ---- ---- - 1 - MD5 "MD5" + 1 - MD5 [HAC] "MD5" 2 - SHA-1 [FIPS180] "SHA1" - 3 - RIPE-MD/160 "RIPEMD160" + 3 - RIPE-MD/160 [HAC] "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. @@ -3130,21 +3126,21 @@ 5.2.2 for the OIDs and expanded signature prefixes. Adding a new hash algorithm MUST be done through the IETF CONSENSUS method, as described in [RFC2434]. 10.3.4. Compression Algorithms OpenPGP specifies a number of compression algorithms. This specification creates a registry of compression algorithm identifiers. The registry includes the algorithm name, and a reference to the defining specification. The initial values for this - registry can be found in section 9. Adding a new compression key + registry can be found in section 9.3. Adding a new compression key algorithm MUST be done through the IETF CONSENSUS method, as described in [RFC2434]. 10.4. Private or Experimental Parameters S2K specifiers, Signature subpacket types, user attribute types, image format types, and algorithms described in Section 9 all reserve the range 100 to 110 for private and experimental use. Packet types reserve the range 60 to 63 for private and experimental use. These are intentionally managed with the PRIVATE USE method, as @@ -3712,21 +3710,21 @@ 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. Previous versions of OpenPGP permitted Elgamal [ELGAMAL] signatures with a public key identifier of 20. These are no longer permitted. An implementation MUST NOT generate such keys. An implementation - MUST NOT generate Elgamal signatures. + MUST NOT generate Elgamal signatures. See [BLEICHENBACHER]. 13.9. 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 @@ -3792,21 +3790,21 @@ * As with any technology involving cryptography, you should check the current literature to determine if any algorithms used here have been found to be vulnerable to attack. * This specification uses Public Key Cryptography technologies. It is assumed that the private key portion of a public-private key pair is controlled and secured by the proper party or parties. * 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. + generate these numbers. See RFC 4086. * 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. * SHA-224 and SHA-384 require the same work as SHA-256 and SHA-512 respectively. In general, there are few reasons to use them outside of DSS compatibility. You need a situation where one @@ -4079,94 +4076,85 @@ [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. - [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. - - [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. [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. - [RFC2822] Resnick, P., "Internet Message Format", RFC 2822. [RFC3156] M. Elkins, D. Del Torto, R. Levien, T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001. [RFC3447] B. Kaliski and J. Staddon, "PKCS #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. + [RFC3629] Yergeau., F., "UTF-8, a transformation format of + Unicode and ISO 10646", RFC 3629, November 2003. + + [RFC4086] Eastlake, D., Crocker, S. and J. Schiller, + "Randomness Recommendations for Security", RFC + 4086, June 2005. + [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. 18. 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 - international version of PGP", ftp://ftp.iks- - jena.de/mitarb/lutz/crypt/software/pgp/ [JKS02] Kahil Jallad, Jonathan Katz, Bruce Schneier "Implementation of Chosen-Ciphertext Attacks against PGP and GnuPG" http://www.counterpane.com/pgp-attack.html [MAURER] Ueli Maurer, "Modelling a Public-Key Infrastructure", Proc. 1996 European Symposium on Research in Computer Security (ESORICS' 96), Lecture Notes in Computer Science, Springer-Verlag, vol. 1146, pp. 325-350, Sep 1996. [MZ05] Serge Mister, Robert Zuccherato, "An Attack on CFB Mode Encryption As Used By OpenPGP," IACR http://eprint.iacr.org/2005/033 - [RFC1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC - 1983, August 1996. + [RFC1423] Balenson, D., "Privacy Enhancement for Internet + Electronic Mail: Part III: Algorithms, Modes, and + Identifiers", RFC 1423, October 1993. + + [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format + Specification version 1.3.", RFC 1951, May 1996. + + [RFC1991] Atkins, D., Stallings, W. and P. Zimmermann, "PGP + Message Exchange Formats", RFC 1991, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [SP800-57] NIST Special Publication 800-57, Recommendation on Key Management