Re: [openpgp] New fingerprint: to v5 or not to v5
Peter Gutmann <pgut001@cs.auckland.ac.nz> Mon, 05 October 2015 10:27 UTC
Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41FD51A1AE8 for <openpgp@ietfa.amsl.com>; Mon, 5 Oct 2015 03:27:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 237QeH10UWGh for <openpgp@ietfa.amsl.com>; Mon, 5 Oct 2015 03:27:14 -0700 (PDT)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18B011A1AE6 for <openpgp@ietf.org>; Mon, 5 Oct 2015 03:27:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1444040834; x=1475576834; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UaIVofnXiLr4LnXmrboUQwPGjEy4NQMtdN818BMuimU=; b=OYHt4/S3zkmUzEyDLrZ/qS89RRuCiRqaf2ueusrm6N+6IcgEMQk4wne6 IBv8LnNlfIekljLKCZzPwXGTmCb4olR9HgJiNZ73BitjN5padGFyCXaxj XHShRlA+xF3GzvOv+BKd9lu3/nCJWkgA0+M2D+hSyj5A6L5fusHvaxvEa P7cTSpGJxEP0B29YL3vyGyJNEqud4ru3gx1eKBDEG9aDppNFbMXvov1mc 3vqwxYtXZq4GQdBS4jRmu+7oboZkC0Wv0X+2fdi768mwfGVblHls1XD3L KxXdTeXyZkyeSNpMz8ocyzrNRgZOhmDVYmOJFttsqmoDaxuDKASEe+hXb w==;
X-IronPort-AV: E=Sophos;i="5.17,638,1437393600"; d="scan'208";a="46467965"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 05 Oct 2015 23:27:03 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Mon, 5 Oct 2015 23:27:02 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Werner Koch <wk@gnupg.org>, Phillip Hallam-Baker <phill@hallambaker.com>
Thread-Topic: [openpgp] New fingerprint: to v5 or not to v5
Thread-Index: AQHQ8XkqGRFnZAPwNU68Rcs3/4z3Np5TD6qAgAGZmFyAAc3ZgIADWg0AgAHwMP2AAQuhlw==
Date: Mon, 05 Oct 2015 10:27:02 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B278ED@uxcn10-5.UoA.auckland.ac.nz>
References: <878u84zy4r.fsf@vigenere.g10code.de> <87fv1xxe5w.fsf@alice.fifthhorseman.net> <87r3lgcup8.fsf@vigenere.g10code.de> <CACsn0c=-LKagSqTbgOV1W4Gu4u-f6vpVq82-nWSLGogjoeFKeg@mail.gmail.com> <CAMm+LwjeKDKnN2ZAisbKhWVS4kwCEm_VvcZ1MtftYzEJQpGdhg@mail.gmail.com>, <87y4fi5wa9.fsf@vigenere.g10code.de>
In-Reply-To: <87y4fi5wa9.fsf@vigenere.g10code.de>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/EjpamOFRt5CeZaGYhh_MSWl0ZuA>
Cc: Watson Ladd <watsonbladd@gmail.com>, IETF OpenPGP <openpgp@ietf.org>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Subject: Re: [openpgp] New fingerprint: to v5 or not to v5
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 05 Oct 2015 10:27:18 -0000
Werner Koch <wk@gnupg.org> writes: >Thus we already "salt" the fingerprints with version numbers and a timestamp >and get different fingerprints for these 3 protocols and most likely for all >protocols even for the same key material. For a v5 key the fingerprint will >also be different due to a.3b). ... which is a major pain because the value used to ID the key changes with any tiny change in the metadata surrounding it, so you can no longer identify the key that was used to sign something. The timestamp is the real killer, since non-PGP key formats don't record this and there's no explicit storage of the keyID (it's implicitly calculated from data that isn't available in non- PGP storage), you can no longer track down which key did what. I've got around it by always recording a creation time of zero for keys (so you just hash four bytes of zeroes), but this only works for keys created in my code that knows about this convention. The whole PGP key format as it currently stands is rather a mess. There's no single entry for a key but a connected series of packets of arbitrary number where you have to perform arbitrary amounts of lookahead to see where they end, then a second pass to parse the packets, and then more iterative passes to resolve all the bits and pieces in the packets. Since the keyID is generated implicitly from the packets, you have to do this each time you search a keyring. There are all sorts of attributes, often only vaguely defined, that can be attached at any point where a signature can be found. The descriptions contain gems like: This is a flag in a User ID's self-signature that states whether this User ID is the main User ID for this key [...] If more than one User ID in a key is marked as primary, the implementation may resolve the ambiguity in any way it sees fit, [...] I have no idea what would happen if you created entries like ones with multiple subkeys or conflicting attributes in different locations, but I'd imagine the behaviour of implementations would be pretty much a coin-toss, and the spec doesn't help. I've got around this in my code by assuming a canonical "one main key, one subkey, some userIDs", with anything outside this ignored. This leads to predictable, deterministic behaviour and (hopefully) a lack of surprises, like the one I'm currently dealing with where a particular implementation wants to see a certain arrangement of packets and attributes and I'm still not sure what they are. If the keyring format is redefined for the PGPng, I'd really like to see the format be made more usable, something like (for each entry): header (type + length ) { ID information (explicitly stored, not implicitly generated); primary key; [ optional subkey ]; user IDs; certifications (signatures); } To find a key: foreach entry { read length; check IDs for a match; if( match ) break; skip length bytes; } With the IDs explicitly stored, you no longer need some complex hash-based value to identify the key, you can use any probabilistically-unique value. Peter.
- [openpgp] New fingerprint: to v5 or not to v5 Werner Koch
- Re: [openpgp] New fingerprint: to v5 or not to v5 vedaal
- Re: [openpgp] New fingerprint: to v5 or not to v5 Werner Koch
- Re: [openpgp] New fingerprint: to v5 or not to v5 ianG
- Re: [openpgp] New fingerprint: to v5 or not to v5 Simon Josefsson
- Re: [openpgp] New fingerprint: to v5 or not to v5 Daniel Kahn Gillmor
- Re: [openpgp] New fingerprint: to v5 or not to v5 ianG
- Re: [openpgp] New fingerprint: to v5 or not to v5 Daniel A. Nagy
- Re: [openpgp] New fingerprint: to v5 or not to v5 Werner Koch
- Re: [openpgp] New fingerprint: which hash algo (w… Werner Koch
- Re: [openpgp] New fingerprint: to v5 or not to v5 Watson Ladd
- Re: [openpgp] New fingerprint: to v5 or not to v5 Phillip Hallam-Baker
- Re: [openpgp] New fingerprint: which hash algo (w… Tom Ritter
- Re: [openpgp] New fingerprint: to v5 or not to v5 Werner Koch
- Re: [openpgp] New fingerprint: to v5 or not to v5 Mark D. Baushke
- Re: [openpgp] New fingerprint: to v5 or not to v5 Peter Gutmann
- Re: [openpgp] New fingerprint: to v5 or not to v5 Werner Koch
- Re: [openpgp] New fingerprint: to v5 or not to v5 Werner Koch
- Re: [openpgp] New fingerprint: to v5 or not to v5 Peter Gutmann
- Re: [openpgp] New fingerprint: to v5 or not to v5 ianG
- Re: [openpgp] New fingerprint: to v5 or not to v5 ianG
- Re: [openpgp] New fingerprint: to v5 or not to v5 Werner Koch
- Re: [openpgp] New fingerprint: to v5 or not to v5 Werner Koch
- Re: [openpgp] New fingerprint: which hash algo (w… Simon Josefsson
- Re: [openpgp] New fingerprint: to v5 or not to v5 Peter Gutmann
- Re: [openpgp] New fingerprint: to v5 or not to v5 Werner Koch
- Re: [openpgp] New fingerprint: to v5 or not to v5 Peter Gutmann
- Re: [openpgp] New fingerprint: to v5 or not to v5 Werner Koch
- Re: [openpgp] New fingerprint: to v5 or not to v5 Peter Gutmann
- Re: [openpgp] New fingerprint: which hash algo ianG
- Re: [openpgp] New fingerprint: which hash algo vedaal
- Re: [openpgp] New fingerprint: which hash algo Steve Pointer
- Re: [openpgp] New fingerprint: which hash algo Alessandro Barenghi
- Re: [openpgp] New fingerprint: which hash algo Robert J. Hansen
- Re: [openpgp] New fingerprint: to v5 or not to v5 Daniel Kahn Gillmor
- Re: [openpgp] New fingerprint: to v5 or not to v5 Peter Gutmann
- Re: [openpgp] New fingerprint: to v5 or not to v5 Jonathan McDowell
- Re: [openpgp] New fingerprint: to v5 or not to v5 Nicholas Cole
- Re: [openpgp] New fingerprint: to v5 or not to v5 Vincent Breitmoser
- Re: [openpgp] New fingerprint: which hash algo Daniel A. Nagy
- Re: [openpgp] New fingerprint: to v5 or not to v5 Werner Koch
- Re: [openpgp] New fingerprint: to v5 or not to v5 Werner Koch
- Re: [openpgp] New fingerprint: to v5 or not to v5 Peter Gutmann
- Re: [openpgp] New fingerprint: to v5 or not to v5 Watson Ladd
- Re: [openpgp] New fingerprint: to v5 or not to v5 Werner Koch
- Re: [openpgp] New fingerprint: which hash algo Phillip Hallam-Baker
- Re: [openpgp] New fingerprint: which hash algo ianG
- Re: [openpgp] New fingerprint: which hash algo Daniel Kahn Gillmor
- Re: [openpgp] New fingerprint: which hash algo Phillip Hallam-Baker