Re: [openpgp] Proposed text for V5 fingerprint

Thijs van Dijk <> Mon, 19 September 2016 10:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B8C112B0CB for <>; Mon, 19 Sep 2016 03:36:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.334
X-Spam-Status: No, score=-1.334 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_NONE=-0.0001, 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 Ly39RilPiyZO for <>; Mon, 19 Sep 2016 03:36:13 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8D09412B11C for <>; Mon, 19 Sep 2016 03:36:06 -0700 (PDT)
Received: by with SMTP id i66so81298821yba.0 for <>; Mon, 19 Sep 2016 03:36:06 -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=Z8+o5cUj3oMHXtSr5m6sGjqI8eKxOAruTaCdgj7V0iQ=; b=Cny8Q1cmUqHZZIr3qTVxMgKbHPIw4rpcqtwJ5qtX5U/IijVNUJGO+oswLvLwt06188 /ySK+XrjcNrHZRWCYq4h3yHQQGSDS49NlCs6oi7HkhCi6oj2O9O0whdb19WwssKxNp5V VgecQzJnL4VyvemElKn1Xu7coxBJgBBAYIc7M=
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=Z8+o5cUj3oMHXtSr5m6sGjqI8eKxOAruTaCdgj7V0iQ=; b=eNeI2LAl1SrEdS+HSXMgrhxA8ygIWT3dXcTmhbJbZuMLa6mVf8+ru/jGmQxVCZRENT iL5LONt1ss3TNJZd7xq1nWLSvCQUwanZxYuYK1cpoz2UQuGEcuv2U2jIOL1oTAj9n3My 8dmTts4xBDNmxkB3qCTSQI9UIm2KZlP2tQ9y5fPlKu2yDAx5Qt0JDyMcoia/QWsF1RrL 0ow45nzRVHe06Ceps613ydgzOiL68rTxG4HtqS9Si2aJCiDwEfjAAArQCXDw7lY/IFYB AbtAzoERfJyymK3VLMopKVcrJhNFVEeRDX6sc4zDQEC+131K43b93/pGjdmGDu95V6yc LN0g==
X-Gm-Message-State: AE9vXwN4Z0ICU6QAuhoGscxYllG4U6d6OnLFcrdAhae/P/2WUpaZPycH2lG0E868jKWhB+sYcSLtEEURPFY80A==
X-Received: by with SMTP id l10mr24202887ybb.133.1474281365662; Mon, 19 Sep 2016 03:36:05 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 19 Sep 2016 03:36:04 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Thijs van Dijk <>
Date: Mon, 19 Sep 2016 12:36:04 +0200
Message-ID: <>
To: Phillip Hallam-Baker <>
Content-Type: multipart/alternative; boundary="001a113fdef819b836053cd9e149"
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: Mon, 19 Sep 2016 10:36:14 -0000

On 17 September 2016 at 23:43, Phillip Hallam-Baker <>

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

Right. Sorry.

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
> anyway.​

That's a good point. In fact, I'll hazard a guess and say that that's
likely to be the only event to warrant a key version bump.

​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
> ways.

Fair enough.
At the other end of the spectrum, do you have any thoughts on what we can
consider the "full" fingerprint? This scheme has an implied maximum length
of 500 bits (the largest multiple of 25 less than 512+8). Apart from
specifying a minimum (100 bits), do you think we should make a
recommendation for what is an appropriate level of assurance? (E.g. 250
bits - 10 groups of 5 base32 characters, similar in size and grouping to V4

Apart from this, you'll be glad to know that I've kicked the tyres of this
proposal about all I can, and I like it a lot. Eagerly awaiting someone
else to chime in at this point.