[openpgp] Re: PQC requires urgent semantic cleanup

Hi, Daniel!

On 02/12/2025 16:53, Daniel Huigens wrote:
> 👋
> 
> To be clear, I'm not claiming that we should keep the
> behavior because the interop test suite says so, but rather because 4-6
> implementations agree with it (depending on the exact case being tested)
> and thus with each other. Another way to phrase that, leaving the test
> suite out of it, is just that most implementations behave consistently
> today, and reversing that requires a strong justification, as the risk
> is that we end up with no consistency rather than implementations
> consistently doing the opposite.

I think there is a strong justification, and it boils down to two 
things: conceptual simplicity and robustness. The conceptual simplicity 
is that only the most recent self-signature is meaningful, so it is 
always equally easy to answer the question "what properties does this 
certificate have?". And robustness comes from the ability to make 
changes through adding new self-signatures and cleaning up old ones, 
without inadvertently breaking old stuff. (It would still be possible to 
break old stuff, for example by removing key flags, but it should be 
more difficult to do by accident, and will be relatively easy to fix 
after the fact by generating another self-signature).

> Then, let's say you decide you don't care about old signatures anymore
> and minimize the cert in Sequoia, ending up with:
> - Primary key generated at t1
> - Second self-signature at t3
> 
> For Sequoia, the new validity period of the cert is t3-now.
> Under draft-signatures, the validity period is t1-now.
> Oops, now signatures created between t2-t3 are also valid while they
> weren't before.

OK, but what are the actual consequences of that? The signatures created 
between t2-t3 were genuine signatures made by the genuine keyholder. The 
only way this would be a problem would be if the keyholder created them 
and then later intentionally rendered them invalid by the indirect 
method of cert minimisation, and relied on that invalidation for some 
security purpose. And for that to be robust, they would need to be 
*absolutely sure* that nobody cached a copy of the deleted selfsigs in 
the meantime.

So it just isn't effective as an intentional construction. It is much 
more likely that the keyholder did it by accident, because they didn't 
understand the consequences of cert minimisation in sequoia.

>> I recall you mentioning expiring revocations elsewhere, but it's not in
>> your previous mail in this thread - that only explicitly mentions
>> expiring primary key binding sigs.
> 
> My opinion is the same, in the sense that it's simplest to implement
> signature expiration consistently (so that it works everywhere).

I'm not convinced by this. Sure, if you do temporal validation in a 
common signature validation function, you only have to write the code 
once. But on the other hand you need to pass a reference time much 
further down the call stack than strictly necessary. And if signature 
expiration time is only meaningful in one or two contexts, you're still 
only writing the code once or twice - just elsewhere...?

> I don't really see why it's the consumer's responsibility to enforce
> that revocation should be permanent. It's true that temporarily revoking
> a key seems a bit silly and pointless, but if the key owner wants to
> do so, what's the risk in allowing it?

The risk is that the key owner didn't actually want to do so. It is such 
a bizarre construction that if it was encountered in the wild, it is 
much more likely to be the result of an accident, or an implementation 
error, than from intent. The key owner thinks they have permanently 
soft-revoked their key, but in reality they haven't, someone encrypts to 
the wrong key, which may have been destroyed in the meantime, and the 
key owner gets fail-to-decrypt. IMO the risk of this is much greater 
than the risk of an implementation not supporting an esoteric use case.

A

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