Re: [openpgp] Proposed text for V5 fingerprint

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 06 September 2016 04:47 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7651012B123 for <openpgp@ietfa.amsl.com>; Mon, 5 Sep 2016 21:47:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 l2AeA55eiI1X for <openpgp@ietfa.amsl.com>; Mon, 5 Sep 2016 21:47:28 -0700 (PDT)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 1E87512B134 for <openpgp@ietf.org>; Mon, 5 Sep 2016 21:47:28 -0700 (PDT)
Received: by mail-qk0-x229.google.com with SMTP id z190so206955602qkc.0 for <openpgp@ietf.org>; Mon, 05 Sep 2016 21:47:28 -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:from:date:message-id :subject:to; bh=dkkhe1OHtbQUnbxm9JMSibPgkHcds4rt7IBLE4KHa7M=; b=FfqEjy5b8mVxcBnZ/VDqrLNS7YnOXD1BFITjWAQk3dVQV8f2BWAg4s9W7mqFCyoCg6 ruqX/mv8NFYhnSzem+YfMY/LU2AqlKrdr00fgFwNTJqUCpzRuaKNhVjspWHiMAf+dVx5 HBhckWL+TW9wKs+NDXEQeE8FtC4wS2nua1jSTqCaJ+HNmPYI8pgsJ5gj1dyIgbSmTysi eYg5pukC+CqqjMNgDRPviCgvx/ThZfztLQw2gLISdeFT6jrsI8sEpk/1rL3y3WkimUA4 tOZRl/rnPYZS/ofy9ColEZ76499FHFOvYTSC4Ady3/Eoz/xeeSX33cfHTH0cFO94cIV9 fRpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=dkkhe1OHtbQUnbxm9JMSibPgkHcds4rt7IBLE4KHa7M=; b=kVboKW6NXd6XHEx//ADs6iPdvuO988oE/bbBx16NGDmJOyU6o3d/1t2ATSdPdKSDpO 8LPkoXNmGjU550Is+PdZCQGZQe1c7iX25f6ILQ7fYVp0opT6iAjn6Sm72/AQNLT8Alkj EXNEsH/OPcy/2EkldqH3+ZM3UwOJGsnxWFG0ZfrE1YuFhAMLAuur343XXDKOQr2LdbHW 5CnXVkuBe4SoqfCmUyF2Gxg2ayLQ+s9Q9ixwDmuJsIdVzLHpUp1uGClFpr8eIuCbAgL2 zlfe+Har2nnClSdIMhqKXyrDkDDYIPeksH84M3oL4PRYzbxOpb2f9u9U7dPP4pMqQf8n 75vQ==
X-Gm-Message-State: AE9vXwO3m6bg4Oa+2E1AgV05VUhBEEDp8IxJQgj8gizmIIm2oDJ95d337dTxUYxh48udM2ZApyiF4WKJossM9w==
X-Received: by 10.55.186.65 with SMTP id k62mr42826786qkf.204.1473137247168; Mon, 05 Sep 2016 21:47:27 -0700 (PDT)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.55.209.87 with HTTP; Mon, 5 Sep 2016 21:47:26 -0700 (PDT)
In-Reply-To: <CAMm+Lwhz973u20W0TETFrE0Y_frKQth=B0QcisP5bD2jskta4g@mail.gmail.com>
References: <CAMm+Lwhz973u20W0TETFrE0Y_frKQth=B0QcisP5bD2jskta4g@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Tue, 6 Sep 2016 00:47:26 -0400
X-Google-Sender-Auth: P8VVoruTCc4ZDNGMz09UJWDtm6E
Message-ID: <CAMm+Lwj595p1QtrBbFTeig0VX2Mg0giBXCoZNhNZwzXuKfVUNQ@mail.gmail.com>
To: IETF OpenPGP <openpgp@ietf.org>
Content-Type: multipart/alternative; boundary=94eb2c0441ce52b11d053bcf7e0a
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/Fa7Kt87E9RVv0C1FdfikTxAlrXI>
Subject: Re: [openpgp] Proposed text for V5 fingerprint
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: Tue, 06 Sep 2016 04:47:30 -0000

Here is the revised proposed text. I am trying to work out what the
instructions on using gitlab mean. How does making a pull request put
updates into a repo?

There is a piece of technology that I would very much like to propose using
but it is very much encumbered :-( So I am going to propose that separately
and see if we can get the IPR sorted in time to use it. For the time being
it is not in the draft.



## {12.2} Legacy Key IDs and Fingerprints

For a V3 key, the eight-octet Key ID consists of the low 64 bits of
the public modulus of the RSA key.

The fingerprint of a V3 key is formed by hashing the body (but not the
two-octet length) of the MPIs that form the key material (public
modulus n, followed by exponent e) with MD5.  Note that both V3 keys
and MD5 are deprecated.

A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, followed
by the two-octet packet length, followed by the entire Public-Key
packet starting with the version field.  The Key ID is the low-order 64
bits of the fingerprint.  Here are the fields of the hash material,
with the example of a DSA key:

    a.1) 0x99 (1 octet)

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

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

         b) version number = 4 (1 octet);

         c) timestamp of key creation (4 octets);

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

         e) Algorithm-specific fields.

    Algorithm-Specific Fields for DSA keys (example):

    e.1) MPI of DSA prime p;

    e.2) MPI of DSA group order q (q is a prime divisor of p-1);

    e.3) MPI of DSA group generator g;

    e.4) MPI of DSA public-key value y (= g\*\*x mod p where x is secret).

Note that it is possible for there to be collisions of Key IDs -- two
different keys with the same Key ID.  Note that there is a much
smaller, but still non-zero, probability that two different keys have
the same fingerprint.

Also note that if V3 and V4 format keys share the same RSA key
material, they will have different Key IDs as well as different
fingerprints.

Finally, the Key ID and fingerprint of a subkey are calculated in the
same way as for a primary key, including the 0x99 as the first octet
(even though this is not a valid packet ID for a public subkey).

## {12.3} V5 Fingerprint

A V5 Fingerprint is a 512 bit cryptographic digest truncated to provide
a presentation form that is a multiple of 25 bits. In the default
presentation
format using BASE32 encoding, this gives a fingerprint that is a multiple
of five significant characters.

The design of the V5 fingerprint format anticipates the possibile
introduction of additional presentation formats and the use of the same
fingerprint format with other applications. For example the use of
a 2D barcode presentation format.

To enable this separation the calculation of the V5 digest value is
described
separately from the presentation.

### {12.3.1} V5 Key Format

The key data over which the digest value is calculated is the same as
the V4 key data field with the ommission of the creation timestamp.

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

### {12.3.2} V5 Fingerprint Digest Calculation

A V5 fingerprint

The OpenPGP V5 fingerprint value is calculated as follows

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

Where:

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>

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

### {12.3.3} V5 Fingerprint Digest Truncation

The Binary Fingerprint Value is truncated to an integer multiple
of 25 bits regardless of the intended output presentation. Applications
MUST not use Fingerprint Values

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]

Fingerprint Digest Values MUST NOT be truncated to less than 100 bits
in length.

### {12.3.3} V5 Fingerprint BASE32 Presentation

Except where prevented by the affordances of the device on which it is
deployed
(e.g. lacks keyboard), applications MUST support generation and use of the
BASE32 Presentation format.

The Truncated digest value is converted to BASE32.

For ease of entry and verification, the five character blocks SHOULD be
separated by a dash '-'. Applications MUST generate and accept V5
fingerprints
that include separators.

Applications SHOULD accept V5 fingerprints with the dash characters
ommitted.

Applications MUST accept V5 fingerprints with lower case characters,
treating
these as equivalent to the corresponding upper case character.

### {12.3.4} V5 Fingerprint Strengthening.

When an application successfully authenticates a key against a truncated
fingerprint, the application MAY record a longer presentation of the
fingerprint
presentation for future use. This is called key strengthening.

Wherever practical, applications SHOULD support the use of key
strengthening.

For most purposes, strengthening to 250 bits offers a sufficient workfactor
for
almost any application while limiting the resulting fingerprint to 59
characters.