[openpgp] Subkeys of Subkeys

Paul Schaub <vanitasvitae@fsfe.org> Mon, 20 September 2021 14:10 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 C714C3A1174 for <openpgp@ietfa.amsl.com>; Mon, 20 Sep 2021 07:10:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.231
X-Spam-Level:
X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 7JSN3XJUamLz for <openpgp@ietfa.amsl.com>; Mon, 20 Sep 2021 07:10:09 -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 8CD633A1175 for <openpgp@ietf.org>; Mon, 20 Sep 2021 07:10:09 -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 4HCmfS5pngzF3QV for <openpgp@ietf.org>; Mon, 20 Sep 2021 07:10:08 -0700 (PDT)
X-Riseup-User-ID: E153F55A538F07BB17B0162A01E3C7CC6F06075833929E33010E524C831B6001
Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews1.riseup.net (Postfix) with ESMTPSA id 4HCmfS2nfTz5vY8 for <openpgp@ietf.org>; Mon, 20 Sep 2021 07:10:08 -0700 (PDT)
To: openpgp@ietf.org
From: Paul Schaub <vanitasvitae@fsfe.org>
Jabber-Id: vanitasvitae@mercury-im.org
Message-ID: <7fd6ba0c-bbfd-80b6-2a97-1e77fc9d2a52@fsfe.org>
Date: Mon, 20 Sep 2021 16:10:06 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------3D97D4C938FED0EF8DA6EE41"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/u9utWatG6xThbk3VWeGr5ckw0PI>
Subject: [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: Mon, 20 Sep 2021 14:10:14 -0000

Hey!

RFC 4880 states, that subkeys need to have a signature by the "top
level" certification key
(https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.1, subkey
binding signature):

>        This signature is a statement by the top-level signing key that
>        indicates that it owns the subkey.
Now I would like to know, whether this rules out the possibility that a
subkey itself may have a subkey. Allowing for such constructions would
be interesting for per-device keys in multi-device settings:

An Account Key Alpha owns two Device subkeys A and B, which in turn own
encryption and signing subkeys aE,aS and bE,bS.

Revocation and Expiration could work as usual (revocations/expirations
on higher level keys affect lower-level keys, not the other way round).

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?

Paul