James Donald wrote:
Date: Wed, 04 Jul 2007 09:19:41 +1000
From: "James A. Donald" <[EMAIL PROTECTED]>
Subject: Re: [FDE] Introductions
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=UTF-8; format=flowed
 
I was under the impression that the use of ECC was obstructed by
multiple extremely broad overlapping patents, each patenting much the
same thing,

James:

This is another myth (possibly perpetuated by Certicom). ISC has had ECC (more
precisely, ECDH and ECDSA) in its commercial products for more than 10 years
now. (It's been around so long I can't remember when we first implemented it,
but it pre-dates by several years the announcement of the Certicom toolkit in
1997. And, unlike the situation for RSA, we have not been sued for it yet!)

We do NIST/NSA Suite B/ANSI/IEEE/IETF-compliant ECC key generation, key wrapping,
key agreement, and signatures for CMS, TLS, in our CA, etc. -- freely in char p,
but only with polynomial bases in char 2.

Whether Certicom's point compression patent would stand up to a challenge is
questionable -- some feel there's plenty of implicit and explicit prior art --
but it should be noted that the big boys (Microsoft, et al.) have chosen to avoid
it... something that's easy to do and still comply with the standards.

But that and the avoidance of (optimal) normal bases in char 2 are pretty much
the only things a *software* implementation needs to do to steer clear of the
patents.

There are *no* patents I'm aware of that are required to fully comply with the
above mentioned standards and interoperate with the leading commercial products!
[Usual caveat: I'm not a lawyer, so my response should be taken cum granis salis.]

but that if the NSA licenses you, your ass is covered. 

*Our* NSA license defines a rather specific "field of use;" their license with
other companies may vary. (It was pretty clear when we negotiated our license that
they did not have a fixed contracting procedure in place and we weren't the first
company to go through the process.) For more info, you might start here:
http://www.nsa.gov/ia/industry/crypto_suite_b.cfm

As one might expect, Certicom's spin on the deal is somewhat different (and it's
not at all clear that NSA knows exactly what it paid $25M for):
http://www.certicom.com/download/aid-501/FAQ-The%20NSA%20ECC%20License%20Agreement.pdf

Final determination might come down in the courts, but I'm not aware of lawsuits
yet.

But  for non government uses, NSA is presumably not going to license you, and
  cutting a deal with patent holders is going to be too arduous for any
organization that does not have a menacing team of lawyers in house.

NSA gives you a license to build, sell, and use products including the IP in
question -- 26 US and Canadian patents are cited -- in char p with p at least 256
bits in length to Federal, state, and local government agencies (and to foreign
governments under certain circumstances) for the protection of classified data
or national security purposes. (Here I'm summarizing the clearer parts of an MOU
some of which is vague and subject to various interpretations.)

However, it's worth keeping in mind that you really only need such a license for
MQV/ECMQV, and that's easily avoided by substituting (unencumbered) DH/ECDH.
(Note that all relevant "standards" -- including Suite B -- permit the use of either
scheme for key agreement.)

What is the patent and licensing situation with that product?  Did NSA
license you to sell it to anyone?

For the moment, we only offer our products with ECMQV to DoD agencies wishing to
use them for "national security" purposes -- you might say we're playing it safe.
(Not to mention the fact that, outside of DoD, no one has ever asked us for
MQV! You certainly don't need it to do TLS as you'd have no one to talk to if
you did. See link below.)

Bob Jueneman responded:
I’m not an attorney, but it may be worth observing that Microsoft includes ECC support within Vista, and Sun, Red Hat, and others have announced plans to support ECC as well. 

See http://dev.experimentalstuff.com:8082/ for the current situation regarding
ECC in TLS. (To the best of my knowledge, aside from Certicom, these companies
do not feel that any ECC license is required.)

SPYRUS products are unencumbered with license restrictions, and can be exported and used worldwide.

Ditto for (most) commercial ISC products, subject only to BIS export restrictions.
http://www.infoseccorp.com/products/contents.htm#Export

-mjm
_______________________________________________
FDE mailing list
[email protected]
http://www.xml-dev.com/mailman/listinfo/fde

Reply via email to