Re: [openpgp] Timestamping

Ben Laurie <> Fri, 03 May 2013 19:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 56E0021F8EFE for <>; Fri, 3 May 2013 12:06:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uH8Cy5UeMBUM for <>; Fri, 3 May 2013 12:06:56 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c01::22b]) by (Postfix) with ESMTP id ECDAE21F8E34 for <>; Fri, 3 May 2013 12:06:43 -0700 (PDT)
Received: by with SMTP id q2so861788qch.2 for <>; Fri, 03 May 2013 12:06:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=71rO7/dHUFDXgPSMe8BCwIZq4VuC2l9epmys9ZFXBpk=; b=eeEZLU17yLfRCWCVzKLlacdXmShjtqH4crc8q82OFrQjyivIqC2iGw6M3wubKfV5Uc C57VYf2DsgEqlCGzHCmwUV53NM2FBeIS4adGFhC+ytcPeJHfWKJY5LdXq9i7jNdu+2do BX4L+CLXpMvzO+w0YaF/DS0xJhgOQcnSX7Sd091MirOsgi1S0CvWbFBxU14kGp33VTmV kWkKAFK2mfAQnWwyrjnA8idebI8a6F33FGCv8VLWpJe/I6KLOwUfqcZfS/XNFjvsXfBV lLeIAY5krDaGM3+czIsLKwqosvJTm6x9vjlniHBRAWC/vDjYWs7x7wp1dN9Aj9S0AmF6 PIng==
MIME-Version: 1.0
X-Received: by with SMTP id o6mr16064536qec.5.1367608003097; Fri, 03 May 2013 12:06:43 -0700 (PDT)
Received: by with HTTP; Fri, 3 May 2013 12:06:43 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Fri, 3 May 2013 20:06:43 +0100
X-Google-Sender-Auth: ADcdLlszqdPMPo9UnPPXa9a8QoA
Message-ID: <>
From: Ben Laurie <>
To: Peter Todd <>
Content-Type: text/plain; charset=ISO-8859-1
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: Fri, 03 May 2013 19:07:00 -0000

You might be interested in Certificate Transparency:

On 3 May 2013 18:40, Peter Todd <>; wrote:
> I've been working on and off on a open-source timestamping package
> called OpenTimestamps (
> It's based on hashing, usually by combining many digests into a merkle
> tree, with the tip digest being timestamped by some method. To date it's
> been used with the Bitcoin blockchain as the timestamping method, but
> the architecture is notary agnostic - RFC3161 support is on my TODO list
> for instance.
> The actual structure of a timestamp consists of a set of operations,
> generally hash algorithms, forming a DAG. The operations are computed,
> and provided the path from the input digest to the notarized
> timestamp(s) is valid one can prove that the data existed before the
> time. Nothing very exciting really in terms of actual crypto, but as far
> as I know my project is the first to attempt a flexible, general
> solution based on hashing that can, in principle, support a variety of
> notary methods.
> Timestamping came up on the GnuPG mailing list, and Werner Koch
> suggested I look into adding timestamps to OpenPGP signatures as
> Signature Notation Data. In short the timestamp would apply to the
> digest of the data being signed proving that it existed before some
> particular time; the timestamp would act to prove the Signature Creation
> Time field was correct, at least in one direction.(1) Timestamps on data
> is one obvious applications. Timestamping PGP keys is another, although
> actually doing so usefully is tricky.
> Lets look at data first. Signature Notation Data can either be signed or
> unsigned. A timestamp should be stand-alone - its validity must depend
> on the notary rather than the user - so there really isn't any need to
> actually sign the timestamp itself other than to say the user intended
> for it to be there.
> Another factor favoring unsigned timestamps is that with hashing-based
> timestamps they often can be extended after the fact. For instance, in
> GuardTime's implementation a timestamp is first submitted to a 'level'
> with a 1 second interval, quickly returning the timestamp. However its
> only later that the merkle tree is timestamped permanently by inclusion
> into a widely-witness newspaper ad. An unsigned timestamp allows you to
> extend your timestamp after the fact to include all the intermediary
> digests required to link it to that permanent, trustworthy record.
> Similarly timestamps from different notaries may be collected at a later
> time.
> However, timestamping signatures themselves can also be useful. If a key
> is compromised after some known date, a timestamp of a signature before
> that date can still be trusted.
> As for timestamping PGP keys in theory it can help determine
> trustworthyness by making the assumption that the earlier key is the one
> that is valid. (in addition to WOT and other evaluations) However, it is
> not as simple as just timestamping the fingerprint of the primary key,
> because an attacker can always re-use an existing key, and create new
> User ID packets and sign them; you need to sign the User ID packets as
> well. Unfortunately this isn't a very easy to understand user
> experience, and evaluating exactly what is being proven is subtle.
> Regardless all this does suggest that one timestamp packet be used for
> the whole signature allowing for multiple elements to be incorporated
> into one merkle tree within that packet to be timestamped in one go,
> saving space. In this case I think it would make most sense to either
> define a new packet type, or simply use a signature packet missing the
> actual signature. The latter doesn't really seem ideal though, for
> instance it would require a redundent signature creation time.
> Anyway, I'd appreciate some comments on my line of thought, in
> particular what people think of trade-offs between the simplicity of one
> timestamp per signature, and trying to have some sort of common
> timestamp packet containing a DAG of hash operations for all timestamped
> data, as well as the usefulness of integrating timestamping into OpenPGP
> signatures in general.
> 1) Potentially random beacons such as the Bitcon blockchain or the under
> development NIST beacon could be used to prove a signature was created
> after a given time, but a random beacon can only prove the signature,
> not the data being signed.
> --
> 'peter'[:-1]
> 000000000000006513af2c989a1c0530f7676c1d1b621874fcbfe3065ff7d304
> _______________________________________________
> openpgp mailing list