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

From: [email-masked]
Date: Tue, 28 Oct 2003 22:15:48 +0000

>> how about just putting the 0x50 signature as an unhashed
>> subpacket on the signature that that the 0x50 signature covers?

My concern was over the ability to form an "explicitly notarized
message." I'd prefer to distinguish a notarized document (meaning
"that document whose signatures are collectively notarized") as such
rather than determine the degree of notarized-ness using signature
subpackets. But I think it's just a question of focus: When will the
notarization of signatures deserve more attention (or priority in
computation) than the signatures themselves? I'm imagining something
like:

  10,000 people sign a petition and a notary declares that these
  signatures were made prior to some deadline.

- The notarization is (should be) inseperable from the signature list.
- Hierarchical notarizations need target only the last notary packet.

Where this special consideration is not deserved I agree that a more
general mechanism (like signatures-in-subpackets) should be applied.

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

As I understand the mechanics of the signature-in-a-subpacket:

Since a notarization of a [target] signature signs the target's packet
body (irrespective of hashed or unhashed portions), the
notarization-in-a-subpacket will (once settled) effectively sign
everything around itself and must be removed from the packet body
string before it can be verified (signatures-in-subpackets used for
subkey bindings don't have this feature because the subpacketed
signature did not target its own parent).

If this is correct and multiple notarizations of a given target body
do not happen sequentially using the same (evolving) target body
string, then verification will require figuring out the state of the
unhashed subpackets at the time the notarization in question was made
- a trial and error loop over each permutation.

Just wondering if this was to be taken in stride or if I've made a
mistake.

Mahalo for your suggestion,
tha Poiboy

PS. Off topic, out of scope, and by the way, it'd be nice to use 'v5'
sigs which operate on whole packets no matter what, allowing one-pass
notarizations to sign an unbroken string of target signature packets
and simplifying 5.2.4. And I should add that my suggestion depends
upon the 0x50 definition in 5.2.1 decscribing signatures on "signature
packet(s)." Get rid of the '(s)' and wonders will cease. :)

---

From: David Shaw <[email-masked]>
Date: Tue, 28 Oct 2003 17:44:00 -0500

On Tue, Oct 28, 2003 at 10:15:48PM +0000, [email-masked] wrote:

> Since a notarization of a [target] signature signs the target's
> packet body (irrespective of hashed or unhashed portions), the

I had expected that a notarization would not include any of the
unhashed data from the original signature.  After all, that data is
not part of the original signature.  Looking at the problem with this
in mind, the notary signature doesn't have to be removed before
verification since (being located in the unhashed section of the
original signature), it isn't really there in the first place.

> - a trial and error loop over each permutation.

Using the methodology above, multiple notarizations of a given target
body all have the same target body.

David