Re: [openpgp] Proposal to include AEAD OCB mode to 4880bis

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@cs.auckland.ac.nz<mailto:pgut001@cs.auckland.ac.nz>> wrote:

Werner Koch <wk@gnupg.org<mailto:wk@gnupg.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@ietf.org<mailto:openpgp@ietf.org>
https://www.ietf.org/mailman/listinfo/openpgp