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