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