rfc2440.txt

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

   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.









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


5.2.3.3. Signature creation time

   (4 octet time field)

   The time the signature was made.

   MUST be present in the hashed area.

5.2.3.4. Issuer

   (8 octet key ID)

   The OpenPGP key ID of the key issuing the signature.

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









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


5.2.3.8. 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.9. 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.10. Exportable Certification

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

   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.




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


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

5.2.3.12. Trust signature

   (1 octet "level" (depth), 1 octet of trust amount)

   Signer asserts that the key is not only valid, but also trustworthy,
   at the specified level.  Level 0 has the same meaning as an ordinary
   validity signature.  Level 1 means that the signed key is asserted to
   be a valid trusted introducer, with the 2nd octet of the body
   specifying the degree of trust. Level 2 means that the signed key is
   asserted to be trusted to issue level 1 trust signatures, i.e. that
   it is a "meta introducer". Generally, a level n trust signature
   asserts that a key is trusted to issue level n-1 trust signatures.
   The trust amount is in a range from 0-255, interpreted such that
   values less than 120 indicate partial trust and values of 120 or
   greater indicate complete trust.  Implementations SHOULD emit values
   of 60 for partial trust and 120 for complete trust.

5.2.3.13. Regular expression

   (null-terminated regular expression)

   Used in conjunction with trust signature packets (of level > 0) to
   limit the scope of trust that is extended.  Only signatures by the
   target key on user IDs that match the regular expression in the body
   of this packet have trust extended by the trust signature subpacket.
   The regular expression uses the same syntax as the Henry Spencer's
   "almost public domain" regular expression package. A description of
   the syntax is found in a section below.

5.2.3.14. Revocation key

   (1 octet of class, 1 octet of algid, 20 octets of fingerprint)

   Authorizes the specified key to issue revocation signatures for this
   key.  Class octet must have bit 0x80 set. If the bit 0x40 is set,
   then this means that the revocation information is sensitive.  Other
   bits are for future expansion to other kinds of authorizations. This



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


   is found on a self-signature.

   If the "sensitive" flag is set, the keyholder feels this subpacket
   contains private trust information that describes a real-world
   sensitive relationship. If this flag is set, implementations SHOULD
   NOT export this signature to other users except in cases where the
   data needs to be available: when the signature is being sent to the
   designated revoker, or when it is accompanied by a revocation
   signature from that revoker.  Note that it may be appropriate to
   isolate this subpacket within a separate signature so that it is not
   combined with other subpackets that need to be exported.

5.2.3.15. Notation Data

       (4 octets of flags, 2 octets of name length (M),
                           2 octets of value length (N),
                           M octets of name data,
                           N octets of value data)

   This subpacket describes a "notation" on the signature that the
   issuer wishes to make. The notation has a name and a value, each of
   which are strings of octets. There may be more than one notation in a
   signature. Notations can be used for any extension the issuer of the
   signature cares to make. The "flags" field holds four octets of
   flags.

   All undefined flags MUST be zero. Defined flags are:

       First octet: 0x80 = human-readable. This note is text, a note
                           from one person to another, and has no
                           meaning to software.
       Other octets: none.

5.2.3.16. Key server preferences

   (N octets of flags)

   This is a list of flags that indicate preferences that the key holder
   has about how the key is handled on a key server. All undefined flags
   MUST be zero.

   First octet: 0x80 = No-modify
       the key holder requests that this key only be modified or updated
       by the key holder or an administrator of the key server.

   This is found only on a self-signature.





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


5.2.3.17. Preferred key server

   (String)

   This is a URL of a key server that the key holder prefers be used for
   updates. Note that keys with multiple user ids can have a preferred
   key server for each user id. Note also that since this is a URL, the
   key server can actually be a copy of the key retrieved by ftp, http,
   finger, etc.

5.2.3.18. Primary user id

   (1 octet, boolean)

   This is a flag in a user id's self signature that states whether this
   user id is the main user id for this key. It is reasonable for an
   implementation to resolve ambiguities in preferences, etc. by
   referring to the primary user id. If this flag is absent, its value
   is zero. If more than one user id in a key is marked as primary, the
   implementation may resolve the ambiguity in any way it sees fit.

5.2.3.19. Policy URL

   (String)

   This subpacket contains a URL of a document that describes the policy
   that the signature was issued under.

5.2.3.20. Key Flags

   (Octet string)

   This subpacket contains a list of binary flags that hold information
   about a key. It is a string of octets, and an implementation MUST NOT
   assume a fixed size. This is so it can grow over time. If a list is
   shorter than an implementation expects, the unstated flags are
   considered to be zero. The defined flags are:

       First octet:

       0x01 - This key may be used to certify other keys.

       0x02 - This key may be used to sign data.

       0x04 - This key may be used to encrypt communications.

       0x08 - This key may be used to encrypt storage.




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


       0x10 - The private component of this key may have been split by a
       secret-sharing mechanism.

       0x80 - The private component of this key may be