Re: Reasons to include ECC to our charter

[Jon Callas <[e-mail]>]

I'm afraid that I don't see what the hand-wringing is over Certicom and
ECC. In the IETF, we forbid technologies with intellectual property
encumbrances from being *required*, but we don't forbid them from being
optional.

In the real world, any new public key system has an uphill battle to gain
any sort of acceptance. Look at the DSS/EG keys we have now. They were
invented for two reasons: (1) to address security problems in previous key
versions (2) to migrate from encumbered technologies to unencumbered ones.
Yet in some quarters of the user community, OpenPGP is looked on as if it
were fluoridation, for any number of reasons, none of which are really
relevant to this discussion. What *is* relevant is that if we put the ECC
parameters in OpenPGP, they probably won't be widely adopted, intellectual
property or not. So why not put them in, since they don't hurt anyone else?

Also as a real-world consideration, there's no need for any desktop or
laptop user to use ECC. Do I care if ECC means that a decrypt happens ten
times faster? Nope. The decrypt right now is happening in the blink of an
eye (like 50ms) or two. I'm not going to notice it taking place in a tenth
of an eye-blink. The delays I see in encrypted email are all related to UI
and layers and disk accesses and groveling through databases to *find* the
darned key. I might notice an improvement if I'm encrypting a message to a
dozen or more people, but maybe not. The size savings is utterly laughable.

ECC will matter only on constrained devices. If you want to make a OpenPGP
secured pager or SMS cell phone, then we're starting to see a reason for
ECC. Why not let these people do it interoperably?

I can understand some people's concern that the ECC proponents aren't
pushing things. But they did. About three years ago, some Certicom guys
made a presentation at an IETF meeting (Chicago?) and were basically pelted
with tomatoes and hooted out of the room. It was pretty embarrassing. If I
worked for Certicom, my reaction to this working group would be, "When you
want to talk rationally, email me."

We aren't going to make ECC a MUST or even a SHOULD. We will try very hard
to make the formats for ECC not favor anyone's implementation. We all know
that. So why don't we encourage some ECC experts to write an informational
RFC, do some interoperability testing, and make sure that it doesn't assume
a patented technology? And then if we like it, we can put it in a future
draft, or a follow-on document? We already have reserved PK algorithm
numbers for ECC and ECDSA.

	Jon