Re: [openpgp] Timestamping

"Daniel A. Nagy" <> Sun, 05 May 2013 20:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC95021F9757 for <>; Sun, 5 May 2013 13:44:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tQD-PE8lA9hT for <>; Sun, 5 May 2013 13:44:35 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4013:c01::22d]) by (Postfix) with ESMTP id C9BCA21F9756 for <>; Sun, 5 May 2013 13:44:34 -0700 (PDT)
Received: by with SMTP id d10so1407767eaj.4 for <>; Sun, 05 May 2013 13:44:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:x-enigmail-version :content-type:x-gm-message-state; bh=Q5EQYgiilc6prxOkLWmhgFRBmnEaquKF6kAm58qsGfo=; b=HBfmiApFOKhdjgMA51WiyWNjoCouq2j2UJVvjRd2M/bp+UctyWaOlJ+/ljFs8Hm99o VhyfOS20fG08wQoIg01J2Tptvf/CTwhZNL45BAH749F+di8Cn/jXLbzEyNyEL1wfx3lR ye8GbdlUC6eFyIbQDcrhEh/WSukjOCU1UKjD7pvPRfw+smQA2pP2FIWwZLNGvucpsqya XUU1Wn8ifqn+LzdOqCdR3LbNfJiPwrHHBxWDF6oYWlK2ur5IiAHID17kb3VIh+sdwjYe pTtLwuQcRWtksjSvVM1T3OQaY1Fc0FQFF/uwwzDgp7nPV0H9Kpgf99e44NqviFi7jmTa AQxg==
X-Received: by with SMTP id q4mr45321003eeo.35.1367786673348; Sun, 05 May 2013 13:44:33 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id f3sm10073676eep.3.2013. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 05 May 2013 13:44:32 -0700 (PDT)
Message-ID: <>
Date: Sun, 05 May 2013 22:44:30 +0200
From: "Daniel A. Nagy" <>
Organization: ePoint Systems Ltd.
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130330 Thunderbird/17.0.5
MIME-Version: 1.0
References: <> <> <20130504185057.GA27568@savin>
In-Reply-To: <20130504185057.GA27568@savin>
X-Enigmail-Version: 1.4.6
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB1A107CB102C0EA887D863FB"
X-Gm-Message-State: ALoCoQkvV/6WPs5At9SqQpSXPlq/CeA4rx1io4ujMzfP2x/Q6YpTIsNMeuSVuCQJY9rXHKNGTDB+
Subject: Re: [openpgp] Timestamping
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 05 May 2013 20:44:35 -0000

Speaking of timestamps.

There is this feature in OpenPGP (RFC4880, section 5.2.1) called a
standalone signature that is calculated only on its own packet data. It
is, as I understand, useful for including (or referencing by hash) in
newer documents thereby proving (evidencing) that they are NEWER than
the standalone sig, provided that the maker of these standalone sigs can
be trusted to put correct timestamps into them. By contrast, timestamp
sigs prove (well, evidence) that the document is OLDER than the sig.


Is there any OpenPGP implementation that creates and correctly
interprets such signatures?

I am asking, because GnuPG 1.4.11 seems not to handle them the way I
think it should. I created a script that creates signatures on an empty
binary document, which verify fine with gpg, but if I change the
signature type to standalone sig, gpg complains. This might be a gpg
issue, but I would like to see a working reference implementation.

In general, I think the new standard (or a separate RFC) should include
test vectors (example data) for all packet and subpacket types discussed
in the standard to remove ambiguity.


On 05/04/2013 08:50 PM, Peter Todd wrote:
> On Fri, May 03, 2013 at 08:06:43PM +0100, Ben Laurie wrote:
>> You might be interested in Certificate Transparency:
> I think I've read that paper before actually, or perhaps the EFF's
> version, but yes, CA transparency schemes are interesting to me and I
> think they too could benefit from timestamping as an additional source
> of auditing.
> Bitcoin in particular I find interesting because it's the first
> trustworthy *decentralized* timestamping scheme to be created. Its
> timestamps aren't particularly accurate - Bitcoin has a rule where every
> node accepts blocks with a timestamp less than 2 hours ahead of what it
> believes the time is - but they can be used in conjunction with other
> centralized timestamping schemes to give the guarantee that if the
> timestamp was faked, it was at least done so in the past!
> Obviously the same guarantee is useful for CA auditing, but I'm probably
> getting off-topic here...
> _______________________________________________
> openpgp mailing list