Standards: IETF WG proposing incompatible despite implementations and objections

Bernhard Reiter bernhard at intevation.de
Thu Apr 27 17:16:10 CEST 2023


Am Donnerstag 27 April 2023 13:41:38 schrieb Andrew Gallagher via Gnupg-devel:
> On 27 Apr 2023, at 09:04, Bernhard Reiter <bernhard at intevation.de> wrote:
> > Just to consider the point Bruce brought up: Why is EAX still in?
> > Where can I read up on the argument on this?
>
> AFAICT it’s still in mainly because it’s optional and nobody has formally
> proposed to remove it - Bruce has brought it up a few times but nearly
> always in conjunction with other points that don’t have consensus; there
> doesn’t appear to have been a specific proposal on the WG list to only
> remove EAX but keep everything else as is. It may be worth removing EAX if
> nobody intends to implement it, but if nobody implements EAX there’s no
> urgent need to remove it either.

What would someone, e.g. Bruce, 
need to do to remove EAX from the current draft?
I mean a simpler specification is better, so if an optional thing
is not needed, it SHOULD be taken out. 

> The competing proposals are not contradictory; the version bump has avoided
> that. It is possible for individual implementations to support both “v5”
> and “v6", even if only partially (e.g. read-only support for the “wrong”
> format). This would seem to me to be the most productive compromise path
> forward at this point, however the WG cannot officially suggest such a
> thing. :-)

Thanks for pointing this out. Again I am trying to understand the situation.

[me responding to Vincent]
> > What you are saying is that the working group wants to oppose Werner for
> > showing that they have the power and need to be taken seriously.
>
> This is not fair. Most people on the WG have come around to the current
> position with extreme reluctance. 

I merely infered from Vincent's impression here. I am happy you are presenting 
a different view on it.

> If there were some way to reconcile the competing proposals
> even at this late stage, there would be great rejoicing.

What would need to be done to do this?
With Werner's emails and new draft since Februrary, there seems to be 
something to work on and put forward arguments. Do you know if they have been 
discussed in the working group since then?

The way I see is that someone digs into the technical arguments; at least to 
document why different groups come to their suggestions.
Personally I may not have the time nor the expertise to really go into the 
cryptographic details. who could?

Best 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/20230427/8837718b/attachment.sig>


More information about the Gnupg-devel mailing list