[openpgp] Re: Component key validity should never have "ho les", was Re: PQC requires urgent semantic cleanup

Preston Maness <[email protected]> Fri, 5 Dec 2025 00:29:06 -0600

Newsgroups	gmane.ietf.openpgp
Message-ID	<[email protected]>

Howdy folks,

I'm a (relatively) long-time and enthusiastic OpenPGP user that's been 
lurking on the list for a while. I'm debating diving into the OpenPGP 
world more intentionally vis a vis projects like Keyoxide and trying to 
build a user-friendly web-of-trust. After reading Andrew's initial 
description of current expected behaviour:

 >Currently, the interop test suite requires that if a new 
self-signature is made after the expiry of the previous self-signature, 
the certificate is temporarily invalid between the expiry of one 
signature and the creation of the next, even if both signatures are 
available to the receiving implementation.[1] This also means that if 
the previous self-signature were not available to the receiving 
implementation, the certificate was never valid before the date of the 
newer self-signature, *even if the creation date of the primary key 
indicates otherwise*.

and investigating the link[1], the test case definitely sounds like an 
awful lot of convolution for little benefit. If I as a user let my 
self-signature lapse/expire but then update it again after a couple 
days/weeks, I wouldn't want any messages or signatures made in the 
interim (I'm assuming here that the client software is letting me make 
signatures despite the self-sig being expired) to be considered 
permanently invalid, even if folks checking for a newer self-sig/updated 
expiry successfully/eventually find it. My limited understanding of the 
intention behind having expiration dates at all is that it is intended 
as a way for unused keys to eventually die/prune, not as a way to signal 
permanent "temporal holes," as Heiko calls them, on the validity of my 
identity.

And Heiko's comment:

 >I think that all component keys should *by definition* be valid from 
their creation time either until infinity, or up to *one* temporal end 
point (this *single* end point being caused by either the "last" key 
expiration time or the "earliest" key revocation time).

certainly sounds more straightforward to me, as well as the suggestion 
that temporary revocation be an application-specific thing and not a 
protocol-level thing. But frankly, after digging around a bit on all of 
the pitfalls with revocation[2], I don't really know just how much the 
spec/protocol should mandate, and how much should be treated as 
application-specific details.

-- 
In Solidarity,
Preston Maness
512-955-1048
https://keyoxide.org/79895B2E0F87503F1DDE80B649765D7F0DDD9BD5

[1]https://sequoia-pgp.gitlab.io/openpgp-interoperability-test-suite/results.html?impls=171157#Temporary_validity

[2]https://www.ietf.org/archive/id/draft-dkg-openpgp-revocation-00.html

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]

OpenPGP_0x49765D7F0DDD9BD5.asc (application/pgp-keys, 89.8 KB)

OpenPGP_signature.asc (application/pgp-signature, 833 B)