Re: [openpgp] Proposed text for V5 fingerprint

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 19 September 2016 16:24 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A1612B419 for <openpgp@ietfa.amsl.com>; 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 <openpgp@ietfa.amsl.com>; 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 <openpgp@ietf.org>; Mon, 19 Sep 2016 09:24:48 -0700 (PDT)
Received: by mail-qk0-x243.google.com with SMTP id w204so10038989qka.2 for <openpgp@ietf.org>; 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: <CAMm+LwiEJJeTvOXaacHiX01ytq5BuoQykcK2kPH_wZcvokyDDQ@mail.gmail.com>
References: <CAMm+Lwhz973u20W0TETFrE0Y_frKQth=B0QcisP5bD2jskta4g@mail.gmail.com> <CAMm+Lwj595p1QtrBbFTeig0VX2Mg0giBXCoZNhNZwzXuKfVUNQ@mail.gmail.com> <CADGaDpEJhvktfTtr1V6rVdd7LqORDwwZhFbbSZnz-7LdH_6qEA@mail.gmail.com> <CAMm+Lwjz603dPF+74A0tXBhOC86+ag8r2qHcD8LoVZcrDSTpXQ@mail.gmail.com> <CADGaDpEL7CiO+cWzA=cEDjAqjLwvnf9efRkGOFBsHtgEjcZA0A@mail.gmail.com> <CAMm+LwjC94cKFCbRrTYAcixqkVygQ7zefRAE0pb7nXQBGg+50Q@mail.gmail.com> <CADGaDpE7qdY8VnHWQboW5RYoDTs0GsgT8A8Zg2psKi9goQ=RHQ@mail.gmail.com> <CAMm+LwiEJJeTvOXaacHiX01ytq5BuoQykcK2kPH_wZcvokyDDQ@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Mon, 19 Sep 2016 12:24:46 -0400
X-Google-Sender-Auth: iv843G-qK0TR2IJbTe06VruvpxA
Message-ID: <CAMm+Lwi_V1+c+QHyezKRP7vEMi3zCVF3xhb4MT96wAVBYTz=4Q@mail.gmail.com>
To: Thijs van Dijk <schnabbel@inurbanus.nl>
Content-Type: multipart/alternative; boundary=001a1144179620e4b7053cdec0cf
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/VXVEAHX_J9cHQDZ_Mpap8_ok4JM>
Cc: IETF OpenPGP <openpgp@ietf.org>
Subject: Re: [openpgp] Proposed text for V5 fingerprint
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Sep 2016 16:24:51 -0000

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:1000: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 <phill@hallambaker.com
> wrote:

> 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@hallambaker.com> wrote:
>>
>>> ​
>>>
>> The only thing that forces a change of VersionID is a change in digest
>>> algorithm. Which is probably the thing that would lead to a V6 format
>>> anyway.​
>>>
>>
>> That's a good point. In fact, I'll hazard a guess and say that that's
>> likely to be the only event to warrant a key version bump.
>>
>
> ​Yep, 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 ​be doing it now. I hope
> OpenPGPv6 won't need to rev the format.
>
>
>
>> ​I think we should kill fingerprints with a work factor of less than 2^92
>>> ​
>>> ​as unsafe.​ No matter what, they just keep coming back and biting in
>>> bad ways.
>>>
>>
>> Fair enough.
>> At the other end of the spectrum, do you have any thoughts on what we can
>> consider the "full" fingerprint? This scheme has an implied maximum length
>> of 500 bits (the largest multiple of 25 less than 512+8). Apart from
>> specifying a minimum (100 bits), do you think we should make a
>> recommendation for what is an appropriate level of assurance? (E.g. 250
>> bits - 10 groups of 5 base32 characters, similar in size and grouping to V4
>> fingerprints.)
>>
>
> ​I think that for virtually all purposes, a 50+9 character (i.e. 2^242
> work factor) fingerprint is sufficient.​ I don't see more being useful
> 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 = M5VWK-ZTIO5-WGWZL-GNRVX-OZLGN-RVXOZ-LGNJW-GW53K-MVTGY-2LKNR
> Remote2 = 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
> ​... (5000 chars)..
>
> ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAywWhrwq4FjHt+UuwZcZ
> ​... (5000 chars)..
>
>
> ​The 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.
>
>
> ​The 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 ​MF3WU-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 ​MF3WU-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 this
>> proposal about all I can, and I like it a lot. Eagerly awaiting someone
>> else to chime in at this point.
>>
>
> ​Thanks for doing so.​
>
>
>
>