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: