ietf-openpgp
[Top] [All Lists]

Re: [openpgp] Implementers: does your OpenPGP tool gracefully discard signature packets of unknown version?

2022-05-03 04:30:00
Hey!

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.

Paul

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.

Details
=======

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

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
messages:

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

More notes
==========

This is tracked here:

   https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/107

You can see some interoperability testing here:

    https://tests.sequoia-pgp.org/#Detached_signatures_with_unknown_packets
    https://tests.sequoia-pgp.org/#Messages_with_unknown_packets

Those tests highlight that many existing implementations fail in a
problematic way.

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

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.

The Ask
=======

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!

Regards,

         --dkg

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp

<Prev in Thread] Current Thread [Next in Thread>