Subject: Whither the 0x40 timestamp signature?

From: David Shaw <[email-masked]>
Date: Mon, 19 Apr 2004 20:49:20 -0400

When we defined the 0x50 notary signature, the old 0x40 from 1991 was
the insipration for it.  0x40 was defined in 1991 as more or less what
the 0x50 sig is defined for today.  Now we have both the 0x40 and
0x50, and the 0x40 seems rather underdefined to me.

For starters, there are no hashing rules specified for it, so how do
you make one?  Since both the 0x40 and 0x50 get a target subpacket,
one could infer that they are similar, but there is nothing concrete.

I'm not necessarily requesting that 0x40 be fleshed out and clarified:
I'd be just as content to see it dropped.  If, as I assume, the 0x40
is just the same as the 0x50 with a different (human) interpretation,
then perhaps we should just drop it.  If people want to assign human
interpretations to their signatures, let them use notations.

David

---

From: Jon Callas <[email-masked]>
Date: Mon, 19 Apr 2004 21:19:18 -0700

> interpretations to their signatures, let them use notations.

As I remember, it stays there for the same reason that some other 
seldom-to-never-used
signature types are there: for backwards compatibility with their never 
being used. They are there for the same reason there is old stuff in my 
garage -- we hope to use it someday.

I'm not sure spring cleaning is warranted, but it's easy enough, if 
people think so.

	Jon

---

From: Ian Grigg <[email-masked]>
Date: Tue, 20 Apr 2004 07:54:28 -0400

> I'm not sure spring cleaning is warranted, but it's easy enough, if 

If it can be marked with a SHOULD NOT use / deprecated
then that would be good.  More spring cleaning is better.
OpenPGP's incessant algorithmic messiness slows its migration.

(a general comment, not specific.  for clarification I
have no clue as to the particular number.)

iang

---

From: David Shaw <[email-masked]>
Date: Tue, 20 Apr 2004 11:10:28 -0400

> I'm not sure spring cleaning is warranted, but it's easy enough, if 

I'm not sure about spring cleaning, either.  Underspecified parts of
the standard trouble me, however.  They can't be implemented, and they
aren't marked "for future use" either.

The 0x40 signature was mentioned in 1991 as a signature over a
signature, but no information was given on how to actually make one.
2440 redefined the 0x40 as a "timestamp signature", but still no
information was given on how to make one, and it was no longer stated
to be a signature over a signature.

The 2440bis drafts add a little hint in that 0x40 gets a signature
target, which only makes sense if 0x40 has a signature as at least
part of its input.

I'll defer to the feeling of the WG on whether to drop or not.
However, if are going to keep 0x40 in the standard, we should at least
say how to make one or explicitly mark it for future use.

If the intent is that 0x40 is in fact a signature over a signature
(and nothing else), then a simple fix is to change section 5.2.1,
which currently says:

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

Change to read:

    0x40: Timestamp signature.
        This signature is a signature over some other OpenPGP
	signature packet(s).  It is only meaningful for the timestamp
	contained in it.

I'm not advocating that outcome.  I'm equally content to see it
defined, marked for future use, or dropped.

David

---

From: Jon Callas <[email-masked]>
Date: Wed, 21 Apr 2004 13:07:15 -0700

It's really easy to remove this. Ian has a good reason to remove it. 
I'll take Ian and David proposing removing it, as 0x50 has more 
function and is better defined. Does anyone object strongly? Anyone, 
anyone?

	Jon

---

From: Lutz Donnerhacke <[email-masked]>
Date: Thu, 22 Apr 2004 08:23:19 +0000 (UTC)

> defined, marked for future use, or dropped.

I do have an application for this type of signature without providing the
full meaning of notary (0x50) signatures.

There is a full blown enviroment which requires timestamping at users end
without involving a real notary timestamping service. The German signature
law contains a protocol error in proofing signatures of withdrawn keys. The
only sound solution requires an additional timestamp of every signature. The
law assumes that the sender is responsible for providing the timestamp.

A simple (non notary) timestamp to be included consists of two values:
  - name of the timestamping service
  - value of the timestamp

Those values can be included in three ways:
  a) Defining (one or two) notation data packets to optionally include such
     a timestamp in every signature packet.
  b) Defining a 0x40 signature as hashing the refered signature, and both
     fields.
  c) Defining a 0x40 signature as hashing the refered signature and include
     the notation data packets from version a.

Variant a seems the most interesting one. Variant c extents this variant to
the possibility of timestamping a signature later (by an other person).

So I'd vote for defining a signature subpackets or two notation data
subpackets for providing (non notary) timestamping pruposes, and defining
the 0x40 signature type to as a hash over the whole signature subpacket
(followed by the normal signature process). It's recommented to include the
timestamp subpackets into every 0x40 signature.

Should I provide detailed description, or should we remove the whole part?

---

From: Ian Grigg <[email-masked]>
Date: Thu, 22 Apr 2004 08:13:07 -0400

> full meaning of notary (0x50) signatures.

When you say "I do have ..." are you saying that this
is in existence, or that you are proposing this as a
potential future use of 0x40 sigs?

[description of App elided]

> Should I provide detailed description, or should we remove the whole part?

There are three reasons against your suggestion.

One, that you seem to be defining a new app for an
apparently unused but similar feature.  If it is only
a similar application, then we'd want to show that
there are no extant uses of the allocated 0x40 code,
etc, so that we don't end up with any confusion.

(It's relatively ok for implementations to be confused,
but the standard should not be...)

(I guess it would be fine to *document* the prior use
of the feature, from code.)

Secondly, even if you could show that the old number
was out of use, I'd still suggest formatting a new
application with new bits and bobs, new meanings,
and new text.  Unless we are running out of bits in
some obscure sense, I think it's better to leave old
uses to die, and allocate new codes to new purposes,
even if close.

Thirdly (as I mooted in a prior post) I think we should
be seriously considering putting the RFC process into
feature freeze.  So if there is anything *new* about
this, such as a meaning, or an app still to be written,
then I'd say the onus would be on the proposer to
carefully make the case that this should go forward.

E.g., once in feature freeze, we should switch attention
to chopping deprecated and other dead-wood out there, and
to fixing grammer and spelling and whatnot, and thinking
about how it is that the darn thing gets finished.

iang

---

From: Lutz Donnerhacke <[email-masked]>
Date: Thu, 22 Apr 2004 14:14:33 +0000 (UTC)

* Ian Grigg wrote:
> Lutz Donnerhacke wrote:
>> I do have an application for this type of signature without providing
>> the full meaning of notary (0x50) signatures.
>

Only a potential future use. I'd only show a real world need for such things.

> uses to die, and allocate new codes to new purposes,

Ok. Remove it.

> feature freeze.

Ack.

---

From: Florian Weimer <[email-masked]>
Date: Sat, 24 Apr 2004 11:48:06 +0200

> law assumes that the sender is responsible for providing the timestamp.

SigG/SigV conformance of OpenPGP applications is not going to happen
(and is not even desirable IMHO).

RFC 2440bis should simply state that there are a few flags for which
future RFCs may specify semantics.  Consensus on this list seems to be
that RFC 2440bis should remain a format spec, and signature semantics
would clearly be beyond its scope.

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: atlas.cz, bigpond.com, postino.it, tiscali.co.uk,
tiscali.cz, tiscali.it, voila.fr.