Re: [openpgp] Subkeys of Subkeys

Paul Schaub <vanitasvitae@fsfe.org> Tue, 21 September 2021 11:51 UTC

Return-Path: <vanitasvitae@fsfe.org>
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 96DD33A094D for <openpgp@ietfa.amsl.com>; Tue, 21 Sep 2021 04:51:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.232
X-Spam-Level:
X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 Pk2xeKCsXxQe for <openpgp@ietfa.amsl.com>; Tue, 21 Sep 2021 04:51:42 -0700 (PDT)
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (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 CE0183A0949 for <openpgp@ietf.org>; Tue, 21 Sep 2021 04:51:42 -0700 (PDT)
Received: from fews1.riseup.net (fews1-pn.riseup.net [10.0.1.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "fews1.riseup.net", Issuer "R3" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4HDKXF3W84zDqh4; Tue, 21 Sep 2021 04:51:41 -0700 (PDT)
X-Riseup-User-ID: C467CAF872BD1CCDBCC1B55E3BDD4C86F95F73BE2CDBCF102A474D303ED6EB55
Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews1.riseup.net (Postfix) with ESMTPSA id 4HDKXD678Jz5vkC; Tue, 21 Sep 2021 04:51:40 -0700 (PDT)
To: Justus Winter <justus@sequoia-pgp.org>, openpgp@ietf.org
References: <7fd6ba0c-bbfd-80b6-2a97-1e77fc9d2a52@fsfe.org> <87mto617rv.fsf@europ.lan>
From: Paul Schaub <vanitasvitae@fsfe.org>
Jabber-Id: vanitasvitae@mercury-im.org
Message-ID: <938c9ca6-039d-c3f1-86a9-0f056f3d66c4@fsfe.org>
Date: Tue, 21 Sep 2021 13:51:38 +0200
MIME-Version: 1.0
In-Reply-To: <87mto617rv.fsf@europ.lan>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/UXbJ_VPIK0pNZI7fdbEu5Oi_wDU>
Subject: Re: [openpgp] Subkeys of Subkeys
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 21 Sep 2021 11:51:48 -0000

Hey Justus,

That test vector looks exactly like I would imagine it. It's a bummer
that there is no support in applications though. My library is able to
generate keys in this form (with some trickery) but cannot yet handle
them correctly.

What must happen so that a future revision of the specification
explicitly allows this behavior? Would it make sense to specify this
usecase explicitly?

Paul

Am 21.09.21 um 13:35 schrieb Justus Winter:
> Hi Paul :)
>
> Paul Schaub <vanitasvitae@fsfe.org> writes:
>
>> Allowing for such constructions would be interesting for per-device
>> keys in multi-device settings:
> Yes, we'd like to improve multi-device support using per-device keys as
> well.
>
>> I see no obvious issues which might prevent this, apart from the
>> ambiguous definition quoted above.
>> Has anyone already experimented with such constructions? If so, did you
>> encounter any issues which would need to be taken into consideration?
> We considered it, and I talk (see [0] and [1]) about that in the context
> of bringing forward-secrecy to OpenPGP (see also [2] if you are into
> that).  We have also constructed a test vector [3], but unsurprisingly,
> no implementation supports that [4].
>
> 0: https://sequoia-pgp.org/talks/2018-08-moving-forward/moving-forward.pdf
> 1: https://www.youtube.com/watch?v=an6oYjikAPY
> 2: https://gitlab.com/sequoia-pgp/openpgp-dr/-/tree/wip-openpgp
> 3: https://gitlab.com/sequoia-pgp/weird-keys#cert-subkeyspgp
> 4: https://gitlab.com/sequoia-pgp/weird-keys#results
>
> Justus