Thank you Werner for the supporting comment. Seeing the comments I think we all
agree that OCB is a great AEAD mode, and the only concern is about its IP.
1. A number of statements have been made regarding IETF standards and patents,
but those statements do not necessary reflect today’s reality.
IETF’s IPR page details its stance towards IP and specifically, patents. There
does not seem to be no requirement that the standard is “unencumbered”, “free”
or “gratis”. The requirement is that licenses must be granted in a
non-discriminatory way.
In the IETF’s IPR disclosure listing (https://datatracker.ietf.org/ipr/), you
can find quite a few examples of newly published RFC documents that are clearly
covered by issued patents, with no “indemnification” for implementers.
In fact, RFC 8179 clarifies the following for a Standards Track document:
----
9. Licensing Requirements to Advance Standards Track IETF Documents
Section 2.2 of RFC 6410 [RFC6410] states:
If the technology required to implement the specification requires
patented or otherwise controlled technology, then the set of
implementations must demonstrate at least two independent,
separate and successful uses of the licensing process.
A key word in this text is "requires". The mere existence of
disclosed IPR does not necessarily mean that licenses are actually
required in order to implement the technology.
----
For RFC 8179 compliance, there are already 3 licenses issued on Rogaway’s web
site, and many others that are not shown there. This means that incorporating
OCB in the 4880 document would NOT affect its status as a Standard.
2. There has been some misunderstanding regarding the OCB license coverage.
a. OCB is already shipped in Red Hat and Debian today in the OpenSSL and Botan
cryptographic libraries.
b. Linking and distribution of any closed-source software with an open-source
software (OCB License 2: as defined by the FSF, including BSD, GPL licenses),
is already an accepted, licensed use of OCB.
In all of Brian’s examples, linking or distribution of “any closed-source
software shipped on that system or any non-open-source custom-built apps” that
utilize an OCB-enabled open-source crypto library, is explicitly allowed by
License 2.
3. The misunderstanding that OpenPGP implementers will not implement OCB due to
IPR disclosures.
Werner of GnuPG, has already indicated support to OCB on multiple occasions.
Our own open-source OpenPGP implementation, RNP, will implement OCB. Anyone
that uses popular cryptographic libraries like OpenSSL and Botan can already
implement this and is covered by the licenses.
Again, OCB is proposed to be a MAY algorithm, not a MUST or even a SHOULD — if
someone doesn't like it, there is no need to prevent others from using it.
Thanks for the comments.
Ron
_____________________________________
Ronald Tse
Ribose Inc.
On Oct 27, 2017, at 4:46 PM, Peter Gutmann
<pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz<mailto:pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz>>
wrote:
Werner Koch <wk(_at_)gnupg(_dot_)org<mailto:wk(_at_)gnupg(_dot_)org>> writes:
rfc2440 and rfc4880 both included IDEA as a SHOULD algorithm despite that
IDEA was patent encumbered. Also RSA was patent encumbered when 2440 was
published and nevertheless a SHOULD algorithm.
They were there because there wasn't much choice. PGP 2.0 used IDEA and RSA,
so it had to be kept around for future versions, although it was only a
SHOULD, not a MUST. With OCB in contrast you're introducing a new patent-
encumbered algorithm for no obvious reason.
If you really want the protection that OCB offers then encrypt-then-MAC is a
totally unencumbered way of doing the same thing. It's been in S/MIME for
years.
Peter.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org<mailto: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