Incompatability with other PGP implementations

[Werner Koch]

Hi!

Thanks for the description of your problem.  However, I am not sure
whether I really understood all details.

On Wed, 30 Oct 2024 12:40, Ivan Hell said:

> key's binding signature validity check. In contrast to GPG, when
> checking a signature validity, this library looks at the subkey's
> binding signature creation date instead of the subkey's creation date.

Interesting, the binding signature creation time is "soft"-timestamp and
has is used to figure out which binding signature prevails.  The specs
leave it to the implementer on how to do this.

GnuPG and PGP have been developed together in a way to achieve best
compatibility.  Thus the interpretation of the OpenPGP standard as
implemented by gpg is as close as possible to the interpretation of
PGP.com's interpretation of the OpenPGP respective their original
implementation.  In fact, David and me worked closely with Hal Finney of
PGP to have a common understanding on how to interpret a standard.

> the OpenPGP specification and its RFCs when checking signatures and
> that gpg may deviate slightly in its implementation of the standard.

A specification always needs interpretation and cross-testing.  You
simply can't write a specification for an existing protocol (PGP 2 and
5) in such a detail that it describes everything.  If you would do that
you would replicate the implementation.  I believe it is common sense
that interop testing is the best way to achieve high interoperability.

> He also argued that according to sequoia-pgp's OpenPGP
> interoperability tests, most implementations adhere to his

Well, someone wrote a new implementation of OpenPGP and thus uses an own
interpretation.  How they also write a test suite and claim that this
reflects the standard.  Does it really reflect the actual use of OpenPGP
and all the deployed versions of PGP, GnuPG, RNP, and BouncyCastle used
in productive environments?  We don't have exact numbers but an educated
guess (based on my >25 years experience and lots of commercial support)
is that they make up more more than 95% of deployed implementations.

> My question now is whether the current implementation of GPG is
> exposed to a security risk by not taking the creation date of the
> binding signature into account? I also wanted to find out whether

The problem here is that a few newcomers try to break an existing and
well matured standard by adding new interpretations (and a new version
of OpenPGP) and thereby creating interoperability problems.

> there is a way to adapt the implementation in GPG so that it is
> compatible with the other OpenPGP implementations (possibly using a

No, we won't play that game.  BTW, this trouble was the reason why RNP
and us came up with a new term for the widely deployed version of
OpenPGP (rfc4880bis): LibrePGP [1].


Salam-Shalom,

   Werner


[1] See https://librepgp.org for more information.
-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20241030/890c5cf9/attachment-0001.sig>