potential IETF WG incompatibility with GnuPG 2.3

Bernhard Reiter bernhard at intevation.de
Thu Dec 15 10:11:30 CET 2022


Hey Vincent,

Am Dienstag 13 Dezember 2022 12:07:20 schrieb Vincent Breitmoser via 
Gnupg-devel:
> On 13.12.22 09:35, Bernhard Reiter wrote:
> > It has to be seen if whatever the IETF workgroup comes up with
> > is a good update to RFC4880. 

> I'm not sure how you would qualify a "good" update here?

something that is useful to users (in the end) and updated RFC4880
in an interoperable and technical good way for asychronous, end-to-end 
cryptopgraphy. (Rough, I know, but maybe good enough for this post.)

> If there is a new revision it'll be the standard by definition,
> and you can conform to it or not.

It still maybe a bad revision.
And yes, this comes down to the question of who will be able to shape and 
define what OpenPGP is. Usage has always had an important influence on 
evolving standards, this is why I have added the case of your koo deliberate 
incompatibility to RFC4480 as an example.

> If you have doubts it will be a "good" update, they are currently asking
> for a last round of feedback on it.

To put time into the committee work personally I would need to be convinced 
that it is well invested time. Given that Werner, Niibe-San and others will 
have given technical feedback already, I am not sure if it is worth the time.
(See my answer to Andrew for more elaboration.)

> > In previous IETF OpenPGP standardisation processes, it seems that well
> > working practice was considered to a large extend, it seems natural up to
> > a point to try and see if new things are needed and useful.
>
> Agreed. That's what the --rfc4880bis flag did, and reasonably so. But
> unless I misread the commit, we're talking about GnuPG emitting a
> GnuPG-specific certificate format by default here, so no experiment by any
> means?

I don't know. But what were the reasons the current working group did decide
to go with a different package format? Do you think it was the better choice?

> > (Same as you did when you have decided to made keys.openpgp.org
> > incompatible to the existing OpenPGP standard
>
> Indeed, so I did. 
[rest of the example cut out]

> I'm not insinuating anything, I'm openly pointing out a commit that changes
> GnuPG default behavior in a significant way, and asking what the plans here
> are.

When I have read your email, the subject and the 
"will be incompatible with the upcoming OpenPGP standard."
and your remark at 
https://dev.gnupg.org/rG4583f4fe2e11b3dd070066628c3f16776cc74f72#75449
leans my understanding towards a non constructive question, because it frames 
the burden of answering it onto GnuPG's devs.

It is the little things in your phrasing
 a) The WG does not yet has a new spec on "OpenPGP" only proposal.
 b) The WG does not define alone what "OpenPGP" is in the wild.

And the framing and omissions: 
 c) you do understand that there are good reasons
for going ahead in an implementation, even if it is not ahereing to the 
standardised protocols. But you are not displaying that you have given the
potential reasons a deep thought in the question or on the list here.
 d) You do not explain or ask what and why the WG is going a way to be   
incompatible to a useful and widely deployed implementation (and long time 
contributors to the WGs.)

Regards
Bernhard
-- 
https://intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20221215/a8d9d02a/attachment.sig>


More information about the Gnupg-devel mailing list