It is of course an issue for implementer adoption as well as user adoption. If
no one implements it, no user can use it, no matter how much they want it. And
since there are people who want to implement this, I don’t think the intention
of the spec is to stop implementers from doing so.
The stated concern is only about whether Debian will carry any cryptographic
library that implements OCB. OpenSSL and Botan are both Debian packages that
already contain OCB today, and it should not be different with libgcrypt. At
least it seems that the other issues are addressed.
Everyone has different expectations of what the spec should be, or what IETF
RFCs should be or should stand for. In this case, I do not believe the IETF
publication process has anything to do with the objection of OCB. Especially in
this case, the patent owner has already demonstrated strong history of allowing
open source usage.
We all appreciate the work put into adding the AEAD packet specifications and
making a real registry of it. It should be a good thing that someone proposes
to actually use the AEAD registry. There’s really no reason blocking others
from doing what they want.
Again, no one is taking anything away from the spec with a “MAY” phrase.
_____________________________________
Ronald Tse
Ribose Inc.
On Oct 28, 2017, at 8:33 AM, brian m. carlson
<sandals(_at_)crustytoothpaste(_dot_)net<mailto:sandals(_at_)crustytoothpaste(_dot_)net>>
wrote:
On Fri, Oct 27, 2017 at 10:12:51AM +0000, Ronald Tse wrote:
3. The misunderstanding that OpenPGP implementers will not implement OCB due to
IPR disclosures.
This has nothing to do with whether implementers will implement it.
This has to do with whether users will be willing to use a spec or
implementation that has patent concerns associated with it.
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.
GnuPG relies on libgcrypt for cryptographic functionality. On Debian,
libgcrypt is linked into Xorg, which is often linked to proprietary
software such as graphics drivers. Since Debian cannot avail itself of
license 2 (because restrictions on military use are unacceptable) and
license 1 prohibits uses with proprietary software, Debian's GnuPG is
unlikely to have support for OCB unless Debian ships two separate copies
of libgcrypt. For the same reason, Ubuntu is also likely to have the
same policy.
I've filed a bug with Debian to bring this to their attention.
These are the kind of practical reasons that patented software is
problematic and should not be a part of any specifications. I don't
believe there's a consensus on adding this, since the groups seem at
best evenly split. Previous opinions in the working group were mostly
negative.
I remain wholly opposed to including OCB in the OpenPGP specification,
and if this specification should make it to last call with OCB included,
I will oppose it on those grounds.
--
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp