Re: [openpgp] call for adoption of draft-koch-openpgp-rfc4880bis

[Jon Callas <[e-mail]>]

> On Jun 27, 2016, at 12:35 PM, Robert J. Hansen <[e-mail]> wrote:
> 
>> Let me give two answers -- one a crypto answer and the other a
>> standards answer.
> 
> [de-lurks]
> 
> Jon, it seems like you're saying "since this is a purely normative
> document we can be as extensive as we want, and there are good reasons
> for purely normative documents to be extensive."

Well, no, that's not what I'm saying.

It seems to me that you're setting up a straw man. I realize you're probably not, but that's what I'm saying.

What I am saying is that in this *specific* case, the risks of adding it are low.

I recognize that options are good and options are bad. There's a cost to options, but there's a cost to not having them.

> 
> The presence of an algorithm in the spec tends to create pressure on
> implementations to support that algorithm.  When RFC2440 had reserved
> entries for TIGER192, there was a small but vocal crowd in the GnuPG
> community crying out, "we need TIGER192, it's in the spec!"  And as soon
> as TIGER192 was removed, those voices died out -- because hey, it's no
> longer in the spec.

I think I disagree, because one of the reasons Tiger and others were removed is that they essentially weren't being used.

But -- let me just concede the point. We made a mistake in removing Tiger, then. We removed it because there was no constituency. If there *was* a constituency and we didn't realize it, we made a mistake. 

However, let me address your larger point, the "pressure" to support an algorithm.

In 2440/4880 there were two reference implementations, PGP and GnuPG. For better or worse, PGP did not implement Blowfish (actually, it's more complex than that -- PGP would *decrypt* a message encrypted with Blowfish because some versions of GnuPG didn't do cipher negotiation properly, but it wasn't offered as a choice and never encrypted to it). It didn't implement SAFER nor DES/SK. It did not implement Elgamal signatures. It didn't implement Tiger nor Haval nor MD2. 

GnuPG took the admirable stand of implementing everything in the standard, but still didn't implement RSA until the patents expired. (But that is also something that's more complex than the simple preceding sentence.)

I know that today, there are a number of implementations that don't do Camellia. 

You are absolutely right that in some places implementers just go and implement whatever. The OpenPGP community hasn't ever been one of those places, it's been a raucous group of people with definite opinions and tastes. That has never been a problem here. OpenPGP is designed so that people can go play in their own sandbox with no detriment to the people who don't want to play.

Rich Salz brought up a great suggestion -- put the identifier registry outside the main document, which would help as well. That takes pressure off of the casual reader.


> 
> I am completely and vigorously in favor of OpenPGP retaining the ability
> to be agile with respect to algorithms.  (In fact, I'd like to see more
> work go into this.)  But with respect to adding new reserved numbers,
> due to the tendency of users to see the spec as prescriptive rather than
> normative, I'd like to see us be more conservative.
> 
> Also, on a somewhat tangential note -- for more than twenty years we've
> been talking off and on about a prescriptive OpenPGP RFC, one that would
> focus on what was a good idea as opposed to what was strictly legal.
> We've never done it.  I'd like to see that change.

Okay. That gets to the core of it. If the standard is prescriptive with everything as MUST, then sure, you have to be difficult about what you allow.

If you don't want AE because it's an impediment to a prescriptive, that's a different discussion. We should have the discussion of a prescriptive standard on its own.

	Jon