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

Hello all,

following this train of thought, I want to propose (for discussion) the 
principle that the validity of a certificate and its subkeys should 
always be contiguous, and never have "temporal holes".


The validity of a component key always have a lower bound (it definitely 
never extends earlier than its creation time). Let's put aside hard 
revoked keys, which are never temporally valid.

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).

I believe that any semantics clarifications should uphold this principle 
of contiguous component key validity.


Because as soon as we allow temporal "holes", we will always require 
retaining "n" (or "2n", depending on the exact mechanism) binding 
signatures for any component key that has "n" validity holes.
If we were serious about upholding such temporal semantics, we would 
need to strive to distribute *all of these signatures* to *any user* who 
ever wants to interact with that certificate, *in perpetuity*.
To be defensive, all implementations would need to merge any signature 
packets they learn of into their copy of the certificate, and either not 
minimize signatures at all, or be extremely careful about which 
signatures can be elided without changing any validity semantics.

This seems hard, dangerous and brittle. I believe it would be a *very 
bad* trade-off to try and obtain any "validity hole" semantics. The 
ecosystem cost of the complexity and the DOS-ability that flows from it 
outweighs any utility I can imagine. By orders of magnitude.


Of course I agree that someone might have gotten the idea that OpenPGP 
allows such semantics.
It would definitely have been better to clarify this question in the WG 
years ago. But the next best time for such a clarification - I think - 
is now.

Thanks,
:) Heiko

PS: I don't think we should get into in the business of modeling 
Schrödinger's private key material compromise with general-purpose 
OpenPGP semantics (as in your Yubikey example).
If some application wants to model validity of component keys during 
even minutes, but not during odd minutes (and maybe also not during full 
moon), then I think it should specify an application-specific notation, 
and model its unusual requirements in that confined context.


On 12/2/25 9:02 PM, Daniel Huigens wrote:
> So - a lot of this discussion hinges on whether it's useful to do a
> temporary revocation.
>
> I don't really want to claim that it is useful, but what if someone
> _thought_ it's useful: let's say, for example, that someone goes on
> vacation for a month, and leaves their YubiKey at home. The neighbors
> have a key (of the variety that opens a door), so they revoke the
> OpenPGP key for a month. If they come back and see the YubiKey still
> in place, they may be confident that the key material is still secure,
> but it may theoretically have been used to sign emails on their behalf
> in the past month.
>
> Now - we may argue about whether that's a valid use case or not, but
> according to the straightforward reading of RFC9580, it's possible
> today. So, someone may have done it, so we should be careful about
> breaking it.
>
> Combined with the scenario I described before, this would result in
> an actual problem if the maliciously created signatures then become
> valid.
>
> Best,
> Daniel
>
> _______________________________________________
> openpgp mailing list -- [email protected]
> To unsubscribe send an email to [email protected]

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