draft-ietf-openpgp-rfc2440bis-07.txt

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

     - An eight-octet number that gives the key ID of the public key
       that the session key is encrypted to. If the session key is
       encrypted to a subkey then the key ID of this subkey is used
       here instead of the key ID of the primary key.

     - A one-octet number giving the public key algorithm used.

     - A string of octets that is the encrypted session key. This
       string takes up the remainder of the packet, and its contents
       are dependent on the public key algorithm used.

   Algorithm Specific Fields for RSA encryption

     - multiprecision integer (MPI) of RSA encrypted value m**e mod n.

   Algorithm Specific Fields for Elgamal encryption:

     - MPI of Elgamal (Diffie-Hellman) value g**k mod p.



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

     - MPI of Elgamal (Diffie-Hellman) value m * y**k mod p.

   The value "m" in the above formulas is derived from the session key
   as follows.  First the session key is prefixed with a one-octet
   algorithm identifier that specifies the symmetric encryption
   algorithm used to encrypt the following Symmetrically Encrypted Data
   Packet.  Then a two-octet checksum is appended which is equal to the
   sum of the preceding session key octets, not including the algorithm
   identifier, modulo 65536.  This value is then encoded as described
   in PKCS-1 block encoding EME-PKCS1-v1_5 [RFC2437] to form the "m"
   value used in the formulas above.

   Note that when an implementation forms several PKESKs with one
   session key, forming a message that can be decrypted by several
   keys, the implementation MUST make new PKCS-1 encoding for each key.

   An implementation MAY accept or use a Key ID of zero as a "wild
   card" or "speculative" Key ID. In this case, the receiving
   implementation would try all available private keys, checking for a
   valid decrypted session key. This format helps reduce traffic
   analysis of messages.

5.2. Signature Packet (Tag 2)

   A signature packet describes a binding between some public key and
   some data. The most common signatures are a signature of a file or a
   block of text, and a signature that is a certification of a user ID.

   Two versions of signature packets are defined.  Version 3 provides
   basic signature information, while version 4 provides an expandable
   format with subpackets that can specify more information about the
   signature. PGP 2.6.x only accepts version 3 signatures.

   Implementations MUST accept V3 signatures. Implementations SHOULD
   generate V4 signatures.  Implementations MAY generate a V3 signature
   that can be verified by PGP 2.6.x.

   Note that if an implementation is creating an encrypted and signed
   message that is encrypted to a V3 key, it is reasonable to create a
   V3 signature.

5.2.1. Signature Types

   There are a number of possible meanings for a signature, which are
   specified in a signature type octet in any given signature. These
   meanings are:

   0x00: Signature of a binary document.
       This means the signer owns it, created it, or certifies that it
       has not been modified.



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

   0x01: Signature of a canonical text document.
       This means the signer owns it, created it, or certifies that it
       has not been modified.  The signature is calculated over the
       text data with its line endings converted to <CR><LF> and
       trailing blanks removed.

   0x02: Standalone signature.
       This signature is a signature of only its own subpacket
       contents. It is calculated identically to a signature over a
       zero-length binary document. Note that it doesn't make sense to
       have a V3 standalone signature.

   0x10: Generic certification of a User ID and Public Key packet.
       The issuer of this certification does not make any particular
       assertion as to how well the certifier has checked that the
       owner of the key is in fact the person described by the user ID.
       Note that all PGP "key signatures" are this type of
       certification.

   0x11: Persona certification of a User ID and Public Key packet.
       The issuer of this certification has not done any verification
       of the claim that the owner of this key is the user ID
       specified. 

   0x12: Casual certification of a User ID and Public Key packet.
       The issuer of this certification has done some casual
       verification of the claim of identity.

   0x13: Positive certification of a User ID and Public Key packet.
       The issuer of this certification has done substantial
       verification of the claim of identity.

       Please note that the vagueness of these certification claims is
       not a flaw, but a feature of the system. Because PGP places
       final authority for validity upon the receiver of a
       certification, it may be that one authority's casual
       certification might be more rigorous than some other authority's
       positive certification. These classifications allow a
       certification authority to issue fine-grained claims.

   0x18: Subkey Binding Signature
       This signature is a statement by the top-level signing key
       indicates that it owns the subkey. This signature is calculated
       directly on the subkey itself, not on any User ID or other
       packets.

   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

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

       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) or direct-key
       signature (0x1F). 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.

   0x50: Notary signature.
       This signature is a signature over some other OpenPGP signature
       packet. It is a notary seal on the signed data. Note that a
       notary signature SHOULD include a Signature Target subpacket to
       give easy identification.

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.         Expires September 3, 2003              [Page 20]
INTERNET-DRAFT          OpenPGP Message Format            March 3, 2003

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

   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.

   Algorithm Specific Fields for Elgamal signatures:

     - MPI of Elgamal value a = g**k mod p.

     - MPI of Elgamal value b = (h-a*x)/k mod p-1.

   The hash h is PKCS-1 padded exactly the same way as for the above
   described RSA signatures.

   With RSA signatures, the hash value is encoded as described in
   PKCS-1 section 9.2.1 encoded using PKCS-1 encoding type
   EMSA-PKCS1-v1_5 [RFC2437].  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



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

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

     - SHA256:     0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01

     - SHA384:     0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02

     - SHA512:     0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03

   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

     - SHA256:     2.16.840.1.101.3.4.2.1

     - SHA384:     2.16.840.1.101.3.4.2.2

     - SHA512:     2.16.840.1.101.3.4.2.3

   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

       SHA256:     0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
                   0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05,
                   0x00, 0x04, 0x20

       SHA384:     0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
                   0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05,
                   0x00, 0x04, 0x30

       SHA512:     0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
                   0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05,
                   0x00, 0x04, 0x40


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

   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