From pete@petertodd.org Fri May 3 10:43:49 2013 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; Fri, 3 May 2013 18:40:17 +0100 (BST) Date: Fri, 3 May 2013 13:40:15 -0400 From: Peter Todd 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:43:49 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. --=20 'peter'[:-1]@petertodd.org 000000000000006513af2c989a1c0530f7676c1d1b621874fcbfe3065ff7d304 --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlGD9n8ACgkQpEFN739thoybvQCgijGDe/ZKdnMc0/8glXZXxs7V 71sAn2SZ6UQUh/+XevKR5tSe4UhKey4D =iTGp -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- From benlaurie@gmail.com Fri May 3 12:06:58 2013 Return-Path: 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 ; 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 ; 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 ; Fri, 3 May 2013 12:06:43 -0700 (PDT) Received: by mail-qc0-f171.google.com 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; 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: From: Ben Laurie To: Peter Todd 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." 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: http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf On 3 May 2013 18:40, Peter Todd 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 > From pete@petertodd.org Sat May 4 11:51:15 2013 Return-Path: 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 3F23321F9677 for ; Sat, 4 May 2013 11:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 ZG9c8CJt1fJU for ; Sat, 4 May 2013 11:51:07 -0700 (PDT) Received: from outmail148111.authsmtp.net (outmail148111.authsmtp.net [62.13.148.111]) by ietfa.amsl.com (Postfix) with ESMTP id 71F0821F9675 for ; Sat, 4 May 2013 11:51:07 -0700 (PDT) Received: from mail-c233.authsmtp.com (mail-c233.authsmtp.com [62.13.128.233]) by punt8.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r44Ip5eX083465; Sat, 4 May 2013 19:51:05 +0100 (BST) Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r44IowbJ070049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 4 May 2013 19:51:00 +0100 (BST) Date: Sat, 4 May 2013 14:50:57 -0400 From: Peter Todd To: Ben Laurie Message-ID: <20130504185057.GA27568@savin> References: <20130503174015.GA4310@petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 908c89b9-b4eb-11e2-a49c-0025907707a1 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdgYUFVQNAgsB AmUbWl1eVVx7WWM7 bAxPbAVDY01GQQRq WVdMSlVNFUsqBRh4 WVlMKBl1dwVCcTB3 ZkBqEHlbVBdyfBR0 XxxQQD8bZGY1an1O VEkLagNUcgZDfhhC alcuVT1vNG8XDSUg EgkrMCgEdQleLSlO XggINVMUTi4I X-Authentic-SMTP: 61633532353630.1021:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 May 2013 18:51:21 -0000 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 03, 2013 at 08:06:43PM +0100, Ben Laurie wrote: > You might be interested in Certificate Transparency: > http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf 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... --=20 'peter'[:-1]@petertodd.org 000000000000001e37401431b5d24c5f798773655e7fe23cc6bbe3a6a871e492 --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRhViNAAoJECSBQD2l8JH7bV8IAKYWRv3oDfwBFRadKnaFhPrb 3eD7sURSaN2VksLsRGhS9kegqDGvA+99KJ8sDdyM9Kr7uuf/S0XUeVozHcrAM5PE 3tMlmSyCDYxpr8DRGFfgIgw2YkgZze6E9mZI5RKRr2oXgBCX1b8AZXSjuGR4U9UQ m29wH88vUSMk/dV+JqkJH/nif+rneX3wqLadzfaWSO/iBz4p65IcbyUdUXzROio5 X9buGGarSovo+pb8h2zGLLQjtPWnB4eQkX+63GJOxbKXuxJCyuHJQEi4zcGxHb7y nNN7S+6eWDlFAnJF8fuGyYqVU5tAzPl2PQ1sMp2gCXSmy0i2LksnsZ1h+z4UodI= =hTMF -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- From nagydani@epointsystem.org Sun May 5 13:44:35 2013 Return-Path: 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 CC95021F9757 for ; Sun, 5 May 2013 13:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 tQD-PE8lA9hT for ; Sun, 5 May 2013 13:44:35 -0700 (PDT) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C9BCA21F9756 for ; Sun, 5 May 2013 13:44:34 -0700 (PDT) Received: by mail-ea0-f173.google.com 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; d=google.com; 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 10.14.208.132 with SMTP id q4mr45321003eeo.35.1367786673348; Sun, 05 May 2013 13:44:33 -0700 (PDT) Received: from [192.168.55.151] (business-178-48-2-49.business.broadband.hu. [178.48.2.49]) by mx.google.com with ESMTPSA id f3sm10073676eep.3.2013.05.05.13.44.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 05 May 2013 13:44:32 -0700 (PDT) Message-ID: <5186C4AE.2010908@epointsystem.org> 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 To: openpgp@ietf.org References: <20130503174015.GA4310@petertodd.org> <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-BeenThere: openpgp@ietf.org 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 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB1A107CB102C0EA887D863FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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. Question: 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. Daniel 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: >> http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf >=20 > 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. >=20 > 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 ever= y > 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! >=20 > Obviously the same guarantee is useful for CA auditing, but I'm probabl= y > getting off-topic here... >=20 >=20 >=20 > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp >=20 --------------enigB1A107CB102C0EA887D863FB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGGxLQACgkQVjtq4DhBLAOBugCeLBgNKfQ603grZMd5WdzmCKD7 IOYAoMAJpMBjWhuqqk2DX7pfV48w3SFc =0yvH -----END PGP SIGNATURE----- --------------enigB1A107CB102C0EA887D863FB-- From dkg@fifthhorseman.net Tue May 7 08:11:58 2013 Return-Path: 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 3AE7421F8F33 for ; Tue, 7 May 2013 08:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 8CTPCoxrA2Om for ; Tue, 7 May 2013 08:11:53 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 87DB921F8E2C for ; Tue, 7 May 2013 08:11:53 -0700 (PDT) Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 9CFECF979; Tue, 7 May 2013 11:11:48 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 78C081FDBF; Tue, 7 May 2013 11:11:48 -0400 (EDT) From: Daniel Kahn Gillmor To: David Shaw In-Reply-To: <3C32E4F1-6B48-4561-94FF-7489D44E36CC@jabberwocky.com> References: <50E5E6AE.5050201@jcea.es> <3C32E4F1-6B48-4561-94FF-7489D44E36CC@jabberwocky.com> User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-pc-linux-gnu) Date: Tue, 07 May 2013 11:11:45 -0400 Message-ID: <87zjw6keoe.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Cc: openpgp@ietf.org Subject: Re: [openpgp] keyserver protocol X-BeenThere: openpgp@ietf.org 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: Tue, 07 May 2013 15:11:58 -0000 --=-=-= Content-Type: text/plain On Thu 2013-01-03 17:53:15 -0500, David Shaw wrote: > I actually wrote this up at one point as an informational draft, but > for one reason or another didn't finish submitting it. If there is > interest, I can clean it up and submit: > > http://tools.ietf.org/id/draft-shaw-openpgp-hkp-00.txt David, i would like to see this picked back up if possible. Is there a way that i can help? In particular, I would like to see the error signalling and semantics be more clearly and explicitly defined, so that (for example) when a keyserver has a problem the user agents (e.g. client tools like gpg --refresh) have a clear way to distinguish between cases like: 0) "I have no key material matching this name/keyid at all" 1) "I have too many keys that match this search to bother you with an insanely long list" 2) "something is broken in my database, and I'm confused" and so forth. Any thoughts on what would be reasonable next steps? Regards --dkg --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQJ8BAEBCgBmBQJRiRmxXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcTEkQAL9nrsFxzLJW3YrNrBycDH/1 /iaES0+J2gbJ1NFWgr/mxZb8eaZ7Fz63w9441PTpJWfqDjZorywBtRRQk64Fvfxl 0E3UarFqa8d9IJreg6zfKUIp+B50qcSpXWcE6eoprvY0Clxlx2CMMrSpIGDAgSN8 zN9CNuXPOl3gCgMyO8QWGzWT78lDz4LmG+K8N3AdeUwcpBbo4Zyyc4QF1bKzoHT9 Ml1Owd+1yc5qEI6dXAJLOQo0e8NjznAXIDrWad4BJGFBWfVHa9SlHBNFm0CpckNq mw8Da7I3kTan/qwGUMfmHcUR7Onzp9NgWELjaUMAWbrp+XGBAHmtvpyeGcQRqxr0 NJkQi4+0mxGRz/DsHD3BxKpoGr6Uo/l/tbmYCcUB4FPTOzGLYVbcIxywhWvkhHuy m2IMvshjZ365ughPfnHkTj+NVZ3CufO9f0S0dCqWptG0qOLFdrG/ZQmiKgtV4OzG XzY1+7QkJWXXdsJh8hQN1m1hjkAPZHvrwcm5hnMMzp5Uxm9mYt/sxtAxh0sBNVVa j6jwvdTJuXlIJCMRozp7c4ZIIVkajpu5ndbf3GXOpyfZAhvj+iu1qPQMdI+scuwc ZnQzMb6jhx9KMa8ACVSptdYWC3eATl8eF/h9ZNacRe7wTxI3vbpFWCEBCrblEcAA qDmoIvaLIIPAhx5BHBZm =A/hz -----END PGP SIGNATURE----- --=-=-=-- From nagydani@epointsystem.org Tue May 7 08:44:52 2013 Return-Path: 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 1932A21F8F53 for ; Tue, 7 May 2013 08:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 5UKhWpbXC6YD for ; Tue, 7 May 2013 08:44:47 -0700 (PDT) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by ietfa.amsl.com (Postfix) with ESMTP id EDA7C21F8F26 for ; Tue, 7 May 2013 08:44:43 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id b57so403711eek.19 for ; Tue, 07 May 2013 08:44:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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=HBeKWL+a06YeCVCdXCKv3dJdPVViQOerq/r64jkf6Cs=; b=VA7JY9QUd2GSKoyJk/EHJ56jsdOA3oQ89OcbmTpucbhQnHQesOnAKO1WHrMzdyGEvV KKdKND7gjjINtAorAlKyMR55N5HHEw6Ox3qj4EGzT3hORkPYx99aWaGFVHy5pI4O8w41 Gp4Hddbwvoay4pLT+6wRBBWJVlKTJB5p1ImcBslYOY9tTVHcyGN6JfX71IjbZp/LzVMn htSHaXWfs0f19kEIUDLJKRXbaERCuzpcqm08CBCkCZz86fQ3jFwWpvqV3ehdwnOHKN/+ 8r1R7CR62cooMxZvBfQz9nvtHbO6q2rdN12ZYiJxVWx+MZqB6GJvUlhL7nrFGJvAHOWu uASQ== X-Received: by 10.14.172.197 with SMTP id t45mr6475447eel.37.1367941482971; Tue, 07 May 2013 08:44:42 -0700 (PDT) Received: from [192.168.1.225] (catv-178-48-114-85.catv.broadband.hu. [178.48.114.85]) by mx.google.com with ESMTPSA id x41sm31420789eey.17.2013.05.07.08.44.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 May 2013 08:44:41 -0700 (PDT) Message-ID: <51892168.3080703@epointsystem.org> Date: Tue, 07 May 2013 17:44:40 +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 To: openpgp@ietf.org References: <50E5E6AE.5050201@jcea.es> <3C32E4F1-6B48-4561-94FF-7489D44E36CC@jabberwocky.com> <87zjw6keoe.fsf@alice.fifthhorseman.net> In-Reply-To: <87zjw6keoe.fsf@alice.fifthhorseman.net> X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEE546F3FC1C5CAE64F6D2BA1" X-Gm-Message-State: ALoCoQk9lZrgHyUAv7QEsifF8xeiVexDwTE2Go/3eQLetpM+1BvaBXx6wcWdzLXkJf3buGD3HXzg Subject: Re: [openpgp] keyserver protocol X-BeenThere: openpgp@ietf.org 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: Tue, 07 May 2013 15:44:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEE546F3FC1C5CAE64F6D2BA1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 05/07/2013 05:11 PM, Daniel Kahn Gillmor wrote: > On Thu 2013-01-03 17:53:15 -0500, David Shaw wrote: >=20 >> I actually wrote this up at one point as an informational draft, but >> for one reason or another didn't finish submitting it. If there is >> interest, I can clean it up and submit: >> >> http://tools.ietf.org/id/draft-shaw-openpgp-hkp-00.txt >=20 > David, i would like to see this picked back up if possible. Is there a= > way that i can help? >=20 > In particular, I would like to see the error signalling and semantics b= e > more clearly and explicitly defined, so that (for example) when a > keyserver has a problem the user agents (e.g. client tools like gpg > --refresh) have a clear way to distinguish between cases like: >=20 > 0) "I have no key material matching this name/keyid at all" >=20 > 1) "I have too many keys that match this search to bother you with an > insanely long list" >=20 > 2) "something is broken in my database, and I'm confused" Also, I think that it makes sense to explicitly allow for partial implementations of the protocol. For example, one that only allows for searching by keyID's or even just long keyID's and fingerprints. I think, there should be a clear way to communicate that the use of an unsupported part of the protocol has been attempted. Bests, Daniel --------------enigEE546F3FC1C5CAE64F6D2BA1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlGJIWcACgkQVjtq4DhBLAOfDACdHHoS0OtKnIV5uQIazg8Wuuab Mg8AnRjV6qlrV9uKUfIMFYPN8joUrGiv =25VV -----END PGP SIGNATURE----- --------------enigEE546F3FC1C5CAE64F6D2BA1-- From JPClizbe@tx.rr.com Tue May 7 21:02:36 2013 Return-Path: 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 EE2E021F8AE2 for ; Tue, 7 May 2013 21:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_82=0.6] 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 HlPXIBMT+PZy for ; Tue, 7 May 2013 21:02:33 -0700 (PDT) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by ietfa.amsl.com (Postfix) with ESMTP id D799A21F8B38 for ; Tue, 7 May 2013 21:02:32 -0700 (PDT) X-Authority-Analysis: v=2.0 cv=JqNzXbEC c=1 sm=0 a=ulbKWX+3DyaA8G8Ha9A3Bw==:17 a=ehAo5EXnqZIA:10 a=XqBCkJwx3yUA:10 a=05ChyHeVI94A:10 a=M0ekKXdxTI4A:10 a=IkcTkHD0fZMA:10 a=ayC55rCoAAAA:8 a=48vgC7mUAAAA:8 a=hvCv-v4cZ4kA:10 a=69wJf7TsAAAA:8 a=q34bkTyjAAAA:8 a=pGLkceISAAAA:8 a=jFpR5k_0AAAA:8 a=QfKxxUxMAAAA:8 a=QZHjU0VWhBe4lku4iAIA:9 a=QEXdDO2ut3YA:10 a=22Nk3EchLcgA:10 a=a9n_x6BPe_4A:10 a=0QJAjy8SXTUA:10 a=hB6TBpPrBZUA:10 a=MSl-tDqOz04A:10 a=AoHxI1HT9TUA:10 a=Sat1diPe-X4v6ftc:21 a=kugy_II1io-qu3kb:21 a=ulbKWX+3DyaA8G8Ha9A3Bw==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 173.175.198.28 Received: from [173.175.198.28] ([173.175.198.28:55107] helo=[192.168.1.18]) by cdptpa-oedge02.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id F0/FB-16585-65EC9815; Wed, 08 May 2013 04:02:31 +0000 Message-ID: <5189CE51.3050208@tx.rr.com> Date: Tue, 07 May 2013 23:02:25 -0500 From: John Clizbe Organization: GingerBear Conspiracy Theories To Go User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17.1 MIME-Version: 1.0 To: openpgp@ietf.org References: <50E5E6AE.5050201@jcea.es> <3C32E4F1-6B48-4561-94FF-7489D44E36CC@jabberwocky.com> <87zjw6keoe.fsf@alice.fifthhorseman.net> In-Reply-To: <87zjw6keoe.fsf@alice.fifthhorseman.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [openpgp] keyserver protocol X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: openpgp@ietf.org List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 04:02:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Daniel Kahn Gillmor wrote: > On Thu 2013-01-03 17:53:15 -0500, David Shaw wrote: > >> I actually wrote this up at one point as an informational draft, but >> for one reason or another didn't finish submitting it. If there is >> interest, I can clean it up and submit: >> >> http://tools.ietf.org/id/draft-shaw-openpgp-hkp-00.txt > > David, i would like to see this picked back up if possible. Is there a > way that i can help? > > In particular, I would like to see the error signalling and semantics be > more clearly and explicitly defined, so that (for example) when a > keyserver has a problem the user agents (e.g. client tools like gpg > --refresh) have a clear way to distinguish between cases like: > > 0) "I have no key material matching this name/keyid at all" > > 1) "I have too many keys that match this search to bother you with an > insanely long list" You /must/ mean documenting how those two are already implemented? X-HKP-Results-Count: number of matching keys Content-Length: number of bytes in resulting keys - From the SKS CHANGELOG(+) and Mercurial commit log(+>): + 1.1.4 + - Fix X-HKP-Results-Count so that limit=0 returns no results, but include + the header, to let client poll for how many results exist, without + retrieving any. Submitted by Phil Pennock. See: + http://lists.nongnu.org/archive/html/sks-devel/2010-11/msg00015.html +> changeset: 115:47835fd59b63 +> parent: 113:73ba20267254 +> user: Phil Pennock +> date: Sat Apr 21 18:24:46 2012 -0500 +> files: dbserver.ml key.ml request.ml wserver.ml +> description: +> Limit fix for limit=0 +> Return real status text strings, rather than confusing "500 OK". +> Handle No_results as an exception type, giving 404 instead of 500. +> Treat limit of -1 (or <0) as "unlimited". +> Handle limit=0 so that can ask for number of results without getting results. +> +> From email submission: +> Back when X-HKP-Results-Count: was discussed, David Shaw suggested that +> limit=0 should return no results, but include the header, to let a +> client poll for how many results exist, without retrieving any. See: +> http://lists.nongnu.org/archive/html/sks-devel/2010-11/msg00015.html +> +> Please find attached a patch. Plus a couple of related cleanups in HTTP error +> response handling. + 1.1.2: + - Johan van Selst's patch implementing Phil Pennock's suggestion + of an X-HKP-Results-Count: header to returned web server queries + - Johan van Selst's patch to add Content-length header to web results +> changeset: 49:68f88ae59b6a +> user: John Clizbe +> date: Thu Nov 04 02:37:31 2010 -0500 +> files: dbserver.ml request.ml wserver.ml +> description: +> Johan van Selst's patch implementing Phil Pennock's suggestion +> of an X-KHP-Results-Count: header to returned web server queries +> +> http://lists.nongnu.org/archive/html/sks-devel/2010-11/msg00016.html +> +> changeset: 48:e6d918ac4c66 +> user: John Clizbe +> date: Wed Nov 03 21:58:51 2010 -0500 +> files: wserver.ml +> description: +> Johan van Selst's patch to add Content-length header to web results +> +> http://lists.nongnu.org/archive/html/sks-devel/2010-11/msg00005.html > 2) "something is broken in my database, and I'm confused" Could you /maybe just possibly/ tie this down to something like a real error condition instead of something so ambiguous? Taking a look at lines 245-307 of wserver.ml may be helpful. - -John PS: Dan, please DO NOT CC me on replies to the list. - -- John P. Clizbe Inet: John (a) Gingerbear DAWT net SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys@gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" - -- John P. Clizbe Inet: JPClizbe(a)comcast DOT nyet Golden Bear Networks PGP/GPG KeyID: 0x608D2A10 "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl! Comment: Be part of the £33† ECHELON -- Use Strong Encryption. Comment: It's YOUR right - for the time being. Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iF4EAREIAAYFAlGJzkoACgkQ614Z89ZWmCU5YgD/ePoiYfnYBStLptdHxLnF5CUc z/Kuq0R8pZpgNuGPVXcA+wW5gNXtO+YAJqkG2z2C9lx+nC3YWNWVCHXNeXmNMIv4 =y7Pw -----END PGP SIGNATURE----- From dkg@fifthhorseman.net Tue May 7 21:32:46 2013 Return-Path: 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 9780321F8E62 for ; Tue, 7 May 2013 21:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_82=0.6] 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 cSkB8lT7AdlT for ; Tue, 7 May 2013 21:32:42 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id D77ED21F8E2C for ; Tue, 7 May 2013 21:32:41 -0700 (PDT) Received: from [192.168.13.156] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 54330F979 for ; Wed, 8 May 2013 00:32:40 -0400 (EDT) Message-ID: <5189D564.4000604@fifthhorseman.net> Date: Wed, 08 May 2013 00:32:36 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130413 Icedove/17.0.5 MIME-Version: 1.0 To: openpgp@ietf.org References: <50E5E6AE.5050201@jcea.es> <3C32E4F1-6B48-4561-94FF-7489D44E36CC@jabberwocky.com> <87zjw6keoe.fsf@alice.fifthhorseman.net> <5189CE51.3050208@tx.rr.com> In-Reply-To: <5189CE51.3050208@tx.rr.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2QTCAAXGGIMIFEGPWWJAJ" Subject: Re: [openpgp] keyserver protocol X-BeenThere: openpgp@ietf.org 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: Wed, 08 May 2013 04:32:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2QTCAAXGGIMIFEGPWWJAJ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for these details, John. This is exactly the sort of thing that i wanted to start getting fleshed out. On 05/08/2013 12:02 AM, John Clizbe wrote: > Daniel Kahn Gillmor wrote: >> 0) "I have no key material matching this name/keyid at all" >=20 >> 1) "I have too many keys that match this search to bother you with an = >> insanely long list" >=20 > You /must/ mean documenting how those two are already implemented? well, this is how they're implemented in SKS, which is the defacto reference implementation, for sure. so yes, documenting this in the only public spec of the HKP protocol would be good. > X-HKP-Results-Count: number of matching keys This header (i think you're implying that it is an HTTP response header) doesn't seem to be used at all in GnuPG if i'm searching git://git.gnupg.org/gnupg.git properly. I know there are other HKP client implementations but (like sks on the server side) gnupg is a sort of defacto reference implementation. If it's not making use of this header, then it probably needs to be better documented and patches pushed to gpg. What should a responsible client do or assume if this header is absent from an HKP response? How should a responsible client respond if X-HKP-Results-Count is greater than the limit query parameter? for that matter, limit itself doesn't seem to be documented in draft-shaw-openpgp-hkp-00. This seems like another detail worth including in any update. looking in dbserver.ml, i don't see any corresponding offset=3D query parameter. so= if X-HKP-Results-Count =3D=3D limit + 2, if an HKP client wants to get th= e last two that were beyond the limit, they have to re-fetch the whole list of keys. Is that right? >> 2) "something is broken in my database, and I'm confused" >=20 > Could you /maybe just possibly/ tie this down to something like a real = error > condition instead of something so ambiguous? Taking a look at lines 24= 5-307 > of wserver.ml may be helpful. I'm thinking here of the protocol from the perspective of an HKP client; i don't think a client should need to know the gory details of how any particular HKP server is implemented in order to be able to interact with it robustly. While we may decide that there are certain error cases that are common enough (or dangerous enough) to call them out specifically in the protocol spec, it seems simplest to start by specifying a general error code that we expect to be interpreted as "Server broken, please try again later or try someone else" (perhaps this is HTTP's "500 Internal Server Error"). It would also be useful to provide guidance for how we expect a responsible HKP client to respond to that error state. For those of us who run sks or other keyservers behind reverse proxies, there may also be system errors that come into play at the proxy level. So having an explicit understanding of what sorts of errors HKP clients expect to see and how they should handle them would help to inform best practices for reverse proxy configuration. It might turn out that these answers are all very simple. that's great! in that case, let's document them explicitly, and then we can set about testing the various HKP clients and reverse proxies to ensure that they behave reasonably in the face of the expected range of responses. Regards, --dkg ------enig2QTCAAXGGIMIFEGPWWJAJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJRidVkXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcsTQQANt99u94w5kxXRNrZSJlvf+D zdZum5U+viIlTMWGSU/KoRhIDq53UUSaPFfZHAro1FKAc9HkPaTiR7qUxi03cpZ2 OVNcQ01h6hv7hgnY+FrJiqf8yvdzzV5RF5tHVOSb6+ZwfVM0XoSUcba7HQw65+rz b6cPwfubMnThHQeGTL9xjXqqQEPtL2YQFB2xLOLNC5PfsIFm4kpM0+f3r7S+RVsH B9yp+VO/XkA5mo2zQOVMgMgq3CfdYWuS/XdNsMNl2W9H4EzWhlhV6deoZZhOs/0g xjENQAxBjleitHJ8PSeAkmmWgj9hF8+SSDAclDJUUfsBhRFCjDOlZpJc+/AerM6F iyvpkclyJ0EmZdFalcZA9RSNrSn056rt9VCEHAlcfKEAu1yn26myXQMoO/DfptNX oC+1hhQ6biPTWTdFgr2A2fipMXxP/qcWaOD/QKrwmSR1Xt+6Da5vB7gtww9Rpodo eHtBqj3GPYdBydu/RZSMPEJPEuFWX38XzlvfF44GAa+F1V/IQiIU27rknAo340Fp zXBIymd6oJU6VFgAsL+eKk4iR3nsIQCpukkleKmr5F3sg26UIhy90cQ45kPVZc4E YOQ189EtWU7+Zb/T5hf7txeiL/0GbsPd65guE1G4ZyrwPFUKsn9rrHtiU6tcZ7vO tosVOHej65sv4B3WJfqH =Qvox -----END PGP SIGNATURE----- ------enig2QTCAAXGGIMIFEGPWWJAJ-- From JPClizbe@tx.rr.com Wed May 8 05:25:50 2013 Return-Path: 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 53F4621F8E98 for ; Wed, 8 May 2013 05:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, J_CHICKENPOX_51=0.6] 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 UPJOopHSBWI7 for ; Wed, 8 May 2013 05:25:44 -0700 (PDT) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF7121F8E84 for ; Wed, 8 May 2013 05:25:41 -0700 (PDT) X-Authority-Analysis: v=2.0 cv=cYNQXw/M c=1 sm=0 a=ulbKWX+3DyaA8G8Ha9A3Bw==:17 a=ehAo5EXnqZIA:10 a=XqBCkJwx3yUA:10 a=05ChyHeVI94A:10 a=M0ekKXdxTI4A:10 a=ayC55rCoAAAA:8 a=48vgC7mUAAAA:8 a=hvCv-v4cZ4kA:10 a=GwUem0DFAAAA:8 a=69wJf7TsAAAA:8 a=jFpR5k_0AAAA:8 a=5ZAm5Rvu49jaItqNxMUA:9 a=QEXdDO2ut3YA:10 a=AoHxI1HT9TUA:10 a=OtjhUDtStarv06SK:21 a=YZSYIv5btM9ZXAsH:21 a=QfKxxUxMAAAA:8 a=UXUmiDrv6FKpzWzVWkcA:9 a=ulbKWX+3DyaA8G8Ha9A3Bw==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 173.175.198.28 Received: from [173.175.198.28] ([173.175.198.28:51794] helo=[192.168.1.18]) by cdptpa-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 0B/70-11869-2444A815; Wed, 08 May 2013 12:25:39 +0000 Message-ID: <518A4423.6050904@tx.rr.com> Date: Wed, 08 May 2013 07:25:07 -0500 From: John Clizbe Organization: GingerBear Conspiracy Theories To Go User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17.1 MIME-Version: 1.0 To: openpgp@ietf.org References: <50E5E6AE.5050201@jcea.es> <3C32E4F1-6B48-4561-94FF-7489D44E36CC@jabberwocky.com> <87zjw6keoe.fsf@alice.fifthhorseman.net> <5189CE51.3050208@tx.rr.com> <5189D564.4000604@fifthhorseman.net> In-Reply-To: <5189D564.4000604@fifthhorseman.net> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2PQRFTFVVLVPMQMWXALJC" Subject: Re: [openpgp] keyserver protocol X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: openpgp@ietf.org List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 12:25:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2PQRFTFVVLVPMQMWXALJC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Daniel Kahn Gillmor wrote: > Thanks for these details, John. This is exactly the sort of thing that= > i wanted to start getting fleshed out. >=20 > On 05/08/2013 12:02 AM, John Clizbe wrote: >> Daniel Kahn Gillmor wrote: >>> 0) "I have no key material matching this name/keyid at all" >>=20 >>> 1) "I have too many keys that match this search to bother you with an= =20 >>> insanely long list" >>=20 >> You /must/ mean documenting how those two are already implemented? >=20 > well, this is how they're implemented in SKS, which is the defacto > reference implementation, for sure. so yes, documenting this in the > only public spec of the HKP protocol would be good. Casey Marshall is well along in his implementation, Hockeypuck, which if = I understood correctly, is implementing HKP with the behavior of SKS. He is= implementing the reconciliation process of SKS as well. He has implemente= d them in Go. >> X-HKP-Results-Count: number of matching keys >=20 > This header (i think you're implying that it is an HTTP response header= ) > doesn't seem to be used at all in GnuPG if i'm searching > git://git.gnupg.org/gnupg.git properly. >=20 > I know there are other HKP client implementations but (like sks on the > server side) gnupg is a sort of defacto reference implementation. If > it's not making use of this header, then it probably needs to be better= > documented and patches pushed to gpg. Yes, it's a HTTP header, returned since 1.1.2. See this thread for more details about why it exists: [Sks-devel] SKS, Content-Length and HEAD req= uests [https://lists.nongnu.org/archive/html/sks-devel/2010-11/threads.html#000= 00 ] This may be getting a bit SKS-centric for the OpenPGP list. --=20 John P. Clizbe Inet: John (a) Gingerbear DAWT net SKS/Enigmail/PGP-EKP or: John ( @ ) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys@gingerbear.net?subject=3DHELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" ------enig2PQRFTFVVLVPMQMWXALJC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl! Comment: Be part of the £33† ECHELON -- Use Strong Encryption. Comment: It's YOUR right - for the time being. Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iF4EAREIAAYFAlGKRDsACgkQ614Z89ZWmCWw6wD6AofxzpOzv8Gy4CZGZYcPpMsx c3/rA3z1FtWT7gEgs4UA+gNWrQtArIhnWL+FFqF+PHKAvz1lRufpZIFuCix/K9OA =PmYx -----END PGP SIGNATURE----- ------enig2PQRFTFVVLVPMQMWXALJC--