Re: [openpgp] Timestamping
Ben Laurie <ben@links.org> Fri, 03 May 2013 19:06 UTC
Return-Path: <benlaurie@gmail.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E0021F8EFE for <openpgp@ietfa.amsl.com>; Fri, 3 May 2013 12:06:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uH8Cy5UeMBUM for <openpgp@ietfa.amsl.com>; Fri, 3 May 2013 12:06:56 -0700 (PDT)
Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id ECDAE21F8E34 for <openpgp@ietf.org>; Fri, 3 May 2013 12:06:43 -0700 (PDT)
Received: by mail-qc0-f171.google.com with SMTP id q2so861788qch.2 for <openpgp@ietf.org>; Fri, 03 May 2013 12:06:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.49.14.102 with SMTP id o6mr16064536qec.5.1367608003097; Fri, 03 May 2013 12:06:43 -0700 (PDT)
Sender: benlaurie@gmail.com
Received: by 10.49.12.9 with HTTP; Fri, 3 May 2013 12:06:43 -0700 (PDT)
In-Reply-To: <20130503174015.GA4310@petertodd.org>
References: <20130503174015.GA4310@petertodd.org>
Date: Fri, 03 May 2013 20:06:43 +0100
X-Google-Sender-Auth: ADcdLlszqdPMPo9UnPPXa9a8QoA
Message-ID: <CAG5KPzyNQzg=hnR9X8PUGHGhhminQad4OhzjNFWCQx3zUQb1UQ@mail.gmail.com>
From: Ben Laurie <ben@links.org>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: openpgp@ietf.org
Subject: Re: [openpgp] Timestamping
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/openpgp>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 May 2013 19:07:00 -0000
You might be interested in Certificate Transparency: http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf On 3 May 2013 18:40, Peter Todd <pete@petertodd.org> wrote: > I've been working on and off on a open-source timestamping package > called OpenTimestamps (https://github.com/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]@petertodd.org > 000000000000006513af2c989a1c0530f7676c1d1b621874fcbfe3065ff7d304 > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp >
- Re: [openpgp] Timestamping Peter Todd
- [openpgp] Timestamping Peter Todd
- Re: [openpgp] Timestamping Ben Laurie
- Re: [openpgp] Timestamping Daniel A. Nagy