[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reasons to include ECC to our charter
Dominikus Scherkl wrote:
>
> Dear openPGP Working Group,
>
> Sorry, that I supposed my suggestions for an ECC-extension
> to the openPGP message format to be property of this WG while
> it is only a personal draft.
>
> Now for my reasons, why this WG should include
> <draft-scherkl-openpgp-ecc-00.txt> to its charter:
>
> I think it is time to fulfill the promise this WG made by
> reserving space for ECC and ECDSA, if we want to keep this
> standard as wide used as it is.
>
> Long time has gone since we reserved IDs for ECC algorithms
> and many applications now support ECC but can't provide it in
> an openPGP context. So they uses other standards like S/MIME
> or proprietary protocols to provide these algorithms to those
> who want to enjoy their advantages.
>
> Different sets of ECC parameters have now been tested long
> enough to outsource all trivialy (and many not so trivial)
> cases that won't provide sufficient security, so ECC becomes
> a "well known" algortithm.
> In this light the somewhat slightly advantages "short keys"
> and "high performance" gain weight due to the lack of
> disadvantages.
>
> Therefore I'm convinced we can include it in the standard
> without high probability to compromise our security goals.
>
> The attached draft is thought to be fully conform with the
> openPGP format and even some other standards, and it defines
> all elliptic curves so that no greater changes in the
> future are expected (it keeps no further gaps in the ECC
> definiton as some older suggestions have done).
> If it isn't, I'm sure we can make it with small efford.
>
> At all, the openPGP standard can only gain by adding this
> draft to the charter.
You can't add it to the _standard_ because of restrictive licensing. I
guess Informational RFCs are possible, but they don't make me happy -
essentially the WG is doing free work, both technical and marketing, for
the owner(s) of the patents.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html