[openpgp] V5 Fingerprint again

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 01 March 2017 17:30 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 13803129462 for <openpgp@ietfa.amsl.com>; Wed, 1 Mar 2017 09:30:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.369
X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id coee7ruJQaN0 for <openpgp@ietfa.amsl.com>; Wed, 1 Mar 2017 09:30:16 -0800 (PST)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::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 100121204D9 for <openpgp@ietf.org>; Wed, 1 Mar 2017 09:30:16 -0800 (PST)
Received: by mail-yw0-x22d.google.com with SMTP id v200so38076500ywc.3 for <openpgp@ietf.org>; Wed, 01 Mar 2017 09:30:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=ZClDcR8mqt1tk4g3gM5mAQqzAqmSOdQTzzQLx972W2g=; b=LeUqNi8EOMGBzELOUVdxLoUBQ3HExW8FdT9GMEyue1xYPi5SLvBhEwlnLAg9Uw0AZv d7vcBK7lo3b+qBM6BoCO4OToi308MIJrZYOv2HRT6duebRsMvnMFZLeoYQwHt9rxe1xj 8hNEntdfIuq5+GqGCsokVYKFFy6O/sheCX6WwW80RGhxJwHeyeS06L9MzwHvZqXwRzXZ h4KZGz177mN9Oy7QHHX9IDoJ8KG3PPDJZRyMMrZweMwCSLqeXtwo+Gxpe0RCIH0yH6iv rN5Rp0ZCIjLXy7XJf3iqFA4rIAi656atbrf7N3b5XhDyJ424qu7ejbTPDqkxMlPLzurc +WEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=ZClDcR8mqt1tk4g3gM5mAQqzAqmSOdQTzzQLx972W2g=; b=b928wvDf40qNbu6AdDuIns37MOPlXpJ07xjjmdnyfIHvjq2Ktg2O0SJ1h5F+a4/J+a q0cW9vVX4gfN9KzbAbSi3IM5h6fZV4HGgp4Qq6RACwZdFuSaWm5kXNq9NTCvbKH1mB8j Qwupb0GTS3YGM+rZBfHOU1ybhnlPf5bfiEgkZg8ajME+ozw5I+wKsTCAfN8Vx3npKrGr bx3QHM/GVPP74TJCcPs7KmFtPxinVrO8AKwfbdeOMI/Uga3R/+NYNjl+IcatmEm5KO8G bX+hceKw1D0NyU1JjaMM7Zv/by42T7Tk6EcWwPwrvC1ZwUFReHljA4/z72LLVYeQUtQz HDpQ==
X-Gm-Message-State: AMke39kvzeqD+lnvT2K1i8sEoFUErFXuqKHs8fAEmfjNFlldLw7yc0hoHi6QIs30YYxwWkeynzhoFls/Uk+uyg==
X-Received: by with SMTP id q19mr3846708ywg.186.1488389414974; Wed, 01 Mar 2017 09:30:14 -0800 (PST)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by with HTTP; Wed, 1 Mar 2017 09:30:14 -0800 (PST)
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Wed, 01 Mar 2017 12:30:14 -0500
X-Google-Sender-Auth: wq7GZL39-oCD8hwlePHTkUIJKLs
Message-ID: <CAMm+Lwju5i5xHt=ma6Ush4_4dfZNwOi2=2km+6Qja+sDbkvbxg@mail.gmail.com>
To: IETF OpenPGP <openpgp@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0b7a5c5dfadb0549aeaaa9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/_uV_coJ0CYayv_2ptJMuSraJhws>
Subject: [openpgp] V5 Fingerprint again
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 01 Mar 2017 17:30:18 -0000

Given the SHA-1 break, Could we return to the V5 fingerprint discussion?

The issue we are seeing the the SHA-1 break is that a LOT of software is
based on the assumption that SHA-1 is unique. And this is causing software
to crash in real world applications.

For example, lets say you are using a GIT like system and some joker has
uploaded different versions of the the colliding PDF into different
instances of the same repository. The two repositories can function quite
happily for quite a while without noticing anything amiss. The problem
comes when we then take SHA-1 hash of the bulk data in both repos:

SHA1(Evil) = SHA1(Evil')


SHA1 (Evil + M0 + .... ) != SHA1 (Evil' + M0 + .... )

We really do need to push to get SHA-1 eliminated before the cost of this
attack falls to the point where you only need 50 GPU years to do it....

The proposal I made introduces a context into the fingerprint so that
S/MIME, OpenPGP, etc. can all use the same fingerprint format without
semantic substitution attacks being possible.

##V5 Fingerprint calculation and presentation

A V5 fingerprint value is a sequence of bits that provides a sufficiently
unique identifier for a public key. In addition to generating and accepting
the text string presentation used in earlier versions of OpenPGP
MAY support such additional presentation formats as are found to be useful.

Conforming V5 OpenPGP implementations MUST support the V5 Fingerprint
text presentation format for display and entry of fingerprint values.
Support for all other fingerprint values is optional.

###V5 Fingerprint value calculation

The OpenPGP V5 fingerprint value is calculated as follows

Fingerprint = <Version-ID> + H (<Content-ID>  + ‘:’ + H(<data>))


Version-ID = 0x60

Content-ID = "application/pgp-v5-key"
<<MIME Content-Type string TBS by IANA>>

H(x) = SHA-2-512(x)

<data> = <pgp-v5-key>

<pgp-v5-key> =

a.1) 0x99 (1 octet)

a.2) high-order length octet of (b)-(d) (1 octet)

a.3) low-order length octet of (b)-(d) (1 octet)

b) version number = 5 (1 octet);

c) algorithm (1 octet): 17 = DSA (example);

d) Algorithm-specific fields.

The value of Version-ID is intentionally chosen so that
the first character of every V5 fingerprint in the text presentation
format is 'M', a character that is guaranteed not to appear in a V4
or earlier fingerprint format where hexadecimal values were used.
Thus ensuring that V5 fingerprints are not accidentally confused.

The construction of the data sequence over which the hash value
is calculated follows the construction used in V4 with the omission
of the key creation timestamp field. This ensures that a given set
of public key parameters has exactly one V5 fingerprint value.

The Content-ID is a MIME content type identifier that indicates that
fingerprint value is of data in the pgp-v5-key format specified
above and is intended for use with an OpenPGP application.

If a fingerprint value is to be calculated for a public key value
specified in a different format (e.g. a PKIX certificate or key)
or for a future version of OpenPGP with a different <data> format,
a different Content-ID value MUST be used.

###V5 Fingerprint Text Presentation.

The Binary Fingerprint Value is truncated to an integer multiple
of 25 bits regardless of the intended output presentation.

The output of the hash function is truncated to a sequence of n bits
by first selecting the first n/8 bytes of the output function. If n
is an integer multiple of 8, no additional bits are required and
this is the result. Otherwise the remaining bits are taken from the
most significant bits of the next byte and any unused bits set to 0.

For example, to truncate the byte sequence [a0, b1, c2, d3, e4] to
25 bits. 25/8 = 3 bytes with 1 bit remaining, the first three bytes
of the truncated sequence is [a0, b1, c2] and the final byte is
e4 AND 80 = 80 which we add to the previous result to obtain the
final truncated sequence of [a0, b1, c2, 80]

A modified version of Base32 [!RFC4648] encoding is used to present
the fingerprint in text form grouping the output text into groups of
five characters separated by a dash ‘-‘.

# IANA Requirements

Register a new content type for application/pgp-v5-key