idnits 2.17.1 draft-atkins-pgpformat-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. == Mismatching filename: the document gives the document name as 'draft-atkins-pgpformats-01', but the file name used is 'draft-atkins-pgpformat-01' == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 968 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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.) ** There are 285 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 14 has weird spacing: '...ment is an I...' == Line 15 has weird spacing: '...cuments of t...' == Line 16 has weird spacing: '...ups may also ...' == Line 20 has weird spacing: '... and may be...' == Line 21 has weird spacing: '...opriate to u...' == (280 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (July 1995) is 10503 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Atkins 2 INTERNET_DRAFT MIT 3 Category: Informational W. Stallings 4 Expires in six months Comp-Comm Consulting 5 P. Zimmermann 6 Boulder Software Engineering 7 July 1995 9 PGP Message Exchange Formats 10 12 Status of this memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 26 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 27 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 28 Rim). 30 Distribution of this memo is unlimited. Please send comments to the 31 mailing list. 33 Table of Contents 35 1. Introduction............................................2 36 2. PGP Services............................................3 37 2.1 Digital signature.......................................3 38 2.2 Confidentiality.........................................3 39 2.3 Compression.............................................4 40 2.4 Radix-64 conversion.....................................4 41 2.4.1 ASCII Armor Formats.....................................5 42 3. Data Element Formats....................................6 43 3.1 Byte strings............................................6 44 3.2 Whole number fields.....................................7 45 3.3 Multiprecision fields...................................7 46 3.4 String fields...........................................8 47 3.5 Time fields.............................................8 48 4. Common Fields...........................................8 49 4.1 Packet structure fields.................................8 50 4.2 Number ID fields.......................................10 51 4.3 Version fields.........................................10 52 5. Packets................................................10 53 5.1 Overview...............................................10 54 5.2 General Packet Structure...............................11 55 5.2.1 Message component......................................11 56 5.2.2 Signature component....................................11 57 5.2.3 Session key component..................................11 58 6. PGP Packet Types.......................................12 59 6.1 Literal data packets...................................12 60 6.2 Signature packets......................................13 61 6.2.1 Message-digest-related fields..........................14 62 6.2.2 Public-key-related fields..............................15 63 6.2.3 RSA signatures.........................................16 64 6.2.4 Miscellaneous fields...................................16 65 6.3 Compressed data packets................................16 66 6.4 Conventional-key-encrypted data packets................17 67 6.4.1 Conventional-encryption type byte......................18 68 6.5 Public-key-encrypted packets...........................18 69 6.5.1 RSA-encrypted data encryption key (DEK)................19 70 6.6 Public-key Packets.....................................19 71 6.7 User ID packets........................................19 72 7. Transferable Public Keys...............................20 73 8. Acknowledgments........................................20 74 9. Security Considerations................................20 75 10. Authors' Addresses.....................................21 77 1. Introduction 79 PGP (Pretty Good Privacy) uses a combination of public-key and 80 conventional encryption to provide security services for electronic 81 mail messages and data files. These services include confidentiality 82 and digital signature. PGP is widely used throughout the global 83 computer community. This document describes the format of "PGP 84 files", i.e., messages that have been encrypted and/or signed with 85 PGP. 87 PGP was created by Philip Zimmermann and first released, in Version 88 1.0, in 1991. Subsequent versions have been designed and implemented 89 by an all-volunteer collaborative effort under the design guidance of 90 Philip Zimmermann. PGP and Pretty Good Privacy are trademarks of 91 Philip Zimmermann. 93 This document describes versions 2.x of PGP. Specifically, versions 94 2.6 and 2.7 conform to this specification. Version 2.3 conforms to 95 this specification with minor differences. 97 A new release of PGP, known as PGP 3.0, is anticipated in 1995. To 98 the maximum extent possible, this version will be upwardly compatible 99 with version 2.x. At a minimum, PGP 3.0 will be able to read messages 100 and signatures produced by version 2.x. 102 2. PGP Services 104 PGP provides four services related to the format of messages and data 105 files: digital signature, confidentiality, compression, and radix-64 106 conversion. 108 2.1 Digital signature 110 The digital signature service involves the use of a hash code, or 111 message digest, algorithm, and a public-key encryption algorithm. The 112 sequence is as follows: 114 -the sender creates a message 115 -the sending PGP generates a hash code of the message 116 -the sending PGP encrypts the hash code using the sender's private 117 key 118 -the encrypted hash code is prepended to the message 119 -the receiving PGP decrypts the hash code using the sender's public 120 key 121 -the receiving PGP generates a new hash code for the received 122 message and compares it to the decrypted hash code. If the two 123 match, the message is accepted as authentic 125 Although signatures normally are found attached to the message or 126 file that they sign, this is not always the case: detached signatures 127 are supported. A detached signature may be stored and transmitted 128 separately from the message it signs. This is useful in several 129 contexts. A user may wish to maintain a separate signature log of all 130 messages sent or received. A detached signature of an executable 131 program can detect subsequent virus infection. Finally, detached 132 signatures can be used when more than one party must sign a document, 133 such as a legal contract. Each person's signature is independent and 134 therefore is applied only to the document. Otherwise, signatures 135 would have to be nested, with the second signer signing both the 136 document and the first signature, and so on. 138 2.2 Confidentiality 140 PGP provides confidentiality by encrypting messages to be transmitted 141 or data files to be stored locally using conventional encryption. In 142 PGP, each conventional key is used only once. That is, a new key is 143 generated as a random 128-bit number for each message. Since it is to 144 be used only once, the session key is bound to the message and 145 transmitted with it. To protect the key, it is encrypted with the 146 receiver's public key. The sequence is as follows: 148 -the sender creates a message 149 -the sending PGP generates a random number to be used as a session 150 key for this message only 151 -the sending PGP encrypts the message using the session key 152 -the session key is encrypted using the recipient's public key and 153 prepended to the encrypted message 154 -the receiving PGP decrypts the session key using the recipient's 155 private key 156 -the receiving PGP decrypts the message using the session key 158 Both digital signature and confidentiality services may be applied to 159 the same message. First, a signature is generated for the message and 160 prepended to the message. Then, the message plus signature is 161 encrypted using a conventional session key. Finally, the session key 162 is encrypted using public-key encryption and prepended to the 163 encrypted block. 165 2.3 Compression 167 As a default, PGP compresses the message after applying the signature 168 but before encryption. 170 2.4 Radix-64 conversion 172 When PGP is used, usually part of the block to be transmitted is 173 encrypted. If only the signature service is used, then the message 174 digest is encrypted (with the sender's private key). If the 175 confidentiality service is used, the message plus signature (if 176 present) are encrypted (with a one-time conventional key). Thus, part 177 or all of the resulting block consists of a stream of arbitrary 8-bit 178 bytes. However, many electronic mail systems only permit the use of 179 blocks consisting of ASCII text. To accommodate this restriction, PGP 180 provides the service of converting the raw 8-bit binary stream to a 181 stream of printable ASCII characters, called ASCII Armor. 183 The scheme used for this purpose is radix-64 conversion. Each group 184 of three bytes of binary data is mapped into 4 ASCII characters. This 185 format also appends a CRC to detect transmission errors. This 186 radix-64 conversion, also called Ascii Armor, is a wrapper around the 187 binary PGP messages, and is used to protect the binary messages 188 during transmission over non-binary channels, such as Internet Email. 190 The following table defines the mapping. The characters used are the 191 upper- and lower-case letters, the digits 0 through 9, and the 192 characters + and /. The carriage-return and linefeed characters 193 aren't used in the conversion, nor is the tab or any other character 194 that might be altered by the mail system. The result is a text file 195 that is "immune" to the modifications inflicted by mail systems. 197 6-bit character 6-bit character 6-bit character 6-bit character 198 value encoding value encoding value encoding value encoding 199 0 A 16 Q 32 g 48 w 200 1 B 17 R 33 h 49 x 201 2 C 18 S 34 i 50 y 202 3 D 19 T 35 j 51 z 203 4 E 20 U 36 k 52 0 204 5 F 21 V 37 l 53 1 205 6 G 22 W 38 m 54 2 206 7 H 23 X 39 n 55 3 207 8 I 24 Y 40 o 56 4 208 9 J 25 Z 41 p 57 5 209 1 K 26 a 42 q 58 6 210 11 L 27 b 43 r 59 7 211 12 M 28 c 44 s 60 8 212 13 N 29 d 45 t 61 9 213 14 O 30 e 46 u 62 + 214 15 P 31 f 47 v 63 / 215 (pad) = 217 It is possible to use PGP to convert any arbitrary file to ASCII 218 Armor. When this is done, PGP tries to compress the data before it 219 is converted to Radix-64. 221 2.4.1 ASCII Armor Formats 223 When PGP encodes data into ASCII Armor, it puts specific headers 224 around the data, so PGP can reconstruct the data at a future time. 225 PGP tries to inform the user what kind of data is encoded in the 226 ASCII armor through the use of the headers. 228 ASCII Armor is created by concatenating the following data: 230 - An Armor Headerline, appropriate for the type of data 231 - Armor Headers 232 - A blank line 233 - The ASCII-Armored data 234 - An Armor Checksum 235 - The Armor Tail (which depends on the Armor Headerline). 237 An Armor Headerline is composed by taking the appropriate headerline 238 text surrounded by five (5) dashes (-) on either side of the 239 headerline text. The headerline text is chosen based upon the type 240 of data that is being encoded in Armor, and how it is being encoded. 241 Headerline texts include the following strings: 243 BEGIN PGP MESSAGE -- used for signed, encrypted, or compressed files 244 BEGIN PGP PUBLIC KEY BLOCK -- used for transferring public keys 245 BEGIN PGP MESSAGE, PART X/Y -- used for multi-part messages, where 246 the armor is split amongst Y files, 247 and this is the Xth file out of Y. 249 The Armor Headers are pairs of strings that can give the user or the 250 receiving PGP program some information about how to decode or use the 251 message. The Armor Headers are a part of the armor, not a part of 252 the message, and hence should not be used to convey any important 253 information, since they can be changed in transport. 255 The format of an Armor Header is that of a key-value pair, the 256 encoding of RFC-822 headers. PGP should consider improperly 257 formatted Armor Headers to be corruption of the ASCII Armor. Unknown 258 Keys should be reported to the user, but so long as the RFC-822 259 formatting is correct, PGP should continue to process the message. 260 Currently defined Armor Header Keys include "Version" and "Comment", 261 which define the PGP Version used to encode the message and a 262 user-defined comment. 264 The Armor Checksum is a 24-bit CRC converted to four bytes of 265 radix-64 encoding, prepending an equal-sign (=) to the four-byte 266 code. The CRC is computed by using the generator 0x864CFB and an 267 initialization of 0xB704CE. The accumulation is done on the data 268 before it is converted to radix-64, rather than on the converted 269 data. For more information on CRC functions, the reader is asked to 270 look at chapter 19 of the book "C Programmer's Guide to Serial 271 Communications," by Joe Campbell. 273 The Armor Tail is composed in the same manner as the Armor 274 Headerline, except the string "BEGIN" is replaced by the string 275 "END". 277 3. Data Element Formats 279 3.1 Byte strings 281 The objects considered in this document are all "byte strings." A 282 byte string is a finite sequence of bytes. The concatenation of byte 283 string X of length M with byte string Y of length N is a byte string 284 Z of length M + N; the first M bytes of Z are the bytes of X in the 285 same order, and the remaining N bytes of Z are the bytes of Y in the 286 same order. 288 Literal byte strings are written from left to right, with pairs of 289 hex nibbles separated by spaces, enclosed by angle brackets: for 290 instance, <05 ff 07> is a byte string of length 3 whose bytes have 291 numeric values 5, 255, and 7 in that order. All numbers in this 292 document outside angle brackets are written in decimal. 294 The byte string of length 0 is called "empty" and written <>. 296 3.2 Whole number fields 298 Purpose. A whole number field can represent any nonnegative integer, 299 in a format where the field length is known in advance. 301 Definition. A whole number field is any byte string. It is stored 302 in radix-256 MSB-first format. This means that a whole number field 303 of length N with bytes b_0 b_1 ... b_{N-2} b_{N-1} in that order has 304 value 306 b_0 * 256^{N-1} + b_1 * 256^{N-2} + ... + b_{N-2} * 256 + b_{N-1}. 308 Examples. The byte string <00 0D 64 11 00 00> is a valid whole 309 number field with value 57513410560. The byte string is a valid 310 whole number field with value 255. The byte string <00 00> is a 311 valid whole number field with value 0. The empty byte string <> is a 312 valid whole number field with value 0. 314 3.3 Multiprecision fields 316 Purpose. A multiprecision field can represent any nonnegative 317 integer which is not too large. The field length need not be known 318 in advance. Multiprecision fields are designed to waste very little 319 space: a small integer uses a short field. 321 Definition. A multiprecision field is the concatenation of two 322 fields: 324 (a) a whole number field of length 2, with value B; 325 (b) a whole number field, with value V. 327 Field (b) is of length [(B+7)/8], i.e., the greatest integer which is 328 no larger than (B+7)/8. The value of the multiprecision field is 329 defined to be V. V must be between 2^{B-1} and 2^B - 1 inclusive. 330 In other words B must be exactly the number of significant bits in V. 332 Some implementations may limit the possible range of B. The 333 implementor must document which values of B are allowed by an 334 implementation. 336 Examples. The byte string <00 00> is a valid multiprecision integer 337 with value 0. The byte string <00 03 05> is a valid multiprecision 338 field with value 5. The byte strings <00 03 85> and <00 00 00> are 339 not valid multiprecision fields. The former is invalild because <85> 340 has 8 significant bits, not 3; the latter is invalid because the 341 second field has too many bytes of data given the value of the first 342 field. The byte string <00 09 01 ff> is a valid multiprecision field 343 with value 511. The byte string <01 00 80 00 00 00 00 00 00 00 00 00 344 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07> is 345 a valid multiprecision field with value 2^255 + 7. 347 3.4 String fields 349 Purpose. A string field represents any sequence of bytes of length 350 between 0 and 255 inclusive. The length need not be known in 351 advance. By convention, the content of a string field is normally 352 interpreted as ASCII codes when it is displayed. 354 Definition. A string field is the concatenation of the following: 356 (a) a whole number field of length 1, with value L; 357 (b) a byte string of length L. 359 The content of the string field is defined to be field (b). 361 Examples: <05 48 45 4c 4c 4f> is a valid string field which would 362 normally be displayed as the string HELLO. <00> is a valid string 363 field which would normally be displayed as the empty string. <01 00> 364 is a valid string field. 366 3.5 Time fields 368 Purpose. A time field represents the number of seconds elapsed since 369 1970 Jan 1 00:00:00 GMT. It is compatible with the usual 370 representation of times under UNIX. 372 Definition. A time field is a whole number field of length 4, with 373 value V. The time represented by the time field is the one-second 374 interval beginning V seconds after 1970 Jan 1 00:00:00 GMT. 376 4. Common Fields 378 This section defines fields found in more than one packet format. 380 4.1 Packet structure fields 382 Purpose. The packet structure field distinguishes between different 383 types of packets, and indicates the length of packets. 385 Definition. A packet structure field is a byte string of length 1, 386 2, 3, or 5. Its first byte is the cipher type byte (CTB), with bits 387 labeled 76543210, 7 the most significant bit and 0 the least 388 significant bit. As indicated below the length of the packet 389 structure field is determined by the CTB. 391 CTB bits 76 have values listed in the following table: 393 10 - normal CTB 394 11 - reserved for future experimental work 395 all others - reserved 397 CTB bits 5432, the "packet type bits", have values listed in the 398 following table: 400 0001 - public-key-encrypted packet 401 0010 - signature packet 402 0101 - secret-key certificate packet 403 0110 - public-key certificate packet 404 1000 - compressed data packet 405 1001 - conventional-key-encrypted packet 406 1011 - literal data packet 407 1100 - keyring trust packet 408 1101 - user id packet 409 1110 - comment packet (*) 410 all others - reserved 412 CTB bits 10, the "packet-length length bits", have values listed in 413 the following table: 415 00 - 1-byte packet-length field 416 01 - 2-byte packet-length field 417 10 - 4-byte packet-length field 418 11 - no packet length supplied, unknown packet length 420 As indicated in this table, depending on the packet-length length 421 bits, the remaining 1, 2, 4, or 0 bytes of the packet structure field 422 are a "packet-length field". The packet-length field is a whole 423 number field. The value of the packet-length field is defined to be 424 the value of the whole number field. 426 A value of 11 is currently used in one place: on compressed 427 data. That is, a compressed data block currently looks like , where , binary 10 1000 11, is an indefinite-length 429 packet. The proper interpretation is "until the end of the enclosing 430 structure", although it should never appear outermost (where the 431 enclosing structure is a file). 433 Options marked with an asterisk (*) are not implemented yet; PGP 434 2.6.2 will never output this packet type. 436 4.2 Number ID fields 438 Purpose. The ID of a whole number is its 64 least significant bits. 439 The ID is a convenient way to distinguish between large numbers such 440 as keys, without having to transmit the number itself. Thus, a number 441 that may be hundreds or thousands of decimal digits in length can be 442 identified with a 64-bit identifier. Two keys may have the same ID by 443 chance or by malice; although the probability that two large keys 444 chosen at random would have the same ID is extremely small. 446 Definition. A number ID field is a whole number field of length 8. 447 The value of the number ID field is defined to be the value of the 448 whole number field. 450 4.3 Version fields 452 Many packet types include a version number as the first byte of the 453 body. The format and meaning of the body depend on the version 454 number. More versions of packets, with new version numbers, may be 455 defined in the future. An implementation need not support every 456 version of each packet type. However, the implementor must document 457 which versions of each packet type are supported by the 458 implementation. 460 A version number of 2 or 3 is currently allowed for each packet 461 format. New versions will probably be numbered sequentially up from 462 3. For backwards compatibility, implementations will usually be 463 expected to support version N of a packet whenever they support 464 version N+1. Version 255 may be used for experimental purposes. 466 5. Packets 468 5.1 Overview 470 A packet is a digital envelope with data inside. A PGP file, by 471 definition, is the concatenation of one or more packets. In addition, 472 one or more of the packets in a file may be subject to a 473 transformation using encryption, compression, or radix-64 conversion. 475 A packet is the concatenation of the following: 477 (a) a packet structure field; 478 (b) a byte string of some length N. 480 Byte string (b) is called the "body" of the packet. The value of the 481 packet-length field inside the packet structure field (a) must equal 482 N, the length of the body. 484 Other characteristics of the packet are determined by the type of the 485 packet. See the definitions of particular packet types for further 486 details. The CTB packet-type bits inside the packet structure always 487 indicate the packet type. 489 Note that packets may be nested: one digital envelope may be placed 490 inside another. For example, a conventional-key-encrypted packet 491 contains a disguised packet, which in turn might be a compressed data 492 packet. 494 5.2 General packet structure 496 A pgp file consists of three components: a message component, a 497 signature (optional), and a session key component (optional). 499 5.2.1 Message component 501 The message component includes the actual data to be stored or 502 transmitted as well as a header that includes control information 503 generated by PGP. The message component consists of a single literal 504 data packet. 506 5.2.2 Signature component 508 The signature component is the signature of the message component, 509 formed using a hash code of the message component and the public key 510 of the sending PGP entity. The signature component consists of a 511 single signature packet. 513 If the default option of compression is chosen, then the block 514 consisting of the literal data packet and the signature packet is 515 compressed to form a compressed data packet. 517 5.2.3 Session key component 519 The session key component includes the encrypted session key and the 520 identifier of the recipients public key used by the sender to encrypt 521 the session key. The session key component consists of a single 522 public-key-encrypted packet for each recipient of the message. 524 If compression has been used, then conventional encryption is applied 525 to the compressed data packet formed from the compression of the 526 signature packet and the literal data packet. Otherwise, conventional 527 encryption is applied to the block consisting of the signature packet 528 and the literal data packet. In either case, the cyphertext is 529 referred to as a conventional-key-encrypted data packet. 531 6. PGP Packet Types 533 PGP includes the following types of packets: 535 -literal data packet 536 -signature packet 537 -compressed data packet 538 -conventional-key-encrypted data packet 539 -public-key-encrypted packet 540 -public-key packet 541 -User ID packet 543 6.1 Literal data packets 545 Purpose. A literal data packet is the lowest level of contents of a 546 digital envelope. The data inside a literal data packet is not 547 subject to any further interpretation by PGP. 549 Definition. A literal data packet is the concatenation of the 550 following fields: 552 (a) a packet structure field; 553 (b) a byte, giving a mode; 554 (c) a string field, giving a filename; 555 (d) a time field; 556 (e) a byte string of literal data. 558 Fields (b), (c), and (d) suggest how the data should be written to a 559 file. Byte (b) is either ASCII b <62>, for binary, or ASCII t <74>, 560 for text. Byte (b) may also take on the value ASCII 1, indicating a 561 machine-local conversion. It is not defined how PGP will convert this 562 across platforms. 564 Field (c) suggests a filename. Field (d) should be the time at which 565 the file was last modified, or the time at which the data packet was 566 created, or 0. 568 Note that only field (e) of a literal data packet is fed to a 569 message-digest function for the formation of a signature. The 570 exclusion of the other fields ensures that detached signatures are 571 exactly the same as attached signatures prefixed to the message. 572 Detached signatures are calculated on a separate file that has none 573 of the literal data packet header fields. 575 6.2 Signature packet 577 Purpose. Signatures are attached to data, in such a way that only 578 one entity, called the "writer," can create the signature. The 579 writer must first create a "public key" K and distribute it. The 580 writer keeps certain private data related to K. Only someone 581 cooperating with the writer can sign data using K, enveloping the 582 data in a signature packet (also known as a private-key-encrypted 583 packet). Anyone can look through the glass in the envelope and 584 verify that the signature was attached to the data using K. If the 585 data is altered in any way then the verification will fail. 587 Signatures have different meanings. For example, a signature might 588 mean "I wrote this document," or "I received this document." A 589 signature packet includes a "classification" which expresses its 590 meaning. 592 Definition. A signature packet, version 2 or 3, is the concatenation 593 of the following fields: 595 (a) packet structure field (2, 3, or 5 bytes); 596 (b) version number = 2 or 3 (1 byte); 597 (c) length of following material included in MD calculation 598 (1 byte, always the value 5); 599 (d1) signature classification (1 byte); 600 (d2) signature time stamp (4 bytes); 601 (e) key ID for key used for singing (8 bytes); 602 (f) public-key-cryptosystem (PKC) type (1 byte); 603 (g) message digest algorithm type (1 byte); 604 (h) first two bytes of the MD output, used as a checksum 605 (2 bytes); 606 (i) a byte string of encrypted data holding the RSA-signed digest. 608 The message digest is taken of the bytes of the file, followed by the 609 bytes of field (d). It was originally intended that the length (c) 610 could vary, but now it seems that it will alwaye remain a constant 611 value of 5, and that is the only value that will be accepted. Thus, 612 only the fields (d1) and (d2) will be hashed into the signature along 613 with the main message. 615 6.2.1 Message-digest-related fields 617 The message digest algorithm is specified by the message digest (MD) 618 number of field (g). The following MD numbers are currently defined: 620 1 - MD5 (output length 16) 621 255 - experimental 623 More MD numbers may be defined in the future. An implementation need 624 not support every MD number. The implementor must document the MD 625 numbers understood by an implementation. 627 A message digest algorithm reads a byte string of any length, and 628 writes a byte string of some fixed length, as indicated in the table 629 above. 631 The input to the message digest algorithm is the concatenation of 632 some "primary input" and some "appended input." 634 The appended input is specified by field (c), which gives a number of 635 bytes to be taken from the following fields: (d1), (d2), and so on. 636 The current implementation uses the value 5 for this number, for 637 fields (d1) and (d2). Any field not included in the appended input 638 is not "signed" by field (i). 640 The primary input is determined by the signature classification byte 641 (d1). Byte (d1) is one of the following hex numbers, with these 642 meanings: 644 <00> - document signature, binary image ("I wrote this document") 645 <01> - document signature, canonical text ("I wrote this document") 646 <10> - public key packet and user ID packet, generic certification 647 ("I think this key was created by this user, but I won't say 648 how sure I am") 649 <11> - public key packet and user ID packet, persona certification 650 ("This key was created by someone who has told me that he is 651 this user") (#) 652 <12> - public key packet and user ID packet, casual certification 653 ("This key was created by someone who I believe, after casual 654 verification, to be this user") (#) 655 <13> - public key packet and user ID packet, positive certification 656 ("This key was created by someone who I believe, after 657 heavy-duty identification such as picture ID, to be this 658 user") (#) 659 <20> - public key packet, key compromise ("This is my key, and I 660 have revoked it") 661 <30> - public key packet and user ID packet, revocation ("I retract 662 all my previous statements that this key is related to this 663 user") (*) 664 <40> - time stamping ("I saw this document") (*) 666 More classification numbers may be defined in the future to handle 667 other meanings of signatures, but only the above numbers may be used 668 with version 2 or version 3 of a signature packet. It should be 669 noted that PGP 2.6.2 has not implemented the packets marked with an 670 asterisk (*), and the packets marked with a hash (#) are not output 671 by PGP 2.6.2. 673 Signature packets are used in two different contexts. One (signature 674 type <00> or <01>) is of text (either the contents of a literal 675 packet or a separate file), while types <10> through <1F> appear only 676 in key files, after the keys and user IDs that they sign. Type <20> 677 appears in key files, after the keys that it signs, and type <30> 678 also appears after a key/userid combination. Type <40> is intended to 679 be a signature of a signature, as a notary seal on a signed document. 681 The output of the message digest algorithm is a message digest, or 682 hash code. Field i contains the cyphertext produced by encrypting the 683 message digest with the signer's private key. Field h contains the 684 first two bytes of the unencrypted message digest. This enables the 685 recipient to determine if the correct public key was used to decrypt 686 the message digest for authentication, by comparing this plaintext 687 copy of the first two byes with the first two bytes of the decrypted 688 digest. These two bytes also serve as a 16-bit frame check sequence 689 for the message. 691 6.2.2 Public-key-related fields 693 The message digest is signed by encrypting it using the writer's 694 private key. Field (e) is the ID of the corresponding public key. 696 The public-key-encryption algorithm is specified by the public-key 697 cryptosystem (PKC) number of field (f). The following PKC numbers are 698 currently defined: 700 1 - RSA 701 255 - experimental 703 More PKC numbers may be defined in the future. An implementation 704 need not support every PKC number. The implementor must document the 705 PKC numbers understood by an implementation. 707 A PKC number identifies both a public-key encryption method and a 708 signature method. Both of these methods are fully defined as part of 709 the definition of the PKC number. Some cryptosystems are usable only 710 for encryption, or only for signatures; if any such PKC numbers are 711 defined in the future, they will be marked appropriately. 713 6.2.3 RSA signatures 715 An RSA-signed byte string is a multiprecision field that is formed by 716 taking the message digest and filling in an ASN structure, and then 717 encrypting the whole byte string in the RSA key of the signer. 719 PGP versions 2.3 and later encode the MD into a PKCS-format signature 720 string, which has the following format: 722 MSB . . . LSB 723 0 1 (n bytes) 0 ASN(18 bytes) MD(16 bytes) 725 See RFC1423 for an explanation of the meaning of the ASN string. It 726 is the following 18 byte long hex value: 728 <30 20 30 0C 06 08 2A 86 48 86 F7 0D 02 05 05 00 04 10> 730 Enough bytes of padding are added to make the length of this 731 whole string equal to the number of bytes in the modulus. 733 6.2.4 Miscellaneous fields 735 The timestamp field (d2) is analogous to the date box next to a 736 signature box on a form. It represents a time which is typically 737 close to the moment that the signature packet was created. However, 738 this is not a requirement. Users may choose to date their signatures 739 as they wish, just as they do now in handwritten signatures. 741 If an application requires the creation of trusted timestamps on 742 signatures, a detached signature certificate with an untrusted 743 timestamp may be submitted to a trusted timestamp notary service to 744 sign the signature packet with another signature packet, creating a 745 signature of a signature. The notary's signature's timestamp could 746 be used as the trusted "legal" time of the original signature. 748 6.3 Compressed data packets 750 Purpose. A compressed data packet is an envelope which safely 751 squeezes its contents into a small space. 753 Definition. A compressed data packet is the concatenation of the 754 following fields: 756 (a) a packet structure field; 757 (b) a byte, giving a compression type; 758 (c) a byte string of compressed data. 760 Byte string (c) is a packet which may be decompressed using the 761 algorithm identified in byte (b). Typically, the data that are 762 compressed consist of a literal data packet or a signature packet 763 concatenated to a literal data packet. 765 A compression type selects a compression algorithm for use in 766 compressed data packets. The following compression numbers are 767 currently defined. 769 1 - ZIP 770 255 - experimental 772 More compression numbers may be defined in the future. An 773 implementation need not support every MD number. The implementor 774 must document the compression numbers understood by an 775 implementation. 777 6.4 Conventional-key-encrypted data packets 779 Purpose. A conventional-key-encrypted data packet is formed by 780 encrypting a block of data with a conventional encryption algorithm 781 using a one-time session key. Typically, the block to be encrypted is 782 a compressed data packet. 784 Definition. A conventional-key-encrypted data packet is the 785 concatenation of the following fields: 787 (a) a packet structure field; 788 (b) a byte string of encrypted data. 790 The plaintext or compressed plaintext that is encrypted to form field 791 (b) is first prepended with 64 bits of random data plus 16 "key 792 check" bits. The random prefix serves to start off the cipher 793 feedback chaining process with 64 bits of random material; this 794 serves the same function as an initialization vector (IV) for a 795 cipher-block-chaining encryption scheme. The key check prefix is 796 equal to the last 16 bits of the random prefix. During decryption, a 797 comparison is made to see if the 7th and 8th byte of the decrypted 798 material match the 9th and 10th bytes. If so, then the conventional 799 session key used for decryption is assumed to be correct. 801 6.4.1 Conventional-encryption type byte 803 Purpose. The conventional-encryption type byte is used to determine 804 what conventional encryption algorithm is in use. The algorithm type 805 byte will also define how long the conventional encryption key is, 806 based upon the algorithm in use. 808 Definition. A conventional-encryption type byte is a single byte 809 which defines the algorithm in use. It is possible that the 810 algorithm in use may require further definition, such as key-length. 811 It is up to the implementor to document the supported key-length in 812 such a situation. 814 1 - IDEA (16-byte key) 815 255 - experimental 817 6.5 Public-key-encrypted packets 819 Purpose. The public-key-encrypted packet is the format for the 820 session key component of a message. The purpose of this packet is to 821 convey the one-time session key used to encrypt the message to the 822 recipient in a secure manner. This is done by encrypting the session 823 key with the recipient's public key, so that only the recipient can 824 recover the session key. 826 Definition. A public-key-encrypted packet, version 2 or 3, is the 827 concatenation of the following fields: 829 (a) a packet structure field; 830 (b) a byte, giving the version number, 2 or 3; 831 (c) a number ID field, giving the ID of a key; 832 (d) a byte, giving a PKC number; 833 (e) a byte string of encrypted data (DEK). 835 Byte string (e) represents the value of the session key, encrypted 836 using the reader's public key K, under the cryptosystem identified in 837 byte (d). 839 The value of field (c) is the ID of K. 841 Note that the packet does not actually identify K: two keys may have 842 the same ID, by chance or by malice. Normally it will be obvious 843 from the context which key K was used to create the packet. But 844 sometimes it is not obvious. In this case field (c) is useful. If, 845 for example, a reader has created several keys, and receives a 846 message, then he should attempt to decrypt the message only with the 847 key whose ID matches the value of field (c). If he has accidentally 848 generated two keys with the same ID, then he must attempt to decrypt 849 the message with both keys, but this case is highly unlikely to occur 850 by chance. 852 6.5.1 RSA-encrypted data encryption key (DEK) 854 The Data Encryption Key (DEK) is a multiprecision field which stores 855 an RSA encrypted byte string. The byte string is a PKCS encoding of 856 the secret key used the encrypt the message, with random padding for 857 each Public-Key encrypted packet. 859 PGP version 2.3 and later encode the DEK into an MPI using the 860 following format: 862 MSB . . . LSB 863 0 2 RND(n bytes) 0 ALG(1 byte) DEK(k bytes) CSUM(2 bytes) 865 ALG refers to the algorithm byte for the secret key algorithm used to 866 encrypt the data packet. The DEK is the actual Data Encryption Key, 867 and its size is dependent upon the encryption algorithm defined by 868 ALG. For the IDEA encryption algorithm, type byte 1, the DEK is 16 869 bytes long. CSUM is a 16-bit checksum of the DEK, used to determine 870 that the correct Private key was used to decrypt this packet. The 871 checksum is computed by the 16-bit sum of the bytes in the DEK. RND 872 is random padding to expand the byte to fill the size of the RSA 873 Public Key that is used to encrypt the whole byte. 875 6.6 Public Key Packet 877 Purpose. A public key packet defines an RSA public key. 879 Definition. A public key packet is the concatenation of the 880 following fields: 882 (a) packet structure field (2 or 3 bytes); 883 (b) version number = 2 or 3 (1 byte);; 884 (c) time stamp of key creation (4 bytes); 885 (d) validity period in days (0 means forever) (2 bytes); 886 (e) public-key-cryptosystem (PKC) type (1 byte); 887 (f) MPI of RSA public modulus n; 888 (g) MPI of RSA public encryption exponent e. 890 The validity period is always set to 0. 892 6.7 User ID Packet 894 Purpose. A user ID packet identifies a user and is associated with a 895 public or private key. 897 Definition. A user ID packet is the concatenation of the following 898 fields: 900 (a) packet structure field (2 bytes); 901 (b) User ID string. 903 The User ID string may be any string of printable ASCII characters. 904 However, since the purpose of this packet is to uniquely identify an 905 individual, the usual practice is for the User ID string to consist 906 of the user's name followed by an e-mail address for that user, the 907 latter enclosed in angle brackets. 909 7. Transferable Public Keys 911 Public keys may transferred between PGP users. The essential elements 912 of a transferable public key are 914 (a) One public key packet; 915 (b) One or more user ID packets; 916 (c) Zero or more signature packets 918 The public key packet occurs first. Each of the following user ID 919 packets provides the identity of the owner of this public key. If 920 there are multiple user ID packets, this corresponds to multiple 921 means of identifying the same unique individual user; for example, a 922 user may enjoy the use of more than one e-mail address, and construct 923 a user ID packet for each one. Immediately following each user ID 924 packet, there are zero or more signature packets. Each signature 925 packet is calculated on the immediately preceding user ID packet and 926 the initial public key packet. The signature serves to certify the 927 corresponding public key and user ID. In effect, the signer is 928 testifying to his or her belief that this public key belongs to the 929 user identified by this user ID. 931 8. Acknowledgments 933 Philip Zimmermann is the creator of PGP 1.0, which is the precursor 934 of PGP 2.x. Major parts of later versions of PGP have been 935 implemented by an international collaborative effort involving a 936 large number of contributors, under the design guidance of Philip 937 Zimmermann. 939 9. Security Considerations 941 Security issues are discussed throughout this memo. 943 10. Authors' Addresses 945 Derek Atkins 946 12 Rindge Ave. #1R 947 Cambridge, MA 948 Phone: +1 617 868-4469 949 EMail: warlord@MIT.EDU 951 William Stallings 952 Comp-Comm Consulting 953 P. O. Box 2405 954 Brewster, MA 02631 955 EMail: stallings@ACM.org 957 Philip Zimmermann 958 Boulder Software Engineering 959 3021 Eleventh Street 960 Boulder, Colorado 80304 USA 961 Phone: +1-303-541-0140 962 EMail: prz@acm.org