Bouncy Castle is choking on unknown packet versions unfortunately. I got
a fix for signatures merged upstream (I'm not affiliated with the Bouncy
Castle project), so at least unknown signature versions will now be
ignored, however unknown PKESK packets still cause issues. I guess
future-proofing BC takes some more work.
Am 29.04.22 um 02:28 schrieb Daniel Kahn Gillmor:
Hey OpenPGP folks--
The design-team is (hopefully) a few weeks away from being able to hand
the crypto-refresh back to the WG for the WG last call. We need some
attention from implementers about a specific issue as we nail down the
last parts of the draft.
The biggest interop concern we have is that several widespread
implementations don't deal well with new versions of signature packets.
In particular, the presence of a single signature packet of unknown
version causes some implementations to choke when handling signatures
that they should otherwise be able process cleanly.
Implementers: please see "The Ask" at the bottom of this message.
v5 keys make v5 signatures, and in a one-pass arrangement, a v5
signature packets has a mirrored v5 One-Paas Signature (OPS) packet.
A v4 key makes v4 signatures, each of which which is mirrored by v3 OPS
The concern is when someone who holds both a v5 key and a v4 key wants
to communicate with someone who holds a v4 key. There are two kinds of
- an encrypted+signed message that contains a v5 signature (possibly
also including one or more v4 signatures)
- a signed message where the signatures contain a v5 signature
(possibly also including one or more v4 signatures)
Some existing implementations see signature packets (and OPS packets) of
unknown versions and choke on processing them, refusing to handle
*other* signature packets which they would be able to handle otherwise.
We don't expect existing tooling to be able to validate a new signature
packet. But we do expect an implementation to discard an unknown
version of a signature in at least the same way that it would discard a
signature of a known version that otherwise fails to validate.
It would be pretty bad for the ecosystem if the presence of an unknown
version of a signature packet caused a message to either fail to
decrypt, or to fail to verify *other* signature packets in the message
that are of known versions.
This is tracked here:
You can see some interoperability testing here:
Those tests highlight that many existing implementations fail in a
If we can't get those implementations patched to gracefully ignore
signature packets (and OPS packets) that they cannot parse, we are going
to have a hard time ever rolling out a v5 signature format for messages.
If all the existing implementations can be updated to gracefully ignore
the packets they don't understand, our design process will be a lot
Otherwise, the DT needs to either give up on widespread, unilateral
deployment of v5 signatures, or take some unusual measures in the design
and wireformat framing of v5 signatures so that they "masquerade" in
such a way that we can help existing implementations ignore them safely.
Could every implementer please take a look at the sample messages
offered in the interop test suite, run them against their tooling, and
propose and identify a patch if the current tooling chokes? If you
think the test suite is wrong, and your client handles the situation
fine despite looking problematic in the test suite, that would also be
good news. Please report!
openpgp mailing list
openpgp mailing list