1 2 3 4 5 6 7Network Working Group D. Atkins 8Request for Comments: 1991 MIT 9Category: Informational W. Stallings 10 Comp-Comm Consulting 11 P. Zimmermann 12 Boulder Software Engineering 13 August 1996 14 15 16 PGP Message Exchange Formats 17 18Status of This Memo 19 20 This memo provides information for the Internet community. This memo 21 does not specify an Internet standard of any kind. Distribution of 22 this memo is unlimited. 23 24Table of Contents 25 26 1. Introduction............................................2 27 2. PGP Services............................................2 28 2.1 Digital signature.......................................3 29 2.2 Confidentiality.........................................3 30 2.3 Compression.............................................4 31 2.4 Radix-64 conversion.....................................4 32 2.4.1 ASCII Armor Formats.....................................5 33 3. Data Element Formats....................................6 34 3.1 Byte strings............................................6 35 3.2 Whole number fields.....................................7 36 3.3 Multiprecision fields...................................7 37 3.4 String fields...........................................8 38 3.5 Time fields.............................................8 39 4. Common Fields...........................................8 40 4.1 Packet structure fields.................................8 41 4.2 Number ID fields.......................................10 42 4.3 Version fields.........................................10 43 5. Packets................................................10 44 5.1 Overview...............................................10 45 5.2 General Packet Structure...............................11 46 5.2.1 Message component......................................11 47 5.2.2 Signature component....................................11 48 5.2.3 Session key component..................................11 49 6. PGP Packet Types.......................................12 50 6.1 Literal data packets...................................12 51 6.2 Signature packets......................................13 52 6.2.1 Message-digest-related fields..........................14 53 6.2.2 Public-key-related fields..............................15 54 6.2.3 RSA signatures.........................................16 55 56 57 58Atkins, et. al. Informational [Page 1] 59 60RFC 1991 PGP Message Exchange Formats August 1996 61 62 63 6.2.4 Miscellaneous fields...................................16 64 6.3 Compressed data packets................................17 65 6.4 Conventional-key-encrypted data packets................17 66 6.4.1 Conventional-encryption type byte......................18 67 6.5 Public-key-encrypted packets...........................18 68 6.5.1 RSA-encrypted data encryption key (DEK)................19 69 6.6 Public-key Packets.....................................19 70 6.7 User ID packets........................................20 71 7. Transferable Public Keys...............................20 72 8. Acknowledgments........................................20 73 9. Security Considerations................................21 74 10. Authors' Addresses.....................................21 75 761. Introduction 77 78 PGP (Pretty Good Privacy) uses a combination of public-key and 79 conventional encryption to provide security services for electronic 80 mail messages and data files. These services include confidentiality 81 and digital signature. PGP is widely used throughout the global 82 computer community. This document describes the format of "PGP 83 files", i.e., messages that have been encrypted and/or signed with 84 PGP. 85 86 PGP was created by Philip Zimmermann and first released, in Version 87 1.0, in 1991. Subsequent versions have been designed and implemented 88 by an all-volunteer collaborative effort under the design guidance of 89 Philip Zimmermann. PGP and Pretty Good Privacy are trademarks of 90 Philip Zimmermann. 91 92 This document describes versions 2.x of PGP. Specifically, versions 93 2.6 and 2.7 conform to this specification. Version 2.3 conforms to 94 this specification with minor differences. 95 96 A new release of PGP, known as PGP 3.0, is anticipated in 1995. To 97 the maximum extent possible, this version will be upwardly compatible 98 with version 2.x. At a minimum, PGP 3.0 will be able to read messages 99 and signatures produced by version 2.x. 100 1012. PGP Services 102 103 PGP provides four services related to the format of messages and data 104 files: digital signature, confidentiality, compression, and radix-64 105 conversion. 106 107 108 109 110 111 112 113 114Atkins, et. al. Informational [Page 2] 115 116RFC 1991 PGP Message Exchange Formats August 1996 117 118 1192.1 Digital signature 120 121 The digital signature service involves the use of a hash code, or 122 message digest, algorithm, and a public-key encryption algorithm. The 123 sequence is as follows: 124 125 -the sender creates a message 126 -the sending PGP generates a hash code of the message 127 -the sending PGP encrypts the hash code using the sender's private 128 key 129 -the encrypted hash code is prepended to the message 130 -the receiving PGP decrypts the hash code using the sender's public 131 key 132 -the receiving PGP generates a new hash code for the received 133 message and compares it to the decrypted hash code. If the two 134 match, the message is accepted as authentic 135 136 Although signatures normally are found attached to the message or 137 file that they sign, this is not always the case: detached signatures 138 are supported. A detached signature may be stored and transmitted 139 separately from the message it signs. This is useful in several 140 contexts. A user may wish to maintain a separate signature log of all 141 messages sent or received. A detached signature of an executable 142 program can detect subsequent virus infection. Finally, detached 143 signatures can be used when more than one party must sign a document, 144 such as a legal contract. Each person's signature is independent and 145 therefore is applied only to the document. Otherwise, signatures 146 would have to be nested, with the second signer signing both the 147 document and the first signature, and so on. 148 1492.2 Confidentiality 150 151 PGP provides confidentiality by encrypting messages to be transmitted 152 or data files to be stored locally using conventional encryption. In 153 PGP, each conventional key is used only once. That is, a new key is 154 generated as a random 128-bit number for each message. Since it is to 155 be used only once, the session key is bound to the message and 156 transmitted with it. To protect the key, it is encrypted with the 157 receiver's public key. The sequence is as follows: 158 159 -the sender creates a message 160 -the sending PGP generates a random number to be used as a session 161 key for this message only 162 -the sending PGP encrypts the message using the session key 163 -the session key is encrypted using the recipient's public key and 164 prepended to the encrypted message 165 -the receiving PGP decrypts the session key using the recipient's 166 private key 167 168 169 170Atkins, et. al. Informational [Page 3] 171 172RFC 1991 PGP Message Exchange Formats August 1996 173 174 175 -the receiving PGP decrypts the message using the session key 176 177 Both digital signature and confidentiality services may be applied to 178 the same message. First, a signature is generated for the message and 179 prepended to the message. Then, the message plus signature is 180 encrypted using a conventional session key. Finally, the session key 181 is encrypted using public-key encryption and prepended to the 182 encrypted block. 183 1842.3 Compression 185 186 As a default, PGP compresses the message after applying the signature 187 but before encryption. 188 1892.4 Radix-64 conversion 190 191 When PGP is used, usually part of the block to be transmitted is 192 encrypted. If only the signature service is used, then the message 193 digest is encrypted (with the sender's private key). If the 194 confidentiality service is used, the message plus signature (if 195 present) are encrypted (with a one-time conventional key). Thus, part 196 or all of the resulting block consists of a stream of arbitrary 8-bit 197 bytes. However, many electronic mail systems only permit the use of 198 blocks consisting of ASCII text. To accommodate this restriction, PGP 199 provides the service of converting the raw 8-bit binary stream to a 200 stream of printable ASCII characters, called ASCII Armor. 201 202 The scheme used for this purpose is radix-64 conversion. Each group 203 of three bytes of binary data is mapped into 4 ASCII characters. This 204 format also appends a CRC to detect transmission errors. This 205 radix-64 conversion, also called Ascii Armor, is a wrapper around the 206 binary PGP messages, and is used to protect the binary messages 207 during transmission over non-binary channels, such as Internet Email. 208 209 The following table defines the mapping. The characters used are the 210 upper- and lower-case letters, the digits 0 through 9, and the 211 characters + and /. The carriage-return and linefeed characters 212 aren't used in the conversion, nor is the tab or any other character 213 that might be altered by the mail system. The result is a text file 214 that is "immune" to the modifications inflicted by mail systems. 215 216 217 218 219 220 221 222 223 224 225 226Atkins, et. al. Informational [Page 4] 227 228RFC 1991 PGP Message Exchange Formats August 1996 229 230 231 6-bit character 6-bit character 6-bit character 6-bit character 232 value encoding value encoding value encoding value encoding 233 0 A 16 Q 32 g 48 w 234 1 B 17 R 33 h 49 x 235 2 C 18 S 34 i 50 y 236 3 D 19 T 35 j 51 z 237 4 E 20 U 36 k 52 0 238 5 F 21 V 37 l 53 1 239 6 G 22 W 38 m 54 2 240 7 H 23 X 39 n 55 3 241 8 I 24 Y 40 o 56 4 242 9 J 25 Z 41 p 57 5 243 1 K 26 a 42 q 58 6 244 11 L 27 b 43 r 59 7 245 12 M 28 c 44 s 60 8 246 13 N 29 d 45 t 61 9 247 14 O 30 e 46 u 62 + 248 15 P 31 f 47 v 63 / 249 (pad) = 250 251 It is possible to use PGP to convert any arbitrary file to ASCII 252 Armor. When this is done, PGP tries to compress the data before it 253 is converted to Radix-64. 254 2552.4.1 ASCII Armor Formats 256 257 When PGP encodes data into ASCII Armor, it puts specific headers 258 around the data, so PGP can reconstruct the data at a future time. 259 PGP tries to inform the user what kind of data is encoded in the 260 ASCII armor through the use of the headers. 261 262 ASCII Armor is created by concatenating the following data: 263 264 - An Armor Headerline, appropriate for the type of data 265 - Armor Headers 266 - A blank line 267 - The ASCII-Armored data 268 - An Armor Checksum 269 - The Armor Tail (which depends on the Armor Headerline). 270 271 An Armor Headerline is composed by taking the appropriate headerline 272 text surrounded by five (5) dashes (-) on either side of the 273 headerline text. The headerline text is chosen based upon the type 274 of data that is being encoded in Armor, and how it is being encoded. 275 Headerline texts include the following strings: 276 277 BEGIN PGP MESSAGE -- used for signed, encrypted, or compressed files 278 BEGIN PGP PUBLIC KEY BLOCK -- used for transferring public keys 279 280 281 282Atkins, et. al. Informational [Page 5] 283 284RFC 1991 PGP Message Exchange Formats August 1996 285 286 287 BEGIN PGP MESSAGE, PART X/Y -- used for multi-part messages, where 288 the armor is split amongst Y files, 289 and this is the Xth file out of Y. 290 291 The Armor Headers are pairs of strings that can give the user or the 292 receiving PGP program some information about how to decode or use the 293 message. The Armor Headers are a part of the armor, not a part of 294 the message, and hence should not be used to convey any important 295 information, since they can be changed in transport. 296 297 The format of an Armor Header is that of a key-value pair, the 298 encoding of RFC-822 headers. PGP should consider improperly 299 formatted Armor Headers to be corruption of the ASCII Armor. Unknown 300 Keys should be reported to the user, but so long as the RFC-822 301 formatting is correct, PGP should continue to process the message. 302 Currently defined Armor Header Keys include "Version" and "Comment", 303 which define the PGP Version used to encode the message and a user- 304 defined comment. 305 306 The Armor Checksum is a 24-bit CRC converted to four bytes of radix- 307 64 encoding, prepending an equal-sign (=) to the four-byte code. The 308 CRC is computed by using the generator 0x864CFB and an initialization 309 of 0xB704CE. The accumulation is done on the data before it is 310 converted to radix-64, rather than on the converted data. For more 311 information on CRC functions, the reader is asked to look at chapter 312 19 of the book "C Programmer's Guide to Serial Communications," by 313 Joe Campbell. 314 315 The Armor Tail is composed in the same manner as the Armor 316 Headerline, except the string "BEGIN" is replaced by the string 317 "END". 318 3193. Data Element Formats 320 3213.1 Byte strings 322 323 The objects considered in this document are all "byte strings." A 324 byte string is a finite sequence of bytes. The concatenation of byte 325 string X of length M with byte string Y of length N is a byte string 326 Z of length M + N; the first M bytes of Z are the bytes of X in the 327 same order, and the remaining N bytes of Z are the bytes of Y in the 328 same order. 329 330 Literal byte strings are written from left to right, with pairs of 331 hex nibbles separated by spaces, enclosed by angle brackets: for 332 instance, <05 ff 07> is a byte string of length 3 whose bytes have 333 numeric values 5, 255, and 7 in that order. All numbers in this 334 document outside angle brackets are written in decimal. 335 336 337 338Atkins, et. al. Informational [Page 6] 339 340RFC 1991 PGP Message Exchange Formats August 1996 341 342 343 The byte string of length 0 is called "empty" and written <>. 344 3453.2 Whole number fields 346 347 Purpose. A whole number field can represent any nonnegative integer, 348 in a format where the field length is known in advance. 349 350 Definition. A whole number field is any byte string. It is stored 351 in radix-256 MSB-first format. This means that a whole number field 352 of length N with bytes b_0 b_1 ... b_{N-2} b_{N-1} in that order has 353 value 354 355 b_0 * 256^{N-1} + b_1 * 256^{N-2} + ... + b_{N-2} * 256 + b_{N-1}. 356 357 Examples. The byte string <00 0D 64 11 00 00> is a valid whole 358 number field with value 57513410560. The byte string <FF> is a valid 359 whole number field with value 255. The byte string <00 00> is a 360 valid whole number field with value 0. The empty byte string <> is a 361 valid whole number field with value 0. 362 3633.3 Multiprecision fields 364 365 Purpose. A multiprecision field can represent any nonnegative 366 integer which is not too large. The field length need not be known 367 in advance. Multiprecision fields are designed to waste very little 368 space: a small integer uses a short field. 369 370 Definition. A multiprecision field is the concatenation of two 371 fields: 372 373 (a) a whole number field of length 2, with value B; 374 (b) a whole number field, with value V. 375 376 Field (b) is of length [(B+7)/8], i.e., the greatest integer which is 377 no larger than (B+7)/8. The value of the multiprecision field is 378 defined to be V. V must be between 2^{B-1} and 2^B - 1 inclusive. 379 In other words B must be exactly the number of significant bits in V. 380 381 Some implementations may limit the possible range of B. The 382 implementor must document which values of B are allowed by an 383 implementation. 384 385 Examples. The byte string <00 00> is a valid multiprecision integer 386 with value 0. The byte string <00 03 05> is a valid multiprecision 387 field with value 5. The byte strings <00 03 85> and <00 00 00> are 388 not valid multiprecision fields. The former is invalild because <85> 389 has 8 significant bits, not 3; the latter is invalid because the 390 second field has too many bytes of data given the value of the first 391 392 393 394Atkins, et. al. Informational [Page 7] 395 396RFC 1991 PGP Message Exchange Formats August 1996 397 398 399 field. The byte string <00 09 01 ff> is a valid multiprecision field 400 with value 511. The byte string <01 00 80 00 00 00 00 00 00 00 00 00 401 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07> is 402 a valid multiprecision field with value 2^255 + 7. 403 4043.4 String fields 405 406 Purpose. A string field represents any sequence of bytes of length 407 between 0 and 255 inclusive. The length need not be known in 408 advance. By convention, the content of a string field is normally 409 interpreted as ASCII codes when it is displayed. 410 411 Definition. A string field is the concatenation of the following: 412 413 (a) a whole number field of length 1, with value L; 414 (b) a byte string of length L. 415 416 The content of the string field is defined to be field (b). 417 418 Examples: <05 48 45 4c 4c 4f> is a valid string field which would 419 normally be displayed as the string HELLO. <00> is a valid string 420 field which would normally be displayed as the empty string. <01 00> 421 is a valid string field. 422 4233.5 Time fields 424 425 Purpose. A time field represents the number of seconds elapsed since 426 1970 Jan 1 00:00:00 GMT. It is compatible with the usual 427 representation of times under UNIX. 428 429 Definition. A time field is a whole number field of length 4, with 430 value V. The time represented by the time field is the one-second 431 interval beginning V seconds after 1970 Jan 1 00:00:00 GMT. 432 4334. Common Fields 434 435 This section defines fields found in more than one packet format. 436 4374.1 Packet structure fields 438 439 Purpose. The packet structure field distinguishes between different 440 types of packets, and indicates the length of packets. 441 442 Definition. A packet structure field is a byte string of length 1, 443 2, 3, or 5. Its first byte is the cipher type byte (CTB), with bits 444 labeled 76543210, 7 the most significant bit and 0 the least 445 significant bit. As indicated below the length of the packet 446 structure field is determined by the CTB. 447 448 449 450Atkins, et. al. Informational [Page 8] 451 452RFC 1991 PGP Message Exchange Formats August 1996 453 454 455 CTB bits 76 have values listed in the following table: 456 457 10 - normal CTB 458 11 - reserved for future experimental work 459 all others - reserved 460 461 CTB bits 5432, the "packet type bits", have values listed in the 462 following table: 463 464 0001 - public-key-encrypted packet 465 0010 - signature packet 466 0101 - secret-key certificate packet 467 0110 - public-key certificate packet 468 1000 - compressed data packet 469 1001 - conventional-key-encrypted packet 470 1011 - literal data packet 471 1100 - keyring trust packet 472 1101 - user id packet 473 1110 - comment packet (*) 474 all others - reserved 475 476 CTB bits 10, the "packet-length length bits", have values listed in 477 the following table: 478 479 00 - 1-byte packet-length field 480 01 - 2-byte packet-length field 481 10 - 4-byte packet-length field 482 11 - no packet length supplied, unknown packet length 483 484 As indicated in this table, depending on the packet-length length 485 bits, the remaining 1, 2, 4, or 0 bytes of the packet structure field 486 are a "packet-length field". The packet-length field is a whole 487 number field. The value of the packet-length field is defined to be 488 the value of the whole number field. 489 490 A value of 11 is currently used in one place: on compressed data. 491 That is, a compressed data block currently looks like <A3 01 . . .>, 492 where <A3>, binary 10 1000 11, is an indefinite-length packet. The 493 proper interpretation is "until the end of the enclosing structure", 494 although it should never appear outermost (where the enclosing 495 structure is a file). 496 497 Options marked with an asterisk (*) are not implemented yet; PGP 498 2.6.2 will never output this packet type. 499 500 501 502 503 504 505 506Atkins, et. al. Informational [Page 9] 507 508RFC 1991 PGP Message Exchange Formats August 1996 509 510 5114.2 Number ID fields 512 513 Purpose. The ID of a whole number is its 64 least significant bits. 514 The ID is a convenient way to distinguish between large numbers such 515 as keys, without having to transmit the number itself. Thus, a number 516 that may be hundreds or thousands of decimal digits in length can be 517 identified with a 64-bit identifier. Two keys may have the same ID by 518 chance or by malice; although the probability that two large keys 519 chosen at random would have the same ID is extremely small. 520 521 Definition. A number ID field is a whole number field of length 8. 522 The value of the number ID field is defined to be the value of the 523 whole number field. 524 5254.3 Version fields 526 527 Many packet types include a version number as the first byte of the 528 body. The format and meaning of the body depend on the version 529 number. More versions of packets, with new version numbers, may be 530 defined in the future. An implementation need not support every 531 version of each packet type. However, the implementor must document 532 which versions of each packet type are supported by the 533 implementation. 534 535 A version number of 2 or 3 is currently allowed for each packet 536 format. New versions will probably be numbered sequentially up from 537 3. For backwards compatibility, implementations will usually be 538 expected to support version N of a packet whenever they support 539 version N+1. Version 255 may be used for experimental purposes. 540 5415. Packets 542 5435.1 Overview 544 545 A packet is a digital envelope with data inside. A PGP file, by 546 definition, is the concatenation of one or more packets. In addition, 547 one or more of the packets in a file may be subject to a 548 transformation using encryption, compression, or radix-64 conversion. 549 550 A packet is the concatenation of the following: 551 552 (a) a packet structure field; 553 (b) a byte string of some length N. 554 555 Byte string (b) is called the "body" of the packet. The value of the 556 packet-length field inside the packet structure field (a) must equal 557 N, the length of the body. 558 559 560 561 562Atkins, et. al. Informational [Page 10] 563 564RFC 1991 PGP Message Exchange Formats August 1996 565 566 567 Other characteristics of the packet are determined by the type of the 568 packet. See the definitions of particular packet types for further 569 details. The CTB packet-type bits inside the packet structure always 570 indicate the packet type. 571 572 Note that packets may be nested: one digital envelope may be placed 573 inside another. For example, a conventional-key-encrypted packet 574 contains a disguised packet, which in turn might be a compressed data 575 packet. 576 5775.2 General packet structure 578 579 A pgp file consists of three components: a message component, a 580 signature (optional), and a session key component (optional). 581 5825.2.1 Message component 583 584 The message component includes the actual data to be stored or 585 transmitted as well as a header that includes control information 586 generated by PGP. The message component consists of a single literal 587 data packet. 588 5895.2.2 Signature component 590 591 The signature component is the signature of the message component, 592 formed using a hash code of the message component and the public key 593 of the sending PGP entity. The signature component consists of a 594 single signature packet. 595 596 If the default option of compression is chosen, then the block 597 consisting of the literal data packet and the signature packet is 598 compressed to form a compressed data packet. 599 6005.2.3 Session key component 601 602 The session key component includes the encrypted session key and the 603 identifier of the recipients public key used by the sender to encrypt 604 the session key. The session key component consists of a single 605 public-key-encrypted packet for each recipient of the message. 606 607 If compression has been used, then conventional encryption is applied 608 to the compressed data packet formed from the compression of the 609 signature packet and the literal data packet. Otherwise, conventional 610 encryption is applied to the block consisting of the signature packet 611 and the literal data packet. In either case, the cyphertext is 612 referred to as a conventional-key-encrypted data packet. 613 614 615 616 617 618Atkins, et. al. Informational [Page 11] 619 620RFC 1991 PGP Message Exchange Formats August 1996 621 622 6236. PGP Packet Types 624 625 PGP includes the following types of packets: 626 627 -literal data packet 628 -signature packet 629 -compressed data packet 630 -conventional-key-encrypted data packet 631 -public-key-encrypted packet 632 -public-key packet 633 -User ID packet 634 6356.1 Literal data packets 636 637 Purpose. A literal data packet is the lowest level of contents of a 638 digital envelope. The data inside a literal data packet is not 639 subject to any further interpretation by PGP. 640 641 Definition. A literal data packet is the concatenation of the 642 following fields: 643 644 (a) a packet structure field; 645 (b) a byte, giving a mode; 646 (c) a string field, giving a filename; 647 (d) a time field; 648 (e) a byte string of literal data. 649 650 651 Fields (b), (c), and (d) suggest how the data should be written to a 652 file. Byte (b) is either ASCII b <62>, for binary, or ASCII t <74>, 653 for text. Byte (b) may also take on the value ASCII 1, indicating a 654 machine-local conversion. It is not defined how PGP will convert this 655 across platforms. 656 657 Field (c) suggests a filename. Field (d) should be the time at which 658 the file was last modified, or the time at which the data packet was 659 created, or 0. 660 661 Note that only field (e) of a literal data packet is fed to a 662 message-digest function for the formation of a signature. The 663 exclusion of the other fields ensures that detached signatures are 664 exactly the same as attached signatures prefixed to the message. 665 Detached signatures are calculated on a separate file that has none 666 of the literal data packet header fields. 667 668 669 670 671 672 673 674Atkins, et. al. Informational [Page 12] 675 676RFC 1991 PGP Message Exchange Formats August 1996 677 678 6796.2 Signature packet 680 681 Purpose. Signatures are attached to data, in such a way that only 682 one entity, called the "writer," can create the signature. The 683 writer must first create a "public key" K and distribute it. The 684 writer keeps certain private data related to K. Only someone 685 cooperating with the writer can sign data using K, enveloping the 686 data in a signature packet (also known as a private-key-encrypted 687 packet). Anyone can look through the glass in the envelope and 688 verify that the signature was attached to the data using K. If the 689 data is altered in any way then the verification will fail. 690 691 Signatures have different meanings. For example, a signature might 692 mean "I wrote this document," or "I received this document." A 693 signature packet includes a "classification" which expresses its 694 meaning. 695 696 Definition. A signature packet, version 2 or 3, is the concatenation 697 of the following fields: 698 699 (a) packet structure field (2, 3, or 5 bytes); 700 (b) version number = 2 or 3 (1 byte); 701 (c) length of following material included in MD calculation 702 (1 byte, always the value 5); 703 (d1) signature classification (1 byte); 704 (d2) signature time stamp (4 bytes); 705 (e) key ID for key used for singing (8 bytes); 706 (f) public-key-cryptosystem (PKC) type (1 byte); 707 (g) message digest algorithm type (1 byte); 708 (h) first two bytes of the MD output, used as a checksum 709 (2 bytes); 710 (i) a byte string of encrypted data holding the RSA-signed digest. 711 712 The message digest is taken of the bytes of the file, followed by the 713 bytes of field (d). It was originally intended that the length (c) 714 could vary, but now it seems that it will alwaye remain a constant 715 value of 5, and that is the only value that will be accepted. Thus, 716 only the fields (d1) and (d2) will be hashed into the signature along 717 with the main message. 718 719 720 721 722 723 724 725 726 727 728 729 730Atkins, et. al. Informational [Page 13] 731 732RFC 1991 PGP Message Exchange Formats August 1996 733 734 7356.2.1 Message-digest-related fields 736 737 The message digest algorithm is specified by the message digest (MD) 738 number of field (g). The following MD numbers are currently defined: 739 740 1 - MD5 (output length 16) 741 255 - experimental 742 743 More MD numbers may be defined in the future. An implementation need 744 not support every MD number. The implementor must document the MD 745 numbers understood by an implementation. 746 747 A message digest algorithm reads a byte string of any length, and 748 writes a byte string of some fixed length, as indicated in the table 749 above. 750 751 The input to the message digest algorithm is the concatenation of 752 some "primary input" and some "appended input." 753 754 The appended input is specified by field (c), which gives a number of 755 bytes to be taken from the following fields: (d1), (d2), and so on. 756 The current implementation uses the value 5 for this number, for 757 fields (d1) and (d2). Any field not included in the appended input 758 is not "signed" by field (i). 759 760 The primary input is determined by the signature classification byte 761 (d1). Byte (d1) is one of the following hex numbers, with these 762 meanings: 763 764 <00> - document signature, binary image ("I wrote this document") 765 <01> - document signature, canonical text ("I wrote this document") 766 <10> - public key packet and user ID packet, generic certification 767 ("I think this key was created by this user, but I won't say 768 how sure I am") 769 <11> - public key packet and user ID packet, persona certification 770 ("This key was created by someone who has told me that he is 771 this user") (#) 772 <12> - public key packet and user ID packet, casual certification 773 ("This key was created by someone who I believe, after casual 774 verification, to be this user") (#) 775 <13> - public key packet and user ID packet, positive certification 776 ("This key was created by someone who I believe, after 777 heavy-duty identification such as picture ID, to be this 778 user") (#) 779 <20> - public key packet, key compromise ("This is my key, and I 780 have revoked it") 781 782 783 784 785 786Atkins, et. al. Informational [Page 14] 787 788RFC 1991 PGP Message Exchange Formats August 1996 789 790 791 <30> - public key packet and user ID packet, revocation ("I retract 792 all my previous statements that this key is related to this 793 user") (*) 794 <40> - time stamping ("I saw this document") (*) 795 796 More classification numbers may be defined in the future to handle 797 other meanings of signatures, but only the above numbers may be used 798 with version 2 or version 3 of a signature packet. It should be 799 noted that PGP 2.6.2 has not implemented the packets marked with an 800 asterisk (*), and the packets marked with a hash (#) are not output 801 by PGP 2.6.2. 802 803 Signature packets are used in two different contexts. One (signature 804 type <00> or <01>) is of text (either the contents of a literal 805 packet or a separate file), while types <10> through <1F> appear only 806 in key files, after the keys and user IDs that they sign. Type <20> 807 appears in key files, after the keys that it signs, and type <30> 808 also appears after a key/userid combination. Type <40> is intended to 809 be a signature of a signature, as a notary seal on a signed document. 810 811 The output of the message digest algorithm is a message digest, or 812 hash code. Field i contains the cyphertext produced by encrypting the 813 message digest with the signer's private key. Field h contains the 814 first two bytes of the unencrypted message digest. This enables the 815 recipient to determine if the correct public key was used to decrypt 816 the message digest for authentication, by comparing this plaintext 817 copy of the first two byes with the first two bytes of the decrypted 818 digest. These two bytes also serve as a 16-bit frame check sequence 819 for the message. 820 8216.2.2 Public-key-related fields 822 823 The message digest is signed by encrypting it using the writer's 824 private key. Field (e) is the ID of the corresponding public key. 825 826 The public-key-encryption algorithm is specified by the public-key 827 cryptosystem (PKC) number of field (f). The following PKC numbers are 828 currently defined: 829 830 1 - RSA 831 255 - experimental 832 833 More PKC numbers may be defined in the future. An implementation 834 need not support every PKC number. The implementor must document the 835 PKC numbers understood by an implementation. 836 837 838 839 840 841 842Atkins, et. al. Informational [Page 15] 843 844RFC 1991 PGP Message Exchange Formats August 1996 845 846 847 A PKC number identifies both a public-key encryption method and a 848 signature method. Both of these methods are fully defined as part of 849 the definition of the PKC number. Some cryptosystems are usable only 850 for encryption, or only for signatures; if any such PKC numbers are 851 defined in the future, they will be marked appropriately. 852 8536.2.3 RSA signatures 854 855 An RSA-signed byte string is a multiprecision field that is formed by 856 taking the message digest and filling in an ASN structure, and then 857 encrypting the whole byte string in the RSA key of the signer. 858 859 PGP versions 2.3 and later encode the MD into a PKCS-format signature 860 string, which has the following format: 861 862 MSB . . . LSB 863 0 1 <FF>(n bytes) 0 ASN(18 bytes) MD(16 bytes) 864 865 See RFC1423 for an explanation of the meaning of the ASN string. It 866 is the following 18 byte long hex value: 867 868 <30 20 30 0C 06 08 2A 86 48 86 F7 0D 02 05 05 00 04 10> 869 870 Enough bytes of <FF> padding are added to make the length of this 871 whole string equal to the number of bytes in the modulus. 872 8736.2.4 Miscellaneous fields 874 875 The timestamp field (d2) is analogous to the date box next to a 876 signature box on a form. It represents a time which is typically 877 close to the moment that the signature packet was created. However, 878 this is not a requirement. Users may choose to date their signatures 879 as they wish, just as they do now in handwritten signatures. 880 881 If an application requires the creation of trusted timestamps on 882 signatures, a detached signature certificate with an untrusted 883 timestamp may be submitted to a trusted timestamp notary service to 884 sign the signature packet with another signature packet, creating a 885 signature of a signature. The notary's signature's timestamp could 886 be used as the trusted "legal" time of the original signature. 887 888 889 890 891 892 893 894 895 896 897 898Atkins, et. al. Informational [Page 16] 899 900RFC 1991 PGP Message Exchange Formats August 1996 901 902 9036.3 Compressed data packets 904 905 Purpose. A compressed data packet is an envelope which safely 906 squeezes its contents into a small space. 907 908 Definition. A compressed data packet is the concatenation of the 909 following fields: 910 911 (a) a packet structure field; 912 (b) a byte, giving a compression type; 913 (c) a byte string of compressed data. 914 915 Byte string (c) is a packet which may be decompressed using the 916 algorithm identified in byte (b). Typically, the data that are 917 compressed consist of a literal data packet or a signature packet 918 concatenated to a literal data packet. 919 920 A compression type selects a compression algorithm for use in 921 compressed data packets. The following compression numbers are 922 currently defined. 923 924 1 - ZIP 925 255 - experimental 926 927 More compression numbers may be defined in the future. An 928 implementation need not support every MD number. The implementor 929 must document the compression numbers understood by an 930 implementation. 931 9326.4 Conventional-key-encrypted data packets 933 934 Purpose. A conventional-key-encrypted data packet is formed by 935 encrypting a block of data with a conventional encryption algorithm 936 using a one-time session key. Typically, the block to be encrypted is 937 a compressed data packet. 938 939 Definition. A conventional-key-encrypted data packet is the 940 concatenation of the following fields: 941 942 (a) a packet structure field; 943 (b) a byte string of encrypted data. 944 945 The plaintext or compressed plaintext that is encrypted to form field 946 (b) is first prepended with 64 bits of random data plus 16 "key 947 check" bits. The random prefix serves to start off the cipher 948 feedback chaining process with 64 bits of random material; this 949 serves the same function as an initialization vector (IV) for a 950 cipher-block-chaining encryption scheme. The key check prefix is 951 952 953 954Atkins, et. al. Informational [Page 17] 955 956RFC 1991 PGP Message Exchange Formats August 1996 957 958 959 equal to the last 16 bits of the random prefix. During decryption, a 960 comparison is made to see if the 7th and 8th byte of the decrypted 961 material match the 9th and 10th bytes. If so, then the conventional 962 session key used for decryption is assumed to be correct. 963 9646.4.1 Conventional-encryption type byte 965 966 Purpose. The conventional-encryption type byte is used to determine 967 what conventional encryption algorithm is in use. The algorithm type 968 byte will also define how long the conventional encryption key is, 969 based upon the algorithm in use. 970 971 Definition. A conventional-encryption type byte is a single byte 972 which defines the algorithm in use. It is possible that the 973 algorithm in use may require further definition, such as key-length. 974 It is up to the implementor to document the supported key-length in 975 such a situation. 976 977 1 - IDEA (16-byte key) 978 255 - experimental 979 9806.5 Public-key-encrypted packets 981 982 Purpose. The public-key-encrypted packet is the format for the 983 session key component of a message. The purpose of this packet is to 984 convey the one-time session key used to encrypt the message to the 985 recipient in a secure manner. This is done by encrypting the session 986 key with the recipient's public key, so that only the recipient can 987 recover the session key. 988 989 Definition. A public-key-encrypted packet, version 2 or 3, is the 990 concatenation of the following fields: 991 992 (a) a packet structure field; 993 (b) a byte, giving the version number, 2 or 3; 994 (c) a number ID field, giving the ID of a key; 995 (d) a byte, giving a PKC number; 996 (e) a byte string of encrypted data (DEK). 997 998 Byte string (e) represents the value of the session key, encrypted 999 using the reader's public key K, under the cryptosystem identified in 1000 byte (d). 1001 1002 The value of field (c) is the ID of K. 1003 1004 Note that the packet does not actually identify K: two keys may have 1005 the same ID, by chance or by malice. Normally it will be obvious 1006 from the context which key K was used to create the packet. But 1007 1008 1009 1010Atkins, et. al. Informational [Page 18] 1011 1012RFC 1991 PGP Message Exchange Formats August 1996 1013 1014 1015 sometimes it is not obvious. In this case field (c) is useful. If, 1016 for example, a reader has created several keys, and receives a 1017 message, then he should attempt to decrypt the message only with the 1018 key whose ID matches the value of field (c). If he has accidentally 1019 generated two keys with the same ID, then he must attempt to decrypt 1020 the message with both keys, but this case is highly unlikely to occur 1021 by chance. 1022 10236.5.1 RSA-encrypted data encryption key (DEK) 1024 1025 The Data Encryption Key (DEK) is a multiprecision field which stores 1026 an RSA encrypted byte string. The byte string is a PKCS encoding of 1027 the secret key used the encrypt the message, with random padding for 1028 each Public-Key encrypted packet. 1029 1030 PGP version 2.3 and later encode the DEK into an MPI using the 1031 following format: 1032 1033 MSB . . . LSB 1034 0 2 RND(n bytes) 0 ALG(1 byte) DEK(k bytes) CSUM(2 bytes) 1035 1036 ALG refers to the algorithm byte for the secret key algorithm used to 1037 encrypt the data packet. The DEK is the actual Data Encryption Key, 1038 and its size is dependent upon the encryption algorithm defined by 1039 ALG. For the IDEA encryption algorithm, type byte 1, the DEK is 16 1040 bytes long. CSUM is a 16-bit checksum of the DEK, used to determine 1041 that the correct Private key was used to decrypt this packet. The 1042 checksum is computed by the 16-bit sum of the bytes in the DEK. RND 1043 is random padding to expand the byte to fill the size of the RSA 1044 Public Key that is used to encrypt the whole byte. 1045 10466.6 Public Key Packet 1047 1048 Purpose. A public key packet defines an RSA public key. 1049 1050 Definition. A public key packet is the concatenation of the 1051 following fields: 1052 1053 (a) packet structure field (2 or 3 bytes); 1054 (b) version number = 2 or 3 (1 byte);; 1055 (c) time stamp of key creation (4 bytes); 1056 (d) validity period in days (0 means forever) (2 bytes); 1057 (e) public-key-cryptosystem (PKC) type (1 byte); 1058 (f) MPI of RSA public modulus n; 1059 (g) MPI of RSA public encryption exponent e. 1060 1061 The validity period is always set to 0. 1062 1063 1064 1065 1066Atkins, et. al. Informational [Page 19] 1067 1068RFC 1991 PGP Message Exchange Formats August 1996 1069 1070 10716.7 User ID Packet 1072 1073 Purpose. A user ID packet identifies a user and is associated with a 1074 public or private key. 1075 1076 Definition. A user ID packet is the concatenation of the following 1077 fields: 1078 1079 (a) packet structure field (2 bytes); 1080 (b) User ID string. 1081 1082 The User ID string may be any string of printable ASCII characters. 1083 However, since the purpose of this packet is to uniquely identify an 1084 individual, the usual practice is for the User ID string to consist 1085 of the user's name followed by an e-mail address for that user, the 1086 latter enclosed in angle brackets. 1087 10887. Transferable Public Keys 1089 1090 Public keys may transferred between PGP users. The essential elements 1091 of a transferable public key are 1092 1093 (a) One public key packet; 1094 (b) One or more user ID packets; 1095 (c) Zero or more signature packets 1096 1097 The public key packet occurs first. Each of the following user ID 1098 packets provides the identity of the owner of this public key. If 1099 there are multiple user ID packets, this corresponds to multiple 1100 means of identifying the same unique individual user; for example, a 1101 user may enjoy the use of more than one e-mail address, and construct 1102 a user ID packet for each one. Immediately following each user ID 1103 packet, there are zero or more signature packets. Each signature 1104 packet is calculated on the immediately preceding user ID packet and 1105 the initial public key packet. The signature serves to certify the 1106 corresponding public key and user ID. In effect, the signer is 1107 testifying to his or her belief that this public key belongs to the 1108 user identified by this user ID. 1109 11108. Acknowledgments 1111 1112 Philip Zimmermann is the creator of PGP 1.0, which is the precursor 1113 of PGP 2.x. Major parts of later versions of PGP have been 1114 implemented by an international collaborative effort involving a 1115 large number of contributors, under the design guidance of Philip 1116 Zimmermann. 1117 1118 1119 1120 1121 1122Atkins, et. al. Informational [Page 20] 1123 1124RFC 1991 PGP Message Exchange Formats August 1996 1125 1126 11279. Security Considerations 1128 1129 Security issues are discussed throughout this memo. 1130 113110. Authors' Addresses 1132 1133 Derek Atkins 1134 12 Rindge Ave. #1R 1135 Cambridge, MA 1136 1137 Phone: +1 617 868-4469 1138 EMail: warlord@MIT.EDU 1139 1140 1141 William Stallings 1142 Comp-Comm Consulting 1143 P. O. Box 2405 1144 Brewster, MA 02631 1145 1146 EMail: stallings@ACM.org 1147 1148 1149 Philip Zimmermann 1150 Boulder Software Engineering 1151 3021 Eleventh Street 1152 Boulder, Colorado 80304 USA 1153 1154 Phone: +1-303-541-0140 1155 EMail: prz@acm.org 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178Atkins, et. al. Informational [Page 21] 1179 1180