From nobody Mon Sep 5 21:47:32 2016 Return-Path: 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 ; 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 ; 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 ; Mon, 5 Sep 2016 21:47:28 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id z190so206955602qkc.0 for ; 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: References: From: Phillip Hallam-Baker Date: Tue, 6 Sep 2016 00:47:26 -0400 X-Google-Sender-Auth: P8VVoruTCc4ZDNGMz09UJWDtm6E Message-ID: To: IETF OpenPGP Content-Type: multipart/alternative; boundary=94eb2c0441ce52b11d053bcf7e0a Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2016 04:47:30 -0000 --94eb2c0441ce52b11d053bcf7e0a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 =3D 4 (1 octet); c) timestamp of key creation (4 octets); d) algorithm (1 octet): 17 =3D 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 (=3D 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. =3D 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 =3D 5 (1 octet); c) algorithm (1 octet): 17 =3D 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 =3D + H ( + =E2=80=98:=E2=80=99 + H(<= data>)) Where: Version-ID =3D 0x60 Content-ID =3D "application/pgp-v5-key" <> H(x) =3D SHA-2-512(x) =3D 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 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 =3D 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 =3D 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. --94eb2c0441ce52b11d053bcf7e0a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Her= e is the revised proposed text. I am trying to work out what the instructio= ns 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 muc= h 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 Finger= prints

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

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

A V4 fingerprint is the 160-bit SHA-1 hash of the o= ctet 0x99, followed
by the two-octet pack= et length, followed by the entire Public-Key
packet starting with the version field.=C2=A0 The Key ID is the low-ord= er 64
bits of the fingerprint.=C2=A0 Here= are the fields of the hash material,
wit= h the example of a DSA key:

=C2=A0 =C2=A0 a.1) 0x99 (1 octet)

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

=C2=A0 =C2=A0 a.3) low-order l= ength octet of (b)-(e) (1 octet)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0b) version= number =3D 4 (1 octet);

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0c) timestamp of ke= y creation (4 octets);

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0d) algorithm (1 octe= t): 17 =3D DSA (example);

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e) Algorithm-spec= ific fields.

=C2=A0 =C2=A0 Algorithm-Specific Fields for DSA keys (example):<= /div>

= =C2=A0 =C2=A0 e.1) MPI of DSA prime p;
=C2=A0 =C2=A0 e.2) MPI of DSA group or= der q (q is a prime divisor of p-1);

=
=C2=A0 =C2=A0 e.3) MPI of DSA group gene= rator g;

=C2=A0 =C2=A0 e.4) MPI of DSA public-key value y (=3D g\*\*x mod p w= here x is secret).

Note that it is possible for there to be collisions of K= ey IDs -- two
different keys with the sam= e Key ID.=C2=A0 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
mat= erial, they will have different Key IDs as well as different
fingerprints.

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

## {12.3} V5 Fingerprint=C2=A0

A V5 Fingerprint is a 512 bit cryptographic = digest truncated to provide
a presentatio= n form that is a multiple of 25 bits. In the default presentation
format using BASE32 encoding, this gives a fingerp= rint that is a multiple
of five significa= nt characters.

The design of the V5 fingerprint format anticipates the possib= ile
introduction of additional presentati= on formats and the use of the same
finger= print format with other applications. For example the use of=C2=A0
a 2D barcode presentation format.

To enable this se= paration the calculation of the V5 digest value is described=C2=A0
separately from the presentation.

### {12.3.1} V5 K= ey Format

The key data over which the digest value is calculated is the same = as=C2=A0
the V4 key data field with the o= mmission of the creation timestamp.

<= /div>
<pgp-v5-key> =3D=C2=A0

a.1) 0x99 (1 octet)<= /div>

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 =3D 5 (1 octet);

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

d) Algorithm-specific fields.

### {12.3.2} V5 Fingerprint Digest Calcula= tion

A V5 fingerprint=C2=A0

The OpenPGP V5 fingerprint value is calculated as f= ollows

Fingerprint =3D <Version-ID> + H (<Content-ID> =C2=A0+ =E2=80= =98:=E2=80=99 + H(<data>))

Where:
Version-ID =3D 0x60

Content-ID =3D "applicat= ion/pgp-v5-key"=C2=A0
<<MIME Con= tent-Type string TBS by IANA>>

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

<data> =3D <pgp-v5-= key>

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

=
The Content-ID is a MIME content type id= entifier that indicates that
fingerprint = value is of data in the pgp-v5-key format specified=C2=A0
above and is intended for use with an OpenPGP applicatio= n.=C2=A0

If a fingerprint value is to be calculated for a public key value=C2= =A0
specified in a different format (e.g.= a PKIX certificate or key)
or for a futu= re 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 a= n integer multiple=C2=A0
of 25 bits regar= dless of the intended output presentation. Applications
MUST not use Fingerprint Values=C2=A0

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

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

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

### {12.3.3} V5 Fingerprint BASE32 Presentation

Except whe= re prevented by the affordances of the device on which it is deployed
=
(e.g. lacks keyboard), applications MUST suppo= rt generation and use of the
BASE32 Prese= ntation format.

The Truncated digest value is converted to BASE32.

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

Applications SHOULD accept V5 fingerprints with th= e dash characters ommitted.

Applications MUST accept V5 fingerprints with low= er case characters, treating
these as equ= ivalent to the corresponding upper case character.

### {12.3.4} V5 Fingerprin= t Strengthening.

When an application successfully authenticates a key against= a truncated=C2=A0
fingerprint, the appli= cation MAY record a longer presentation of the fingerprint
presentation for future use. This is called key strength= ening.

Wherever practical, applications SHOULD support the use of key strengt= hening.

For most purposes, strengthening to 250 bits offers a sufficient work= factor for
almost any application while l= imiting the resulting fingerprint to 59 characters.


--94eb2c0441ce52b11d053bcf7e0a-- From nobody Sun Sep 11 09:57:03 2016 Return-Path: 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 4722312B0D7 for ; Sun, 11 Sep 2016 09:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=no 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 i8Pbsp2LyIvu for ; Sun, 11 Sep 2016 09:56:59 -0700 (PDT) Received: from albireo.enyo.de (albireo.enyo.de [5.158.152.32]) (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 8B29D12B0E8 for ; Sun, 11 Sep 2016 09:56:58 -0700 (PDT) Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1bj83s-0001iK-04; Sun, 11 Sep 2016 18:56:56 +0200 Received: from fw by deneb.enyo.de with local (Exim 4.84_2) (envelope-from ) id 1bj83r-0000KD-O2; Sun, 11 Sep 2016 18:56:55 +0200 From: Florian Weimer To: "Neal H. Walfield" References: <87bnfdldo3.wl-neal@walfield.org> Date: Sun, 11 Sep 2016 18:56:55 +0200 In-Reply-To: <87bnfdldo3.wl-neal@walfield.org> (Neal H. Walfield's message of "Wed, 15 Jul 2015 16:05:00 +0200") Message-ID: <87h99mtlwo.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Mailing lists X-BeenThere: openpgp@ietf.org 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: Sun, 11 Sep 2016 16:57:01 -0000 * Neal H. Walfield: > The basic idea is to publish the list of subscribes as an OpenPGP > message. Concretely: > > To create a mailing list, the mailing list administrator generates a > new key pair in the usual way. > > Associated with the key pair is a list of encryption keys > (Public-Key Packet, tag 6, or Public-Subkey Packet, tag 14). Each > key may optionally be preceded by a user id (User ID packet, tag > 13). This list is stored in a signature subpacket with a new > subpacket type. An existing implementation of this feature uses signature subpacket 10 to specify fingerprints of additional keys to which messages shall be encrypted, in addition to the user-specified key. It was rejected for IETF standardization. From nobody Mon Sep 12 06:27:21 2016 Return-Path: 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 D3AC112B27E for ; Mon, 12 Sep 2016 06:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=inurbanus.nl 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 E89U_uSTAkgL for ; Mon, 12 Sep 2016 06:27:18 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 C73EF12B293 for ; Mon, 12 Sep 2016 06:27:13 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id v189so133598840vkv.1 for ; Mon, 12 Sep 2016 06:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inurbanus.nl; s=google-inurb; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4Tlx1ZpKFkffXmggYww+P/gLiaVG21WRgisOeWE6+JU=; b=VOCNhH4tOyrbdg952/So5TSKrLnJTNB7oJ5u2KQgIvZe9bMtpQQR+GrFZ4bYtvbA5u wFcCgOeggtlwDzuKRz5fw62irPTdTZzKulXsqjB2uLLargq0xr97jjPxgq0J3javZ/EL EfbXDRkxI0v7OVtfC//BtQCSMYRaaBV4I90ik= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4Tlx1ZpKFkffXmggYww+P/gLiaVG21WRgisOeWE6+JU=; b=TjFtmnr6RAlCuew37keWSFsR3H44hFGIYMdgRn+VZ5h9WA2p0AYcEZ+sXrqfviURcT ojXyAcZl5XIDnydxsUyOatZuCf6cxvWVSb7CN91xr0eF4P3i1Gsfy0KMhiB/G0SifwlC /VxWdgmt6uRQFYl/kyGaxrszhGSPM+9RC3xhL8qqPw19Att55ON5klX2UVwuDAZ4r6kf k2NZJDCxPcUeM0jy45GB0yQrOEbtSEZde7emGNeFeIIIhP0FSOn8HXp4iFbvFWYbAWAY 9SRzChsRmrdQgSLCtf/wenuw8mN0gehyB0gevPSR3jgHXZQuIq9D3Ih+uEhbYSM36hEn jBjQ== X-Gm-Message-State: AE9vXwPv884dUMGbG/79TyJL+KGpLakHhWSGGsUMQoWD6et/wpaLYUi9DRY7qommgqc8b15jCfqDmJbWZH/F/w== X-Received: by 10.31.109.65 with SMTP id i62mr10336572vkc.137.1473686832452; Mon, 12 Sep 2016 06:27:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.81.24 with HTTP; Mon, 12 Sep 2016 06:27:11 -0700 (PDT) In-Reply-To: References: From: Thijs van Dijk Date: Mon, 12 Sep 2016 15:27:11 +0200 Message-ID: To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=94eb2c096ef428abff053c4f74a7 Archived-At: Cc: IETF OpenPGP 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 13:27:20 -0000 --94eb2c096ef428abff053c4f74a7 Content-Type: text/plain; charset=UTF-8 Hi Phillip, As promised, I'll post my two cents' worth about your proposal. In your talk last Thursday, you've revealed some details about the larger design of which this V5 fingerprint proposal is a part. I can see now you weren't kidding when you described it as "encumbered." Though your talk was certainly interesting, I'll try and stay on topic and evaluate your proposal as a self-contained unit rather than as a tiny part of a larger design. To wit: +1 on dropping SHA-1 in favour of SHA-2. This is kind of a no-brainer. +1 on prepending a version number to the output for futureproofing. ?? on embedding a content-ID field in the final hash input. +1 on changing the default fingerprint representation from hex to base32. +1 on changing the definition of the short/long key ID to n bits from the start rather than from the end, so even the truncated versions will include the version ID. On the content-ID, it's unclear from the above draft which problem you're trying to solve. If I were to guess, I'd say it would open the door to unification of OpenPGP and X509 somewhat, but currently it's not obvious how exactly this fingerprint format would help. Could you elaborate a bit? -- Thijs van Dijk 6A94 F9A2 DFE5 40E3 067E C282 2AFE 9EFA 718B 6165 On 6 September 2016 at 06:47, Phillip Hallam-Baker wrote: > 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. > > [...] > --94eb2c096ef428abff053c4f74a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Phillip,

As promised, I'll post = my two cents' worth about your proposal.

In yo= ur talk last Thursday, you've revealed some details about the larger de= sign of which this V5 fingerprint proposal is a part. I can see now you wer= en't kidding when you described it as "encumbered." Though yo= ur talk was certainly interesting, I'll try and stay on topic and evalu= ate your proposal as a self-contained unit rather than as a tiny part of a = larger design.

To wit:

+1= on dropping SHA-1 in favour of SHA-2. This is kind of a no-brainer.
<= div>+1 on prepending a version number to the output for futureproofing.
?? on embedding a content-ID field in the final hash input.
+1 on changing the default fingerprint representation from hex to base32.=
+1 on changing the definition of the short/long key ID to n bits= from the start rather than from the end, so even the truncated versions wi= ll include the version ID.

On the content-ID, it&#= 39;s unclear from the above draft which problem you're trying to solve.=
If I were to guess, I'd say it would open the door to unific= ation of OpenPGP and X509 somewhat, but currently it's not obvious how = exactly this fingerprint format would help. Could you elaborate a bit?

--
Thijs van Dijk

6A94 F9A2 DFE5 40E3 067E =C2=A0C282 2A= FE 9EFA 718B 6165

On 6 September 2016 at 06:47, Phillip Hallam= -Baker <phill@hallambaker.com> wrote:
Here is the= revised proposed text. I am trying to work out what the instructions on us= ing 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 separatel= y and see if we can get the IPR sorted in time to use it. For the time bein= g it is not in the draft.

[...]
--94eb2c096ef428abff053c4f74a7-- From nobody Mon Sep 12 13:32:13 2016 Return-Path: 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 DB50F12B078 for ; Mon, 12 Sep 2016 13:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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, 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 aemwzQq6oyke for ; Mon, 12 Sep 2016 13:32:10 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 562D912B0F3 for ; Mon, 12 Sep 2016 13:32:09 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id l91so61509587qte.3 for ; Mon, 12 Sep 2016 13:32:09 -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:cc; bh=HNpFZ3gjySczb7XHkw9Iz2sRbWfCmDIL0log2sp6W6M=; b=KGaY9QKeV6FUIMgWXtCJVcWsp/XOmoE59tCcrmaj/QafRrkz8MOIQ5qO2CL/2b1jNF I1kG5Fj8Vk0h7x2cT5hBZIlxuBsbf8dZO6i6WVnFEw+ojpjk65dfGncRvPgwxx/NX6iG hSdxF3XXSRpyjjwqkUSI4XQAI5PvYZ3Hrxy5m8fDJHWRDfGNj5wEFxS8lT3fNQg4Df1W Uzh754CjQxpFY9rlj6oZ7PywArFlFmTGkiGE26wAMRzqylZ7mDkZVKYzwFvwq0QxrVrt qAI46ToXYW25u1Whk88cIx3jRGzG5CXUyBmIySpbi1WeO1ixNsWoDZpi2gR6Ipxvuba6 tl5g== 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:cc; bh=HNpFZ3gjySczb7XHkw9Iz2sRbWfCmDIL0log2sp6W6M=; b=Ef2tx+xYEA98OoJHB6QRRjt8kOeutYfIsrU1LkV9p9xH1lcRMIFoDaYEUodkvkhKtm G8Riufe6OMGn2RJrXaajVxHKQBHNUY9OeUXxISzklujo0HNkykbcQvSuxL+ifqHpM/6+ cz4tW2qtHEUx4Nsry4uXeF59a4iqjzUN76p/FSAMIUJBWbe9wVPaCzRLTLchHCvnchpg UEb3FZbp6gCzqQVB/OudEmaQIKXdCQZJAoqFvz6Qgt6gvswiZ36W03OpuEQc/O/+XDiq LVeJI4JvC83ZdEq0KXIpPXLxeA9OS+x6kGqfamm8GUe0sE9TN1EQKyHQxHvjdLwkn3Bv hnHQ== X-Gm-Message-State: AE9vXwMBRiT+1bdvYGod5famPNfCbDImDW1eIRZ1w4+nnYRTM41WToD/NBP8KE6THzyAmDx/BEa+lPKFAsOLcw== X-Received: by 10.237.41.2 with SMTP id s2mr21756543qtd.115.1473712328446; Mon, 12 Sep 2016 13:32:08 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.55.209.87 with HTTP; Mon, 12 Sep 2016 13:32:07 -0700 (PDT) In-Reply-To: References: From: Phillip Hallam-Baker Date: Mon, 12 Sep 2016 16:32:07 -0400 X-Google-Sender-Auth: O8hyNF3qlzjzo2vh9JjxSbgRkAc Message-ID: To: Thijs van Dijk Content-Type: multipart/alternative; boundary=94eb2c113d10d69eb3053c55630f Archived-At: Cc: IETF OpenPGP 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2016 20:32:12 -0000 --94eb2c113d10d69eb3053c55630f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Sep 12, 2016 at 9:27 AM, Thijs van Dijk wrote: > Hi Phillip, > > As promised, I'll post my two cents' worth about your proposal. > > In your talk last Thursday, you've revealed some details about the larger > design of which this V5 fingerprint proposal is a part. I can see now you > weren't kidding when you described it as "encumbered." Though your talk w= as > certainly interesting, I'll try and stay on topic and evaluate your > proposal as a self-contained unit rather than as a tiny part of a larger > design. > =E2=80=8BThe only part that I believe is encumbered is the 'work hardening'= scheme that is not currently in the drafts at all. All the rest is pretty well covered by prior art, albeit that is not an absolute guarantee.=E2=80=8B > To wit: > > +1 on dropping SHA-1 in favour of SHA-2. This is kind of a no-brainer. > +1 on prepending a version number to the output for futureproofing. > ?? on embedding a content-ID field in the final hash input. > +1 on changing the default fingerprint representation from hex to base32. > +1 on changing the definition of the short/long key ID to n bits from the > start rather than from the end, so even the truncated versions will inclu= de > the version ID. > > On the content-ID, it's unclear from the above draft which problem you're > trying to solve. > If I were to guess, I > =E2=80=8B=E2=80=8B > 'd say it would open the door to unification of OpenPGP and X509 somewhat= , > but currently it's not obvious how exactly this fingerprint format would > help. Could you elaborate a bit? > =E2=80=8BToday there are several formats that are regularly used to describ= e trust anchors: PGP Key format X.509 / PKIX root cert=E2=80=8B =E2=80=8BCertificate Trust List (Microsoft) SSH Public Key format SAML DNSSEC 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. The traditional way to solve this problem is with a URI type scheme: OpenPGP:mwj3e-wj3id-2kqai-2iwiq But that uses up a lot of bits and not for any real purpose because all you have is a fingerprint, you don't know how to interpret those bits. The idea of putting the content-type into the fingerprint calculation is that it allows each of the six applications described to make use of one fingerprint format without risk of someone working out how to cause a semantic attack by confusing one content type for another. It would of course be a bad thing if someone could generate an OpenPGP key that turns out to be a legal X.509v3 certificate. 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. --94eb2c113d10d69eb3053c55630f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Se= p 12, 2016 at 9:27 AM, Thijs van Dijk <schnabbel@inurbanus.nl>= wrote:
Hi Philli= p,

As promised, I'll post my two cents' worth ab= out your proposal.

In your talk last Thursday, you= 've revealed some details about the larger design of which this V5 fing= erprint proposal is a part. I can see now you weren't kidding when you = described it as "encumbered." Though your talk was certainly inte= resting, I'll try and stay on topic and evaluate your proposal as a sel= f-contained unit rather than as a tiny part of a larger design.
=

=E2=80=8BThe only part that I believe is encumbered is the = 9;work hardening' scheme that is not currently in the drafts at all. Al= l the rest is pretty well covered by prior art, albeit that is not an absol= ute guarantee.=E2=80=8B

=C2=A0
To wit:
=
+1 on dropping SHA-1 in favour of SHA-2. This is kind of a n= o-brainer.
+1 on prepending a version number to the output for fu= tureproofing.
?? on embedding a content-ID field in the final has= h input.
+1 on changing the default fingerprint representation fr= om hex to base32.
+1 on changing the definition of the short/long= key ID to n bits from the start rather than from the end, so even the trun= cated versions will include the version ID.

On the= content-ID, it's unclear from the above draft which problem you're= trying to solve.
If I were to guess, I
=E2=80=8B=E2=80=8B
'd = say it would open the door to unification of OpenPGP and X509 somewhat, but= currently it's not obvious how exactly this fingerprint format would h= elp. Could you elaborate a bit?

=E2=80=8BToday ther= e are several formats that are regularly used to describe trust anchors:

PGP Key format
X.509 / PKIX root cert=E2= =80=8B
=E2=80= =8BCertificate Trust List (Microsoft)
SSH Public Key format
SAML=C2=A0
DNSSEC

It would be really nice if we could all use the same format to iden= tify a root of trust. But that is of course not going to happen unless we c= an get all six of the major PKI infrastructures to agree on one approach an= d that probably isn't even desirable.

The traditional way to solve this problem is with a UR= I type scheme:
=
OpenPGP:mw= j3e-wj3id-2kqai-2iwiq

But= that uses up a lot of bits and not for any real purpose because all you ha= ve is a fingerprint, you don't know how to interpret those bits.
<= div class=3D"gmail_default" style=3D"font-size:small">
The idea of putting the conten= t-type into the fingerprint calculation is that it allows each of the six a= pplications described to make use of one fingerprint format without risk of= someone working out how to cause a semantic attack by confusing one conten= t type for another. It would of course be a bad thing if someone could gene= rate an OpenPGP key that turns out to be a legal X.509v3 certificate.
=


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 lik= e without having to use up any of those scarce fingerprint version IDs.=C2= =A0



=C2=A0
--94eb2c113d10d69eb3053c55630f-- From nobody Wed Sep 14 07:20:22 2016 Return-Path: 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 3712C12B38A for ; Wed, 14 Sep 2016 07:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=inurbanus.nl 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 JGdsKBOsIGGj for ; Wed, 14 Sep 2016 07:20:17 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 0B0D012B9F7 for ; Wed, 14 Sep 2016 06:39:36 -0700 (PDT) Received: by mail-yw0-x233.google.com 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; d=inurbanus.nl; 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; d=1e100.net; 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 10.13.234.8 with SMTP id t8mr2446248ywe.170.1473860376076; Wed, 14 Sep 2016 06:39:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.0.71 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-BeenThere: openpgp@ietf.org 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 --94eb2c0872da2a57a8053c77dce6 Content-Type: text/plain; charset=UTF-8 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? -Thijs [1]: A tale as old as time - https://xkcd.com/927/ [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". --94eb2c0872da2a57a8053c77dce6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Phillip,

Thanks for clearing that up.
=C2=A0
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 unl= ess we can get all six of the major PKI infrastructures to agree on one app= roach and that probably isn't even desirable.

Yes. Out of curiosity, are you currently wor= king 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 sta= ndard. [1]

The other reason for having the conte= nt-id in is to allow versioning within OpenPGP. So for example, lets say th= at there is a V6 key format but we don't want to change the digest valu= e. 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.<= /div>

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 ca= se 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 no= w 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 b= ack is that the Public-Key Encrypted Session Key packet now only has 24 use= ful bits of key ID, down from 32. I don't think this will be problemati= c since the probability of a collision is negligible in normal use [2], and= the opportunities for malice are very limited [3]. Furthermore, it could g= o hand in hand with removing the key ID from the PKESK altogether and defau= lting to "anonymous" encryption / trial decryption - of which I w= ould be in favour. Nonetheless, it's something to keep in mind.


About the text, the last paragraph feels out of pla= ce. Did you add it in anticipation of many backreferences to the term "= ;fingerprint strengthening" [4], or are you just describing client beh= aviour? In my understanding, most operations (verifying a signature, encryp= ting to someone, etc. [5]) will require one to have the full public key any= way, 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 SH= OULD use the full fingerprint for verification.
```

Your thoughts?


-Thijs


[1]: A tale as old as time -=C2=A0https://xkcd.com/927/
[2]: One would need 2^12+ private keys in their keyring in order to b= e affected by this (down from 2^16).
[3]: A= t best, an attacker could force many trial decrypts.
[4]: Or "key strengthening". Are those terms interchang= eable?
[5]: In fact, any operation which is= n't "select a key from my keyring" or "download and impo= rt a key from a keyserver".
--94eb2c0872da2a57a8053c77dce6-- From nobody Thu Sep 15 02:33:16 2016 Return-Path: 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 3377912B215 for ; Thu, 15 Sep 2016 02:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no 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 AXHOuJnw2Li8 for ; Thu, 15 Sep 2016 02:33:13 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 6213E12B223 for ; Thu, 15 Sep 2016 02:33:13 -0700 (PDT) Received: from p50813126.dip0.t-ipconnect.de ([80.129.49.38] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1bkT2b-0001Ym-0m for openpgp@ietf.org; Thu, 15 Sep 2016 09:33:09 +0000 Date: Thu, 15 Sep 2016 11:33:10 +0200 Message-ID: <87mvj9mrs9.wl-neal@walfield.org> From: "Neal H. Walfield" To: IETF OpenPGP User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [openpgp] Signer's User ID X-BeenThere: openpgp@ietf.org 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: Thu, 15 Sep 2016 09:33:15 -0000 RFC 4880 says: 5.2.3.22. Signer's User ID (String) This subpacket allows a keyholder to state which User ID is responsible for the signing. Many keyholders use a single key for different purposes, such as business communications as well as personal communications. This subpacket allows such a keyholder to state which of their roles is making a signature. This subpacket is not appropriate to use to refer to a User Attribute packet. In GnuPG, we use the user id's email address. Thus, if a key has the user id "Neal H. Walfield" , and the user runs: echo data to sign | gpg --default-key neal@walfield.org -s or echo data to sign | gpg --default-key 'Neal H. Walfield' -s Then, in both cases we include this subpacket in the signature packet with the string "neal@walfield.org". Note: we use data for locating the key via DANE or WKS as well as in our TOFU implementation to identify the intended binding. Since, IMO, the spec is unclear about the contents of this field and Werner pointed out that another implementation could reasonably use the hash of the user id here, I think it makes sense to clarify exactly what is expected to increase interoperability. My proposal to standardize GnuPG's behavior is: 5.2.3.22. Signer's User ID (String) This subpacket allows a keyholder to state which User ID is responsible for the signing. Many keyholders use a single key for different purposes, such as business communications as well as personal communications. This subpacket allows such a keyholder to * state which of their roles is making a signature. The value of * this subpacket is a byte-for-byte copy of the RFC 2822 mail name-addr * portion of the User ID. This subpacket is not appropriate to use to refer to a User Attribute packet. Thanks, :) Neal From nobody Thu Sep 15 03:24:04 2016 Return-Path: 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 03CA212B244 for ; Thu, 15 Sep 2016 03:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=inurbanus.nl 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 oMi4os9-pm0j for ; Thu, 15 Sep 2016 03:23:56 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 BDD0F12B231 for ; Thu, 15 Sep 2016 03:23:56 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id h134so19165105vkd.2 for ; Thu, 15 Sep 2016 03:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inurbanus.nl; s=google-inurb; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eI2k+4vI6CKGHucfRxfAOUYDpg3tlVHCugQgY3yitm4=; b=Ab/yZr3i8b9gIGnd+zLiG3CddOn3l3+Sh80Xik/C7hjT8xq8PzVHch5J5+wDvbWHBQ zM7pGJBHHYOu4brmbL8BIPAHcPCvC9QTeyZGAXCC0H58xsjBN1vl4mIjHmV+/9Bg5Jyz KWKBkSA997zttKuneonI/xJ+BforQEX5YJ6g0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eI2k+4vI6CKGHucfRxfAOUYDpg3tlVHCugQgY3yitm4=; b=LGkopP9F9SB97UuO8dDYh/nt74bD4kagpQ3vqD9j+IuFyuxT5M07Uj7UJeWI4xiIJq kIPi5GTlbDWWM8DsVr5iF485dk77QE+ZGYSdhCUaqc08kqv5z71DSYInH+iUt4Jka+bt 16QVcz7sAUXfdDdl5vI6VHSlQn2ZRScSir8blAqKBLc62LR+zzOdxS8yuhn0LC0V6ame QEWBAZgP+08iT39O8CLnM2uauvZ1peU0YwPNBoMUywTtBr6QHj6DgxqT5lE3EgcfsMNc utzd11OdFmLE4GcmjsSsMgrGIM3uB1plJjw0EThe2ul6vVVtMvQxcyrwPqV5gkkM9ANs qIEA== X-Gm-Message-State: AE9vXwP+cCvHFB8uv9SiEajXjdq2R2JY2RvApDACORVHs0h4PNg8+Zq46GUBTxjLlCYM7KOc5vIPrhCZi4WUXw== X-Received: by 10.31.51.195 with SMTP id z186mr1946492vkz.137.1473935035823; Thu, 15 Sep 2016 03:23:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.0.71 with HTTP; Thu, 15 Sep 2016 03:23:55 -0700 (PDT) In-Reply-To: <87mvj9mrs9.wl-neal@walfield.org> References: <87mvj9mrs9.wl-neal@walfield.org> From: Thijs van Dijk Date: Thu, 15 Sep 2016 12:23:55 +0200 Message-ID: To: "Neal H. Walfield" Content-Type: multipart/alternative; boundary=001a1144abcc3b9303053c893e28 Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Signer's User ID X-BeenThere: openpgp@ietf.org 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: Thu, 15 Sep 2016 10:24:03 -0000 --001a1144abcc3b9303053c893e28 Content-Type: text/plain; charset=UTF-8 Good catch. I think being explicit about the expected contents of this packet also makes the next sentence redundant (the one that prohibits embedding a UAT). -Thijs -- Thijs van Dijk 6A94 F9A2 DFE5 40E3 067E C282 2AFE 9EFA 718B 6165 On 15 September 2016 at 11:33, Neal H. Walfield wrote: > RFC 4880 says: > > 5.2.3.22. Signer's User ID > > (String) > > This subpacket allows a keyholder to state which User ID is > responsible for the signing. Many keyholders use a single key for > different purposes, such as business communications as well as > personal communications. This subpacket allows such a keyholder to > state which of their roles is making a signature. > > This subpacket is not appropriate to use to refer to a User Attribute > packet. > > In GnuPG, we use the user id's email address. Thus, if a key has the > user id "Neal H. Walfield" , and the user runs: > > echo data to sign | gpg --default-key neal@walfield.org -s > > or > > echo data to sign | gpg --default-key 'Neal H. Walfield' -s > > Then, in both cases we include this subpacket in the signature packet > with the string "neal@walfield.org". > > > Note: we use data for locating the key via DANE or WKS as well as in > our TOFU implementation to identify the intended binding. > > > Since, IMO, the spec is unclear about the contents of this field and > Werner pointed out that another implementation could reasonably use > the hash of the user id here, I think it makes sense to clarify > exactly what is expected to increase interoperability. My proposal to > standardize GnuPG's behavior is: > > 5.2.3.22. Signer's User ID > > (String) > > This subpacket allows a keyholder to state which User ID is > responsible for the signing. Many keyholders use a single key for > different purposes, such as business communications as well as > personal communications. This subpacket allows such a keyholder to > * state which of their roles is making a signature. The value of > * this subpacket is a byte-for-byte copy of the RFC 2822 mail name-addr > * portion of the User ID. > > This subpacket is not appropriate to use to refer to a User Attribute > packet. > > Thanks, > > :) Neal > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp > --001a1144abcc3b9303053c893e28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Good catch. I think being explicit about the expected cont= ents of this packet also makes the next sentence redundant (the one that pr= ohibits embedding a UAT).

-Thijs

--
Thijs van= Dijk

6A94 F9A2 DFE5 40E3 067E =C2=A0C282 2AFE 9EFA 718= B 6165

On 15 September 2016 at 11:33, Neal H. Walfi= eld <neal@walfield.org> wrote:
RFC 4880 says:

=C2=A0 5.2.3.22.=C2=A0 Signer's User ID

=C2=A0 =C2=A0(String)

=C2=A0 =C2=A0This subpacket allows a keyholder to state which User ID is =C2=A0 =C2=A0responsible for the signing.=C2=A0 Many keyholders use a singl= e key for
=C2=A0 =C2=A0different purposes, such as business communications as well as=
=C2=A0 =C2=A0personal communications.=C2=A0 This subpacket allows such a ke= yholder to
=C2=A0 =C2=A0state which of their roles is making a signature.

=C2=A0 =C2=A0This subpacket is not appropriate to use to refer to a User At= tribute
=C2=A0 =C2=A0packet.

In GnuPG, we use the user id's email address.=C2=A0 Thus, if a key has = the
user id "Neal H. Walfield" <neal@walfield.org>, and the user runs:

=C2=A0 echo data to sign | gpg --default-key neal@walfield.org -s

or

=C2=A0 echo data to sign | gpg --default-key 'Neal H. Walfield' -s<= br>
Then, in both cases we include this subpacket in the signature packet
with the string "neal@walfield.or= g".


Note: we use data for locating the key via DANE or WKS as well as in
our TOFU implementation to identify the intended binding.


Since, IMO, the spec is unclear about the contents of this field and
Werner pointed out that another implementation could reasonably use
the hash of the user id here, I think it makes sense to clarify
exactly what is expected to increase interoperability.=C2=A0 My proposal to=
standardize GnuPG's behavior is:

=C2=A0 5.2.3.22.=C2=A0 Signer's User ID

=C2=A0 =C2=A0(String)

=C2=A0 =C2=A0This subpacket allows a keyholder to state which User ID is =C2=A0 =C2=A0responsible for the signing.=C2=A0 Many keyholders use a singl= e key for
=C2=A0 =C2=A0different purposes, such as business communications as well as=
=C2=A0 =C2=A0personal communications.=C2=A0 This subpacket allows such a ke= yholder to
*=C2=A0 state which of their roles is making a signature.=C2=A0 The value o= f
*=C2=A0 this subpacket is a byte-for-byte copy of the RFC 2822 mail name-ad= dr
*=C2=A0 portion of the User ID.

=C2=A0 =C2=A0This subpacket is not appropriate to use to refer to a User At= tribute
=C2=A0 =C2=A0packet.

Thanks,

:) Neal

_______________________________________________
openpgp mailing list
openpgp@ietf.org
https://www.ietf.org/mailman/listinfo/openpgp<= br>

--001a1144abcc3b9303053c893e28-- From nobody Thu Sep 15 03:25:01 2016 Return-Path: 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 72D2F12B231 for ; Thu, 15 Sep 2016 03:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no 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 3BnNgF5witNJ for ; Thu, 15 Sep 2016 03:24:58 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id DCCC912B138 for ; Thu, 15 Sep 2016 03:24:57 -0700 (PDT) Received: from p50813126.dip0.t-ipconnect.de ([80.129.49.38] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1bkTqf-0003hr-Q7; Thu, 15 Sep 2016 10:24:53 +0000 Date: Thu, 15 Sep 2016 12:24:55 +0200 Message-ID: <87lgytmpe0.wl-neal@walfield.org> From: "Neal H. Walfield" To: Thijs van Dijk In-Reply-To: References: <87mvj9mrs9.wl-neal@walfield.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Signer's User ID X-BeenThere: openpgp@ietf.org 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: Thu, 15 Sep 2016 10:24:59 -0000 On Thu, 15 Sep 2016 12:23:55 +0200, Thijs van Dijk wrote: > Good catch. I think being explicit about the expected contents of this > packet also makes the next sentence redundant (the one that prohibits > embedding a UAT). Good point. :) Neal From nobody Sat Sep 17 14:43:12 2016 Return-Path: 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 97E20126D74 for ; Sat, 17 Sep 2016 14:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.697 X-Spam-Level: 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: 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 BfDDKF-sDyl1 for ; Sat, 17 Sep 2016 14:43:08 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 7BDEB128B38 for ; Sat, 17 Sep 2016 14:43:08 -0700 (PDT) Received: by mail-qk0-x22f.google.com 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; d=gmail.com; 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; d=1e100.net; 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 10.233.223.198 with SMTP id t189mr21570735qkf.58.1474148587578; Sat, 17 Sep 2016 14:43:07 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.55.209.87 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-BeenThere: openpgp@ietf.org 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 --94eb2c04448ee8ac1a053cbaf68e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Sep 14, 2016 at 9:39 AM, Thijs van Dijk wrote: > 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 g= et >> all six of the major PKI infrastructures to agree on one approach and th= at >> 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] > =E2=80=8BThat 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.=E2=80=8B =E2=80=8BThe SMIME group has been talking about a fingerprint mode. There i= s 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 thing.=E2=80=8B > 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 b= ut >> we don't want to change the digest value. We can change the OpenPGP cont= ent >> 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 documen= t > 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. > =E2=80=8BThe 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.=E2=80=8B > Also, one other consequence of prepending a version ID to a key > fingerprint and reading the key ID from the start of the fingerprint rath= er > than the back is that the Public-Key Encrypted Session Key packet now onl= y > has 24 useful bits of key ID, down from 32. > =E2=80=8BWhich bits OpenPGPv5 uses for the session key can be defined separ= ately. Since the key must be a v5 key, there is no need for a version ID.=E2=80=8B About the text, the last paragraph feels out of place. Did you add it in > anticipation of many backreferences to the term "fingerprint strengthenin= g" > [4], or are you just describing client behaviour? In my understanding, mo= st > 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: > =E2=80=8BI added it out of my usual intent to create as wide a prior art tr= ail as possible in developing a spec.=E2=80=8B ``` > 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? > =E2=80=8BI think we should kill fingerprints with a work factor of less tha= n 2^92 =E2=80=8B =E2=80=8Bas unsafe.=E2=80=8B No matter what, they just keep coming back and= biting in bad ways. --94eb2c04448ee8ac1a053cbaf68e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Se= p 14, 2016 at 9:39 AM, Thijs van Dijk <schnabbel@inurbanus.nl>= wrote:
Hi Phillip,
Thanks for clearing that up.
=C2=A0<= /div>
It would be really nice if we could all use the same format to ident= ify a root of trust. But that is of course not going to happen unless we ca= n 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 worki= ng 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 stand= ard. [1]

=E2=80=8BThat 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 OpenPG= P fingerprint. So designing that so that other applications can use the sam= e spec is no additional cost.=E2=80=8B

=E2=80=8BThe 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 Open= PGP so it is logical to expect them to do the same thing.=E2=80=8B

=C2=A0
=
The other reason for having the content-id in is to allow ve= rsioning within OpenPGP. So for example, lets say that there is a V6 key fo= rmat but we don't want to change the digest value. We can change the Op= enPGP content definition format as many times as we like without having to = use up any of those scarce fingerprint version IDs.
=

Ah, so the v= ersion ID pertains to the fingerprint method only and not the underlying ke= y? That's good to know, and probably a good thing to document for poste= rity 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 k= eys in full.

=E2=80=8BThe current design neither fo= rces 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 anyw= ay.=E2=80=8B
=C2=A0
Also, one other consequence of= prepending a version ID to a key fingerprint and reading the key ID from t= he start of the fingerprint rather than the back is that the Public-Key Enc= rypted Session Key packet now only has 24 useful bits of key ID, down from = 32.

=E2=80=8BWhich bits OpenPGPv5 uses for the ses= sion key can be defined separately. Since the key must be a v5 key, there i= s no need for a version ID.=E2=80=8B


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

=E2=80=8BI added it out of my usual intent to create as wide a prior= art trail as possible in developing a spec.=E2=80=8B

<= br>
```
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 SH= OULD use the full fingerprint for verification.
```

Your thoughts?


=E2= =80=8BI think we should kill fingerprints with a work factor of less than 2= ^92 =E2=80=8B
=E2=80=8Bas unsafe.=E2=80=8B No matter what, they just keep c= oming back and biting in bad ways.

--94eb2c04448ee8ac1a053cbaf68e-- From nobody Mon Sep 19 03:36:16 2016 Return-Path: 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 9B8C112B0CB for ; Mon, 19 Sep 2016 03:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=inurbanus.nl 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 Ly39RilPiyZO for ; Mon, 19 Sep 2016 03:36:13 -0700 (PDT) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (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 8D09412B11C for ; Mon, 19 Sep 2016 03:36:06 -0700 (PDT) Received: by mail-yb0-x230.google.com 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; d=inurbanus.nl; 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; d=1e100.net; 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 10.37.87.10 with SMTP id l10mr24202887ybb.133.1474281365662; Mon, 19 Sep 2016 03:36:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.0.71 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-BeenThere: openpgp@ietf.org 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 --001a113fdef819b836053cd9e149 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 17 September 2016 at 23:43, Phillip Hallam-Baker wrote: > =E2=80=8BThat 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 conten= t >>> 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 th= e >> underlying key? That's good to know, and probably a good thing to docume= nt >> 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 fingerprin= t >> belongs to a v5 or a v6 key even if we keep the hash format the same, bu= t I >> see now that that isn't going to be possible without downloading the key= s >> in full. >> > > =E2=80=8BThe current design neither forces the version ID to stay the sam= e 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.=E2=80=8B > 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. =E2=80=8BI think we should kill fingerprints with a work factor of less tha= n 2^92 =E2=80=8B > =E2=80=8Bas unsafe.=E2=80=8B No matter what, they just keep coming back a= nd 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 fingerprints.) 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. -Thijs --001a113fdef819b836053cd9e149 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 7 September 2016 at 23:43, Phillip Hallam-Baker <phill@hallambaker.com= > wrote:
<= div style=3D"font-size:small">=E2=80=8BThat is a really bad cartoon to brin= g 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 c= hange the OpenPGP content definition format as many times as we like withou= t having to use up any of those scarce fingerprint version IDs.
=

Ah, so the v= ersion ID pertains to the fingerprint method only and not the underlying ke= y? That's good to know, and probably a good thing to document for poste= rity 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 k= eys in full.

=E2=80=8BThe 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 chang= e in digest algorithm. Which is probably the thing that would lead to a V6 = format anyway.=E2=80=8B

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

=E2=80=8BI think we should= kill fingerprints with a work factor of less than 2^92 =E2=80=8B
=E2=80=8Bas unsafe.=E2=80=8B No m= atter what, they just keep coming back and biting in bad ways.
<= /div>

Fair enough.
At= the other end of the spectrum, do you have any thoughts on what we can con= sider 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 recommendat= ion for what is an appropriate level of assurance? (E.g. 250 bits - 10 grou= ps of 5 base32 characters, similar in size and grouping to V4 fingerprints.= )


Apart from this, you'll be gl= ad 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 poi= nt.

-Thijs
--001a113fdef819b836053cd9e149-- From nobody Mon Sep 19 06:24:27 2016 Return-Path: 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 CED1C12B05A for ; Mon, 19 Sep 2016 06:24:25 -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 HUMQ7bKEp16N for ; Mon, 19 Sep 2016 06:24:16 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 274E712B0ED for ; Mon, 19 Sep 2016 06:24:16 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id t7so145958427qkh.2 for ; Mon, 19 Sep 2016 06:24:16 -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:cc; bh=5b5OKg2LhESR8ed8MEVOgW/xL4GoCX0u2EwKoqa9zx0=; b=AzJ/x3Ng5v5I2hrdajGnAkCo/6IRA7g3Ky5Gryw113X/WjJjgBNAPMfmLlkr9J4w58 WidSCOUgPq8kyhYjkZUW8KS8lEHFhJnp1HBy59HHkTU9ycs7cXpEXEFaBgE2w/cDFzZn YUdlYxfCuDiMLjlME31e1fXS5jVFLaWkRTG9M8tmmwA1vcus5/jGHprv5Ph/uLqN4PJU 0HQNeHmwqK5iBBNJuu9t2zRcfy2rbObPkKVX6ye/Y/y4lE74oqovUks+jdp3UeJqW7Pk HmCoai/mZTGknsbuD/S9LPTqI8FBBZBajrKcsMx2ey9hYrbXvv0dv+zz2/VMHc7YBlWf i7GQ== 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:cc; bh=5b5OKg2LhESR8ed8MEVOgW/xL4GoCX0u2EwKoqa9zx0=; b=R/Jc8IsPTKMidjUv1oWVtjucPI3FeXnvlLry8NREObOnbbpbe+hYxHjSb6+O5PCJl/ JR3ZQq3RNjOxocOdTjU0v8yS2JZsMBwKOQTx+HEX6xxaQdAsQdu5/84dNKfOJe6wDgG8 bn9biBQSGENlL6TqS3K4u1fCDe96L8W9WfOZFm23se0YqsqX6Q2RmjlIHjRETWTMvyie Twu3Z3Cy3A0d3Zrjd0NvdztVoZv+i5LGQCGE+DWUzqBBenWCGutt+1AYA75/EdHiEO1W b9Ibrnof8NKnbP/84rjSJWYxhKQ1IULRhxUl2ie+H5SkTaM+0W6i7hzzfRtjnXq23ALV zIZw== X-Gm-Message-State: AE9vXwNR08jlv1rATR0I9D2rjBlsKiAPvW/rdEl9TarpuD+hxiv63Yq24KPJ/T+X9Eh0Xotx0MBqYEc/QlF/9g== X-Received: by 10.55.6.8 with SMTP id 8mr30329538qkg.5.1474291455331; Mon, 19 Sep 2016 06:24:15 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.55.209.87 with HTTP; Mon, 19 Sep 2016 06:24:14 -0700 (PDT) In-Reply-To: References: From: Phillip Hallam-Baker Date: Mon, 19 Sep 2016 09:24:14 -0400 X-Google-Sender-Auth: dp-KJXoR4MUdB9beFzgjLB3Tovg Message-ID: To: Thijs van Dijk Content-Type: multipart/alternative; boundary=001a114da1127d987f053cdc3a1e Archived-At: Cc: IETF OpenPGP 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 13:24:26 -0000 --001a114da1127d987f053cdc3a1e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Sep 19, 2016 at 6:36 AM, Thijs van Dijk wrote: > On 17 September 2016 at 23:43, Phillip Hallam-Baker > wrote: > >> =E2=80=8B >> > 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.=E2=80=8B >> > > 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. > =E2=80=8BYep, if it wasn't for the fact that we need to get rid of the issu= e time and use SHA2 and Base32, maybe we wouldn't =E2=80=8Bbe doing it now. I hope OpenPGPv6 won't need to rev the format. > =E2=80=8BI think we should kill fingerprints with a work factor of less t= han 2^92 =E2=80=8B >> =E2=80=8Bas unsafe.=E2=80=8B 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 lengt= h > 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 > fingerprints.) > =E2=80=8BI think that for virtually all purposes, a 50+9 character (i.e. 2^= 242 work factor) fingerprint is sufficient.=E2=80=8B I don't see more being useful u= nless you are really keen on keeping the full 256WF of AES-256. This is a manageable length for configuration files (looking at you SSH). So yesterday, I was working on a IoT project to develop a secure means of controlling the garage door etc. on the house. The config file looks like: Remote1 =3D M5VWK-ZTIO5-WGWZL-GNRVX-OZLGN-RVXOZ-LGNJW-GW53K-MVTGY-2LKNR Remote2 =3D MF3WU-23FNR-VWU4L-XMVTG-Y23RN-J3WK3-DGNNY-XO3DL-MVTGU-3DLOF ... In this case the remote is currently a Teensy 3.2 device ($12) that has a 32 bit processor and so I am using public key (cos I can). But I might well want to use a Kerberos type approach and a cheaper CPU (Arduino Nano, $1.30) instead. I can still use the same approach to authenticate and authorize the remote. Note that the configuration file does not need to specify the type of key because that will be specified when the public portion of the key is presented. Whether that is a Curve25529 key or a Kerberos ticket, the message that presents the public key will specify what it is. I could well see the same approach for SSH authorized_keys files. In fact my project for this morning/week is to get something like this working: mesh M5VWK-ZTIO5-WGWZL-GNRVX-OZLGN-RVXOZ-LGNJW-GW53K-MVTGY-2LKNR ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA0KJDLOiiXj9XdMxiCT9Kv =E2=80=8B... (5000 chars).. ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAywWhrwq4FjHt+UuwZcZ =E2=80=8B... (5000 chars).. =E2=80=8BThe first lines is the actual trust anchor which is a fingerprint = of a master key of a mesh profile. This is a long term (100 year) key and is not expected to change. The next two lines are keys that have been fetched from the mesh and are the latest SSH keys for the two devices the user has connected to that profile for SSH use. =E2=80=8BThe equivalent for OpenPGP would be to manually edit your keyring.= In this case Carol enters the following: alice@example.com M5VWK-ZTIO5-WGWZL-GNRVX-OZLGN-RVXOZ-LGNJW-GW53K-MVTGY-2LKNR bob@example.com =E2=80=8BMF3WU-23FNR-VWU4L-XMVTG When a mail from Bob is received, the mail client updates its copy of the keyring with the strengthened fingerprint: alice@example.com M5VWK-ZTIO5-WGWZL-GNRVX-OZLGN-RVXOZ-LGNJW-GW53K-MVTGY-2LKNR bob@example.com =E2=80=8BMF3WU-23FNR-VWU4L-XMVTG-Y23RN-J3WK3-DGNNY-XO3DL-MV= TGU-3DLOF 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. > =E2=80=8BThanks for doing so.=E2=80=8B --001a114da1127d987f053cdc3a1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = Mon, Sep 19, 2016 at 6:36 AM, Thijs van Dijk <schnabbel@inurbanus.nl= > wrote:
On 17 September 2016 at 23:43, Phillip Hallam-Baker = <phill@hallam= baker.com> wrote:
=E2=80=8B
<= /div>
The only thing that = forces a change of VersionID is a change in digest algorithm. Which is prob= ably the thing that would lead to a V6 format anyway.=E2=80=8B
<= /div>

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

=E2=80=8BYep, if it wasn't for the fact that we need to get ri= d of the issue time and use SHA2 and Base32, maybe we wouldn't =E2=80= =8Bbe doing it now. I hope OpenPGPv6 won't need to rev the format.
=C2=A0
=E2= =80=8BI think we should kill fingerprints with a work factor of less than 2= ^92 =E2=80=8B
=E2=80=8Ba= s unsafe.=E2=80=8B 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 a= ny thoughts on what we can consider the "full" fingerprint? This = scheme has an implied maximum length of 500 bits (the largest multiple of 2= 5 less than 512+8). Apart from specifying a minimum (100 bits), do you thin= k we should make a recommendation for what is an appropriate level of assur= ance? (E.g. 250 bits - 10 groups of 5 base32 characters, similar in size an= d grouping to V4 fingerprints.)
=E2=80= =8BI think that for virtually all purposes, a 50+9 character (i.e. 2^242 wo= rk factor) fingerprint is sufficient.=E2=80=8B I don't see more being u= seful unless you are really keen on keeping the full 256WF of AES-256.

This is a manageable length f= or configuration files (looking at you SSH). So yesterday, I was working on= a IoT project to develop a secure means of controlling the garage door etc= . on the house. The config file looks like:

Remote1 =3D M5VWK-ZTIO5-WGWZL-GNRVX-OZLGN-RVXOZ-LGNJW-= GW53K-MVTGY-2LKNR
Remote2 =3D MF3WU-23FNR-VWU4L-XMVTG-Y23RN-J3WK3-DGNNY-XO3DL-MVTGU-3DLOF<= /div>
...
=

In this case the remote i= s currently a Teensy 3.2 device ($12) that has a 32 bit processor and so I = am using public key (cos I can). But I might well want to use a Kerberos ty= pe approach and a cheaper CPU (Arduino Nano, $1.30) instead. I can still us= e the same approach to authenticate and authorize the remote.

Note that the configuration file does = not need to specify the type of key because that will be specified when the= public portion of the key is presented. Whether that is a Curve25529 key o= r a Kerberos ticket, the message that presents the public key will specify = what it is.

I could well see the sa= me approach for SSH authorized_keys files. In fact my project for this morn= ing/week is to get something like this working:

mesh M5VWK-ZTIO5-WGWZL-GNRVX-OZLGN-RVXOZ-LGNJW-GW53K= -MVTGY-2LKNR
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA0KJDLOiiXj= 9XdMxiCT9Kv
=E2=80=8B... (5000 chars)..

ssh-rsa AAAAB3NzaC1yc= 2EAAAABIwAAAIEAywWhrwq4FjHt+UuwZcZ
=E2=80=8B... (5000 chars)..


=E2=80=8BThe first = lines is the actual trust anchor which is a fingerprint of a master key of = a mesh profile. This is a long term (100 year) key and is not expected to c= hange. The next two lines are keys that have been fetched from the mesh and= are the latest SSH keys for the two devices the user has connected to that= profile for SSH use.


=E2=80=8BThe equivalent for= OpenPGP would be to manually edit your keyring. In this case Carol enters = the following:
=
alice@example.com M5VWK-ZTIO5-WGWZL-GNRVX-OZ= LGN-RVXOZ-LGNJW-GW53K-MVTGY-2LKNR
bob@example.com= =E2=80=8BMF3WU-23FNR-VWU4L-XMVTG

When a mail from Bob is received, the mail client updates its co= py of the keyring with the strengthened fingerprint:

alice@example.com M5VWK-ZTIO5-WG= WZL-GNRVX-OZLGN-RVXOZ-LGNJW-GW53K-MVTGY-2LKNR
bob@example.com =E2=80=8BMF3WU-= 23FNR-VWU4L-XMVTG-Y23RN-J3WK3-DGNNY-XO3DL-MVTGU-3DLOF

<= /div>

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

=E2=80=8BThanks for doing so.=E2=80=8B
=C2=A0
<= br>

--001a114da1127d987f053cdc3a1e-- From nobody Mon Sep 19 09:24:53 2016 Return-Path: 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 25A1612B419 for ; Mon, 19 Sep 2016 09:24:51 -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 4wbBUuNo0ewQ for ; Mon, 19 Sep 2016 09:24:49 -0700 (PDT) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (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 2EEAA12B106 for ; Mon, 19 Sep 2016 09:24:48 -0700 (PDT) Received: by mail-qk0-x243.google.com with SMTP id w204so10038989qka.2 for ; Mon, 19 Sep 2016 09:24:48 -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:cc; bh=xaGLVeQ+7R+6f0117KTwsEy+ZXSEMCOb3+36RViVnVk=; b=jWgrJ/75gjPce0i099YByjmFGBKrmVV4syk+tQefCYvxU1VYH45+2Nh3/Tavu9y1cE oFLZlMKxN01ZLZgkIHMMqAxeaiBNt95zd4vQNhW/+kSHeSDdB5hTbPigIGx2wOX8F6Au 0ItY5//LNspDZrrMUatZ1f0k8ODSFmFIqBZCq5KTALJDn0e3j+kKFVmkIloj6P+599pO kPW7EWBf9/uP6v2n1AS1EOtIhZSUus1Hl3tQVbKIWn/Fsf3SRKaePjY8YuX2ub/x6CRL 6ekx6TOj1p4a0SqG46nx/+DCcujOcT+bspmm2WG2hactQtr+wrGF6uMopgGAUPd5y/B3 vYPA== 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:cc; bh=xaGLVeQ+7R+6f0117KTwsEy+ZXSEMCOb3+36RViVnVk=; b=gm9ArqVJMdknr3pCJy76WiVOEm6wFfgdbw6jbzYBdA/V2cMCefpJvAaMIoyD4URVlI 9nVB3xyGBd5nSNbShneCJ426mHgsa4rl0RW5bMXtp9cxmUnIWnq9rgPsgW1RwtJEvKgG A86j7jaeuGOcWNq2Y75/sKUWvHB9Sdq/BUThN6weckvB8y9n6rH5tmUBzDpLuv8Nuz4q 9BpsFJj9SRB/PXm6eztaq1lcLEjmWw1OMX3poWPp4xznxRP4IaSiNBwTzfFCJ6bLqBAR C2Ez+rHfdeu9PyM2Dk2ysME1SJRPsVajBwz1+mg1luRQH9Qmp3JNd70mtlKLMLIFaRyT O1OA== X-Gm-Message-State: AE9vXwPry250TtcWJx6lRQdd289dDNZcu4D53zwdFBGFD4nBqpXaXbhxqnpjoDvlctF+1E3NgOToXs6Yv7v8Xg== X-Received: by 10.55.24.194 with SMTP id 63mr29897946qky.30.1474302287338; Mon, 19 Sep 2016 09:24:47 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.55.209.87 with HTTP; Mon, 19 Sep 2016 09:24:46 -0700 (PDT) In-Reply-To: References: From: Phillip Hallam-Baker Date: Mon, 19 Sep 2016 12:24:46 -0400 X-Google-Sender-Auth: iv843G-qK0TR2IJbTe06VruvpxA Message-ID: To: Thijs van Dijk Content-Type: multipart/alternative; boundary=001a1144179620e4b7053cdec0cf Archived-At: Cc: IETF OpenPGP 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2016 16:24:51 -0000 --001a1144179620e4b7053cdec0cf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I just found an even more compelling use case for a single fingerprint format. Let us say that we have the following entry in /etc/passwd (or something equivalent): jsmith:M5VWK-ZTIO5-WGWZL-GNRVX-OZLGN-RVXOZ-LGNJW-GW53K-MVTGY-2LKNR:1001:100= 0:Joe Smith,Room 1007,(234)555-8910,(234)555-0044,email:/home/jsmith:/bin/sh OK, so we are still working within the clunky /etc/passwd format. But the point is that we can put the fingerprint of a public key in the password file. And that could then be used to validate all interactions with that user: * Single sign on tokens * SSH login * OpenPGP emails to/from system admins. Now obviously, you probably wouldn't want to put an OpenPGP key in the password file. But you might want to put the key that is used to sign a policy statement describing the keys for all the above in that file. And you might well want to use OpenPGP key format to do that. On Mon, Sep 19, 2016 at 9:24 AM, Phillip Hallam-Baker wrote: > On Mon, Sep 19, 2016 at 6:36 AM, Thijs van Dijk > wrote: > >> On 17 September 2016 at 23:43, Phillip Hallam-Baker < >> phill@hallambaker.com> wrote: >> >>> =E2=80=8B >>> >> 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.=E2=80=8B >>> >> >> 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. >> > > =E2=80=8BYep, if it wasn't for the fact that we need to get rid of the is= sue time > and use SHA2 and Base32, maybe we wouldn't =E2=80=8Bbe doing it now. I ho= pe > OpenPGPv6 won't need to rev the format. > > > >> =E2=80=8BI think we should kill fingerprints with a work factor of less = than 2^92 >>> =E2=80=8B >>> =E2=80=8Bas unsafe.=E2=80=8B 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 ca= n >> consider the "full" fingerprint? This scheme has an implied maximum leng= th >> 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 >> fingerprints.) >> > > =E2=80=8BI think that for virtually all purposes, a 50+9 character (i.e. = 2^242 > work factor) fingerprint is sufficient.=E2=80=8B I don't see more being u= seful > unless you are really keen on keeping the full 256WF of AES-256. > > This is a manageable length for configuration files (looking at you SSH). > So yesterday, I was working on a IoT project to develop a secure means of > controlling the garage door etc. on the house. The config file looks like= : > > Remote1 =3D M5VWK-ZTIO5-WGWZL-GNRVX-OZLGN-RVXOZ-LGNJW-GW53K-MVTGY-2LKNR > Remote2 =3D MF3WU-23FNR-VWU4L-XMVTG-Y23RN-J3WK3-DGNNY-XO3DL-MVTGU-3DLOF > ... > > In this case the remote is currently a Teensy 3.2 device ($12) that has a > 32 bit processor and so I am using public key (cos I can). But I might we= ll > want to use a Kerberos type approach and a cheaper CPU (Arduino Nano, > $1.30) instead. I can still use the same approach to authenticate and > authorize the remote. > > Note that the configuration file does not need to specify the type of key > because that will be specified when the public portion of the key is > presented. Whether that is a Curve25529 key or a Kerberos ticket, the > message that presents the public key will specify what it is. > > > I could well see the same approach for SSH authorized_keys files. In fact > my project for this morning/week is to get something like this working: > > mesh M5VWK-ZTIO5-WGWZL-GNRVX-OZLGN-RVXOZ-LGNJW-GW53K-MVTGY-2LKNR > ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA0KJDLOiiXj9XdMxiCT9Kv > =E2=80=8B... (5000 chars).. > > ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAywWhrwq4FjHt+UuwZcZ > =E2=80=8B... (5000 chars).. > > > =E2=80=8BThe first lines is the actual trust anchor which is a fingerprin= t of a > master key of a mesh profile. This is a long term (100 year) key and is n= ot > expected to change. The next two lines are keys that have been fetched fr= om > the mesh and are the latest SSH keys for the two devices the user has > connected to that profile for SSH use. > > > =E2=80=8BThe equivalent for OpenPGP would be to manually edit your keyrin= g. In > this case Carol enters the following: > > alice@example.com M5VWK-ZTIO5-WGWZL-GNRVX-OZLGN- > RVXOZ-LGNJW-GW53K-MVTGY-2LKNR > bob@example.com =E2=80=8BMF3WU-23FNR-VWU4L-XMVTG > > When a mail from Bob is received, the mail client updates its copy of the > keyring with the strengthened fingerprint: > > alice@example.com M5VWK-ZTIO5-WGWZL-GNRVX-OZLGN- > RVXOZ-LGNJW-GW53K-MVTGY-2LKNR > bob@example.com =E2=80=8BMF3WU-23FNR-VWU4L-XMVTG-Y23RN-J3WK3-DGNNY-XO3DL-= MVTGU- > 3DLOF > > > Apart from this, you'll be glad to know that I've kicked the tyres of thi= s >> proposal about all I can, and I like it a lot. Eagerly awaiting someone >> else to chime in at this point. >> > > =E2=80=8BThanks for doing so.=E2=80=8B > > > > --001a1144179620e4b7053cdec0cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I j= ust found an even more compelling use case for a single fingerprint format.= Let us say that we have the following entry in /etc/passwd (or something e= quivalent):
jsmith:M5VWK-ZTIO5-WGWZL-GNRVX-OZLGN-RV= XOZ-LGNJW-GW53K-MVTGY-2LKNR:1001:1000:Joe Smith,Room 1007,(234)555-8910,(23= 4)555-0044,email:/home/jsmith:/bin/sh

OK, so we are still working within = the clunky /etc/passwd format. But the point is that we can put the fingerp= rint of a public key in the password file. And that could then be used to v= alidate all interactions with that user:
=
* Single sign on tokens
* SSH login
* OpenP= GP emails to/from system admins.

Now obviously, you probably wouldn't wan= t to put an OpenPGP key in the password file. But you might want to put the= key that is used to sign a policy statement describing the keys for all th= e above in that file. And you might well want to use OpenPGP key format to = do that.




On Mon, Sep 19, 2016 at 9:24 A= M, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
On Mon, Sep 19, 2016 at 6:36= AM, Thijs van Dijk <schnabbel@inurbanus.nl> wrote:
=
On 17 Septembe= r 2016 at 23:43, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
=E2=80=8B
<= /span>
The only thing that forces a cha= nge of VersionID is a change in digest algorithm. Which is probably the thi= ng that would lead to a V6 format anyway.=E2=80=8B
<= /div>

That's a good point. In fa= ct, I'll hazard a guess and say that that's likely to be the only e= vent to warrant a key version bump.

=E2=80=8BYep, if it wasn't for the fact that we need to get rid of = the issue time and use SHA2 and Base32, maybe we wouldn't =E2=80=8Bbe d= oing it now. I hope OpenPGPv6 won't need to rev the format.

=C2=A0
=E2=80=8BI= think we should kill fingerprints with a work factor of less than 2^92 =E2= =80=8B
=E2=80=8Bas unsaf= e.=E2=80=8B No matter what, they just keep coming back and biting in bad wa= ys.

Fa= ir enough.
At the other end of the spectrum, do you have any thou= ghts 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 sh= ould 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 group= ing to V4 fingerprints.)

=E2=80= =8BI think that for virtually all purposes, a 50+9 character (i.e. 2^242 wo= rk factor) fingerprint is sufficient.=E2=80=8B I don't see more being u= seful unless you are really keen on keeping the full 256WF of AES-256.

This is a manageable length f= or configuration files (looking at you SSH). So yesterday, I was working on= a IoT project to develop a secure means of controlling the garage door etc= . on the house. The config file looks like:

Remote1 =3D M5VWK-ZTIO5-WGWZL-GNRVX-OZLGN-RVXOZ-L= GNJW-GW53K-MVTGY-2LKNR
Remote2 =3D MF3WU-23FNR-VWU4L-XMVTG-Y23RN-J3WK3-DGNNY-XO3DL-MV= TGU-3DLOF
...

=
In this case th= e remote is currently a Teensy 3.2 device ($12) that has a 32 bit processor= and so I am using public key (cos I can). But I might well want to use a K= erberos type approach and a cheaper CPU (Arduino Nano, $1.30) instead. I ca= n still use the same approach to authenticate and authorize the remote.

Note that the configuration = file does not need to specify the type of key because that will be specifie= d when the public portion of the key is presented. Whether that is a Curve2= 5529 key or a Kerberos ticket, the message that presents the public key wil= l specify what it is.

I could well = see the same approach for SSH authorized_keys files. In fact my project for= this morning/week is to get something like this working:

mesh M5VWK-ZTIO5-WGWZL-GNRVX-OZLGN-= RVXOZ-LGNJW-GW53K-MVTGY-2LKNR
ssh-rsa AAAAB3NzaC1yc2EAAAABI= wAAAIEA0KJDLOiiXj9XdMxiCT9Kv
=E2=80=8B... (5000 chars)..

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAywWhrwq4FjHt+UuwZcZ
=E2=80=8B... (5000 chars)..

=E2=80=8BThe first lines is the actual trust anchor which is a fing= erprint of a master key of a mesh profile. This is a long term (100 year) k= ey and is not expected to change. The next two lines are keys that have bee= n fetched from the mesh and are the latest SSH keys for the two devices the= user has connected to that profile for SSH use.

=

= =E2=80=8BThe equivalent for OpenPGP would be to manually edit your keyring.= In this case Carol enters the following:

ali= ce@example.com M5VWK-ZTIO5-WGWZL-GNRVX-OZLGN-RVXOZ-LGNJW-GW53K-MVT= GY-2LKNR
bob@example.com =E2=80= =8BMF3WU-23FNR-VWU4L-XMVTG

When a mail from Bob is received, the mail client updates its copy of the= keyring with the strengthened fingerprint:

alice@example.com M5VWK= -ZTIO5-WGWZL-GNRVX-OZLGN-RVXOZ-LGNJW-GW53K-MVTGY-2LKNR
bob= @example.com =E2=80=8BMF3WU-23FNR-VWU4L-XMVTG-Y23RN-J3WK3-DGNNY-XO= 3DL-MVTGU-3DLOF


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

=E2=80=8BThanks for doing so.=E2=80=8B
=C2=A0

=


--001a1144179620e4b7053cdec0cf-- From nobody Tue Sep 20 14:56:51 2016 Return-Path: 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 3522E12B9FB for ; Tue, 20 Sep 2016 14:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 SMnCD4HCqyBA for ; Tue, 20 Sep 2016 14:56:48 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id D2A7B12B9FE for ; Tue, 20 Sep 2016 14:56:46 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id AD04BF999; Tue, 20 Sep 2016 17:56:44 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id BF23E20140; Tue, 20 Sep 2016 16:39:08 -0400 (EDT) From: Daniel Kahn Gillmor To: "Neal H. Walfield" , IETF OpenPGP In-Reply-To: <87mvj9mrs9.wl-neal@walfield.org> References: <87mvj9mrs9.wl-neal@walfield.org> Date: Tue, 20 Sep 2016 16:39:08 -0400 Message-ID: <87fuouux03.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [openpgp] Signer's User ID X-BeenThere: openpgp@ietf.org 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: Tue, 20 Sep 2016 21:56:50 -0000 On Thu 2016-09-15 05:33:10 -0400, Neal H. Walfield wrote: > RFC 4880 says: > > 5.2.3.22. Signer's User ID > > (String) > > This subpacket allows a keyholder to state which User ID is > responsible for the signing. Many keyholders use a single key for > different purposes, such as business communications as well as > personal communications. This subpacket allows such a keyholder to > state which of their roles is making a signature. > > This subpacket is not appropriate to use to refer to a User Attribute > packet. > > In GnuPG, we use the user id's email address. Thus, if a key has the > user id "Neal H. Walfield" , and the user runs: > > echo data to sign | gpg --default-key neal@walfield.org -s > > or > > echo data to sign | gpg --default-key 'Neal H. Walfield' -s > > Then, in both cases we include this subpacket in the signature packet > with the string "neal@walfield.org". > > > Note: we use data for locating the key via DANE or WKS as well as in > our TOFU implementation to identify the intended binding. > > > Since, IMO, the spec is unclear about the contents of this field and > Werner pointed out that another implementation could reasonably use > the hash of the user id here, I think it makes sense to clarify > exactly what is expected to increase interoperability. My proposal to > standardize GnuPG's behavior is: > > 5.2.3.22. Signer's User ID > > (String) > > This subpacket allows a keyholder to state which User ID is > responsible for the signing. Many keyholders use a single key for > different purposes, such as business communications as well as > personal communications. This subpacket allows such a keyholder to > * state which of their roles is making a signature. The value of > * this subpacket is a byte-for-byte copy of the RFC 2822 mail name-addr > * portion of the User ID. > > This subpacket is not appropriate to use to refer to a User Attribute > packet. fwiw, i've always assumed this was a byte-for-byte match of the signing User ID itself, UTF-8-encoded just like the User ID. Making this a specific transformation of the User ID seems like an extra complication, without much gain, no? Tools that do DANE or WKS or other lookups can do whatever transformation they need independently of what's stored in this subpacket. Why require a new transformation in the OpenPGP spec itself? --dkg From nobody Wed Sep 21 02:22:05 2016 Return-Path: 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 2BB9112B0B3 for ; Wed, 21 Sep 2016 02:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no 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 I3gUz6k9ygB9 for ; Wed, 21 Sep 2016 02:22:02 -0700 (PDT) Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id B570F12B0E8 for ; Wed, 21 Sep 2016 02:22:02 -0700 (PDT) Received: from p5ddfbd40.dip0.t-ipconnect.de ([93.223.189.64] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1bmdj2-0008Ht-4q; Wed, 21 Sep 2016 09:21:56 +0000 Date: Wed, 21 Sep 2016 11:21:57 +0200 Message-ID: <87lgyllia2.wl-neal@walfield.org> From: "Neal H. Walfield" To: Daniel Kahn Gillmor In-Reply-To: <87fuouux03.fsf@alice.fifthhorseman.net> References: <87mvj9mrs9.wl-neal@walfield.org> <87fuouux03.fsf@alice.fifthhorseman.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: IETF OpenPGP Subject: Re: [openpgp] Signer's User ID X-BeenThere: openpgp@ietf.org 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, 21 Sep 2016 09:22:04 -0000 Hi Daniel, On Tue, 20 Sep 2016 22:39:08 +0200, Daniel Kahn Gillmor wrote: > fwiw, i've always assumed this was a byte-for-byte match of the signing > User ID itself, UTF-8-encoded just like the User ID. Making this a > specific transformation of the User ID seems like an extra complication, > without much gain, no? This was my initial assumption as well, but Werner had some arguments, which I'm having trouble reproducing now. Hopefully he'll respond here. :) Neal From nobody Wed Sep 21 08:47:51 2016 Return-Path: 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 4057312B3A4 for ; Wed, 21 Sep 2016 08:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no 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 2W1NVF2PSVui for ; Wed, 21 Sep 2016 08:47:48 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 6587712B078 for ; Wed, 21 Sep 2016 08:47:48 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.84_2 #1 (Debian)) id 1bmjkQ-0006UB-2E for ; Wed, 21 Sep 2016 17:47:46 +0200 Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1bmjdA-0004pK-SY; Wed, 21 Sep 2016 17:40:16 +0200 From: Werner Koch To: "Neal H. Walfield" References: <87mvj9mrs9.wl-neal@walfield.org> <87fuouux03.fsf@alice.fifthhorseman.net> <87lgyllia2.wl-neal@walfield.org> Organisation: The GnuPG Project X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: url=https://k.gnupg.net/80615870F5BAD690333686D0F2AD85AC1E42B367 Mail-Followup-To: "Neal H. Walfield" , Daniel Kahn Gillmor , IETF OpenPGP Date: Wed, 21 Sep 2016 17:40:16 +0200 In-Reply-To: <87lgyllia2.wl-neal@walfield.org> (Neal H. Walfield's message of "Wed, 21 Sep 2016 11:21:57 +0200") Message-ID: <87lgyls1lr.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=national_information_infrastructure_Bin_Laden_tempest_BLU-114/B=clan"; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Cc: IETF OpenPGP , Daniel Kahn Gillmor Subject: Re: [openpgp] Signer's User ID X-BeenThere: openpgp@ietf.org 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, 21 Sep 2016 15:47:50 -0000 --=national_information_infrastructure_Bin_Laden_tempest_BLU-114/B=clan Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 21 Sep 2016 11:21, neal@walfield.org said: > This was my initial assumption as well, but Werner had some arguments, > which I'm having trouble reproducing now. Hopefully he'll respond There are lot of things in OpenPGP which are not strictly defined and it is assumed that applications do the Right Thing. IIRC, the Signer's UID was discussed but nobody had a real interest in using it. Thus what we have is a subpacket number and a generic description for what it may be used. I am in favor of not changing the specs. Salam-Shalom, Werner =2D-=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. --=national_information_infrastructure_Bin_Laden_tempest_BLU-114/B=clan Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlfiqeAACgkQTwVA1Xf5X5VeGgCeM0m+7toPkJrDGT+UOLlkx6Zy KIwAn1gFHjNsh011wN7Zh7oNuw3vFKD7 =sDkr -----END PGP SIGNATURE----- --=national_information_infrastructure_Bin_Laden_tempest_BLU-114/B=clan-- From nobody Thu Sep 22 00:55:00 2016 Return-Path: X-Original-To: openpgp@ietf.org Delivered-To: openpgp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C39912BDE4; Thu, 22 Sep 2016 00:54:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147453089900.22494.2200250719077104627.idtracker@ietfa.amsl.com> Date: Thu, 22 Sep 2016 00:54:59 -0700 Archived-At: Cc: openpgp-chairs@ietf.org, openpgp@ietf.org, barryleiba@gmail.com, stephen.farrell@cs.tcd.ie Subject: [openpgp] openpgp - Not having a session at IETF 97 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 07:54:59 -0000 Barry Leiba, a chair of the openpgp working group, indicated that the openpgp working group does not plan to hold a session at IETF 97. This message was generated and sent by the IETF Meeting Session Request Tool.