Re: [openpgp] Clarify status of subkeys with certification use

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Fri, 25 May 2018 20:01 UTC

Return-Path: <dkg@fifthhorseman.net>
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 2FA9312E8D2 for <openpgp@ietfa.amsl.com>; Fri, 25 May 2018 13:01:07 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 sz5nMtlxlwwl for <openpgp@ietfa.amsl.com>; Fri, 25 May 2018 13:01:05 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349B112E8CA for <openpgp@ietf.org>; Fri, 25 May 2018 13:01:05 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 7D5DDF99A; Fri, 25 May 2018 16:01:03 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 335BE20670; Fri, 25 May 2018 16:01:01 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: "Neal H. Walfield" <neal@walfield.org>, Kristian Fiskerstrand <kristian.fiskerstrand@sumptuouscapital.com>
Cc: IETF OpenPGP <openpgp@ietf.org>, Justus Winter <justus@sequoia-pgp.org>
In-Reply-To: <8736yg2gz3.wl-neal@walfield.org>
References: <c37c7f94-edef-7f2d-9151-787112abcbfc@sumptuouscapital.com> <8736yg2gz3.wl-neal@walfield.org>
Date: Fri, 25 May 2018 16:00:58 -0400
Message-ID: <87h8mvfqth.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/0dkwoMmEQADN1tdXsiEkRCK-1RU>
Subject: Re: [openpgp] Clarify status of subkeys with certification use
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 25 May 2018 20:01:10 -0000

On Fri 2018-05-25 11:59:44 +0200, Neal H. Walfield wrote:

> Justus and I have been thinking about how to realize per-device keys
> and approximate forward secrecy.  These two things are related: if we
> want devices to do their own key rotation (and I think this is
> sensible, as the alternative is to somehow regularly transfer secret
> key material to each device), then the devices need to be able to
> generate self-signatures.  Since we don't want all devices to have
> access to the primary key, each device could have its own
> certification subkey.

I've also been thinking about how to do forward secrecy, but i think
i've come to the opposite result as Neal and Justus here.

Per-device keys are bad for user privacy (they leak how many devices the
user has), and they either complicate any potential interface for
cryptographic identity verification (i now need to somehow both know and
understand the range of devices held by my peer), or they provide a
convenient mechanism for a wiretap capability (sneak in an extra
certification key for a user somehow).

you can still keep a primary certification-capable key offline (or on a
"master" client), while retaining the ability to revoke access to
certain clients -- you just need to revoke existing subkeys, and provide
all remaining good clients with the new subkeys, so i don't see
certification-capable subkeys as a win there either.

And i believe that sensible clients connected to a single account will
need a way to synchronize *other* state as well -- not just secret keys
-- so there's not much of a savings on the difficulty of state
synchronization here anyway.

Additionally (as i wrote elsewhere in this thread) i think they
represent pretty serious implementation complexity, which i don't think
is healthy for the ecosystem.

So i'm still on the side of trying to make more explicit the current
assumption that only primary keys hold certification capabilities.

           --dkg