draft-ietf-openpgp-rfc2440bis-07.txt

用C#开发实现SMTP相关技术,能接收到带附件的邮件服务功能.

   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.

     - 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.



Callas, et al.         Expires September 3, 2003              [Page 23]
INTERNET-DRAFT          OpenPGP Message Format            March 3, 2003

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:

       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

Callas, et al.         Expires September 3, 2003              [Page 24]
INTERNET-DRAFT          OpenPGP Message Format            March 3, 2003

       28 = signer's user id
       29 = reason for revocation
       30 = features
       31 = signature target

   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.

   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" and the "reason for
   revocation" subpackets. Note, however, that if an implementation
   chooses not to implement some of the preferences, it is required to
   behave in a polite manner to respect the wishes of those users who
   do implement these 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 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.

5.2.3.3. Notes on Self-Signatures

   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

Callas, et al.         Expires September 3, 2003              [Page 25]
INTERNET-DRAFT          OpenPGP Message Format            March 3, 2003

   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.

   Revoking a self-signature or allowing it to expire has a semantic
   meaning that varies with the signature type. Revoking the
   self-signature on a user ID effectively retires that user name. The
   self-signature is a statement, "My name X is tied to my signing key
   K" and is corroborated by other users' certifications. If another
   user revokes their certification, they are effectively saying that
   they no longer believe that name and that key are tied together.
   Similarly, if the user themselves revokes their self-signature, it
   means the user no longer goes by that name, no longer has that email
   address, etc. Revoking a binding signature effectively retires that
   subkey. Revoking a direct-key signature cancels that signature.
   Please see the "Reason for Revocation" subpacket below for more
   relevant detail.

   Since a self-signature contains important information about the
   key's use, an implementation SHOULD allow the user to rewrite the
   self-signature, and important information in it, such as preferences
   and key expiration.

   An implementation that encounters multiple self-signatures on the
   same object may resolve the ambiguity in any way it sees fit, but it
   is RECOMMENDED that priority be given to the most recent
   self-signature.

5.2.3.4. Signature creation time

   (4 octet time field)

   The time the signature was made.

   MUST be present in the hashed area.

5.2.3.5. Issuer 

   (8 octet key ID)

   The OpenPGP key ID of the key issuing the signature.



Callas, et al.         Expires September 3, 2003              [Page 26]
INTERNET-DRAFT          OpenPGP Message Format            March 3, 2003

5.2.3.6. Key expiration time

   (4 octet time field)

   The validity period of the key.  This is the number of seconds after
   the key creation time that the key expires.  If this is not present
   or has a value of zero, the key never expires. This is found only on
   a self-signature.

5.2.3.7. Preferred symmetric algorithms

   (sequence of one-octet values)

   Symmetric algorithm numbers that indicate which algorithms the key
   holder prefers to use.  The subpacket body is an ordered list of
   octets with the most preferred listed first. It is assumed that only
   algorithms listed are supported by the recipient's software.
   Algorithm numbers in section 9. This is only found on a
   self-signature.

5.2.3.8. Preferred hash algorithms

   (array of one-octet values)

   Message digest algorithm numbers that indicate which algorithms the
   key holder prefers to receive. Like the preferred symmetric
   algorithms, the list is ordered. Algorithm numbers are in section 6.
   This is only found on a self-signature.

5.2.3.9. Preferred compression algorithms

   (array of one-octet values)

   Compression algorithm numbers that indicate which algorithms the key
   holder prefers to use. Like the preferred symmetric algorithms, the
   list is ordered. Algorithm numbers are in section 6. If this
   subpacket is not included, ZIP is preferred. A zero denotes that
   uncompressed data is preferred; the key holder's software might have
   no compression software in that implementation. This is only found
   on a self-signature.

5.2.3.10. Signature expiration time

   (4 octet time field)

   The validity period of the signature.  This is the number of seconds
   after the signature creation time that the signature expires. If
   this is not present or has a value of zero, it never expires.

5.2.3.11. Exportable Certification

   (1 octet of exportability, 0 for not, 1 for exportable)

Callas, et al.         Expires September 3, 2003              [Page 27]
INTERNET-DRAFT          OpenPGP Message Format            March 3, 2003

   This subpacket denotes whether a certification signature is
   "exportable," to be used by other users than the signature's issuer.
   The packet body contains a Boolean flag indicating whether the
   signature is exportable. If this packet is not present, the
   certification is exportable; it is equivalent to a flag containing a
   1. 

   Non-exportable, or "local," certifications are signatures made by a
   user to mark a key as valid within that user's implementation only.
   Thus, when an implementation prepares a user's copy of a key for
   transport to another user (this is the process of "exporting" the
   key), any local certification signatures are deleted from the key.

   The receiver of a transported key "imports" it, and likewise trims
   any local certifications. In normal operation, there won't be any,
   assuming the import is performed on an exported key. However, there
   are instances where this can reasonably happen. For example, if an
   implementation allows keys to be imported from a key database in
   addition to an exported key, then this situation can arise.

   Some implementations do not represent the interest of a single user
   (for example, a key server). Such implementations always trim local
   certifications from any key they handle.

5.2.3.12. Revocable

   (1 octet of revocability, 0 for not, 1 for revocable)

   Signature's revocability status.  Packet body contains a Boolean
   flag indicating whether the signature is revocable.  Signatures that
   are not revocable have any later revocation signatures ignored.
   They represent a commitment by the signer that he cannot revoke his
   signature for the life of his key.  If this packet is not present,
   the signature is r