Paul Lambert says:
So I doubt that open-pgp will be able to include ECC.
If open-pgp contains RSA why can't it contain ECC?
Because today it is possible to have a free and legal
implementation of RSA. But it is not possible to have
a free and legal implementation of ECC.
Several people and companies have various patents, the
rumor is that even some CURVES have been patented - so
how would you suggest the implementors of free
software to deal with it? In my view the
simplest is to just leave that mirky
thing alone.
ECC is an option in open-pgp and not mandatory. It is a very useful option
that should have equal status to other patented algorithms.
I don't argue the usefulness of ECC - only its [in]availability for
the free code developers.
Certicom has
very reasonable licensing terms (as compared to other un-named companies
with three letter acronyms in their names).
Here we are not talking about commercial licensing.
Certicom would issue a
non-commercial use license for ECC in open-pgp that would allow broad
"personal use" by the open-pgp community.
That would be THE way. How close is Certicom to actually formulating
the non-commercial Personal Use Only license?
Oh, and is it true that there are other (non-Certicom) patents (such as
on the individual curves themselves etc.) that may require licensing
and thus may affect the free software developers? I assume that
Certicom might be aware of what parts of the field are
covered, and if so - might be nice enough to share
that info?
Certicom would charge for
business use of ECC in open-pgp at our very low rates (we have to find some
way to hordes of Ph.D. mathematicians in our research labs).
Of course. Nobody objects to that.
In reviewing the specification, it does appear that some additional details
would be useful to better define ECC in open-pgp. I will try to get some
of our cryptographers to submit some algorithm and parameter related text.
Cool. Thanks for the good news!
--
Regards,
Uri uri(_at_)watson(_dot_)ibm(_dot_)com
-=-=-=-=-=-=-
<Disclaimer>