Subject: Signature types

From: [email-masked] (Daniel A. Nagy)
Date: Sat, 27 Aug 2005 09:50:18 +0200

I am wondering if I understand the following correctly:

0x40 Timestamp signature.

It is calculated directly on any document like a 0x00 signature (BTW, it
would probably makes sense to introduce a 0x41 timestamp for textual
documents), but the issuer of the signature does not claim authorship or
endorse the document, just states the fact that the document existed at the
time when the signature was issued.

This one I do not understand at all:

0x50 Third-Party Confirmation signature.

What is the signature calculated on? The document? The certified signature?
Both?

My guess would be that it is calculated on te document and includes in
one (or more) subpackets the canonical hash of the certified signature(s).
In this case the notary certifies the fact that the signatures are valid at
the time of issuing this signature.

But in this case a blind notary that certifies only the fact that the
signature has been made before the time of issuing the singature should use
standalone (0x02) signatures with a target signature subpacket. There is
absolutely no point in 0x50 signatures without target signature subpackets
in this setting, but I might have misunderstood something.

Thanks in advance for the clarification.

-- 
Daniel

---

From: Ian G <[email-masked]>
Date: Sat, 27 Aug 2005 10:25:07 +0100

Daniel A. Nagy wrote:
 > ... [some stuff]

On that section, but not on Daniel's question, it occurs to
me that the caveat found half way down ("Please note that
the vagueness...") could be usefully expanded to cover all
of 5.2.1.

Something like:

5.2.1. Signature Types

   There are a number of possible meanings for a signature.
   By convention, OpenPGP suggests meanings by the following
   signature type octets in any given signature.

   Please note that the vagueness of these signature claims
   is not a flaw, but a feature of the system.  Cryptographic
   signing technology alone cannot make these claims true,
   and a relying party would need to examine the intentions
   of any signer, and the wider context of the system and
   environment in order to assess any claims.  OpenPGP places
   final authority and responsibility on the receiver of any
   signature.

   0x01:...

Which then allows a simplification of the post-0x13 comment:

   0x13:...

     Please note that one authority's casual certification
     might be more rigorous than some other authority's
     positive certification. These classifications allow a
     certification authority to issue fine-grained claims.

     Most OpenPGP implementations make their "key signatures" as 0x10
     certifications. Some implementations can issue 0x11-0x13
     certifications, but few differentiate between the types.

As an alternate, such general commentary could append to the
end of the section - but in legal terms, if it is a warning
as to limitations, it should be at the front.  Given the
somewhat poisoned waters of digital signatures, I'd prefer
to see the disclaims before any claims.

iang

PS: are we in final call already?

---

From: David Shaw <[email-masked]>
Date: Sat, 27 Aug 2005 09:55:52 -0400

> time when the signature was issued.

Signature over a signature, just like 0x50.  It's not exactly made
clear in section 5.2.1, but note that it gets a signature target
subpacket.  That only makes sense if it is a signature over a
signature.  Note that 0x40 actually existed in rfc-1991 as well (also
a signature over a signature).

> What is the signature calculated on? The document? The certified signature?

The signature.  I thought this one was pretty clear (from 5.2.1):

        This signature is a signature over some other OpenPGP
	signature packet(s). It is analogous to a notary seal on the
	signed data.

David

---

From: [email-masked] (Daniel A. Nagy)
Date: Sat, 27 Aug 2005 17:26:46 +0200

> subpacket.  That only makes sense if it is a signature over a

If the signature target subpacket is in the hashed part of the signature, it
makes perfect sense with signatures on the document as well, as it binds
the document to the signature (e.g. a party that has access only to the
notary's public key can be assured that it is a valid signature on the
document, provided that the notatry is trusted).

> Note that 0x40 actually existed in rfc-1991 as well (also

It's actually RFC1991 that got me wondering:

     <40> - time stamping ("I saw this document") (*)
  ...                                          Type <40> is intended to
  be a signature of a signature, as a notary seal on a signed document.

Now, this is contradictory. If a signature does not have any cryptograpic
binding (except the indirect one through the other signature) to the
document, it cannot be used to assert the integrity thereof.

Someone with the public key of the notary cannot verify this claim. Also, it
makes a lot of sense to certify documents that have not been signed. Since
there are no implementations of 0x40 signatures (to my knowledge) it is
worth giving it a thought. A timestamp signature on (possibly unsigned)
documents that can, if required, bind signatures to it is immensely useful

> 	signature packet(s). It is analogous to a notary seal on the

Except that if it's a signature on the signature, then it cannot be
analogous to a notary seal on the signed data (see above). Yet, a signature
over a signature is also useful, as it can be issued by a blind notary that
doesn't see the document. Also, it does prove to someone with access to all
public keys the integrity of the document.

In sum, if 0x40 would be a timestamp signature on the document while 0x50 a
timestamp signature on the signature, it would make perfect sense, making
both of them useful and not redundant at all. This won't contradict the
wording of RFC2440, while RFC1991 contradicts itself, so being consistent
with that one is hopeless to begin with.

-- 
Daniel

---

From: [email-masked] (Daniel A. Nagy)
Date: Sat, 27 Aug 2005 17:34:25 +0200

> the vagueness...") could be usefully expanded to cover all

What the claim of the signature is can be indeed very vague, but what kind
of objects are hashed to verify the signature should be unambiguous in the
standard.

I still maintain that there is a very legitimate need for a timestamp
signature on any kind of data that has no meaning beyond the timestamp.

A signature on a signature is also useful (for different purposes), but it
cannot have the same signature type as the above signature, because the
objects that they sign are different.

Using 0x40 (and possibly 0x41) for the first purpose and 0x50 for the second
seems logical and in line with RFC2440.

-- 
Daniel