[pkg-gnupg-maint] Upgrading sid to 2.2.42?

[Daniel Kahn Gillmor]

Hi Andreas, all--

sorry for the delay in reviewing these changes, there was a lot of
material in the tarball and it took me a while to make the time to sort
through it. Assuming that the well-labeled keys and encrypted messages
in the tarball mean what they are labeled to mean, my summary follows:

The good news: The certificates from 2.2.42 don't appear to advertise
any new features that would cause other implementations to send data
that could cause thunderbird any problems.

The bad news: 2.2.42 appears to produce encrypted data that Thunderbird
*could* have problems with, if it was using an imported certificate that
advertises these other features.

I think this is related to the discussion about
gnupg2-revert-rfc4880bis.patch over on pkg-gnupg-maint, so i'm inclined
to try to coalesce these discussions.

It seems to me that we have a few different things to consider:

About encryption/decryption:

a) being able to convert draft-koch-style encrypted content to
   cleartext, despite the lack of key derivation function, which leaves
   room for an adversary to tamper undetectably with the asymmetric
   encryption metadata, potentially producing confusing output.  I don't
   know of any strong attacks against this at the moment.

b) producing OpenPGP certificates which advertise support for decrypting
   draft-koch-style encrypted content in the Features subpacket.

c) producing draft-koch-style encrypted content to any certificate which
   advertises support for it.

About key/cert formats and signatures:

c) Being able to verify draft-koch-style signatures (so-called "v5")
   even though they can be aliased to v3 signatures over subtly
   different data.
   
d) Producing draft-koch-style ("v5") certificates.

e) Producing certificates which advertise support for draft-koch in the
   Features subpacket (it's still not clear to me how this particular
   signal is supposed to be actionable).

f) Producing draft-koch-style ("v5") signatures over data.

g) Producing draft-koch-style ("v5") certifications when "keysigning".

Does this sound like the right range of concerns?  So far, our
discussion in this thread has focused mainly on (a), (b), and (c).

Shall we move this discussion to the revert-rfc4880bis.patch thread?

           --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 324 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20240220/fd7ffcaf/attachment.sig>