ietf-openpgp
[Top] [All Lists]

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

2016-06-28 03:18:54
Folks, if you want to discuss the document itself, please change the
subject line appropriately, to start a new thread.  Please leave this
thread for comments about using this draft as the starting point for
the work.

Barry, as chair


On Mon, Jun 27, 2016 at 6:20 PM, Jon Callas <joncallas(_at_)icloud(_dot_)com> 
wrote:

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

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp

<Prev in Thread] Current Thread [Next in Thread>