Subject: [Cfrg] Request from W3C WebCrypto Working Group - confirmation on recommendation

From: Harry Halpin <[email-masked]>
Date: Fri, 06 Mar 2015 21:51:55 +0100

CFRG,

The W3C Web Cryptography Working Group has a deadline of March 12th on
their dependency on CFRG's recommendations, in particular [1]:

"The WG will not decide which additional curve to integrate before
IETF/CFRG shares its recommendation. Once this recommendation shared,
based on timing constraint, algorithm maturity, the WG will make
decision about integrating the curves, in accordance with the extensible
mechanism the WG will decide, according to bug 25618. In case IETF/CFRG
does not share recommendation before the Web Crypto API move to Proposed
Recommendation, there will be no curve added."

Thus, unless there is something I'm not aware of, the CFRG has
recommended for the 128 bit security level the curve specified in this
document:

https://tools.ietf.org/html/draft-irtf-cfrg-curves-01

  cheers,
      harry

[1]
http://www.w3.org/2012/webcrypto/DispositionOfComments/WebCryptoDispositionOfComments.html

---

From: Watson Ladd <[email-masked]>
Date: Fri, 6 Mar 2015 13:07:45 -0800

> https://tools.ietf.org/html/draft-irtf-cfrg-curves-01

It's not enough to have a curve. One needs to know what the values are that
need to be computed, and how these values are represented.

Sincerely,
Watson Ladd
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

---

From: Harry Halpin <[email-masked]>
Date: Mon, 09 Mar 2015 17:26:52 +0100

> need to be computed, and how these values are represented.

Note that Trevor Perrin started down this path re ECDH:

http://www.w3.org/2012/webcrypto/WebCryptoCurve25519/Curve25519-WebCrypto.html

So we could continue and co-ordinate with CFRG re representational
issues. However, we need a clear signal from CFRG that indeed, Curve
25519 would be suitable for the 128 bit security level. I believe that
consensus has been found inside CFRG, not sure when the plan was to send
it to the outside the world.

   cheers,
        harry

---

From: Watson Ladd <[email-masked]>
Date: Mon, 9 Mar 2015 10:00:47 -0700

Based on Bernstein definition, which there is no reason to change. But the
CFRG is contemplating OrangeBikeShed as an alternative, which reverses the
bytes.

The problem is that you will potentially need both. But there's an easy
solution: encourage the CFRG not to unnecessary multiply confusion by
specifying a big endian variant.

> it to the outside the world.

I think this is more a question for the chairs.