OpenPGP Message Format

http://tools.ietf.org/html/rfc4880

 

 

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 SHOULD accept V3 signatures.  Implementations SHOULD
   generate V4 signatures.

   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
   indicated in a signature type octet in any given signature.  Please
   note that the vagueness of these meanings is not a flaw, but a
   feature of the system.  Because OpenPGP places final authority for
   validity upon the receiver of a signature, it may be that one
   signer's casual act might be more rigorous than some other
   authority's positive act.  See Section 5.2.4, "Computing Signatures",
   for detailed information on how to compute and verify signatures of
   each type.

   These meanings are as follows:

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

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

   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.

5.4.  One-Pass Signature Packets (Tag 4)

   The One-Pass Signature packet precedes the signed data and contains
   enough information to allow the receiver to begin calculating any
   hashes needed to verify the signature.  It allows the Signature
   packet to be placed at the end of the message, so that the signer
   can compute the entire signed message in one pass.

   A One-Pass Signature does not interoperate with PGP 2.6.x or
   earlier.



Callas, et al               Standards Track                    [Page 39]

 
RFC 4880                 OpenPGP Message Format            November 2007


   The body of this packet consists of:

     - A one-octet version number.  The current version is 3.

     - A one-octet signature type.  Signature types are described in
       Section 5.2.1.

     - A one-octet number describing the hash algorithm used.

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

     - An eight-octet number holding the Key ID of the signing key.

     - A one-octet number holding a flag showing whether the signature
       is nested.  A zero value indicates that the next packet is
       another One-Pass Signature packet that describes another
       signature to be applied to the same message data.

   Note that if a message contains more than one one-pass signature,
   then the Signature packets bracket the message; that is, the first
   Signature packet after the message corresponds to the last one-pass
   packet and the final Signature packet corresponds to the first
   one-pass packet.

 

7.  Cleartext Signature Framework

   It is desirable to be able to sign a textual octet stream without
   ASCII armoring the stream itself, so the signed text is still
   readable without special software.  In order to bind a signature to
   such a cleartext, this framework is used.  (Note that this framework
   is not intended to be reversible.  RFC 3156 [RFC3156] defines another
   way to sign cleartext messages for environments that support MIME.)





Callas, et al               Standards Track                    [Page 59]

 
RFC 4880                 OpenPGP Message Format            November 2007


   The cleartext signed message consists of:

     - The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a
       single line,

     - One or more "Hash" Armor Headers,

     - Exactly one empty line not included into the message digest,

     - The dash-escaped cleartext that is included into the message
       digest,

     - The ASCII armored signature(s) including the '-----BEGIN PGP
       SIGNATURE-----' Armor Header and Armor Tail Lines.

   If the "Hash" Armor Header is given, the specified message digest
   algorithm(s) are used for the signature.  If there are no such
   headers, MD5 is used.  If MD5 is the only hash used, then an
   implementation MAY omit this header for improved V2.x compatibility.
   If more than one message digest is used in the signature, the "Hash"
   armor header contains a comma-delimited list of used message digests.

   Current message digest names are described below with the algorithm
   IDs.

   An implementation SHOULD add a line break after the cleartext, but
   MAY omit it if the cleartext ends with a line break.  This is for
   visual clarity.