rfc2440.txt

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

         Bit 6 -- New packet format if set

   PGP 2.6.x only uses old format packets. Thus, software that
   interoperates with those versions of PGP must only use old format
   packets. If interoperability is not an issue, either format may be
   used. Note that old format packets have four bits of content tags,
   and new format packets have six; some features cannot be used and
   still be backward-compatible.

   Old format packets contain:

         Bits 5-2 -- content tag
         Bits 1-0 - length-type





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


   New format packets contain:

         Bits 5-0 -- content tag

4.2.1. Old-Format Packet Lengths

   The meaning of the length-type in old-format packets is:

   0 - The packet has a one-octet length. The header is 2 octets long.

   1 - The packet has a two-octet length. The header is 3 octets long.

   2 - The packet has a four-octet length. The header is 5 octets long.

   3 - The packet is of indeterminate length.  The header is 1 octet
       long, and the implementation must determine how long the packet
       is. If the packet is in a file, this means that the packet
       extends until the end of the file. In general, an implementation
       SHOULD NOT use indeterminate length packets except where the end
       of the data will be clear from the context, and even then it is
       better to use a definite length, or a new-format header. The
       new-format headers described below have a mechanism for precisely
       encoding data of indeterminate length.

4.2.2. New-Format Packet Lengths

   New format packets have four possible ways of encoding length:

    1. A one-octet Body Length header encodes packet lengths of up to
       191 octets.

   2. A two-octet Body Length header encodes packet lengths of 192 to
       8383 octets.

    3. A five-octet Body Length header encodes packet lengths of up to
       4,294,967,295 (0xFFFFFFFF) octets in length. (This actually
       encodes a four-octet scalar number.)

    4. When the length of the packet body is not known in advance by the
       issuer, Partial Body Length headers encode a packet of
       indeterminate length, effectively making it a stream.










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


4.2.2.1. One-Octet Lengths

   A one-octet Body Length header encodes a length of from 0 to 191
   octets. This type of length header is recognized because the one
   octet value is less than 192.  The body length is equal to:

       bodyLen = 1st_octet;

4.2.2.2. Two-Octet Lengths

   A two-octet Body Length header encodes a length of from 192 to 8383
   octets.  It is recognized because its first octet is in the range 192
   to 223.  The body length is equal to:

       bodyLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192

4.2.2.3. Five-Octet Lengths

   A five-octet Body Length header consists of a single octet holding
   the value 255, followed by a four-octet scalar. The body length is
   equal to:

       bodyLen = (2nd_octet << 24) | (3rd_octet << 16) |
                 (4th_octet << 8)  | 5th_octet

4.2.2.4. Partial Body Lengths

   A Partial Body Length header is one octet long and encodes the length
   of only part of the data packet. This length is a power of 2, from 1
   to 1,073,741,824 (2 to the 30th power).  It is recognized by its one
   octet value that is greater than or equal to 224, and less than 255.
   The partial body length is equal to:

       partialBodyLen = 1 << (1st_octet & 0x1f);

   Each Partial Body Length header is followed by a portion of the
   packet body data. The Partial Body Length header specifies this
   portion's length. Another length header (of one of the three types --
   one octet, two-octet, or partial) follows that portion. The last
   length header in the packet MUST NOT be a partial Body Length header.
   Partial Body Length headers may only be used for the non-final parts
   of the packet.

4.2.3. Packet Length Examples

   These examples show ways that new-format packets might encode the
   packet lengths.




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


   A packet with length 100 may have its length encoded in one octet:
   0x64. This is followed by 100 octets of data.

   A packet with length 1723 may have its length coded in two octets:
   0xC5, 0xFB.  This header is followed by the 1723 octets of data.

   A packet with length 100000 may have its length encoded in five
   octets: 0xFF, 0x00, 0x01, 0x86, 0xA0.

   It might also be encoded in the following octet stream: 0xEF, first
   32768 octets of data; 0xE1, next two octets of data; 0xE0, next one
   octet of data; 0xF0, next 65536 octets of data; 0xC5, 0xDD, last 1693
   octets of data.  This is just one possible encoding, and many
   variations are possible on the size of the Partial Body Length
   headers, as long as a regular Body Length header encodes the last
   portion of the data. Note also that the last Body Length header can
   be a zero-length header.

   An implementation MAY use Partial Body Lengths for data packets, be
   they literal, compressed, or encrypted. The first partial length MUST
   be at least 512 octets long. Partial Body Lengths MUST NOT be used
   for any other packet types.

   Please note that in all of these explanations, the total length of
   the packet is the length of the header(s) plus the length of the
   body.

4.3. Packet Tags

   The packet tag denotes what type of packet the body holds. Note that
   old format headers can only have tags less than 16, whereas new
   format headers can have tags as great as 63. The defined tags (in
   decimal) are:

       0        -- Reserved - a packet tag must not have this value
       1        -- Public-Key Encrypted Session Key Packet
       2        -- Signature Packet
       3        -- Symmetric-Key Encrypted Session Key Packet
       4        -- One-Pass Signature Packet
       5        -- Secret Key Packet
       6        -- Public Key Packet
       7        -- Secret Subkey Packet
       8        -- Compressed Data Packet
       9        -- Symmetrically Encrypted Data Packet
       10       -- Marker Packet
       11       -- Literal Data Packet
       12       -- Trust Packet




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


       13       -- User ID Packet
       14       -- Public Subkey Packet
       60 to 63 -- Private or Experimental Values

5. Packet Types

5.1. Public-Key Encrypted Session Key Packets (Tag 1)

   A Public-Key Encrypted Session Key packet holds the session key used
   to encrypt a message. Zero or more Encrypted Session Key packets
   (either Public-Key or Symmetric-Key) may precede a Symmetrically
   Encrypted Data Packet, which holds an encrypted message.  The message
   is encrypted with the session key, and the session key is itself
   encrypted and stored in the Encrypted Session Key packet(s).  The
   Symmetrically Encrypted Data Packet is preceded by one Public-Key
   Encrypted Session Key packet for each OpenPGP key to which the
   message is encrypted.  The recipient of the message finds a session
   key that is encrypted to their public key, decrypts the session key,
   and then uses the session key to decrypt the message.

   The body of this packet consists of:

     - A one-octet number giving the version number of the packet type.
       The currently defined value for packet version is 3. An
       implementation should accept, but not generate a version of 2,
       which is equivalent to V3 in all other respects.

     - An eight-octet number that gives the key ID of the public key
       that the session key is encrypted to.

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

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






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


   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 padded as described in
   PKCS-1 block type 02 [RFC2313] 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 padding 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.
         Typically, this means the signer owns it, created it, or
         certifies that it has not been modified.




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


   0x01: Signature of a canonical text document.
         Typically, 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.