Re: Timestamp and 3rd party sig

nagydani@epointsystem.org (Daniel A. Nagy) Sun, 16 July 2006 19:03 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Bu9-0007d8-VB for openpgp-archive@lists.ietf.org; Sun, 16 Jul 2006 15:03:49 -0400
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2Bu7-0005pa-Ia for openpgp-archive@lists.ietf.org; Sun, 16 Jul 2006 15:03:49 -0400
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6GIcnNv026601; Sun, 16 Jul 2006 11:38:49 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k6GIcn6E026600; Sun, 16 Jul 2006 11:38:49 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6GIclsr026567 for <ietf-openpgp@imc.org>; Sun, 16 Jul 2006 11:38:47 -0700 (MST) (envelope-from nagydani@epointsystem.org)
Received: by mail.epointsystem.org (Postfix, from userid 1001) id 71B0E17FD; Sun, 16 Jul 2006 20:38:41 +0200 (CEST)
Date: Sun, 16 Jul 2006 20:38:41 +0200
To: ietf-openpgp@imc.org
Cc: klao@cs.elte.hu
Subject: Re: Timestamp and 3rd party sig
Message-ID: <20060716183840.GB4342@epointsystem.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK"
Content-Disposition: inline
User-Agent: Mutt/1.5.9i
From: nagydani@epointsystem.org (Daniel A. Nagy)
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36

In his message on Feb 17, 2005
http://www.imc.org/ietf-openpgp/mail-archive/msg09179.html
Rick van Rein raised two important questions only one of which has been
addressed (by W. Koch). Rick proposed changes to the definiton of timestamp
signatures (sig type 0x40) which have been neither rejected nor accepted. In
fact, they have not even been discussed.

I would suggest to revisit his suggestion as it clarifies the correct use of
this potentially very useful signature type. I do agree with explicitly
stating the purpose of the signature as in all other cases:

    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.

While I see the wording of the additional paragraph a bit clumsy and perhaps
overly specific, some explanation about the calculation of the signature
would be helpful. Before proceeding with that, however, I would like to ask
if there are any implementations that constrain how such signatures should
be constructed and verified?

Another question that arises in the context of timestamps whether it is
worth defining another type (say, 0x41) for timestamping canonical text
documents analogously to the distinction between 0x00 and 0x01? My personal
opinion is that it is definitely worth doing. Thus, I would propose the
following wording:

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

    0x41: Timestamp signature of a canonical text document.
        The intention of this signature is to accurately record the time
        at which the timestampe text was seen by the timestamp-signing
        party. The signature is calculated over the text data with its
        line endings converted to <CR><LF>.

Since I am currently implementing an OpenPGP compliant timestamping service,
I would like to solicit opinions on the issue even without suggesting
immediate changes to the standard. In particular, I would like to know how
various implementations treat 0x40 signatures when encountering them during
signature verification?

Thank you in advance,

-- 
Daniel A. Nagy