rfc1991.txt

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

   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 only the above numbers may be used
   with version 2 or version 3 of a signature packet.  It should be
   noted that PGP 2.6.2 has not implemented the packets marked with an
   asterisk (*), and the packets marked with a hash (#) are not output
   by PGP 2.6.2.

   Signature packets are used in two different contexts. One (signature
   type <00> or <01>) is of text (either the contents of a literal
   packet or a separate file), while types <10> through <1F> appear only
   in key files, after the keys and user IDs that they sign.  Type <20>
   appears in key files, after the keys that it signs, and type <30>
   also appears after a key/userid combination. Type <40> is intended to
   be a signature of a signature, as a notary seal on a signed document.

   The output of the message digest algorithm is a message digest, or
   hash code. Field i contains the cyphertext produced by encrypting the
   message digest with the signer's private key.  Field h contains the
   first two bytes of the unencrypted message digest. This enables the
   recipient to determine if the correct public key was used to decrypt
   the message digest for authentication, by comparing this plaintext
   copy of the first two byes with the first two bytes of the decrypted
   digest. These two bytes also serve as a 16-bit frame check sequence
   for the message.

6.2.2 Public-key-related fields

   The message digest is signed by encrypting it using the writer's
   private key. Field (e) is the ID of the corresponding public key.

   The public-key-encryption algorithm is specified by the public-key
   cryptosystem (PKC) number of field (f). The following PKC numbers are
   currently defined:

      1 - RSA
      255 - experimental

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






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


   A PKC number identifies both a public-key encryption method and a
   signature method.  Both of these methods are fully defined as part of
   the definition of the PKC number.  Some cryptosystems are usable only
   for encryption, or only for signatures; if any such PKC numbers are
   defined in the future, they will be marked appropriately.

6.2.3 RSA signatures

   An RSA-signed byte string is a multiprecision field that is formed by
   taking the message digest and filling in an ASN structure, and then
   encrypting the whole byte string in the RSA key of the signer.

   PGP versions 2.3 and later encode the MD into a PKCS-format signature
   string, which has the following format:

          MSB               .   .   .                    LSB
          0   1   <FF>(n bytes)   0   ASN(18 bytes)   MD(16 bytes)

   See RFC1423 for an explanation of the meaning of the ASN string.  It
   is the following 18 byte long hex value:

          <30 20 30 0C 06 08 2A 86 48 86 F7 0D 02 05 05 00 04 10>

   Enough bytes of <FF> padding are added to make the length of this
   whole string equal to the number of bytes in the modulus.

6.2.4 Miscellaneous fields

   The timestamp field (d2) is analogous to the date box next to a
   signature box on a form.  It represents a time which is typically
   close to the moment that the signature packet was created.  However,
   this is not a requirement.  Users may choose to date their signatures
   as they wish, just as they do now in handwritten signatures.

   If an application requires the creation of trusted timestamps on
   signatures, a detached signature certificate with an untrusted
   timestamp may be submitted to a trusted timestamp notary service to
   sign the signature packet with another signature packet, creating a
   signature of a signature.  The notary's signature's timestamp could