Thank you Werner, I share the same opinion.
One-size-fits-all is often a misnomer. I believe having an option is usually
better than not having one.
_____________________________________
Ronald Tse
Ribose Inc.
On Oct 27, 2017, at 7:07 PM, Werner Koch <wk(_at_)gnupg(_dot_)org> wrote:
On Fri, 27 Oct 2017 12:38, hanno(_at_)hboeck(_dot_)de said:
Don't add multiple algorithms unless there isn't a very good reason for
it. Add one that is good for everything. Having a "may" algorithm only
There is a good reason for adding a MAY mode:
- We want an AEAD mode.
- The WG seems not to like OCB for political (patent) reasons.
- Thus the proposed solution is to require EAX but prepare for other
modes.
- OCB has been suggested as such another mode.
- We can add it to rfc4880bis as MAY mode to give a specification in
case someone will implement it anyway.
Consider what will happen if we don't do this: OCB may be implemented
anyway but at best an I-D extending RFC4880bis is used as specification.
Or worse, there is no spec at all and everyone implements it in slightly
different ways.
Also: The first revisions of I-Ds for RFC6637 (ECC for OpenPGP)
specified _only_ NIST curves and didn't allowed for any other curves.
This has been challenged and fortunately RFC6637 allows for arbitrary
curves, albeit less well specified. Without that semi-MAY we would not
have been able to deploy software using modern curves. Patents on ECC
are still a minefield but nevertheless everyone is moving towards ECC.
The GPG protocol is far more complex than it has to be.
You mean OpenPGP.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
signature.asc
Description: Message signed with OpenPGP
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp