Re: [openpgp] a new draft overlapping the WG draft

[Kai Engert <[e-mail]>]

On 27.09.22 17:54, Paul Wouters wrote:
> If there is an interoperability split with one
> implementation, I guess the endusers will figure out what they will
> do, with options being ditch openpgp entirely, or ignore one
> implementation for interoperablity, or perhaps do the extra work
> for supporting non-standard draft specifications with the added
> security risks involved.

Let's say the OpenPGP community splits, and two new flavors of OpenPGP 
are defined.

An email client might want to be able to interoperate with both flavors.

The email client might not know which flavor of OpenPGP a recipient 
implements. Or it might be necessary to send a message to multiple 
recipients, some using flavor 1 and others using flavor 2.

What should the email client do?

The simplest choice is to only use the common denominator of both 
flavors, and disable all features that are known to have limited 
compatibility. It might be difficult to understand what exactly is 
defined in both flavor specifications, so it might be easiest to simply 
stay with the older specification. My worry is, if the community splits 
by defining two different flavor specifications, isn't it likely that 
both specifications are ignored?

(Another possibility could also implement both flavors, and always send 
all messages in both flavors. However, that seems impractical to me, and 
most applications probably wouldn't want to do that.)

My earlier statement, in which I suggested to use the common denominator 
and drop other suggestions, was based on two assumptions:

Assumption 1:
Most applications that implement OpenPGP want universal interoperability.

Assumption 2:
The two suggested documents have a good set of agreements, so even 
taking the denominator would result in a useful improvement.

Based on other messages in this thread, it sounds like my assumption 2 
was wrong?

Is my assumption 1 wrong, too? Is there a significant amount of 
applications, which wouldn't require universal interoperability?

I really think a split of the community should be avoided. It's already 
a challenge to use OpenPGP across a channel like email. If two flavors 
are implemented, then email clients might have to display messages like 
"this message cannot be decrypted because the sender used encryption 
technology that this software does not support". Users shouldn't be 
required to run two different email clients to be able to read all their 
encrypted email.

Kai