Eric Rescorla <[email protected]> wrote: > TBH, I'm not a fan of SHOULD+, etc., and they're pretty alien to TLS, so > you should just use words if you want to convey these points.
> With that said, I don't really understand the objective here: we're
> generally moving towards the CFRG curves, so what's the reasoning for the
> P256 MUST and why do you think that will change.
Because current generation of hardware and TPM modules has definite support
for P256, and while some of the hardware assist out there can accelerate CFRG
curves as well or better:
a) it's not universally true.
b) it takes time to get the new code through a FIPS process.
So, we want to say, P256 is if you must, and CFRG if you can on the
constrained device.
On a non-constrained CA side, P256 becomes a MUST because one needs to
support the old devices, and CFRG becomes a MUST just as soon as one
can get the code through the right processes.
In any case, 7925 says EXACTLY this, so we are happy, and do not want to
repeat things.
> wrote:
>>
>> Hannes Tschofenig <[email protected]> wrote:
>> > why don't you just reference https://tools.ietf.org/html/rfc7925?
>>
>> Ignorance :-)
>> Thank you, I think that we will reference it then;
>>
>> Section 4.4 includes:
>>
>> At the time of writing, the
>> recommended curve is secp256r1, and the use of uncompressed points
>> follows the recommendation in CoAP. Note that standardization for
>> Curve25519 (for ECDHE) is ongoing (see [RFC7748]), and support for
>> this curve will likely be required in the future.
>>
>> which is what we want to say anyway.
>>
>> > I am not a big fan of making all sorts of different crypto
>> > recommendations in our specs that differ slightly.
>>
>> --
>> ] Never tell me the odds! | ipv6 mesh
>> networks [
>> ] Michael Richardson, Sandelman Software Works | network
>> architect [
>> ] [email protected] http://www.sandelman.ca/ | ruby on
>> rails [
>>
>>
>> _______________________________________________
>> Ace mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/ace
>>
>>
> ----------------------------------------------------
> Alternatives:
> ----------------------------------------------------
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
