Re: [openpgp] Fingerprints
Derek Atkins <derek@ihtfp.com> Fri, 10 April 2015 14:58 UTC
Return-Path: <derek@ihtfp.com>
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 25F4B1A0275 for <openpgp@ietfa.amsl.com>; Fri, 10 Apr 2015 07:58:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.289
X-Spam-Level:
X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no
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 ga8mNt5TqKWz for <openpgp@ietfa.amsl.com>; Fri, 10 Apr 2015 07:58:19 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C20CB1A0364 for <openpgp@ietf.org>; Fri, 10 Apr 2015 07:58:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 71031E2038; Fri, 10 Apr 2015 10:58:16 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 23796-10; Fri, 10 Apr 2015 10:58:14 -0400 (EDT)
Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id D17A9E2036; Fri, 10 Apr 2015 10:58:13 -0400 (EDT)
Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t3AEwCQ5022518; Fri, 10 Apr 2015 10:58:12 -0400
From: Derek Atkins <derek@ihtfp.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
References: <CAMm+LwhbB+-MnGRBCvprgAGOuu+5CJ2rgod7EBGOQR5UNVrspQ@mail.gmail.com> <87y4m0ozlt.fsf@vigenere.g10code.de>
Date: Fri, 10 Apr 2015 10:58:11 -0400
In-Reply-To: <87y4m0ozlt.fsf@vigenere.g10code.de> (Werner Koch's message of "Fri, 10 Apr 2015 15:57:18 +0200")
Message-ID: <sjmk2xkf2t8.fsf@securerf.ihtfp.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/sax8aFm6Su-Q1NyauAwGZF-XDUY>
Cc: "openpgp@ietf.org" <openpgp@ietf.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [openpgp] Fingerprints
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: <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, 10 Apr 2015 14:58:21 -0000
Werner Koch <wk@gnupg.org> writes: > On Fri, 10 Apr 2015 15:23, phill@hallambaker.com said: > >> There is no need to have an algorithm field, a version field is >> sufficient because we should only be using one algorithm at a given > > Right. However an algorithm field is as good as a version field because > they have the same purpose in this context. An algorithm field saves us > a mapping to the actual algorithm. Recall that OpenPGP uses an > one-octet indentifier and not an OID. I'm with Werner on this one. There's not a significant difference between a version field and an algorithm field. Either option adds a single byte to the data structure, but using a version field requires additional lookup map (from fingerprint version # to hash algorithm). Maybe that's useful to make sure an attacker doesn't use a "bad" hash algorithm for a fingerprint? But I'd rather just use the hash algorithm directly. >> time. There is no need for a length field either. > > Agreed. > > It is often useful to have a keyid to quickly (but insecure) refer to a > key. I suggest to take it from the fingerprint bytes 1 to 4 (ignoring > the algorithm byte). There is no need for a long keyid. However, we > may also suggest a use like in git where you may abbreviate it as you > like - however the keyid should be non-normative because the protocol > should not make any use of it. I presume here you are referring to the "printed" fingerprint, and not the "internal" fingerprint? Internally we'd still use the full length, right? Or would we need to somehow know when (and how) to truncate the hash? >> I am also using SHA512 and truncating to 128 bits, then base 32 >> encoding. The rationale for this is > > Because there are several versions of BASE-32 I suggest the use of > z-base-32 which is used by Tahoe-LAFS and ZRTP. The truncation length of > the hash should be match a best match for the base 32 encoding. Similarly, I think we should be clear that we're talking about two different things here. Internally (e.g. in a signature packet) it should be the binary result, not hex- or base-32 encoded. >> * Fingerprints are the root of trust, there is an outside chance that >> SHA-2-256 might be broken but breaking SHA-2-512 truncated to 256 bits >> is a lot harder because it has 80 rounds rather than 64. > > I think that should be discussed in the context of the new default hash > algorithm. > > >> The bit that will probably be controversial is how I am calculating >> them, over an X.509v3 KeyInfo block. There is method to the madness > > X.509 has no definition for a fingerprint but OpenPG already uses a well > defined method to compute the fingerprint. You can't compare the two > protocols or define a unique fingerprint method. I think "how you take the fingerprint of an X509 key block" should be out of scope for the OpenPGP WG. I think that you can (and should) write a separate document that does that. >> If people really can't stomach ASN.1 code then we could do some other >> key format. But the problem then becomes having to specify how to > > We want to do an rfc4880bis and not an entire new protocol. Thus any > ASN.1 encoding is not an option. Ditto. If the goal here is to have the same key material result in the same fingerprint regardless of whether it's encoded in OpenPGP or X.509, I think the answer is going to be "X.509 people are going to need to convert their key material to OpenPGP packet format and feed into the hash algorithm". I see no other way, and frankly any other way is madness (for the OpenPGP group). I'm sure Phill wont like that answer, but I think it's the right answer for this (potential) working group. > > Salam-Shalom, > > Werner -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints Werner Koch
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints Derek Atkins
- Re: [openpgp] Fingerprints Werner Koch
- [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Werner Koch
- Re: [openpgp] Fingerprints Tom Ritter
- Re: [openpgp] Fingerprints Werner Koch
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints ianG
- Re: [openpgp] Fingerprints Daniel A. Nagy
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints Stephen Paul Weber
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints Jon Callas
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints David Shaw
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Jon Callas
- Re: [openpgp] Fingerprints ianG
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints ianG
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Werner Koch
- Re: [openpgp] Fingerprints Derek Atkins
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints ianG
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints ianG
- Re: [openpgp] Fingerprints Daniel Kahn Gillmor
- Re: [openpgp] Fingerprints Derek Atkins
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Derek Atkins
- Re: [openpgp] Designated Revokers Vincent Breitmoser
- Re: [openpgp] Fingerprints Vincent Breitmoser
- Re: [openpgp] Fingerprints Werner Koch
- Re: [openpgp] Fingerprints Jon Callas
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Derek Atkins
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Daniel Ranft
- Re: [openpgp] Fingerprints Werner Koch
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints Werner Koch
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints ianG
- Re: [openpgp] Fingerprints Daniel A. Nagy
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints Vincent Breitmoser
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Vincent Breitmoser
- Re: [openpgp] Fingerprints Werner Koch
- Re: [openpgp] Fingerprints Vincent Breitmoser
- Re: [openpgp] [eX-bulk] : Re: Fingerprints Christopher LILJENSTOLPE
- Re: [openpgp] [eX-bulk] : Re: Fingerprints Christopher LILJENSTOLPE
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints Vincent Breitmoser
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints Christoph Anton Mitterer
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- Re: [openpgp] Fingerprints ianG
- Re: [openpgp] Fingerprints ianG
- Re: [openpgp] Fingerprints Phillip Hallam-Baker
- [openpgp] [RFC4880bis PATCH] Deprecate "Revocatio… Daniel Kahn Gillmor
- Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revoc… Daniel Kahn Gillmor
- Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revoc… Neal H. Walfield
- Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revoc… Daniel Kahn Gillmor
- Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revoc… Daniel Kahn Gillmor
- Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revoc… Werner Koch
- Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revoc… vedaal
- Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revoc… Paul Wouters
- Re: [openpgp] [Suspected Junk Mail] Re: [RFC4880b… vedaal
- Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revoc… Daniel Kahn Gillmor
- Re: [openpgp] [RFC4880bis PATCH] Deprecate "Revoc… Daniel Kahn Gillmor
- Re: [openpgp] [Suspected Junk Mail] Re: [RFC4880b… Daniel Kahn Gillmor