GnuPG 2.3 Beta

[Werner Koch]

On Wed, 24 Feb 2021 12:06, Marco Ricci said:

> Then let me ask directly: if I generate an Ed448 key (packet), an ECDH
> X448 key (packet), or a general v5 key or v5 signature packet, using

I would not suggest to do this because there are to my knowledge no
other implementations which can use that.  OTOH, cv25519/ed25519 support
is widely deployed and for example protonmail.com uses it for more than
a year by default.

BTW, for AEAD we have even read support in 2.2 so that if something goes
wrong with AEAD preferences 2.2 can still receive such messages.

> GnuPG 2.3beta, can I assume that when exporting such keys/signatures
> they (a) conform to RFC4880bis-10, and (b) they remain *valid* packets
> even when RFC4880bis is finalized? Or is the format still experimental?

I can't know for sure but there are at least 3 mainstream
implementations using this format (openpgp.js, rnp, gnupg).

> I took your previous commentary about AEAD to mean that EAX and OCB mode
> are pretty much final, as far as RFC4880bis is concerned, and that
> you're in the phase "we need multiple interoperable implementations in
> the wild so that we can add this to the RFC, so now we're releasing one

We do have these implementaions adn did interop tests several years
ago.  There were just some disturbing actions in the WG so that the area
director decided to start from scratch.

> such implementation". So what I'm actually wondering about is whether
> this holds for the v5 keys/signatures and X448 formats as well.

We did fewer interop tests and the WG once had rough consensus.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20210224/6a0f0338/attachment.sig>