idnits 2.17.1 draft-ietf-openpgp-formats-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 39 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 156 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Unrecognized Status in 'Category: INTERNET-DRAFT', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 503 == Missing Reference: 'CAMPBELL' is mentioned on line 239, but not defined -- Looks like a reference, but probably isn't: '0' on line 503 -- Looks like a reference, but probably isn't: '2' on line 503 -- Looks like a reference, but probably isn't: '3' on line 504 == Missing Reference: 'ISO10646' is mentioned on line 537, but not defined == Missing Reference: 'Optional' is mentioned on line 1516, but not defined == Missing Reference: 'Ref' is mentioned on line 1598, but not defined == Unused Reference: 'DONNERHACKE' is defined on line 1997, but no explicit reference was found in the text == Unused Reference: 'ISO-10646' is defined on line 2001, but no explicit reference was found in the text == Unused Reference: 'RFC822' is defined on line 2010, but no explicit reference was found in the text == Unused Reference: 'RFC1423' is defined on line 2013, but no explicit reference was found in the text == Unused Reference: 'RFC1641' is defined on line 2017, but no explicit reference was found in the text == Unused Reference: 'RFC1750' is defined on line 2020, but no explicit reference was found in the text == Unused Reference: 'RFC1951' is defined on line 2023, but no explicit reference was found in the text == Unused Reference: 'RFC1983' is defined on line 2026, but no explicit reference was found in the text == Unused Reference: 'RFC1991' is defined on line 2028, but no explicit reference was found in the text == Unused Reference: 'RFC2015' is defined on line 2031, but no explicit reference was found in the text == Unused Reference: 'RFC2045' is defined on line 2037, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 2041, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DONNERHACKE' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-10646' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS1' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Downref: Normative reference to an Historic RFC: RFC 1423 ** Downref: Normative reference to an Experimental RFC: RFC 1641 ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) ** Downref: Normative reference to an Informational RFC: RFC 1951 ** Downref: Normative reference to an Informational RFC: RFC 1983 ** Obsolete normative reference: RFC 1991 (Obsoleted by RFC 4880) ** Obsolete normative reference: RFC 2044 (Obsoleted by RFC 2279) Summary: 19 errors (**), 0 flaws (~~), 19 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Jon Callas 2 Category: INTERNET-DRAFT Pretty Good Privacy 3 draft-ietf-openpgp-formats-00.txt Lutz Donnerhacke 4 Expires May 1998 IN-Root-CA Individual Network e.V. 5 November 1997 Hal Finney 6 Pretty Good Privacy 7 Rodney Thayer 8 Sable Technology 10 OP Formats - OpenPGP Message Format 11 draft-ietf-openpgp-formats-00.txt 13 Copyright 1997 by The Internet Society. All Rights Reserved. 15 Status of this Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, and 19 its working groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference material 25 or to cite them other than as "work in progress." 27 To learn the current status of any Internet-Draft, please check the 28 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 Abstract 35 This document is maintained in order to publish all necessary 36 information needed to develop interoperable applications based on the 37 OP format. It is not a step-by-step cookbook for writing an 38 application, it describes only the format and methods needed to read, 39 check, generate and write conforming packets crossing any network. It 40 does not deal with storing and implementation questions albeit it is 41 necessary to avoid security flaws. 43 OP (Open-PGP) software uses a combination of strong public-key and 44 conventional cryptography to provide security services for electronic 45 communications and data storage. These services include 46 confidentiality, key management, authentication and digital signatures. 47 This document specifies the message formats used in OP. 49 Table of Contents 51 1. Introduction 52 1.1 Terms 53 2. General functions 54 2.1 Confidentiality 55 2.2 Digital signature 56 2.3 Compression 57 2.4 Conversion to Radix-64 58 2.4.1 Forming ASCII Armor 59 2.4.2 Encoding Binary in Radix-64 60 2.4.3 Decoding Radix-64 61 2.4.4 Examples of Radix-64 62 2.5 Example of an ASCII Armored Message 63 2.6 Cleartext signature framework 64 3.0 Data Element Formats 65 3.1 Scalar numbers 66 3.2 Multi-Precision Integers 67 3.3 Counted Strings 68 3.4 Time fields 69 3.5 String-to-key (S2K) specifiers 70 3.5.1 String-to-key (S2k) specifier types 71 3.5.1.1 Simple S2K 72 3.5.1.2 Salted S2K 73 3.5.1.3 Iterated and Salted S2K 74 3.5.2 String-to-key usage 75 3.5.2.1 Secret key encryption 76 3.5.2.2 Conventional message encryption 77 3.5.3 String-to-key algorithms 78 3.5.3.1 Simple S2K algorithm 79 3.5.3.2 Salted S2K algorithm 80 3.5.3.3 Iterated-Salted S2K algorithm 81 4.0 Packet Syntax 82 4.1 Overview 83 4.2 Packet Headers 84 4.3 Packet Tags 85 5.0 Packet Types 86 5.1 Encrypted Session Key Packets (Tag 1) 87 5.2 Signature Packet (Tag 2) 88 5.2.1 Version 3 Signature Packet Format 89 5.2.2 Version 4 Signature Packet Format 90 5.2.2.1 Signature Subpacket Specification 91 5.2.2.2 Signature Subpacket Types 92 5.2.3 Signature Types 93 5.3 Conventional Encrypted Session-Key Packets (Tag 3) 94 5.4 One-Pass Signature Packets (Tag 4) 95 5.5 Key Material Packet 96 5.5.1 Key Packet Variants 97 5.5.1.1 Public Key Packet (Tag 6) 98 5.5.1.2 Public Subkey Packet (Tag 14) 99 5.5.1.3 Secret Key Packet (Tag 5) 100 5.5.1.4 Secret Subkey Packet (Tag 7) 101 5.5.2 Public Key Packet Formats 102 5.5.3 Secret Key Packet Formats 103 5.6 Compressed Data Packet (Tag 8) 104 5.7 Symmetrically Encrypted Data Packet (Tag 9) 105 5.8 Marker Packet (Obsolete Literal Packet) (Tag 10) 106 5.9 Literal Data Packet (Tag 11) 107 5.10 Trust Packet (Tag 12) 108 5.11 User ID Packet (Tag 13) 109 5.12 Comment Packet (Tag 16) 110 6. Constants 111 6.1 Public Key Algorithms 112 6.2 Symmetric Key Algorithms 113 6.3 Compression Algorithms 114 6.4 Hash Algorithms 115 7. Packet Composition 116 7.1 Transferable Public Keys 117 7.2 OP Messages 118 8. Enhanced Key Formats 119 8.1 Key Structures 120 8.4 V4 Key IDs and Fingerprints 121 9. Security Considerations 122 10. Authors and Working Group Chair 123 11. References 124 12. Full Copyright Statement 126 1. Introduction 128 This document provides information on the message-exchange packet 129 formats used by OP to provide encryption, decryption, signing, key 130 management and functions. It builds on the foundation provided RFC 131 1991 "PGP Message Exchange Formats" [1]. 133 1.1 Terms 135 OP - OpenPGP. This is a definition for security software that uses PGP 136 5.x as a basis. 138 PGP - Pretty Good Privacy. PGP is a family of software systems 139 developed by Philip R. Zimmermann from which OP is based. 141 PGP 2.6.x - This version of PGP has many variants, hence the term PGP 142 2.6.x. It used only RSA and IDEA for its cryptography. 144 PGP 5.x - This version of PGP is formerly known as "PGP 3" in the 145 community and also in the predecessor of this document, RFC1991. It 146 has new formats and corrects a number of problems in the PGP 2.6.x. It 147 is referred to here as PGP 5.x because that software was the first 148 release of the "PGP 3" code base. 150 "PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of 151 Pretty Good Privacy, Inc. 153 2. General functions 154 OP provides data integrity services for messages and data files by 155 using these core technologies: 157 -digital signature -encryption -compression -radix-64 conversion 159 In addition, OP provides key management and certificate services. 161 2.1 Confidentiality via Encryption 163 OP offers two encryption options to provide confidentiality: 164 conventional (symmetric-key) encryption and public key encryption. 165 With public-key encryption, the message is actually encrypted using a 166 conventional encryption algorithm. In this mode, each conventional key 167 is used only once. That is, a new key is generated as a random number 168 for each message. Since it is used only once, the "session key" is 169 bound to the message and transmitted with it. To protect the key, it 170 is encrypted with the receiver's public key. The sequence is as 171 follows: 173 1. The sender creates a message. 174 2. The sending OP generates a random number to be used as a 175 session key for this message only. 176 3. The session key is encrypted using each recipient's public key. 177 These "encrypted session keys" start the message. 178 4. The sending OP encrypts the message using the session key, which 179 forms the remainder of the message. Note that the message is 180 also usually compressed. 181 5. The receiving OP decrypts the session key using the recipient's 182 private key. 183 6. The receiving OP decrypts the message using the session key. 184 If the message was compressed, it will be decompressed. 186 Both digital signature and confidentiality services may be applied to 187 the same message. First, a signature is generated for the message and 188 attached to the message. Then, the message plus signature is encrypted 189 using a conventional session key. Finally, the session key is 190 encrypted using public-key encryption and prepended to the encrypted 191 block. 193 2.2 Authentication via Digital signature 195 The digital signature uses a hash code or message digest algorithm, and 196 a public-key signature algorithm. The sequence is as follows: 198 1. The sender creates a message. 199 2. The sending software generates a hash code of the message 200 3. The sending software generates a signature from the hash code using 201 the sender's private key. 202 4. The binary signature is attached to the message. 203 5. The receiving software keeps a copy of the message signature. 204 6. The receiving software generates a new hash code for the received 205 message and verifies it using the message's signature. If the 206 verification is successful, the message is accepted as authentic. 208 2.3 Compression 210 OP implementations MAY compress the message after applying the 211 signature but before encryption. 213 2.4 Conversion to Radix-64 215 OP's underlying native representation for encrypted messages, signature 216 certificates, and keys is a stream of arbitrary octets. Some systems 217 only permit the use of blocks consisting of seven-bit, printable text. 218 For transporting OP's native raw binary octets through email channels, 219 a printable encoding of these binary octets is needed. OP provides the 220 service of converting the raw 8-bit binary octet stream to a stream of 221 printable ASCII characters, called Radix-64 encoding or ASCII Armor. 223 In principle, any printable encoding scheme that met the requirements 224 of the email channel would suffice, since it would not change the 225 underlying binary bit streams of the native OP data structures. The OP 226 standard specifies one such printable encoding scheme to ensure 227 interoperability. 229 OP's Radix-64 encoding is composed of two parts: a base64 encoding of 230 the binary data, and a checksum. The base64 encoding is identical to 231 the MIME base64 content-transfer-encoding [RFC 2045, Section 6.8]. An 232 OP implementation MAY use ASCII Armor to protect the raw binary data. 234 The checksum is a 24-bit CRC converted to four characters of radix-64 235 encoding by the same MIME base64 transformation, preceded by an equals 236 sign (=). The CRC is computed by using the generator 0x864CFB and an 237 initialization of 0xB704CE. The accumulation is done on the data 238 before it is converted to radix-64, rather than on the converted data. 239 (For more information on CRC functions, see chapter 19 of [CAMPBELL].) 241 {{Editor's note: This is old text, dating back to RFC 1991. I have 242 never liked the glib way the CRC has been dismissed, but I also know 243 that this is no place to start a discussion of CRC theory. Should we 244 construct a sample implementation in C and put it in an appendix? -- 245 jdcc}} 247 The checksum with its leading equal sign MAY appear on the first line 248 after the Base64 encoded data. 250 Rationale for CRC-24: The size of 24 bits fits evenly into printable 251 base64. The nonzero initialization can detect more errors than a zero 252 initialization. 254 2.4.1 Forming ASCII Armor 256 When OP encodes data into ASCII Armor, it puts specific headers around 257 the data, so OP can reconstruct the data later. OP informs the user 258 what kind of data is encoded in the ASCII armor through the use of the 259 headers. 261 Concatenating the following data creates ASCII Armor: 263 - An Armor Header Line, appropriate for the type of data - Armor 264 Headers - A blank (zero-length, or containing only whitespace) line - 265 The ASCII-Armored data - An Armor Checksum - The Armor Tail, which 266 depends on the Armor Header Line. 268 An Armor Header Line consists of the appropriate header line text 269 surrounded by five (5) dashes ('-', 0x2D) on either side of the header 270 line text. The header line text is chosen based upon the type of data 271 that is being encoded in Armor, and how it is being encoded. Header 272 line texts include the following strings: 274 BEGIN PGP MESSAGE used for signed, encrypted, or compressed files 276 BEGIN PGP PUBLIC KEY BLOCK used for armoring public keys 278 BEGIN PGP PRIVATE KEY BLOCK used for armoring private keys 280 BEGIN PGP MESSAGE, PART X/Y used for multi-part messages, where the 281 armor is split amongst Y parts, and this is the Xth part out of Y. 283 BEGIN PGP MESSAGE, PART X used for multi-part messages, where this is 284 the Xth part of an unspecified number of parts. Requires the MESSAGE-ID 285 Armor Header to be used. 287 BEGIN PGP SIGNATURE used for detached signatures, OP/MIME signatures, 288 and signatures following clearsigned messages 290 The Armor Headers are pairs of strings that can give the user or the 291 receiving OP message block some information about how to decode or use 292 the message. The Armor Headers are a part of the armor, not a part of 293 the message, and hence are not protected by any signatures applied to 294 the message. 296 The format of an Armor Header is that of a key-value pair. A colon 297 (':' 0x38) and a single space (0x20) separate the key and value. OP 298 should consider improperly formatted Armor Headers to be corruption of 299 the ASCII Armor. Unknown keys should be reported to the user, but OP 300 should continue to process the message. Currently defined Armor Header 301 Keys include "Version" and "Comment", which define the OP Version used 302 to encode the message and a user-defined comment. 304 The "MessageID" Armor Header specifies a 32-character string of 305 printable characters. The string must be the same for all parts of a 306 multi-part message that uses the "PART X" Armor Header. MessageID 307 strings should be chosen with enough internal randomness that no two 308 messages would have the same MessageID string. 310 The MessageID should not appear unless it is in a multi-part message. 311 If it appears at all, it should be computed from the message in a 312 deterministic fashion, rather than contain a purely random value. This 313 is to allow anyone to determine that the MessageID cannot serve as a 314 covert means of leaking cryptographic key information. 316 {{Editor's note: This needs to be cleaned up, with a table of the 317 defined headers. Also, the MessageID description is too vague about 318 how random the id has to be.}} 320 The Armor Tail Line is composed in the same manner as the Armor Header 321 Line, except the string "BEGIN" is replaced by the string "END." 323 2.4.2 Encoding Binary in Radix-64 325 The encoding process represents 24-bit groups of input bits as output 326 strings of 4 encoded characters. Proceeding from left to right, a 327 24-bit input group is formed by concatenating three 8-bit input groups. 328 These 24 bits are then treated as four concatenated 6-bit groups, each 329 of which is translated into a single digit in the Radix-64 alphabet. 330 When encoding a bit stream with the Radix-64 encoding, the bit stream 331 must be presumed to be ordered with the most-significant-bit first. 332 That is, the first bit in the stream will be the high-order bit in the 333 first 8-bit byte, and the eighth bit will be the low-order bit in the 334 first 8-bit byte, and so on. 336 +--first octet--+-second octet--+--third octet--+ 337 |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| 338 +-----------+---+-------+-------+---+-----------+ 339 |5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0| 340 +--1.index--+--2.index--+--3.index--+--4.index--+ 342 Each 6-bit group is used as an index into an array of 64 printable 343 characters from the table below. The character referenced by the index 344 is placed in the output string. 346 Value Encoding Value Encoding Value Encoding Value Encoding 347 0 A 17 R 34 i 51 z 348 1 B 18 S 35 j 52 0 349 2 C 19 T 36 k 53 1 350 3 D 20 U 37 l 54 2 351 4 E 21 V 38 m 55 3 352 5 F 22 W 39 n 56 4 353 6 G 23 X 40 o 57 5 354 7 H 24 Y 41 p 58 6 355 8 I 25 Z 42 q 59 7 356 9 J 26 a 43 r 60 8 357 10 K 27 b 44 s 61 9 358 11 L 28 c 45 t 62 + 359 12 M 29 d 46 u 63 / 360 13 N 30 e 47 v 361 14 O 31 f 48 w (pad) = 362 15 P 32 g 49 x 363 16 Q 33 h 50 y 365 The encoded output stream must be represented in lines of no more than 366 76 characters each. 368 Special processing is performed if fewer than 24 bits are available at 369 the end of the data being encoded. There are three possibilities: 371 - The last data group has 24 bits (3 octets). No special processing is 372 needed. 374 - The last data group has 16 bits (2 octets). The first two 6-bit 375 groups are processed as above. The third (incomplete) data group has 376 two zero-value bits added to it, and is processed as above. A pad 377 character (=) is added to the output. 379 - The last data group has 8 bits (1 octet). The first 6-bit group is 380 processed as above. The second (incomplete) data group has four 381 zero-value bits added to it, and is processed as above. Two pad 382 characters (=) are added to the output. 384 2.4.3 Decoding Radix-64 386 Any characters outside of the base64 alphabet are ignored in Radix-64 387 data. Decoding software must ignore all line breaks or other 388 characters not found in the table above. 390 In Radix-64 data, characters other than those in the table, line 391 breaks, and other white space probably indicate a transmission error, 392 about which a warning message or even a message rejection might be 393 appropriate under some circumstances. 395 Because it is used only for padding at the end of the data, the 396 occurrence of any "=" characters may be taken as evidence that the end 397 of the data has been reached (without truncation in transit). No such 398 assurance is possible, however, when the number of octets transmitted 399 was a multiple of three and no "=" characters are present. 401 2.4.4 Examples of Radix-64 403 Input data: 0x14fb9c03d97e 404 Hex: 1 4 f b 9 c | 0 3 d 9 7 e 405 8-bit: 00010100 11111011 10011100 | 00000011 11011001 11111110 406 6-bit: 000101 001111 101110 011100 | 000000 111101 100111 111110 407 Decimal: 5 15 46 28 0 61 37 63 408 Output: F P u c A 9 l / 410 Input data: 0x14fb9c03d9 411 Hex: 1 4 f b 9 c | 0 3 d 9 412 8-bit: 00010100 11111011 10011100 | 00000011 11011001 413 pad with 00 414 6-bit: 000101 001111 101110 011100 | 000000 111101 100100 415 Decimal: 5 15 46 28 0 61 36 416 pad with = 418 Output: F P u c A 9 k = 420 Input data: 0x14fb9c03 421 Hex: 1 4 f b 9 c | 0 3 422 8-bit: 00010100 11111011 10011100 | 00000011 423 pad with 0000 424 6-bit: 000101 001111 101110 011100 | 000000 110000 425 Decimal: 5 15 46 28 0 48 426 pad with = = 427 Output: F P u c A w = = 429 2.5 Example of an ASCII Armored Message 431 -----BEGIN PGP MESSAGE----- 432 Version: OP V0.0 434 owFbx8DAYFTCWlySkpkHZDKEFCXmFedmFhdn5ucpZKdWFiv4hgaHKPj5hygUpSbn 435 l6UWpabo8XIBAA== 436 =3m1o 437 -----END PGP MESSAGE----- 439 Note that this example is indented by two spaces. 441 2.6 Cleartext signature framework 443 Sometimes it is necessary to sign a textual octet stream without ASCII 444 armoring the stream itself, so the signed text is still readable 445 without special software. In order to bind a signature to such a 446 cleartext, this framework is used. (Note that RFC 2015 defines another 447 way to clear sign messages for environments that support MIME.) 449 The cleartext signed message consists of: 450 - The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a 451 single line, 452 - Zero or more "Hash" Armor Headers (3.1.2.4), 453 - Exactly one empty line not included into the message digest, 454 - The dash-escaped cleartext that is included into the message digest, 455 - The ASCII armored signature(s) including the Armor Header and Armor 456 Tail Lines. 458 If the "Hash" armor header is given, the specified message digest 459 algorithm is used for the signature. If this header is missing, SHA-1 460 is assumed. If more than one message digest is used in the signature, 461 the "Hash" armor header contains a comma-delimited list of used message 462 digests. As an abbreviation, the "Hash" armor header may be placed on 463 the cleartext header line, inserting a comma after the word 'MESSAGE', 464 as follows: 466 '-----BEGIN PGP SIGNED MESSAGE, Hash: MD5, SHA1'. 468 {{Editor's note: Should the above armor header line stay or go? 469 There's no reason that the "Hash:" armor header can't have multiple 470 hashes in it. I think anything that reduces parsing complexity is a 471 Good Thing. --jdcc}} 473 Current message digest names are: 475 - "SHA1" 476 - "MD5" 477 - "RIPEMD160" 479 Dash escaped cleartext is the ordinary cleartext where every line 480 starting with a dash '-' (0x2D) is prepended by the sequence dash '-' 481 (0x2D) and space ' ' (0x20). This prevents the parser from recognizing 482 armor headers of the cleartext itself. The message digest is computed 483 using the cleartext itself, not the dash escaped form. 485 As with binary signatures on text documents (see below), the cleartext 486 signature is calculated on the text using canonical line 487 endings. The line ending (i.e. the ) before the '-----BEGIN 488 PGP SIGNATURE-----' line that terminates the signed text is not 489 considered part of the signed text. 491 Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of 492 any line is ignored when the cleartext signature is calculated. 494 3. Data Element Formats 496 This section describes the data elements used by OP. 498 3.1 Scalar numbers 500 Scalar numbers are unsigned, and are always stored in big-endian 501 format. Using n[k] to refer to the kth octet being interpreted, the 502 value of a two-octet scalar is ((n[0] << 8) + n[1]). The value of a 503 four-octet scalar is ((n[0] << 24) + (n[1] << 16) + (n[2] << 8) + 504 n[3]). 506 3.2 Multi-Precision Integers 508 Multi-Precision Integers (also called MPIs) are unsigned integers used 509 to hold large integers such as the ones used in cryptographic 510 calculations. 512 An MPI consists of two pieces: a two-octet scalar that is the length of 513 the MPI in bits followed by a string of octets that contain the actual 514 integer. 516 These octets form a big-endian number; a big-endian number can be made 517 into an MPI by prefixing it with the appropriate length. 519 Examples: 521 (all numbers are in hexadecimal) 522 The string of octets [00 01 01] forms an MPI with the value 1. The 523 string [00 09 01 FF] forms an MPI with the value of 511. 525 Additional rules: 527 The size of an MPI is ((MPI.length + 7) / 8) + 2. 529 The length field of an MPI describes the length starting from its most 530 significant non-zero bit. Thus, the MPI [00 02 01] is not formed 531 correctly. It should be [00 01 01]. 533 3.3 Counted Strings 535 A counted string consists of a length and then N octets of string data. 536 Its default character set is UTF-8 [RFC2044] encoding of Unicode 537 [ISO10646]. 539 3.4 Time fields 541 A time field is an unsigned four-octet number containing the number of 542 seconds elapsed since midnight, 1 January 1970 UTC. 544 3.5 String-to-key (S2K) specifiers 546 String-to-key (S2K) specifiers are used to convert passphrase strings 547 into conventional encryption/decryption keys. They are used in two 548 places, currently: to encrypt the secret part of private keys in the 549 private keyring, and to convert passphrases to encryption keys for 550 conventionally encrypted messages. 552 3.5.1 String-to-key (S2k) specifier types 554 There are three types of S2K specifiers currently supported, as 555 follows: 557 3.5.1.1 Simple S2K 559 This directly hashes the string to produce the key data. See below for 560 how this hashing is done. 562 Octet 0: 0x00 563 Octet 1: hash algorithm 565 3.5.1.2 Salted S2K 567 This includes a "salt" value in the S2K specifier -- some arbitrary 568 data -- that gets hashed along with the passphrase string, to help 569 prevent dictionary attacks. 571 Octet 0: 0x01 572 Octet 1: hash algorithm 573 Octets 2-9: 8-octet salt value 574 3.5.1.3 Iterated and Salted S2K 576 This includes both a salt and an octet count. The salt is combined 577 with the passphrase and the resulting value is hashed repeatedly. This 578 further increases the amount of work an attacker must do to try 579 dictionary attacks. 581 Octet 0: 0x03 582 Octet 1: hash algorithm 583 Octets 2-9: 8-octet salt value 584 Octet 10: count, in special format (described below) 586 3.5.2 String-to-key usage 588 Implementations MUST implement simple S2K and salted S2K specifiers. 589 Implementations MAY implement iterated and salted S2K specifiers. 590 Implementations SHOULD use salted S2K specifiers, as simple S2K 591 specifiers are more vulnerable to dictionary attacks. 593 3.5.2.1 Secret key encryption 595 An S2K specifier can be stored in the secret keyring to specify how to 596 convert the passphrase to a key that unlocks the secret data. Older 597 versions of PGP just stored a cipher algorithm octet preceding the 598 secret data or a zero to indicate that the secret data was unencrypted. 599 The MD5 hash function was always used to convert the passphrase to a 600 key for the specified cipher algorithm. 602 For compatibility, when an S2K specifier is used, the special value 255 603 is stored in the position where the hash algorithm octet would have 604 been in the old data structure. This is then followed immediately by a 605 one-octet algorithm identifier, and then by the S2K specifier as 606 encoded above. 608 Therefore, preceding the secret data there will be one of these 609 possibilities: 611 0 secret data is unencrypted (no pass phrase) 612 255 followed by algorithm octet and S2K specifier 613 Cipher alg use Simple S2K algorithm using MD5 hash 615 This last possibility, the cipher algorithm number with an implicit use 616 of MD5 is provided for backward compatibility; it should be understood, 617 but not generated. 619 These are followed by an 8-octet Initial Vector for the decryption of 620 the secret values, if they are encrypted, and then the secret key 621 values themselves. 623 3.5.2.2 Conventional message encryption 625 PGP 2.X always used IDEA with Simple string-to-key conversion when 626 conventionally encrypting a message. PGP 5 can create a Conventional 627 Encrypted Session Key packet at the front of a message. This can be 628 used to allow S2K specifiers to be used for the passphrase conversion, 629 to allow other ciphers than IDEA to be used, or to create messages with 630 a mix of conventional ESKs and public key ESKs. This allows a message 631 to be decrypted either with a passphrase or a public key. 633 3.5.3 String-to-key algorithms 635 3.5.3.1 Simple S2K algorithm 637 Simple S2K hashes the passphrase to produce the session key. The 638 manner in which this is done depends on the size of the session key 639 (which will depend on the cipher used) and the size of the hash 640 algorithm's output. If the hash size is greater than or equal to the 641 session key size, the leftmost octets of the hash are used as the key. 643 If the hash size is less than the key size, multiple instances of the 644 hash context are created -- enough to produce the required key data. 645 These instances are preloaded with 0, 1, 2, ... octets of zeros (that 646 is to say, the first instance has no preloading, the second gets 647 preloaded with 1 octet of zero, the third is preloaded with two octets 648 of zeros, and so forth). 650 As the data is hashed, it is given independently to each hash context. 651 Since the contexts have been initialized differently, they will each 652 produce different hash output. Once the passphrase is hashed, the 653 output data from the multiple hashes is concatenated, first hash 654 leftmost, to produce the key data, with any excess octets on the right 655 discarded. 657 3.5.3.2 Salted S2K algorithm 659 Salted S2K is exactly like Simple S2K, except that the input to the 660 hash function(s) consists of the 8 octets of salt from the S2K 661 specifier, followed by the passphrase. 663 3.5.3.3 Iterated-Salted S2K algorithm 665 {{Editor's note: This is very complex, with bizarre things like an 666 8-bit floating point format. Should we just drop it? --jdcc}} 668 Iterated-Salted S2K hashes the passphrase and salt data multiple times. 669 The total number of octets to be hashed is encoded in the count octet 670 that follows the salt in the S2K specifier. The count value is stored 671 as a normalized floating-point value with 4 bits of exponent and 4 bits 672 of mantissa. The formula to convert from the count octet to a count of 673 the number of octets to be hashed is as follows, letting the high 4 674 bits of the count octet be CEXP and the low four bits be CMANT: 676 count of octets to be hashed = (16 + CMANT) << (CEXP + 6) 678 This allows encoding hash counts as low as 16 << 6 or 1024 (using an 679 octet value of 0), and as high as 31 << 21 or 65011712 (using an octet 680 value of 0xff). Note that the resulting count value is an octet count 681 of how many octets will be hashed, not an iteration count. 683 Initially, one or more hash contexts are set up as with the other S2K 684 algorithms, depending on how many octets of key data are needed. Then 685 the salt, followed by the passphrase data is repeatedly hashed until 686 the number of octets specified by the octet count has been hashed. The 687 one exception is that if the octet count is less than the size of the 688 salt plus passphrase, the full salt plus passphrase will be hashed even 689 though that is greater than the octet count. After the hashing is done 690 the data is unloaded from the hash context(s) as with the other S2K 691 algorithms. 693 4. Packet Syntax 695 This section describes the packets used by OP. 697 4.1 Overview 699 An OP message is constructed from a number of records that are 700 traditionally called packets. A packet is a chunk of data that has a 701 tag specifying its meaning. An OP message, keyring, certificate, and 702 so forth consists of a number of packets. Some of those packets may 703 contain other OP packets (for example, a compressed data packet, when 704 uncompressed, contains OP packets). 706 Each packet consists of a packet header, followed by the packet body. 707 The packet header is of variable length. 709 4.2 Packet Headers 711 The first octet of the packet header is called the "Packet Tag." It 712 determines the format of the header and denotes the packet contents. 713 The remainder of the packet header is the length of the packet. 715 Note that the most significant bit is the left-most bit, called bit 7. 716 A mask for this bit is 0x80 in hexadecimal. 718 +---------------+ 719 PTag |7 6 5 4 3 2 1 0| 720 +---------------+ 721 Bit 7 -- Always one 722 Bit 6 -- New packet format if set 724 PGP 2.6.X only uses old format packets. Thus, software that 725 interoperates with those versions of PGP must only use old format 726 packets. If interoperability is not an issue, either format may be 727 used. 729 Old format packets contain: 730 Bits 5-2 -- content tag 731 Bits 1-0 - length-type 733 New format packets contain: 734 Bits 5-0 -- content tag 736 The meaning of the length-type in old-format packets is: 738 0 - The packet has a one-octet length. The header is 2 octets long. 740 1 - The packet has a two-octet length. The header is 3 octets long. 742 2 - The packet has a four-octet length. The header is 5 octets long. 744 3 - The packet is of indeterminate length. The header is 1 byte long, 745 and the application must determine how long the packet is. If the 746 packet is in a file, this means that the packet extends until the end 747 of the file. In general, an application should not use indeterminate 748 length packets except where the end of the data will be clear from the 749 context. 751 New format packets have three possible ways of encoding length. A 752 one-octet Body Length header encodes packet lengths of up to 191 753 octets, and a two-octet Body Length header encodes packet lengths of 754 192 to 8383 octets. For cases where longer packet body lengths are 755 needed, or where the length of the packet body is not known in advance 756 by the issuer, Partial Body Length headers can be used. These are 757 one-octet length headers that encode the length of only part of the 758 data packet. 760 Each Partial Body Length header is followed by a portion of the packet 761 body data. The Partial Body Length header specifies this portion's 762 length. Another length header (of one of the three types) follows that 763 portion. The last length header in the packet must always be a regular 764 Body Length header. Partial Body Length headers may only be used for 765 the non-final parts of the packet. 767 A one-octet Body Length header encodes a length of from 0 to 191 768 octets. This type of length header is recognized because the one octet 769 value is less than 192. The body length is equal to: 771 bodyLen = length_octet; 773 A two-octet Body Length header encodes a length of from 192 to 8383 774 octets. It is recognized because its first octet is in the range 192 775 to 223. The body length is equal to: 777 bodyLen = (1st_octet - 192) * 256 + (2nd_octet) + 192 779 A Partial Body Length header is one octet long and encodes a length 780 which is a power of 2, from 1 to 2147483648 (2 to the 31st power). It 781 is recognized because its one octet value is greater than or equal to 782 224. The partial body length is equal to: 784 partialBodyLen = 1 << (length_octet & 0x1f); 786 Examples: 788 A packet with length 100 may have its length encoded in one octet: 789 0x64. This is followed by 100 octets of data. 791 A packet with length 1723 may have its length coded in two octets: 792 0xC5, 0xFB. This header is followed by the 1723 octets of data. 794 A packet with length 100000 might be encoded in the following octet 795 stream: 0xE1, first two octets of data, 0xE0, next one octet of data, 796 0xEF, next 32768 octets of data, 0xF0, next 65536 octets of data, 0xC5, 797 0xDD, last 1693 octets of data. This is just one possible encoding, 798 and many variations are possible on the size of the Partial Body Length 799 headers, as long as a regular Body Length header encodes the last 800 portion of the data. Note also that the last Body Length header can be 801 a zero-length header. 803 Please note that in all of these explanations, the total length of the 804 packet is the length of the header(s) plus the length of the body. 806 4.3 Packet Tags 808 The packet tag denotes what type of packet the body holds. Note that 809 old format packets can only have tags less than 16, whereas new format 810 packets can have tags as great as 63. The defined tags (in decimal) 811 are: 813 0 -- Reserved. A packet must not have a tag with this value. 814 1 -- Encrypted Session Key Packet 815 2 -- Signature Packet 816 3 -- Conventionally Encrypted Session Key Packet 817 4 -- One-Pass Signature Packet 818 5 -- Secret Key Packet 819 6 -- Public Key Packet 820 7 -- Secret Subkey Packet 821 8 -- Compressed Data Packet 822 9 -- Symmetrically Encrypted Data Packet 823 10 -- Marker Packet 824 11 -- Literal Data Packet 825 12 -- Trust Packet 826 13 -- Name Packet 827 14 -- Subkey Packet 828 15 -- Reserved 829 16 -- Comment Packet 830 60 to 63 -- Private or Experimental Values 832 5. Packet Types 834 5.1 Encrypted Session Key Packets (Tag 1) 835 An Encrypted Session Key packet holds the key used to encrypt a message 836 that is itself encrypted with a public key. Zero or more Encrypted 837 Session Key packets and/or Conventional Encrypted Session Key packets 838 may precede a Symmetrically Encrypted Data Packet, which holds an 839 encrypted message. The message is encrypted with a session key, and 840 the session key is itself encrypted and stored in the Encrypted Session 841 Key packet or the Conventional Encrypted Session Key packet. The 842 Symmetrically Encrypted Data Packet is preceded by one Encrypted 843 Session Key packet for each OP key to which the message is encrypted. 844 The recipient of the message finds a session key that is encrypted to 845 their public key, decrypts the session key, and then uses the session 846 key to decrypt the message. 848 The body of this packet consists of: 850 - A one-octet number giving the version number of the packet type. 851 The currently defined value for packet version is 3. An 852 implementation should accept, but not generate a version of 2, 853 which is equivalent to V3 in all other respects. 854 - An eight-octet number that gives the key ID of the public key that 855 the session key is encrypted to. 856 - A one-octet number giving the public key algorithm used. 857 - A string of octets that is the encrypted session key. This 858 string takes up the remainder of the packet, and its contents are 859 dependent on the public key algorithm used. 861 Algorithm Specific Fields for RSA encryption 862 - multiprecision integer (MPI) of RSA encrypted value m**e. 864 Algorithm Specific Fields for Elgamal encryption: 865 - MPI of DSA value g**k. 866 - MPI of DSA value m * y**k. 868 The encrypted value "m" in the above formulas is derived from the 869 session key as follows. First the session key is prepended with a 870 one-octet algorithm identifier that specifies the conventional 871 encryption algorithm used to encrypt the following Symmetrically 872 Encrypted Data Packet. Then a two-octet checksum is appended which is 873 equal to the sum of the preceding octets, including the algorithm 874 identifier and session key, modulo 65536. This value is then padded as 875 described in PKCS-1 block type 02 [PKCS1] to form the "m" value used in 876 the formulas above. 878 5.2 Signature Packet (Tag 2) 880 A signature packet describes a binding between some public key and some 881 data. The most common signatures are a signature of a file or a block 882 of text, and a signature that is a certification of a user ID. 884 Two versions of signature packets are defined. Version 3 provides 885 basic signature information, while version 4 provides an expandable 886 format with subpackets that can specify more information about the 887 signature. PGP 2.6.X only accepts version 3 signatures. 889 Implementations MUST accept V3 signatures. Implementations SHOULD 890 generate V4 signatures, unless there is a need to generate a signature 891 that can be verified by PGP 2.6.x. 893 5.2.1 Version 3 Signature Packet Format 895 A version 3 Signature packet contains: 896 - One-octet version number (3). 897 - One-octet length of following hashed material. MUST be 5. 898 - One-octet signature type. 899 - Four-octet creation time. 900 - Eight-octet key ID of signer. 901 - One-octet public key algorithm. 902 - One-octet hash algorithm. 903 - Two-octet field holding left 16 bits of signed hash value. 904 - One or more multi-precision integers comprising the signature. 905 This portion is algorithm specific, as described below. 907 The data being signed is hashed, and then the signature type and 908 creation time from the signature packet are hashed (5 additional 909 octets). The resulting hash value is used in the signature algorithm. 910 The high 16 bits (first two octets) of the hash are included in the 911 signature packet to provide a quick test to reject some invalid 912 signatures. 914 Algorithm Specific Fields for RSA signatures: 915 - multiprecision integer (MPI) of RSA signature value m**d. 917 Algorithm Specific Fields for DSA signatures: 918 - MPI of DSA value r. 919 - MPI of DSA value s. 921 The signature calculation is based on a hash of the signed data, as 922 described above. The details of the calculation are different for DSA 923 signature than for RSA signatures. 925 With RSA signatures, the hash value is encoded as described in PKCS-1 926 section 10.1.2, "Data encoding", producing an ASN.1 value of type 927 DigestInfo, and then padded using PKCS-1 block type 01 [PKCS1]. This 928 requires inserting the hash value as an octet string into an ASN.1 929 structure. The object identifier for the type of hash being used is 930 included in the structure. The hexadecimal representations for the 931 currently defined hash algorithms are: 933 - SHA-1: 0x2b, 0x0e, 0x03, 0x02, 0x1a 934 - MD5: 0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x02, 0x05 935 - RIPEMD-160: 0x2b, 0x24, 0x03, 0x02, 0x01 937 The ASN.1 OIDs are: 938 - MD5: 1.2.840.113549.2.5 939 - SHA-1: 1.3.14.3.2.26 940 - RIPEMD160: 1.3.36.3.2.1 941 DSA signatures SHOULD use hashes with a size of 160 bits, to match q, 942 the size of the group generated by the DSA key's generator value. The 943 hash function result is treated as a 160 bit number and used directly 944 in the DSA signature algorithm. 946 5.2.2 Version 4 Signature Packet Format 948 A version 4 Signature packet contains: 949 - One-octet version number (4). 950 - One-octet signature type. 951 - One-octet public key algorithm. 952 - One-octet hash algorithm. 953 - Two-octet octet count for following hashed subpacket data. 954 - Hashed subpacket data. 955 - Two-octet octet count for following unhashed subpacket data. 956 - Unhashed subpacket data. 957 - Two-octet field holding left 16 bits of signed hash value. 958 - One or more multi-precision integers comprising the signature. 959 This portion is algorithm specific, as described above. 961 The data being signed is hashed, and then the signature data from the 962 version number through the hashed subpacket data is hashed. The 963 resulting hash value is what is signed. The left 16 bits of the hash 964 are included in the signature packet to provide a quick test to reject 965 some invalid signatures. 967 There are two fields consisting of signature subpackets. The first 968 field is hashed with the rest of the signature data, while the second 969 is unhashed. The second set of subpackets is not cryptographically 970 protected by the signature and should include only advisory 971 information. 973 The algorithms for converting the hash function result to a signature 974 are described above. 976 5.2.2.1 Signature Subpacket Specification 978 The subpacket fields consist of zero or more signature subpackets. 979 Each set of subpackets is preceded by a two-octet count of the length 980 of the set of subpackets. 982 Each subpacket consists of a subpacket header and a body. The header 983 consists of: 985 - subpacket length (1 or 2 octets): 986 Length includes the type octet but not this length, 987 1st octet < 192, then length is octet value 988 1st octet >= 192, then length is 2 octets and equal to 989 (1st octet - 192) * 256 + (2nd octet) + 192 990 - subpacket type (1 octet): 991 If bit 7 is set, subpacket understanding is critical, 992 2 = signature creation time, 993 3 = signature expiration time, 994 4 = exportable, 995 5 = trust signature, 996 6 = regular expression, 997 7 = revocable, 998 9 = key expiration time, 999 10 = additional recipient request, 1000 11 = preferred symmetric algorithms, 1001 12 = revocation key, 1002 16 = issuer key ID, 1003 20 = notation data, 1004 21 = preferred hash algorithms, 1005 22 = preferred compression algorithms, 1006 23 = key server preferences, 1007 24 = preferred key server 1009 - subpacket specific data: 1011 Bit 7 of the subpacket type is the "critical" bit. If set, it implies 1012 that it is critical that the subpacket be one which is understood by 1013 the software. If a subpacket is encountered which is marked critical 1014 but the software does not understand, the handling depends on the 1015 relationship between the issuing key and the key that is signed. If 1016 the signature is a valid self-signature (for which the issuer is the 1017 key that is being signed, either directly or via a username binding), 1018 then the key should not be used. In other cases, the signature 1019 containing the critical subpacket should be ignored. 1021 5.2.2.2 Signature Subpacket Types 1023 Several types of subpackets are currently defined. Some subpackets 1024 apply to the signature itself and some are attributes of the key. 1025 Subpackets that are found on a self-signature are placed on a user name 1026 certification made by the key itself. Note that a key may have more 1027 than one user name, and thus may have more than one self-signature, and 1028 differing subpackets. 1030 Implementing software should interpret a self-signature's preference 1031 subpackets as narrowly as possible. For example, suppose a key has two 1032 usernames, Alice and Bob. Suppose that Alice prefers the symmetric 1033 algorithm CAST5, and Bob prefers IDEA or Triple-DES. If the software 1034 locates this key via Alice's name, then the preferred algorithm is 1035 CAST5, if software locates the key via Bob's name, then the preferred 1036 algorithm is IDEA. If the key is located by key id, then algorithm of 1037 the default user name of the key provides the default symmetric 1038 algorithm. 1040 The descriptions below describe whether a subpacket is typically found 1041 in the hashed or unhashed subpacket sections. If a subpacket is not 1042 hashed, then it cannot be trusted. 1044 Signature creation time (4 octet time field) (Hashed) 1046 The time the signature was made. Always included with new signatures. 1048 Issuer (8 octet key ID) (Non-hashed) 1050 The OP key ID of the key issuing the signature. 1052 Key expiration time (4 octet time field) (Hashed) 1054 The validity period of the key. This is the number of seconds after 1055 the key creation time that the key expires. If this is not present or 1056 has a value of zero, the key never expires. This is found only on a 1057 self-signature. 1059 Preferred symmetric algorithms (array of one-octet values) (Hashed) 1061 Symmetric algorithm numbers that indicate which algorithms the key 1062 holder prefers to use. This is an ordered list of octets with the most 1063 preferred listed first. It should be assumed that only algorithms 1064 listed are supported by the recipient's software. Algorithm numbers in 1065 section 6. This is only found on a self-signature. 1067 Preferred hash algorithms (array of one-octet values) (Hashed) 1069 Message digest algorithm numbers that indicate which algorithms the key 1070 holder prefers to receive. Like the preferred symmetric algorithms, 1071 the list is ordered. Algorithm numbers are in section 6. This is only 1072 found on a self-signature. 1074 {{Editor's note: The above preference (hash algs) is controversial. I 1075 included it in for symmetry, because if someone wants to build a 1076 minimal OP implementation, there needs to be a way to tell someone that 1077 you won't be able to verify a signature unless it's made with some set 1078 of algorithms. It also permits to prefer DSA with RIPEMD-160, for 1079 example. If you have an opinion, please state it.}} 1081 Preferred compression algorithms (array of one-octet values) 1082 (Hashed) 1084 Compression algorithm numbers that indicate which algorithms the key 1085 holder prefers to use. Like the preferred symmetric algorithms, the 1086 list is ordered. Algorithm numbers are in section 6. If this 1087 subpacket is not included, ZIP is preferred. A zero denotes that no 1088 compression is preferred; the key holder's software may not have 1089 compression software. This is only found on a self-signature. 1091 Signature expiration time (4 octet time field) (Hashed) 1093 The validity period of the signature. This is the number of seconds 1094 after the signature creation time that the signature expires. If this 1095 is not present or has a value of zero, it never expires. 1097 Exportable (1 octet of exportability, 0 for not, 1 for exportable) 1098 (Hashed) 1100 Signature's exportability status. Packet body contains a boolean flag 1101 indicating whether the signature is exportable. Signatures which are 1102 not exportable are ignored during export and import operations. If 1103 this packet is not present the signature is assumed to be exportable. 1105 Revocable (1 octet of revocability, 0 for not, 1 for revocable) 1106 (Hashed) 1108 Signature's revocability status. Packet body contains a boolean flag 1109 indicating whether the signature is revocable. Signatures which are 1110 not revocable get any later revocation signatures ignored. They 1111 represent a commitment by the signer that he cannot revoke his 1112 signature for the life of his key. If this packet is not present the 1113 signature is assumed to be revocable. 1115 Trust signature (1 octet of "level" (depth), 1 octet of trust amount) 1116 (Hashed) 1117 Signer asserts that the key is not only valid, but also trustworthy, at 1118 the specified level. Level 0 has the same meaning as an ordinary 1119 validity signature. Level 1 means that the signed key is asserted to 1120 be a valid trusted introducer, with the 2nd octet of the body 1121 specifying the degree of trust. Level 2 means that the signed key is 1122 asserted to be trusted to issue level 1 trust signatures, i.e. that it 1123 is a "meta introducer". Generally, a level n trust signature asserts 1124 that a key is trusted to issue level n-1 trust signatures. The trust 1125 amount is in a range from 0-255, interpreted such that values less than 1126 120 indicate partial trust and values of 120 or greater indicate 1127 complete trust. Implementations SHOULD emit values of 60 for partial 1128 trust and 120 for complete trust. 1130 Regular expression (null-terminated regular expression) (Hashed) 1132 Used in conjunction with trust signature packets (of level > 0) to 1133 limit the scope of trust which is extended. Only signatures by the 1134 target key on user IDs which match the regular expression in the body 1135 of this packet have trust extended by the trust packet. 1137 Additional recipient request (1 octet of class, 1 octet of algid, 1138 20 octets of fingerprint) (Hashed) 1140 Key holder requests encryption to additional recipient when data is 1141 encrypted to this username. If the class octet contains 0x80, then the 1142 key holder strongly requests that the additional recipient be added to 1143 an encryption. Implementing software may treat this subpacket in any 1144 way it sees fit. This is found only on a self-signature. 1146 Revocation key (1 octet of class, 1 octet of algid, 20 octets of 1147 fingerprint) (Hashed) 1149 Authorizes the specified key to issue revocation self-signatures on 1150 this key. Class octet must have bit 0x80 set, other bits are for 1151 future expansion to other kinds of signature authorizations. This is 1152 found on a self-signature. 1154 Notation Data (4 octets of flags, 2 octets of name length, 1155 2 octets of value length, M octets of name data, 1156 N octets of value data) (Hashed) 1158 This subpacket describes a "notation" on the signature that the issuer 1159 wishes to make. The notation has a name and a value, each of which are 1160 strings of octets. There may be more than one notation in a signature. 1161 Notations can be used for any extension the issuer of the signature 1162 cares to make. The "flags" field holds four octets of flags. All 1163 undefined flags MUST be zero. Defined flags are: 1164 First octet: 0x80 = human-readable. This note is text, a note 1165 from one person to another, and has no 1166 meaning to software. 1167 Other octets: none. 1169 Key server preferences (N octets of flags) (Hashed) 1171 This is a list of flags that indicate preferences that the key holder 1172 has about how the key is handled on a key server. All undefined flags 1173 MUST be zero. 1175 First octet: 0x80 = No-modify -- the key holder requests that 1176 this key only be modified or updated by the 1177 key holder or an authorized administrator of 1178 the key server. 1179 This is found only on a self-signature. 1181 Preferred key server (String) (Hashed) 1183 This is a URL of a key server that the key holder prefers be used for 1184 updates. Note that keys with multiple user names can have a preferred 1185 key server for each user name. This is found only on a self-signature. 1187 Implementations SHOULD implement a "preference" and MAY implement a 1188 "request." 1190 {{Editor's note: None of the preferences have a way to specify a 1191 negative preference (for example, I like Triple-DES, don't use 1192 algorithm X). Tacitly, the absence of an algorithm from a set is a 1193 negative preference, but should there be an explicit way to give a 1194 negative preference? -jdcc}} 1196 {{Editor's note: A missing feature is to invalidate (or revoke) a user 1197 id, rather than the entire key. Lots of people want this, and many 1198 people have keys cluttered with old work email addresses. There is 1199 another related issue, that that is with key rollover -- suppose I'm 1200 retiring an old key, but I don't want to have to lose all my 1201 certification signatures. It would be nice if there were a way for a 1202 key to transfer itself to a new one. Lastly, if either (or both) of 1203 these is desirable, do we handle them with a new signature type, or 1204 with notations, which are an extension mechanism. I think that it 1205 makes sense to make a revocation type (because it's analogous to the 1206 other forms of revocation), but rollover might be best implemented as 1207 an extension. --jdcc}} 1209 {{Editor's note: PGP 3 designed, but never implemented a number of 1210 other subpacket types. They were: A signature version number; A set 1211 of key usage flags (signing key, encryption key for communication, and 1212 encryption key for storage); User ID of the signer; Policy URL; net 1213 location of the key. 1215 Some of these options are things the WG has talked about as being a 1216 Good Thing -- like flags denoting if a key is a comm key or a storage 1217 key. My design of such a feature would be different than the other 1218 one, though. I think it would be a great idea to have a URL that's a 1219 location to find the key, so people who prefer to have a web, ftp, or 1220 finger location can use those. However, some of them (like a URL) are 1221 also perfect for designing in with extensions. After all, we only have 1222 128 subpacket constants. 1224 --jdcc}} 1226 5.2.3 Signature Types 1228 There are a number of possible meanings for a signature, which are 1229 specified in a signature type octet in any given signature. These 1230 meanings are: 1232 - 0x00: Signature of a binary document. 1233 Typically, this means the signer owns it, created it, or certifies that 1234 it has not been modified. 1236 - 0x01: Signature of a canonical text document. 1237 Typically, this means the signer owns it, created it, or certifies that 1238 it has not been modified. The signature will be calculated over the 1239 textual data with its line endings converted to . 1241 - 0x02: Standalone signature. 1242 This signature is a signature of only its own subpacket contents. It 1243 is calculated identically to a signature over a zero-length binary 1244 document. 1246 - 0x10: The generic certification of a User ID and Public Key 1247 packet. 1248 The issuer of this certification does not make any particular assertion 1249 as to how well the certifier has checked that the owner of the key is 1250 in fact the person described by the user ID. Note that all PGP "key 1251 signatures" are this type of certification. 1253 - 0x11: This is a persona certification of a User ID and 1254 Public Key packet. 1255 It means that the issuer of this certification has not done any 1256 verification of the claim that the owner of this key is the user ID 1257 specified. Note that no released version of PGP has generated this 1258 type of certification. 1260 - 0x12: This is the casual certification of a User ID and 1261 Public Key packet. 1262 It means that the issuer of this certification has done some casual 1263 verification of the claim of identity. Note that no version of PGP has 1264 generated this type of certification, nor is there any definition of 1265 what constitutes a casual certification. 1267 - 0x13: This is the positive certification of a User ID and 1268 Public Key packet. 1269 It means that the issuer of this certification has done substantial 1270 verification of the claim of identity. Note that no version of PGP has 1271 generated this type of certification, nor is there any definition of 1272 what constitutes a positive certification. Please also note that the 1273 vagueness of these certification systems is not a flaw, but a feature 1274 of the system. Because PGP places final authority for validity upon 1275 the receiver of a certification, it may be that one authority's casual 1276 certification might be more rigorous than some other authority's 1277 positive certification. 1279 {{Editor's note: While there is a scale of identification signatures 1280 in the range 0x10 to 0x13, most of them have never been implemented or 1281 used. Current implementations only use 0x10, the "generic 1282 certification." Should the others be removed? RFC 1991 went to some 1283 trouble to explain which ones were defined but not implemented, or read 1284 but not generated. I think we should not do that. If we define them, 1285 they should be MAY features at the very least. If we're not going to 1286 use them, they shouldn't be in the spec. --jdcc}} 1288 - 0x18: This is used for a signature by a signature key to bind a 1289 subkey which will be used for encryption. 1290 The signature is calculated directly on the subkey itself, not on any 1291 User ID or other packets. 1293 - 0x20: This signature is used to revoke a key. 1294 The signature is calculated directly on the key being revoked. A 1295 revoked key is not to be used. Only revocation signatures by the key 1296 being revoked, or by an authorized revocation key, should be 1297 considered. 1299 - 0x28: This is used to revoke a subkey. 1300 The signature is calculated directly on the subkey being revoked. A 1301 revoked subkey is not to be used. Only revocation signatures by the 1302 top-level signature key which is bound to this subkey, or by an 1303 authorized revocation key, should be considered. 1305 - 0x30: This signature revokes an earlier user ID certification 1306 signature (signature class 0x10 - 0x13). 1307 It should be issued by the same key which issued the revoked signature, 1308 and should have a later creation date. 1310 - 0x40: Timestamp signature. 1312 {{Editor's note: The timestamp signature is left over from RFC 1991, 1313 and has never been fully designed nor implemented. Is this the sort of 1314 thing best handled by notations? --jdcc}} 1316 {{Editor's note: It would be nice to have a signature that applied to 1317 the key alone, rather than a key plus a user name. Perhaps this is 1318 best done with a notation. --jdcc}} 1320 {{Editor's note: There is presently no way for a key-signer (a.k.a. 1321 certifier) to sign a main key along with a subkey. There are a number 1322 of useful situations for a set of keys (main plus subkeys) to all be 1323 signed together. How do we solve this? --jdcc}} 1325 5.3 Conventional Encrypted Session-Key Packets (Tag 3) 1327 The Conventional Encrypted Session Key packet holds the 1328 conventional-cipher encryption of a session key used to encrypt a 1329 message. Zero or more Encrypted Session Key packets and/or 1330 Conventional Encrypted Session Key packets may precede a Symmetrically 1331 Encrypted Data Packet that holds an encrypted message. The message is 1332 encrypted with a session key, and the session key is itself encrypted 1333 and stored in the Encrypted Session Key packet or the Conventional 1334 Encrypted Session Key packet. 1336 If the Symmetrically Encrypted Data Packet is preceded by one or more 1337 Conventional Encrypted Session Key packets, each specifies a passphrase 1338 which may be used to decrypt the message. This allows a message to be 1339 encrypted to a number of public keys, and also to one or more pass 1340 phrases. This packet type is new, and is not generated by PGP 2.x or 1341 PGP 5.0. 1343 The body of this packet consists of: 1344 - A one-octet version number. The only currently defined version is 1345 4. 1346 - A one-octet number describing the symmetric algorithm used. 1347 - A string-to-key (S2K) specifier, length as defined above. 1348 - Optionally, the encrypted session key itself, which is decrypted 1349 with the string-to-key object. 1351 If the encrypted session key is not present (which can be detected on 1352 the basis of packet length and S2K specifier size), then the S2K 1353 algorithm applied to the passphrase produces the session key for 1354 decrypting the file, using the symmetric cipher algorithm from the 1355 Conventional Encrypted Session Key packet. 1357 If the encrypted session key is present, the result of applying the S2K 1358 algorithm to the passphrase is used to decrypt just that encrypted 1359 session key field, using CFB mode with an IV of all zeros. The 1360 decryption result consists of a one-octet algorithm identifier that 1361 specifies the conventional encryption algorithm used to encrypt the 1362 following Symmetrically Encrypted Data Packet, followed by the session 1363 key octets themselves. 1365 Note: because an all-zero IV is used for this decryption, the S2K 1366 specifier MUST use a salt value, either a a Salted S2K or an 1367 Iterated-Salted S2K. The salt value will insure that the decryption 1368 key is not repeated even if the passphrase is reused. 1370 5.4 One-Pass Signature Packets (Tag 4) 1372 The One-Pass Signature packet precedes the signed data and contains 1373 enough information to allow the receiver to begin calculating any 1374 hashes needed to verify the signature. It allows the Signature Packet 1375 to be placed at the end of the message, so that the signer can compute 1376 the entire signed message in one pass. 1378 A One-Pass Signature does not interoperate with PGP 2.6.x or earlier. 1380 The body of this packet consists of: 1381 - A one-octet version number. The current version is 3. 1382 - A one-octet signature type. Signature types are described 1383 in section 5.2.3. 1384 - A one-octet number describing the hash algorithm used. 1385 - A one-octet number describing the public key algorithm used. 1386 - An eight-octet number holding the key ID of the signing key. 1387 - A one-octet number holding a flag showing whether the signature 1388 is nested. A zero value indicates that the next packet is 1389 another One-Pass Signature packet which describes another 1390 signature to be applied to the same message data. 1392 5.5 Key Material Packet 1394 A key material packet contains all the information about a public or 1395 private key. There are four variants of this packet type, and two 1396 major versions. Consequently, this section is complex. 1398 5.5.1 Key Packet Variants 1400 5.5.1.1 Public Key Packet (Tag 6) 1402 A Public Key packet starts a series of packets that forms an OP key 1403 (sometimes called an OP certificate). 1405 5.5.1.2 Public Subkey Packet (Tag 14) 1407 A Public Subkey packet (tag 14) has exactly the same format as a Public 1408 Key packet, but denotes a subkey. One or more subkeys may be 1409 associated with a top-level key. By convention, the top-level key 1410 provides signature services, and the subkeys provide encryption 1411 services. 1413 Note: in PGP 2.6.X, tag 14 was intended to indicate a comment packet. 1415 This tag was selected for reuse because no previous version of PGP ever 1416 emitted comment packets but they did properly ignore them. Public 1417 Subkey packets are ignored by PGP 2.6.X and do not cause it to fail, 1418 providing a limited degree of backwards compatibility. 1420 5.5.1.3 Secret Key Packet (Tag 5) 1422 A Secret Key packet contains all the information that is found in a 1423 Public Key packet, including the public key material, but also includes 1424 the secret key material after all the public key fields. 1426 5.5.1.4 Secret Subkey Packet (Tag 7) 1428 A Secret Subkey packet (tag 7) is the subkey analog of the Secret Key 1429 packet, and has exactly the same format. 1431 5.5.2 Public Key Packet Formats 1433 There are two versions of key-material packets. Version 3 packets were 1434 first generated PGP 2.6. Version 2 packets are identical in format to 1435 Version 3 packets, but are generated by PGP 2.5 or before. PGP 5.0 1436 introduces version 4 packets, with new fields and semantics. PGP 2.6.X 1437 will not accept key-material packets with versions greater than 3. 1439 OP implementations SHOULD create keys with version 4 format. An 1440 implementation MAY generate a V3 key to ensure interoperability with 1441 old software; note, however, that V4 keys correct some security 1442 deficiencies in V3 keys. These deficiencies are described below. An 1443 implementation MUST NOT create a V3 key with a public key algorithm 1444 other than RSA. 1446 A version 3 public key or public subkey packet contains: 1447 - A one-octet version number (3). 1448 - A four-octet number denoting the time that the key was created. 1449 - A two-octet number denoting the time in days that this key is 1450 valid. If this number is zero, then it does not expire. 1451 - A one-octet number denoting the public key algorithm of this key 1452 - A series of multi-precision integers comprising the key 1453 material: 1454 - a multiprecision integer (MPI) of RSA public modulus n; 1455 - an MPI of RSA public encryption exponent e. 1457 The fingerprint of the key is formed by hashing the body (but not the 1458 two-octet length) of the MPIs that form the key material (public 1459 modulus n, followed by exponent e) with MD5. 1461 The eight-octet key ID of the key consists of the low 64 bits of the 1462 public modulus of an RSA key. 1464 Since the release of V3 keys, there have been a number of improvements 1465 desired in the key format. For example, if the key ID is a function of 1466 the public modulus, it is easy for a person to create a key that has 1467 the same key ID as some existing key. Similarly, MD5 is no longer the 1468 preferred hash algorithm, and not hashing the length of an MPI with its 1469 body increases the chances of a fingerprint collision. 1471 The version 4 format is similar to the version 3 format except for the 1472 absence of a validity period. This has been moved to the signature 1473 packet. In addition, fingerprints of version 4 keys are calculated 1474 differently from version 3 keys, as described elsewhere. 1476 A version 4 packet contains: 1477 - A one-octet version number (4). 1478 - A four-octet number denoting the time that the key was created. 1479 - A one-octet number denoting the public key algorithm of this key 1480 - A series of multi-precision integers comprising the key 1481 material. This algorithm-specific portion is: 1483 Algorithm Specific Fields for RSA public keys: 1484 - multiprecision integer (MPI) of RSA public modulus n; 1485 - MPI of RSA public encryption exponent e. 1487 Algorithm Specific Fields for DSA public keys: 1488 - MPI of DSA prime p; 1489 - MPI of DSA group order q (q is a prime divisor of p-1); 1490 - MPI of DSA group generator g; 1491 - MPI of DSA public key value y (= g**x where x is secret). 1493 Algorithm Specific Fields for Elgamal public keys: 1494 - MPI of Elgamal prime p; 1495 - MPI of Elgamal group generator g; 1496 - MPI of Elgamal public key value y (= g**x where x 1497 is secret). 1499 5.5.3 Secret Key Packet Formats 1501 The Secret Key and Secret Subkey packets contain all the data of the 1502 Public Key and Public Subkey packets, with additional 1503 algorithm-specific secret key data appended, in encrypted form. 1505 The packet contains: 1506 - A Public Key or Public Subkey packet, as described above 1507 - One octet indicating string-to-key usage conventions. 0 indicates 1508 that the secret key data is not encrypted. 255 indicates that a 1509 string-to-key specifier is being given. Any other value 1510 is a conventional encryption algorithm specifier. 1511 - [Optional] If string-to-key usage octet was 255, a one-octet 1512 conventional encryption algorithm. 1513 - [Optional] If string-to-key usage octet was 255, a string-to-key 1514 specifier. The length of the string-to-key specifier is implied 1515 by its type, as described above. 1516 - [Optional] If secret data is encrypted, eight-octet Initial Vector 1517 (IV). 1518 - Encrypted multi-precision integers comprising the secret key data. 1519 These algorithm-specific fields are as described below. 1521 - Two-octet checksum of the plaintext of the algorithm-specific 1522 portion (sum of all octets, mod 65536). 1524 Algorithm Specific Fields for RSA secret keys: 1525 - multiprecision integer (MPI) of RSA secret exponent d. 1526 - MPI of RSA secret prime value p. 1527 - MPI of RSA secret prime value q (p < q). 1528 - MPI of u, the multiplicative inverse of p, mod q. 1530 Algorithm Specific Fields for DSA secret keys: 1531 - MPI of DSA secret exponent x. 1533 Algorithm Specific Fields for Elgamal secret keys: 1534 - MPI of Elgamal secret exponent x. 1536 Secret MPI values can be encrypted using a passphrase. If a 1537 string-to-key specifier is given, that describes the algorithm for 1538 converting the passphrase to a key, else a simple MD5 hash of the 1539 passphrase is used. Implementations SHOULD use a string-to-key 1540 specifier; the simple hash is for backwards compatibility. The cipher 1541 for encrypting the MPIs is specified in the secret key packet. 1543 Encryption/decryption of the secret data is done in CFB mode using the 1544 key created from the passphrase and the Initial Vector from the packet. 1545 A different mode is used with RSA keys than with other key formats. 1546 With RSA keys, the MPI bit count prefix (i.e., the first two octets) is 1547 not encrypted. Only the MPI non-prefix data is encrypted. 1548 Furthermore, the CFB state is resynchronized at the beginning of each 1549 new MPI value, so that the CFB block boundary is aligned with the start 1550 of the MPI data. 1552 With non-RSA keys, a simpler method is used. All secret MPI values are 1553 encrypted in CFB mode, including the MPI bitcount prefix. 1555 The 16-bit checksum that follows the algorithm-specific portion is the 1556 algebraic sum, mod 65536, of the plaintext of all the 1557 algorithm-specific octets (including MPI prefix and data). With RSA 1558 keys, the checksum is stored in the clear. With non-RSA keys, the 1559 checksum is encrypted like the algorithm-specific data. This value is 1560 used to check that the passphrase was correct. 1562 5.6 Compressed Data Packet (Tag 8) 1564 The Compressed Data packet contains compressed data. Typically, this 1565 packet is found as the contents of an encrypted packet, or following a 1566 Signature or One-Pass Signature packet, and contains literal data 1567 packets. 1569 The body of this packet consists of: 1570 - One octet that gives the algorithm used to compress the packet. 1571 - The remainder of the packet is compressed data. 1573 A Compressed Data Packet's body contains an RFC1951 DEFLATE block that 1574 compresses some set of packets. See section 7 for details on how 1575 messages are formed. 1577 5.7 Symmetrically Encrypted Data Packet (Tag 9) 1579 The Symmetrically Encrypted Data packet contains data encrypted with a 1580 conventional (symmetric-key) algorithm. When it has been decrypted, it 1581 will typically contain other packets (often literal data packets or 1582 compressed data packets). 1584 The body of this packet consists of: 1586 - Encrypted data, the output of the selected conventional cipher 1587 operating in PGP's variant of Cipher Feedback (CFB) mode. 1589 The conventional cipher used may be specified in an Encrypted Session 1590 Key or Conventional Encrypted Session Key packet which precedes the 1591 Symmetrically Encrypted Data Packet. In that case, the cipher 1592 algorithm octet is prepended to the session key before it is encrypted. 1593 If no packets of these types precede the encrypted data, the IDEA 1594 algorithm is used with the session key calculated as the MD5 hash of 1595 the passphrase. 1597 The data is encrypted in CFB mode, with a CFB shift size equal to the 1598 cipher's block size [Ref]. The Initial Vector (IV) is specified as all 1599 zeros. Instead of using an IV, OP prepends a 10 octet string to the 1600 data before it is encrypted. The first eight octets are random, and 1601 the 9th and 10th octets are copies of the 7th and 8th octets, 1602 respectivelly. After encrypting the first 10 octets, the CFB state is 1603 resynchronized if the cipher block size is 8 octets or less. The last 1604 8 octets of ciphertext are passed through the cipher and the block 1605 boundary is reset. 1607 The repetition of 16 bits in the 80 bits of random data prepended to 1608 the message allows the receiver to immediately check whether the 1609 session key is correct. 1611 5.8 Marker Packet (Obsolete Literal Packet) (Tag 10) 1613 An experimental version of PGP used this packet as the Literal packet, 1614 but no released version of PGP generated Literal packets with this tag. 1615 With PGP 5.x, this packet has been re-assigned and is reserved for use 1616 as the Marker packet. 1618 The body of this packet consists of: 1619 - The three octets 0x60, 0x47, 0x60 (which spell "PGP" in UTF-8). 1621 Such a packet should be ignored on input. It may be placed at the 1622 beginning of a message that uses features not available in PGP 2.6.X in 1623 order to cause that version to report that newer software necessary to 1624 process the message. 1626 5.9 Literal Data Packet (Tag 11) 1627 A Literal Data packet contains the body of a message; data that is not 1628 to be further interpreted. 1630 The body of this packet consists of: 1631 - A one-octet field that describes how the data is formatted. 1632 If it is a 'b' (0x62), then the literal packet contains binary data. If 1633 it is a 't' (0x74), then it contains text data, and thus may need line 1634 ends converted to local form, or other text-mode changes. RFC 1991 1635 also defined a value of 'l' as a 'local' mode for machine-local 1636 conversions. This use is now deprecated. 1638 - File name as a string (one-octet length, followed by file name), 1639 if the encrypted data should be saved as a file. 1640 If the special name "_CONSOLE" is used, the message is considered to be 1641 "for your eyes only". This advises that the message data is unusually 1642 sensitive, and the receiving program should process it more carefully, 1643 perhaps avoiding storing the received data to disk, for example. 1645 - A four-octet number that indicates the modification date of the 1646 file, or the creation time of the packet, or a zero that indicates the 1647 present time. 1649 - The remainder of the packet is literal data. 1651 Text data is stored with text endings. This should be 1652 converted to native line endings by the receiving software. 1654 5.10 Trust Packet (Tag 12) 1656 The Trust packet is used only within keyrings and is not normally 1657 exported. Trust packets contain data that record the user's 1658 specifications of which key holders are trustworthy introducers, along 1659 with other information that implementing software uses for trust 1660 information. 1662 Trust packets SHOULD NOT be emitted to output streams that are 1663 transferred to other users, and they SHOULD be ignored on any input 1664 other than local keyring files. 1666 {{Editor's note: I have brushed aside the description of the old PGP 1667 trust packets for a number of reasons. They are context dependent; 1668 their meaning depends on the packet preceding them in a keyring. 1670 There is also a security problem with trust packets. For example, 1671 malicious software can write a new public key into a user's key ring 1672 with trust packets that make it trusted. 1674 A number of us have discussed this problem, and think that trust 1675 information should always be self-signed to act as an integrity check, 1676 but other people may have other solutions. 1678 My solution is to make trust packets implementation dependent. They 1679 are not emitted on export and ignored on import. Because of this, they 1680 are arguably out of scope of this document anyway. Given that the PGP 1681 implementation of trust packets has security flaws, this seems to be 1682 the best way to deal with them. 1684 --jdcc}} 1686 5.11 User ID Packet (Tag 13) 1688 A User ID packet consists of data which is intended to represent the 1689 name and email address of the key holder. By convention, it includes 1690 an RFC822 mail name, but there are no restrictions on its content. The 1691 packet length in the header specifies the length of the user name. If 1692 it is text, it is encoded in UTF-8. 1694 {{Editor's note: PRZ thinks there should be more types of "user ids" 1695 other than the traditional name, such as photos, and so on. The above 1696 definition, which assiduously avoids saying that the content of the 1697 packet is a counted string, is one potential way to handle it. Another 1698 would be to explicitly state that this packet is a string, and 1699 introduce a free-form user identification packet. 1701 A related issue with this document is that sometimes it says "user id" 1702 and sometimes "user name." We need some work here. Present plan is to 1703 use "User ID" everywhere. --jdcc}} 1705 {{Editor's note: Carl Ellison pointed out to me that if we have 1706 non-exportable (local to one's own keyring) usernames that I can assign 1707 to keys I use, then essentially we have SDSI naming in PGP. This is a 1708 Good Thing, in my opinion, but we have to have a way to define it. 1709 --jdcc}} 1711 5.12 Comment Packet (Tag 16) 1713 A Comment packet is used for holding data that is not relevant to 1714 software. Comment packets should be ignored. 1716 {{Editor's note: should? Must? What does it mean to ignore them? For 1717 example, if it's desirable to show a comment to a user, then how does 1718 that interact with should/must and a suitable definition of "ignore." I 1719 believe that they MUST be ignored, but displaying them to a user is 1720 ignoring them. Looking inside them for cryptographic content (like OP 1721 packets) is *not* ignoring them.}} 1723 {{Editor's note: should we put in an X.509 encapsulation packet type?}} 1725 6. Constants 1727 This section describes the constants used in OP. 1729 Note that these tables are not exhaustive lists; an implementation MAY 1730 implement an algorithm not on these lists. 1732 6.1 Public Key Algorithms 1734 1 - RSA (Encrypt or Sign) 1735 2 - RSA Encrypt-Only 1736 3 - RSA Sign-Only 1737 16 - Elgamal 1738 17 - DSA (Digital Signature Standard) 1739 100 to 110 - Private/Experimental algorithm. 1741 Implementations MUST implement DSA for signatures, and Elgamal for 1742 encryption. Implementations SHOULD implement RSA encryption. 1743 Implementations MAY implement any other algorithm. 1745 {{Editor's note: reserve an algorithm for elliptic curve? Note that 1746 I've left Elgamal signatures completely unmentioned. I think this is 1747 good. --jdcc}} 1749 6.2 Symmetric Key Algorithms 1751 0 - Plaintext 1752 1 - IDEA 1753 2 - Triple-DES (DES-EDE, as per spec - 1754 168 bit key derived from 192) 1755 3 - CAST5 (128 bit key) 1756 4 - Blowfish (128 bit key) 1757 5 - ROT-N (128 bit N) 1758 6 - SAFER-SK128 1759 7 - DES/SK 1760 100 to 110 - Private/Experimental algorithm. 1762 Implementations MUST implement Triple-DES. Implementations SHOULD 1763 implement IDEA and CAST5.Implementations MAY implement any other 1764 algorithm. 1766 6.3 Compression Algorithms 1768 0 - Uncompressed 1769 1 - ZIP 1770 100 to 110 - Private/Experimental algorithm. 1772 Implementations MUST implement uncompressed data. Implementations 1773 SHOULD implement ZIP. 1775 6.4 Hash Algorithms 1777 1 - MD5 1778 2 - SHA-1 1779 3 - RIPE-MD/160 1780 4 - HAVAL 1781 100 to 110 - Private/Experimental algorithm. 1783 Implementations MUST implement SHA-1. Implementations SHOULD implement 1784 MD5. 1786 7. Packet Composition 1788 OP packets may be assembled into sequences in order to create messages 1789 and transfer keys. Not all possible packet sequences are meaningful 1790 and correct. This describes the rules for how packets should be placed 1791 into sequences. 1793 7.1 Transferable Public Keys 1795 OP users may transfer public keys. The essential elements of a 1796 transferable public key are: 1798 - One Public Key packet 1799 - Zero or more revocation signatures 1800 - One or more User ID packets 1801 - After each User ID packet, zero or more Signature packets 1802 - Zero or more Subkey packets 1803 - After each Subkey packet, one or more Signature packets 1805 The Public Key packet occurs first. Each of the following User ID 1806 packets provides the identity of the owner of this public key. If 1807 there are multiple User ID packets, this corresponds to multiple means 1808 of identifying the same unique individual user; for example, a user may 1809 enjoy the use of more than one e-mail address, and construct a User ID 1810 packet for each one. 1812 Immediately following each User ID packet, there are zero or more 1813 signature packets. Each signature packet is calculated on the 1814 immediately preceding User ID packet and the initial Public Key packet. 1815 The signature serves to certify the corresponding public key and user 1816 ID. In effect, the signer is testifying to his or her belief that this 1817 public key belongs to the user identified by this user ID. 1819 After the User ID packets there may be one or more Subkey packets. 1820 Subkeys are used in cases where the top-level public key is a 1821 signature-only key. The subkeys are then encryption-only keys that are 1822 bound to the signature key. Each Subkey packet must be followed by at 1823 least one Signature packet, which should be of the subkey binding 1824 signature type, and issued by the top level key. 1826 {{Editor's note: I think it is a good idea to have signature-only 1827 subkeys, too (or even encrypt-and-sign subkeys), but no implementation 1828 does this. Should we generalize here? --jdcc}} 1830 Subkey and Key packets may each be followed by a revocation Signature 1831 packet to indicate that the key is revoked. Revocation signatures are 1832 only accepted if they are issued by the key itself, or by a key which 1833 is authorized to issue revocations via a revocation key subpacket in a 1834 self-signature by the top level key. 1836 Transferable public key packet sequences may be concatenated to allow 1837 transferring multiple public keys in one operation. 1839 7.2 OP Messages 1841 An OP message is a packet or sequence of packets that corresponds to 1842 the following grammatical rules (comma represents sequential 1843 composition, and vertical bar separates alternatives): 1845 OP Message :- Encrypted Message | Signed Message | Compressed Message 1846 | Literal Message. 1848 Compressed Message :- Compressed Data Packet. 1850 Literal Message :- Literal Data Packet. 1852 ESK :- Encrypted Session Key Packet | 1853 Conventionally Encrypted Session Key Packet. 1855 ESK Sequence :- ESK | ESK Sequence, ESK. 1857 Encrypted Message :- Symmetrically Encrypted Data Packet | 1858 ESK Sequence, Symmetrically Encrypted Data Packet. 1860 One-Pass Signed Message :- One-Pass Signature Packet, OP Message, 1861 Signature Packet. 1863 Signed Message :- Signature Packet, OP Message | 1864 One-Pass Signed Message. 1866 In addition, the decrypting a Symmetrically Encrypted Data packet and 1867 decompressing a Compressed Data packet must yield a valid OP Message. 1869 8. Enhanced Key Formats 1871 8.1 Key Structures 1873 The format of V3 OP key using RSA is as follows. Entries in square 1874 brackets are optional and ellipses indicate repetition. 1876 RSA Public Key 1877 [Revocation Self Signature] 1878 User ID [Signature ...] 1879 [User ID [Signature ...] ...] 1881 Each signature certifies the RSA public key and the preceding user ID. 1882 The RSA public key can have many user IDs and each user ID can have 1883 many signatures. 1885 The format of an OP V4 key that uses two public keys is very similar 1886 except that the second key is added to the end as a 'subkey' of the 1887 primary key. 1889 Primary-Key 1891 [Revocation Self Signature] 1892 User ID [Signature ...] 1893 [User ID [Signature ...] ...] 1894 [Subkey Primary-Key-Signature] 1896 The subkey always has a single signature after it that is issued using 1897 the primary key to tie the two keys together. The new format can use 1898 either the new signature packets or the old signature packets. 1900 In an Elgamal/DSA key, the DSA public key is the primary key, the 1901 Elgamal public key is the subkey, and either version 3 or 4 of the 1902 signature packet can be used. There may be other types of V4 keys, 1903 too. For example, there may be a single-key RSA key in V4 format, a DSA 1904 primary key with an RSA encryption key, etc, or RSA primary key with an 1905 Elgamal subkey. 1907 It is also possible to have a signature-only subkey. This permits a 1908 primary key that collects certifications (key signatures) but is used 1909 only used for certifying subkeys that are used for encryption and 1910 signatures. 1912 8.2 V4 Key IDs and Fingerprints 1914 A V4 fingerprint is the 160-bit SHA-1 hash of the one-octet Packet Tag, 1915 followed by the two-octet packet length, followed by the entire Public 1916 Key packet starting with the version field. The key ID is either the 1917 low order 32 bits or 64 bits of the fingerprint. Here are the fields 1918 of the hash material, with the example of a DSA key: 1920 a.1) 0x99 (1 byte) 1921 a.2) high order length byte of (b)-(f) (1 byte) 1922 a.3) low order length byte of (b)-(f) (1 byte) 1923 b) version number = 4 (1 byte); 1924 c) time stamp of key creation (4 bytes); 1925 e) algorithm (1 byte): 1926 17 = DSA; 1927 f) Algorithm specific fields. 1929 Algorithm Specific Fields for DSA keys (example): 1930 f.1) MPI of DSA prime p; 1931 f.2) MPI of DSA group order q (q is a prime divisor of p-1); 1932 f.3) MPI of DSA group generator g; 1933 f.4) MPI of DSA public key value y (= g**x where x is secret). 1935 9. Security Considerations 1937 As with any technology involving cryptography, you should check the 1938 current literature to determine if any algorithms used here have been 1939 found to be vulnerable to attack. 1941 This specification uses Public Key Cryptography technologies. 1943 Possession of the private key portion of a public-private key pair is 1944 assumed to be controlled by the proper party or parties. 1946 Certain operations in this specification involve the use of random 1947 numbers. An appropriate entropy source should be used to generate 1948 these numbers. See RFC 1750. 1950 The MD5 hash algorithm has been found to have weaknesses 1951 (pseudo-collisions in the compress function) that make some people 1952 deprecate its use. They consider the SHA-1 algorithm better. 1954 If you are building an authentication system, the recipient may specify 1955 a preferred signing algorithm. However, the signer would be foolish to 1956 use a weak algorithm simply because the recipient requests it. 1958 Some of the encryption algorithms mentioned in this document have been 1959 analyzed less than others. For example, although CAST5 is presently 1960 considered strong, it has been analyzed less than Triple-DES. Other 1961 algorithms may have other controversies surrounding them. 1963 Some technologies mentioned here may be subject to government control 1964 in some countries. 1966 10. Authors and Working Group Chair 1968 The working group can be contacted via the current chair: 1970 John W. Noerenberg, II Qualcomm, Inc 6455 Lusk Blvd San Diego, CA 1971 92131 USA Email: jwn2@qualcomm.com Tel: +1 619 658 3510 1973 The principal authors of this draft are (in alphabetical order): 1975 Jon Callas Pretty Good Privacy, Inc. 555 Twin Dolphin Drive, #570 1976 Redwood Shores, CA 94065, USA Email: jon@pgp.com Tel: +1-650-596-1960 1978 Lutz Donnerhacke IKS GmbH Wildenbruchstr. 15 07745 Jena, Germany EMail: 1979 lutz@iks-jena.de Tel: +49-3641-675642 1981 Hal Finney Pretty Good Privacy, Inc. 555 Twin Dolphin Drive, #570 1982 Redwood Shores, CA 94065, USA Email: hal@pgp.com Tel: +1-650-572-0430 1984 Rodney Thayer Sable Technology Corporation 246 Walnut Street Newton, MA 1985 02160 USA Email: rodney@sabletech.com Tel: +1-617-332-7292 1987 This draft also draws on much previous work from a number of other 1988 authors who include: Derek Atkins, Charles Breed, Dave Del Torto, Marc 1989 Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Raph Levine, 1990 Colin Plumb, Will Price, William Stallings, Mark Weaver, and Philip R. 1991 Zimmermann. 1993 11. References 1994 [CAMPBELL} Campbell, Joe, "C Programmer's Guide to Serial 1995 Communications" 1997 [DONNERHACKE] Donnerhacke, L., et. al, "PGP263in - an improved 1998 international version of PGP", 1999 ftp://ftp.iks-jena.de/mitarb/lutz/crypt/software/pgp/ 2001 [ISO-10646] ISO/IEC 10646-1:1993. International Standard -- 2002 Information technology -- Universal Multiple-Octet Coded Character Set 2003 (UCS) -- Part 1: Architecture and Basic Multilingual Plane. UTF-8 is 2004 described in Annex R, adopted but not yet published. UTF-16 is 2005 described in Annex Q, adopted but not yet published. 2007 [PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard," version 2008 1.5, November 1993 2010 [RFC822] D. Crocker, "Standard for the format of ARPA Internet text 2011 messages", RFC 822, August 1982 2013 [RFC1423] D. Balenson, "Privacy Enhancement for Internet Electronic 2014 Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, 2015 October 1993 2017 [RFC1641] Goldsmith, D., and M. Davis, "Using Unicode with MIME", RFC 2018 1641, Taligent inc., July 1994. 2020 [RFC1750] Eastlake, Crocker, & Schiller., Randomness Recommendations 2021 for Security. December 1994. 2023 [RFC1951] Deutsch, P., DEFLATE Compressed Data Format Specification 2024 version 1.3. May 1996. 2026 [RFC1983] G. Malkin., Internet Users' Glossary. August 1996. 2028 [RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message 2029 Exchange Formats", RFC 1991, August 1996. 2031 [RFC2015] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", 2032 RFC 2015, October 1996. 2034 [RFC2044] F. Yergeau., UTF-8, a transformation format of Unicode and 2035 ISO 10646. October 1996. 2037 [RFC2045] Borenstein, N., and Freed, N., "Multipurpose Internet Mail 2038 Extensions (MIME) Part One: Format of Internet Message Bodies.", 2039 November 1996 2041 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate 2042 Requirement Level. March 1997. 2044 12. Full Copyright Statement 2045 Copyright 1997 by The Internet Society. All Rights Reserved. 2047 This document and translations of it may be copied and furnished to 2048 others, and derivative works that comment on or otherwise explain it or 2049 assist in its implementation may be prepared, copied, published and 2050 distributed, in whole or in part, without restriction of any kind, 2051 provided that the above copyright notice and this paragraph are 2052 included on all such copies and derivative works. However, this 2053 document itself may not be modified in any way, such as by removing the 2054 copyright notice or references to the Internet Society or other 2055 Internet organizations, except as needed for the purpose of developing 2056 Internet standards in which case the procedures for copyrights defined 2057 in the Internet Standards process must be followed, or as required to 2058 translate it into languages other than English. 2060 The limited permissions granted above are perpetual and will not be 2061 revoked by the Internet Society or its successors or assigns.