Network Working Group Jon Callas Category: INTERNET-DRAFTPretty Good Privacy draft-ietf-openpgp-formats-00.txtNetwork Associates draft-ietf-openpgp-formats-01.txt Lutz Donnerhacke ExpiresMayAug 1998 IN-Root-CA Individual Network e.V.NovemberMarch 1997 Hal FinneyPretty Good PrivacyNetwork Associates Rodney Thayer Sable Technology OP Formats - OpenPGP Message Formatdraft-ietf-openpgp-formats-00.txtdraft-ietf-openpgp-formats-01.txt Copyright19971998 by The Internet Society. All Rights Reserved. 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 useInternet-DraftsInternet- Drafts as reference material or to cite them other than as "work in progress." Tolearnview thecurrent statusentire list ofany Internet-Draft,current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa),nic.nordu.net (Europe),ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),ds.internic.netftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OP format. It is not a step-by-step cookbook for writing an application, it describes only the format and methods needed to read, check, generate and write conforming packets crossing any network. It does not deal with storing and implementation questions albeit it is necessary to avoid security flaws.OP (Open-PGP)Open-PGP software uses a combination of strong public-key and conventional cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication and digital signatures. This document specifies the message formats used in OP. Table of Contents 1. Introduction 1.1 Terms 2. General functions 2.1 Confidentiality via Encryption 2.2 Authentication via Digital signature 2.3 Compression 2.4 Conversion to Radix-642.4.1 Forming ASCII Armor 2.4.2 Encoding Binary in Radix-64 2.4.3 Decoding Radix-64 2.4.4 Examples of Radix-64 2.5 Example of an ASCII Armored Message 2.6 Cleartext signature framework 3.03. Data Element Formats 3.1 Scalar numbers 3.2 Multi-Precision Integers 3.3Counted StringsKey IDs 3.4 Text 3.5 Time fields3.53.6 String-to-key (S2K) specifiers3.5.13.6.1 String-to-key (S2k) specifier types3.5.1.13.6.1.1 Simple S2K3.5.1.23.6.1.2 Salted S2K3.5.1.33.6.1.3 Iterated and Salted S2K3.5.23.6.2 String-to-key usage3.5.2.13.6.2.1 Secret key encryption3.5.2.23.6.2.2 Conventional message encryption3.5.33.6.3 String-to-key algorithms3.5.3.13.6.3.1 Simple S2K algorithm3.5.3.23.6.3.2 Salted S2K algorithm3.5.3.33.6.3.3 Iterated-Salted S2K algorithm4.04. Packet Syntax 4.1 Overview 4.2 Packet Headers 4.3 Packet Tags5.05. Packet Types 5.1 Public-Key Encrypted Session Key Packets (Tag 1) 5.2 Signature Packet (Tag 2) 5.2.1 Version 3 Signature Packet Format 5.2.2 Version 4 Signature Packet Format 5.2.2.1 Signature Subpacket Specification 5.2.2.2 Signature Subpacket Types 5.2.3 Signature Types 5.2.4 Computing Signatures 5.3ConventionalSymmetric-Key Encrypted Session-Key Packets (Tag 3) 5.4 One-Pass Signature Packets (Tag 4) 5.5 Key Material Packet 5.5.1 Key Packet Variants 5.5.1.1 Public Key Packet (Tag 6) 5.5.1.2 Public Subkey Packet (Tag 14) 5.5.1.3 Secret Key Packet (Tag 5) 5.5.1.4 Secret Subkey Packet (Tag 7) 5.5.2 Public Key Packet Formats 5.5.3 Secret Key Packet Formats 5.6 Compressed Data Packet (Tag 8) 5.7 Symmetrically Encrypted Data Packet (Tag 9) 5.8 Marker Packet (Obsolete Literal Packet) (Tag 10) 5.9 Literal Data Packet (Tag 11) 5.10 Trust Packet (Tag 12) 5.11 User ID Packet (Tag 13)5.12 Comment Packet (Tag 16)6.ConstantsRadix-64 Conversions 6.1 An Implementation of the CRC-24 in "C" 6.2 Forming ASCII Armor 6.3 Encoding Binary in Radix-64 6.4 Decoding Radix-64 6.5 Examples of Radix-64 6.6 Example of an ASCII Armored Message 7. Cleartext signature framework 8. Regular expressions 9. Constants 9.1 Public Key Algorithms6.29.2 Symmetric Key Algorithms6.39.3 Compression Algorithms6.49.4 Hash Algorithms7.10. Packet Composition7.110.1 Transferable Public Keys7.210.2 OP Messages8.11. Enhanced Key Formats8.111.1 Key Structures8.411.2 V4 Key IDs and Fingerprints9.12. Security Considerations10.13. Authors and Working Group Chair11.14. References12.15. Full Copyright Statement 1. Introduction This document provides information on the message-exchange packet formats used by OP to provide encryption, decryption, signing, key management and functions. It builds on the foundation provided RFC 1991 "PGP Message ExchangeFormats" [1].Formats." 1.1 Terms OP - OpenPGP. This is a definition for security software that uses PGP 5.x as a basis. PGP - Pretty Good Privacy. PGP is a family of software systems developed by Philip R. Zimmermann from which OP is based. PGP 2.6.x - This version of PGP has many variants, hence the term PGP 2.6.x. It used only RSA and IDEA for its cryptography. PGP 5.x - This version of PGP is formerly known as "PGP 3" in the community and also in the predecessor of this document, RFC1991. It has new formats and corrects a number of problems in the PGP 2.6.x. It is referred to here as PGP 5.x because that software was the first release of the "PGP 3" code base. "PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks ofPretty Good Privacy,Network Associates, Inc. 2. General functions OP provides data integrity services for messages and data files by using these core technologies: -digital signature -encryption -compression -radix-64 conversion In addition, OP provides key management and certificate services. 2.1 Confidentiality via Encryption OP offers two encryption options to provide confidentiality: conventional (symmetric-key) encryption and public key encryption. With public-key encryption, the message is actually encrypted using a conventional encryption algorithm. In this mode, each conventional key is used only once. That is, a new key is generated as a random number for each message. Since it is 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 OP generates a random number to be used as a session key for this message only. 3. The session key is encrypted using each recipient's public key. These "encrypted session keys" start the message. 4. The sending OP encrypts the message using the session key, which forms the remainder of the message. Note that the message is also usually compressed. 5. The receiving OP decrypts the session key using the recipient's private key. 6. The receiving OP decrypts the message using the session key. If the message was compressed, it will be decompressed. Both digital signature and confidentiality services may be applied to the same message. First, a signature is generated for the message and attached 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.2 Authentication via Digital signature The digital signature uses a hash code or message digest algorithm, and a public-key signature algorithm. The sequence is as follows: 1. The sender creates a message. 2. The sending software generates a hash code of the message 3. The sending software generates a signature from the hash code using the sender's private key. 4. The binary signature is attached to the message. 5. The receiving software keeps a copy of the message signature. 6. The receiving software generates a new hash code for the received message and verifies it using the message's signature. If the verification is successful, the message is accepted as authentic. 2.3 Compression OP implementations MAY compress the message after applying the signature but before encryption. 2.4 Conversion to Radix-64 OP's underlying native representation for encrypted messages, signature certificates, and keys is a stream of arbitrary octets. Some systems only permit the use of blocks consisting of seven-bit, printable text. For transporting OP's native raw binary octets throughemail channels,channels that are not safe to raw binary data, a printable encoding of these binary octets is needed. OP 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.In principle, any printable encoding schemeImplementations SHOULD provide Radix-64 conversions. Note thatmet the requirements of the email channel would suffice, since it would not change the underlying binary bit streams ofmany applications, particularly messaging applications, will want more advanced features as described in thenativeOpenPGP-MIME document, RFC2015. An application that implements OP for messaging SHOULD also implement OpenPGP-MIME. 3. Data Element Formats This section describes the datastructures. The OP standard specifies one such printable encoding schemeelements used by OP. 3.1 Scalar numbers Scalar numbers are unsigned, and are always stored in big-endian format. Using n[k] toensure interoperability. OP's Radix-64 encoding is composedrefer to the kth octet being interpreted, the value oftwo parts:abase64 encodingtwo-octet scalar is ((n[0] << 8) + n[1]). The value ofthe binary data, andachecksum. The base64 encodingfour-octet scalar isidentical to the MIME base64 content-transfer-encoding [RFC 2045, Section 6.8]. An OP implementation MAY use ASCII Armor((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 toprotecthold large integers such as theraw binary data. The checksum is a 24-bit CRC converted to four charactersones used in cryptographic calculations. An MPI consists ofradix-64 encoding by the same MIME base64 transformation, preceded by an equals sign (=). The CRCtwo pieces: a two-octet scalar that iscomputed by usingthegenerator 0x864CFB and an initializationlength of0xB704CE. The accumulation is done onthedata before it is converted to radix-64, rather than on the converted data. (For more information on CRC functions, see chapter 19MPI in bits followed by a string of[CAMPBELL].) {{Editor's note: This is old text, dating back to RFC 1991. I have never liked the glib way the CRC has been dismissed, but I also knowoctets thatthis is no place to startcontain the actual integer. These octets form adiscussion of CRC theory. Should we constructbig-endian number; asample implementation in C and putbig-endian number can be made into an MPI by prefixing it with the appropriate length. Examples: (all numbers are inan appendix? -- jdcc}}hexadecimal) Thechecksumstring of octets [00 01 01] forms an MPI withits leading equal sign MAY appear onthefirst line aftervalue 1. The string [00 09 01 FF] forms an MPI with theBase64 encoded data. Rationale for CRC-24:value of 511. Additional rules: The size of24 bits fits evenly into printable base64.an MPI is ((MPI.length + 7) / 8) + 2. Thenonzero initialization can detect more errors than a zero initialization. 2.4.1 Forming ASCII Armor When OP encodes data into ASCII Armor, it puts specific headers around the data, so OP can reconstruct the data later. OP informs the user what kind of data is encoded in the ASCII armor through the uselength field of an MPI describes theheaders. Concatenating the following data creates ASCII Armor: - An Armor Header Line, appropriate forlength starting from its most significant non-zero bit. Thus, thetype of data - Armor Headers -MPI [00 02 01] is not formed correctly. It should be [00 01 01]. 3.3 Key IDs Ablank (zero-length, or containing only whitespace) line - The ASCII-Armored data - An Armor Checksum -Key ID is an eight-octet number that identifies a key. Implementations SHOULD NOT assume that Key IDs are unique. TheArmor Tail, which depends on the Armor Header Line. An Armor Header Line consists of the appropriate header line text surrounded by five (5) dashes ('-', 0x2D) on either side of the header line text.section, "Enhanced Key Formats" below describes how Key IDs are formed. 3.4 Text Theheader linedefault character set for text ischosen based uponthetypeUTF-8 [RFC2044] encoding ofdata that is being encoded in Armor, and how itUnicode [ISO10646]. 3.5 Time fields A time field isbeing encoded. Header line texts includean unsigned four-octet number containing thefollowing strings: BEGIN PGP MESSAGEnumber of seconds elapsed since midnight, 1 January 1970 UTC. 3.6 String-to-key (S2K) specifiers String-to-key (S2K) specifiers are usedfor signed, encrypted, or compressed files BEGIN PGP PUBLIC KEY BLOCKto convert passphrase strings into conventional encryption/decryption keys. They are usedfor armoring publicin two places, currently: to encrypt the secret part of private keysBEGIN PGP PRIVATE KEY BLOCK used for armoringin the private keyring, and to convert passphrases to encryption keysBEGIN PGP MESSAGE, PART X/Y usedformulti-part messages, whereconventionally encrypted messages. 3.6.1 String-to-key (S2k) specifier types There are three types of S2K specifiers currently supported, as follows: 3.6.1.1 Simple S2K This directly hashes thearmor is split amongst Y parts, and this isstring to produce theXth part out of Y. BEGIN PGP MESSAGE, PART X usedkey data. See below formulti-part messages, wherehow this hashing is done. Octet 0: 0x00 Octet 1: hash algorithm 3.6.1.2 Salted S2K This includes a "salt" value in theXth part of an unspecified number of parts. RequiresS2K specifier -- some arbitrary data -- that gets hashed along with theMESSAGE-ID Armor Headerpassphrase string, tobe used. BEGIN PGP SIGNATURE used for detached signatures, OP/MIME signatures,help prevent dictionary attacks. Octet 0: 0x01 Octet 1: hash algorithm Octets 2-9: 8-octet salt value 3.6.1.3 Iterated andsignatures following clearsigned messagesSalted S2K This includes both a salt and an octet count. TheArmor Headers are pairs of strings that can givesalt is combined with theuser orpassphrase and thereceiving OP message block some information about how to decode or useresulting value is hashed repeatedly. This further increases themessage. The Armor Headers are a partamount ofthe armor, notwork an attacker must do to try dictionary attacks. Octet 0: 0x04 Octet 1: hash algorithm Octets 2-9: 8-octet salt value Octets 10-13: count, apart offour-octet, unsigned value Note that themessage, and hence are not protected by any signatures applied to the message. The formatvalue 0x03 for octet 0 ofan Armor Headera S2K specifier isthatreserved; it denotes an obsolete form ofa key-value pair. A colon (':' 0x38) and a single space (0x20) separatethekeyInterated andvalue. OP should consider improperly formatted Armor HeadersSalted S2K. 3.6.2 String-to-key usage Implementations SHOULD use salted or iterated-and-salted S2K specifiers, as simple S2K specifiers are more vulnerable to dictionary attacks. 3.6.2.1 Secret key encryption An S2K specifier can becorruption ofstored in theASCII Armor. Unknown keys should be reportedsecret keyring tothe user, but OP should continuespecify how toprocess the message. Currently defined Armor Header Keys include "Version" and "Comment", which defineconvert theOP Version usedpassphrase toencode the message and a user-defined comment. The "MessageID" Armor Header specifiesa32-character string of printable characters. The string must bekey that unlocks thesame for all partssecret data. Older versions of PGP just stored amulti-part message that usescipher algorithm octet preceding the"PART X" Armor Header. MessageID strings should be chosen with enough internal randomnesssecret data or a zero to indicate thatno two messages would havethesame MessageID string.secret data was unencrypted. TheMessageID should not appear unless it is in a multi-part message. If it appears at all, it should be computed from the message in a deterministic fashion, rather than contain a purely random value. This is to allow anyoneMD5 hash function was always used todetermine thatconvert theMessageID cannot serve as a covert means of leaking cryptographic key information. {{Editor's note: This needspassphrase tobe cleaned up, withatable of the defined headers. Also,key for theMessageID descriptionspecified cipher algorithm. For compatibility, when an S2K specifier istoo vague about how randomused, theid has to be.}} The Armor Tail Linespecial value 255 iscomposedstored in thesame manner asposition where theArmor Header Line, excepthash algorithm octet would have been in thestring "BEGIN"old data structure. This isreplacedthen followed immediately by a one-octet algorithm identifier, and then by thestring "END." 2.4.2 Encoding Binary in Radix-64 The encoding process represents 24-bit groups of input bitsS2K specifier asoutput strings of 4encodedcharacters. Proceeding from left to right, a 24-bit input groupabove. Therefore, preceding the secret data there will be one of these possibilities: 0 secret data isformedunencrypted (no pass phrase) 255 followed byconcatenating three 8-bit input groups.algorithm octet and S2K specifier Cipher alg use Simple S2K algorithm using MD5 hash This last possibility, the cipher algorithm number with an implicit use of MD5 is provided for backward compatibility; it should be understood, but not generated. These24 bitsarethen treated as four concatenated 6-bit groups, eachfollowed by an 8-octet Initial Vector for the decryption ofwhich is translated into a single digit intheRadix-64 alphabet. When encoding a bit stream withsecret values, if they are encrypted, and then theRadix-64 encoding,secret key values themselves. 3.6.2.2 Conventional message encryption PGP 2.X always used IDEA with Simple string-to-key conversion when conventionally encrypting a message. PGP 5 can create a Conventional Encrypted Session Key packet at thebit stream mustfront of a message. This can bepresumedused to allow S2K specifiers to beorderedused for the passphrase conversion, to allow other ciphers than IDEA to be used, or to create messages with a mix of conventional ESKs and public key ESKs. This allows a message to be decrypted either with a passphrase or a public key. 3.6.3 String-to-key algorithms 3.6.3.1 Simple S2K algorithm Simple S2K hashes themost-significant-bit first. That is,passphrase to produce thefirst bitsession key. The manner in which this is done depends on thestream will besize of thehigh-order bit insession key (which will depend on thefirst 8-bit byte,cipher used) and theeighth bit will besize of thelow-order bit inhash algorithm's output. If thefirst 8-bit byte, and so on. +--first octet--+-second octet--+--third octet--+ |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +-----------+---+-------+-------+---+-----------+ |5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0| +--1.index--+--2.index--+--3.index--+--4.index--+ Each 6-bit grouphash size is greater than or equal to the session key size, the leftmost octets of the hash are used asan index into an arraythe key. If the hash size is less than the key size, multiple instances of64 printable characters fromthetable below. The character referenced byhash context are created -- enough to produce theindexrequired key data. These instances are preloaded with 0, 1, 2, ... octets of zeros (that isplaced into say, theoutput string. Value Encoding Value Encoding Value Encoding Value Encoding 0 A 17 R 34 i 51 z 1 B 18 S 35 j 52 0 2 C 19 T 36 k 53 1 3 D 20 U 37 l 54 2 4 E 21 V 38 m 55 3 5 F 22 W 39 n 56 4 6 G 23 X 40 o 57 5 7 H 24 Y 41 p 58 6 8 I 25 Z 42 q 59 7 9 J 26 a 43 r 60 8 10 K 27 b 44 s 61 9 11 L 28 c 45 t 62 + 12 M 29 d 46 u 63 / 13 N 30 e 47 v 14 O 31 f 48 w (pad) = 15 P 32 g 49 x 16 Q 33 h 50 y The encoded output stream must be represented in lines offirst instance has nomore than 76 characters each. Special processing is performed if fewer than 24 bits are available atpreloading, theendsecond gets preloaded with 1 octet of zero, thedata being encoded. There are three possibilities: - The last data group has 24 bits (3 octets). No special processing is needed. - The last data group has 16 bits (2 octets). The first two 6-bit groups are processed as above. Thethird(incomplete) data group hasis preloaded with twozero-value bits added to it,octets of zeros, and so forth). As the data isprocessed as above. A pad character (=)hashed, it isaddedgiven independently to each hash context. Since the contexts have been initialized differently, they will each produce different hash output.- The last data group has 8 bits (1 octet). The first 6-bit groupOnce the passphrase isprocessed as above. The second (incomplete)hashed, the output datagroup has four zero-value bits addedfrom the multiple hashes is concatenated, first hash leftmost, toit, andproduce the key data, with any excess octets on the right discarded. 3.6.3.2 Salted S2K algorithm Salted S2K isprocessed as above. Two pad characters (=) are addedexactly like Simple S2K, except that the input to theoutput. 2.4.3 Decoding Radix-64 Any characters outsidehash function(s) consists of thebase64 alphabet are ignored in Radix-64 data. Decoding software must ignore all line breaks or other characters not found in8 octets of salt from thetable above. In Radix-64 data, characters other than those inS2K specifier, followed by thetable, line breaks,passphrase. 3.6.3.3 Iterated-Salted S2K algorithm Iterated-Salted S2K hashes the passphrase andother white space probably indicate a transmission error, about which a warning message or even a message rejection mightsalt data multiple times. The total number of octets to beappropriate under some circumstances. Because ithashed isused only for padding atspecified in theend offour-octet count in thedata,S2K specifier. Note that theoccurrenceresulting count value is an octet count ofany "=" characters mayhow many octets will betakenhashed, not an iteration count. Initially, one or more hash contexts are set up asevidence thatwith theendother S2K algorithms, depending on how many octets of key data are needed. Then the salt, followed by the passphrase datahas been reached (without truncation in transit). No such assuranceispossible, however, whenrepeatedly hashed until the number of octetstransmitted was a multiple of three and no "=" characters are present. 2.4.4 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 Decimal: 5 15 46 28 0 61 37 63 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 8-bit: 00010100 11111011 10011100 | 00000011 pad with 0000 6-bit: 000101 001111 101110 011100 | 000000 110000 Decimal: 5 15 46 28 0 48 pad with = = Output: F P u c A w = = 2.5 Example of an ASCII Armored Message -----BEGIN PGP MESSAGE----- Version: OP V0.0 owFbx8DAYFTCWlySkpkHZDKEFCXmFedmFhdn5ucpZKdWFiv4hgaHKPj5hygUpSbn l6UWpabo8XIBAA== =3m1o -----END PGP MESSAGE----- Note that this example is indented by two spaces. 2.6 Cleartext signature framework Sometimes it is necessary to sign a textual octet stream without ASCII armoring the stream itself, so the signed text is still readable without special software. In order to bind a signature to such a cleartext, this framework is used. (Note that RFC 2015 defines another way to clear sign messages for environments that support MIME.) The cleartext signed message consists of: - The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a single line, - Zero or more "Hash" Armor Headers (3.1.2.4), - Exactly one empty line not included into the message digest, - The dash-escaped cleartext that is included into the message digest, - The ASCII armored signature(s) including the Armor Header and Armor Tail Lines. If the "Hash" armor header is given, the specified message digest algorithm is used for the signature. If this header is missing, SHA-1 is assumed. If more than one message digest is used in the signature, the "Hash" armor header contains a comma-delimited list of used message digests. As an abbreviation, the "Hash" armor header may be placed on the cleartext header line, inserting a comma after the word 'MESSAGE', as follows: '-----BEGIN PGP SIGNED MESSAGE, Hash: MD5, SHA1'. {{Editor's note: Should the above armor header line stay or go? There's no reason that the "Hash:" armor header can't have multiple hashes in it. I think anything that reduces parsing complexity is a Good Thing. --jdcc}} Current message digest names are: - "SHA1" - "MD5" - "RIPEMD160" Dash escaped cleartext is the ordinary cleartext where every line starting with a dash '-' (0x2D) is prepended 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. As with binary signatures on text documents (see below), the cleartext signature is calculated on the text using canonical <CR><LF> line endings. The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP SIGNATURE-----' line that terminates the signed text is not considered part of the signed text. Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of any line is ignored when the cleartext signature is calculated. 3. Data Element Formats This section describes the data elements used by OP. 3.1 Scalar numbers Scalar numbers are unsigned, and are always stored in big-endian format. Using n[k] to refer to the kth octet being interpreted, 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 the 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. Examples: (all numbers are in hexadecimal) The string of octets [00 01 01] forms an MPI with the value 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 Counted Strings A counted string consists of a length and then N octets of string data. Its default character set is UTF-8 [RFC2044] encoding of Unicode [ISO10646]. 3.4 Time fields A time field is an unsigned four-octet number containing the number of seconds elapsed since midnight, 1 January 1970 UTC. 3.5 String-to-key (S2K) specifiers String-to-key (S2K) specifiers are used to convert passphrase strings into conventional encryption/decryption keys. They are used in two places, currently: to encrypt the secret part of private keys in the private keyring, and to convert passphrases to encryption keys for conventionally encrypted messages. 3.5.1 String-to-key (S2k) specifier types There are three types of S2K specifiers currently supported, as follows: 3.5.1.1 Simple S2K This directly hashes the string to produce the key data. See below for how this hashing is done. Octet 0: 0x00 Octet 1: hash algorithm 3.5.1.2 Salted S2K This includes a "salt" value in the S2K specifier -- some arbitrary data -- that gets hashed along with the passphrase string, to help prevent dictionary attacks. Octet 0: 0x01 Octet 1: hash algorithm Octets 2-9: 8-octet salt value 3.5.1.3 Iterated and Salted S2K This includes both a salt and an octet count. The salt is combined with the passphrase and the resulting value is hashed repeatedly. This further increases the amount of work an attacker must do to try dictionary attacks. Octet 0: 0x03 Octet 1: hash algorithm Octets 2-9: 8-octet salt value Octet 10: count, in special format (described below) 3.5.2 String-to-key usage Implementations MUST implement simple S2K and salted S2K specifiers. Implementations MAY implement iterated and salted S2K specifiers. Implementations SHOULD use salted S2K specifiers, as simple S2K specifiers are more vulnerable to dictionary attacks. 3.5.2.1 Secret key encryption An S2K specifier can be stored in the secret keyring to specify how to convert the passphrase to a key that unlocks the secret data. Older versions of PGP just stored a cipher algorithm octet preceding the secret data or a zero to indicate that the secret data was unencrypted. The MD5 hash function was always used to convert the passphrase to a key for the specified cipher algorithm. For compatibility, when an S2K specifier is used, the special value 255 is stored in the position where the hash algorithm octet would have been in the old data structure. This is then followed immediately by a one-octet algorithm identifier, and thenspecified by theS2K specifier as encoded above. Therefore, preceding the secret data there will be one of these possibilities: 0 secret data is unencrypted (no pass phrase) 255 followed by algorithmoctetand S2K specifier Cipher alg use Simple S2K algorithm using MD5 hash This last possibility, the cipher algorithm number with an implicit use of MD5 is provided for backward compatibility; it should be understood, but not generated. These are followed by an 8-octet Initial Vector for the decryption of the secret values, if they are encrypted, and then the secret key values themselves. 3.5.2.2 Conventional message encryption PGP 2.X always used IDEA with Simple string-to-key conversion when conventionally encrypting a message. PGP 5 can create a Conventional Encrypted Session Key packet at the front of a message. This can be used to allow S2K specifiers to be used for the passphrase conversion, to allow other ciphers than IDEA to be used, or to create messages with a mix of conventional ESKs and public key ESKs. This allows a message to be decrypted either with a passphrase or a public key. 3.5.3 String-to-key algorithms 3.5.3.1 Simple S2K algorithm Simple S2K hashes the passphrase to produce the session key. The manner in which this is done depends on the size of the session key (which will depend on the cipher used) and the size of the hash algorithm's output. If the hash size is greater than or equal to the session key size, the leftmost octets of the hash are used as the key. Ifcount has been hashed. The one exception is that if thehash sizeoctet count is less than thekey size, multiple instancessize of thehash context are created -- enough to producesalt plus passphrase, therequired key data. These instances are preloaded with 0, 1, 2, ... octets of zeros (thatfull salt plus passphrase will be hashed even though that isto say, the first instance has no preloading,greater than thesecond gets preloaded with 1octetof zero,count. After thethirdhashing ispreloaded with two octets of zeros, and so forth). Asdone the data ishashed, it is given independently to each hash context. Sinceunloaded from thecontexts have been initialized differently, they will each produce differenthashoutput. Oncecontext(s) as with thepassphrase is hashed,other S2K algorithms. 4. Packet Syntax This section describes theoutput datapackets used by OP. 4.1 Overview An OP message is constructed from a number of records that are traditionally called packets. A packet is a chunk of data that has a tag specifying its meaning. An OP message, keyring, certificate, and so forth consists of a number of packets. Some of those packets may contain other OP packets (for example, a compressed data packet, when uncompressed, contains OP packets). Each packet consists of a packet header, followed by themultiple hashespacket body. The packet header isconcatenated,of variable length. 4.2 Packet Headers The firsthash leftmost, to produce the key data, with any excess octets onoctet of theright discarded. 3.5.3.2 Salted S2K algorithm Salted S2Kpacket header isexactly like Simple S2K, except thatcalled the "Packet Tag." It determines the format of theinput toheader and denotes thehash function(s) consistspacket contents. The remainder of the8 octetspacket header is the length ofsalt fromtheS2K specifier, followed bypacket. Note that thepassphrase. 3.5.3.3 Iterated-Salted S2K algorithm {{Editor's note: Thismost significant bit isvery complex,the left-most bit, called bit 7. A mask for this bit is 0x80 in hexadecimal. +---------------+ PTag |7 6 5 4 3 2 1 0| +---------------+ Bit 7 -- Always one Bit 6 -- New packet format if set PGP 2.6.X only uses old format packets. Thus, software that interoperates withbizarre things likethose versions of PGP must only use old format packets. If interoperability is not an8-bit floating point format. Should we just drop it? --jdcc}} Iterated-Salted S2K hashes the passphraseissue, either format may be used. Note that old format packets have four bits of content tags, andsalt data multiple times.new format packets have six; some features cannot be used and still be backwards-compatible. Old format packets contain: Bits 5-2 -- content tag Bits 1-0 - length-type New format packets contain: Bits 5-0 -- content tag Thetotal numbermeaning of the length-type in old-format packets is: 0 - The packet has a one-octet length. The header is 2 octetsto be hashedlong. 1 - The packet has a two-octet length. The header isencoded in3 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 thecount octet that followsapplication must determine how long thesalt inpacket is. If theS2K specifier. The count valuepacket isstored asin anormalized floating-point value with 4 bits of exponent and 4 bits of mantissa. The formula to convert fromfile, this means that thecount octet to a count ofpacket extends until thenumberend ofoctets to be hashed is as follows, lettingthehigh 4 bitsfile. In general, an application should not use indeterminate length packets except where the end of thecount octetdata will beCEXP andclear from thelow four bits be CMANT: countcontext. New format packets have three possible ways ofoctets to be hashed = (16 + CMANT) << (CEXP + 6) This allowsencodinghash counts as low as 16 << 6 or 1024 (using an octet valuelength. A one-octet Body Length header encodes packet lengths of0),up to 191 octets, andas high as 31 << 21a two-octet Body Length header encodes packet lengths of 192 to 8383 octets. For cases where longer packet body lengths are needed, or65011712 (using an octet valuewhere the length of0xff). Note thattheresulting count valuepacket body isan octet count of how many octets will be hashed,notan iteration count. Initially, one or more hash contextsknown in advance by the issuer, Partial Body Length headers can be used. These areset up as withone-octet length headers that encode theother S2K algorithms, depending on how many octetslength of only part ofkey data are needed. Thenthesalt,data packet. Each Partial Body Length header is followed by a portion of thepassphrase data is repeatedly hashed untilpacket body data. The Partial Body Length header specifies this portion's length. Another length header (of one of the three types) follows that portion. The last length header in thenumberpacket must always be a regular Body Length header. Partial Body Length headers may only be used for the non-final parts ofoctets specified bytheoctet count has been hashed. The one exceptionpacket. A one-octet Body Length header encodes a length of from 0 to 191 octets. This type of length header isthat ifrecognized because the one octetcountvalue is less thanthe size192. The body length is equal to: bodyLen = length_octet; A two-octet Body Length header encodes a length ofthe salt plus passphrase, the full salt plus passphrase will be hashed even though thatfrom 192 to 8383 octets. It isgreater than therecognized because its first octetcount. After the hashing is done the dataisunloaded from the hash context(s) as with the other S2K algorithms. 4. Packet Syntax This section describesin thepackets used by OP. 4.1 Overview An OP messagerange 192 to 223. The body length isconstructed from a number of records that are traditionally called packets.equal to: bodyLen = (1st_octet - 192) * 256 + (2nd_octet) + 192 ApacketPartial Body Length header isa chunk of data that has a tag specifying its meaning. An OP message, keyring, certificate,one octet long andso forth consists ofencodes anumber of packets. Some of those packets may contain other OP packets (for example,length which is acompressed data packet, when uncompressed, contains OP packets). Each packet consistspower ofa2, from 1 to 2147483648 (2 to the 31st power). It is recognized because its one octet value is greater than or equal to 224. The partial body length is equal to: partialBodyLen = 1 << (length_octet & 0x1f); Examples: A packetheader,with length 100 may have its length encoded in one octet: 0x64. This is followed bythe packet body. The100 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 ofvariable length. 4.2 Packet Headers Thedata. A packet with length 100000 might be encoded in the following octet stream: 0xE1, first two octets of data, 0xE0, next one octet ofthe packet headerdata, 0xEF, next 32768 octets of data, 0xF0, next 65536 octets of data, 0xC5, 0xDD, last 1693 octets of data. This iscalledjust one possible encoding, and many variations are possible on the"Packet Tag." It determinessize of theformatPartial 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 headerand denotescan be a zero-length header. Please note that in all of these explanations, thepacket contents. The remaindertotal length of the packetheaderis the length of thepacket. Note thatheader(s) plus themost significant bit islength of theleft-most bit, called bit 7. A mask for this bit is 0x80 in hexadecimal. +---------------+ PTag |7 6 5 4 3 2 1 0| +---------------+ Bit 7 -- Always one Bit 6 -- Newbody. 4.3 Packet Tags The packetformat if set PGP 2.6.X only uses old format packets. Thus, software that interoperates with those versionstag denotes what type ofPGP must only usepacket the body holds. Note that old formatpackets. If interoperability is not an issue, either format may be used. Old formatpacketscontain: Bits 5-2 -- content tag Bits 1-0 - length-type Newcan only have tags less than 16, whereas new format packetscontain: Bits 5-0 -- content tagcan have tags as great as 63. Themeaning of the length-type in old-format packets is:defined tags (in decimal) are: 0- The-- Reserved. A packethasmust not have aone-octet length. The header is 2 octets long.tag with this value. 1- The packet has a two-octet length. The header is 3 octets long.-- Public-Key Encrypted Session Key Packet 2- The packet has a four-octet length. The header is 5 octets long.-- Signature Packet 3- The-- Symmetric-Key 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 -- Marker Packet 11 -- Literal Data Packet 12 -- Trust Packet 13 -- Name Packet 14 -- Subkey Packet 15 -- Reserved 60 to 63 -- Private or Experimental Values 5. Packet Types 5.1 Public-Key Encrypted Session Key Packets (Tag 1) A Public-Key Encrypted Session Key packet holds the key used to encrypt a message that isof indeterminate length.itself encrypted with a public key. Zero or more Encrypted Session Key packets and/or Conventional Encrypted Session Key packets may precede a Symmetrically Encrypted Data Packet, which holds an encrypted message. Theheadermessage is1 byte long,encrypted with a session key, and theapplication must determine how longsession key is itself encrypted and stored in the Encrypted Session Key packet(s). The Symmetrically Encrypted Data Packet is preceded by one Public-Key Encrypted Session Key packetis. Iffor each OP key to which thepacketmessage isinencrypted. The recipient of the message finds afile, this meanssession 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 packetextends untilconsists of: - A one-octet number giving theendversion number of thefile. In general, an applicationpacket type. The currently defined value for packet version is 3. An implementation should accept, but notuse indeterminate length packets except wheregenerate a version of 2, which is equivalent to V3 in all other respects. - An eight-octet number that gives theendkey ID of thedata will be clear frompublic key that thecontext. New format packets have three possible ways of encoding length.session key is encrypted to. - A one-octetBody Length header encodes packet lengthsnumber giving the public key algorithm used. - A string of octets that is the encrypted session key. This string takes upto 191 octets, and a two-octet Body Length header encodes packet lengthsthe remainder of192 to 8383 octets. For cases where longer packet body lengthsthe packet, and its contents areneeded, or wheredependent on thelengthpublic key algorithm used. Algorithm Specific Fields for RSA encryption - multiprecision integer (MPI) of RSA encrypted value m**e mod n. Algorithm Specific Fields for Elgamal encryption: - MPI of DSA value g**k mod p. - MPI of DSA value m * y**k mod p. The encrypted value "m" in thepacket bodyabove formulas isnot known in advance byderived from theissuer, Partial Body Length headers can be used. These aresession key as follows. First the session key is prepended with a one-octetlength headersalgorithm identifier thatencodespecifies thelength of only part ofconventional encryption algorithm used to encrypt thedata packet. Each Partial Body Length header is followed byfollowing Symmetrically Encrypted Data Packet. Then aportion oftwo-octet checksum is appended which is equal to thepacket body data. The Partial Body Length header specifies this portion's length. Another length header (of onesum of thethree types) follows that portion. The last length headerpreceding octets, including the algorithm identifier and session key, modulo 65536. This value is then padded as described in PKCS-1 block type 02 [PKCS1] to form thepacket must always be a regular Body Length header. Partial Body Length headers may only be"m" value usedforin thenon-final partsformulas above. An implementation MAY use a Key ID of zero as a "wild card" or "speculative" Key ID. In this case, thepacket. A one-octet Body Length header encodesimplementation would try all available private keys, checking for alength of from 0 to 191 octets.valid decrypted session key. Thistypeformat helps reduce traffic analysis oflength header is recognized because the one octet value is less than 192. The body length is equal to: bodyLen = length_octet;messages. 5.2 Signature Packet (Tag 2) Atwo-octet Body Length header encodessignature packet describes a binding between some public key and some data. The most common signatures are alengthsignature offrom 192 to 8383 octets. It is recognized because its first octet is in the range 192 to 223. The body length is equal to: bodyLen = (1st_octet - 192) * 256 + (2nd_octet) + 192 A Partial Body Length header is one octet longa file or a block of text, andencodesalength whichsignature that is apowercertification of2, from 1 to 2147483648 (2 toa 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 the31st power). Itsignature. PGP 2.6.X only accepts version 3 signatures. Implementations MUST accept V3 signatures. Implementations SHOULD generate V4 signatures, unless there isrecognized because its one octet valuea need to generate a signature that can be verified by old implementations. Note that if an implementation isgreater than or equalcreating an encrypted and signed message that is encrypted to224. The partial body lengtha V3 key, it isequal to: partialBodyLen = 1 << (length_octet & 0x1f); Examples:reasonable to create a V3 signature. 5.2.1 Version 3 Signature Packet Format A version 3 Signature packetwith length 100 may have itscontains: - One-octet version number (3). - One-octet lengthencoded in one octet: 0x64.of following hashed material. MUST be 5. - One-octet signature type. - Four-octet creation time. - Eight-octet key ID of signer. - One-octet public key algorithm. - One-octet hash algorithm. - Two-octet field holding left 16 bits of signed hash value. - One or more multi-precision integers comprising the signature. This portion isfollowed by 100 octets of data. A packet with length 1723 may have its length coded in two octets: 0xC5, 0xFB. This headeralgorithm specific, as described below. The data being signed isfollowed byhashed, and then the1723 octets of data. Asignature type and creation time from the signature packetwith length 100000 might be encodedare hashed (5 additional octets). The resulting hash value is used in thefollowing octet stream: 0xE1, firstsignature algorithm. The high 16 bits (first twooctets of data, 0xE0, next one octetoctets) ofdata, 0xEF, next 32768 octetsthe hash are included in the signature packet to provide a quick test to reject some invalid signatures. Algorithm Specific Fields for RSA signatures: - multiprecision integer (MPI) ofdata, 0xF0, next 65536 octetsRSA signature value m**d. Algorithm Specific Fields for DSA signatures: - MPI ofdata, 0xC5, 0xDD, last 1693 octetsDSA value r. - MPI ofdata. ThisDSA value s. The signature calculation isjust one possible encoding, and many variations are possiblebased onthe size of the Partial Body Length headers, as long asaregular Body Length header encodes the last portionhash of thedata. Note also that the last Body Length header can be a zero-length header. Please note that in allsigned data, as described above. The details ofthese explanations,thetotal length ofcalculation are different for DSA signature than for RSA signatures. With RSA signatures, thepackethash value isthe length of the header(s) plus the lengthencoded as described in PKCS-1 section 10.1.2, "Data encoding", producing an ASN.1 value of type DigestInfo, and then padded using PKCS-1 block type 01 [PKCS1]. This requires inserting thebody. 4.3 Packet Tagshash value as an octet string into an ASN.1 structure. Thepacket tag denotes whatobject identifier for the type ofpackethash being used is included in thebody holds. Note that old format packets can only have tags less than 16, whereas new format packets can have tags as great as 63.structure. The hexadecimal representations for the currently definedtags (in decimal)hash algorithms are:0 -- Reserved. A packet must not have a tag- MD5: 0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x02, 0x05 - SHA-1: 0x2b, 0x0e, 0x03, 0x02, 0x1a - RIPEMD-160: 0x2b, 0x24, 0x03, 0x02, 0x01 The ASN.1 OIDs are: - MD5: 1.2.840.113549.2.5 - SHA-1: 1.3.14.3.2.26 - RIPEMD160: 1.3.36.3.2.1 DSA signatures SHOULD use hashes withthis 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 -- Marker Packet 11 -- Literal Data Packet 12 -- Trust Packet 13 -- Name Packet 14 -- Subkey Packet 15 -- Reserved 16 -- Comment Packet 60a size of 160 bits, to63 -- Private or Experimental Values 5. Packet Types 5.1 Encrypted Session Key Packets (Tag 1) An Encrypted Session Key packet holdsmatch q, thekey used to encrypt a message thatsize of the group generated by the DSA key's generator value. The hash function result isitself encrypted withtreated as a 160 bit number and used directly in the DSA signature algorithm. 5.2.2 Version 4 Signature Packet Format A version 4 Signature packet contains: - One-octet version number (4). - One-octet signature type. - One-octet publickey. Zerokey algorithm. - One-octet hash algorithm. - Two-octet octet count for following hashed subpacket data. - Hashed subpacket data. (zero or moreEncrypted Session Key packets and/or Conventional Encrypted Session Key packets may precede a Symmetrically Encrypted Data Packet, which holds an encrypted message.subpackets) - Two-octet octet count for following unhashed subpacket data. - Unhashed subpacket data. (zero or more subpackets) - Two-octet field holding left 16 bits of signed hash value. - One or more multi-precision integers comprising the signature. This portion is algorithm specific, as described above. Themessagedata being signed isencrypted with a session key,hashed, and then thesession keysignature data from the version number through the hashed subpacket data isitself encrypted and storedhashed. The resulting hash value is what is signed. The left 16 bits of the hash are included in theEncrypted Session Keysignature packetorto provide a quick test to reject some invalid signatures. There are two fields consisting of signature subpackets. The first field is hashed with theConventional Encrypted Session Key packet.rest of the signature data, while the second is unhashed. The second set of subpackets is not cryptographically protected by the signature and should include only advisory information. The algorithms for converting the hash function result to a signature are described above. 5.2.2.1 Signature Subpacket Specification TheSymmetrically Encrypted Data Packetsubpacket fields consist of zero or more signature subpackets. Each set of subpackets is preceded byone Encrypted Session Key packet for each OP key to whicha two-octet count of themessage is encrypted. The recipientlength of themessage findsset of subpackets. Each subpacket consists of asession key that is encrypted to their public key, decrypts the session key,subpacket header andthen uses the session key to decrypt the message.a body. Thebody of this packetheader consists of: -A one-octet number givingsubpacket length (1 or 2 octets): Length includes the type octet but not this length, 1st octet < 192, then length is octet value 1st octet >= 192, then length is 2 octets and equal to (1st octet - 192) * 256 + (2nd octet) + 192 - subpacket type (1 octet): If bit 7 is set, subpacket understanding is critical, 2 = signature creation time, 3 = signature expiration time, 4 = exportable, 5 = trust signature, 6 = regular expression, 7 = revocable, 9 = key expiration time, 10 = placeholder for backwards 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, 26 = policy URL, 27 = key flags, 28 = Signer's user id - subpacket specific data: An implementation SHOULD ignore any subpacket that it does not recognize. Bit 7 of the subpacket type is the "critical" bit. If set, it denotes that theversion numbersubpacket is one which is critical that the evaluator of thepacket type. The currently defined value for packet version is 3. An implementation should accept, but not generatesignature recognize. If aversion of 2,subpacket is encountered which isequivalentmarked critical but is unknown toV3the evaluating software, the evaluator SHOULD consider the signature to be inall other respects. -error. Aneight-octet number that gives the key IDevaluator may "recognize" a subpacket, but not implement it. The purpose of thepublic key that the session keycritical bit isencrypted to. - A one-octet number givingto allow thepublic key algorithm used. - A string of octetssigner to tell an evaluator thatis the encrypted session key. This string takes up the remainderit would prefer a new, unknown feature to generate an error than be ignored. 5.2.2.2 Signature Subpacket Types Several types of subpackets are currently defined. Some subpackets apply to thepacket,signature itself andits contentssome aredependent on the public key algorithm used. Algorithm Specific Fields for RSA encryption - multiprecision integer (MPI) of RSA encrypted value m**e. Algorithm Specific Fields for Elgamal encryption: - MPI of DSA value g**k. - MPIattributes ofDSA value m * y**k. The encrypted value "m" in the above formulas is derived fromthesession key as follows. Firstkey. Subpackets that are found on a self-signature are placed on a user name certification made by thesessionkeyis prepended with a one-octet algorithm identifieritself. Note thatspecifies the conventional encryption algorithm used to encrypt the following Symmetrically Encrypted Data Packet. Thenatwo-octet checksum is appended whichkey may have more than one user name, and thus may have more than one self-signature, and differing subpackets. A self-signature isequal toa binding signature made by thesumkey the signature refers to. There are three types of self-signatures, thepreceding octets, includingcertification signatures (types 0x10-0x13), thealgorithm identifierdirect-key signature (type 0x1f), andsession key, modulo 65536. This value is then padded as described in PKCS-1 block type 02 [PKCS1] to form the "m" value used intheformulas above. 5.2 Signature Packet (Tag 2) A signature packet describes asubkey bindingbetween some public key and some data. The most common signatures are asignatureof a file or(type 0x18). For certification self-signatures, username may have ablock of text,self-signature, and thus different subpackets in those self-signatures. For subkey binding signatures, each subkey in fact has asignatureself-signature. Subpackets thatisappear in a certificationof a user ID. Two versions of signature packets are defined. Version 3 provides basicself-signature apply to the username, and subpackets that appear in the subkey self-signature apply to the subkey. Lastly, subpackets on the direct key signatureinformation, while version 4 provides an expandable format withapply 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 thatcan specify more information aboutAlice prefers thesignature. PGP 2.6.X only accepts version 3 signatures. Implementations MUST accept V3 signatures. Implementations SHOULD generate V4 signatures, unless theresymmetric 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 isa need to generate a signature that can be verifiedlocated byPGP 2.6.x. 5.2.1 Version 3 Signature Packet Format 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. - Four-octet creation time. - Eight-octetkeyIDid, then algorithm ofsigner. - One-octet publicthe default user name of the key provides the default symmetric algorithm.- One-octet hash algorithm. - Two-octet field holding left 16 bits of signed hash value. - One or more multi-precision integers comprisingA subpacket may be found either in the hashed or unhashed subpacket sections of a signature.This portion is algorithm specific, as described below. The data being signedIf a subpacket is not hashed,andthen the information in it cannot be considered definitive because it is not part of the signaturetype andproper. Subpacket types: Signature creation timefrom the signature packet are hashed (5 additional octets).(4 octet time field) Theresulting hash value is used intime the signaturealgorithm.was made. Always included with new signatures. Issuer (8 octet key ID) Thehigh 16 bits (first two octets)OP key ID of thehash are included inkey issuing thesignature packet to provide a quick test to reject some invalid signatures. Algorithm Specific Fields for RSA signatures: - multiprecision integer (MPI)signature. Key expiration time (4 octet time field) The validity period ofRSA signature value m**d. Algorithm Specific Fields for DSA signatures: - MPIthe key. This is the number ofDSAseconds after the key creation time that the key expires. If this is not present or has a valuer. - MPIofDSA value s. The signature calculationzero, the key never expires. This isbasedfound only on ahashself-signature. Preferred symmetric algorithms (array of one-octet values) Symmetric algorithm numbers that indicate which algorithms thesigned data, as described above. The detailskey holder prefers to use. This is an ordered list of octets with thecalculationmost preferred listed first. It should be assumed that only algorithms listed aredifferent for DSA signature than for RSA signatures. With RSA signatures,supported by thehash value is encoded as describedrecipient's software. Algorithm numbers inPKCS-1section10.1.2, "Data encoding", producing an ASN.1 value of type DigestInfo, and then padded using PKCS-1 block type 01 [PKCS1].6. Thisrequires inserting theis only found on a self-signature. Preferred hashvalue as an octet string into an ASN.1 structure. The object identifier for the typealgorithms (array ofhash being used is included inone-octet values) Message digest algorithm numbers that indicate which algorithms thestructure. The hexadecimal representations forkey holder prefers to receive. Like thecurrently defined hash algorithms are: - SHA-1: 0x2b, 0x0e, 0x03, 0x02, 0x1a - MD5: 0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x02, 0x05 - RIPEMD-160: 0x2b, 0x24, 0x03, 0x02, 0x01 The ASN.1 OIDs are: - MD5: 1.2.840.113549.2.5 - SHA-1: 1.3.14.3.2.26 - RIPEMD160: 1.3.36.3.2.1 DSA signatures SHOULD use hashes withpreferred symmetric algorithms, the list is ordered. Algorithm numbers are in section 6. This is only found on asizeself-signature. Preferred compression algorithms (array of160 bits,one-octet values) Compression algorithm numbers that indicate which algorithms the key holder prefers tomatch q,use. Like thesize ofpreferred symmetric algorithms, thegroup generated bylist is ordered. Algorithm numbers are in section 6. If this subpacket is not included, ZIP is preferred. A zero denotes that uncompressed data is preferred; theDSA key's generator value. The hash function resultkey holder's software may not have compression software. This istreated asonly found on a160 bitself-signature. Signature expiration time (4 octet time field) The validity period of the signature. This is the numberand used directly inof seconds after theDSAsignaturealgorithm. 5.2.2 Version 4 Signature Packet Format A version 4 Signature packet contains: - One-octet version number (4). - One-octetcreation time that the signaturetype. - One-octet public key algorithm. - One-octet hash algorithm. - Two-octetexpires. If this is not present or has a value of zero, it never expires. Exportable (1 octetcountof exportability, 0 forfollowing hashed subpacket data. - Hashed subpacket data. - Two-octet octet countnot, 1 forfollowing unhashed subpacket data. - Unhashed subpacket data. - Two-octet field holding left 16 bits of signed hash value. - One or more multi-precision integers comprisingexportable) Signature's exportability status. Packet body contains a boolean flag indicating whether thesignature. This portion is algorithm specific, as described above. The data being signedsignature ishashed,exportable. Signatures which are not exportable are ignored during export andthenimport operations. If this packet is not present the signature is assumed to be exportable. Revocable (1 octet of revocability, 0 for not, 1 for revocable) Signature's revocability status. Packet body contains a boolean flag indicating whether the signaturedata fromis revocable. Signatures which are not revocable have any later revocation signatures ignored. They represent a commitment by theversion number throughsigner that he cannot revoke his signature for thehashed subpacket data is hashed. The resulting hash valuelife of his key. If this packet iswhatnot present, the signature issigned. The left 16 bitsrevocable. Trust signature (1 octet "level" (depth), 1 octet of trust amount) Signer asserts that thehash are included inkey is not only valid, but also trustworthy, at thesignature packetspecified level. Level 0 has the same meaning as an ordinary validity signature. Level 1 means that the signed key is asserted toprovidebe aquick test to reject some invalid signatures. There are two fields consisting of signature subpackets. The first field is hashedvalid trusted introducer, with therest2nd octet of thesignature data, whilebody specifying thesecond is unhashed. The second setdegree ofsubpackets is not cryptographically protected by the signature and should include only advisory information. The algorithms for convertingtrust. Level 2 means that thehash function resultsigned key is asserted to be trusted to issue level 1 trust signatures, i.e. that it is a "meta introducer". Generally, a level n trust signatureare described above. 5.2.2.1 Signature Subpacket Specificationasserts that a key is trusted to issue level n-1 trust signatures. Thesubpacket fields consisttrust amount is in a range from 0-255, interpreted such that values less than 120 indicate partial trust and values ofzero120 ormoregreater indicate complete trust. Implementations SHOULD emit values of 60 for partial trust and 120 for complete trust. Regular expression (null-terminated regular expression) Used in conjunction with trust signaturesubpackets. Each setpackets (of level > 0) to limit the scope ofsubpacketstrust which isprecededextended. Only signatures bya two-octet count ofthelength oftarget key on user IDs which match thesetregular expression in the body ofsubpackets. Each subpacket consiststhis packet have trust extended by the trust packet. The regular expression uses the same syntax as the Henry Spencer's "almost public domain" regular expression package. A description of the syntax in in asubpacket header and a body. The header consists of: - subpacket lengthsection below. Revocation key (1or 2 octets): Length includes the type octet but not this length, 1st octet < 192, then length isoctetvalue 1stof class, 1 octet>= 192, then length is 2of algid, 20 octetsand equalof fingerprint) Authorizes the specified key to(1stissue revocation self-signatures for this key. Class octet- 192) * 256 + (2nd octet) + 192 - subpacket type (1 octet): Ifmust have bit7 is0x80 set,subpacket understanding is critical, 2 = signature creation time, 3 =other bits are for future expansion to other kinds of signatureexpiration time, 4 = exportable, 5 = trust signature, 6 = regular expression, 7 = revocable, 9 = key expiration time, 10 = additional recipient request, 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 = preferredauthorizations. This is found on a self-signature. Authorizes the specified keyserver - subpacket specific data: Bit 7 ofto issue revocation signatures for this key. Class octet must have bit 0x80 set. If thesubpacket typebit 0x40 is set, then this means that the"critical" bit.revocation information is sensitive. Other bits are for future expansion to other kinds of authorizations. This is found on a self-signature. If the "sensitive" flag is set,it impliesthe keyholder feels this subpacket contains private trust information thatitdescribes a real-world sensitive relationship. If this flag iscritical thatset, implementations SHOULD NOT export this signature to other users except in cases where thesubpacketdata needs to beone whichavailable: when the signature isunderstood bybeing sent to thesoftware. Ifdesignated revoker, or when it is accompanied by a revocation signature from that revoker. Note that it may be appropriate to isolate this subpacket within a separate signature so that it isencountered which is marked critical but the software doesnotunderstand, the handling dependscombined with other subpackets which need to be exported. Notation Data (4 octets of flags, 2 octets of name length, 2 octets of value length, M octets of name data, N octets of value data) This subpacket describes a "notation" on therelationship betweensignature that theissuing keyissuer wishes to make. The notation has a name and a value, each of which are strings of octets. There may be more than one notation in a signature. Notations can be used for any extension thekey that is signed. Ifissuer of the signature cares to make. The "flags" field holds four octets of flags. All undefined flags MUST be zero. Defined flags are: First octet: 0x80 = human-readable. This note is text, a note from one person to another, and has no meaning to software. Other octets: none. Key server preferences (N octets of flags) This is avalid self-signature (for whichlist of flags that indicate preferences that theissuer iskey holder has about how the keythatisbeing signed, either directly or viahandled on ausername binding), then thekeyshould notserver. All undefined flags MUST beused. In other cases, the signature containingzero. First octet: 0x80 = No-modify -- thecritical subpacket shouldkey holder requests that this key only beignored. 5.2.2.2 Signature Subpacket Types Several types of subpackets are currently defined. Some subpackets apply tomodified or updated by thesignature itself and some are attributeskey holder or an authorized administrator of thekey. Subpackets that arekey server. This is found only on aself-signature are placed onself-signature. Preferred key server (String) This is auser name certification made byURL of a key server that the keyitself.holder prefers be used for updates. Note that keys with multiple user names can have a preferred keymay have more than oneserver for each username, and thus may have more than one self-signature, and differing subpackets. Implementing software should interpretname. Note also that since this is aself-signature's preference subpackets as narrowly as possible. For example, supposeURL, the key server can actually be a copy of the keyhas two usernames, Alice and Bob. Supposeretrieved by ftp, http, finger, etc. Primary user id (1 octet, boolean) This is a flag in a user id's self signature thatAlice prefersstates whether this user id is thesymmetric algorithm CAST5, and Bob prefers IDEA or Triple-DES. Ifmain user id for this key. It is reasonable for an implementation to resolve ambiguities in preferences, etc. by referring to thesoftware locatesprimary user id. If thiskey via Alice's name, then the preferred algorithmflag isCAST5, if software locates the key via Bob's name, then the preferred algorithmabsent, its value isIDEA.zero. Ifthemore than one user id in a key islocated by key id, then algorithm ofmarked as primary, thedefault user nameimplementation may resolve the ambiguity in any way it sees fit. Policy URL (String) This subpacket contains a URL of a document that describes thekey providespolicy under which thedefault symmetric algorithm. The descriptions below describe whether asignature was issued. Key Flags (Octet string) This subpacket contains a list of binary flags that hold information about a key. It istypically found in the hashed or unhashed subpacket sections. Ifasubpacketstring of octets, and an implementation MUST NOT assume a fixed size. This isnot hashed, thenso itcannotcan grow over time. If a list is shorter than an implementation expects, the unstated flags are considered to betrusted. Signature creation time (4 octet time field) (Hashed)zero. Thetime the signature was made. Always included with new signatures. Issuer (8 octetdefined flags are: First octet: 0x01 - This keyID) (Non-hashed) The OPmay be used to certify other keys. 0x02 - This keyIDmay be used to sign data. 0x04 - This key may be used to encrypt communications. 0x08 - This key may be used to encrypt storage. 0x10 - The private component ofthethis keyissuing the signature. Key expiration time (4 octet time field) (Hashed)may have been split by a secret-sharing mechanism. 0x80 - Thevalidity periodprivate component of this key may be in thekey. Thisposession of more than one person. Usage notes: The flags in this packet may appear in self-signatures or in certification signatures. They mean different things depending on who is making thenumber of seconds after the key creation timestatement -- for example, a certification signature thatthe key expires. If this is not present orhasa value of zero,thekey never expires. This"sign data" flag isfound only on a self-signature. Preferred symmetric algorithms (array of one-octet values) (Hashed) Symmetric algorithm numbersstating thatindicate which algorithmsthekey holder prefers to use. Thiscertification isan ordered list of octets with the most preferred listed first. It should be assumedfor thatonly algorithms listed are supported byuse. On therecipient's software. Algorithm numbersother hand, the "communications encryption" flag insection 6. Thisa self-signature isonly found onstating aself-signature. Preferred hash algorithms (array of one-octet values) (Hashed) Message digest algorithm numberspreference thatindicate which algorithms thea given keyholder prefersbe used for communications. Note however, that it is a thorny issue toreceive. Like the preferred symmetric algorithms, the listdetermine what isordered. Algorithm numbers are in section 6."communications" and what is "storage." This decision isonly foundleft wholly up to the implementation; the authors of this document do not claim any special wisdom ona self-signature. {{Editor's note:the issue, and realize that accepted opinion may change. Theabove preference (hash algs) is controversial. I included it in for symmetry, because if someone wants to build"split key" (0x10) and "group key" (0x80) flags are placed on aminimal OP implementation, there needs to beself-signature only; they are meaningless on away to tell someone that you won'tcertification signature. They SHOULD beable to verifyplaced only on a direct-key signatureunless it's made with some set of algorithms. It also permits to prefer DSA with RIPEMD-160, for example. If you have an opinion, please state it.}} Preferred compression algorithms (array of one-octet values) (Hashed) Compression algorithm numbers(type 0x1f) or a subkey signature (type 0x18), one thatindicate which algorithms the key holder prefersrefers touse. Likethepreferred symmetric algorithms,key thelist is ordered. Algorithm numbers are in section 6. If thisflag applies to. Signer's User ID This subpacket allows a keyholder to state which user id isnot included, ZIP is preferred. A zero denotes that no compression is preferred;responsible for the signing. Many keyholders use a single keyholder's software may not have compression software.for different purposes, such as business communications as well as personal communications. This subpacket allows such a keyholder to state which of their roles isonly found onmaking aself-signature.signature. Implementations SHOULD implement "preferences". 5.2.3 Signatureexpiration time (4 octet time field) (Hashed) The validity periodTypes There are a number ofthepossible meanings for a signature, which are specified in a signature type octet in any given signature.This isThese meanings are: - 0x00: Signature of a binary document. Typically, this means thenumbersigner owns it, created it, or certifies that it has not been modified. - 0x01: Signature ofseconds aftera canonical text document. Typically, this means thesignature creation timesigner owns it, created it, or certifies that it has not been modified. The signature will be calculated over the text data with its line endings converted to <CR><LF>. - 0x02: Standalone signature. This signatureexpires. If thisisnot present or hasavaluesignature ofzero,only its own subpacket contents. It is calculated identically to a signature over a zero-length binary document. Note that itnever expires. Exportable (1 octetdoesn't make sense to have a V3 standalone signature. - 0x10: The certification ofexportability, 0 for not, 1 for exportable) (Hashed) Signature's exportability status. Packet body containsaboolean flag indicating whether the signature is exportable. Signatures which are not exportable are ignored during exportUser ID andimport operations. IfPublic Key packet. The issuer of thispacket iscertification does notpresent the signature is assumedmake any particular assertion as tobe exportable. Revocable (1 octethow well the certifier has checked that the owner ofrevocability, 0 for not, 1 for revocable) (Hashed) Signature's revocability status. Packet body contains a boolean flag indicating whetherthesignaturekey isrevocable. Signatures whichin fact the person described by the user ID. Note that all PGP "key signatures" are this type of certification. - 0x11: This is a persona certification of a User ID and Public Key packet. The issuer of this certification has notrevocable getdone anylater revocation signatures ignored. They represent a commitment byverification of thesignerclaim thathe cannot revoke his signature forthelifeowner ofhis key. Ifthispacketkey isnot presentthesignatureuser ID specified. - 0x12: This isassumed to be revocable. Trust signature (1 octetthe casual certification of"level" (depth), 1 octeta User ID and Public Key packet. The issuer of this certification has done some casual verification oftrust amount) (Hashed) Signer asserts thatthekeyclaim of identity. - 0x13: This isnot only valid, but also trustworthy, atthespecified level. Level 0positive certification of a User ID and Public Key packet. The issuer of this certification has done substantial verification of thesame meaning as an ordinary validity signature. Level 1 meansclaim of identity. Please note that thesigned keyvagueness of these certification claims isasserted to benot a flaw, but avalid trusted introducer, with the 2nd octetfeature of thebody specifyingsystem. Because PGP places final authority for validity upon thedegreereceiver oftrust. Level 2 meansa certification, it may be thatthe signed key is asserted toone authority's casual certification might betrustedmore rigorous than some other authority's positive certification. These classifications allow a certification authority to issuelevel 1 trust signatures, i.e. that itfine-grained claims. - 0x18: This is used for a"meta introducer". Generally, a level n trustsignatureasserts thatby a signature keyis trustedtoissue level n-1 trust signatures. The trust amount is inbind arange 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 120subkey which will be used forcomplete trust. Regular expression (null-terminated regular expression) (Hashed) Used in conjunction with trustencryption. The signaturepackets (of level > 0) to limit the scope of trust whichisextended. Only signatures bycalculated directly on thetargetsubkey itself, not on any User ID or other packets. - 0x1f: Signature directly on a key This signature is calculated directly onuser IDs which matcha key. It binds theregular expressioninformation in thebody of this packet have trust extended bysignature subpackets to thetrust packet. Additional recipient request (1 octet of class, 1 octet of algid, 20 octets of fingerprint) (Hashed) Key holder requests encryptionkey, and is appropriate toadditional recipient when databe used for subpackets which provide information about the key, such as the revocation key subpacket. It isencryptedalso appropriate for statements that non-self certifiers want tothis username. If the class octet contains 0x80, thenmake about the keyholder strongly requests thatitself, rather than theadditional recipient be added to an encryption. Implementing software may treat this subpacket in any way it sees fit.binding between a key and a name. - 0x20: This signature isfound only onused to revoke aself-signature. Revocation key (1 octet of class, 1 octet of algid, 20 octets of fingerprint) (Hashed) Authorizeskey. The signature is calculated directly on thespecifiedkey being revoked. A revoked key is not toissuebe used. Only revocationself-signatures on this key. Class octet must have bit 0x80 set, other bits are for future expansion to other kinds of signature authorizations.signatures by the key being revoked, or by an authorized revocation key, should be considered. - 0x28: This isfound on a self-signature. Notation Data (4 octets of flags, 2 octets of name length, 2 octets of value length, M octets of name data, N octets of value data) (Hashed) This subpacket describesused to revoke a"notation" on thesubkey. The signaturethatis calculated directly on theissuer wishessubkey being revoked. A revoked subkey is not tomake. The notation has a name and a value, each ofbe used. Only revocation signatures by the top-level signature key whichare strings of octets. There mayis bound to this subkey, or by an authorized revocation key, should bemore than one notation inconsidered. - 0x30: This signature revokes an earlier user ID certification signature (signature class 0x10 through 0x13). It should be issued by the same key which issued the revoked signature, and should have a later creation date than the signature it revokes. - 0x40: Timestamp signature.Notations can be usedThis signature is only meaningful forany extensiontheissuer oftimestamp contained in it. 5.2.4 Computing Signatures All signatures are formed by producing a hash over the signaturecares to make.data, and then using the resulting hash in the signature algorithm. The"flags" field holds four octets of flags. All undefined flags MUST be zero. Defined flags are: First octet: 0x80 = human-readable. This notesignature data istext, a note from one personsimple toanother,compute for document signatures (types 0x00 andhas no meaning to software. Other octets: none. Key server preferences (N octets of flags) (Hashed) This0x01), for which the document itself is the data. For standalone signatures, this is alist of flags that indicate preferences thatnull string. When a signature is made over a key, thekey holder has about howhash data starts with thekey is handled onoctet 0x99, followed by akey server. All undefined flags MUST be zero. First octet: 0x80 = No-modify --two-octet length of the key, and then body of the keyholder requestspacket. (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. Key revocation signatures (types 0x20 and 0x28) hash onlybe modified or updated bythe keyholder orbeing revoked. A certification signature (type 0x10 through 0x13) then hashes the user name being bound to the key. A V3 certification hashes the contents of the name packet, without any header. A V4 certification hashes the constant 0xd4 (which is anauthorized administratorold-style CTB with the length-of-length set to zero), a four-octet number giving the length of thekey server. Thisusername, and then the username data. Once the data body isfound only onhashed, then aself-signature. Preferred key server (String) (Hashed)trailer is hashed. A V3 signature hashes five octets of the packet body, starting from the signature type field. This data isa URLthe 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 ofa key server thatthe hashed subpacket data. Thus, the fields hashed are the signature version, the signature type, the public keyholder prefers be used for updates. Note that keys with multiple user names can have a preferred key server for each user name. Thisalgorithm, the hash algorithm, the hashed subpacket length, and the hashed subpacket body. After all this has been hashed, the resulting hash field isfound only on a self-signature. Implementations SHOULD implement a "preference"used in the signature algorithm, andMAY implement a "request." {{Editor's note: Noneplaced at the end of thepreferences have a way to specify a negative preference (for example, I like Triple-DES, don't use algorithm X). Tacitly,signature packet. 5.3 Symmetric-Key Encrypted Session-Key Packets (Tag 3) The Symmetric-Key Encrypted Session Key packet holds theabsenceconventional-cipher encryption ofan algorithm from a set isanegative preference, but should there be an explicit waysession key used togiveencrypt anegative preference? -jdcc}} {{Editor's note: A missing feature is to invalidate (or revoke)message. Zero or more Encrypted Session Key packets and/or Conventional Encrypted Session Key packets may precede auser id, rather than the entire key. Lots of people want this, and many people have keys cluttered with old work email addresses. There is another related issue, thatSymmetrically Encrypted Data Packet that holds an encrypted message. The message is encrypted withkey rollover -- suppose I'm retiring an old key, but I don't want to have to lose all my certification signatures. It would be nice if there were a way fora session key, and the session keyto transferis itselfto a new one. Lastly, if either (or both) of theseencrypted and stored in the Encrypted Session Key packet or the Conventional Encrypted Session Key packet. If the Symmetrically Encrypted Data Packet isdesirable, do we handle them with a new signature type,preceded by one orwith notations,more Symmetric-Key Encrypted Session Key packets, each specifies a passphrase whichare an extension mechanism. I think that it makes sensemay be used tomakedecrypt the message. This allows arevocation type (because it's analogousmessage tothe other forms of revocation), but rollover mightbebest implemented as an extension. --jdcc}} {{Editor's note: PGP 3 designed, but never implementedencrypted to a number ofother subpacket types. They were: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: - Asignatureone-octet versionnumber;number. The only currently defined version is 4. - Aset ofone-octet number describing the symmetric algorithm used. - A string-to-key (S2K) specifier, length as defined above. - Optionally, the encrypted session keyusage flags (signing key, encryptionitself, which is decrypted with the string-to-key object. If the encrypted session keyfor communication,is not present (which can be detected on the basis of packet length andencryptionS2K specifier size), then the S2K algorithm applied to the passphrase produces the session key forstorage); User ID of the signer; Policy URL; net location ofdecrypting thekey. Some of these options are thingsfile, using theWG has talked about as being a Good Thing -- like flags denoting if asymmetric cipher algorithm from the Symmetric-Key Encrypted Session Key packet. If the encrypted session key isa comm key or a storage key. My designpresent, the result ofsuch a feature would be different thanapplying theother one, though. I think it would be a great idea to have a URL that's a locationS2K algorithm tofindthekey, so people who preferpassphrase is used tohave a web, ftp, or finger location can use those. However, some of them (like a URL) are also perfect for designing indecrypt just that encrypted session key field, using CFB mode withextensions. After all, we only have 128 subpacket constants. --jdcc}} 5.2.3 Signature Types There are a number of possible meanings for a signature, which are specified in a signature type octet in any given signature. These meanings are: - 0x00: Signaturean IV ofa binary document. Typically, this means the signer owns it, created it, or certifies that it has not been modified. - 0x01: Signatureall zeros. The decryption result consists of acanonical text document. Typically, this means the signer owns it, created it, or certifiesone-octet algorithm identifier thatit has not been modified. The signature will be calculated overspecifies thetextual data with its line endings convertedconventional encryption algorithm used to<CR><LF>. - 0x02: Standalone signature. This signature is a signature of only its own subpacket contents. Itencrypt the following Symmetrically Encrypted Data Packet, followed by the session key octets themselves. Note: because an all-zero IV iscalculated identically toused for this decryption, the S2K specifier MUST use asignature oversalt value, either azero-length binary document. - 0x10: The generic certification ofaUser ID and Public Key packet.Salted S2K or an Iterated-Salted S2K. Theissuer of this certification doessalt value will insure that the decryption key is notmakerepeated even if the passphrase is reused. 5.4 One-Pass Signature Packets (Tag 4) The One-Pass Signature packet precedes the signed data and contains enough information to allow the receiver to begin calculating anyparticular assertion ashashes needed tohow wellverify thecertifier has checked thatsignature. It allows theownerSignature Packet to be placed at the end of thekey is in factmessage, so that theperson described bysigner can compute theuser ID. Note that allentire signed message in one pass. A One-Pass Signature does not interoperate with PGP"key signatures" are this type2.6.x or earlier. The body ofcertification.this packet consists of: -0x11: ThisA one-octet version number. The current version isa persona certification3. - A one-octet signature type. Signature types are described in section 5.2.3. - 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 aUser ID and Public Key packet. It meansflag showing whether the signature is nested. A zero value indicates that theissuer of this certification has not done any verification ofnext packet is another One-Pass Signature packet which describes another signature to be applied to theclaim thatsame message data. 5.5 Key Material Packet A key material packet contains all theownerinformation about a public or private key. There are four variants of thiskey is the user ID specified. Note that no released version of PGP has generatedpacket type, and two major versions. Consequently, thistype of certification. - 0x12: Thissection isthe casual certification of a User ID andcomplex. 5.5.1 Key Packet Variants 5.5.1.1 Public Keypacket. It means that the issuer of this certification has done some casual verification of the claimPacket (Tag 6) A Public Key packet starts a series ofidentity. Notepackets thatno version of PGPforms an OP key (sometimes called an OP certificate). 5.5.1.2 Public Subkey Packet (Tag 14) A Public Subkey packet (tag 14) hasgenerated this type of certification, nor is there any definition of what constitutes a casual certification. - 0x13: This isexactly thepositive certification ofsame format as aUser ID andPublic Keypacket. It means thatpacket, but denotes a subkey. One or more subkeys may be associated with a top-level key. By convention, theissuer of this certification has done substantial verification oftop-level key provides signature services, and theclaim of identity. Note thatsubkeys provide encryption services. Note: in PGP 2.6.X, tag 14 was intended to indicate a comment packet. This tag was selected for reuse because no previous version of PGPhas generated this type of certification, nor is there any definition of what constitutesever emitted comment packets but they did properly ignore them. Public Subkey packets are ignored by PGP 2.6.X and do not cause it to fail, providing apositive certification. Please also note thatlimited degree of backwards compatibility. 5.5.1.3 Secret Key Packet (Tag 5) A Secret Key packet contains all thevagueness of these certification systemsinformation that isnotfound in aflaw,Public Key packet, including the public key material, buta feature ofalso includes thesystem. Because PGP places final authority for validity uponsecret key material after all thereceiver of a certification, it may be that one authority's casual certification might be more rigorous than some other authority's positive certification. {{Editor's note: While therepublic key fields. 5.5.1.4 Secret Subkey Packet (Tag 7) A Secret Subkey packet (tag 7) isa scale of identification signatures intherange 0x10 to 0x13, mostsubkey analog ofthem have never been implemented or used. Current implementations only use 0x10,the"generic certification." ShouldSecret Key packet, and has exactly theothers be removed? RFC 1991 went to some trouble to explain which onessame format. 5.5.2 Public Key Packet Formats There are two versions of key-material packets. Version 3 packets weredefinedfirst generated PGP 2.6. Version 2 packets are identical in format to Version 3 packets, butnot implemented,are generated by PGP 2.5 orread but not generated. I think we shouldbefore. PGP 5.0 introduces version 4 packets, with new fields and semantics. PGP 2.6.X will notdo that. If we define them, they should beaccept key-material packets with versions greater than 3. OP implementations SHOULD create keys with version 4 format. An implementation MAYfeatures atgenerate 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. A version 3 public key or public subkey packet contains: - A one-octet version number (3). - A four-octet number denoting thevery least. If we're not going to use them, they shouldn't be intime that thespec. --jdcc}}key was created. -0x18: This is used for a signature by a signatureA two-octet number denoting the time in days that this keyto bind a subkey which will be used for encryption. The signatureiscalculated directly on the subkey itself,valid. If this number is zero, then it does noton any User ID or other packets.expire. -0x20: This signature is used to revoke a key. The signature is calculated directly onA one-octet number denoting the public keybeing revoked. A revokedalgorithm of this keyis not to be used. Only revocation signatures by- A series of multi-precision integers comprising the keybeing revoked, or by an authorized revocation key, should be considered.material: -0x28: This is used to revokeasubkey.multiprecision integer (MPI) of RSA public modulus n; - an MPI of RSA public encryption exponent e. Thesignature is calculated directly onfingerprint of thesubkey being revoked. A revoked subkeykey isnot to be used. Only revocation signaturesformed by hashing the body (but not the two-octet length) of the MPIs that form thetop-level signaturekeywhich is bound to this subkey, ormaterial (public modulus n, followed by exponent e) with MD5. The eight-octet key ID of the key consists of the low 64 bits of the public modulus of anauthorized revocation key, should be considered. - 0x30: This signature revokes an earlier userRSA key. Since the release of V3 keys, there have been a number of improvements desired in the key format. For example, if the key IDcertification signature (signature class 0x10 - 0x13). It should be issued byis a function of the public modulus, it is easy for a person to create a key that has the same keywhich issuedID as some existing key. Similarly, MD5 is no longer therevoked signature,preferred hash algorithm, andshould havenot hashing the length of an MPI with its body increases the chances of alater creation date. - 0x40: Timestamp signature. {{Editor's note:fingerprint collision. Thetimestamp signatureversion 4 format isleft over from RFC 1991, and has never been fully designed nor implemented. Is thissimilar to thesortversion 3 format except for the absence ofthing best handled by notations? --jdcc}} {{Editor's note: It would be nice to havea 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 thatapplied tothe keyalone, rather than awas created. - A one-octet number denoting the public keyplus a user name. Perhapsalgorithm of this key - A series of multi-precision integers comprising the key material. This algorithm-specific portion is: Algorithm Specific Fields for RSA public keys: - multiprecision integer (MPI) of RSA public modulus n; - MPI of RSA public encryption exponent e. Algorithm Specific Fields for DSA public keys: - MPI of DSA prime p; - MPI of DSA group order q (q isbest done withanotation. --jdcc}} {{Editor's note: Thereprime divisor of p-1); - MPI of DSA group generator g; - MPI of DSA public key value y (= g**x where x ispresently no waysecret). Algorithm Specific Fields fora key-signer (a.k.a. certifier) to sign a main key along with a subkey. There are a numberElgamal public keys: - MPI ofuseful situations for a setElgamal prime p; - MPI ofkeys (main plus subkeys) to all be signed together. How do we solve this? --jdcc}} 5.3 Conventional Encrypted Session-Key Packets (Tag 3) The Conventional Encrypted Session Key packet holds the conventional-cipher encryptionElgamal group generator g; - MPI ofa sessionElgamal public keyused to encrypt a message. Zero or more Encrypted Session Key packets and/or Conventional Encrypted Sessionvalue y (= g**x where x is secret). 5.5.3 Secret Keypackets may precede a Symmetrically Encrypted DataPacketthat holds an encrypted message.Formats Themessage is encrypted with a session key, and the session key is itself encrypted and stored in the Encrypted SessionSecret Keypacket orand Secret Subkey packets contain all theConventional Encrypted Session Key packet. Ifdata of theSymmetrically Encrypted Data Packet is preceded by one or more Conventional Encrypted SessionPublic Key and Public Subkey packets,each specifies a passphrase which may be used to decrypt the message. This allows a message to bewith additional algorithm-specific secret key data appended, in encryptedto 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.form. Thebody of thispacketconsists of:contains: - Aone-octet version number. The only currently defined versionPublic Key or Public Subkey packet, as described above - One octet indicating string-to-key usage conventions. 0 indicates that the secret key data is4.not encrypted. 255 indicates that a string-to-key specifier is being given. Any other value is a conventional encryption algorithm specifier. -A[Optional] If string-to-key usage octet was 255, a one-octetnumber describing the symmetric algorithm used.conventional encryption algorithm. -A[Optional] If string-to-key(S2K) specifier,usage octet was 255, a string-to-key specifier. The length of the string-to-key specifier is implied by its type, asdefineddescribed above. -Optionally,[Optional] If secret data is encrypted, eight-octet Initial Vector (IV). - Encrypted multi-precision integers comprising theencrypted sessionsecret keyitself, which is decrypted withdata. These algorithm-specific fields are as described below. - Two-octet checksum of thestring-to-key object. Ifplaintext of theencrypted session key is not present (which can be detected onalgorithm-specific portion (sum of all octets, mod 65536). Algorithm Specific Fields for RSA secret keys: - multiprecision integer (MPI) of RSA secret exponent d. - MPI of RSA secret prime value p. - MPI of RSA secret prime value q (p < q). - MPI of u, thebasismultiplicative inverse ofpacket length and S2Kp, mod q. Algorithm Specific Fields for DSA secret keys: - MPI of DSA secret exponent x. Algorithm Specific Fields for Elgamal secret keys: - MPI of Elgamal secret exponent x. Secret MPI values can be encrypted using a passphrase. If a string-to-key specifiersize), thenis given, that describes theS2Kalgorithmappliedfor converting the passphrase to a key, else a simple MD5 hash of the passphrase is used. Implementations SHOULD use a string-to-key specifier; the simple hash is for backwards compatibility. The cipher for encrypting thepassphrase producesMPIs is specified in thesessionsecret keyfor decryptingpacket. Encryption/decryption of thefile,secret data is done in CFB mode using thesymmetric cipher algorithmkey created from theConventional Encrypted Session Key packet. Ifpassphrase and theencrypted session keyInitial Vector from the packet. A different mode ispresent,used with RSA keys than with other key formats. With RSA keys, theresult of applyingMPI bit count prefix (i.e., theS2K algorithm tofirst two octets) is not encrypted. Only thepassphraseMPI non-prefix data isused to decrypt justencrypted. Furthermore, the CFB state is resynchronized at the beginning of each new MPI value, so thatencrypted session key field, usingthe CFBmodeblock boundary is aligned withan IV of all zeros. The decryption result consiststhe start of the MPI data. With non-RSA keys, aone-octet algorithm identifiersimpler method is used. All secret MPI values are encrypted in CFB mode, including the MPI bitcount prefix. The 16-bit checksum thatspecifiesfollows theconventional encryption algorithm used to encryptalgorithm-specific portion is thefollowing Symmetrically Encrypted Data Packet, followed byalgebraic sum, mod 65536, of thesession keyplaintext of all the algorithm-specific octetsthemselves. Note: because an all-zero IV(including MPI prefix and data). With RSA keys, the checksum isused for this decryption,stored in theS2K specifier MUST use a salt value, either a a Salted S2K or an Iterated-Salted S2K. The saltclear. With non-RSA keys, the checksum is encrypted like the algorithm-specific data. This valuewill insureis used to check that thedecryption keypassphrase was correct. 5.6 Compressed Data Packet (Tag 8) The Compressed Data packet contains compressed data. Typically, this packet isnot repeated even iffound as thepassphrase is reused. 5.4 One-Passcontents of an encrypted packet, or following a SignaturePackets (Tag 4) Theor One-Pass Signaturepacket precedes the signed datapacket, and containsenough information to allow the receiver to begin calculating any hashes needed to verify the signature. It allowsliteral data packets. The body of this packet consists of: - One octet that gives theSignature Packetalgorithm used tobe placed atcompress theendpacket. - The remainder of themessage, so that the signer can compute the entire signed message in one pass.packet is compressed data. AOne-Pass Signature does not interoperateCompressed Data Packet's body contains an RFC1951 DEFLATE block that compresses some set of packets. See section "Packet Composition" for details on how messages are formed. 5.7 Symmetrically Encrypted Data Packet (Tag 9) The Symmetrically Encrypted Data packet contains data encrypted withPGP 2.6.xa conventional (symmetric-key) algorithm. When it has been decrypted, it will typically contain other packets (often literal data packets orearlier.compressed data packets). The body of this packet consists of: -A one-octet version number.Encrypted data, the output of the selected conventional cipher operating in PGP's variant of Cipher Feedback (CFB) mode. Thecurrent version is 3. - A one-octet signature type. Signature types are describedconventional cipher used may be specified insection 5.2.3. - A one-octet number describingan Encrypted Session Key or Conventional Encrypted Session Key packet which precedes thehash algorithm used. - A one-octet number describingSymmetrically Encrypted Data Packet. In that case, thepublic key algorithm used. - An eight-octet number holdingcipher algorithm octet is prepended to the session keyIDbefore it is encrypted. If no packets of these types precede thesigning key. - A one-octet number holding a flag showing whether the signature is nested. A zero value indicates thatencrypted data, thenext packetIDEA algorithm isanother One-Pass Signature packet which describes another signature to be applied toused with thesame message data. 5.5 Key Material Packet Asession keymaterial packet contains allcalculated as theinformation about a public or private key. There are four variantsMD5 hash ofthis packet type, and two major versions. Consequently, this sectionthe passphrase. The data iscomplex. 5.5.1 Key Packet Variants 5.5.1.1 Public Key Packet (Tag 6) A Public Key packet startsencrypted in CFB mode, with aseriesCFB shift size equal to the cipher's block size. The Initial Vector (IV) is specified as all zeros. Instead ofpackets that forms an OP key (sometimes calledusing an IV, OPcertificate). 5.5.1.2 Public Subkey Packet (Tag 14) A Public Subkey packet (tag 14) has exactly the same format as a Public Key packet, but denotes a subkey. One or more subkeys may be associated withprefixes atop-level key. By convention,10 octet string to thetop-level key provides signature services,data before it is encrypted. The first eight octets are random, and thesubkeys provide encryption services. Note: in PGP 2.6.X, tag 14 was intended to indicate a comment packet. This tag was selected for reuse because no previous version9th and 10th octets are copies of the 7th and 8th octets, respectivelly. After encrypting the first 10 octets, the CFB state is resynchronized if the cipher block size is 8 octets or less. The last 8 octets ofPGP ever emitted comment packets but they did properly ignore them. Public Subkey packetsciphertext areignored by PGP 2.6.Xpassed through the cipher anddo not cause it to fail, providing a limited degree of backwards compatibility. 5.5.1.3 Secret Key Packet (Tag 5) A Secret Key packet contains alltheinformation thatblock boundary isfoundreset. The repetition of 16 bits ina Public Key packet, includingthepublic key material, but also includes80 bits of random data prepended to thesecret key material after allmessage allows thepublicreceiver to immediately check whether the session keyfields. 5.5.1.4 Secret Subkeyis correct. 5.8 Marker Packet (Obsolete Literal Packet) (Tag7) A Secret Subkey packet (tag 7) is the subkey analog10) An experimental version of PGP used this packet as theSecret KeyLiteral packet,and has exactly the same format. 5.5.2 Public Key Packet Formats There are two versionsbut no released version ofkey-material packets. Version 3 packets were first generatedPGP2.6. Version 2 packets are identical in format to Version 3 packets, but aregeneratedby PGP 2.5 or before. PGP 5.0 introduces version 4 packets,Literal packets withnew fieldsthis tag. With PGP 5.x, this packet has been re-assigned andsemantics.is reserved for use as the Marker packet. The body of this packet consists of: - The three octets 0x60, 0x47, 0x60 (which spell "PGP" in UTF-8). Such a packet MUST be ignored when received. It may be placed at the beginning of a message that uses features not available in PGP 2.6.Xwill not accept key-material packets with versions greater than 3. OP implementations SHOULD create keys with version 4 format. An implementation MAY generate a V3 keyin order toensure interoperability with old software; note, however,cause thatV4 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. A version 3 public key or public subkey packet contains: - A one-octetversionnumber (3). - A four-octet number denoting the timeto report that newer software necessary to process thekey was created. -message. 5.9 Literal Data Packet (Tag 11) Atwo-octet number denotingLiteral Data packet contains thetime in daysbody of a message; data thatthis keyisvalid. If this number is zero, then it doesnotexpire. - A one-octet number denoting the public key algorithmto be further interpreted. The body of thiskeypacket consists of: - Aseries of multi-precision integers comprisingone-octet field that describes how thekey material: -data is formatted. If it is amultiprecision integer (MPI) of RSA public modulus n; - an MPI of RSA public encryption exponent e. The fingerprint of'b' (0x62), then thekeyliteral packet contains binary data. If it isformeda 't' (0x74), then it contains text data, and thus may need line ends converted to local form, or other text-mode changes. RFC 1991 also defined a value of 'l' as a 'local' mode for machine-local conversions. This use is now deprecated. - File name as a string (one-octet length, followed byhashingfile name), if thebody (but notencrypted data should be saved as a file. If thetwo-octet length) ofspecial name "_CONSOLE" is used, theMPIsmessage is considered to be "for your eyes only". This advises thatformthekey material (public modulus n, followed by exponent e) with MD5. The eight-octet key ID ofmessage data is unusually sensitive, and thekey consists ofreceiving program should process it more carefully, perhaps avoiding storing thelow 64 bits ofreceived data to disk, for example. - A four-octet number that indicates thepublic modulusmodification date ofan RSA key. Sincetherelease of V3 keys, there have been a number of improvements desired infile, or thekey format. For example, ifcreation time of thekey ID ispacket, or afunctionzero that indicates the present time. - The remainder of thepublic modulus, itpacket iseasy for a personliteral data. Text data is stored with <CR><LF> text endings (i.e. network-normal line endings). These should be converted tocreate a key that hasnative line endings by thesame key ID as some existing key. Similarly, MD5receiving software. 5.10 Trust Packet (Tag 12) The Trust packet isno longer the preferred hash algorithm,used only within keyrings and is nothashingnormally exported. Trust packets contain data that record thelengthuser's specifications ofan MPIwhich key holders are trustworthy introducers, along withits body increases the chancesother information that implementing software uses for trust information. 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 ofa fingerprint collision. The version 4 formatdata which issimilarintended to represent theversion 3 format except for the absencename and email address ofa validity period. This has been moved tothesignature packet. In addition, fingerprints of version 4 keyskey holder. By convention, it includes an RFC822 mail name, but there arecalculated differently from version 3 keys, as described elsewhere. A version 4no restrictions on its content. The packetcontains: - A one-octet version number (4). - A four-octet number denoting the time thatlength in thekey was created. - A one-octet number denotingheader specifies thepublic key algorithm of this key - A serieslength ofmulti-precision integers comprisingthekey material. This algorithm-specific portion is: Algorithm Specific Fields for RSA public keys: - multiprecision integer (MPI) of RSA public modulus n; - MPI of RSA public encryption exponent e. Algorithm Specific Fields for DSA public keys: - MPI of DSA prime p; - MPI of DSA group order q (quser name. If it isa prime divisor of p-1); - MPI of DSA group generator g; - MPI of DSA public key value y (= g**x where xtext, it issecret). Algorithm Specific Fieldsencoded in UTF-8. 6. Radix-64 Conversions As stated in the introduction, OP's underlying native representation forElgamal public keys: - MPIobjects is a stream ofElgamal prime p; - MPIarbitrary octets, and some systems desire these objects to be immune to damage caused by character set translation, data conversions, etc. In principle, any printable encoding scheme that met the requirements ofElgamal group generator g; - MPIthe unsafe channel would suffice, since it would not change the underlying binary bit streams ofElgamal public key value y (= g**x where x is secret). 5.5.3 Secret Key Packet Formats The Secret Key and Secret Subkey packets contain allthe native OP data structures. The OP standard specifies one such printable encoding scheme to ensure interoperability. OP's Radix-64 encoding is composed of two parts: a base64 encoding of thePublic Keybinary data, andPublic Subkey packets, with additional algorithm-specific secret key data appended, in encrypted form.a checksum. Thepacket contains: - A Public Key or Public Subkey packet, as described above - One octet indicating string-to-key usage conventions. 0 indicates thatbase64 encoding is identical to thesecret key dataMIME base64 content-transfer-encoding [RFC 2045, Section 6.8]. An OP implementation MAY use ASCII Armor to protect the raw binary data. The checksum isnot encrypted. 255 indicates thatastring-to-key specifier24-bit CRC converted to four characters of radix-64 encoding by the same MIME base64 transformation, preceded by an equals sign (=). The CRC isbeing given. Any other valuecomputed by using the generator 0x864CFB and an initialization of 0xB704CE. The accumulation isa conventional encryptiondone on the data before it is converted to radix-64, rather than on the converted data. A sample implementation of this algorithmspecifier. - [Optional] If string-to-key usage octet was 255, a one-octet conventional encryption algorithm. - [Optional] If string-to-key usage octet was 255, a string-to-key specifier.is in the next section. The checksum with its leading equal sign MAY appear on the first line after the Base64 encoded data. Rationale for CRC-24: Thelengthsize of 24 bits fits evenly into printable base64. The nonzero initialization can detect more errors than a zero initialization. 6.1 An Implementation of thestring-to-key specifier is implied by its type, as described above. - [Optional] If secretCRC-24 in "C" #define CRC24_INIT 0xb704ce #define CRC24_POLY 0x1864cfb crc24 crc_bytes(unsigned char *bytes, size_t len) { crc24 crc = CRC_INIT; int i; while (len--) { crc ^= *bytes++; for (i = 0; i < 8; i++) { crc <<= 1; if (crc & 0x1000000) crc ^= CRC24_POLY; } } return crc; } 6.2 Forming ASCII Armor When OP encodes datais encrypted, eight-octet Initial Vector (IV). - Encrypted multi-precision integers comprisinginto ASCII Armor, it puts specific headers around thesecret key data. These algorithm-specific fields are as described below. - Two-octet checksum ofdata, so OP can reconstruct theplaintextdata later. OP informs the user what kind of data is encoded in thealgorithm-specific portion (sumASCII armor through the use ofall octets, mod 65536). Algorithm Specific Fields for RSA secret keys:the headers. Concatenating the following data creates ASCII Armor: -multiprecision integer (MPI)An Armor Header Line, appropriate for the type ofRSA secret exponent d.data -MPI of RSA secret prime value p.Armor Headers -MPI of RSA secret prime value q (p < q).A blank (zero-length, or containing only whitespace) line -MPI of u, the multiplicative inverse of p, mod q. Algorithm Specific Fields for DSA secret keys:The ASCII-Armored data -MPI of DSA secret exponent x. Algorithm Specific Fields for Elgamal secret keys:An Armor Checksum -MPI of Elgamal secret exponent x. Secret MPI values can be encrypted using a passphrase. If a string-to-key specifier is given, that describes the algorithm for convertingThe Armor Tail, which depends on thepassphrase to a key, else a simple MD5 hashArmor Header Line. An Armor Header Line consists of thepassphrase is used. Implementations SHOULD use a string-to-key specifier;appropriate header line text surrounded by five (5) dashes ('-', 0x2D) on either side of thesimple hash is for backwards compatibility.header line text. Thecipher for encrypting the MPIsheader line text isspecified inchosen based upon thesecret key packet. Encryption/decryptiontype ofthe secretdata that isdonebeing encoded inCFB mode using the key created from the passphraseArmor, andthe Initial Vector from the packet. A different modehow it is being encoded. Header line texts include the following strings: BEGIN PGP MESSAGE usedwith RSAfor signed, encrypted, or compressed files BEGIN PGP PUBLIC KEY BLOCK used for armoring public keysthan with other key formats. With RSA keys, the MPI bit count prefix (i.e.,BEGIN PGP PRIVATE KEY BLOCK used for armoring private keys BEGIN PGP MESSAGE, PART X/Y used for multi-part messages, where thefirst two octets)armor isnot encrypted. Only the MPI non-prefix datasplit amongst Y parts, and this isencrypted. Furthermore,theCFB stateXth part out of Y. BEGIN PGP MESSAGE, PART X used for multi-part messages, where this isresynchronized atthebeginningXth part ofeach new MPI value, soan unspecified number of parts. Requires the MESSAGE-ID Armor Header to be used. BEGIN PGP SIGNATURE used for detached signatures, OP/MIME signatures, and signatures following clearsigned messages The Armor Headers are pairs of strings that can give theCFBuser or the receiving OP message blockboundary is aligned withsome information about how to decode or use thestartmessage. The Armor Headers are a part of theMPI data. With non-RSA keys,armor, not asimpler method is used. All secret MPI valuespart of the message, and hence areencrypted in CFB mode, includingnot protected by any signatures applied to theMPI bitcount prefix.message. The16-bit checksum that follows the algorithm-specific portionformat of an Armor Header is that of a key-value pair. A colon (':' 0x38) and a single space (0x20) separate thealgebraic sum, mod 65536,key and value. OP should consider improperly formatted Armor Headers to be corruption of theplaintextASCII Armor. Unknown keys should be reported to the user, but OP should continue to process the message. Currently defined Armor Header Keys are: - "Version", which states the OP Version used to encode the message. - "Comment", a user-defined comment. - "MessageID", a 32-character string of printable characters. The string must be the same for all parts of a multi-part message that uses thealgorithm-specific octets (including MPI prefix and data). With RSA keys,"PART X" Armor Header. MessageID strings should be unique enough that thechecksum is stored inrecipient of theclear. With non-RSA keys,mail can associate all the parts of a message with each other. A good checksum or cryptographic hash function isencrypted like the algorithm-specific data. This valuesufficent. The MessageID should not appear unless it isused to check thatin a multi-part message. If it appears at all, it MUST be computed from thepassphrase was correct. 5.6 Compressed Data Packet (Tag 8) The Compressed Data packet contains compressed data. Typically, this packetmessage in a deterministic fashion, rather than contain a purely random value. This isfound asto allow anyone to determine that thecontents of an encrypted packet, or followingMessageID cannot serve as aSignature or One-Pass Signature packet, and contains literal data packets. The bodycovert means ofthis packet consists of: - One octet that givesleaking cryptographic key information. The Armor Tail Line is composed in thealgorithm used to compresssame manner as thepacket. - The remainder ofArmor Header Line, except thepacketstring "BEGIN" iscompressed data. A Compressed Data Packet's body contains an RFC1951 DEFLATE block that compresses some setreplaced by the string "END." 6.3 Encoding Binary in Radix-64 The encoding process represents 24-bit groups ofpackets. See section 7 for details on how messagesinput bits as output strings of 4 encoded characters. Proceeding from left to right, a 24-bit input group is formed by concatenating three 8-bit input groups. These 24 bits areformed. 5.7 Symmetrically Encrypted Data Packet (Tag 9) The Symmetrically Encrypted Data packet contains data encrypted withthen treated as four concatenated 6-bit groups, each of which is translated into aconventional (symmetric-key) algorithm.single digit in the Radix-64 alphabet. Whenit has been decrypted, it will typically contain other packets (often literal data packets or compressed data packets). The body of this packet consists of: - Encrypted data,encoding a bit stream with theoutput ofRadix-64 encoding, theselected conventional cipher operating in PGP's variant of Cipher Feedback (CFB) mode. The conventional cipher used maybit stream must bespecifiedpresumed to be ordered with the most-significant-bit first. That is, the first bit inan Encrypted Session Key or Conventional Encrypted Session Key packet which precedestheSymmetrically Encrypted Data Packet. In that case,stream will be thecipher algorithm octet is prepended tohigh-order bit in thesession key before it is encrypted. If no packets of these types precedefirst 8-bit byte, and theencrypted data,eighth bit will be theIDEA algorithmlow-order bit in the first 8-bit byte, and so on. +--first octet--+-second octet--+--third octet--+ |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +-----------+---+-------+-------+---+-----------+ |5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0| +--1.index--+--2.index--+--3.index--+--4.index--+ Each 6-bit group is usedwith the session key calculatedasthe MD5 hashan index into an array of 64 printable characters from thepassphrase.table below. The character referenced by the index is placed in the output string. Value Encoding Value Encoding Value Encoding Value Encoding 0 A 17 R 34 i 51 z 1 B 18 S 35 j 52 0 2 C 19 T 36 k 53 1 3 D 20 U 37 l 54 2 4 E 21 V 38 m 55 3 5 F 22 W 39 n 56 4 6 G 23 X 40 o 57 5 7 H 24 Y 41 p 58 6 8 I 25 Z 42 q 59 7 9 J 26 a 43 r 60 8 10 K 27 b 44 s 61 9 11 L 28 c 45 t 62 + 12 M 29 d 46 u 63 / 13 N 30 e 47 v 14 O 31 f 48 w (pad) = 15 P 32 g 49 x 16 Q 33 h 50 y Thedata is encryptedencoded output stream must be represented inCFB mode, with a CFB shift size equal to the cipher's block size [Ref]. The Initial Vector (IV) is specified as all zeros. Insteadlines ofusing an IV, OP prepends a 10 octet string to the data before itno more than 76 characters each. Special processing isencrypted. The first eight octetsperformed if fewer than 24 bits arerandom, andavailable at the9th and 10th octets are copiesend of the7th and 8th octets, respectivelly. After encrypting the first 10 octets, the CFB state is resynchronized if the cipher block size is 8 octets or less.data being encoded. There are three possibilities: - The last8 octets of ciphertext are passed through the cipher and the block boundarydata group has 24 bits (3 octets). No special processing isreset.needed. - Therepetition oflast data group has 16 bitsin the 80 bits of random data prepended to the message allows the receiver to immediately check whether the session key is correct. 5.8 Marker Packet (Obsolete Literal Packet) (Tag 10) An experimental version of PGP used this packet(2 octets). The first two 6-bit groups are processed asthe Literal packet, but no released version of PGP generated Literal packets with this tag. With PGP 5.x, this packetabove. The third (incomplete) data group hasbeen re-assignedtwo zero-value bits added to it, and isreserved for useprocessed as above. A pad character (=) is added to theMarker packet. The body of this packet consists of:output. - Thethree octets 0x60, 0x47, 0x60 (which spell "PGP" in UTF-8). Such a packet should be ignored on input. It may be placed at the beginning of a message that uses features not available in PGP 2.6.X in order to cause that version to report that newer software necessary to process the message. 5.9 Literal Data Packet (Tag 11) A Literal Data packet contains the body of a message;last datathatgroup has 8 bits (1 octet). The first 6-bit group isnot to be further interpreted.processed as above. Thebody of this packet consists of: - A one-octet field that describes how thesecond (incomplete) data group has four zero-value bits added to it, and isformatted. If it is a 'b' (0x62), thenprocessed as above. Two pad characters (=) are added to theliteral packet contains binaryoutput. 6.4 Decoding Radix-64 Any characters outside of the base64 alphabet are ignored in Radix-64 data.If it is a 't' (0x74), then it contains text data, and thus may needDecoding software must ignore all lineends converted to local form,breaks or othertext-mode changes. RFC 1991 also definedcharacters not found in the table above. In Radix-64 data, characters other than those in the table, line breaks, and other white space probably indicate avalue of 'l' astransmission error, about which a'local' mode for machine-local conversions. This use is now deprecated. - File name aswarning message or even astring (one-octet length, followed by file name), if the encrypted data shouldmessage rejection might besaved as a file. If the special name "_CONSOLE"appropriate under some circumstances. Because it isused,used only for padding at themessage is considered toend of the data, the occurrence of any "=" characters may be"for your eyes only". This advisestaken as evidence that themessageend of the data has been reached (without truncation in transit). No such assurance isunusually sensitive, and the receiving program should process it more carefully, perhaps avoiding storingpossible, however, when thereceived data to disk, for example. -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 Decimal: 5 15 46 28 0 61 37 63 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 8-bit: 00010100 11111011 10011100 | 00000011 pad with 0000 6-bit: 000101 001111 101110 011100 | 000000 110000 Decimal: 5 15 46 28 0 48 pad with = = Output: F P u c Afour-octet number that indicates the modification date of the file, or the creation timew = = 6.6 Example ofthe packet, or a zeroan ASCII Armored Message -----BEGIN PGP MESSAGE----- Version: OP V0.0 owFbx8DAYFTCWlySkpkHZDKEFCXmFedmFhdn5ucpZKdWFiv4hgaHKPj5hygUpSbn l6UWpabo8XIBAA== =3m1o -----END PGP MESSAGE----- Note thatindicates the present time. - The remainder of the packet is literal data. Text datathis example isstored with <CR><LF> text endings. This should be converted to native line endingsindented bythe receiving software. 5.10 Trust Packet (Tag 12) The Trust packet is used only within keyrings andtwo spaces. 7. Cleartext signature framework It isnot normally exported. Trust packets contain data that record the user's specifications of which key holders are trustworthy introducers, along with other information that implementing software uses for trust information. Trust packets SHOULD NOT be emitted to output streams that are transferreddesirable toother users, and they SHOULD be ignored on any input other than local keyring files. {{Editor's note: I have brushed asidesign a textual octet stream without ASCII armoring thedescription ofstream itself, so theold PGP trust packets forsigned text is still readable without special software. In order to bind anumber of reasons. They are context dependent; their meaning depends on the packet preceding them insignature to such akeyring. Therecleartext, this framework isalso a security problem with trust packets. For example, malicious software can writeused. (Note that RFC 2015 defines another way to clear sign messages for environments that support MIME.) The cleartext signed message consists of: - The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on anew public keysingle line, - Zero or more "Hash" Armor Headers, - Exactly one empty line not included intoa user's key ring with trust packets that make it trusted. A number of us have discussed this problem, and thinkthe message digest, - The dash-escaped cleartext thattrust information should always be self-signed to act as an integrity check, but other people may have other solutions. My solutionisto make trust packets implementation dependent. They are not emitted on exportincluded into the message digest, - The ASCII armored signature(s) including the Armor Header andignored on import. Because of this, theyArmor Tail Lines. If the "Hash" armor header is given, the specified message digest algorithm is used for the signature. If there arearguably outno such headers, SHA-1 is used. If more than one message digest is used in the signature, the "Hash" armor header contains a comma-delimited list ofscopeused message digests. Current message digest names are: - "SHA1" - "MD5" - "RIPEMD160" The cleartext content ofthis document anyway. Given thatthePGP implementation of trust packets has security flaws, this seems tomessage must also be dash-escaped. Dash escaped cleartext is thebest way to dealordinary cleartext where every line starting withthem. --jdcc}} 5.11 User ID Packet (Tag 13) A User ID packet consists of data whicha dash '-' (0x2D) isintended to representprefixed by thenamesequence dash '-' (0x2D) andemail addressspace ' ' (0x20). This prevents the parser from recognizing armor headers of thekey holder. By convention, it includes an RFC822 mail name, but there are no restrictionscleartext itself. The message digest is computed using the cleartext itself, not the dash escaped form. As with binary signatures onits content.text documents, a cleartext signature is calculated on the text using canonical <CR><LF> line endings. Thepacket length inline ending (i.e. theheader specifies<CR><LF>) before thelength of'-----BEGIN PGP SIGNATURE-----' line that terminates theuser name. If it is text, itsigned text isencoded in UTF-8. {{Editor's note: PRZ thinks there should be more typesnot considered part of"user ids" other thanthetraditional name, such as photos,signed text. Also, any trailing whitespace (spaces, andso on. The above definition, which assiduously avoids saying thattabs, 0x09) at thecontentend of any line is ignored when thepacketcleartext signature isa counted string,calculated. 8. Regular Expressions A regular expression isone potential way to handle it. Another would be to explicitly statezero or more branches, separated by `|'. It matches anything thatthis packetmatches one of the branches. A branch is zero or more pieces, concatenated. It matches astring, and introducematch for the first, followed by afree-form user identification packet.match for the second, etc. Arelated issue with this document is that sometimes it says "user id" and sometimes "user name." We need some work here. Present planpiece isto use "User ID" everywhere. --jdcc}} {{Editor's note: Carl Ellison pointed out to me that if we have non-exportable (local to one's own keyring) usernames that I can assign to keys I use, then essentially we have SDSI naming in PGP. Thisan atom possibly followed by `*', `+', or `?'. An atom followed by `*' matches a sequence of 0 or more matches of the atom. An atom followed by `+' matches a sequence of 1 or more matches of the atom. An atom fol- lowed by `?' matches a match of the atom, or the null string. An atom is aGood Thing,regular expression inmy opinion, but we have to haveparentheses (matching away to define it. --jdcc}} 5.12 Comment Packet (Tag 16) A Comment packet is usedmatch forholding data that is not relevant to software. Comment packets should be ignored. {{Editor's note: should? Must? What does it mean to ignore them? For example, if it's desirable to showthe regular expression), a range (see below), `.' (matching any single character), `^' (matching the null string at the beginning of the input string), `$' (matching the null string at the end of the input string), acomment to`\' followed by auser, then how doessingle character (matching thatinteract with should/must andchar- acter), or asuitable definition of "ignore." I believesingle character with no other significance (matching thatthey MUST be ignored, but displaying them tocharacter). A range is ausersequence of characters enclosed in `[]'. It normally matches any single character from the sequence. If the sequence begins with `^', it matches any single character not from the rest of the sequence. If two char- acters in the sequence are separated by `-', this isignoring them. Looking inside themshorthand forcryptographic content (like OP packets) is *not* ignoring them.}} {{Editor's note: should we putthe full list of ASCII characters between them (e.g. `[0-9]' matches any decimal digit). To include a literal `]' inan X.509 encapsulation packet type?}} 6.the sequence, make it the first character (following a possible `^'). To include a literal `-', make it the first or last character. 9. Constants This section describes the constants used in OP. Note that these tables are not exhaustive lists; an implementation MAY implement an algorithm not on these lists.6.19.1 Public Key Algorithms 1 - RSA (Encrypt or Sign) 2 - RSA Encrypt-Only 3 - RSA Sign-Only 16 -ElgamalElgamal, see [ELGAMAL] 17 - DSA (Digital Signature Standard) 18 - Elliptic Curve 19 - ECDSA 21 - Diffie-Hellman (X9.42) 100 to 110 - Private/Experimental algorithm. Implementations MUST implement DSA for signatures, and Elgamal for encryption. Implementations SHOULD implement RSA encryption. Implementations MAY implement any other algorithm.{{Editor's note: reserve an algorithm for elliptic curve? Note that I've left Elgamal signatures completely unmentioned. I think this is good. --jdcc}} 6.29.2 Symmetric Key Algorithms 0 - Plaintext 1 - IDEA 2 - Triple-DES (DES-EDE, as per spec - 168 bit key derived from 192) 3 - CAST5 (128 bit key) 4 - Blowfish (128 bitkey)key, 16 rounds) 5 - ROT-N (128 bit N) 6 - SAFER-SK128 7 - DES/SK 100 to 110 - Private/Experimental algorithm. Implementations MUST implement Triple-DES. Implementations SHOULD implement IDEA and CAST5.Implementations MAY implement any other algorithm.6.39.3 Compression Algorithms 0 - Uncompressed 1 - ZIP 100 to 110 - Private/Experimental algorithm. Implementations MUST implement uncompressed data. Implementations SHOULD implement ZIP.6.49.4 Hash Algorithms 1 - MD5 2 - SHA-1 3 - RIPE-MD/160 4 - HAVAL 100 to 110 - Private/Experimental algorithm. Implementations MUST implement SHA-1. Implementations SHOULD implement MD5.7.10. Packet Composition OP packetsmay beare assembled into sequences in order to create messages and to transfer keys. Not all possible packet sequences are meaningful and correct. This describes the rules for how packets should be placed into sequences.7.110.1 Transferable Public Keys OP users may transfer public keys. The essential elements of a transferable public key are: - One Public Key packet - Zero or more revocation signatures - One or more User ID packets - After each User ID packet, zero or more Signature packets - Zero or more Subkey packets - After each Subkey packet, one 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. After the User ID packets there may be one or more Subkey packets.SubkeysIn general, subkeys areusedprovided in cases where the top-level public key is a signature-only key.TheHowever, any V4 key may have subkeys, and the subkeysare thenmay be encryption-onlykeys that are bound to the signature key.keys, signature-only keys, or general-purpose keys. Each Subkey packet must be followed by at least one Signature packet, which should be of the subkey binding signature type,andissued by the top level key.{{Editor's note: I think it is a good idea to have signature-only subkeys, too (or even encrypt-and-sign subkeys), but no implementation does this. Should we generalize here? --jdcc}}Subkey and Key packets may each be followed by a revocation Signature packet to indicate that the key is revoked. Revocation signatures are only accepted if they are issued by the key itself, or by a key which is authorized to issue revocations via a revocation key subpacket in a self-signature by the top level key. Transferable public key packet sequences may be concatenated to allow transferring multiple public keys in one operation.7.210.2 OP Messages An OP message is a packet or sequence of packets that corresponds to the following grammatical rules (comma represents sequential composition, and vertical bar separates alternatives): OP Message :- Encrypted Message | Signed Message | Compressed Message | Literal Message. Compressed Message :- Compressed Data Packet. Literal Message :- Literal Data Packet. ESK :- Pubic Key Encrypted Session Key Packet | Conventionally Encrypted Session Key Packet. ESK Sequence :- ESK | ESK Sequence, ESK. Encrypted Message :- Symmetrically Encrypted Data Packet | ESK Sequence, Symmetrically Encrypted Data Packet. One-Pass Signed Message :- One-Pass Signature Packet, OP Message, Signature Packet. Signed Message :- Signature Packet, OP Message | One-Pass Signed Message. In addition,thedecrypting a Symmetrically Encrypted Data packet and decompressing a Compressed Data packet must yield a valid OP Message.8.11. Enhanced Key Formats8.111.1 Key Structures The format of V3 OP key using RSA 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 have many signatures. The format of an OP V4 key that uses 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] [Direct Key Self Signature...] User ID [Signature ...] [User ID [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 old signature packets. In anElgamal/DSA key, the DSA publickeyisthat has a main key and subkeys, the primarykey, the Elgamal publickeyis the subkey,MUST be a key capable of signing. The subkeys may be keys of any other type, and either version 3 or 4 of the signature packet can be used. There may be other types 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, etc, or RSA primary key with an Elgamal subkey. It is also possible to have a signature-only subkey. This permits a primary key that collects certifications (key signatures) but is used only used for certifying subkeys that are used for encryption and signatures.8.211.2 V4 Key IDs and Fingerprints 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 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, with the example of a DSA key: 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 = DSA; f) Algorithm specific fields. Algorithm Specific Fields for DSA keys (example): f.1) MPI of DSA prime p; f.2) MPI of DSA group order q (q is a prime divisor of p-1); f.3) MPI of DSA group generator g; f.4) MPI of DSA public key value y (= g**x where x is secret).9.12. Security Considerations 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. Possession of the private key portion of a public-private key pair is assumed to be controlled 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. 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. If you are building an authentication system, the recipient may specify a preferred signing algorithm. However, the signer would be foolish to use a weak algorithm simply because the recipient requests it. Some of the encryption algorithms mentioned in this document have been analyzed less than others. For example, although CAST5 is presently considered strong, it has been analyzed less than Triple-DES. Other algorithms may have other controversies surrounding them. Some technologies mentioned here may be subject to government control in some countries.10.13. 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: +1619 658 3510619-658-3510 The principal authors of this draft are (in alphabetical order): Jon CallasPretty Good Privacy,Network Associates, Inc.555 Twin Dolphin Drive, #570 Redwood Shores,4200 Bohannon Drive Menlo Park, CA94065,94025, USA Email: jon@pgp.com Tel:+1-650-596-1960+1-650-473-2860 Lutz Donnerhacke IKS GmbH Wildenbruchstr. 15 07745 Jena, Germany EMail: lutz@iks-jena.de Tel: +49-3641-675642 Hal FinneyPretty Good Privacy,Network Associates, Inc.555 Twin Dolphin Drive, #570 Redwood Shores,4200 Bohannon Drive Menlo Park, CA94065,94025, USA Email: hal@pgp.comTel: +1-650-572-0430Rodney Thayer Sable Technology Corporation 246 Walnut Street Newton, MA 02160 USA Email: rodney@sabletech.com Tel: +1-617-332-7292 This draft also draws on much previous work from a number of other authors who include: Derek Atkins, Charles Breed, Dave Del Torto, Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Raph Levine, Colin Plumb, Will Price, William Stallings, Mark Weaver, and Philip R. Zimmermann.11.14. References[CAMPBELL} Campbell, Joe, "C Programmer's Guide to Serial Communications"[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. [ISO-10646] ISO/IEC 10646-1:1993. International Standard -- Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. UTF-8 is described in Annex R, adopted but not yet published. UTF-16 is described in Annex Q, adopted but not yet published. [PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard," version 1.5, November 1993 [RFC822] D. Crocker, "Standard for the format of ARPA Internet text messages", RFC 822, August 1982 [RFC1423] D. Balenson, "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, Taligent inc., July 1994. [RFC1750] Eastlake, Crocker, & Schiller., Randomness Recommendations for Security. December 1994. [RFC1951] Deutsch, P., DEFLATE Compressed Data Format Specification version 1.3. May 1996. [RFC1983] G. Malkin., Internet Users' Glossary. August 1996. [RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message Exchange Formats", RFC 1991, August 1996. [RFC2015] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996. [RFC2044] F. Yergeau., UTF-8, a transformation format of Unicode and ISO 10646. October 1996. [RFC2045] Borenstein, N., and Freed, N., "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies.", November 1996 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate Requirement Level. March 1997.12.15. Full Copyright Statement Copyright19971998 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 the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.