rfc1991.txt

RFC 的详细文档！

   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