Network Working Group D. Atkins
`Request for Comments: 1991 MIT
`Category: Informational W. Stallings
` Comp-Comm Consulting
` P. Zimmermann
` Boulder Software Engineering
` August 1996
`
` PGP Message Exchange Formats
`
`Status of This Memo
`
` This memo provides information for the Internet community. This memo
` does not specify an Internet standard of any kind. Distribution of
` this memo is unlimited.
`
`Table of Contents
`
` 1. Introduction............................................2
` 2. PGP Services............................................2
` 2.1 Digital signature.......................................3
` 2.2 Confidentiality.........................................3
` 2.3 Compression.............................................4
` 2.4 Radix-64 conversion.....................................4
` 2.4.1 ASCII Armor Formats.....................................5
` 3. Data Element Formats....................................6
` 3.1 Byte strings............................................6
` 3.2 Whole number fields.....................................7
` 3.3 Multiprecision fields...................................7
` 3.4 String fields...........................................8
` 3.5 Time fields.............................................8
` 4. Common Fields...........................................8
` 4.1 Packet structure fields.................................8
` 4.2 Number ID fields.......................................10
` 4.3 Version fields.........................................10
` 5. Packets................................................10
` 5.1 Overview...............................................10
` 5.2 General Packet Structure...............................11
` 5.2.1 Message component......................................11
` 5.2.2 Signature component....................................11
` 5.2.3 Session key component..................................11
` 6. PGP Packet Types.......................................12
` 6.1 Literal data packets...................................12
` 6.2 Signature packets......................................13
` 6.2.1 Message-digest-related fields..........................14
` 6.2.2 Public-key-related fields..............................15
` 6.2.3 RSA signatures.........................................16
`
`Atkins, et. al. Informational [Page 1]
`
`IPR2017-00430
`UNIFIED EX1021
`
`

`

`RFC 1991 PGP Message Exchange Formats August 1996
`
` 6.2.4 Miscellaneous fields...................................16
` 6.3 Compressed data packets................................17
` 6.4 Conventional-key-encrypted data packets................17
` 6.4.1 Conventional-encryption type byte......................18
` 6.5 Public-key-encrypted packets...........................18
` 6.5.1 RSA-encrypted data encryption key (DEK)................19
` 6.6 Public-key Packets.....................................19
` 6.7 User ID packets........................................20
` 7. Transferable Public Keys...............................20
` 8. Acknowledgments........................................20
` 9. Security Considerations................................21
` 10. Authors’ Addresses.....................................21
`
`1. Introduction
`
` PGP (Pretty Good Privacy) uses a combination of public-key and
` conventional encryption to provide security services for electronic
` mail messages and data files. These services include confidentiality
` and digital signature. PGP is widely used throughout the global
` computer community. This document describes the format of "PGP
` files", i.e., messages that have been encrypted and/or signed with
` PGP.
`
` PGP was created by Philip Zimmermann and first released, in Version
` 1.0, in 1991. Subsequent versions have been designed and implemented
` by an all-volunteer collaborative effort under the design guidance of
` Philip Zimmermann. PGP and Pretty Good Privacy are trademarks of
` Philip Zimmermann.
`
` This document describes versions 2.x of PGP. Specifically, versions
` 2.6 and 2.7 conform to this specification. Version 2.3 conforms to
` this specification with minor differences.
`
` A new release of PGP, known as PGP 3.0, is anticipated in 1995. To
` the maximum extent possible, this version will be upwardly compatible
` with version 2.x. At a minimum, PGP 3.0 will be able to read messages
` and signatures produced by version 2.x.
`
`2. PGP Services
`
` PGP provides four services related to the format of messages and data
` files: digital signature, confidentiality, compression, and radix-64
` conversion.
`
`Atkins, et. al. Informational [Page 2]
`
`

`

`RFC 1991 PGP Message Exchange Formats August 1996
`
`2.1 Digital signature
`
` The digital signature service involves the use of a hash code, or
` message digest, algorithm, and a public-key encryption algorithm. The
` sequence is as follows:
`
` -the sender creates a message
` -the sending PGP generates a hash code of the message
` -the sending PGP encrypts the hash code using the sender’s private
` key
` -the encrypted hash code is prepended to the message
` -the receiving PGP decrypts the hash code using the sender’s public
` key
` -the receiving PGP generates a new hash code for the received
` message and compares it to the decrypted hash code. If the two
` match, the message is accepted as authentic
`
` Although signatures normally are found attached to the message or
` file that they sign, this is not always the case: detached signatures
` are supported. A detached signature may be stored and transmitted
` separately from the message it signs. This is useful in several
` contexts. A user may wish to maintain a separate signature log of all
` messages sent or received. A detached signature of an executable
` program can detect subsequent virus infection. Finally, detached
` signatures can be used when more than one party must sign a document,
` such as a legal contract. Each person’s signature is independent and
` therefore is applied only to the document. Otherwise, signatures
` would have to be nested, with the second signer signing both the
` document and the first signature, and so on.
`
`2.2 Confidentiality
`
` PGP provides confidentiality by encrypting messages to be transmitted
` or data files to be stored locally using conventional encryption. In
` PGP, each conventional key is used only once. That is, a new key is
` generated as a random 128-bit number for each message. Since it is to
` be used only once, the session key is bound to the message and
` transmitted with it. To protect the key, it is encrypted with the
` receiver’s public key. The sequence is as follows:
`
` -the sender creates a message
` -the sending PGP generates a random number to be used as a session
` key for this message only
` -the sending PGP encrypts the message using the session key
` -the session key is encrypted using the recipient’s public key and
` prepended to the encrypted message
` -the receiving PGP decrypts the session key using the recipient’s
` private key
`
`Atkins, et. al. Informational [Page 3]
`
`

`

`RFC 1991 PGP Message Exchange Formats August 1996
`
` -the receiving PGP decrypts the message using the session key
`
` Both digital signature and confidentiality services may be applied to
` the same message. First, a signature is generated for the message and
` prepended to the message. Then, the message plus signature is
` encrypted using a conventional session key. Finally, the session key
` is encrypted using public-key encryption and prepended to the
` encrypted block.
`
`2.3 Compression
`
` As a default, PGP compresses the message after applying the signature
` but before encryption.
`
`2.4 Radix-64 conversion
`
` When PGP is used, usually part of the block to be transmitted is
` encrypted. If only the signature service is used, then the message
` digest is encrypted (with the sender’s private key). If the
` confidentiality service is used, the message plus signature (if
` present) are encrypted (with a one-time conventional key). Thus, part
` or all of the resulting block consists of a stream of arbitrary 8-bit
` bytes. However, many electronic mail systems only permit the use of
` blocks consisting of ASCII text. To accommodate this restriction, PGP
` provides the service of converting the raw 8-bit binary stream to a
` stream of printable ASCII characters, called ASCII Armor.
`
` The scheme used for this purpose is radix-64 conversion. Each group
` of three bytes of binary data is mapped into 4 ASCII characters. This
` format also appends a CRC to detect transmission errors. This
` radix-64 conversion, also called Ascii Armor, is a wrapper around the
` binary PGP messages, and is used to protect the binary messages
` during transmission over non-binary channels, such as Internet Email.
`
` The following table defines the mapping. The characters used are the
` upper- and lower-case letters, the digits 0 through 9, and the
` characters + and /. The carriage-return and linefeed characters
` aren’t used in the conversion, nor is the tab or any other character
` that might be altered by the mail system. The result is a text file
` that is "immune" to the modifications inflicted by mail systems.
`
`Atkins, et. al. Informational [Page 4]
`
`

`

`RFC 1991 PGP Message Exchange Formats August 1996
`
` 6-bit character 6-bit character 6-bit character 6-bit character
` value encoding value encoding value encoding value encoding
` 0 A 16 Q 32 g 48 w
` 1 B 17 R 33 h 49 x
` 2 C 18 S 34 i 50 y
` 3 D 19 T 35 j 51 z
` 4 E 20 U 36 k 52 0
` 5 F 21 V 37 l 53 1
` 6 G 22 W 38 m 54 2
` 7 H 23 X 39 n 55 3
` 8 I 24 Y 40 o 56 4
` 9 J 25 Z 41 p 57 5
` 1 K 26 a 42 q 58 6
` 11 L 27 b 43 r 59 7
` 12 M 28 c 44 s 60 8
` 13 N 29 d 45 t 61 9
` 14 O 30 e 46 u 62 +
` 15 P 31 f 47 v 63 /
` (pad) =
`
` It is possible to use PGP to convert any arbitrary file to ASCII
` Armor. When this is done, PGP tries to compress the data before it
` is converted to Radix-64.
`
`2.4.1 ASCII Armor Formats
`
` When PGP encodes data into ASCII Armor, it puts specific headers
` around the data, so PGP can reconstruct the data at a future time.
` PGP tries to inform the user what kind of data is encoded in the
` ASCII armor through the use of the headers.
`
` ASCII Armor is created by concatenating the following data:
`
` - An Armor Headerline, appropriate for the type of data
` - Armor Headers
` - A blank line
` - The ASCII-Armored data
` - An Armor Checksum
` - The Armor Tail (which depends on the Armor Headerline).
`
` An Armor Headerline is composed by taking the appropriate headerline
` text surrounded by five (5) dashes (-) on either side of the
` headerline text. The headerline text is chosen based upon the type
` of data that is being encoded in Armor, and how it is being encoded.
` Headerline texts include the following strings:
`
` BEGIN PGP MESSAGE -- used for signed, encrypted, or compressed files
` BEGIN PGP PUBLIC KEY BLOCK -- used for transferring public keys
`
`Atkins, et. al. Informational [Page 5]
`
`

`

`RFC 1991 PGP Message Exchange Formats August 1996
`
` BEGIN PGP MESSAGE, PART X/Y -- used for multi-part messages, where
` the armor is split amongst Y files,
` and this is the Xth file out of Y.
`
` The Armor Headers are pairs of strings that can give the user or the
` receiving PGP program some information about how to decode or use the
` message. The Armor Headers are a part of the armor, not a part of
` the message, and hence should not be used to convey any important
` information, since they can be changed in transport.
`
` The format of an Armor Header is that of a key-value pair, the
` encoding of RFC-822 headers. PGP should consider improperly
` formatted Armor Headers to be corruption of the ASCII Armor. Unknown
` Keys should be reported to the user, but so long as the RFC-822
` formatting is correct, PGP should continue to process the message.
` Currently defined Armor Header Keys include "Version" and "Comment",
` which define the PGP Version used to encode the message and a user-
` defined comment.
`
` The Armor Checksum is a 24-bit CRC converted to four bytes of radix-
` 64 encoding, prepending an equal-sign (=) to the four-byte code. The
` CRC is computed by using the generator 0x864CFB and an initialization
` of 0xB704CE. The accumulation is done on the data before it is
` converted to radix-64, rather than on the converted data. For more
` information on CRC functions, the reader is asked to look at chapter
` 19 of the book "C Programmer’s Guide to Serial Communications," by
` Joe Campbell.
`
` The Armor Tail is composed in the same manner as the Armor
` Headerline, except the string "BEGIN" is replaced by the string
` "END".
`
`3. Data Element Formats
`
`3.1 Byte strings
`
` The objects considered in this document are all "byte strings." A
` byte string is a finite sequence of bytes. The concatenation of byte
` string X of length M with byte string Y of length N is a byte string
` Z of length M + N; the first M bytes of Z are the bytes of X in the
` same order, and the remaining N bytes of Z are the bytes of Y in the
` same order.
`
` Literal byte strings are written from left to right, with pairs of
` hex nibbles separated by spaces, enclosed by angle brackets: for
` instance, <05 ff 07> is a byte string of length 3 whose bytes have
` numeric values 5, 255, and 7 in that order. All numbers in this
` document outside angle brackets are written in decimal.
`
`Atkins, et. al. Informational [Page 6]
`
`

`

`RFC 1991 PGP Message Exchange Formats August 1996
`
` The byte string of length 0 is called "empty" and written <>.
`
`3.2 Whole number fields
`
` Purpose. A whole number field can represent any nonnegative integer,
` in a format where the field length is known in advance.
`
` Definition. A whole number field is any byte string. It is stored
` in radix-256 MSB-first format. This means that a whole number field
` of length N with bytes b_0 b_1 ... b_{N-2} b_{N-1} in that order has
` value
`
` b_0 * 256^{N-1} + b_1 * 256^{N-2} + ... + b_{N-2} * 256 + b_{N-1}.
`
` Examples. The byte string <00 0D 64 11 00 00> is a valid whole
` number field with value 57513410560. The byte string <FF> is a valid
` whole number field with value 255. The byte string <00 00> is a
` valid whole number field with value 0. The empty byte string <> is a
` valid whole number field with value 0.
`
`3.3 Multiprecision fields
`
` Purpose. A multiprecision field can represent any nonnegative
` integer which is not too large. The field length need not be known
` in advance. Multiprecision fields are designed to waste very little
` space: a small integer uses a short field.
`
` Definition. A multiprecision field is the concatenation of two
` fields:
`
` (a) a whole number field of length 2, with value B;
` (b) a whole number field, with value V.
`
` Field (b) is of length [(B+7)/8], i.e., the greatest integer which is
` no larger than (B+7)/8. The value of the multiprecision field is
` defined to be V. V must be between 2^{B-1} and 2^B - 1 inclusive.
` In other words B must be exactly the number of significant bits in V.
`
` Some implementations may limit the possible range of B. The
` implementor must document which values of B are allowed by an
` implementation.
`
` Examples. The byte string <00 00> is a valid multiprecision integer
` with value 0. The byte string <00 03 05> is a valid multiprecision
` field with value 5. The byte strings <00 03 85> and <00 00 00> are
` not valid multiprecision fields. The former is invalild because <85>
` has 8 significant bits, not 3; the latter is invalid because the
` second field has too many bytes of data given the value of the first
`
`Atkins, et. al. Informational [Page 7]
`
`

`

`RFC 1991 PGP Message Exchange Formats August 1996
`
` field. The byte string <00 09 01 ff> is a valid multiprecision field
` with value 511. The byte string <01 00 80 00 00 00 00 00 00 00 00 00
` 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07> is
` a valid multiprecision field with value 2^255 + 7.
`
`3.4 String fields
`
` Purpose. A string field represents any sequence of bytes of length
` between 0 and 255 inclusive. The length need not be known in
` advance. By convention, the content of a string field is normally
` interpreted as ASCII codes when it is displayed.
`
` Definition. A string field is the concatenation of the following:
`
` (a) a whole number field of length 1, with value L;
` (b) a byte string of length L.
`
` The content of the string field is defined to be field (b).
`
` Examples: <05 48 45 4c 4c 4f> is a valid string field which would
` normally be displayed as the string HELLO. <00> is a valid string
` field which would normally be displayed as the empty string. <01 00>
` is a valid string field.
`
`3.5 Time fields
`
` Purpose. A time field represents the number of seconds elapsed since
` 1970 Jan 1 00:00:00 GMT. It is compatible with the usual
` representation of times under UNIX.
`
` Definition. A time field is a whole number field of length 4, with
` value V. The time represented by the time field is the one-second
` interval beginning V seconds after 1970 Jan 1 00:00:00 GMT.
`
`4. Common Fields
`
` This section defines fields found in more than one packet format.
`
`4.1 Packet structure fields
`
` Purpose. The packet structure field distinguishes between different
` types of packets, and indicates the length of packets.
`
` Definition. A packet structure field is a byte string of length 1,
` 2, 3, or 5. Its first byte is the cipher type byte (CTB), with bits
` labeled 76543210, 7 the most significant bit and 0 the least
` significant bit. As indicated below the length of the packet
` structure field is determined by the CTB.
`
`Atkins, et. al. Informational [Page 8]
`
`

`

`RFC 1991 PGP Message Exchange Formats August 1996
`
` CTB bits 76 have values listed in the following table:
`
` 10 - normal CTB
` 11 - reserved for future experimental work
` all others - reserved
`
` CTB bits 5432, the "packet type bits", have values listed in the
` following table:
`
` 0001 - public-key-encrypted packet
` 0010 - signature packet
` 0101 - secret-key certificate packet
` 0110 - public-key certificate packet
` 1000 - compressed data packet
` 1001 - conventional-key-encrypted packet
` 1011 - literal data packet
` 1100 - keyring trust packet
` 1101 - user id packet
` 1110 - comment packet (*)
` all others - reserved
`
` CTB bits 10, the "packet-length length bits", have values listed in
` the following table:
`
` 00 - 1-byte packet-length field
` 01 - 2-byte packet-length field
` 10 - 4-byte packet-length field
` 11 - no packet length supplied, unknown packet length
`
` As indicated in this table, depending on the packet-length length
` bits, the remaining 1, 2, 4, or 0 bytes of the packet structure field
` are a "packet-length field". The packet-length field is a whole
` number field. The value of the packet-length field is defined to be
` the value of the whole number field.
`
` A value of 11 is currently used in one place: on compressed data.
` That is, a compressed data block currently looks like <A3 01 . . .>,
` where <A3>, binary 10 1000 11, is an indefinite-length packet. The
` proper interpretation is "until the end of the enclosing structure",
` although it should never appear outermost (where the enclosing
` structure is a file).
`
` Options marked with an asterisk (*) are not implemented yet; PGP
` 2.6.2 will never output this packet type.
`
`Atkins, et. al. Informational [Page 9]
`
`

`

`RFC 1991 PGP Message Exchange Formats August 1996
`
`4.2 Number ID fields
`
` Purpose. The ID of a whole number is its 64 least significant bits.
` The ID is a convenient way to distinguish between large numbers such
` as keys, without having to transmit the number itself. Thus, a number
` that may be hundreds or thousands of decimal digits in length can be
` identified with a 64-bit identifier. Two keys may have the same ID by
` chance or by malice; although the probability that two large keys
` chosen at random would have the same ID is extremely small.
`
` Definition. A number ID field is a whole number field of length 8.
` The value of the number ID field is defined to be the value of the
` whole number field.
`
`4.3 Version fields
`
` Many packet types include a version number as the first byte of the
` body. The format and meaning of the body depend on the version
` number. More versions of packets, with new version numbers, may be
` defined in the future. An implementation need not support every
` version of each packet type. However, the implementor must document
` which versions of each packet type are supported by the
` implementation.
`
` A version number of 2 or 3 is currently allowed for each packet
` format. New versions will probably be numbered sequentially up from
` 3. For backwards compatibility, implementations will usually be
` expected to support version N of a packet whenever they support
` version N+1. Version 255 may be used for experimental purposes.
`
`5. Packets
`
`5.1 Overview
`
` A packet is a digital envelope with data inside. A PGP file, by
` definition, is the concatenation of one or more packets. In addition,
` one or more of the packets in a file may be subject to a
` transformation using encryption, compression, or radix-64 conversion.
`
` A packet is the concatenation of the following:
`
` (a) a packet structure field;
` (b) a byte string of some length N.
`
` Byte string (b) is called the "body" of the packet. The value of the
` packet-length field inside the packet structure field (a) must equal
` N, the length of the body.
`
`Atkins, et. al. Informational [Page 10]
`
`

`

`RFC 1991 PGP Message Exchange Formats August 1996
`
` Other characteristics of the packet are determined by the type of the
` packet. See the definitions of particular packet types for further
` details. The CTB packet-type bits inside the packet structure always
` indicate the packet type.
`
` Note that packets may be nested: one digital envelope may be placed
` inside another. For example, a conventional-key-encrypted packet
` contains a disguised packet, which in turn might be a compressed data
` packet.
`
`5.2 General packet structure
`
` A pgp file consists of three components: a message component, a
` signature (optional), and a session key component (optional).
`
`5.2.1 Message component
`
` The message component includes the actual data to be stored or
` transmitted as well as a header that includes control information
` generated by PGP. The message component consists of a single literal
` data packet.
`
`5.2.2 Signature component
`
` The signature component is the signature of the message component,
` formed using a hash code of the message component and the public key
` of the sending PGP entity. The signature component consists of a
` single signature packet.
`
` If the default option of compression is chosen, then the block
` consisting of the literal data packet and the signature packet is
` compressed to form a compressed data packet.
`
`5.2.3 Session key component
`
` The session key component includes the encrypted session key and the
` identifier of the recipients public key used by the sender to encrypt
` the session key. The session key component consists of a single
` public-key-encrypted packet for each recipient of the message.
`
` If compression has been used, then conventional encryption is applied
` to the compressed data packet formed from the compression of the
` signature packet and the literal data packet. Otherwise, conventional
` encryption is applied to the block consisting of the signature packet
` and the literal data packet. In either case, the cyphertext is
` referred to as a conventional-key-encrypted data packet.
`
`Atkins, et. al. Informational [Page 11]
`
`

`

`RFC 1991 PGP Message Exchange Formats August 1996
`
`6. PGP Packet Types
`
` PGP includes the following types of packets:
`
` -literal data packet
` -signature packet
` -compressed data packet
` -conventional-key-encrypted data packet
` -public-key-encrypted packet
` -public-key packet
` -User ID packet
`
`6.1 Literal data packets
`
` Purpose. A literal data packet is the lowest level of contents of a
` digital envelope. The data inside a literal data packet is not
` subject to any further interpretation by PGP.
`
` Definition. A literal data packet is the concatenation of the
` following fields:
`
` (a) a packet structure field;
` (b) a byte, giving a mode;
` (c) a string field, giving a filename;
` (d) a time field;
` (e) a byte string of literal data.
`
` Fields (b), (c), and (d) suggest how the data should be written to a
` file. Byte (b) is either ASCII b <62>, for binary, or ASCII t <74>,
` for text. Byte (b) may also take on the value ASCII 1, indicating a
` machine-local conversion. It is not defined how PGP will convert this
` across platforms.
`
` Field (c) suggests a filename. Field (d) should be the time at which
` the file was last modified, or the time at which the data packet was
` created, or 0.
`
` Note that only field (e) of a literal data packet is fed to a
` message-digest function for the formation of a signature. The
` exclusion of the other fields ensures that detached signatures are
` exactly the same as attached signatures prefixed to the message.
` Detached signatures are calculated on a separate file that has none
` of the literal data packet header fields.
`
`Atkins, et. al. Informational [Page 12]
`
`

`

`RFC 1991 PGP Message Exchange Formats August 1996
`
`6.2 Signature packet
`
` Purpose. Signatures are attached to data, in such a way that only
` one entity, called the "writer," can create the signature. The
` writer must first create a "public key" K and distribute it. The
` writer keeps certain private data related to K. Only someone
` cooperating with the writer can sign data using K, enveloping the
` data in a signature packet (also known as a private-key-encrypted
` packet). Anyone can look through the glass in the envelope and
` verify that the signature was attached to the data using K. If the
` data is altered in any way then the verification will fail.
`
` Signatures have different meanings. For example, a signature might
` mean "I wrote this document," or "I received this document." A
` signature packet includes a "classification" which expresses its
` meaning.
`
` Definition. A signature packet, version 2 or 3, is the concatenation
` of the following fields:
`
` (a) packet structure field (2, 3, or 5 bytes);
` (b) version number = 2 or 3 (1 byte);
` (c) length of following material included in MD calculation
` (1 byte, always the value 5);
` (d1) signature classification (1 byte);
` (d2) signature time stamp (4 bytes);
` (e) key ID for key used for singing (8 bytes);
` (f) public-key-cryptosystem (PKC) type (1 byte);
` (g) message digest algorithm type (1 byte);
` (h) first two bytes of the MD output, used as a checksum
` (2 bytes);
` (i) a byte string of encrypted data holding the RSA-signed digest.
`
` The message digest is taken of the bytes of the file, followed by the
` bytes of field (d). It was originally intended that the length (c)
` could vary, but now it seems that it will alwaye remain a constant
` value of 5, and that is the only value that will be accepted. Thus,
` only the fields (d1) and (d2) will be hashed into the signature along
` with the main message.
`
`Atkins, et. al. Informational [Page 13]
`
`

`

`RFC 1991 PGP Message Exchange Formats August 1996
`
`6.2.1 Message-digest-related fields
`
` The message digest algorithm is specified by the message digest (MD)
` number of field (g). The following MD numbers are currently defined:
`
` 1 - MD5 (output length 16)
` 255 - experimental
`
` More MD numbers may be defined in the future. An implementation need
` not support every MD number. The implementor must document the MD
` numbers understood by an implementation.
`
` A message digest algorithm reads a byte string of any length, and
` writes a byte string of some fixed length, as indicated in the table
` above.
`
` The input to the message digest algorithm is the concatenation of
` some "primary input" and some "appended input."
`
` The appended input is specified by field (c), which gives a number of
` bytes to be taken from the following fields: (d1), (d2), and so on.
` The current implementation uses the value 5 for this number, for
` fields (d1) and (d2). Any field not included in the appended input
` is not "signed" by field (i).
`
` The primary input is determined by the signature classification byte
` (d1). Byte (d1) is one of the following hex numbers, with these
` meanings:
`
` <00> - document signature, binary image ("I wrote this document")
` <01> - document signature, canonical text ("I wrote this document")
` <10> - public key packet and user ID packet, generic certification
` ("I think this key was created by this user, but I won’t say
` how sure I am")
` <11> - public key packet and user ID packet, persona certification
` ("This key was created by someone who has told me that he is
` this user") (#)
` <12> - public key packet and user ID packet, casual certification
` ("This key was created by someone who I believe, after casual
` verification, to be this user") (#)
` <13> - public key packet and user ID packet, positive certification
` ("This key was created by someone who I believe, after
` heavy-duty identification such as picture ID, to be this
` user") (#)
` <20> - public key packet, key compromise ("This is my key, and I
` have revoked it")
`
`Atkins, et. al. Informational [Page 14]
`
`

`

`RFC 1991 PGP Message Exchange Formats August 1996
`
` <30> - public key packet and user ID packet, revocation ("I retract
` all my previous statements that this key is related to this
` user") (*)
` <40> - time stamping ("I saw this document") (*)
`
` More classification numbers may be defined in the future to handle
` other meanings of signatures, but on