Subject: Let's finish up 0x50 "notary" signatures

From: David Shaw <[email-masked]>
Date: Wed, 29 Oct 2003 15:59:59 -0500

The current state of the 0x50 or notary signature is nearly, but not
quite, completed.  The main thing missing is a machine-readable
transport of a signature and it's notarization.

The current language in the draft is:

   0x50: Third-Party Confirmation signature.

      This signature is a signature over some other OpenPGP signature
      packet(s). It is a notary seal on the signed data. A third-party
      signature SHOULD include Signature Target subpacket(s) to give
      easy identification. Note that we really do mean SHOULD. There
      are plausible uses for this (such a a blind party that only sees
      the signature, not the key nor source document) that cannot
      include a target subpacket.

Two suggestions:

1) Do not include the unhashed data of the target signature when
   generating the notary signature.  The unhashed data is not part of
   the original signature.

2) Define a signature-in-a-subpacket where notary signatures can be
   placed.  This allows the notary signature to be attached (as an
   unhashed subpacket) to the signature that it notarizes, giving a
   simple and clean transport method.  Any number of notary signatures
   can be attached to the original signature this way (up to the limit
   on the unhashed data section), and notary signatures may be easily
   nested (notarizing a notary signature) by placing a notary
   signature in the unhashed data section of another notary signature.

   A signature-in-a-subpacket is simply a signature subpacket that
   contains another signature.  The packet headers are not included,
   but the signature is otherwise complete.

Note that one of the possible solutions to the stolen subkey problem
also involves signature-in-a-subpacket.  This is a different use of
the technique, and its use here is not relevant to the stolen subkey
problem.

David