Timestamp and 3rd party sig

[Rick van Rein <[e-mail]>]

Hello,

Dare I suggest a rephrasing of the 0x40 and 0x50 definitions?

   0x40: Timestamp signature.
       This signature is only meaningful for the timestamp contained in
       it.

This can be read as if the document signed and the signing key don't matter.
The point of a timestamp is a matter of emphasising what its intention is,
but not much more.

A topic open for debate would be whether it may be assumed that "extra" or
"sufficient" effort has been taken to guard and/or synchronise the time
encapsulated.  In line with the intention of 0x10..0x13 I left this out
in the text that follows, to avoid pinning down something that is open
to debate.

I therefore propose either this text...

   0x40: Timestamp signature.
	The intention of this signature is to accurately record the time
	at which the timestamped data was seen by the timestamp-signing
	party.

...then I tried to add a definition of what was being timestamped...

	If the timestamped data is an OpenPGP signature, it MUST
	be referenced with a Signature Target [or Signature Reference,
	see below] subpacket. In all other cases, the timestamped data MUST
	be constructed as a normal signature on data.

This is much clearer to an implementer, I think.
-> Is the distinction between sig-on-sig and sig-on-data desirable?
-> The MUSTs are intended to avoid multiple formats which mean the same.
-> Given this definition, should one use 0x40 or 0x50 to confirm revocations?


Another issue:

   0x50: Third-Party Confirmation signature.
       This signature is a signature over some other OpenPGP signature
       packet(s). It is analogous to 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 as a blind
       party that only sees the signature, not the key nor source
       document) that cannot include a target subpacket.

The term 'notary seal' is a bit confusing because the strength and
implications of such seals differ strongly between countries.

Since the Signature Target subpacket(s) are hashes, they convey the
signature subpacket that is being signed -- is that not sufficient for
blind signing purposes?  If the signature target is not provided, what
would then be the subpackets determining what is being confirmed?

The term Third Party is used a lot for key escrow parties.  Is it an idea
to rename this to an "Independent Confirmation signature"?


In 5.2.3.25, the definition of "Signature Target" is not very accurate.
Notably, it is not very strict about the contents being hashed.  Also,
I (as a non-native English speaker) am tempted to call it a "Signature
Reference".   Dare I rephrase?


CURRENT:

5.2.3.25. Signature Target

   (1 octet PK algorithm, 1 octet hash algorithm, N octets hash)

   This subpacket identifies a specific target signature that a
   signature refers to. For revocation signatures, this subpacket
   provides explicit designation of which signature is being revoked.
   For a third-party or timestamp signature, this designates what
   signature is signed. All arguments are an identifier of that target
   signature.

   The N octets of hash data MUST be the size of the hash of the
   signature. For example, a target signature with a SHA-1 hash MUST
   have 20 octets of hash data.



PROPOSED:

5.2.3.25. Signature Reference

   (1 octet PK algorithm, 1 octet hash algorithm, N octets hash)

   This subpacket refers to a Signature Packet without including the
   Signature Packet inside the Signature Reference subpacket.  Instead,
   the hash of the Signature Packet is included.  When used in a
   revocation signature, this subpacket refers to the signature being
   revoked.  For a Independent/Third-Party Confirmation signatures and
   Timestamp signatures, this subpacket refers to the signature that
   is being confirmed or timestamped.

   The signature that is referenced by this subpacket may or may not
   be present in the same OpenPGP message; a signing party may even
   be totally unaware of the referenced Signature Packet, in which
   case the signature with this subpacket would be a blind signature.

   The N octets of hash data MUST be the size of the hash of the
   signature. For example, a target signature with a SHA-1 hash MUST
   have 20 octets of hash data.



Thanks,

Rick van Rein,
OpenFortress.