Subject: [pkix] IPR status for ECDH and ECDSA

From: Anders Rundgren <[email-masked]>
Date: Sat, 07 Aug 2010 10:58:12 +0200

I'm plotting with a smart card concept where ECC is a corner-stone
with NIST's SP800-56A C(2, 0, ECC CDH) algorithm as a prerequisite
for creating a shared session-key using two  ephemeral keys.

Although RIM/Certicom presumable offers RAND terms it is pretty hard
to know what that means in practice and even how it is supposed to be
controlled since the concept is based on Open Hardware and Open Software
which means that production could happen anywhere, like in China.

Is my assumption correct that ECDSA and ECDH are IPR-free but that
some implementations are not?  Is it known if OpenSSL's or BouncyCastle's
implementations violate RIM/Certiticom IPR?  I would be nice if they
don't since the design heavily builds on their work as well.

Anders

---

From: "Todd E. Johnson" <[email-masked]>
Date: Sun, 08 Aug 2010 10:04:49 -0400

Hi Anders,

I am highly interested in a response on this as well.

For example, there is a document at secg.org by Certicom which provides 
some coverage of Certicom patents (although a bit dated):

http://www.secg.org/download/aid-398/certicom_patent_letter_SECG.pdf

Which seem it was compelled by the SECG Patent Policy:

http://www.secg.org/index.php?action=secg,about_patents

Funny thing is, I am generally unaware of any implementations based on 
SECG standards, yet I am certainly no authority in this field...

On 08/07/2010 04:58 AM, Anders Rundgren wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

-- 

Regards,

Todd E. Johnson

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 08 Aug 2010 19:26:55 +0200

Thank for the pointers Todd!

My hope (and uneducated guess) is that

        http://en.wikipedia.org/wiki/Moore's_law

effectively vaporizes RIM/Certicom IPR which is very much
based on realizing public key cryptography in computationally
weak devices.

A state-of-the-art 100 Mhz 32-bit ARM device with 64K RAM and
256K ROM should be able to use less-than-optimal algorithms.

Anyway, it would be awfully nice to get some truly authoritative
input on this matter although I understand that in the end the
validity of patents and violations is primarily a legal issue.
IANAL. The deeper your pockets are, the better it gets :-)

Associated question: if you put NIST suite B in standard electronics
devices like USB memory sticks, will you violate the Wassenaar
agreements in spite of the fact that anybody can build such devices?

Anders

---

From: Michael StJohns <[email-masked]>
Date: Sun, 08 Aug 2010 14:31:16 -0400

A completely lay opinion with no legal basis.

Stay away from point compression, binary (F2m) curves and ECMQV and you've probably avoided most mine fields.  

With respect to the smart card implementation - the IPR of the smart card is basically not your problem - you have to ask the card provider what they've done in the space and whether or not they'll indemnify you and from what I can tell, most will.  Either because they bought a license from Certicom or because their lawyers have done the IPR analysis.

With respect to OpenSSL and BouncyCastle - well, there's sort of this principle in law called laches which says that failure to assert your rights in patents in a timely manner tends to void your ability to claim infringement or to enforce a claim of infringement.  I note without further comment that both OpenSSl and BouncyCastle have had EC suites for quite a while and that the OpenSSL EC was built by Sun in a manner intended to be non-infringing.  

Mike

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 09 Aug 2010 16:04:08 +1200

Michael StJohns <[email-masked]> writes:

>With respect to OpenSSL and BouncyCastle - well, there's sort of this
>principle in law called laches which says that failure to assert your rights
>in patents in a timely manner tends to void your ability to claim
>infringement or to enforce a claim of infringement.

Does this actually work in practice though?  I'm thinking of things like
Unisys and the GIF (well, LZW) patent.

Peter.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 9 Aug 2010 10:26:18 -0400

NIST's inclusion of algorithms in any document should not be taken to imply that these algorithms are unencumbered by intellectual property.  NIST and the US Federal Government are under no onus to use public domain specifications.

In fact, the US Federal government has a no-fee license from Certicom for a whole portfolio of ECC-related patents, but that license applies only to implementations intended *solely* for use with the government.

-- Tim

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Anders Rundgren
>Sent: Sunday, August 08, 2010 12:27 PM
>To: Todd E. Johnson
>Cc: [email-masked]
>Subject: Re: [pkix] IPR status for ECDH and ECDSA
>

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 9 Aug 2010 10:28:47 -0400

IIRC, a failure to enforce resulting in the forfeiture of IP rights only applies to trademarks, service marks, and trade secrets (under US law).  But since IANAL either, this probably is wrong.  :)

-- Tim

>Michael StJohns
>Sent: Sunday, August 08, 2010 1:31 PM
>To: Anders Rundgren; Todd E. Johnson
>Cc: [email-masked]
>Stay away from point compression, binary (F2m) curves and ECMQV and
>you've probably avoided most mine fields.
>
>With respect to the smart card implementation - the IPR of the smart
>card is basically not your problem - you have to ask the card provider
>what they've done in the space and whether or not they'll indemnify you
>and from what I can tell, most will.  Either because they bought a
>license from Certicom or because their lawyers have done the IPR
>analysis.
>
>principle in law called laches which says that failure to assert your
>rights in patents in a timely manner tends to void your ability to claim
>infringement or to enforce a claim of infringement.  I note without
>further comment that both OpenSSl and BouncyCastle have had EC suites
>for quite a while and that the OpenSSL EC was built by Sun in a manner
>intended to be non-infringing.
>
>Mike
>
>
>

---

From: Michael StJohns <[email-masked]>
Date: Mon, 09 Aug 2010 11:22:35 -0400

>In fact, the US Federal government has a no-fee license from Certicom for a whole portfolio of ECC-related patents, but that license applies only to implementations intended *solely* for use with th…

Actually, NSA can sublicense the Certicom stuff. So it's not solely for use within the US government. (Hmm... looking at the web site, I think some of this language has changed since I looked at it a year or so ago - specifically, "infrastructure protection" seems to have fallen off the page).

But that's not really the point - the question is whether or not the Certicom patents encumber the open source implementations or would encumber a clean room implementation done to certain pre-1994 math approaches (e.g. David McGrew's paper).

Mike

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 17 Aug 2010 17:08:50 +0200

Michael StJohns wrote:
> whether or not the Certicom patents encumber the open source
> implementations or

OpenSSL undertook some serious efforts to avoid the Certicom patents.
I think NSS did the same.

> would encumber a clean room implementation done to
> certain pre-1994 math approaches (e.g. David McGrew's paper).

As noted in the "9. Intellectual Property" section of 
draft-mcgrew-fundamental-ecc-03.txt, all the references used for ECDH 
were published during or before 1989, and those for Type I KT signatures 
were published during or before May, 1994.

Certicom claimed during IESG last call that an implementation based on 
this document could infringe US6704870, granted in 2004, filed in Aug 
2001 and US7215773, granted in 2007, filed in Oct 1998, see 
https://datatracker.ietf.org/ipr/1337/

 From what I read, US6704870 is about a smart way to split the ECC 
workload between the smart card and the card reader without getting out 
the private key, and US7215773 about a step of verifying if the public 
key is a cryptographically valid/secure key when verifying a signature 
or granting a certificate.

So on the whole, Certicom's IPR confirms an approach based on 
draft-mcgrew-fundamental-ecc-03.txt can be used to implement ECC without 
infringing it's IP.

On a side note, whilst US7215773 is not really needed to implement ECC, 
it would be nice to start searching for prior art which seems obvious to 
exist somewhere.