Subject: AW: Reasons to include ECC to our charter

From: "Dominikus Scherkl" <[email-masked]>
Date: Wed, 15 Aug 2001 15:33:24 +0200

Hi.

> > IIRC, not all ECC stuff is patented, only curves over GF(q), q even,
> > which can be implemented efficiently using two-valued logic.
> 
> As I read it, this I-D includes these.
But it also includes Curves over GF(q), q prime or a power of some
odd prime. I wouldn't appreciate it much to exclude some stuff,
now that we have a definition including simply every finite field.
But my suggestion doesn't require an application to use binary
fields, and other curves are also given (and own for which noone
could claim any rights could be generated), so licence problems are
easy to avoid.

As I already mentioned to some people, I think it is the main topic
for an internet standard to enhance interoperability. So im still
convinced it is a good idea to provide a common way to store data
for ECC algorithms even if a particular implementation decide not to
use ECC (or not all suggested curves) for licence reasons.

I see the point that we shouldn't do the work for those who claimed
rights that should not be granted to anyone (like patenting a number).

But 1. most of the work is done, 2. a patent won't last forever and
if a standard is available before it's most likely that future
applications will conform to it.
-- 
Dominikus Scherkl
Biodata Application Security AG
mail: [email-masked]

---

From: John W Noerenberg II <[email-masked]>
Date: Sat, 18 Aug 2001 09:18:54 -0700

>now that we have a definition including simply every finite field.

I agree with Dominkus on this point.  As long as what he has defined 
gives a means for any ECC curve deemed useful, I believe that 
finesses the IPR issues raised by Certicom's patents.

However, At 1:42 AM +1200 8/11/01, Peter Gutmann wrote:
>The rule of thumb for ECC is something like "ECC curves are divided into three
>groups, weak curves, inefficient curves, and curves patented by Certicom".

If Peter is accurate, then Certicom's IPR poses a significant 
obstacle to ECC utility.  Do others wish to comment on this?

It may be possible to pursue an agreement along the lines of RFC1790. 
Certicom would have to be agreeable, and  we would have to persuade 
the IETF as a whole such an agreement is in the IETF's interest.  To 
my knowledge, the RFCs covered by agreement documented in 1790 did 
not achieve STD status, but that doesn't mean we would not succeed. 
It is still a useful model.

Assuming we do proceed, it would be appropriate to be warn people 
about classes of curves which are either inefficient to compute, or 
may require licensing from a third party.  Both considerations limit 
utility of some ECC designs.

However, I would like to see more analysis of ECC curves (not to 
slight Peter's assessment), before I consider this matter resolved. 
Further, if someone could point me towards the appropriate person at 
Certicom to discuss the 1790 approach, please do so.

best,
-- 

john noerenberg
[email-masked]
   --------------------------------------------------------------------------
   Peace of mind isn't at all superficial, really.  It's the whole thing.
   That which produces it is good maintenance; that which disturbs it
   is poor maintenance.
   -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974
   --------------------------------------------------------------------------