11.1 I would like to see "MAY implement curve ID 2" explicitly stated
(this *is* mentioned in section 12, but would like to see it here too)
11.3 says "The best remedy to this .. is to add .. AES-256"
not sure about "best" - perhaps "simplest"? The reason being is
that as AES128 is an ECC must, then this guarantees us *a* Suite
B acceptable cipher, although - as you're trying to get at - having
AES256 means that we'd cover *both* Suite B profiles.
I'm not sure if I agree with the sentiment of "adding .. to .. each
recipient's key" - doesn't quite sound right? (Maybe because it
sounds like sender coercion, rather than a higher-level admin
led policy?)
12 "It is generally advisable to list at the head of the preference list
a symmetric algorithm of strength corresponding to the public key."
Again, I see what you're trying to say, but as is noted elsewhere in
the ECC doc, it's merely the intersection - it's up to the implementation
to make its own decision thereafter (and so take advantage of any
ordering information).
I think section 12 also needs to explicitly deprecate AES-192, saying
that it's not necessarily going to be fielded widely (bring in the fact
that it is only a MAY here might help), isn't one of the Suite B ciphers,
and that it's probably only suitable if for some reason you *really*
need a 192-bit cipher: otherwise go for AES256 for security or -128
for performance.
overall, though, I think we're getting there.
On 3/10/08, Andrey Jivsov <openpgp(_at_)brainhub(_dot_)org> wrote:
Here is the updated revision of the proposal that incorporates most
requested corrections that was possible to make without breaking or
severely affecting interoperability.
http://brainhub.googlepages.com/2008-draft-ietf-openpgp-ecc-pre-7.txt
The same document in other formats:
http://brainhub.googlepages.com/pgp .
Here is the partial list of changes:
1. Make curve ID 1 MUST, ID 3 SHOULD.
2. MUST SHA2-256 and SHOULD implement SHA2-512
3. Note on Suite-B / OpenPGP incompatibility
4. MUST support ECDSA and and ECDH
5. MDC MUST, MUST use Iterated and Salted S2K
6. Note on matching relative strength specified in section 12.
7. Removed open reference to hashes (removed "or its successor").
8. SHOULD use stronger algorithm, while maintaining RFC4880 rules
Thank you again for your comments.