- From: Brian Smith <brian@briansmith.org>
- Date: Fri, 10 Oct 2014 12:06:05 -0700
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Fri, Oct 10, 2014 at 11:55 AM, Martin Thomson <martin.thomson@gmail.com> wrote: >> As you noted, "security level" is assessed differently by different >> organizations. Also, as you noted, 224-bit ECC keys are commonly >> assessed at the 112 bit security level, but you're not really >> intending for 224-bit ECC keys to be acceptable. > > If we intend to permit 25519, then we'll need to permit something > lower than 256. I don't see any reason why permitting ECC keys of 224 > bits is a problem, do you? In current practice, it is not a problem, because (virtually) nobody supports any 224-bit curves anyway. I do think that things should be specified in such a way that Curve25519 would be acceptable. (I overlooked that the Curve25519 key is not considered to be 256 bits long.) My main point is to try to avoid "security level" because that's not a well-defined and well-agreed-upon concept. I don't see why saying "224 bit keys" is better than saying "250 bit keys" or "225-bit keys" unless the intention is specifically to allow 224-bit ECC keys. Cheers, Brian
Received on Friday, 10 October 2014 19:06:32 UTC