Re: W3C Web Crypto WG - about the NUMS/25519 curves integration in Web Crypto API

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 08/04/2014 09:30 PM, GALINDO Virginie wrote:
> Harry,
> 
> Thanks for reminder about non-NIST curves mentionned by Brian. I
> understand that your proposal is a new option.
> 
> Lets call it OPTION 3 : we can decide to integrate Non-NIST curves
> ( because we bet on their attractivity for IETF) in the main
> specification,  with a mention 'feature at risk', and we drop it if
> it happens that there is no implementation nor requirement from
> IETF.
> 

Actually, it was a re-phrasal of your option 2, using the "Feature at
Risk" so we can figure out how to go forward with the "option" of
putting it in the main spec and not going back to Last Call.

- From the latest CFRG schedule, they plan to get their recommendations
to TLS WG by mid-September. However, these schedules are always a bit
up in the air.


> To all, What I am trying to get is a direction where the WG want to
> go. I dont want to enter into the details of the way the option 1
> or 2 or 3 will be implemented. So please state your favorite
> option, the one you could live with, the one you would object to.
> This is an informal vote, take it as a mean to prepare
> consensus...
> 
> Virginie
> 
> 
> Copying other options as a reminder OPTION 1 : - We can decide to
> have an extension for NUMS and already have an editor for it - We
> can decide to have an extension for curves 25519 and have a
> potential draft with an editor coming on 10th of august - We can
> decide to have that/those extension(s) mandatory in the future
> browser profile Or OPTION 2 : - We can decide ¡®not to choose
> between extension and main spec¡¯ but decide on the principle to
> develop the NUMS/curve 25519 descriptions and put it into the spec
> once it is tested and proven it is available
> 
> 
> ---- Ryan Sleevi a ¨¦crit ----
> 
> 
> 
> On Aug 4, 2014 9:00 AM, "Harry Halpin"
> <hhalpin@w3.org<mailto:hhalpin@w3.org>> wrote:
>> 
> 
> 
> On 08/04/2014 05:52 PM, Ryan Sleevi wrote:
>>>> Harry,
>>>> 
>>>> Is this an official endorsement of a third proposal? It
>>>> seemed that for the entirity of discussion, it has
>>>> specifically been two proposals, precisely so that we could
>>>> avoid your third proposal.
> 
> This is an argument for Virginie's third proposal and a way to 
> operationalize it.
> 
> "We can decide ¡®not to choose between extension and main spec¡¯ but 
> decide on the principle to develop the NUMS/curve 25519
> descriptions and put it into the spec once it is tested and
> proven"
> 
> It seemed to reflect the sentiment in the last telecon that while
> BAL has provided text for NUMS and Trevor has promised 25519 text, 
> deciding now might be a bad idea as though it was pretty clear that
> at least one non-NIST curve would be recommended by TLS/CFRG
> eventually, it was unclear about the timeline or which precise
> curve.
> 
> Again, it's easy to add "features at risk" and take them out
> sensibly if the decision by TLS/CFRG never resolves. It seems as if
> it does resolve, it would be a good idea to keep open the
> possibility of adding that TBD non-NIST curve in the spec without
> going back to Last Call.
> 
>> OK. I don't think this proposal is practical nor realistic, in as
>> much as it fails to address the issues, and presumes a
>> non-trivial amount of editing work at some later point that will
>> meaningfully alter the spec in surprising ways, but sure, at
>> least it's out there.
> 
> 
> I've added suggestions on the monkey-patching bug to
> operationalize how we can deal with extension specs formally in the
> spec.
> 
> cheers, harry
> 
> 
> 
>>>> On Aug 4, 2014 7:14 AM, "Harry Halpin"
>>>> <hhalpin@w3.org<mailto:hhalpin@w3.org>> wrote:
>>>> 
>>>> The problem, as BAL pointed on the call, is that we do *not*
>>>> have resolution on a single curve from TLS or CFRG.  It is
>>>> unclear when those decisions will be made, although a
>>>> decision is likely I would say before we exist CR. However,
>>>> chosing between NUMS and 25519 may be premature optimization
>>>> at this point. Nonetheless, as BAL noted on the call and was
>>>> backed up on the Bugzilla, there is a real demand for
>>>> non-NIST ECC curve support in Web Crypto.
>>>> 
>>>> In general, in W3C process it is *more* difficult to add
>>>> features than to subtract them when going into CR. Thus, the
>>>> "feature at risk" mechanism.
>>>> 
>>>> So, I'd like to add another proposal.  I suggest that we
>>>> simply add a "feature at risk", using a modification of BAL's
>>>> edits, for a "TBD non-NIST" curve in the main spec. This TBD
>>>> curve, if not resolved and supported by CFRG/TLS by the time
>>>> we exit from CR, is then to be removed from the main spec. If
>>>> it is later resolved after we have exited CR, then we propose
>>>> to add these curves using the standard extension mechanism.
>>>> 
>>>> cheers, harry
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 08/04/2014 03:40 PM, GALINDO Virginie wrote:
>>>>>>> Hello Web Crypto participants,
>>>>>>> 
>>>>>>> Following our call last week [1], I have listed the 
>>>>>>> different ideas/directions that were raised about the
>>>>>>> way to proceed on the integration of NUMS and 25519
>>>>>>> curves, as discussed in bug 
>>>>>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839
>>>>>>> 
>>>>>>> ** Two possible options to handle NUMS and 25519
>>>>>>> curves integration OPTION 1 : - We can decide to have
>>>>>>> an extension for NUMS and already have an editor for it
>>>>>>> - We can decide to have an extension for curves 25519
>>>>>>> and have a potential draft with an editor coming on
>>>>>>> 10th of august - We can decide to have that/those
>>>>>>> extension(s) mandatory in the future browser profile Or
>>>>>>> OPTION 2 : - We can decide ¡®not to choose between 
>>>>>>> extension and main spec¡¯ but decide on the principle
>>>>>>> to develop the NUMS/curve 25519 descriptions and put it
>>>>>>> into the spec once it is tested and proven it is
>>>>>>> available
>>>>>>> 
>>>>>>> ** Other requirements : - We have to stay synchronized
>>>>>>> with IETF/CFRG - TLS requirements, which may require
>>>>>>> new algorithms ¡ú this is in favor of delaying the
>>>>>>> decision, expecting IETF decision - Learning loop : We
>>>>>>> have to decide how to make our spec extensible ¡ú this
>>>>>>> is favor to make early choice and beta test extension
>>>>>>> addition
>>>>>>> 
>>>>>>> I would like to have your views on the preferred path
>>>>>>> to progress, option 1 or option 2. If you have another
>>>>>>> option, feel free to suggest.
>>>>>>> 
>>>>>>> Note that we have a call scheduled next Monday 11th of
>>>>>>> August to discuss that question, but early opinion are
>>>>>>> helping to make calls efficient.
>>>>>>> 
>>>>>>> Regards, Virginie Chair of the web crypto WG
>>>>>>> 
>>>>>>> 
>>>>>>> [1] 
>>>>>>> http://lists.w3.org/Archives/Public/public-webcrypto/2014Jul/0144.html
>>>>>>>
>>>>>>>
>>>>>>>
>
>>>>>>> 
(please ignore statement below)
>>>>>>> 
>>>>>>> ________________________________ This message and any 
>>>>>>> attachments are intended solely for the addressees and
>>>>>>> may contain confidential information. Any unauthorized
>>>>>>> use or disclosure, either whole or partial, is
>>>>>>> prohibited. E-mails are susceptible to alteration. Our
>>>>>>> company shall not be liable for the message if altered,
>>>>>>> changed or falsified. If you are not the intended
>>>>>>> recipient of this message, please delete it and notify
>>>>>>> the sender. Although all reasonable efforts have been
>>>>>>> made to keep this transmission free from viruses, the
>>>>>>> sender will not be liable for damages caused by a
>>>>>>> transmitted virus.
>>>>>>> 
>>>>> 
>>>>> 
>>>> 
> 
> ________________________________ This message and any attachments
> are intended solely for the addressees and may contain confidential
> information. Any unauthorized use or disclosure, either whole or
> partial, is prohibited. E-mails are susceptible to alteration. Our
> company shall not be liable for the message if altered, changed or
> falsified. If you are not the intended recipient of this message,
> please delete it and notify the sender. Although all reasonable
> efforts have been made to keep this transmission free from viruses,
> the sender will not be liable for damages caused by a transmitted
> virus.
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJT3+CLAAoJEPgwUoSfMzqcoZMQAI/ihvFyY4VYOGFKXPFNWBXv
K3mV4cEcBhzlUWlvJ+43JXpl7HvIhtt3jIXDraoZjsHm4Bz1MdSEVxQICJIrf4gb
wl2NXr2tfPv9JHFUMXfqx+bfLa+EXZEJ7qENO7UxvDucVpHSW15m8QGHlbmCJGtn
g7bjMCPXSUwYB2NkZ59GGi+E35Zo0Lmdh7PkTyVR3PT0+Vh8JF6eZaKAM8mUmzJN
r7fpqF7jSHaAPKfw/qHW0SxP0EIxNkFFKwkPtv1rOMB9vTK16S6lG7dNsLgiXBWB
2zmj7ktehLfQ2l5qhmLZMeJSprfrJpg7xmfP05XFZgXVSwkAy4KCtCyS2hyREGI5
md7ne1FLRGanhnGdOtrNDdzs65YYwDV8IFkqn2aeBFT1HlkTTbmg1SBDe1fzRReK
//8tc6dtzwlcjISYWZNSs59sXyCsgYHAOWWo34PGktW+SQjP7VM9oFrx6hJ42p6k
nRI3BscPCkCIKzAyYFltHXiEjAZpdaoNJgaEgL8l4Sb2cGp3wDolqeTWztrxJV+n
9EO9CEUb+IeMUOU0vVVrPt5vvk5D7TcMFZtMp0sSNDdbXfK0GG6+urwGNx0tmIiC
tHGnUf//F1uxfcoRbgp/xvnPU8J+aFFOoTLy59Q5eiQrC3P170NV3yqkm4KKIDyg
0nbhtNmUaY3vblnZJxfu
=a8j7
-----END PGP SIGNATURE-----

Received on Monday, 4 August 2014 19:35:50 UTC