Re: [openpgp] Followup on fingerprints
Phillip Hallam-Baker <phill@hallambaker.com> Thu, 30 July 2015 14:12 UTC
Return-Path: <hallam@gmail.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 3008A1A1A0B for <openpgp@ietfa.amsl.com>; Thu, 30 Jul 2015 07:12:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 k5jM_KQEDRHg for <openpgp@ietfa.amsl.com>; Thu, 30 Jul 2015 07:12:44 -0700 (PDT)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5BE01A1A06 for <openpgp@ietf.org>; Thu, 30 Jul 2015 07:12:43 -0700 (PDT)
Received: by laah7 with SMTP id h7so25855042laa.0 for <openpgp@ietf.org>; Thu, 30 Jul 2015 07:12:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=R0qInHLVSiT9FzFAHu2tEV6coqw+L8btJEO06t0LJL0=; b=EOSwZxthpXJz7G2/st/oehmgEDYCh0Hxv2yces0cFgMkdiDtYMkmTFLXi28UfPLYYC Vnv66rLeyY+SAIoBJ9XE9PpZb6OKvDGqTyvvn7YyTaiuQLeOYkGAMFc79iXX+lsxY94j 1z9fstl8sWn6iWvKozu6sq0pLXbgLw/sNtbyjfsXWQ3eWprXhrfoRRQGhGsJh31GTTg+ CiSRml4dBuCS4iirKew95J3y9Zj9eDefZZ8nJxuws1EiTwP+utkdKtmgoIlRjQI4E08A OXqiLQjnHshalFhNOUNH5gTT2adiEeyP5guMYGFaQWHzBijN27BBEMDBhn9xwQPCaJbI JXmg==
MIME-Version: 1.0
X-Received: by 10.152.87.72 with SMTP id v8mr10146631laz.124.1438265561999; Thu, 30 Jul 2015 07:12:41 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.203.163 with HTTP; Thu, 30 Jul 2015 07:12:41 -0700 (PDT)
In-Reply-To: <87si870zqy.fsf@vigenere.g10code.de>
References: <CAMm+LwgTcn8CY+Zk-f9gzXQtMJezG97T+kx2=C7PR5g7zFer_A@mail.gmail.com> <87twsn2wcz.fsf@vigenere.g10code.de> <CAMm+LwgRJX-SvydmpUAJMmN3yysi4zzGSpO2yY4JAMhD-9xLgQ@mail.gmail.com> <87si870zqy.fsf@vigenere.g10code.de>
Date: Thu, 30 Jul 2015 10:12:41 -0400
X-Google-Sender-Auth: 9WyihiQ2WOI-ICeNFDwoUyWcHa0
Message-ID: <CAMm+LwgRgLDxu2sC8-cohYv_ewNRHAp_HaLQf=jTXB8gJENzVg@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>, IETF OpenPGP <openpgp@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c36410ea7163051c184bf9"
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/8fYaVeqyT-E9jgLOaiQjlMCEfeM>
Subject: Re: [openpgp] Followup on 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: <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: Thu, 30 Jul 2015 14:12:47 -0000
OK, so looking through the threads, I think we are talking at cross purposes due to differences in terminology. For me a fingerprint is a presentation of a digest to be read by a human. Getting the nomenclature consistent may seem unimportant but it is actually 50% of getting a spec right. I suggest the following. We have a sequence of two modules as follows. Digested content = The input into the fingerprint digest function. Fingerprint digest function = Some function involving SHA-2/SHA-3 and a version identifier. Tagged Digest/Binary Fingerprint = The output from the Fingerprint digest function. Presentation Function = Converts the Binary Fingerprint for human readability. Probably involves truncation, BASE32 and inserting dashes. Fingerprint = What the user sees. Internally, the Tagged Digest/Binary Fingerprint is the structure that is closest to the existing OpenPGP 'fingerprint'. On Wed, Jul 29, 2015 at 11:06 AM, Werner Koch <wk@gnupg.org> wrote: > On Wed, 29 Jul 2015 16:31, phill@hallambaker.com said: > > > On Wed, Jul 29, 2015 at 4:37 AM, Werner Koch <wk@gnupg.org> wrote: > > >> OpenPGP does not specify a user interface but the wire format. > >> Obviously we use the most compact format there which is the plain binary > >> format. The questions are > >> > > > > That is how we used to work in the 1990s. Since then we have had to do > > internationalization and such. > > I can't see what internationalization has to do with the binary > representation of a fingerprint. As I said RFC-4880 is about the wire > format and not about user interfaces: It tells how to compute a > fingerprint and that it is the 16 octet MD5 hash or the 20 octet SHA-1 > hash. Now that a fingerprint is printed like this > > pub dsa2048/F2AD85AC1E42B367 2007-12-31 [expires: 2018-12-31] > Key fingerprint = 8061 5870 F5BA D690 3336 86D0 F2AD 85AC 1E42 B367 > > is the choice of the concrete implementation. It is an interesting idea > to have a common way of representing fingerprints to the user or in an > URL but that is not in the scope of RFC-4800bis. Back in the 1990s, we could ignore the user interface layer completely. Those times are past. For OpenPGP to work in the real world, people have to be able to write fingerpints on their business cards in ways that different implementations can interpret. When we designed URLs, they were not designed to be written on the side of a truck but they were designed to be printed in the references section of a scientific paper. > > Yes, totally. I am suggesting we put code points in for the SHA-2-512 > > digest and the SHA-3-512 digest. > > Until now we have bound the format of the fingerprint to the version of > the public key format. The fingerprint for OpenPGP is a well defined > and internally used property of OpenPGP. This avoids multiple > fingerprints as we see with X.509 which does not have a specification > for a fingerprint at all. By 'format of the fingerprint' you seem to be referring to the format in which the digested content is presented, i.e. the input to the Fingerprint digest function. I think it is better to have the version specify just the Fingerprint digest function. We can get domain separation between OpenPGP versions by putting a content version somewhere in the Digested Content. > > My preference is to just truncate and use the inferred length. That > allows > > By truncation I mean an arbitary truncation like what we do with keyids. > Those 64 keyids are for example used to locally lookup the secret keys > for decryption - there is no need to have security here because it is > just a convenience method (cf. wild card keyids) There are two points at which truncation might occur. The Presentation module really has to do truncation. Even 256 bits is too many. We might want to truncate the binary fingerprint to 256 bits as well. The reason for using SHA-2-512 is more rounds, not to get more output bits. > > > This is the 'domain separation' issue that was mentioned in the meeting. > > > > I believe that we have to be able to revise the algorithm used to revise > > the fingerprint and the format of the data being formatted independently. > > Again, OpenPGP does not specify how to format a fingerprint. That is > and should stay out of scope for _this_ RFC but may be an additional > item for the WG. Absolutely. This should be a separate document from RFC4880-BIS > > > sufficient would be if a completely radical change to the format was > being > > considered such as moving all the structures to YANG, CBOR, JSON or > JSON-B. > > The OpenPGP format is the OpenPGP format and not BER, PER, XML, or JSON. One of the few things Rudy Guiliani ever said to me that made any sense is that you can't expect every disaster but you plan for all the disasters you can imagine and then you are most likely to be prepared for the one that happens. So planning for an invasion by a zombie hoard might sound like it is completely nuts. But that sort of planning might come in handy if you were facing a major outbreak of Ebola. I think its the same with extensibility. We can't predict every future possible use of the spec and we shouldn't try. But if we can cover all the possibilities we can imagine without undue burden on the spec, we maximize the possibility that someone can build the extension that turns out to be the killer app.
- [openpgp] Followup on fingerprints Phillip Hallam-Baker
- Re: [openpgp] Followup on fingerprints Werner Koch
- Re: [openpgp] Followup on fingerprints Phillip Hallam-Baker
- Re: [openpgp] Followup on fingerprints Werner Koch
- Re: [openpgp] Followup on fingerprints Vincent Breitmoser
- Re: [openpgp] Followup on fingerprints Daniel Kahn Gillmor
- Re: [openpgp] Followup on fingerprints Daniel Kahn Gillmor
- Re: [openpgp] Followup on fingerprints Werner Koch
- Re: [openpgp] Followup on fingerprints Phillip Hallam-Baker
- Re: [openpgp] Followup on fingerprints Phillip Hallam-Baker
- Re: [openpgp] Followup on fingerprints Wyllys Ingersoll
- Re: [openpgp] Followup on fingerprints Phillip Hallam-Baker
- Re: [openpgp] Followup on fingerprints Daniel Kahn Gillmor
- Re: [openpgp] Followup on fingerprints Vincent Breitmoser
- Re: [openpgp] Followup on fingerprints Derek Atkins
- Re: [openpgp] Followup on fingerprints Phillip Hallam-Baker
- Re: [openpgp] Followup on fingerprints Vincent Breitmoser
- Re: [openpgp] Followup on fingerprints ianG
- Re: [openpgp] Followup on fingerprints Gregory Maxwell
- Re: [openpgp] Followup on fingerprints Phillip Hallam-Baker
- Re: [openpgp] Followup on fingerprints Derek Atkins
- Re: [openpgp] Followup on fingerprints Gregory Maxwell
- Re: [openpgp] Followup on fingerprints Derek Atkins
- Re: [openpgp] Followup on fingerprints Peter Pentchev
- Re: [openpgp] Followup on fingerprints Derek Atkins
- Re: [openpgp] Followup on fingerprints Phillip Hallam-Baker
- Re: [openpgp] Followup on fingerprints Vincent Breitmoser
- Re: [openpgp] Followup on fingerprints Vincent Breitmoser
- Re: [openpgp] Followup on fingerprints Phillip Hallam-Baker
- Re: [openpgp] Followup on fingerprints Werner Koch
- Re: [openpgp] Followup on fingerprints Nicholas Cole
- Re: [openpgp] Followup on fingerprints Derek Atkins
- Re: [openpgp] Followup on fingerprints Derek Atkins
- Re: [openpgp] Followup on fingerprints Phillip Hallam-Baker
- Re: [openpgp] Followup on fingerprints Derek Atkins
- Re: [openpgp] Followup on fingerprints Vincent Breitmoser
- Re: [openpgp] Followup on fingerprints Daniel Kahn Gillmor
- Re: [openpgp] Followup on fingerprints Daniel Kahn Gillmor
- Re: [openpgp] Followup on fingerprints Derek Atkins
- Re: [openpgp] Followup on fingerprints ianG
- Re: [openpgp] Followup on fingerprints Vincent Breitmoser
- Re: [openpgp] Followup on fingerprints Nicholas Cole
- Re: [openpgp] Followup on fingerprints Werner Koch
- Re: [openpgp] Followup on fingerprints Phillip Hallam-Baker
- Re: [openpgp] Followup on fingerprints Daniel Kahn Gillmor
- Re: [openpgp] Followup on fingerprints Phillip Hallam-Baker
- Re: [openpgp] Followup on fingerprints ianG
- Re: [openpgp] Followup on fingerprints Vincent Breitmoser
- Re: [openpgp] Followup on fingerprints Bill Frantz
- Re: [openpgp] Followup on fingerprints ianG
- Re: [openpgp] Followup on fingerprints Bill Frantz