ECC in OpenPGP proposal

Hello OpenPGP list,

as Hal Finney had mentioned earlier, here is the draft:
   http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-6.txt

Unless you read this on a text terminal, here is the document in 
alternative formats that offer cross-references as navigation links:
   http://brainhub.googlepages.com/pgp

This submissions considers comments of the group to earlier Elliptic 
curve Cryptography (ECC) draft submissions. A couple of issues that were 
raised then are the justification for ECC in OpenPGP and how the larger 
set of ECC parameters can be managed.
Why do we need ECC? The main reason is better alignment with the 
strength of symmetric key. Given that US government has chosen ECC in 
favor of modp for larger key sizes, this proposal is carefully written 
to comply with NSA Suite-B. Informally, this is a proposal for these who 
are concerned that the use of SHA2-512 and AES-256 will need something 
stronger that RSA 1024. By optimistic estimates users should use at 
least RSA 4096 with AES 256, while it is a common assumption that RSA 
8192 is more appropriate. In practice, many sites today are not able to 
use RSA keys of sizes greater than 4096. ECC offers alternatives to 
larger modp key sizes. Another advantage of ECC is an opportunity to 
expand the set of hardware on which OpenPGP can be implemented. The 
security of AES-128 with corresponding ECC public key may be more 
attractive for "weak" devices, as opposed to RSA public keys, especially 
because the ECC curves introduced by this standard are already supported 
by TLS, IKE, PKIX, and SSH. Any system that communicates over slow 
medium will benefit from smaller keys and ESKs as well.
This paragraph describes the direction chosen by the proposal in 
reference to the issue of magnitude of ECC parameters and options. One 
possible approach an ECC standard can take is to define all possible 
formats in one RFC, a "toolbox" approach. One can argue that smartcard 
devices may prefer ECC in binary fields, while software implementations 
would like to work in generalized Mersenne prime fields. Another group 
of OpenPGP applications may wish to generate its own random curves as 
part of a protocol, and so on. While it may be possible to create such a 
broad standard that will make each concerned implementer happy, it 
creates more interoperability issues. This puts burden on an 
implementation that wants to support every type of ECC key. The 
performance and security issues associated with generation and 
verification of random ECC curves creates new order of complexity. It 
seems to me that in the short run there are two likely outcomes 
resulting from implementing a "toolbox" approach. In the first one, 
there will be no interoperability between different OpenPGP 
implementations. The second possibility is that there will be a core set 
of parameters that will be implemented by everybody who claims ECC 
support. This second possibility is probably wishful thinking. Consider 
the fact that in OpenPGP there is no method to advertise public key 
support, yet alone, a method to advertise a nuance of public key 
support. For example, what an application should use for a top key, so 
that self-signatures and certifications by this key are broadly 
understood? It is rare to see SHA2-512 used for these signatures. I 
think the following approach will help speed up adoption of the 
standard: we define core set of ECC parameters and make them MUST. This 
will be lowest common denominator of all possible ECC configurations 
(within the acceptable security strength). This will not be the optimal 
field for every application, yet, it will be good compromise to achieve 
faster adoption. Future advances in computing will drive the upgrade of 
the core set, but by then there will be a path by which ECC-capable 
applications can transition to other formats. The draft doesn't preclude 
the existence of companion proposals that define ECC in other fields, 
moreover, the draft provides a framework for these extensions.
Finally, only patent-free techniques were chosen for this proposal. The 
requirement to be in unencumbered field further reduced the acceptable 
ECC methods.
To summarize, this document offers narrow core set of functionality and 
focuses on matching AES strength and on Suite-B support. There are lots 
of MUSTs, very few SHOULDs in the interest of interoperability and 
patent clarity.
I would appreciate if the group reviews the document. Thank you.