Subject: Notary signatures

From: David Shaw <[email-masked]>
Date: Thu, 25 Apr 2002 18:07:04 -0400

RFC-1991 defined sigclass 0x40 as a timestamp, and went on to further
explain its intended use ("Type <40> is intended to be a signature of
a signature, as a notary seal on a signed document.")

When RFC-2440 came out, this extra explanation seems to have been
lost, as 2440 defines 0x40 only as a timestamp.  A sigclass for a
signature on a signature would be very useful.  Any chance to restore
this clarification in the next draft?

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

---

From: Len Sassaman <[email-masked]>
Date: Thu, 25 Apr 2002 16:22:00 -0700 (PDT)

> this clarification in the next draft?

Yes, please. I plan to use this in a project in the not-so-distant future.

I know there are a few timestamping services for OpenPGP in operation
already -- are any of them using this now?

--Len.

---

From: Jon Callas <[email-masked]>
Date: Thu, 25 Apr 2002 16:49:46 -0700

> this clarification in the next draft?

It wasn't so much that it was lost, but that it was actively removed.

Only the document and certification signatures were ever implemented before
2440 came out. At one time, we removed all the definitions to simplify. Then
they gradually crept back in. 0x40 became a timestamp because there were
people who wanted to use it.

I may be wrong on this, but would it be better to introduce a new type if
you want to do notaries? Or do this with a notation?

    Jon

---

From: David Shaw <[email-masked]>
Date: Thu, 25 Apr 2002 20:05:27 -0400

> you want to do notaries? Or do this with a notation?

As I see it, all signatures can have a timestamp, so really any of
them is usable for a timestamp signature.  I'm not sure how 0x40
differs here, as it doesn't seem clear what 0x40 is a signature on.
If it is on binary data, then we have a type for that already.  If it
is on textual data, we have a type for that as well.  We even have a
type for a standalone signature-on-nothing "token".

A notary signature does not have to be class 0x40, but since 0x40 was
intended for this in the past, and (as far as I can see) does not
serve a purpose that other signature types cannot already provide, why
not make it 0x40?

David

---

From: Jon Callas <[email-masked]>
Date: Thu, 25 Apr 2002 17:27:37 -0700

> serve a purpose that other signature types cannot already provide, why

0x40 was added in as a timestamp signature after the unused types were all
removed. As I remember, Lutz Donnerhacke was going to be using it, and I
think other people are as well.

I'm not going to overload timestamps with notary signatures. That's a bad
idea. If we decide to put notary signatures back in, they'll get a new
number. RFC 1991 was only ever informational, and is dead as far as we're
concerned. (And no one ever implemented that.) 0x50 is a fine number.

So -- what are you going to do with them? Why do you need it? I'd like to
move towards getting a new RFC soon, so explain what you want, and lets get
a rough consensus of the group that it's a good idea. If we get that, I'll
put it in.

    Jon

---

From: Len Sassaman <[email-masked]>
Date: Thu, 25 Apr 2002 17:54:21 -0700 (PDT)

> a rough consensus of the group that it's a good idea. If we get that, I'll

I'd like to be able to run a service wherein a user submits a signed
document, and the service signs the signature. This is done to allow for
verification that the signature was made prior to the timestamp provided
by my service (the trusted notary).

--Len.

---

From: Jon Callas <[email-masked]>
Date: Thu, 25 Apr 2002 17:58:35 -0700

Here's what I believe timestamp signatures are for --

The hard problem in digital signatures is knowing what they mean. The
semantic content of the signature. Lots of ink has been spilled on this.

The 0x40 timestamp signature is a semantic notation. What it says is "I saw
this blob of data at time T. I know nothing more nor assert nothing other
than I saw it at that time."

It is thus a way for an entity to do nothing but -- well, timestamp it.

    Jon

---

From: Jon Callas <[email-masked]>
Date: Thu, 25 Apr 2002 18:02:10 -0700

> by my service (the trusted notary).

Not the document, only the signature packet? I'm trying to envision what one
would do with this mechanically, as well as syntactically and semantically.

    Jon

---

From: David Shaw <[email-masked]>
Date: Thu, 25 Apr 2002 21:08:50 -0400

> a rough consensus of the group that it's a good idea. If we get that, I'll

Well, I'll let Len speak for what he is planning, but for me, it's
come up a number of times in the context of timestamping services.
There is no way to really trust the timestamp in a signature since the
maker of the signature can use whatever timestamp that suits them.  A
notary service can "guarantee" that signature by signing the
signature, and multiple independent notary services can be used to add
even more assurance that there is no collusion.  I have heard that
this was the intended use of the old notary signature.

Using a different type (0x50 is fine) for this is not strictly
required, but would be very useful on the validation side to know that
when you come across such a packet you are going to be looking for
another signature to check against it.

David

---

From: David Shaw <[email-masked]>
Date: Thu, 25 Apr 2002 21:18:53 -0400

> It is thus a way for an entity to do nothing but -- well, timestamp it.

A regular 0x00 or 0x01 signature has no defined meaning, so it can
therefore mean anything the signer and recepient agree on it to mean.
The 0x40 is just like these signatures except that it is has the
defined meaning of "timestamp". ?  Ok, I get it.  I imagine this is
something that if done today would be done with a signature notation.

Is it possible to get some language in the draft saying what an 0x40
signature is issued on (binary or canonical text data)?

David

---

From: Jon Callas <[email-masked]>
Date: Thu, 25 Apr 2002 18:55:19 -0700

> therefore mean anything the signer and recepient agree on it to mean.

Or what a litigant can convince a judge or jury that any reasonable person
would have thought it to mean. That's the downside of no defined meaning in
a world where there are laws about what signatures mean.

> signature is issued on (binary or canonical text data)?

All signatures are on binary content. A text-mode signature is on binary
content that conforms to some rules. Or so I think. :-)

    Jon

---

From: Derek Atkins <[email-masked]>
Date: 25 Apr 2002 23:21:43 -0400

> would do with this mechanically, as well as syntactically and semantically.

Yes.  The notary verifies the signature, and then signs the
_signature_, not the document.  This is why it's a signature on a
signature.  The notary is trusted to have verified the contents before
it actually creates the new signature.

Note that you still cannot change the document, because to change the
document you would need to change the signature (unless you break the
Hash function).  If you change the signature, then the notary
signature fails.  Therefore, transitively, the notary is verifying
the document.

At least, this was the theory we had when wrtiing 1991.

>     Jon

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: David Shaw <[email-masked]>
Date: Fri, 26 Apr 2002 00:16:47 -0400

On Thu, Apr 25, 2002 at 11:21:43PM -0400, Derek Atkins wrote:
> > Not the document, only the signature packet? I'm trying to
> > envision what one would do with this mechanically, as well as
> > syntactically and semantically.
> 

This is interesting, as I had been thinking of a service that did not
verify the contents of the original document before notarizing the
signature.  This service would purely be to validate the timestamp
(and other data) in the original signature, so no need to send the
original document which may be sensitive.

In notary talk (at least US notary talk), this is somewhat similar to
what is called an "acknowledgement"[1] - the notary taking note that a
document was signed, and affixing a seal to indicate that.  Nothing in
the actual document is relevant in an acknowledgement - just that it
was signed and the signer requested a notary to note that fact.

> signature fails.  Therefore, transitively, the notary is verifying

Yes.

David

[1] Not an exact match - an acknowledgement generally also has the
    statement that the signature was a voluntary act by the signer.
    I don't think there is an algorithm for that. :)

---

From: Jon Callas <[email-masked]>
Date: Thu, 25 Apr 2002 22:31:00 -0700

I like the idea of a notary signature that only signs a signature packet.
This would mean your signer doesn't even need to see the document that's
being notarized, which has a certain panache to it.

How about if I do this:

* Write up a description of a notary signature.

* Change the "revocation target" subpacket to be a "signature target"
subpacket so it can work double duty

How's that sound?

    Jon

---

From: Len Sassaman <[email-masked]>
Date: Thu, 25 Apr 2002 23:53:02 -0700 (PDT)

> subpacket so it can work double duty

Sounds great to me. Would work perfectly for what I want to do.

--Len.

---

From: Werner Koch <[email-masked]>
Date: Fri, 26 Apr 2002 10:42:27 +0200

> being notarized, which has a certain panache to it.

I like this. 

> subpacket so it can work double duty

Make it mandatory (SHOULD) for timestamp signatures so that already
existing 0x40 signature packets can be distinguished (or ignored) from
the new well defined timestamp/notary signatures.  I don't think there
is a reason to add a special 0x50 notary signature then.

  Werner

---

From: David Shaw <[email-masked]>
Date: Fri, 26 Apr 2002 07:18:52 -0400

> subpacket so it can work double duty

Excellent.  That would work quite well for me.

David

---

From: Derek Atkins <[email-masked]>
Date: 26 Apr 2002 09:33:39 -0400

> original document which may be sensitive.

Well, there are certainly multiple services available.  You are
correct that validating the signature is not a requirement.

> being notarized, which has a certain panache to it.

*smiles*

> subpacket so it can work double duty

Sounds good to me.

-derek

---

From: Bill Frantz <[email-masked]>
Date: Fri, 26 Apr 2002 08:46:08 -0400

>it actually creates the new signature.

The notary doesn't need to verify the original signature.  Operationally,
the notary doesn't need to ever see the document, only the signature on the
document.  This lack of "need to know" seems to me to be an advantage for
confidential documents.

>signature fails.  Therefore, transitively, the notary is verifying

Which is what happens if the original signature doesn't match the document.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz           | The principal effect of| Periwinkle -- Consulting
(408)356-8506         | DMCA/CBDTPA is to      | 16345 Englewood Ave.
[email-masked] | prevent fair use.      | Los Gatos, CA 95032, USA

---

From: Jon Callas <[email-masked]>
Date: Sun, 28 Apr 2002 16:52:22 -0700

>> signature fails.  Therefore, transitively, the notary is verifying

I actually disagree with this. The notary is putting a signature on a chunk
of data. The signature means, "I saw this at time T." If that data, a
signature, verifies against a document, *we* may deduce certain things about
that document using the two signatures. But the notary says nothing about
the integrity of the document.

This is a subtle point, but one about the semantics of transitivity.

If Alice says, "A -> B" and Bob says "B -> C", then I might (modulo many
details) deduce that A -> C using both data from Alice and Bob.

However, this is something that *I* am doing, not something Alice nor Bob is
doing. Alice says nothing about C. Bob says nothing about A. I put them both
together. Not Alice, not Bob.

    Jon