rfc2440.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Callas, et. al.             Standards Track                    [Page 12]

RFC 2440                 OpenPGP Message Format            November 1998


   New format packets contain:

         Bits 5-0 -- content tag

4.2.1. Old-Format Packet Lengths

   The meaning of the length-type in old-format packets is:

   0 - The packet has a one-octet length. The header is 2 octets long.

   1 - The packet has a two-octet length. The header is 3 octets long.

   2 - The packet has a four-octet length. The header is 5 octets long.

   3 - The packet is of indeterminate length.  The header is 1 octet
       long, and the implementation must determine how long the packet
       is. If the packet is in a file, this means that the packet
       extends until the end of the file. In general, an implementation
       SHOULD NOT use indeterminate length packets except where the end
       of the data will be clear from the context, and even then it is
       better to use a definite length, or a new-format header. The
       new-format headers described below have a mechanism for precisely
       encoding data of indeterminate length.

4.2.2. New-Format Packet Lengths

   New format packets have four possible ways of encoding length:

    1. A one-octet Body Length header encodes packet lengths of up to
       191 octets.

   2. A two-octet Body Length header encodes packet lengths of 192 to
       8383 octets.

    3. A five-octet Body Length header encodes packet lengths of up to
       4,294,967,295 (0xFFFFFFFF) octets in length. (This actually
       encodes a four-octet scalar number.)

    4. When the length of the packet body is not known in advance by the
       issuer, Partial Body Length headers encode a packet of
       indeterminate length, effectively making it a stream.










Callas, et. al.             Standards Track                    [Page 13]

RFC 2440                 OpenPGP Message Format            November 1998


4.2.2.1. One-Octet Lengths

   A one-octet Body Length header encodes a length of from 0 to 191
   octets. This type of length header is recognized because the one
   octet value is less than 192.  The body length is equal to:

       bodyLen = 1st_octet;

4.2.2.2. Two-Octet Lengths

   A two-octet Body Length header encodes a length of from 192 to 8383
   octets.  It is recognized because its first octet is in the range 192
   to 223.  The body length is equal to:

       bodyLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192

4.2.2.3. Five-Octet Lengths

   A five-octet Body Length header consists of a single octet holding
   the value 255, followed by a four-octet scalar. The body length is
   equal to:

       bodyLen = (2nd_octet << 24) | (3rd_octet << 16) |
                 (4th_octet << 8)  | 5th_octet

4.2.2.4. Partial Body Lengths

   A Partial Body Length header is one octet long and encodes the length
   of only part of the data packet. This length is a power of 2, from 1
   to 1,073,741,824 (2 to the 30th power).  It is recognized by its one
   octet value that is greater than or equal to 224, and less than 255.
   The partial body length is equal to:

       partialBodyLen = 1 << (1st_octet & 0x1f);

   Each Partial Body Length header is followed by a portion of the
   packet body data. The Partial Body Length header specifies this
   portion's length. Another length header (of one of the three types --
   one octet, two-octet, or partial) follows that portion. The last
   length header in the packet MUST NOT be a partial Body Length header.
   Partial Body Length headers may only be used for the non-final parts
   of the packet.

4.2.3. Packet Length Examples

   These examples show ways that new-format packets might encode the
   packet lengths.




Callas, et. al.             Standards Track                    [Page 14]

RFC 2440                 OpenPGP Message Format            November 1998


   A packet with length 100 may have its length encoded in one octet:
   0x64. This is followed by 100 octets of data.

   A packet with length 1723 may have its length coded in two octets:
   0xC5, 0xFB.  This header is followed by the 1723 octets of data.

   A packet with length 100000 may have its length encoded in five
   octets: 0xFF, 0x00, 0x01, 0x86, 0xA0.

   It might also be encoded in the following octet stream: 0xEF, first
   32768 octets of data; 0xE1, next two octets of data; 0xE0, next one
   octet of data; 0xF0, next 65536 octets of data; 0xC5, 0xDD, last 1693
   octets of data.  This is just one possible encoding, and many
   variations are possible on the size of the Partial Body Length
   headers, as long as a regular Body Length header encodes the last
   portion of the data. Note also that the last Body Length header can
   be a zero-length header.

   An implementation MAY use Partial Body Lengths for data packets, be
   they literal, compressed, or encrypted. The first partial length MUST
   be at least 512 octets long. Partial Body Lengths MUST NOT be used
   for any other packet types.

   Please note that in all of these explanations, the total length of
   the packet is the length of the header(s) plus the length of the
   body.

4.3. Packet Tags

   The packet tag denotes what type of packet the body holds. Note that
   old format headers can only have tags less than 16, whereas new
   format headers can have tags as great as 63. The defined tags (in
   decimal) are:

       0        -- Reserved - a packet tag must not have this value
       1        -- Public-Key Encrypted Session Key Packet
       2        -- Signature Packet
       3        -- Symmetric-Key Encrypted Session Key Packet
       4        -- One-Pass Signature Packet
       5        -- Secret Key Packet
       6        -- Public Key Packet
       7        -- Secret Subkey Packet
       8        -- Compressed Data Packet
       9        -- Symmetrically Encrypted Data Packet
       10       -- Marker Packet
       11       -- Literal Data Packet
       12       -- Trust Packet




Callas, et. al.             Standards Track                    [Page 15]

RFC 2440                 OpenPGP Message Format            November 1998


       13       -- User ID Packet
       14       -- Public Subkey Packet
       60 to 63 -- Private or Experimental Values

5. Packet Types

5.1. Public-Key Encrypted Session Key Packets (Tag 1)

   A Public-Key Encrypted Session Key packet holds the session key used
   to encrypt a message. Zero or more Encrypted Session Key packets
   (either Public-Key or Symmetric-Key) may precede a Symmetrically
   Encrypted Data Packet, which holds an encrypted message.  The message
   is encrypted with the session key, and the session key is itself
   encrypted and stored in the Encrypted Session Key packet(s).  The
   Symmetrically Encrypted Data Packet is preceded by one Public-Key
   Encrypted Session Key packet for each OpenPGP key to which the
   message is encrypted.  The recipient of the message finds a session
   key that is encrypted to their public key, decrypts the session key,
   and then uses the session key to decrypt the message.

   The body of this packet consists of:

     - A one-octet number giving the version number of the packet type.
       The currently defined value for packet version is 3. An
       implementation should accept, but not generate a version of 2,
       which is equivalent to V3 in all other respects.

     - An eight-octet number that gives the key ID of the public key
       that the session key is encrypted to.

     - A one-octet number giving the public key algorithm used.

     - A string of octets that is the encrypted session key. This string
       takes up the remainder of the packet, and its contents are
       dependent on the public key algorithm used.

   Algorithm Specific Fields for RSA encryption

     - multiprecision integer (MPI) of RSA encrypted value m**e mod n.

   Algorithm Specific Fields for Elgamal encryption:

     - MPI of Elgamal (Diffie-Hellman) value g**k mod p.

     - MPI of Elgamal (Diffie-Hellman) value m * y**k mod p.






Callas, et. al.             Standards Track                    [Page 16]

RFC 2440                 OpenPGP Message Format            November 1998


   The value "m" in the above formulas is derived from the session key
   as follows.  First the session key is prefixed with a one-octet
   algorithm identifier that specifies the symmetric encryption
   algorithm used to encrypt the following Symmetrically Encrypted Data
   Packet.  Then a two-octet checksum is appended which is equal to the
   sum of the preceding session key octets, not including the algorithm
   identifier, modulo 65536.  This value is then padded as described in
   PKCS-1 block type 02 [RFC2313] to form the "m" value used in the
   formulas above.

   Note that when an implementation forms several PKESKs with one
   session key, forming a message that can be decrypted by several keys,
   the implementation MUST make new PKCS-1 padding for each key.

   An implementation MAY accept or use a Key ID of zero as a "wild card"
   or "speculative" Key ID. In this case, the receiving implementation
   would try all available private keys, checking for a valid decrypted
   session key. This format helps reduce traffic analysis of messages.

5.2. Signature Packet (Tag 2)

   A signature packet describes a binding between some public key and
   some data. The most common signatures are a signature of a file or a
   block of text, and a signature that is a certification of a user ID.

   Two versions of signature packets are defined.  Version 3 provides
   basic signature information, while version 4 provides an expandable
   format with subpackets that can specify more information about the
   signature. PGP 2.6.x only accepts version 3 signatures.

   Implementations MUST accept V3 signatures. Implementations SHOULD
   generate V4 signatures.  Implementations MAY generate a V3 signature
   that can be verified by PGP 2.6.x.

   Note that if an implementation is creating an encrypted and signed
   message that is encrypted to a V3 key, it is reasonable to create a
   V3 signature.

5.2.1. Signature Types

   There are a number of possible meanings for a signature, which are
   specified in a signature type octet in any given signature. These
   meanings are:

   0x00: Signature of a binary document.
         Typically, this means the signer owns it, created it, or
         certifies that it has not been modified.




Callas, et. al.             Standards Track                    [Page 17]

RFC 2440                 OpenPGP Message Format            November 1998


   0x01: Signature of a canonical text document.
         Typically, this means the signer owns it, created it, or
         certifies that it has not been modified.  The signature is
         calculated over the text data with its line endings converted
         to <CR><LF> and trailing blanks removed.

   0x02: Standalone signature.
         This signature is a signature of only its own subpacket
         contents. It is calculated identically to a signature over a
         zero-length binary document. Note that it doesn't make sense to
         have a V3 standalone signature.

   0x10: Generic certification of a User ID and Public Key packet.
         The issuer of this certification does not make any particular
         assertion as to how well the certifier has checked that the
         owner of the key is in fact the person described by the user
         ID.  Note that all PGP "key signatures" are this type of
         certification.

   0x11: Persona certification of a User ID and Public Key packet.
         The issuer of this certification has not done any verification
         of the claim that the owner of this key is the user ID
         specified.

   0x12: Casual certification of a User ID and Public Key packet.
         The issuer of this certification has done some casual
         verification of the claim of identity.

   0x13: Positive certification of a User ID and Public Key packet.
         The issuer of this certification has done substantial
         verification of the claim of identity.

         Please note that the vagueness of these certification claims is
         not a flaw, but a feature of the system. Because PGP places
         final authority for validity upon the receiver of a
         certification, it may be that one authority's casual
         certification might be more rigorous than some other
         authority's positive certification. These classifications allow
         a certification authority to issue fine-grained claims.

   0x18: Subkey Binding Signature
         This signature is a statement by the top-level signing key
         indicates that it owns the subkey. This signature is calculated
         directly on the subkey itself, not on any User ID or other