rfc1991.txt

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

   be used as the trusted "legal" time of the original signature.











Atkins, et. al.              Informational                     [Page 16]

RFC 1991              PGP Message Exchange Formats           August 1996


6.3 Compressed data packets

   Purpose.  A compressed data packet is an envelope which safely
   squeezes its contents into a small space.

   Definition.  A compressed data packet is the concatenation of the
   following fields:

      (a) a packet structure field;
      (b) a byte, giving a compression type;
      (c) a byte string of compressed data.

   Byte string (c) is a packet which may be decompressed using the
   algorithm identified in byte (b).  Typically, the data that are
   compressed consist of a literal data packet or a signature packet
   concatenated to a literal data packet.

   A compression type selects a compression algorithm for use in
   compressed data packets.  The following compression numbers are
   currently defined.

      1 - ZIP
      255 - experimental

   More compression numbers may be defined in the future.  An
   implementation need not support every MD number.  The implementor
   must document the compression numbers understood by an
   implementation.

6.4 Conventional-key-encrypted data packets

   Purpose.  A conventional-key-encrypted data packet is formed by
   encrypting a block of data with a conventional encryption algorithm
   using a one-time session key. Typically, the block to be encrypted is
   a compressed data packet.

   Definition.  A conventional-key-encrypted data packet is the
   concatenation of the following fields:

      (a) a packet structure field;
      (b) a byte string of encrypted data.

   The plaintext or compressed plaintext that is encrypted to form field
   (b) is first prepended with 64 bits of random data plus 16 "key
   check" bits.  The random prefix serves to start off the cipher
   feedback chaining process with 64 bits of random material; this
   serves the same function as an initialization vector (IV) for a
   cipher-block-chaining encryption scheme.  The key check prefix is



Atkins, et. al.              Informational                     [Page 17]

RFC 1991              PGP Message Exchange Formats           August 1996


   equal to the last 16 bits of the random prefix. During decryption, a
   comparison is made to see if the 7th and 8th byte of the decrypted
   material match the 9th and 10th bytes.  If so, then the conventional
   session key used for decryption is assumed to be correct.

6.4.1 Conventional-encryption type byte

   Purpose.  The conventional-encryption type byte is used to determine
   what conventional encryption algorithm is in use.  The algorithm type
   byte will also define how long the conventional encryption key is,
   based upon the algorithm in use.

   Definition.  A conventional-encryption type byte is a single byte
   which defines the algorithm in use.  It is possible that the
   algorithm in use may require further definition, such as key-length.
   It is up to the implementor to document the supported key-length in
   such a situation.

      1 - IDEA (16-byte key)
      255 - experimental

6.5 Public-key-encrypted packets

   Purpose.  The public-key-encrypted packet is the format for the
   session key component of a message. The purpose of this packet is to
   convey the one-time session key used to encrypt the message to the
   recipient in a secure manner. This is done by encrypting the session
   key with the recipient's public key, so that only the recipient can
   recover the session key.

   Definition.  A public-key-encrypted packet, version 2 or 3, is the
   concatenation of the following fields:

      (a) a packet structure field;
      (b) a byte, giving the version number, 2 or 3;
      (c) a number ID field, giving the ID of a key;
      (d) a byte, giving a PKC number;
      (e) a byte string of encrypted data (DEK).

   Byte string (e) represents the value of the session key, encrypted
   using the reader's public key K, under the cryptosystem identified in
   byte (d).

   The value of field (c) is the ID of K.

   Note that the packet does not actually identify K: two keys may have
   the same ID, by chance or by malice.  Normally it will be obvious
   from the context which key K was used to create the packet.  But



Atkins, et. al.              Informational                     [Page 18]

RFC 1991              PGP Message Exchange Formats           August 1996


   sometimes it is not obvious.  In this case field (c) is useful.  If,
   for example, a reader has created several keys, and receives a
   message, then he should attempt to decrypt the message only with the
   key whose ID matches the value of field (c).  If he has accidentally
   generated two keys with the same ID, then he must attempt to decrypt
   the message with both keys, but this case is highly unlikely to occur
   by chance.

6.5.1 RSA-encrypted data encryption key (DEK)

   The Data Encryption Key (DEK) is a multiprecision field which stores
   an RSA encrypted byte string.  The byte string is a PKCS encoding of
   the secret key used the encrypt the message, with random padding for
   each Public-Key encrypted packet.

   PGP version 2.3 and later encode the DEK into an MPI using the
   following format:

     MSB                       .   .   .                       LSB
      0   2   RND(n bytes)   0  ALG(1 byte)  DEK(k bytes)  CSUM(2 bytes)

   ALG refers to the algorithm byte for the secret key algorithm used to
   encrypt the data packet.  The DEK is the actual Data Encryption Key,
   and its size is dependent upon the encryption algorithm defined by
   ALG.  For the IDEA encryption algorithm, type byte 1, the DEK is 16
   bytes long.  CSUM is a 16-bit checksum of the DEK, used to determine
   that the correct Private key was used to decrypt this packet.  The
   checksum is computed by the 16-bit sum of the bytes in the DEK.  RND
   is random padding to expand the byte to fill the size of the RSA
   Public Key that is used to encrypt the whole byte.

6.6 Public Key Packet

   Purpose.  A public key packet defines an RSA public key.

   Definition.  A public key packet is the concatenation of the
   following fields:

      (a) packet structure field (2 or 3 bytes);
      (b) version number = 2 or 3 (1 byte);;
      (c) time stamp of key creation (4 bytes);
      (d) validity period in days (0 means forever) (2 bytes);
      (e) public-key-cryptosystem (PKC) type (1 byte);
      (f) MPI of RSA public modulus n;
      (g) MPI of RSA public encryption exponent e.

    The validity period is always set to 0.




Atkins, et. al.              Informational                     [Page 19]

RFC 1991              PGP Message Exchange Formats           August 1996


6.7 User ID Packet

   Purpose.  A user ID packet identifies a user and is associated with a
   public or private key.

   Definition.  A user ID packet is the concatenation of the following
   fields:

      (a) packet structure field (2 bytes);
      (b) User ID string.

   The User ID string may be any string of printable ASCII characters.
   However, since the purpose of this packet is to uniquely identify an
   individual, the usual practice is for the User ID string to consist
   of the user's name followed by an e-mail address for that user, the
   latter enclosed in angle brackets.

7. Transferable Public Keys

   Public keys may transferred between PGP users. The essential elements
   of a transferable public key are

      (a) One public key packet;
      (b) One or more user ID packets;
      (c) Zero or more signature packets

   The public key packet occurs first.  Each of the following user ID
   packets provides the identity of the owner of this public key.  If
   there are multiple user ID packets, this corresponds to multiple
   means of identifying the same unique individual user; for example, a
   user may enjoy the use of more than one e-mail address, and construct
   a user ID packet for each one.  Immediately following each user ID
   packet, there are zero or more signature packets. Each signature
   packet is calculated on the immediately preceding user ID packet and
   the initial public key packet.  The signature serves to certify the
   corresponding public key and user ID.  In effect, the signer is
   testifying to his or her belief that this public key belongs to the
   user identified by this user ID.

8. Acknowledgments

   Philip Zimmermann is the creator of PGP 1.0, which is the precursor
   of PGP 2.x.  Major parts of later versions of PGP have been
   implemented by an international collaborative effort involving a
   large number of contributors, under the design guidance of Philip
   Zimmermann.





Atkins, et. al.              Informational                     [Page 20]

RFC 1991              PGP Message Exchange Formats           August 1996


9. Security Considerations

   Security issues are discussed throughout this memo.

10. Authors' Addresses

   Derek Atkins
   12 Rindge Ave. #1R
   Cambridge, MA

   Phone: [phone]
   EMail: [e-mail]


   William Stallings
   Comp-Comm Consulting
   P. O. Box 2405
   Brewster, MA 02631

   EMail: [e-mail]


   Philip Zimmermann
   Boulder Software Engineering
   3021 Eleventh Street
   Boulder, Colorado 80304  USA

   Phone: [phone]
   EMail: [e-mail]






















Atkins, et. al.              Informational                     [Page 21]