[pkg-gnupg-maint] gnupg2-revert-rfc4880bis.patch

[Andreas Metzler]

On 2024-02-19 NIIBE Yutaka <gniibe at fsij.org> wrote:
> NIIBE Yutaka <gniibe at fsij.org> wrote:
> > If the intention of the patch were stopping use of the specification
> > RFC4880bis as default, I don't think this reverting is not good (and
> > incomplete).  For me, the reverting is only makes sense when the use of
> > the option --rfc4880bis itself is important, instead.

> Sorry, I meant:

> 	I don't think this reverting is good

Hello,

Thanks for the analysis!

Daniel suggested [1] to merge the discussion about 2.2.42 into this
thread. Which makes a lot of sense, imho there is not much point
discussing implementation unless we have documented the goals.

Disclaimer: I have not read/compared draft-koch-librepgp-00
("draft-koch") with draft-ietf-openpgp-crypto-refresh ("draft-ietf")
and therefore cannot judge their respective *technical* merits and
weaknesses. Afaiui both a) formally extend the algoritm list (which
common practice has already extended far beyond rfc4880) and b) offer
a mutually incompatible new wireformat ("v5").

I think our wishlist looks like this:
#1 Stay as close as possible to upstream gnupg. Our versions should not
  be limited, but might use different defaults. We do not want either
  gnupg22 or gnupg24 to not be able to "talk" to vanilla gnupg22 and
  gnupg24.
#2 Limit the consequences of the schism. By default do not generate
  messages/signatures/key-signatures that cannot decrypted/verified with
  pre-schism-toolset.
#3 Do #2 without sacrificing security.
#4 Define the "safe" pre-schism-toolset. (e.g. gpg <= 2.2.* && rnp 0.17)
#5 We might apply stricter criteria to gnupg22 than gnupg24, implicitely
  assuming that we will keep gnupg24 in experimental and paln on using
  gnupg22 as default for longer timeframe.

I did some limited testing[2], generating keypairs with gnupg 2.4.4
2.2.40 and 2.2.42, importing these keys in all three versions and
encrypting data with each version for all three versions. (The data was
not signed). All data was decryptable by all versions (and rnp and
sqop), however 2.2.42 differed from 2.2.40 in encrypting with OCB for
2.4.4 generated keys. Does 2.4.4 does not generate v5 wireformat or do
rnp and sqop support it?

@Daniel You provided a list to break down the usecases we need to
consider. I think a) and c) also talk about technical issues (lack of
KDF, v5/v3 signature aliasing). - Are these problems with draft-koch or
implementation specific?

cu Andreas

[1] https://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/2024-February/009220.html

[2] https://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/2024-February/009190.html

More links:
https://lists.debian.org/debian-security/2023/12/msg00010.html
https://lists.debian.org/debian-security/2023/12/msg00016.html
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'