Perhaps, and I'm not disagreeing, but for the most part, the crypto
libraries have had ECC support for some time. I'm seeing vendors
beginning to support ECC, and a couple of CAs discussing and preparing
their CPs. Couple all this with the NIST/NSA Suite B recommendation
to go there, it is only a matter of time.
My personal guess is that before the end of this year we will see
major implementations, first as an option. Most will be "vanilla"
implementations staying away from the patented subtopics. In
2009-2010 I expect to see ECC in fairly common use, starting with in
niche applications, the mainstream to follow.
Our challenge as developers is to understand and be ready. My 2 cents.
On Jan 10, 2008, at 4:36 PM, Rodney Thayer wrote:
As far as I'm concerned, ECC isn't a legitimate public key
algorithm for enterprise use at this time because you can't
buy a cert from a CA listed in a major browser where the
cert uses ECC.
Also, those of use who went through the onerous and in the end
counterproductive experience of licensing RSA can tell you that
the "give me money or I'll sue you" business model got old after a
while. I'm not a lawyer but I do have to give CTO-class advice
and, assuming you've found a business case for ECC, I always recommend
people do a build/buy/license/"let them threaten litigation we don't
care" comparison before entering into not-obviously-useful patent
licensing deals. So I recommending paying a lawyer to determine if
you even care about some vendor's alleged patent portfolio.
The fact ECC is in OpenSSL is cute. In the "oh, isn't that cool,
they implement IDEA, RC-6, and ECC" kind of exotic crypto side-show
kind of way. It's not part of "openssl, the open source TLS/SSL
implementation you can use in the real world" any more than any other
non-IE/Firefox-supported TLS ciphersuite combination would be.
I'd be more impressed with the NSA/Certicom deal if I could find any
public evidence there's any PKI anywhere using ECC for a US .gov.
As it
is this just ends up looking like another exotic military purchase not
related to the enterprise world. Show me an HSPD-12 spec that tells
me
I have to use ECC ;-)
Larry Bugbee wrote:
There is no substitute for legal counsel, but Tom had a summary
that you might be interested in...
http://libtom.org/pages/toorcon8_ecc_tstdenis.pdf
See slides 24-27.
Larry
On Jan 10, 2008, at 2:25 PM, Anilkumar Bollineni wrote:
Thanks a lot for the responses.
Bill, I agree with you that the use of ECC is really matters here,
the area where Certicom holds ECC patents. One of our application
with respect to ECC that are planning to use ECDSA (Elliptic Curve
DSA) signature based certificate generation/verification,
signature generation/verification. Meanwhile I talked to one of
the sales guy from Certicom, and he is saying that one of certicom
patents is related to ECDSA and he said if I want to do ECDSA from
OpenSSL, then I need to get license.I am not sure whether that
information is correct or not.
The OpenSSL does not say anyword about the EC/ECDSA usage and its
patents information in Certicom. The only thing I got about that
is that Sun has donated the EC code to OpenSSL.
If OpenSSL users are really violating the Certicom patents then if
users need to be aware of that, then it is better that OpenSSL
tell some information about it in the release notes. Or May be
that OpenSSL EC implementation does not violate any certicom
patents and that's why OpenSSL is not mentioning? Could somebody
has any insight in it?
Thanks again.
Best Regards,
Anil
Bill Colvin <[EMAIL PROTECTED]> wrote:
I would characterize the Certicom patents as falling into 3 main
categories:
1) patents relating to the use of ECC in very specific
application circumstances
This represents the bulk of Certicom patents. For these patents
you will have to do your own research as they are dependent on you
application and have nothing to do with OpenSSL.
2) patents that improve the performance of the underlying
mathematics
For these patents, it would be difficult to say if the developers
who implemented the underlying math algorithms happened to
implement a patented Certicom technique. However, unless they
were actually using the patent docs during implementation, I doubt
that this would be the case.
3) patents on ECC techniques
Now these are the ones you can find in the implementation of
OpenSSL. There are two main ones here – point compression and
MQV. Point compression reduces the size of an ECC public key, but
ECC keys are much smaller than RSA keys even without it, so this
one can be avoided. MQV is a key exchange technique. It also can
be avoided by using ECDH.
NSA licensed 26 Certicom patents (which includes MQV and point
compression) for use in government applications with prime modulus
curves greater than 255. This is a good Q&A on the details of
this license http://www.certicom.ca/download/aid-501/FAQ-The%20NSA%20ECC%20License%20Agreement.pdf
NSA did not license all of Certicom’s patents, only a subset for
use in a limited “field of use”.
Bill
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
] On Behalf Of Anilkumar Bollineni
Sent: January 10, 2008 2:12 PM
To: openssl-users@openssl.org
Subject: About ECC patent and OpenSSL ECC code
Hi there,
I have a question on OpenSSL ECC (Elliptic Curve Cryptography)
code. I saw that Sun systems has donated the the ECCcode to
OpenSSL. Also I saw that Certicom has held 130 patents in ECC area
and finally NSA has licensed that code.
Suppose if I download the code from the OpenSSL and try to develop
a product using the OpenSSL ECC code, does it violate any patent
issue with certicom?
Can anybody share any experience or information about this?
Thanks for support.
-Anil
Never miss a thing. Make Yahoo your homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]