Subject: RE: Comments on ECC draft

From: "Dominikus Scherkl" <[email-masked]>
Date: Tue, 24 Sep 2002 09:46:28 +0200

> I'd like to bring this up again before the next revision of 
> the draft. How close are we to consensus on the ECC semantics?

Really?
Indeed I thought there isn't anybody interessted in this...
what a very positive surprise.

> On Wed, 5 Sep 2001 [email-masked] wrote:
> 
> > We have been looking at the ECC issue and have a few comments on the
> > proposed draft by Dominikus Scherkl and Christoph Fausak.
> >
> > Broadly speaking it looks very good.

As the IEEE has changed it's proposed standard P1363 to allow
for an additionaly point-compression method with no patents
on it (I worked hardly on this), we should have no problem
with this topic.
But I don't know about the current status of other pending
patents.

I will soon submit an updated version of my (long ago expired)
draft soon...

> I'm not against ECC in OpenPGP, but given how close 2440bis is to last
> call, perhaps the ECC specification could go in a companion RFC?
This way is what I intended with my draft.
And I think there's no need to hurry, too, but

> > OpenSSL now has ECC in it, and there is an ECC in TLS draft 
> > being proposed
> That's not certain yet, [and the TLS draft is]
> ... by the same group who did the OpenSSL implementation.

do we realy need to be the last to add ECC to our standard ?

-- 
Dominikus Scherkl
[email-masked]

---

From: "Dominikus Scherkl" <[email-masked]>
Date: Tue, 24 Sep 2002 12:35:05 +0200

Hello.

Really?

> > We have been looking at the ECC issue and have a few 
> > comments on the proposed draft by Dominikus Scherkl and
> > Christoph Fausak.
> >

As the IEEE has changed it's proposed standard P1363 to allow
for an additionaly point-compression method with no patents
on it (I worked hardly on this), we should have no problem
with this topic.
But I don't know about the current status of other pending
patents. (Looking at Annex G of IEEE P1363a/D10.8 may be a good
idea, but most of the patents mentioned there cover other parts
of that proposed standard).

> I'm not against ECC in OpenPGP, but given how close 2440bis 
> is to last call, perhaps the ECC specification could go in a
> companion RFC?

Best regards,

---

From: "Dominikus Scherkl" <[email-masked]>
Date: Wed, 25 Sep 2002 10:19:31 +0200

> Obviously, people's animosity for Certicom is going to
> get in the way of cleanly standardizing this.

> But, as long as ECC remains undefined in RFC2440bis
> and its successor, I wouldn't consider an implementation
> of ECC in OpenPGP to be violating the standard.

Of course not. That's why we insist for its addition
to the standard.

> If you're planning on putting it in CryptoEx,
> I'll be happy to make sure we interoperate with you.
We won't until it's part of the standard.
We've fully implemented all the mathematics, but integrating
it now will be about the same efford as to change it
after a different protocol is suddenly part of RFC 2440.

> I do agree, though, that your draft should pick a
> curve and stick with it, so that all the OpenPGP-ECC
> implementations are interoperable.

I don't think a single curve would be enough, because
it may have undiscovered weaknesses - and the curves
mentioned in my draft are already in use with other
standards, so I think it's a minimum requirement for
an implementation to support these.

But I agree that adding more curves should not be allowed
to everyone - new curves should be added to the standard
if they become nessessary (and that will be done VERY seldom).

to the draft:
Should I reduce my comments to domain parameters to
those nessessary to understand the format in which the
required curves are encoded? Or may I omit them at all?

By the way: I'm somewhat concerned about my mail to you
still not appeared on the list (and got no error report).
Is there something I must do before my mails are accepted?!?