[openpgp] Definition of Subkey Revocation Signatures

Paul Schaub <vanitasvitae@fsfe.org> Thu, 11 May 2023 08:53 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 CD9A2C151094 for <openpgp@ietfa.amsl.com>; Thu, 11 May 2023 01:53:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.23
X-Spam-Level:
X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrBb95QTknyg for <openpgp@ietfa.amsl.com>; Thu, 11 May 2023 01:53:30 -0700 (PDT)
Received: from mx0.riseup.net (mx0.riseup.net [198.252.153.6]) (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) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C96BC15108F for <openpgp@ietf.org>; Thu, 11 May 2023 01:53:29 -0700 (PDT)
Received: from fews01-sea.riseup.net (fews01-sea-pn.riseup.net [10.0.1.109]) (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 "mail.riseup.net", Issuer "R3" (not verified)) by mx0.riseup.net (Postfix) with ESMTPS id 4QH5K51rrxz9t3K for <openpgp@ietf.org>; Thu, 11 May 2023 08:53:29 +0000 (UTC)
X-Riseup-User-ID: 3F7D789B36CD836F99375846EC08A0C2557450BEBEC4DD3065D29B685CC7E3ED
Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews01-sea.riseup.net (Postfix) with ESMTPSA id 4QH5K45sBZzJq82 for <openpgp@ietf.org>; Thu, 11 May 2023 08:53:28 +0000 (UTC)
Content-Type: multipart/alternative; boundary="------------NO5GWhRCGi02pNmsewI00W4H"
Message-ID: <b850fdd2-69b1-fb18-086e-06c94c0cc13b@fsfe.org>
Date: Thu, 11 May 2023 10:53:26 +0200
MIME-Version: 1.0
Content-Language: en-US
To: openpgp@ietf.org
From: Paul Schaub <vanitasvitae@fsfe.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/DCeZPyanbfIb7hPRyJplkXgXK6Y>
Subject: [openpgp] Definition of Subkey Revocation Signatures
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 11 May 2023 08:53:34 -0000

Hey!

While hacking around I discovered, that there was a discrepancy between 
my implementation and rfc4880 that surprised me.

https://www.rfc-editor.org/rfc/rfc4880#section-5.2.1 states for section 
0x28:

>     0x28: Subkey revocation signature
>         The signature is calculated directly on the subkey being revoked.
>         [...]
In my code, I calculated the signature over the primary key and the 
subkey instead.

The descriptions for binding signature types 0x18 and 0x19 explicitly 
stated that the signature would be generated over the primary key and 
the subkey:

>     0x18: Subkey Binding Signature
>         [...] This signature is calculated
>         directly on the primary key and subkey, and not on any User ID or
>         other packets. [...]
>
>     0x19: Primary Key Binding Signature
>         [...] This signature
>         is calculated the same way as a 0x18 signature: directly on the
>         primary key and subkey, and not on any User ID or other packets.
Since I haven't had any interoperability problems with other 
implementations with regards to subkey revocations in the past, I 
suspect that most implementations did not follow the spec to the word 
either and did how I did.

Therefore I proposed a patch that brings the wording of 0x28 signatures 
in line with 0x18 and 0x19: 
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/307

Paul