New feature for GPG

[Dmitri]

On Tue, 2002-11-05 at 09:08, Noel D. Torres Taño wrote:

> I'm thinking in a new GPG feature. I call it Timestamping.
> I know that signing data makes a timestamp in them. But that kind of
> timestamps can be denied only by saying "I recognize the signer, but he
> altered his computer clock while signing this."

The timestamping server must have known-good clock. How would you do
that? Some currently existing servers (as Michael mentioned) derive
strength from numbers - by publishing timestamps they allow many eyes to
see their deeds. Tampering with a large number of adjacent timestamps
would be inconvenient and easier to trace.

But the problem of trust still remains. It is possible to wrongly
timestamp something, especially intentionally. Basically, the question
is "do you trust the server?" - and I do not trust most of servers that
are out there. I will trust my lawyer, though - I know him, I have live
witnesses, each reads the timestamp and gets a copy. Hard to fake that.

> To avoid this scenery, I propose a new feature: remote timestamping. The
> same way you can take a paper, go to the nearest post office and ask the
> official to timestamp your paper, to have an official timestamping of
> your paper, I propose for GPG the possibility of sending data to a
> TIMESTAMPING SERVER, better if it is an official computer providing that
> service.

"official" ? Who will run it?

> The Timestamping server will work simply by signing the received data
> and sending it back to the submitter. But this will be not a simple
> signature, but will have a difference I'll explain later.
> The reason if that, if you SIGN some data, you can be considered legally
> responsible of that data. At least to some extent.

Let them sign a ciphertext. They will envelope it in their own signature
without knowing what is inside. Thus, they can't be held responsible.
The time of signing will be embedded into the signature as usual. It can
be a detached signature as well, thus allowing multiple parallel
timestamps without altering the message block as such.

There is no need for new options. If anything, you need a MUA, or some
pigeons if nothing else works :-)

> WHY to timestamp in a not-exactly-the-same way than signing:
> Because if you sign something, you are respinsible of that, but if you
> timestamp something, you are responsible only for the timestamping.
> 
> About sending unencrypted data to timestamp:
> Data will never be sent to the timestamp server in clear. How to do this
> is expalined in the remote timestamping protocol below.

If the data is encrypted, then where is the problem with responsibility?

>  12.- Server will decrypt data with it's own private key, timestamp it
> with `gpg --timestamp --encrypt -r userpublickey bufferwithdata` and
> send it to user's GPG

Why would a timestamping server need to decrypt the data? My lawyer will
be glad to timestamp a sealed envelope. What he does not know can't hurt
him.

Your proposed protocols are really complicated, and I haven't had much
time to look at them. But the questions that I already asked are quite
obvious, and they invalidate the very need for those protocols.

Also, by sticking with TCP you lose a whole bunch of other
connectivities (such as offline sneaker-net, which may be necessary if
you don't have an Internet link in some village in Africa). Traditional
timestamping does not have online requirements, and may be more secure
than your Internet link.

> I want to code all of this, but I have not enough C knowledge to do it.
> I can, anyway, run a timestamp server (maybe the first) at an official
> place in Spain, in my university.

The principles of the design must be validated before you write even a
single line of code.

Thanks,
Dmitri

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : /pipermail/attachments/20021106/e76fabdc/attachment.bin