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

From: [email-masked]
Date: Thu, 30 Oct 2003 06:07:32 +0000

Casting a vote from the cheap seats, I think signatures-in-subpackets
are an elegant option for 3rd-party signatures on single signatures.
I suggest inserting the following (or something similar) to 5.2.4:

> When a signature over a V4 signature is issued as a subpacket, the
> body of hash data consists of the same data that the (parent) V4
> signature used to build its own hash, that is, the parent's version,
> type, public key algorithm, hash algorithm, and hashed subpacket
> material (length header and subpackets).

and changing the beginning of the existing signature-on-a-signature
paragraph in the same section to make it clear that different rules
apply to "sub-signatures":

< When a signature is made over a signature, the hash data.. 
---
> When a signature is issued over a signature packet, the hash data..

Rounding out thoughts on 0x50,

Removing the canonical header replacement for external signing of
signatures would make it easier to work with many notarized
signatures. This probably steps on toes, though.

The ability to construct nice (10.2) messages using multiple/nested
0x50 signatures on fixed signature data (I suggest adding
functionality to the one-pass packet 'nest') would allow complete
expression of 0x50 signatures per 5.2.1 (as opposed to keeping them
detached or on a per-signature basis in subpackets). Additionally, I
think the "signed and notarized document" deserves the same degree of
clout (that only a bona fide message has) as a normal "signed
document."

Happy days, 
poiboy

---

From: David Shaw <[email-masked]>
Date: Thu, 30 Oct 2003 10:41:30 -0500

> signatures. This probably steps on toes, though.

I wouldn't remove the canonical header for hashing the original
signature.  It would be inconsistent with all of the other hashing
rules in the draft.  The only thing that is necessary here is to
specify that the unhashed data in the original signature is not
included in the notary signature.

Specifically, section 5.2.4 currently says:

  When a signature is made over a signature, the hash data starts with
  the octet 0x88, followed by the four-octet length of the signature,
  and then the body of the signature packet.  (Note that this is an
  old-style packet header for a signature packet with the
  length-of-length set to zero).

I would add a sentence between those two that reads something like:

   The unhashed subpacket data of the signature packet being hashed is
   not included in the hash, and the unhashed subpacket data length
   value is set to zero.

The idea here is that the canonical form of a signature to be hashed
has no unhashed subpacket data.

This addresses your first comment as well.  We don't need to specify
what gets hashed into the notary signature, since it is clear that the
entire target signature, minus its unhashed data, is hashed for the
notary signature.

David