Re: [Cfrg] IPR and algorithms (was Re: Results of the poll: Elliptic Curves - preferred curves around 256bit work factor (ends on March 3rd))

[Harry Halpin <[e-mail]>]

On 03/06/2015 03:59 AM, Watson Ladd wrote:
> On Mar 5, 2015 3:55 PM, "Benjamin Black" <[e-mail]> wrote:
>>
>> As you say, it would be equally a problem for every curve, which was my argument repeatedly rejected by Alyssa and Robert. As they have never made a statement, public or private, of which I am aware withdrawing their assertions, I can only assume they still believe what they said. If they would like to pipe up and explain that they no longer hold those views that'd be swell.
> 
> The above ignores the substantial differences between original NUMS
> and the proposals made last fall, and between curves and algorithms.
> The original NUMS presentation placed a great deal of importance on
> the specific algorithms discussed, and it was very clear that these
> algorithms were the ones that the NUMS group wanted specified.
> 
> It's a moot point when deciding : there are plenty of comb variations
> that are not patented. But were we to have turned the NUMS proposal
> into an RFC containing the algorithms presented, it would have been a
> problem. I really don't see why we're wasting words on this debate:
> Ed448 won out for other reason.

Although I am not a lawyer, I think possible patents are an issue that
can be solved and should not prevent CFRG from making the *technically*
correct choice.

As stated before, *if* CFRG clearly recommends elliptic curves to IETF
TLS and W3C WebCrypto, the W3C WebCrypto WG will specify in either the
body of the main W3C WebCrypto Recommendation or (depending on timing of
CFRG recommendation) in other Recommendation-track drafts the curves
once the implementers decide they are mature.

Given patent agreements already exist from Microsoft, IBM, and many
other large companies in the W3C, we would believe that any patents on
the particular implementations of these curves would be available under
a W3C royalty-free license, and any challenges by patent trolls would
have to cope with W3C's patent policy.

    cheers,
       harry
> 
> Sincerely,
> Watson Ladd
> 
>>
>> I cannot comment on Microsoft as I am no longer there.
>>
>>
>> On Thu, Mar 5, 2015 at 3:41 PM, Michael Hamburg <[e-mail]> wrote:
>>>
>>> Hi Benjamin,
>>>
>>> Robert Ransom was concerned about Microsoft’s paper and code release possibly containing material based on the patent US7602907.  This wasn’t particularly to do with the curve, but with the combs algorithm for fast fixed-point multiplications.  If this is a problem with any curve, it’s equally a problem for (implementations of) every curve.  I believe that Robert was motivated in this pursuit by a deep-seated conviction that Microsoft was trying to pull something shady, but Alyssa and I just want to make sure that the patent landscape is clear so that nobody infringes by accident.
>>>
>>> Since my code uses signed all-bits set combs, and if I understand correctly your patent specifically covers modified LSB-set combs, I don’t believe that my implementation has patent problems.  Again, this is a property of the implementation and not of the curve.
>>>
>>> I asked if you and/or the Microsoft legal team concurred with this analysis.  You said that your team was unaware of the patent and didn’t use it intentionally, but that you would ask legal if it happened to be covered, and whether they thought the Goldilocks code might be affected.  Nearly 6 months have passed and we haven’t heard anything from legal.  Do you have an update for us?
>>>
>>> Cheers,
>>> — Mike
>>>
>>>> On Mar 5, 2015, at 3:22 PM, Benjamin Black <[e-mail]> wrote:
>>>>
>>>> What happened to the earlier, vigorous arguments by Robert Ransom, Alyssa Rowan and Mike Hamburg that Goldilocks448, and perhaps all of the curves based on large primes, would be covered by Microsoft IP?
>>>>
>>>> On Thu, Mar 5, 2015 at 3:11 PM, Alexey Melnikov <[e-mail]> wrote:
>>>>>
>>>>> On 25/02/2015 14:27, Alexey Melnikov wrote:
>>>>>>
>>>>>> CFRG chairs are starting another poll:
>>>>>>
>>>>>> Q3: This is a Quaker poll (please answer one of "preferred", "acceptable" or "no") for each curve specified below:
>>>>>>
>>>>>> 1) 448 (Goldilocks)
>>>>>> 2) 480
>>>>>> 3) 521
>>>>>> 4) other curve (please name another curve that you "prefer" or "accept", or state "no")
>>>>>
>>>>> Thank you for all responses.
>>>>>
>>>>> 521 - 6 preferred, 14 - acceptable
>>>>> 448 - 16 preferred, 4 - acceptable
>>>>>
>>>>> Very few prefer others (512 NUMS, 480).
>>>>>
>>>>> So CFRG prefers curve 448.
>>>>>>
>>>>>>
>>>>>> If you stated your curve preferences in the poll that ended on February 23rd (see the attachment), you don't need to reply to this poll, your opinion is already recorded. But please double check what chairs recorded (see the attachment).
>>>>>>
>>>>>> If you changed your mind or only answered the question about performance versa memory usage for curves 512 and 521, feel free to reply.
>>>>>>
>>>>>> Once this issues is settled, we will be discussing (in no particular order. Chairs reserve the right to add additional questions) implementation specifics and coordinate systems for Diffie-Hellman. We will then make decisions on signature schemes. Please don't discuss any of these future topics at this time.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Cfrg mailing list
>>>>> [e-mail]
>>>>> http://www.irtf.org/mailman/listinfo/cfrg
>>>>
>>>>
>>>> _______________________________________________
>>>> Cfrg mailing list
>>>> [e-mail]
>>>> http://www.irtf.org/mailman/listinfo/cfrg
>>>
>>>
>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]
>> http://www.irtf.org/mailman/listinfo/cfrg
>>
> 
> As you say, it would be equally a problem for every curve, which was
> my argument repeatedly rejected by Alyssa and Robert. As they have
> never made a statement, public or private, of which I am aware
> withdrawing their assertions, I can only assume they still believe
> what they said. If they would like to pipe up and explain that they no
> longer hold those views that'd be swell.
> 
> I cannot comment on Microsoft as I am no longer there.
> 
> As you say, it would be equally a problem for every curve, which was
> my argument repeatedly rejected by Alyssa and Robert. As they have
> never made a statement, public or private, of which I am aware
> withdrawing their assertions, I can only assume they still believe
> what they said. If they would like to pipe up and explain that they no
> longer hold those views that'd be swell.
> 
> I cannot comment on Microsoft as I am no longer there.
> 
> 
> On Thu, Mar 5, 2015 at 3:41 PM, Michael Hamburg <[e-mail]> wrote:
>>
>> Hi Benjamin,
>>
>> Robert Ransom was concerned about Microsoft’s paper and code release possibly containing material based on the patent US7602907.  This wasn’t particularly to do with the curve, but with the combs algorithm for fast fixed-point multiplications.  If this is a problem with any curve, it’s equally a problem for (implementations of) every curve.  I believe that Robert was motivated in this pursuit by a deep-seated conviction that Microsoft was trying to pull something shady, but Alyssa and I just want to make sure that the patent landscape is clear so that nobody infringes by accident.
>>
>> Since my code uses signed all-bits set combs, and if I understand correctly your patent specifically covers modified LSB-set combs, I don’t believe that my implementation has patent problems.  Again, this is a property of the implementation and not of the curve.
>>
>> I asked if you and/or the Microsoft legal team concurred with this analysis.  You said that your team was unaware of the patent and didn’t use it intentionally, but that you would ask legal if it happened to be covered, and whether they thought the Goldilocks code might be affected.  Nearly 6 months have passed and we haven’t heard anything from legal.  Do you have an update for us?
>>
>> Cheers,
>> — Mike
>>
>> On Mar 5, 2015, at 3:22 PM, Benjamin Black <[e-mail]> wrote:
>>
>> What happened to the earlier, vigorous arguments by Robert Ransom, Alyssa Rowan and Mike Hamburg that Goldilocks448, and perhaps all of the curves based on large primes, would be covered by Microsoft IP?
>>
>> On Thu, Mar 5, 2015 at 3:11 PM, Alexey Melnikov <[e-mail]> wrote:
>>>
>>> On 25/02/2015 14:27, Alexey Melnikov wrote:
>>>>
>>>> CFRG chairs are starting another poll:
>>>>
>>>> Q3: This is a Quaker poll (please answer one of "preferred", "acceptable" or "no") for each curve specified below:
>>>>
>>>> 1) 448 (Goldilocks)
>>>> 2) 480
>>>> 3) 521
>>>> 4) other curve (please name another curve that you "prefer" or "accept", or state "no")
>>>
>>> Thank you for all responses.
>>>
>>> 521 - 6 preferred, 14 - acceptable
>>> 448 - 16 preferred, 4 - acceptable
>>>
>>> Very few prefer others (512 NUMS, 480).
>>>
>>> So CFRG prefers curve 448.
>>>>
>>>>
>>>> If you stated your curve preferences in the poll that ended on February 23rd (see the attachment), you don't need to reply to this poll, your opinion is already recorded. But please double check what chairs recorded (see the attachment).
>>>>
>>>> If you changed your mind or only answered the question about performance versa memory usage for curves 512 and 521, feel free to reply.
>>>>
>>>> Once this issues is settled, we will be discussing (in no particular order. Chairs reserve the right to add additional questions) implementation specifics and coordinate systems for Diffie-Hellman. We will then make decisions on signature schemes. Please don't discuss any of these future topics at this time.
>>>
>>>
>>> _______________________________________________
>>> Cfrg mailing list
>>> [e-mail]
>>> http://www.irtf.org/mailman/listinfo/cfrg
>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]
>> http://www.irtf.org/mailman/listinfo/cfrg
>>
>>
> 
> 
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg
> 
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg
>