Re: [openpgp] Proposed text for V5 fingerprint

Thijs van Dijk <> Wed, 14 September 2016 14:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3712C12B38A for <>; Wed, 14 Sep 2016 07:20:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.034
X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JGdsKBOsIGGj for <>; Wed, 14 Sep 2016 07:20:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0B0D012B9F7 for <>; Wed, 14 Sep 2016 06:39:36 -0700 (PDT)
Received: by with SMTP id u82so19117618ywc.2 for <>; Wed, 14 Sep 2016 06:39:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google-inurb; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sLOIvLIdYfl73k5vBmJq059fjfS4GJkn8VX0HLTip7o=; b=PCr3Vqe1EV8MOFiASasO/jJueUdjij+WfX+wR5J0MlszEMNPn3jeuJBIE/Fg3Z2h3P L1XftME6viAfKvEw5oXyJvN+627nSs4Ar1h5AA+batR6vmyYHhaNNVhAJ4i0gz0T/CZG ZgAbvV9Z3ecx01ulrwBS1MOjFwdgTunkJ2P8M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sLOIvLIdYfl73k5vBmJq059fjfS4GJkn8VX0HLTip7o=; b=l0ABvUSExlMMVDUzfLKj8DYXV3l4C9PT4eWC/gmTRxCatW418orXsCsTKZwQASnzs8 mZq90Ujj87WfJr1eifzekPX9JvHETHMQFTFS2ZBuEC+/fkam3HLUiDUPO9f8JRfsHYir MEXLtq/mW3qqf4YB7mX1otkkRwGCwRjU0cDc8BBJ06NhutXZO67nZpDvyxGQ3Q0eJKq9 JyhoY6y9IrEn6fQP7T1HiHg9rO07UH6rvLSQZ6bSMNzVuIr4L8MzvskQqwofoEBjAXz2 Jq8ZGtBJ/qBsCUnc1TvoSyybfnmPxFQ1sVbGeG6Lch/zi4j/L3Kb0p2iGDUY3awQExJK s5cA==
X-Gm-Message-State: AE9vXwP2v12epGkv+reNJrtUW5xLa11iuUfvck8y//pIH3tMNguHRTNEHG4pFcRJBEBLl8SXBeERHlJhlLbQOA==
X-Received: by with SMTP id t8mr2446248ywe.170.1473860376076; Wed, 14 Sep 2016 06:39:36 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 14 Sep 2016 06:39:35 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Thijs van Dijk <>
Date: Wed, 14 Sep 2016 15:39:35 +0200
Message-ID: <>
To: Phillip Hallam-Baker <>
Content-Type: multipart/alternative; boundary="94eb2c0872da2a57a8053c77dce6"
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: Wed, 14 Sep 2016 14:20:21 -0000

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]

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.

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. I don't think this will be problematic
since the probability of a collision is negligible in normal use [2], and
the opportunities for malice are very limited [3]. Furthermore, it could go
hand in hand with removing the key ID from the PKESK altogether and
defaulting to "anonymous" encryption / trial decryption - of which I would
be in favour. Nonetheless, it's something to keep in mind.

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:

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?


[1]: A tale as old as time -
[2]: One would need 2^12+ private keys in their keyring in order to be
affected by this (down from 2^16).
[3]: At best, an attacker could force many trial decrypts.
[4]: Or "key strengthening". Are those terms interchangeable?
[5]: In fact, any operation which isn't "select a key from my keyring" or
"download and import a key from a keyserver".