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

Leo Gaspard <ietf@leo.gaspard.ninja> Sun, 27 May 2018 21:31 UTC

Return-Path: <ietf@leo.gaspard.ninja>
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 7D32112FB32 for <openpgp@ietfa.amsl.com>; Sun, 27 May 2018 14:31:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=leo.gaspard.ninja
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 XfwqOzVZKden for <openpgp@ietfa.amsl.com>; Sun, 27 May 2018 14:31:44 -0700 (PDT)
Received: from smtp.gaspard.ninja (grym.ekleog.org [94.23.42.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A58F127869 for <openpgp@ietf.org>; Sun, 27 May 2018 14:31:43 -0700 (PDT)
Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id a484d4a5; Sun, 27 May 2018 21:31:40 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=leo.gaspard.ninja; h=subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= grym-20170528; bh=GWaNZJmiYzfvGMe6hK+ar71Kbm0=; b=jH/etB7Zz26Ahr vjQ7o4yY0BWeYs/R8V2AIVLXUIRmKpnlw+zfkAFHxhmHDxuXL00eAK3LpyN5X2Vo xWJWOzZpU2oSqe+7uqCz6pMS6apzMtqYj7v2Db5ALI7KCjB3GA8hethrARBET4Mv xED6dgiUAX4OUVbS8AryBRAGcWzzw=
Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTPSA id 4d2e03a4 (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128:NO); Sun, 27 May 2018 21:31:40 +0000 (UTC)
To: "Neal H. Walfield" <neal@walfield.org>
Cc: openpgp@ietf.org
References: <c37c7f94-edef-7f2d-9151-787112abcbfc@sumptuouscapital.com> <8736yg2gz3.wl-neal@walfield.org> <7dcf3192-e004-c95f-7b62-cdbb31f40c0d@leo.gaspard.ninja> <874lit1m22.wl-neal@walfield.org> <58cf1a73-12cf-0f86-d23c-1603273aabe2@leo.gaspard.ninja> <87zi0kzugh.wl-neal@walfield.org>
From: Leo Gaspard <ietf@leo.gaspard.ninja>
Message-ID: <163c6eb8-7eeb-d2ce-db2b-09633db7b597@leo.gaspard.ninja>
Date: Sun, 27 May 2018 23:31:39 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <87zi0kzugh.wl-neal@walfield.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/UijVK1M_v5cRl7dVgSZQew5ua8I>
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: Sun, 27 May 2018 21:31:46 -0000

On 05/27/2018 10:58 PM, Neal H. Walfield wrote:
> On Sun, 27 May 2018 19:00:04 +0200,
> Leo Gaspard wrote:
>> Indeed it's already possible, the issue with this solution being that
>> people willing to rely on signatures by the master key now need to
>> download two keys (the master key and the trusted introducer), and
>> another one after any compromise, while certification subkeys are
>> downloaded and updated at the same time as the master key, thus making
>> for more easy-to-use WoT.
> 
> That's true.  But, I'd argue that this is more of a tooling problem:
> when the tool is computing the WoT and it encounters a trusted
> introducer has tsigned a key, which is not available, it should
> proactively download the key.

Hmm, I'm not sure it's possible? I mean, if I'm a user, there are 3 keys
to me:
 1. The master key that I trust
 2. The trusted introducer
 3. The key whose validity I want to check

As a user, I have only access to 1 and 3: 1 because I signed it, and 3
because I want to check it. I have /a priori/ no access to key 2. When
could I fetch it?

By policy (and I think it's reasonable for metadata protection reasons),
(most?) implementations do not fetch keys on-the-fly during things like
signature checking or encryption. So I must have had access to the key 2
before that.

However, there is no way (as far as I know) to fetch key 2 when I have
only key 1, as the information of which key a key has tsigned is not
stored in the tsigning key.

So the only moment left for the tooling to download key 2 is when
fetching key 3: when downloading a key, it would automatically download
all keys that have signed it. I think that's possible, but not
necessarily reasonable, as it'd lead to surprising behaviour (importing
more keys than expected), and thus potentially to vulnerabilities on
other tools that wouldn't expect this behaviour.

Now, I was putting this forward mostly for giving another use case that
would naturally benefit from certification-able subkeys, I agree that it
certainly wouldn't deserve the added complexity were it the only use
case of them :)