Re: [Cfrg] New Version Notification for draft-whyte-select-pkc-qsh-00.txt

[Simon Josefsson <[e-mail]>]

"Blumenthal, Uri - 0553 - MITLL" <[e-mail]> writes:

>>Many crypto libraries cannot know for what
>>purpose their APIs will be used for, so limiting the ability to use an
>>algorithm for "an IETF protocol" is in practice a non-starter for
>>deployment.
>
> There’s a big difference between a library and a protocol. Not to mention
> that IETF traditionally does not deal with either API or libraries.
>
> A library may include whatever algorithm the authors/maintainers want to -
> the legal issues usually fall on the lap of the user,

That is not consistent with my view or experience.  If you publish a
library that implements a patented algorithm, and your library is
popular enough to attract attention from the patent holder, you will
have a hard time.

> unless the library is a commercial product, in which case it’s a whole
> different ballgame.

In what sense?  The majority of libraries we are talking about (OpenSSL,
libgcrypt, Apple's crypto libraries, Microsoft's crypto libraries, etc)
are sold commercially.  I cannot come up with any crypto library that
would be relevant to the Internet that is not sold commercially.

> A protocol is something that IETF defines, and requires those who claim
> conformance to actually implement the algorithms included in that
> definition. Specifying an algorithm here subjects both developer (who may
> want to sell the conformant product) and user (who unsurprisingly may want
> to use this conformant product) to potential legal licensing issues. Which
> I personally find undesirable and inexcusable.
>  
>
> So, a library is something outside of IETF scope (or interest), and can
> contain anything. A protocol is something “blessed” by IETF, and it better
> not contain algorithms that require licensing fees in any shape or form
> (yes I’m aware of exceptions, and want to see their number drop, not
> increase).

Lucky we are in the IRTF here and not in the IETF then. :-)

/Simon