rfc2440.txt

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

         packets.






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


   0x1F: Signature directly on a key
         This signature is calculated directly on a key.  It binds the
         information in the signature subpackets to the key, and is
         appropriate to be used for subpackets that provide information
         about the key, such as the revocation key subpacket. It is also
         appropriate for statements that non-self certifiers want to
         make about the key itself, rather than the binding between a
         key and a name.

   0x20: Key revocation signature
         The signature is calculated directly on the key being revoked.
         A revoked key is not to be used.  Only revocation signatures by
         the key being revoked, or by an authorized revocation key,
         should be considered valid revocation signatures.

   0x28: Subkey revocation signature
         The signature is calculated directly on the subkey being
         revoked.  A revoked subkey is not to be used.  Only revocation
         signatures by the top-level signature key that is bound to this
         subkey, or by an authorized revocation key, should be
         considered valid revocation signatures.

   0x30: Certification revocation signature
         This signature revokes an earlier user ID certification
         signature (signature class 0x10 through 0x13). It should be
         issued by the same key that issued the revoked signature or an
         authorized revocation key The signature should have a later
         creation date than the signature it revokes.

   0x40: Timestamp signature.
         This signature is only meaningful for the timestamp contained
         in it.

5.2.2. Version 3 Signature Packet Format

   The body of a version 3 Signature Packet contains:

     - One-octet version number (3).

     - One-octet length of following hashed material.  MUST be 5.

         - One-octet signature type.

         - Four-octet creation time.

     - Eight-octet key ID of signer.

     - One-octet public key algorithm.



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


     - One-octet hash algorithm.

     - Two-octet field holding left 16 bits of signed hash value.

     - One or more multi-precision integers comprising the signature.
       This portion is algorithm specific, as described below.

   The data being signed is hashed, and then the signature type and
   creation time from the signature packet are hashed (5 additional
   octets).  The resulting hash value is used in the signature
   algorithm. The high 16 bits (first two octets) of the hash are
   included in the signature packet to provide a quick test to reject
   some invalid signatures.

   Algorithm Specific Fields for RSA signatures:

     - multiprecision integer (MPI) of RSA signature value m**d.

   Algorithm Specific Fields for DSA signatures:

     - MPI of DSA value r.

     - MPI of DSA value s.

   The signature calculation is based on a hash of the signed data, as
   described above.  The details of the calculation are different for
   DSA signature than for RSA signatures.

   With RSA signatures, the hash value is encoded as described in PKCS-1
   section 10.1.2, "Data encoding", producing an ASN.1 value of type
   DigestInfo, and then padded using PKCS-1 block type 01 [RFC2313].
   This requires inserting the hash value as an octet string into an
   ASN.1 structure. The object identifier for the type of hash being
   used is included in the structure.  The hexadecimal representations
   for the currently defined hash algorithms are:

     - MD2:        0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02

     - MD5:        0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05

     - RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01

     - SHA-1:      0x2B, 0x0E, 0x03, 0x02, 0x1A








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


   The ASN.1 OIDs are:

     - MD2:        1.2.840.113549.2.2

     - MD5:        1.2.840.113549.2.5

     - RIPEMD-160: 1.3.36.3.2.1

     - SHA-1:      1.3.14.3.2.26

   The full hash prefixes for these are:

       MD2:        0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86,
                   0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02, 0x05, 0x00,
                   0x04, 0x10

       MD5:        0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86,
                   0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00,
                   0x04, 0x10

       RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24,
                   0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14

       SHA-1:      0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E,
                   0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14

   DSA signatures MUST use hashes with a size of 160 bits, to match q,
   the size of the group generated by the DSA key's generator value.
   The hash function result is treated as a 160 bit number and used
   directly in the DSA signature algorithm.

5.2.3. Version 4 Signature Packet Format

   The body of a version 4 Signature Packet contains:

     - One-octet version number (4).

     - One-octet signature type.

     - One-octet public key algorithm.

     - One-octet hash algorithm.

     - Two-octet scalar octet count for following hashed subpacket
       data. Note that this is the length in octets of all of the hashed
       subpackets; a pointer incremented by this number will skip over
       the hashed subpackets.




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


     - Hashed subpacket data. (zero or more subpackets)

     - Two-octet scalar octet count for following unhashed subpacket
       data. Note that this is the length in octets of all of the
       unhashed subpackets; a pointer incremented by this number will
       skip over the unhashed subpackets.

     - Unhashed subpacket data. (zero or more subpackets)

     - Two-octet field holding left 16 bits of signed hash value.

     - One or more multi-precision integers comprising the signature.
       This portion is algorithm specific, as described above.

   The data being signed is hashed, and then the signature data from the
   version number through the hashed subpacket data (inclusive) is
   hashed. The resulting hash value is what is signed.  The left 16 bits
   of the hash are included in the signature packet to provide a quick
   test to reject some invalid signatures.

   There are two fields consisting of signature subpackets.  The first
   field is hashed with the rest of the signature data, while the second
   is unhashed.  The second set of subpackets is not cryptographically
   protected by the signature and should include only advisory
   information.

   The algorithms for converting the hash function result to a signature
   are described in a section below.

5.2.3.1. Signature Subpacket Specification

   The subpacket fields consist of zero or more signature subpackets.
   Each set of subpackets is preceded by a two-octet scalar count of the
   length of the set of subpackets.

   Each subpacket consists of a subpacket header and a body.  The header
   consists of:

     - the subpacket length (1,  2, or 5 octets)

     - the subpacket type (1 octet)

   and is followed by the subpacket specific data.

   The length includes the type octet but not this length. Its format is
   similar to the "new" format packet header lengths, but cannot have
   partial body lengths. That is:




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


       if the 1st octet <  192, then
           lengthOfLength = 1
           subpacketLen = 1st_octet

       if the 1st octet >= 192 and < 255, then
           lengthOfLength = 2
           subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192

       if the 1st octet = 255, then
           lengthOfLength = 5
           subpacket length = [four-octet scalar starting at 2nd_octet]

   The value of the subpacket type octet may be:

       2 = signature creation time
       3 = signature expiration time
       4 = exportable certification
       5 = trust signature
       6 = regular expression
       7 = revocable
       9 = key expiration time
       10 = placeholder for backward compatibility
       11 = preferred symmetric algorithms
       12 = revocation key
       16 = issuer key ID
       20 = notation data
       21 = preferred hash algorithms
       22 = preferred compression algorithms
       23 = key server preferences
       24 = preferred key server
       25 = primary user id
       26 = policy URL
       27 = key flags
       28 = signer's user id
       29 = reason for revocation
       100 to 110 = internal or user-defined

   An implementation SHOULD ignore any subpacket of a type that it does
   not recognize.

   Bit 7 of the subpacket type is the "critical" bit.  If set, it
   denotes that the subpacket is one that is critical for the evaluator
   of the signature to recognize.  If a subpacket is encountered that is
   marked critical but is unknown to the evaluating software, the
   evaluator SHOULD consider the signature to be in error.






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


   An evaluator may "recognize" a subpacket, but not implement it. The
   purpose of the critical bit is to allow the signer to tell an
   evaluator that it would prefer a new, unknown feature to generate an
   error than be ignored.

   Implementations SHOULD implement "preferences".

5.2.3.2. Signature Subpacket Types

   A number of subpackets are currently defined.  Some subpackets apply
   to the signature itself and some are attributes of the key.
   Subpackets that are found on a self-signature are placed on a user id
   certification made by the key itself. Note that a key may have more
   than one user id, and thus may have more than one self-signature, and
   differing subpackets.

   A self-signature is a binding signature made by the key the signature
   refers to. There are three types of self-signatures, the
   certification signatures (types 0x10-0x13), the direct-key signature
   (type 0x1f), and the subkey binding signature (type 0x18). For
   certification self-signatures, each user ID may have a self-
   signature, and thus different subpackets in those self-signatures.
   For subkey binding signatures, each subkey in fact has a self-
   signature. Subpackets that appear in a certification self-signature
   apply to the username, and subpackets that appear in the subkey
   self-signature apply to the subkey. Lastly, subpackets on the direct
   key signature apply to the entire key.

   Implementing software should interpret a self-signature's preference
   subpackets as narrowly as possible. For example, suppose a key has
   two usernames, Alice and Bob. Suppose that Alice prefers the
   symmetric algorithm CAST5, and Bob prefers IDEA or Triple-DES. If the
   software locates this key via Alice's name, then the preferred
   algorithm is CAST5, if software locates the key via Bob's name, then
   the preferred algorithm is IDEA. If the key is located by key id,
   then algorithm of the default user id of the key provides the default
   symmetric algorithm.

   A subpacket may be found either in the hashed or unhashed subpacket
   sections of a signature. If a subpacket is not hashed, then the
   information in it cannot be considered definitive because it is not
   part of the signature proper.