| blob | aa5018304589871b7ec027bd31adfad54666c11c |
7 Network Working Group D. Atkins
8 Request for Comments: 1991 MIT
9 Category: Informational W. Stallings
10 Comp-Comm Consulting
11 P. Zimmermann
12 Boulder Software Engineering
13 August 1996
16 PGP Message Exchange Formats
18 Status of This Memo
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.
24 Table of Contents
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
58 Atkins, et. al. Informational [Page 1]
59 \f
60 RFC 1991 PGP Message Exchange Formats August 1996
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
76 1. Introduction
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.
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.
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.
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.
101 2. PGP Services
103 PGP provides four services related to the format of messages and data
104 files: digital signature, confidentiality, compression, and radix-64
105 conversion.
114 Atkins, et. al. Informational [Page 2]
115 \f
116 RFC 1991 PGP Message Exchange Formats August 1996
119 2.1 Digital signature
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:
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
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.
149 2.2 Confidentiality
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:
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
170 Atkins, et. al. Informational [Page 3]
171 \f
172 RFC 1991 PGP Message Exchange Formats August 1996
175 -the receiving PGP decrypts the message using the session key
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.
184 2.3 Compression
186 As a default, PGP compresses the message after applying the signature
187 but before encryption.
189 2.4 Radix-64 conversion
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.
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.
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.
226 Atkins, et. al. Informational [Page 4]
227 \f
228 RFC 1991 PGP Message Exchange Formats August 1996
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) =
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.
255 2.4.1 ASCII Armor Formats
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.
262 ASCII Armor is created by concatenating the following data:
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).
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:
277 BEGIN PGP MESSAGE -- used for signed, encrypted, or compressed files
278 BEGIN PGP PUBLIC KEY BLOCK -- used for transferring public keys
282 Atkins, et. al. Informational [Page 5]
283 \f
284 RFC 1991 PGP Message Exchange Formats August 1996
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.
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.
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.
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.
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".
319 3. Data Element Formats
321 3.1 Byte strings
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.
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.
338 Atkins, et. al. Informational [Page 6]
339 \f
340 RFC 1991 PGP Message Exchange Formats August 1996
343 The byte string of length 0 is called "empty" and written <>.
345 3.2 Whole number fields
347 Purpose. A whole number field can represent any nonnegative integer,
348 in a format where the field length is known in advance.
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
355 b_0 * 256^{N-1} + b_1 * 256^{N-2} + ... + b_{N-2} * 256 + b_{N-1}.
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.
363 3.3 Multiprecision fields
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.
370 Definition. A multiprecision field is the concatenation of two
371 fields:
373 (a) a whole number field of length 2, with value B;
374 (b) a whole number field, with value V.
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.
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.
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
394 Atkins, et. al. Informational [Page 7]
395 \f
396 RFC 1991 PGP Message Exchange Formats August 1996
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.
404 3.4 String fields
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.
411 Definition. A string field is the concatenation of the following:
413 (a) a whole number field of length 1, with value L;
414 (b) a byte string of length L.
416 The content of the string field is defined to be field (b).
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.
423 3.5 Time fields
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.
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.
433 4. Common Fields
435 This section defines fields found in more than one packet format.
437 4.1 Packet structure fields
439 Purpose. The packet structure field distinguishes between different
440 types of packets, and indicates the length of packets.
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.
450 Atkins, et. al. Informational [Page 8]
451 \f
452 RFC 1991 PGP Message Exchange Formats August 1996
455 CTB bits 76 have values listed in the following table:
457 10 - normal CTB
458 11 - reserved for future experimental work
459 all others - reserved
461 CTB bits 5432, the "packet type bits", have values listed in the
462 following table:
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
476 CTB bits 10, the "packet-length length bits", have values listed in
477 the following table:
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
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.
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).
497 Options marked with an asterisk (*) are not implemented yet; PGP
498 2.6.2 will never output this packet type.
506 Atkins, et. al. Informational [Page 9]
507 \f
508 RFC 1991 PGP Message Exchange Formats August 1996
511 4.2 Number ID fields
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.
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.
525 4.3 Version fields
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.
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.
541 5. Packets
543 5.1 Overview
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.
550 A packet is the concatenation of the following:
552 (a) a packet structure field;
553 (b) a byte string of some length N.
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.
562 Atkins, et. al. Informational [Page 10]
563 \f
564 RFC 1991 PGP Message Exchange Formats August 1996
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.
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.
577 5.2 General packet structure
579 A pgp file consists of three components: a message component, a
580 signature (optional), and a session key component (optional).
582 5.2.1 Message component
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.
589 5.2.2 Signature component
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.
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.
600 5.2.3 Session key component
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.
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.
618 Atkins, et. al. Informational [Page 11]
619 \f
620 RFC 1991 PGP Message Exchange Formats August 1996
623 6. PGP Packet Types
625 PGP includes the following types of packets:
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
635 6.1 Literal data packets
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.
641 Definition. A literal data packet is the concatenation of the
642 following fields:
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.
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.
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.
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.
674 Atkins, et. al. Informational [Page 12]
675 \f
676 RFC 1991 PGP Message Exchange Formats August 1996
679 6.2 Signature packet
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.
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.
696 Definition. A signature packet, version 2 or 3, is the concatenation
697 of the following fields:
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.
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.
730 Atkins, et. al. Informational [Page 13]
731 \f
732 RFC 1991 PGP Message Exchange Formats August 1996
735 6.2.1 Message-digest-related fields
737 The message digest algorithm is specified by the message digest (MD)
738 number of field (g). The following MD numbers are currently defined:
740 1 - MD5 (output length 16)
741 255 - experimental
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.
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.
751 The input to the message digest algorithm is the concatenation of
752 some "primary input" and some "appended input."
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).
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:
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")
786 Atkins, et. al. Informational [Page 14]
787 \f
788 RFC 1991 PGP Message Exchange Formats August 1996
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") (*)
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.
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.
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.
821 6.2.2 Public-key-related fields
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.
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:
830 1 - RSA
831 255 - experimental
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.
842 Atkins, et. al. Informational [Page 15]
843 \f
844 RFC 1991 PGP Message Exchange Formats August 1996
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.
853 6.2.3 RSA signatures
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.
859 PGP versions 2.3 and later encode the MD into a PKCS-format signature
860 string, which has the following format:
862 MSB . . . LSB
863 0 1 <FF>(n bytes) 0 ASN(18 bytes) MD(16 bytes)
865 See RFC1423 for an explanation of the meaning of the ASN string. It
866 is the following 18 byte long hex value:
868 <30 20 30 0C 06 08 2A 86 48 86 F7 0D 02 05 05 00 04 10>
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.
873 6.2.4 Miscellaneous fields
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.
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.
898 Atkins, et. al. Informational [Page 16]
899 \f
900 RFC 1991 PGP Message Exchange Formats August 1996
903 6.3 Compressed data packets
905 Purpose. A compressed data packet is an envelope which safely
906 squeezes its contents into a small space.
908 Definition. A compressed data packet is the concatenation of the
909 following fields:
911 (a) a packet structure field;
912 (b) a byte, giving a compression type;
913 (c) a byte string of compressed data.
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.
920 A compression type selects a compression algorithm for use in
921 compressed data packets. The following compression numbers are
922 currently defined.
924 1 - ZIP
925 255 - experimental
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.
932 6.4 Conventional-key-encrypted data packets
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.
939 Definition. A conventional-key-encrypted data packet is the
940 concatenation of the following fields:
942 (a) a packet structure field;
943 (b) a byte string of encrypted data.
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
954 Atkins, et. al. Informational [Page 17]
955 \f
956 RFC 1991 PGP Message Exchange Formats August 1996
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.
964 6.4.1 Conventional-encryption type byte
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.
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.
977 1 - IDEA (16-byte key)
978 255 - experimental
980 6.5 Public-key-encrypted packets
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.
989 Definition. A public-key-encrypted packet, version 2 or 3, is the
990 concatenation of the following fields:
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).
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).
1002 The value of field (c) is the ID of K.
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
1010 Atkins, et. al. Informational [Page 18]
1011 \f
1012 RFC 1991 PGP Message Exchange Formats August 1996
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.
1023 6.5.1 RSA-encrypted data encryption key (DEK)
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.
1030 PGP version 2.3 and later encode the DEK into an MPI using the
1031 following format:
1033 MSB . . . LSB
1034 0 2 RND(n bytes) 0 ALG(1 byte) DEK(k bytes) CSUM(2 bytes)
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.
1046 6.6 Public Key Packet
1048 Purpose. A public key packet defines an RSA public key.
1050 Definition. A public key packet is the concatenation of the
1051 following fields:
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.
1061 The validity period is always set to 0.
1066 Atkins, et. al. Informational [Page 19]
1067 \f
1068 RFC 1991 PGP Message Exchange Formats August 1996
1071 6.7 User ID Packet
1073 Purpose. A user ID packet identifies a user and is associated with a
1074 public or private key.
1076 Definition. A user ID packet is the concatenation of the following
1077 fields:
1079 (a) packet structure field (2 bytes);
1080 (b) User ID string.
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.
1088 7. Transferable Public Keys
1090 Public keys may transferred between PGP users. The essential elements
1091 of a transferable public key are
1093 (a) One public key packet;
1094 (b) One or more user ID packets;
1095 (c) Zero or more signature packets
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.
1110 8. Acknowledgments
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.
1122 Atkins, et. al. Informational [Page 20]
1123 \f
1124 RFC 1991 PGP Message Exchange Formats August 1996
1127 9. Security Considerations
1129 Security issues are discussed throughout this memo.
1131 10. Authors' Addresses
1133 Derek Atkins
1134 12 Rindge Ave. #1R
1135 Cambridge, MA
1137 Phone: +1 617 868-4469
1138 EMail: warlord@MIT.EDU
1141 William Stallings
1142 Comp-Comm Consulting
1143 P. O. Box 2405
1144 Brewster, MA 02631
1146 EMail: stallings@ACM.org
1149 Philip Zimmermann
1150 Boulder Software Engineering
1151 3021 Eleventh Street
1152 Boulder, Colorado 80304 USA
1154 Phone: +1-303-541-0140
1155 EMail: prz@acm.org
1178 Atkins, et. al. Informational [Page 21]
1179 \f