INTERNET-DRAFT Gail Haspert Security PGP, Inc. Expires in six months Editor July 30 1997 PGP Message Exchange Formats Status of this Memo This document is an Internet-Draft. 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." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). In order to release information about PGP 5.x prior to the Birds of a Feather discussion at the 39th IETF Conference in Munich, we wanted people to have the opportunity to review the current specification of the published PGP source code. This document is the cookbook for the source code. Completion of items marked TBD will be done by end of October, 1997. Abstract PGP (Pretty Good Privacy) software uses a combination of public-key and conventional encryption to provide strong security services for e-mail, EDI, and data files. These services include confidentiality, authorization, authentication and digital signature. This document specifies the message formats used in version 5.x, fully backward- compatible with earlier PGP versions. Since PGP first became available in 1991, it is now the worldwide de facto standard for securing electronic communications. It has achieve this success through international availability and the unique distributed "Web-of-Trust" model to create the current PGP Public Key Infrastructure for storing and obtaining 'PGP-formatted-certificates.' PGP Formats - Open PGP BOF Page 1 Table of Contents 1. Introduction......................................3 2. PGP Services......................................3 2.1 Digital signature.................................3 2.2 Confidentiality...................................4 2.3 Compression.......................................4 2.4 Radix-64 conversion...............................4 2.4.1 ASCII Armor Formats...............................5 3. Data Element Formats..............................6 3.1 Scalar numbers....................................6 3.2 Multi-Precision Integers..........................6 3.3 Strings...........................................7 3.4 Time fields.......................................7 4. Packets...........................................7 4.1 Overview..........................................7 4.2 Packet Headers....................................7 4.3 Packet Tags.......................................8 5. Packet Types......................................9 5.1 Encrypted Session Key Packets.....................9 5.2 Conventional Encrypted Session-Key Packets........9 5.3 One-Pass Signature Packets........................9 5.4 Symmetrically Encrypted Data Packet..............10 5.5 Compressed Data Packet...........................10 5.6 Literal Data Packet..............................10 5.7 Obsolete Literal Packet..........................11 5.8 Key Material Packet..............................11 5.9 User-Name Packet.................................12 5.10 Signature Packets................................12 6. Constants........................................13 6.1 Public Key Algorithms............................13 6.2 Symmetric Key Algorithms.........................13 6.3 Compression Algorithms...........................13 6.4 Hash Algorithms..................................13 7. Transferable Public Keys.........................13 8. PGP 5.0 Enhanced Key Formats.....................14 8.1 Key Structures...................................14 8.2 Public Key Certificate Packet Structure..........15 8.3 Signature Packet Structure.......................16 8.4 Diffie-Hellman/DSS Key IDs and Fingerprints......18 8.5 New Algorithm and Signature Classification Types.18 8.6 Interoperability.................................18 8.7 Future Formats...................................19 PGP Formats - Open PGP BOF Page 2 1. Introduction This document provides information on the message-exchange packet formats used by PGP to provide encryption, decryption, and signing functions. It builds on the foundation provided RFC 1991, PGP Message Exchange Formats and RFC 2015, MIME Security with Pretty Good Privacy (PGP). PGP and is the collective work of a number of contributing authors. Those authors include, (alphabetical order): Derek Atkins, Charles Breed, Jon Callas, Dave Del Torto, Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Raph Levine, Colin Plumb, Will Price, William Stallings, Mark Weaver, and Philip R. Zimmermann. A special thank you goes to Paul Hoffman for hosting and managing the mail lists for PGP.PGP (Pretty Good Privacy) uses a combination of public-key and conventional encryption to provide security services for electronic mail messages, electronic data interchange (EDI) and data files. These services include confidentiality and digital signature. PGP is widely used throughout the global computer community. This document describes the format of "PGP files", i.e., messages that have been encrypted and/or signed 1991. Subsequent versions have been designed and implemented by a combination of volunteers and PGP, Inc. in a collaborative effort under the design guidance of Philip Zimmermann. PGP and Pretty Good Privacy are trademarks of Pretty Good Privacy, Inc. 2. PGP Services PGP provides four services related to the format of messages and data files: -digital signature -encryption -compression -radix-64 conversion 2.1 Digital signature The digital signature uses a hash code or message digest algorithm, and a public-key encryption algorithm. The sequence is as follows: 1. The sender creates a message 2. The sending PGP generates a hash code of the message 3. The sending PGP encrypts the hash code using the sender's private key. 4. The encrypted hash code is prepended to the message 5. The receiving PGP decrypts the hash code using the sender's public key. 6. The receiving PGP generates a new hash code for the received message and compares it to the decrypted hash code. If the two match, the message is accepted as authentic. PGP Formats - Open PGP BOF Page 3 2.2 Confidentiality PGP provides confidentiality by encrypting messages to be transmitted or data files to be stored locally using conventional encryption. In PGP, each conventional key is used only once. That is, a new key is generated as a random 128-bit number for each message. Since it is to be used only once, the session key is bound to the message and transmitted with it. To protect the key, it is encrypted with the receiver's public key. The sequence is as follows: 1. The sender creates a message. 2. The sending PGP generates a random number to be used as a session key for this message only. 3. The sending PGP encrypts the message using the session key. 4. The session key is encrypted using the recipient's public key and is prepended to the encrypted message. 5. The receiving PGP decrypts the session key using the recipient's private key. 6. The receiving PGP decrypts the message using the session key. Both digital signature and confidentiality services may be applied to the same message. First, a signature is generated for the message and prepended to the message. Then, the message plus signature is encrypted using a conventional session key. Finally, the session key is encrypted using public-key encryption and prepended to the encrypted block. 2.3 Compression As a default, PGP compresses the message after applying the signature but before encryption. 2.4 Radix-64 conversion When using PGP to sign clear text, or to encrypt and/or sign a message a resulting encrypted block must either accompany or travel in place of the message block. Thus, part or all of the resulting block consists of a stream of arbitrary octets. Many electronic mail systems only permit the use of blocks consisting of ASCII text. To accommodate this restriction, PGP provides the service of converting the raw 8-bit binary octet stream to a stream of printable ASCII characters, called Radix-64 encoding or ASCII Armor. Similar to MIME encoding, the process of Radix-64 encoding an 8-bit binary stream of data is as follows. Every three subsequent 8 bit binary octets are mapped into four subsequent 6-bit ASCII characters. Radix-64 encoding also appends a CRC to detect transmission errors. This radix-64 conversion, is a wrapper around the binary PGP messages, and is used to protect the binary messages during transmission over non-binary channels, such as Internet Email. The following table defines the mapping. The characters used are the upper- and lower-case letters, the digits 0 through 9, and the characters + and /. The carriage-return and linefeed characters aren't used in the conversion, nor is the tab or any other character that might be altered by the mail system. The result is a text file that is "immune" to the modifications inflicted by mail systems. PGP Formats - Open PGP BOF Page 4 To encode an arbitrary 3 octets, separate the bit stream logically into four 6-bit groups, calculate the decimal value of the 6-bit group, and replace it with the corresponding character from the table below. Decoding is the exact opposite operation. 6-bit Value Mapped to Character Encoding 6-bit character 6-bit character 6-bit character 6-bit character value encoding value encoding value encoding value encoding 0 A 16 Q 32 g 48 w 1 B 17 R 33 h 49 x 2 C 18 S 34 i 50 y 3 D 19 T 35 j 51 z 4 E 20 U 36 k 52 0 5 F 21 V 37 l 53 1 6 G 22 W 38 m 54 2 7 H 23 X 39 n 55 3 8 I 24 Y 40 o 56 4 9 J 25 Z 41 p 57 5 1 K 26 a 42 q 58 6 11 L 27 b 43 r 59 7 12 M 28 c 44 s 60 8 13 N 29 d 45 t 61 9 14 O 30 e 46 u 62 + 15 P 31 f 47 v 63 / (pad) = Hex octet 0x17 0x3A 0xA3 Example: Binary stream 00010111 00111010 10100011 Translate to 6bit 000101 110011 101010 100011 Decimal 5 51 42 35 Final Character F z q j It is possible to use PGP to convert any arbitrary file to ASCII Armor. When this is done, PGP tries to compress the data before it is converted to Radix-64. 2.4.1 ASCII Armor Formats When PGP encodes data into ASCII Armor, it puts specific headers around the data, so PGP can reconstruct the data at a future time. PGP tries to inform the user what kind of data is encoded in the ASCII armor through the use of the headers. ASCII Armor is created by concatenating the following data: - An Armor Headerline, appropriate for the type of data - Armor Headers - A blank line - The ASCII-Armored data - An Armor Checksum - The Armor Tail, which depends on the Armor Headerline. PGP Formats - Open PGP BOF Page 5 An Armor Headerline is composed by taking the appropriate headerline text surrounded by five (5) dashes (-) on either side of the headerline text. The headerline text is chosen based upon the type of data that is being encoded in Armor, and how it is being encoded. Headerline texts include the following strings: BEGIN PGP MESSAGE -- used for signed, encrypted, or compressed files BEGIN PGP PUBLIC KEY BLOCK -- used for transferring public keys BEGIN PGP MESSAGE, PART X/Y -- used for multi-part messages, where the armor is split amongst Y files, and this is the Xth file out of Y. The Armor Headers are pairs of strings that can give the user or the receiving PGP message block 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 should not be used to convey any important information, since they can be changed in transport. The format of an Armor Header is that of a key-value pair. PGP should consider improperly formatted Armor Headers to be corruption of the ASCII Armor. Unknown keys should be reported to the user, but PGP should continue to process the message. Currently defined Armor Header Keys include "Version" and "Comment," which define the PGP Version used to encode the message and a user-defined comment. The Armor Checksum is a 24-bit CRC converted to four characters of radix-64 encoding, prepending an equal-sign (=) to the four character code. 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. For more information on CRC functions, the reader is asked to look at chapter 19 of the book "C Programmer's Guide to Serial Communications," by Joe Campbell. The Armor Tail is composed in the same manner as the Armor Headerline, except the string "BEGIN" is replaced by the string "END." 3. Data Element Formats This section describes the data elements used by PGP. 3.1 Scalar numbers Scalar numbers are unsigned, and are always stored in big-endian format. Thus, the value of a two-octet scalar is ((n[0] << 8) + n[1]). The value of a four-octet scalar is ((n[0] << 24) + (n[1] << 16) + (n[2] << 8) + n[3]). 3.2 Multi-Precision Integers Multi-Precision Integers (also called MPIs) are unsigned integers used to hold large integers such as ones used in cryptographic calculations. An MPI consists of two pieces: a two-octet scalar that is the length of the MPI in bits followed by a string of octets that contain the actual integer. These octets form a big-endian number; a big-endian number can be made into an MPI by prefixing it with the appropriate length. PGP Formats - Open PGP BOF Page 6 Examples: (all numbers are in hexadecimal) The string of octets [00 01 01] forms an MPI that has a value of 1. The string [00 09 01 ff] forms an MPI with the value of 511. Additional rules: The size of an MPI is ((MPI.length + 7) / 8) + 2. The length field of an MPI describes the length starting from its most significant non-zero bit. Thus, the MPI [00 02 01] is not formed correctly. It should be [00 01 01]. 3.3 Strings A string consists of a one-octet length and then N octets of string data. 3.4 Time fields A time field is a four-octet number containing the number of seconds elapsed since midnight, 1 January 1970 GMT. 4. Packets This section describes the packets used by PGP. 4.1 Overview A packet is a chunk of data that has a tag specifying its meaning. A PGP message, keyring, certificate, and so forth consists of a number of packets. Some of those packets may contain other PGP packets (for example, a compressed data packet, when uncompressed, contains PGP packets). Each packet consists of a packet header, followed by the packet body. The packet header is of variable length. 4.2 Packet Headers The first octet of the packet header is called the "Cipher Type Byte." It determines the format of the header. Its high-order bit (0x80) must be set. If the next bit (0x40) is set, it is a new format packet. If it is clear, then it is an old format packet. New format packets can only be decoded by PGP V5.0 or later. Thus, software that needs to be compatible with earlier versions of PGP must only use old format packets. In an old format packet, the packet tag resides in the middle four bits ((ctb & 0x3c) >> 2). The two low order bits (ctb & 0x3) denote the number of octets following the CTB that hold the length of the packet body. The meaning of the length-type is: PGP Formats - Open PGP BOF Page 7 0 - The packet has a one-octet length. The header is 2 octets long. 1 - The packet has a two-octet length. The header is 3 octets long. 2 - The packet has a four-octet length. The header is 5 octets long. 3 - The packet is of indeterminate length. The header is 1 byte long, and the application must determine how long the packet is. If the packet is in a file, this means that the packet extends until the end of the file. In general, an application should not use indeterminate length packets. In a new format packet, the low-order six bits (cth & 0x3f) form the packet tag. The length of the packet is found in the next one or two octets, thus: If the next octet is 191 or less, then that is the length of the packet body. If that octet is between 192 and 223, then the length of the packet body is held in the two octets following the CTB with the following formula: bodyLen = ((p[1] - 192) * 256) + p[2] + 192; Note that this yields a maximum packet body length of 8383 octets for this type of packet. If the second octet is 224 or greater (note that 224 is E0 in hexadecimal, or 11100000 in binary), then the low-order five bits form the length of the packet body with the formula: bodyLen = 1 << (p[1] & 0x1f); In English, the packet body length is a power of two. Its maximum length is 2**31 octets long. Note that there is no way to form a new-format packet that is longer than 8383 octets and not a power of two in length. Please note that in all of these explanations, the total length of the packet is the length of the header 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 packets can only have tags less than 16, whereas new format packets can have tags as great as 63. The defined tags are: 0 -- Reserved. A packet must not have a tag with this value. 1 -- Encrypted Session Key Packet 2 -- Signature Packet 3 -- Conventionally Encrypted Session Key Packet 4 -- One-Pass Signature Packet 5 -- Secret Key Packet 6 -- Public Key Packet 7 -- Secret Subkey Packet 8 -- Compressed Data Packet 9 -- Symmetrically Encrypted Data Packet 10 -- Obsolete Literal Packet 11 -- Literal Data Packet 12 -- Trust Packet 13 -- Name Packet PGP Formats - Open PGP BOF Page 8 14 -- Subkey Packet 15 -- Reserved 16 -- Comment Packet 5.0 Packet Types This section describes some of the more interesting packet types. 5.1 Encrypted Session Key Packets The encrypted session key packet (tag 1) describes how a message is encrypted. One or more of these packets precede a Symmetrically Encrypted Data Packet, for each PGP key the message is encrypted to. 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, either 2 or 3. All modern versions of PGP generate type 3 packets. - - An eight-octet number that gives the ID of the public key that the session key is encrypted to. - A one-octet number giving the public-key algorithm used. - - A string of octets that is the encrypted session key. This string takes up the remainder of the packet, but is not explicitly counted. 5.2 Conventional Encrypted Session-Key Packets This packet (tag 3) describes a session key that has been encrypted to a secondary symmetric cipher. This allows a message to be encrypted to a number of public keys, and also to one or more pass phrases. This packet type is new, and is not generated by PGP 2.x or PGP 5.0. The body of this packet consists of: - A one-octet version number. The current version is 4. - A one-octet number describing the symmetric algorithm used. - A "string-to-key" object. This is described below. It is 2, 10, or 11 octets long. - The encrypted session key itself, which is decrypted with the string-to-key object. The string-to-key object has this format: 5.3 One-Pass Signature Packets This packet (tag 4) is also a new packet type, but may be generated by PGP 5.0 or later. This in an in-line packet that tells the processing software how to compute a signature so that it does not have to read the entire message before starting. PGP Formats - Open PGP BOF Page 9 The body of this packet consists of: - A one-octet version number. The current version is 3. - A one-octet signature type. Signature types are described later in this document. - A one-octet number describing the hash algorithm used. - A one-octet number describing the public key algorithm used. - An eight-octet number holding the key ID of the signing key. - A one-octet number holding a flag showing if the signature is nested. 5.4 Symmetrically Encrypted Data Packet This packet (tag 9) contains encrypted data. When it has been decrypted, it will typically contain other packets (often literal data packets or compressed data packets). The body of this packet consists of: - Eight octets of initialization data. This is arbitrarily chosen material that starts the encryption engine. This serves a similar purpose to an initialization vector in a cipher-block- chaining engine. It helps to reduce the chance of information leaks caused by known-plaintext attacks. - - Two octets of data that are used to check the decryption process. The seventh and eighth octets of decrypted data must match these two octets. - The remainder of the packet is encrypted data. 5.5 Compressed Data Packet This packet (tag 8) contains compressed data. Typically, this packet is found as the contents of an encrypted packet, and contains literal data packets. The body of this packet consists of: - One octet that gives the algorithm used to compress the packet. - The remainder of the packet is compressed data. 5.6 Literal Data Packet A literal data packet (tag 11) 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. If it is a 'b' (0x62), then the literal packet contains binary data. If it is 't' (0x74), then it contains text data, and thus may need line ends converted to local form, or other text-mode changes (similar to FTP's text mode). RFC 1991 also defines a 'local' mode for machine-local conversions, but does not define it. Curiously, it specifies that the character for it is '1' (numeral one) (which this author thinks might be a typo for 'l' (lower-case ell), and does not give its hexadecimal equivalent. - A counted string giving a file name. - - A four-octet number that indicates the modification date of the file, or the creation time of the packet, or a zero that indicates the present time. - The remainder of the packet is literal data. PGP Formats - Open PGP BOF Page 10 5.7 Obsolete Literal Packet An experimental version of PGP used this packet (tag 10) 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 a marker packet. PGP 5.x makes a packet and puts it at the start of a message that mixes RSA and DSS keys, so that PGP 2.x will recognize it as a legal PGP message, but one that it is not equipped to decode. You may use these packets for similar purposes, and should ignore any you find. The packet that PGP 5.x uses contains three octets of data, holding the string "PGP." 5.8 Key Material Packet A key material packet contains all the information about a public or private key. There are four variants of this packet type, and two major versions. Consequently, this section is complex. A public-key packet (tag 6) starts a series of packets that forms a PGP certificate (or PGP key, as it is commonly known). A subkey packet (tag 14) has exactly the same format, but denotes a subkey. If it had the same tag, then it would be impossible to tell a subkey from the start of another certificate. A secret-key packet (tag 5) contains all the information that is found in a public key packet, including the public key material, but also includes the secret key material after all the public-key fields. As you would expect, a secret subkey packet (tag 7) is the secret-key analog of the secret key packet, and has exactly the same format. There are two versions of key-material packets. Version 3 packets are PGP 2.6 packets. Version 2 packets are identical in format to Version 3 packets, but are generated by PGP 2.5 or before. This document hereafter ignores them. PGP 5.0 introduces version 4 packets, with new fields and semantics. PGP 5.x uses version 3 packets for RSA keys, and version 4 packets for DSS/DH keys. Note that there is no reason that there cannot be a V4 RSA key (except that it is not compatible with previous versions of PGP), nor a reason that there cannot be a V3 DSS key. A version 3 packet contains: - A one-octet version number. - 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. An RSA key has two MPIs: the RSA public modulus (n), followed by the public exponent (e). A Diffie-Hellman key has three MPIs: the prime (p), the generator (g), and the public key (k). A DSS key has four MPIs: the prime (p), the group order (o), the generator(g), and the public key (k). PGP Formats - Open PGP BOF Page 11 The fingerprint of the key is formed by hashing the body (but not the two-octet length) of the MPIs that form the key material with MD5. The eight-octet key ID of the key is formed by taking the low 64 bits of the public modulus of an RSA key. Note that no released version of PGP has created a V3 key with any other public key algorithm other than RSA. PGP 5 still generates its RSA keys in V3 format to ensure interoperability with V2.x. Since the release of PGP 2.6, there have been a number of improvements desired in the key format. For example, making the key id be a function of the public modulus makes it easy for a person to purposely create a key that has the same key id as some existing key. Similarly, MD5 is no longer the preferred hash algorithm, and not hashing the length of an MPI with its body increases the chances of a fingerprint collision. The version four packet format is similar to the V3 format except for the following changes: - There is no validity period field. - The fingerprint is constructed by taking the SHA-1 hash of . - The key ID is the low 64 bits of the fingerprint. 5.9 User-Name Packet A user-name packet is a counted string with a one-octet length. By convention, it is an RFC 822 mail name, but there are no restrictions on its content. 5.10 Signature Packets 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 name. There are a number of meanings of a signature, which are specified in a signature-type octet in any given signature. These meanings are: - 0x00: Signature of a binary document. Typically, this means the signer owns it, created it, or certifies that it has not been modified. - 0x01: Signature of a canonical text document. Typically, this means the signer owns it, created it, or certifies that it has not been modified. - 0x10: The generic certification of a user name 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 name. Note that all PGP "key signatures" are this type of certification. - - 0x11: This is a persona certification of a user name and public-key packet. It means that the issuer of this certification has not done any verification of the claim that the owner of this key is the user name specified. Note that no released version of PGP has generated this type of certification. PGP Formats - Open PGP BOF Page 12 - - 0x12: This is the casual certification of a user name and public-key packet. It means that the issuer of this certification has done some casual verification of the claim of identity. Note that no version of PGP has generated this type of certification, nor is there any definition of what constitutes a casual certification. - - 0x13: This is the positive certification of a user name and public-key packet. It means that the issuer of this certification has done substantial verification of the claim of identity. Note that no version of PGP has generated this type of certification, nor is there any definition of what constitutes a positive certification. Please also note that the vagueness of these certification systems is not a flaw, but a feature of the system. Because PGP 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. SigSubkeyCert = 0x18, SigKRev = 0x20, SigSubkeyRev = 0x28, SigKSRev = 0x30, SigTimeStamp = 0x40 6. Constants This section describes the constants used in PGP Version 5.x. 6.1 Public Key Algorithms 1 - RSA 16 - Diffie-Helman, El Gamal variant 17 - DSS (Digital Signature Algorithm) 6.2 Symmetric Key Algorithms 0 - Plaintext 1 - IDEA 2 - Triple-DES (DES-EDE, 168 bit key) 3 - CAST5 (128 bit key) 6.3 Compression Algorithms 0 - Uncompressed 1 - ZIP 6.4 Hash Algorithms 1 - MD5 2 - SHA-1 ? - RIPE-MD/160 7. Transferable Public Keys Public keys may transferred between PGP users. The essential elements of a transferable public key are: PGP Formats - Open PGP BOF Page 13 (a) One public-key packet (b) One or more user-ID packets (c) Zero or more signature packets The public-key packet occurs first. Each of the following user ID 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 enjoy the use of more than one e-mail address, and construct a user-ID packet 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 belief that this public key belongs to the user identified by this user ID. 8. PGP 5.0 Enhanced Key Formats With PGP 5.0, a more flexible PGP key format was introduced. The new key format allows for two new features. One is the ability to support a key that has one public key to do authentication and a second to do encryption. The other new feature is the ability to easily expand the signature packets. Currently, both authentication and encryption are done using the RSA public key cryptosystem. The RSA algorithm uses a single public/private key pair to perform both operations. The existing PGP key format only supports algorithms that digitally sign and encrypt with a single key. The enhanced key format supports algorithms that can use a different key pair for each operation. The first example of this new flexibility is PGP 5.0's support of keys that use NIST's Digital Signature Standard (DSS) for digital signatures and the ElGamal variation of Diffie-Hellman for encryption and decryption. PGP 5.0 continues to support both the RSA algorithm and the existing PGP key format when used with RSA. The new signature packet (version 4) includes subpackets to easily add new attributes to a signature. Further, two types of subpackets exist; a group of subpackets that is included in the hash used by the signature and a group that is not. The subpackets can be either attributes of the signature packet, or they can be an assertion by the signer about the key being signed. Currently, this new format is only generated for signatures on Diffie-Hellman/DSS keys. This prevents any backward compatibility problems since all RSA keys still use version 3 signatures and all software that supports Diffie-Hellman/DSS also supports the new signature packets. 8.1 Key Structures The format of an existing PGP key using RSA is as follows. Entries in square brackets are optional and ellipses indicate repetition. PGP Formats - Open PGP BOF Page 14 RSA Public Key [Revocation Self Signature] UserID [Signature ...] [UserID [Signature ...] ...] Each signature certifies the RSA public key and the preceding UserID. The RSA public key can have many UserIDs and each UserID can have many signatures. The format of the new PGP key type that requires two public keys is very similar except that the second key is added to the end as a 'subkey' of the primary key. Primary-Key [Revocation Self Signature] UserID [Signature ...] [UserID [Signature ...] ...] [Subkey Primary-Key-Signature] The subkey always has a single signature after it that is issued using the primary key to tie the two keys together. The new format can use either the new signature packets or the existing signature packets. In a Diffie-Hellman/DSS key, the DSS public key is the primary key, the Diffie-Hellman public key is the subkey, and either version 3 or 4 of the signature packet can be used. 8.2 Public Key Certificate Packet Structure To accommodate the addition of the subkey construction, a new version of the public-key-certificate packet was created. Packets with a version of '3' are still created for PGP keys that use RSA public keys. For specifics on version 3 packets, see RFC 1991. The terms and formatting used here are consistent with that RFC. A Cipher Type Byte (CTB) with bits 5-2 of 0110 indicates a primary public-key-certificate packet. This can be either an existing RSA key with a packet version of 3 or a DSS key with a version of 4. A new packet type is now defined for the subkey. The CTB of the subkey packet has bits 5-2 of 1110. Notice that this used to indicate a comment packet. These packet-type bits were selected because no previous version of PGP ever emitted comment packets but they did properly ignore them. This provides some backwards compatibility with existing PGP implementations. Below are the complete definitions for the primary and subkey public key packets. Support for RSA and Diffie-Hellman/DSS keys is described. RSA Public Key Certificate Packet ("old format") a) packet structure field with CTB bits 5-2 = 0110 (2 or 3 bytes); b) version number = 3 (1 byte); c) time stamp of key creation (4 bytes); d) validity period in days (0 means forever) (2 bytes); PGP Formats - Open PGP BOF Page 15 e) algorithm (1 byte): 1 = RSA, f) Algorithm specific fields. Algorithm Specific Fields for RSA keys: f.1) multiprecision integer (MPI) of RSA public modulus n; f.2) MPI of RSA public encryption exponent e. New Public Key Certificate Packet a) packet structure field with (2 or 3 bytes): Bits 5-2 of CTB = 0110 means primary key packet, Bits 5-2 of CTB = 1110 means subkey packet; b) version number = 4 (1 byte); c) time stamp of key creation (4 bytes); e) algorithm (1 byte): 1 = RSA (not presently generated), 16 = Diffie-Hellman, 17 = DSS; f) Algorithm specific fields. Algorithm Specific Fields for DSS keys: f.1) MPI of DSS prime p; f.2) MPI of DSS group order q (q is a prime divisor of p-1); f.3) MPI of DSS group generator g; f.4) MPI of DSS public key value y (= g**x where x is secret). Algorithm Specific Fields for Diffie-Hellman keys: f.1) MPI of Diffie-Hellman prime p; f.2) MPI of Diffie-Hellman group generator g; f.3) MPI of Diffie-Hellman public key value y (= g**x where x is secret). 8.3 Signature Packet Structure Version 4 of the signature packet adds the concept of hashed and non-hashed subpackets. Since this version is not recognized by previous versions of PGP, it is currently only being generated in conjunction with version 4 public-key-certificate packets (i.e., Diffie-Hellman/DSS PGP keys). NOTE: The order and contents of the data that is hashed in a version 4 signature packet needs further detail. Here is the specification of a version 4 signature packet: a) packet structure field with CTB with bits 5-2 = 0010 (2 or 3 bytes); b) version number = 4 (1 byte); c) signature classification (hashed) (1 byte); d) public key algorithm (hashed) (1 byte): 1 = RSA (not presently generated), 16 = Diffie-Hellman, 17 = DSS; PGP Formats - Open PGP BOF Page 16 e) hash algorithm (hashed) (1 byte): 1 = MD5, 2 = SHA; f) length of hashed subpacket data (hashed) (2 bytes); g) hashed subpacket data (hashed) (f bytes): - signature creation time, - key expiration time, - preferred symmetric encryption algorithms; h) length of non-hashed subpacket data (2 bytes); i) non-hashed subpacket data (h bytes): - signer key ID; j) first 2 bytes of message digest (16 bit checksum); k) MPI of public key signature l) MPI #2 of public key signature (for DSS signatures only) Fields g) and i) consist of signature subpackets. Below is the specification of signature subpackets. The list of subpackets may grow in the future. Unrecognized packets should be skipped unless marked as critical. a) subpacket length (1 or 2 bytes): Length includes the type byte but not this length, 1st byte < 192, then length is one byte, 1st byte >= 192, then length is 2 bytes and equal to (1st byte & 0x3F) * 256 + (2nd byte) + 192; b) subpacket type (1 byte): If bit 7 is set, subpacket understanding is critical, 2 = signature creation time, 9 = key expiration time, 11 = preferred symmetric algorithms, 16 = key ID of signer, c) subpacket specific data (b bytes); Several types of subpackets are currently defined. Some subpackets apply to the signature itself and some are attributes of the key. Signature creation time (4 byte time field) (Hashed) The time the signature was made. Always included with new signatures. Key ID of signer (8 byte key ID) (Non-hashed) The PGP key ID of the person signing the key. Key expiration time (4 byte time field) (Hashed) The validity period of the key. This is the number of seconds after the key creation time that the key expires. If this is not present or has a value of zero, the key never expires. This is found on a self-signature. Preferred symmetric algorithms (array of 1 byte) (Hashed) Symmetric algorithm numbers that indicate which algorithms the key holder prefers to use. This is an ordered list of bytes with the most preferred listed first. It should be assumed that only algorithms listed are supported by the recipient's software. Algorithm numbers are provided below. If this subpacket is not included, IDEA is assumed. This is found on a self-signature. PGP Formats - Open PGP BOF Page 17 8.4 Diffie-Hellman/DSS Key IDs and Fingerprints A Diffie-Hellman/DSS fingerprint is the 160-bit SHA-1 hash of a few header bytes followed by the entire public key packet starting with the version field. The key ID is either the low order 32 bits or 64 bits of the fingerprint. Here are the fields of the hash material: a.1) 0x99 (1 byte) a.2) high order length byte of (b)-(f) (1 byte) a.3) low order length byte of (b)-(f) (1 byte) b) version number = 4 (1 byte); c) time stamp of key creation (4 bytes); e) algorithm (1 byte): 17 = DSS; f) Algorithm specific fields. Algorithm Specific Fields for DSS keys: f.1) MPI of DSS prime p; f.2) MPI of DSS group order q (q is a prime divisor of p-1); f.3) MPI of DSS group generator g; f.4) MPI of DSS public key value y (= g**x where x is secret). 8.5 New Algorithm and Signature Classification Types Several new algorithm types were added to support Diffie-Hellman/DSS keys. Below are the new public-key-encryption algorithm numbers: Diffie-Hellman 16 DSS 17 DSS uses a different message digest algorithm, the Secure Hash Algorithm (SHA-1). This is the only message-digest-algorithm number added: SHA-1 2 Below are the preferred symmetric algorithm numbers: IDEA 1 (not new) Triple DES 2 CAST5 3 A single new signature classification was added for the signature packet that ties the subkey to the primary key. Subkey Signature 24 8.6 Interoperability Starting with PGP 5.0, PGP's products support this new format and the sending and receiving of mail protected using either RSA or Diffie-Hellman/DSS keys. A keyring can contain both types of keys and you can send a piece of mail to people with either key type. PGP Formats - Open PGP BOF Page 18 Users of previous versions of PGP cannot accept keys that use Diffie-Hellman/DSS. PGP is releasing patches for most versions that provide some support for Diffie-Hellman/DSS keys. The patches allow prior versions to interoperate better with Diffie-Hellman/DSS keys. The patched versions still do not support generating Diffie-Hellman/DSS keys or usingthem to send or receive encrypted mail. 8.7 Future Formats Additional information on PGP formats is being provided to the public in order for others to build compatible or complimentary systems that support PGP. PGP Formats - Open PGP BOF Page 19