Hello.
That's precisely the issue - how do we make sure it
doesn't assume a patented technology if we don't know
what the patents are?
I think we agree now that there exists patents, so ECC will
not be mandatory part of the standard. But if it's optional
it is not essential to know what is patented and what not -
it would only be nice to know.
If someone comes up with a layout that supports ECC
generically, I'd say go with it.
May I remember that it's exactly what I ask for?
To go with what I submitted?
if someone else does the work and convinces us that it's
generic, I say go for it.
What do you dislike in my proposal? What is not generic enough?
Till mow I've not read any content-specific critics.
That's also why I said to do an informational RFC,
Ok, I can submit my draft also as an informational RFC.
Is it that what you want me to do?
make a sample implementation, let someone hack up GPG to
work with it, and we'll see.
To experiment wit elliptic curves LiDIA (Library for
computational number theory - from the Technische Universitaet
Darmstadt) has all you need. Also P1363 is a good point
to get implementations of most the algorithms needed for
ECC and ECDSA.
I think there are already diverse implementations of ECC
waiting for a standard to interoperate.
What will we see? Clearly its possible to do - so what's
interesting about doing it before we can be sure we can use it?
We indeed _can_ be sure that we can use it - anyone can use it
unless she want to sell it (which may require licencing).
Sorry if my words sound too hard. I don't mind.
I don't worry about the discussion. Quite the opposit, it's
worthwhile. But I would enjoy it very much to have an ECC
standard at last.
Best regards.
--
Dominikus Scherkl
Biodata Application Security AG
mail: Dominikus(_dot_)Scherkl(_at_)Biodata(_dot_)com