On Jun 27, 2016, at 12:35 PM, Robert J. Hansen
<rjh(_at_)sixdemonbag(_dot_)org> 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
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp