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, 3 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
>