Re: [openpgp] Proposed text for V5 fingerprint

Phillip Hallam-Baker <> Sat, 17 September 2016 21:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97E20126D74 for <>; Sat, 17 Sep 2016 14:43:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.697
X-Spam-Status: No, score=-0.697 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BfDDKF-sDyl1 for <>; Sat, 17 Sep 2016 14:43:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7BDEB128B38 for <>; Sat, 17 Sep 2016 14:43:08 -0700 (PDT)
Received: by with SMTP id z190so117788051qkc.3 for <>; Sat, 17 Sep 2016 14:43:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=q5voHWtI3GCOxIbJbbhZ7d5c5pnFz0ilpP58cIPR3Ts=; b=RvwfGgYDKDE3uTVcl9RJxm3NB9IC0Dh6p2thIqU5xIo9YsnQM5ugncaWQ3JY39jslb oH0W3vSwK7vFJM73V8k47EahSuPfyS1OBCeH/hntNuv3bqlqWoCzMoAPOrjeCQ6/zlSr A0r1LEtGjiKV3oiawdoeU6wLJD0U8zoTzcb53am3piQWookaPbfgej3u13lt+5PQdoy9 AzcGLxB6jQR5lYXygAVYGoKdAisJez2ALY8Iqmv6CLl2Iy7HZudrYtleC2I77rBM5a6R Hme4YzV67VDhHsJ37X3BKkN6E0uNi6alzfjILZI9ohsyZgNK46yhXsBmjaKgYofRf/d+ JzwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=q5voHWtI3GCOxIbJbbhZ7d5c5pnFz0ilpP58cIPR3Ts=; b=R7wJ36yUwFOOqztEGksdSADTJI0n5c0Xqz2jPAwePdinYnI6vgvlnXLL4Gk2wvavRg n09DTuWYZa7r10wUh1Ff34mwlfD5VjvVQUXTxmD57hrv5WyeFlStt2T8q/dgmWIGGBLR yCqGorxnyObf80HONuBaoSBQn6+Qx2Y7+H0g8TAF+jEL9l5VdjfO1+cVxM1Oky+L0Ht6 469jMFsQYwHmVSf+oE2Y39KN0hCv7QG0/81SvakGlUXhDW8B9BLZOaW4DKqXy5wEvo9C N8dOVg/uxXLvjZp76Vj6baOaTawVYAK4/o0h/UKIjEn0Ee4/Vubf3CA0kW9fKBDYipnW L8lg==
X-Gm-Message-State: AE9vXwOrUuggWCf9dUyowmnmffSywSKuvmOkoR0U0+KjBuybG5Lx6gpzsw8bQCw9S7xv15K4/VsC4p9/pkAzow==
X-Received: by with SMTP id t189mr21570735qkf.58.1474148587578; Sat, 17 Sep 2016 14:43:07 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 17 Sep 2016 14:43:06 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Phillip Hallam-Baker <>
Date: Sat, 17 Sep 2016 17:43:06 -0400
X-Google-Sender-Auth: 687fditNd0NKoseKBybpR3BgHpg
Message-ID: <>
To: Thijs van Dijk <>
Content-Type: multipart/alternative; boundary="94eb2c04448ee8ac1a053cbaf68e"
Archived-At: <>
Cc: IETF OpenPGP <>
Subject: Re: [openpgp] Proposed text for V5 fingerprint
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 17 Sep 2016 21:43:10 -0000

On Wed, Sep 14, 2016 at 9:39 AM, Thijs van Dijk <>

> Hi Phillip,
> Thanks for clearing that up.
>> It would be really nice if we could all use the same format to identify a
>> root of trust. But that is of course not going to happen unless we can get
>> all six of the major PKI infrastructures to agree on one approach and that
>> probably isn't even desirable.
> Yes. Out of curiosity, are you currently working with any of the other
> five groups to adopt a similar proposal there?
> I realise that one has to be the first, and it might as well be us, but I
> wouldn't want to be the one to add the n+1'th competing standard. [1]

​That is a really bad cartoon to bring up at a standards body.

The point is that we create another standard and THE OTHER ONES DIE. It
really does happen. Before SAML there were 30+ single sign on schemes in
use. Now everything supports SAML.

But in this case we are already proposing a new OpenPGP fingerprint. So
designing that so that other applications can use the same spec is no
additional cost.​

​The SMIME group has been talking about a fingerprint mode. There is no
guarantee that they will do it. BUT if they do it, they would be doing so
to converge with OpenPGP so it is logical to expect them to do the same

> The other reason for having the content-id in is to allow versioning
>> within OpenPGP. So for example, lets say that there is a V6 key format but
>> we don't want to change the digest value. We can change the OpenPGP content
>> definition format as many times as we like without having to use up any of
>> those scarce fingerprint version IDs.
> Ah, so the version ID pertains to the fingerprint method only and not the
> underlying key? That's good to know, and probably a good thing to document
> for posterity if we choose to adopt this scheme.
> In that case I'll have to lower my previous +1 on prepending a version ID.
> I'd have loved to have been able to tell at a glance if a fingerprint
> belongs to a v5 or a v6 key even if we keep the hash format the same, but I
> see now that that isn't going to be possible without downloading the keys
> in full.

​The current design neither forces the version ID to stay the same nor to
change it. So that isn't a decision we need to take now.

The only thing that forces a change of VersionID is a change in digest
algorithm. Which is probably the thing that would lead to a V6 format

> Also, one other consequence of prepending a version ID to a key
> fingerprint and reading the key ID from the start of the fingerprint rather
> than the back is that the Public-Key Encrypted Session Key packet now only
> has 24 useful bits of key ID, down from 32.

​Which bits OpenPGPv5 uses for the session key can be defined separately.
Since the key must be a v5 key, there is no need for a version ID.​

About the text, the last paragraph feels out of place. Did you add it in
> anticipation of many backreferences to the term "fingerprint strengthening"
> [4], or are you just describing client behaviour? In my understanding, most
> operations (verifying a signature, encrypting to someone, etc. [5]) will
> require one to have the full public key anyway, not just the fingerprint.
> It might therefore be better served by e.g. the following:

​I added it out of my usual intent to create as wide a prior art trail as
possible in developing a spec.​

> Client applications MAY import a public key from an external source using
> only the short 50-bit key ID as a reference. However, when checking a key's
> integrity, applications SHOULD use the full fingerprint for verification.
> ```
> Your thoughts?

​I think we should kill fingerprints with a work factor of less than 2^92 ​
​as unsafe.​ No matter what, they just keep coming back and biting in bad