Subject: [Cfrg] Patents and the new elliptic curves

From: Michael Hamburg <[email-masked]>
Date: Tue, 16 Sep 2014 14:56:38 -0700

Hello CFRG,

I’m concerned about patent issues which may affect the new elliptic curve standards.

There has been a side discussion involving several members of this list, including some Microsoft researchers, on the subject of what patents may apply to proposed curves and their implementations and in particular to the NUMS curves.

Microsoft has a policy of avoiding patent searches, not reading patents, not commenting on patents etc, so they have not been particularly helpful.  However, I am concerned that the Microsoft-held US7602907 (and possibly foreign equivalents) may apply to their implementation, covering the mLSB combs algorithm.  Benjamin Black has refused to confirm or deny this.  The NUMS code itself is still usable under the Apache2 license, but it has a "mutually assured destruction” clause, and other implementations might infringe.

So I have a few questions for the list.  First, am I right to be concerned that US7602907 reads against the NUMS code?  How does this interact with the BCP, since the curve’s spec does not require the patent, but the reference implementation does?

Second, is anyone aware of other patents that may read on SafeCurves-style Montgomery or (twisted) Edwards implementations, especially of the proposed curves (\w+)25519, Curve41417, MS NUMS, Ed448-Goldilocks or E-521?  It is required that new curves be efficiently and securely implementable without stepping on such patents, so it is critical to know what they are.

Third, given that mLSB combs may be encumbered, does anyone have information on the patent status of other state-of-the-art comb algorithms?  I’m particularly hoping that the signed all bits set (SABS) combs algorithm used in Goldilocks is patent-free, but I have only conducted a limited search.

Thanks,
— Mike Hamburg

---

From: Benjamin Black <[email-masked]>
Date: Tue, 16 Sep 2014 15:32:27 -0700

Mike,

As I explained in that formerly private discussion, we have asked for an
internal legal review on US7602907 as we were unaware of it at the time the
code and drafts were written. I am not in a position to comment on whether
it is a concern, and until that review is complete there is nothing for
anyone to confirm or deny.

Large companies work this way, including that avoidance of reading patents
to limit exposure in the event of IP litigation. While bashing Microsoft
and its employees seems to never go out of fashion, it is not merely
unhelpful, but counterproductive and inappropriate here. We are
participating in this process in good faith and assume everyone else is, as
well, even if there are points of disagreement.

It does strike me as odd you are criticizing us for not doing extensive
patent searches when you haven't done so and BCP 79 does not require it. I
hope everyone will be held to the same standard here, whatever it is.

b

On Tue, Sep 16, 2014 at 2:56 PM, Michael Hamburg <[email-masked]> wrote:

> There has been a side discussion involving several members of this list,
> including some Microsoft researchers, on the subject of what patents may
> apply to proposed curves and their implementations and in particular to the
> NUMS curves.
>
> Microsoft has a policy of avoiding patent searches, not reading patents,
> not commenting on patents etc, so they have not been particularly helpful.
> However, I am concerned that the Microsoft-held US7602907 (and possibly
> foreign equivalents) may apply to their implementation, covering the mLSB
> combs algorithm.  Benjamin Black has refused to confirm or deny this.  The
> NUMS code itself is still usable under the Apache2 license, but it has a
> "mutually assured destruction” clause, and other implementations might
> infringe.
>
> So I have a few questions for the list.  First, am I right to be concerned
> that US7602907 reads against the NUMS code?  How does this interact with
> the BCP, since the curve’s spec does not require the patent, but the
> reference implementation does?
>
> Second, is anyone aware of other patents that may read on SafeCurves-style
> Montgomery or (twisted) Edwards implementations, especially of the proposed
> curves (\w+)25519, Curve41417, MS NUMS, Ed448-Goldilocks or E-521?  It is
> required that new curves be efficiently and securely implementable without
> stepping on such patents, so it is critical to know what they are.
>
> Third, given that mLSB combs may be encumbered, does anyone have
> information on the patent status of other state-of-the-art comb
> algorithms?  I’m particularly hoping that the signed all bits set (SABS)
> combs algorithm used in Goldilocks is patent-free, but I have only
> conducted a limited search.
>
> Thanks,
> — Mike Hamburg
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Michael Hamburg <[email-masked]>
Date: Tue, 16 Sep 2014 16:30:14 -0700

Hi b,

I’m sorry that email.  I should have phrased this less aggressively, and I should also have mentioned that you have asked legal to review US7602907.  However, that review will answer at most one of the questions I asked, and you have resolutely refused to help with the others.

Please understand that my goal here isn’t to bash Microsoft or its NUMS proposal, but to make sure that new curves can be efficiently implemented in a way that avoids the patent minefield.  To do that, we need to know where the mines are.

I expect (though I am not sure) that any patents that may turn up will not affect which curves should be chosen, either because they can be worked around or because they apply equally to all curves.  However, it is likely that patents will influence protocols and internal algorithms, and perhaps also things coordinate choice or point encoding.  Conceivably the result could be relevant to the Montgomery vs Edwards discussion, particularly if there is no IPR-free version of the comb algorithm.

To my knowledge, there are exactly two open-source implementations available of the newer (i.e. non-25519) curves: Goldilocks and NUMS.  It is likely that if one of those curves is chosen, those packages may be used as a starting point in TLS libraries.  It is therefore necessary to determine whether they are patent encumbered, and how.

The Apache2 license grant is very helpful, but as you are aware it is not sufficient for this purpose; we need to be able to remove any code which may implement patented procedures.

I admit to having the less helpful MIT license on my source code.  At the same time, I do not believe that it implements any patented algorithms, and I would like to be more sure that this is true.

Your accusation of hypocrisy is, of course, inaccurate.  I have spent many hours searching for patents which may impact elliptic curve implementations, because I want to make sure I and other implementers can create unencumbered implementations.  This is why I know about US7602907.

However, I cannot claim to have combed through all possibly relevant patents, and I cannot claim to know that any particular technique is OK.  This is why I hedged my statement about searches, and why I have asked the CFRG for help.

It is not appropriate to compare my concern that I have missed something with a determined ignorance of even your own company’s patents.

I have additional thoughts regarding BCP 79, but I will discuss them with you off list first to avoid causing more trouble.

Cheers,
— Mike

> On Sep 16, 2014, at 3:32 PM, Benjamin Black <[email-masked]> wrote:
> 
> Mike,
> 
> As I explained in that formerly private discussion, we have asked for an internal legal review on US7602907 as we were unaware of it at the time the code and drafts were written. I am not in a position to comment on whether it is a concern, and until that review is complete there is nothing for anyone to confirm or deny. 
> 
> Large companies work this way, including that avoidance of reading patents to limit exposure in the event of IP litigation. While bashing Microsoft and its employees seems to never go out of fashion, it is not merely unhelpful, but counterproductive and inappropriate here. We are participating in this process in good faith and assume everyone else is, as well, even if there are points of disagreement.
> 
> It does strike me as odd you are criticizing us for not doing extensive patent searches when you haven't done so and BCP 79 does not require it. I hope everyone will be held to the same standard here, whatever it is.
> 
> 
> b
> 
> 
> 
> On Tue, Sep 16, 2014 at 2:56 PM, Michael Hamburg <[email-masked] <mailto:[email-masked]>> wrote:
> Hello CFRG,
> 
> [email-masked] <mailto:[email-masked]>
> http://www.irtf.org/mailman/listinfo/cfrg <http://www.irtf.org/mailman/listinfo/cfrg>
>

---

From: Michael Hamburg <[email-masked]>
Date: Tue, 16 Sep 2014 16:50:05 -0700

* I’m sorry *about* that email.  Also sorry for this spam.  Also, I need to use “make plain text” more.

> On Sep 16, 2014, at 4:30 PM, Michael Hamburg <[email-masked]> wrote:
> 
> Hi b,
>

---

From: Benjamin Black <[email-masked]>
Date: Tue, 16 Sep 2014 16:51:22 -0700

Mike,

Thanks for clarifying. I think there might be another misunderstanding,
though. I, personally, don't make a habit of reading patents. I,
personally, won't do a patent search to try to answer your concerns. That
is entirely reasonable and consistent for the reasons I, and others, have
explained. Those responsible for doing such reading and searching are doing
so in the context of '907, as you have known since that review started.
That is the opposite of steadfast refusal to help and why I take issue with
your comments.

However, that approach is cumbersome and slow. We are continuing to discuss
internally how best to eliminate IPR concerns in ways that are simple to
understand, simple to implement, and simple for all participants here to
apply equally. When we have something to propose on that front we will
share it here.

b

On Tue, Sep 16, 2014 at 4:30 PM, Michael Hamburg <[email-masked]> wrote:

> Hi b,
>
> I’m sorry that email.  I should have phrased this less aggressively, and I
> should also have mentioned that you have asked legal to review US7602907.
>  However, that review will answer at most one of the questions I asked, and
> you have resolutely refused to help with the others.
>
> Please understand that my goal here isn’t to bash Microsoft or its NUMS
> proposal, but to make sure that new curves can be efficiently implemented
> in a way that avoids the patent minefield.  To do that, we need to know
> where the mines are.
>
> I expect (though I am not sure) that any patents that may turn up will not
> affect which curves should be chosen, either because they can be worked
> around or because they apply equally to all curves.  However, it is likely
> that patents will influence protocols and internal algorithms, and perhaps
> also things coordinate choice or point encoding.  Conceivably the result
> could be relevant to the Montgomery vs Edwards discussion, particularly if
> there is no IPR-free version of the comb algorithm.
>
> To my knowledge, there are exactly two open-source implementations
> available of the newer (i.e. non-25519) curves: Goldilocks and NUMS.  It is
> likely that if one of those curves is chosen, those packages may be used as
> a starting point in TLS libraries.  It is therefore necessary to determine
> whether they are patent encumbered, and how.
>
> The Apache2 license grant is very helpful, but as you are aware it is not
> sufficient for this purpose; we need to be able to remove any code which
> may implement patented procedures.
>
> I admit to having the less helpful MIT license on my source code.  At the
> same time, I do not believe that it implements any patented algorithms, and
> I would like to be more sure that this is true.
>
> Your accusation of hypocrisy is, of course, inaccurate.  I have spent many
> hours searching for patents which may impact elliptic curve
> implementations, because I want to make sure I and other implementers can
> create unencumbered implementations.  This is why I know about US7602907.
>
> However, I cannot claim to have combed through all possibly relevant
> patents, and I cannot claim to know that any particular technique is OK.
>  This is why I hedged my statement about searches, and why I have asked the
> CFRG for help.
>
> It is not appropriate to compare my concern that I have missed something
> with a determined ignorance of even your own company’s patents.
>
> I have additional thoughts regarding BCP 79, but I will discuss them with
> you off list first to avoid causing more trouble.
>
> Cheers,
> — Mike
>
> internal legal review on US7602907 as we were unaware of it at the time
> the code and drafts were written. I am not in a position to comment on
> whether it is a concern, and until that review is complete there is nothing
> for anyone to confirm or deny.
>
>> So I have a few questions for the list.  First, am I right to be
>> concerned that US7602907 reads against the NUMS code?  How does this
>> interact with the BCP, since the curve’s spec does not require the patent,
>> but the reference implementation does?
>>
>> Second, is anyone aware of other patents that may read on
>> SafeCurves-style Montgomery or (twisted) Edwards implementations,
>> especially of the proposed curves (\w+)25519, Curve41417, MS NUMS,
>> Ed448-Goldilocks or E-521?  It is required that new curves be efficiently
>> and securely implementable without stepping on such patents, so it is
>> critical to know what they are.
>>

---

From: Watson Ladd <[email-masked]>
Date: Tue, 16 Sep 2014 19:07:09 -0700

On Sep 16, 2014 2:56 PM, "Michael Hamburg" <[email-masked]> wrote:
> Second, is anyone aware of other patents that may read on SafeCurves-style Montgomery or (twisted) Edwards implementations, especially of the proposed curves (\w+)25519, Curve41417, MS NUMS, Ed448-Goldilocks or E-521?  It is required that new curves be efficiently and securely >implementable without stepping on such patents, so it is critical to know what they are.

I am not a lawyer. I am not a patent lawyer. The slimiest schyster on
late night TV promising to get rid of your DUI is more of a lawyer
than I am. If you consider making any decision on the basis of what I
write, you are an idiot.

Most of this is due to DJB.

Now that we have said that, let me explain the patent situation as I
see it, regarding Montgomery ECC. The invention of ECC was in 1985:
the use of the x-coordinate only representation was mentioned in the
original paper. The use of Montgomery form to calculate on elliptic
curves was introduced in 1985 as well. It's possible someone files a
patent on the combination, but I cannot imagine that being a very
viable claim.

The efficiency gains from use of a special prime of the form 2^x-s
with s small were mentioned in a paper of Bender and Castagnoli in
1990, who didn't bother to mention how the this happened. Any claims
on particular algorithms are going to be difficult to make,
particularly if the algorithm is a specialization of Barrett reduction
because of this paper. It's not as clear as I would like.

When it comes to Edwards form, the formulas were published in 2007.
However, DJB didn't patent them in the US and is the inventor. I don't
know about other faster formulas. The situation for the primes is the
same as for Montgomery form. As for the exponentiation algorithms,
they are all in Knuth.

The signatures in Ed25519 are variants of Schnorr signatures, and the
patent expired in 2008.

In conclusion I am not worried about the patent issue for tweetnacl.c

> Third, given that mLSB combs may be encumbered, does anyone have information on the patent status of other state-of-the-art comb algorithms?  I’m particularly hoping that the signed all bits set (S…

Aren't the good algorithms in  Knuth, volume 2, due to Pippenger in
1976? In particular with complete addition laws there is no need to
worry about adding the identity, so many of the modifications in
things like signed wNAF are not needed. Of course, they may not be the
world's most efficient, but that's likely to be fine to get fast
enough.

Sincerely,
Watson Ladd

---

From: Alyssa Rowan <[email-masked]>
Date: Wed, 17 Sep 2014 08:05:39 +0100

Thanks, Michael.

> Microsoft has a policy of avoiding patent searches, not reading
> patents, not commenting on patents etc, so they have not been
> particularly helpful.

Of course it's going to be bloody hard for us to evaluate if curve
proposals are securely, simply and efficiently implementable on
grounds of IP1 and especially IP2 without checking the patent status
of ladders securely, simply and efficiently implementing them.

Being fair, Microsoft is far from a monolithic entity. Different
employees act differently. Some have been wonderful, friendly and
helpful. Some have been… less so.

For example, I find it incredibly hard to square the statements (from
the same person, Ben Black) that they went through "weeks of addition
review to ensure ECCLib [was] released under APL2" - yet somehow were
unaware of even their own company's patents in the same field
(notwithstanding they were apparently from MSR China)? Kindly explain.

I note the palpable irony of a few people sensibly investigating if
there's something up the sleeves of those introducing curves _named_
"Nothing Up My Sleeves", and meeting resistance.

We are waiting on a response from Legal (which has been chased).
Perhaps that will clarify matters regarding that patent in particular,
and any others which Microsoft hold or know about.

- -- 
/akr

---

From: Benjamin Black <[email-masked]>
Date: Wed, 17 Sep 2014 01:41:29 -0700

There is a difference between the review required for releasing some code
as open source and a patent search which is looking for specific claims. It
takes weeks even to do the simpler one. I'll assume you are unfamiliar with
either activity which is why the distinction was not clear to you. We
initiated the review of '907 (which covers a comb algorithm, not ladders,
by the way) almost immediately after Mike brought it to our attention, as
both of you were informed. That is the appropriate response in this
situation and was initiated not by the wonderful, friendly and helpful
folks, but by the folks who are less so.

You have received resistance to many of your other claims and demands,
including a number you have subsequently contradicted with your own
statements on the list. These include assertions that:

- BCP 79 requires extensive patent searches when it says the exact opposite.
- That ECCLib, or any other implementation, is a submission, when BCP 79
defines clearly it is not.
- That IP1 and IP2 apply to ECCLib, or any other implementation. Your
recent question to the list regarding this contradicts your earlier
unequivocal statement on this point.
- That we should've released the code under a "more permissive" license
like MIT, despite its complete lack of IPR protections.
- That Microsoft (and only Microsoft) should be required to grant
royalty-free licenses on every patent in the portfolio that could be used
for EC implementations.

I have asked you several times to articulate exactly what you are demanding
of us and when you will be asking the same, on the list, of all other
participants, but you have not done so. Instead, you have chosen to attack
me personally in public for not bowing to your bullying. If you have
further demands regarding participants in this process, kindly direct them
to the chairs.

b

On Wed, Sep 17, 2014 at 12:05 AM, Alyssa Rowan <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Thanks, Michael.
>
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJUGTLDAAoJEOyEjtkWi2t6/kkP/A/tC91G6XUzOWSl7inhWJqD
> D1zS1zPph05BJewDUqZaBz8FcySzc7/POBw0JQTfNJSshuFUfQerKijCVSTiarEp
> ODkrXgy+QImG3+tbogzdcZkVL9MVpRE4mbWG66Y3T+uDNGpStmvDAUaRGoPXfjt0
> LnHXa2WoeDTdW0uAOUa8wHPzBdiZmCzFbIs5HLxyrcwE1Q4WSXTLolLh7X3xwN+F
> 3CV75yFFll3hfx13FVvdeZIlHpIwGI7woeRh4AJ3d7nxn828wYDmYc9XfqYGVCxl
> 4t3WSDiSH5XQde+L1ZOmCIQ5ljoVXmgbOQv3+pTYjWdPfGGECGh5FDidYKvDKoIh
> s9M0mfU5tcympf+Gzua6dVkWLT8GBUjgAzep0nurX+i4zSExskftj/sO/GNymH0x
> hNuHP2k5q7ettlywioYnwOdZ1gsEvd2TkVQ/Xe0UHdpcSvyFUM/jCL/bATvLlNX6
> 0cQFgnC/0yc4d9r6KEQZT5Xo33vrJ2P9IddtcWdiUMieJhI0uukrKEeEMSF2M68g
> 1Os6T8CnBJ5ncV9mA1jLTYEDM8A1r+JccqI9LplK+U70iwSJ2qLEX0EWOyWRntSu
> UQGsumQOhm2RO50Tpjw8M3oqFypO/cBYDGla/FlZQjwxcxkIWCYR407p29gPh08Y
> iBcnDfLWChZVWGjLPKL6
> =fMvF
> -----END PGP SIGNATURE-----
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 17 Sep 2014 08:01:23 -0400

I am not a lawyer. But even if I was, I would not be your lawyer. And
that makes a huge difference.

Expecting any party to issue a free legal opinion on this subject is
futile. Microsoft, Google and all the major companies have spent
several billion dollars in the past few years on settlements and
damages in a long list of patent suits, most of which are utterly
devoid of any merit whatsoever.

One of the patent cases I was involved in was based on a particularly
twisted interpretation of a patent claim that the patent examiner had
specifically excluded in the patent prosecution history.

My concern here is not the risk of a lawsuit against my employer, it
is the risk of a lawsuit against my customers.

That said, the ECC patents are very different to the usual software
patents. These are not 'do it on the Internet' type 'inventions' and
they aren't submarine patents with claims on stuff invented by other
people in continuations after the application was first filed. These
are patents making claims about very specific inventions. And the
original patents on the principal inventions were filed between 1985
and 1990.

---

From: Michael Hamburg <[email-masked]>
Date: Wed, 17 Sep 2014 10:30:42 -0700

To further clarify, when I sent out the initial request, I didn’t expect everyone to initiate legally rigorous patent searchers on behalf of their employers.  Nor did I intend to demand anything, though I cannot speak for Alyssa or Robert.

My question about IPR requirements of this working group seems to have been answered: Benjamin Black says they do not apply here, and I’m inclined to believe him unless there are well-sourced objections.

But I continue to hope that other people with experience in implementations and patents will contribute their wisdom on what patents might apply to the latest batch of curves.  This is not legally required, and I don’t expect to receive legally rigorous analyses.  It also probably has no bearing on which curve should be selected, at least to the degree that any patents can be worked around.  But avoiding patents in this area is critically important for anyone who ends up actually using these curves.

I remind you that the inspiration for this thread was the possibility that Microsoft’s ‘907 patent applies to their NUMS software, but that nobody noticed until now because they were intentionally ignoring patent concerns.  You can walk through a minefield blindfolded, but it may not be the best strategy to avoid getting blown up.  So: does anyone see anything?

— Mike

> On Sep 17, 2014, at 5:01 AM, Phillip Hallam-Baker <[email-masked]> wrote:
>

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Wed, 17 Sep 2014 18:06:48 +0000

On 9/17/14, 13:30 , "Michael Hamburg" <[email-masked]> wrote:

>…….But I continue to hope that other people with experience in
>implementations and patents will contribute their wisdom on what patents
>might apply to the latest batch of curves.  This is not legally required,
>and I don’t expect to receive legally rigorous analyses.  It also
>probably has no bearing on which curve should be selected, at least to
>the degree that any patents can be worked around.

If a curve is selected because it appears to offer significant performance
benefits over other (or over the currently used) curves, and then it turns
out that a patent prevents you from realizing those performance
advantages…?

>But avoiding patents in this area is critically important for anyone who
>ends up actually using these curves.

Yes.

>I remind you that the inspiration for this thread was the possibility
>that Microsoft’s ‘907 patent applies to their NUMS software, but that
>nobody noticed until now because they were intentionally ignoring patent
>concerns.  You can walk through a minefield blindfolded, but it may not
>be the best strategy to avoid getting blown up.  So: does anyone see
>anything?

IANAL. I hope that when Microsoft review is concluded, they’d post the
results here. I don’t expect (or want) this group to make a decision until
then.

My main concern is what other patents (held by other parties) might be
lurking there.

---

From: Alyssa Rowan <[email-masked]>
Date: Thu, 18 Sep 2014 00:04:13 +0100

On 17/09/2014 09:41, Benjamin Black wrote:

> [a bunch of stuff]

Wow. Look. I am quite plainly not in a position to demand, or bully,
anything from anyone. If you somehow read my questions, suggestions
and requests in that way in our offlist discussion, despite the CCs,
then I think we have perhaps simply reached a profound misunderstanding.

I simply want the situation regarding all proposals to be as clear as
it can be: and at present, X25519 and Ed25519 seem, I think, much
clearer than NUMS. (I am slightly less clear about Goldilocks and
E-521, but I've looked into them less.) I think we all want
transparency on this, given the general area of the IP1 and IP2
requirements.

I would have thought anyone implementing their proposal in their
reference implementation, treading on a fairly-specific comb patent
they didn't know about - owned by the same company, but somehow missed
in a careful pre-release legal review despite the open-source licence
containing a limited patent grant - would understand why everyone
wants as much clarity as possible in this area. Nobody wants anything
up _anyone's_ sleeves, really. Our interests all align there.

I have indeed previously misinterpreted the scope of the BCP - which
is not quite as wide as I had thought and indeed does not cover
reference implementations as submissions itself - although it makes it
terribly hard to discuss performance characteristics, which I think
will an important factor in upstream adoption, in real terms without
at least considering reference implementations. I've tried to correct
my misunderstanding there. I still think it would benefit everyone if
all participants could clear the minefield as much as possible, and I
think we're all on the same page about that generally.

In particular, I do suggest that it'd benefit all proposals if
reference implementations were available for as wide use as possible,
as clearly as possible. That seems strongly in the spirit of IP1 and
IP2, and also in the spirit of recommendations actually getting _used_
upstream, which you also want. That's why I suggested that you could,
if you wished, take an approach that wouldn't be incompatible with
GPLv2 (cf: Linux) & BSD (cf: BSDs) licences as I believe Apache 2.0
is, but could actually (as you say) eliminate IPR concerns; Opus might
be a good case study here?

In any case, I very much look forward to hearing what, if anything,
you do propose, and the result of any legal review if you care to let
us know. Thanks.

- -- 
/akr

---

From: Harry Halpin <[email-masked]>
Date: Thu, 18 Sep 2014 01:24:39 +0200

Personally, I don't think patents should be an issue in deciding curves
for CFRG recommendation by NIST. Instead, I'd like a purely technical
judgment for the recommendation by CFRG, and am eagerly awaiting it.

That being said, I don't want patents to derail this discussion. I do
know that the W3C (World Wide Web Consortium) offers Rec-track documents
a very strong royalty-licensing commitment from most of Silicon Valley
and beyond.

The W3C Web Cryptography Working Group is debating including whatever
curve CFRG recommends in the Rec-track Web Cryptography API [1]. For
those that aren't already following that fun discussion, some (although
not all) members of the WG want to include non-NIST ECC curve support in
the final document, which we believe would sync with the CFRG
recommendations to TLS.

I'm not a lawyer but I could double-check, yet I think that one nice
side-effect of baking the CFRG non-NIST recommendation into a W3C spec
would be that a patent troll would have a very difficult time I think
going up against the W3C RF patent policy [2]. Note as part of W3C,
Microsoft could commit patents to NUMS to RF licensing. And I'd be
surprised to say the least if DJB had patents, and concerns of others
trolling his work would also I think be strengthened by the W3C RF
licensing.

I believe the IETF also has a patent policy as well, although I'll leave
it to someone from the IETF to fill us in on that.

  yours,
      harry

[1] https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html
[2] http://www.w3.org/Consortium/Patent-Policy-20040205/

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Thu, 18 Sep 2014 16:55:05 +0000

>for CFRG recommendation by NIST. Instead, I'd like a purely technical
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^???
>judgment for the recommendation by CFRG, and am eagerly awaiting it.

IETF and IRTF have always been about interoperable *implementations*. Thus
there cannot be a “purely technical” judgement that ignores such an
important aspect of implementability.

I’d like to remind that IETF hasn’t touched RSA for many years precisely
because it was not available to implementers under the patent
strangulation. Similar situation repeated with ECC. (And something similar
is likely to happen with NTRU, for much the same reasons.)

>trolling his work would also I think be strengthened by the W3C RF

Possible.

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 22 Sep 2014 09:32:50 -0700 (PDT)

On Wed, September 17, 2014 10:30 am, Michael Hamburg wrote:
> I remind you that the inspiration for this thread was the possibility that
> Microsoft’s ‘907 patent applies to their NUMS software, but that
> concerns.  You can walk through a minefield blindfolded, but it may not be
> the best strategy to avoid getting blown up.  So: does anyone see
> anything?

  The best strategy to avoid getting blown up is to convince others
to cross the minefield first and then follow the path of the first one
to reach the other side both alive and in possession of all his limbs.
That seems to be your strategy. Don't be surprised at the lack of
volunteers to go first.

  regards,

  Dan.

---

From: David Jacobson <[email-masked]>
Date: Mon, 22 Sep 2014 10:27:06 -0700

> That seems to be your strategy. Don't be surprised at the lack of
My experience from multiple employers is that if there is anything the 
company legal department doesn't want their engineers talking about in a 
public forum, it is the validity and applicability of patents. Don't be 
surprised at lack of responsiveness from people in industry.

--David Jacobson

---

From: Michael Hamburg <[email-masked]>
Date: Mon, 22 Sep 2014 11:25:19 -0700

> On Sep 22, 2014, at 10:27 AM, David Jacobson <[email-masked]> wrote:
> 
>>> Microsoftâ€™s â€˜907 patent applies to their NUMS software, but that

I’m pretty sure that in this analogy I’m the guy crossing first.  I’ve implemented my design, searched for patents covering it, and shared my most interesting finding here.  Meanwhile, most of the other comments on this thread have been about why nobody will help me.

> My experience from multiple employers is that if there is anything the company legal department doesn't want their engineers talking about in a public forum, it is the validity and applicability of patents. Don't be surprised at lack of responsiveness from people in industry.
> 
> --David Jacobson

Yeah, I’m not surprised, just a little disappointed.  This is also why I’m hedging to some degree.  I haven’t said that my code is for sure IPR clean, or that ‘907 is/isn’t valid, or that it does/doesn’t apply to a particular implementation, because I don’t want to get dragged into a patent suit.  I’m just *concerned* that ‘907 may apply to the NUMS ECCLib code, and despite some searching, I’m *not aware* of any patents’ applicability to my code.  Hopefully MS’s formal review of ‘907 will suffice for that particular patent.  But it’d be nice to hear some other *concerns*, or lack thereof, on the dangers of other patents.

Maybe I should be more cautious than this, given that I work for an IP firm.  But it seems a bit backwards for a forum so concerned with IPR issues to actively avoid considering them.

— Mike

---

From: Harry Halpin <[email-masked]>
Date: Mon, 22 Sep 2014 20:37:15 +0200

> I’m pretty sure that in this analogy I’m the guy crossing first.  I’ve implemented my design, searched for patents covering it, and shared my most interesting finding here.  Meanwhile, most of the…

Again, note that "searching for patents" may put one under "willfully
infringing" a patent, which is quite dangerous legally in this space.
Unfortunately, the US patent system is dysfunctional, but we have to
deal with it.

Typically in companies what one does when confronted with a patent troll
is to say that one "didn't search" and thus the infringement was
unintentional, and then search your patents for possible counter-suits,
and then make a deal (including getting the patent troll to call it
off). That's why many people who work for large companies rationally
refuse to search for patents and refuse to say they have searched for
patents on the public record, as it puts them  legally in the "willful
infringement category" if a patent case is brought against them.

I still believe the W3C patent policy combined with the IETF patent
policy should cover patent-related concerns from whatever curve CFRG
choses, and thus patent-related concerns here are likely a red herring
in any decision about recommendations of curves if we actively work with
the legal departments in the standards bodies and get the right
commitments from the larger companies in this space. Which means that
the "patent warchest" over whatever non-NIST ECC curve is chosen would
scare off patent trolls.

I'd like to see some decisions, not emails about patents :)

   cheers,
     harry

---

From: Watson Ladd <[email-masked]>
Date: Mon, 22 Sep 2014 12:06:26 -0700

On Sep 22, 2014 11:38 AM, "Harry Halpin" <[email-masked]> wrote:
> > I’m pretty sure that in this analogy I’m the guy crossing first.  I’ve
implemented my design, searched for patents covering it, and shared my most
interesting finding here.  Meanwhile, most of the other comments on this
thread have been about why nobody will help me.
> the "patent warchest" over whatever non-NIST ECC curve is chosen would

What about non practicing entities?
We're dealing with an extremely limited set of inventions: it should be
possible to establish which patents apply.

So far I've searched and found none. I doubt this is worse than many other
RFCs.

> >>
> >> --David Jacobson
> >
> > Yeah, I’m not surprised, just a little disappointed.  This is also why
I’m hedging to some degree.  I haven’t said that my code is for sure IPR
clean, or that ‘907 is/isn’t valid, or that it does/doesn’t apply to a
particular implementation, because I don’t want to get dragged into a
patent suit.  I’m just *concerned* that ‘907 may apply to the NUMS ECCLib
code, and despite some searching, I’m *not aware* of any patents’
applicability to my code.  Hopefully MS’s formal review of ‘907 will
suffice for that particular patent.  But it’d be nice to hear some other
*concerns*, or lack thereof, on the dangers of other patents.
> >
> > Maybe I should be more cautious than this, given that I work for an IP
firm.  But it seems a bit backwards for a forum so concerned with IPR
issues to actively avoid considering them.