Subject: 3rd-party Signatures in a One-Pass Signed Message

From: [email-masked]
Date: Fri, 3 Oct 2003 18:41:29 +0000

Hello all,

My assumption: A 3rd-party signature (0x50) is/must be detached and
its handling is implementation-specific.

* 10.2 does not recognize a sequence of signature packets as a valid
  message, and 5.2.1 states that the 3rd-party signature is made over
  such a sequence.
* See Mr. Shaw's previous posts (including example sigs, below).

I'd like to work with 3rd-party signatures in a bona-fide (standard,
accepted) message context. This is handled in one case..

 Put the signed key sequence in a literal data packet. This buys
 message-parsing convenience at the expense of requiring a literal
 parser to sneak a peek at the "data that is not to be further
 interpreted." (5.9)

..and could be handled in at least a couple other ways:

 Accept single (standalone/detached) signature packets as a third type
 of Signed Message :- Signature Packet | Signature Packet, OpenPGP
 Message | One-Pass Signed Message. I don't like this because there
 are a number of signatures (0x10-13, 0x18, ..) which really don't
 make sense on their own and I don't think that message definitions
 should start digging into packet body attributes (in this case, the
 signature type).

 -or-

 Add an option to the One-Pass "nested" flag which means "this
 signature is applied to the signatures on the same level
 as the next."
 
The nested flag ('n') is only defined for n=0, leaving other n values
up to the imagination. In practice, the signature directly bordering
the signed message is given n=1 ..effectively stating "this next thing
is in my signed nest." I'd like to use an n=2 (n=x, whatever) option
declaring "this next thing is in my signed /signature/ nest" - a
statement which remains true for all one-pass signatures up to (and
including) the one-pass packet with n=1:

 1PASS_N(n=2), 1PASS_A(n=0), 1PASS_B(n=1), MSG, SIG_B, SIG_A, SIG_N

A and B have independently signed MSG, and N signs the combination
SIG_B + SIG_A. The 3rd-party signature needs only the signature
sequence (SIG_B, SIG_A) at creation time *but can later be
represented* in what amounts to a complete message "history."

This method has an "explicit advantage" over hiding signature
sequences in literal packets.

Thoughts? Kudos? Tomatoes?

Aloha,
poiboy at safe-mail.net

ref: http://www.imc.org/ietf-openpgp/mail-archive/msg04135.html
     http://www.imc.org/ietf-openpgp/mail-archive/msg04385.html

---

From: David Shaw <[email-masked]>
Date: Tue, 21 Oct 2003 13:49:31 -0400

> its handling is implementation-specific.

It is true there is currently no language in the draft specifying how
a 0x50 3rd-party or notary signature is handled, but I worry about the
complexity of the proposed solution (extending the onepass
functionality).

When I suggested using a signature-in-a-subpacket to handle the need
for a back-signature from a signing subkey to a main key, I mentioned
that this basic idea could be useful in other places.  0x50 signatures
seem to be a good place to use it: rather than extending onepass or
parsing literal packets (which violate the idea of a *literal*
packet), how about just putting the 0x50 signature as an unhashed
subpacket on the signature that that the 0x50 signature covers?

This gives a good bit of flexibility - it's clear which signature is
being "notarized", and you can trivially generate notary sigs of
notary sigs of notary sigs as many levels as you care to, AND it
shouldn't affect any currently deployed code.

David