On Mon, 30 Oct 2017, Derek Atkins wrote:
As for we have been doing this for 20 years argument, I am still carrying
idea.c and still have to manually compile it every time gpg upgrades. So
the “current” scheme has proven to not work well at all for me.
Honestly, AFAIK there has never been a security issue with IDEA; just
patent/licensing. At this point I think all those issues are gone, too,
so honestly there's little reason not to include it natively.
It was an example of how some people having IDEA and other not having it
causes interop issues to the point that I need to manually hack my
implementation to talk to those people. That's something you want to
avoid more then giving people a list of 6 sexy algorithms to choose
from.
But the real point is that there are so few methods that people want to
support *IN THE PROTOCOL* that there is little reason, IMNSHO, to prevent
them from doing so in a standard way.
I don't understand that sentence.
Remember, just because the protocol supports a method does not mean
implementations will.
If you add things to the protocol that the vast majority will not
implement, you have lost already and that added thing becomes useless.
But if the protocol does NOT support some methods
it might prevent some users from using the protocol.
Which is a good thing? Do you think most users can make a meaningful
decision about which algorithms to trust or not and for how long?
The reason for a lot variance with TLS or IKE/IPsec with protocols is
that performance does matter. For openpgp, performance hardly matters.
You're not doing 1Gbps or running on an IoT device with 32kb RAM or
require less then 25ms latency.
Paul
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp