[openpgp] Question on Signature Expiration

Paul Schaub <vanitasvitae@fsfe.org> Mon, 13 December 2021 16:34 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 4695F3A085E for <openpgp@ietfa.amsl.com>; Mon, 13 Dec 2021 08:34:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.233
X-Spam-Level:
X-Spam-Status: No, score=-1.233 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] 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 xvmp5MIpM4gA for <openpgp@ietfa.amsl.com>; Mon, 13 Dec 2021 08:34:17 -0800 (PST)
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 F0F603A085D for <openpgp@ietf.org>; Mon, 13 Dec 2021 08:34:16 -0800 (PST)
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 "mail.riseup.net", Issuer "R3" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4JCRt00Hr7zDrQy for <openpgp@ietf.org>; Mon, 13 Dec 2021 08:34:16 -0800 (PST)
X-Riseup-User-ID: EFB48B1B1C72C8C94D6ABCECE7E19B976CB2F62A3F1B3F261E213A9D2BD37A14
Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews1.riseup.net (Postfix) with ESMTPSA id 4JCRsy38Xqz5vbc for <openpgp@ietf.org>; Mon, 13 Dec 2021 08:34:14 -0800 (PST)
Message-ID: <4af3dfef-8376-5f73-55c3-a960e6840c6e@fsfe.org>
Date: Mon, 13 Dec 2021 17:34:12 +0100
MIME-Version: 1.0
Content-Language: en-US
To: openpgp@ietf.org
From: Paul Schaub <vanitasvitae@fsfe.org>
Jabber-ID: vanitasvitae@mercury-im.org
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/C0P4MxwqJBbxS6H0YoXFF3oEJ3A>
Subject: [openpgp] Question on Signature Expiration
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, 13 Dec 2021 16:34:19 -0000

Hey OpenPGP folks,

I have a question regarding expiration dates.

As far as I understand, keys can have expiration dates, which are 
described via the KeyExpirationDate subpacket inside a signature.

This works quite well, as if I want to change a key expiration date, I 
just create a new signature with the updated key expiration date inside 
and be done.

Now, lets talk about user-id expiration dates. I can model these by 
setting a signature expiration date in the user-id certification 
signature. Once the signature expires, the binding between the key and 
the user-id expires with it, hence the user-id expires.

However, if I want to shorten the expiration period of a user-id (e.g. I 
want to switch from an expiration date in 2 years to one in 2 weeks 
because I got laid off earlier than expected), there arises a problem.

If I simply use the same technique and create a new user-id 
certification signature, but with an earlier expiration date, the 
signature will expire at the new expiration date. However, now the older 
user-id binding signature is still valid until the old expiration date, 
as is the user-id.

If signatures "overlay" (which, as I understood so far, they do), there 
is no way to shorten the expiration date of a user-id.

A possible solution would be to first revoke the old user-id signature 
and then add the certification signature with the new expiration date, 
but that sounds like a hacky solution as it requires multiple signatures 
to be made.

Another solution would be to only take the very latest user-id 
certification signature into consideration when calculating the 
expiration date, but my intuition tells me that's also not right.

How do other implementations handle this? What is the way the 
specification intends me to solve this?


PS: I know that expiration dates are modeled as duration after 
key/signature creation, but its easier to talk about expiration dates as 
dates.