GnuPG - RFC2440

# RFC2440

[ Contents ]

    10. Packet Composition

       OpenPGP packets are assembled into sequences in order to create
       messages and to transfer keys.  Not all possible packet sequences are
       meaningful and correct.  This describes the rules for how packets
       should be placed into sequences.

    10.1. Transferable Public Keys

       OpenPGP users may transfer public keys. The essential elements of a
       transferable public key are:

         - One Public Key packet

         - Zero or more revocation signatures

         - One or more User ID packets

         - After each User ID packet, zero or more signature packets
           (certifications)

         - Zero or more Subkey packets

         - After each Subkey packet, one signature packet, optionally a
           revocation.

       The Public Key packet occurs first.	Each of the following User ID
       packets provides the identity of the owner of this public key.  If
       there are multiple User ID packets, this corresponds to multiple
       means of identifying the same unique individual user; for example, a
       user may have more than one email address, and construct a User ID
       for each one.

       Immediately following each User ID packet, there are zero or more
       signature packets. Each signature packet is calculated on the
       immediately preceding User ID packet and the initial Public Key
       packet. The signature serves to certify the corresponding public key
       and user ID.  In effect, the signer is testifying to his or her
       belief that this public key belongs to the user identified by this
       user ID.

       After the User ID packets there may be one or more Subkey packets.
       In general, subkeys are provided in cases where the top-level public
       key is a signature-only key.  However, any V4 key may have subkeys,
       and the subkeys may be encryption-only keys, signature-only keys, or
       general-purpose keys.

       Each Subkey packet must be followed by one Signature packet, which
       should be a subkey binding signature issued by the top level key.

       Subkey and Key packets may each be followed by a revocation Signature
       packet to indicate that the key is revoked.	Revocation signatures
       are only accepted if they are issued by the key itself, or by a key
       that is authorized to issue revocations via a revocation key
       subpacket in a self-signature by the top level key.

       Transferable public key packet sequences may be concatenated to allow
       transferring multiple public keys in one operation.

    10.2. OpenPGP Messages

       An OpenPGP message is a packet or sequence of packets that
       corresponds to the following grammatical rules (comma represents
       sequential composition, and vertical bar separates alternatives):

       OpenPGP Message :- Encrypted Message | Signed Message |
    		      Compressed Message | Literal Message.

       Compressed Message :- Compressed Data Packet.

       Literal Message :- Literal Data Packet.

       ESK :- Public Key Encrypted Session Key Packet |
    	  Symmetric-Key Encrypted Session Key Packet.

       ESK Sequence :- ESK | ESK Sequence, ESK.

       Encrypted Message :- Symmetrically Encrypted Data Packet |
    	       ESK Sequence, Symmetrically Encrypted Data Packet.

       One-Pass Signed Message :- One-Pass Signature Packet,
    	       OpenPGP Message, Corresponding Signature Packet.

       Signed Message :- Signature Packet, OpenPGP Message |
    	       One-Pass Signed Message.

       In addition, decrypting a Symmetrically Encrypted Data packet and

       decompressing a Compressed Data packet must yield a valid OpenPGP
       Message.

    10.3. Detached Signatures

       Some OpenPGP applications use so-called "detached signatures." For
       example, a program bundle may contain a file, and with it a second
       file that is a detached signature of the first file. These detached
       signatures are simply a signature packet stored separately from the
       data that they are a signature of.

HTML conversion and comments on this are RFC are Copyright (c) 1998 Werner Koch, Remscheider Str. 22, 40215 Düsseldorf, Germany. Verbatim copying and distribution is permitted in any medium, provided this notice is preserved. See here for copyright information on the RFC itself.

Updated: