[openpgp] Timestamping
Peter Todd <pete@petertodd.org> Fri, 03 May 2013 17:43 UTC
Return-Path: <pete@petertodd.org>
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 914EE21F8233 for <openpgp@ietfa.amsl.com>; Fri, 3 May 2013 10:43:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level:
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-1]
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 n7YtuQOdowz7 for <openpgp@ietfa.amsl.com>; Fri, 3 May 2013 10:43:44 -0700 (PDT)
Received: from outmail148110.authsmtp.com (outmail148110.authsmtp.com [62.13.148.110]) by ietfa.amsl.com (Postfix) with ESMTP id E1A7B21F8201 for <openpgp@ietf.org>; Fri, 3 May 2013 10:40:23 -0700 (PDT)
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt7.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r43HeIwm044980 for <openpgp@ietf.org>; Fri, 3 May 2013 18:40:18 +0100 (BST)
Received: from petertodd.org (petertodd.org [174.129.28.249]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r43HeFt6059137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <openpgp@ietf.org>; Fri, 3 May 2013 18:40:17 +0100 (BST)
Date: Fri, 03 May 2013 13:40:15 -0400
From: Peter Todd <pete@petertodd.org>
To: openpgp@ietf.org
Message-ID: <20130503174015.GA4310@petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 84fd25dc-b418-11e2-b5c5-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKhNXJkIGTSxQ P1pUaF1JP0tEHhZ8 Ui8UWVRVU01wUWlx awBQaktcZU5QXgdj TkpBXFBWHRptCRse B1BcVhoKInMCfn51 bEdhWT5aXEd5cQh1 RhgAF2hSNnoybGEX TUFZIgFJIgYZewJF alJ6XXNcYGBTN30u Iw42MistNDBHKSJa KgAA
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 174.129.28.249/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system.
Subject: [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 17:43:49 -0000
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
- Re: [openpgp] Timestamping Peter Todd
- [openpgp] Timestamping Peter Todd
- Re: [openpgp] Timestamping Ben Laurie
- Re: [openpgp] Timestamping Daniel A. Nagy