[openpgp] Re: PQC requires urgent semantic cleanup

👋

On Tuesday, December 2nd, 2025 at 17:01, Andrew Gallagher wrote:
> Is it that far fetched to believe that the majority of implementations
> have got it wrong in this one case? With the exception of GnuPG and RNP,
> they are most likely doing it this way because the interop suite told
> them so, and it has been phenomenally successful in gamifying compliance
> - which is a good thing! Let's not overlook the many, many test cases
> where we all agree on the expectations.
> 
> But we have to reserve the right to revisit previous decisions and admit
> we got it wrong, as a matter of principle. If we wrap ourselves in the
> interop suite to avoid engaging with a potentially difficult decision,
> then we are giving it the same veto power we created it to liberate us from.
> 
> To be clear, I'm not saying that I'm obviously right, and everyone else
> is obviously wrong! But I'm saying we should be very careful before
> employing "we did what the interop suite told us, and now it's too late"
> as an argument.

Yes, that's true. 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.

But yes, if all other solutions don't solve the problem and this one
does, and we think the problem is important, then we should do so.

It seems to me that this issue is potentially more problematic for
code/package signing and automated setups than for E2EE messaging,
and since I'm not as familiar with the former, I don't want to weigh in
too loudly on that point; if everyone else also thinks it's an issue.

> What signatures are we proposing should be accepted that would not
> currently be accepted? Ones genuinely made by the key in question after
> its embedded creation date, but before the creation date of the earliest
> available binding signature? Under what scenario could this arise, other
> than subsequent cert minimisation? What are the actual risks of
> accepting such a signature?

It's relatively safe if everyone has a consistent model of how to
minimize a cert, and what effects it has. But if we don't, there could
be unintended consequences. For example, let's say you're using Sequoia
today and you un-revoke a key, so that you end up with:
- Primary key generated at t1
- First self-signature at t1
- Revocation at t2
- Second self-signature at t3

For Sequoia, the validity period of the cert is t1-t2 + t3-now.
Under draft-signatures, the validity period is t1-t2.
So far, so good (reducing the validity period is safer than extending it).

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.

> I do agree that it is unfair that people who implemented something in
> good faith would now be asked to undo their hard work, at their own
> expense. But I believe it is a net saving in the long run, and I'm
> personally very willing to get stuck in to help with any changes that
> may be required if we do agree that they are necessary. I will
> personally do the work to update go-crypto, for example.

Thanks :)

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

> For the record, I would be OK with leaving it that signature expirations
> SHOULD NOT be generated in binding sigs - I still think it would be
> cleaner if we also required that they be ignored, but I'm willing to
> settle for a partial win. ;-)
> 
> But I strongly believe signature expiration subpackets MUST be ignored
> in revocations, for the same reason that I believe subsequent
> "un-revocation" binding signatures MUST be ignored - if revocation is
> not permanent, it is not effective.

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?

Best,
Daniel

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