- From: Harry Halpin <hhalpin@w3.org>
- Date: Mon, 11 Aug 2014 23:28:26 +0200
- To: public-webcrypto@w3.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Here's the minutes in text as draft as well!
* [3]Topics
1. [4]W3C Process and the Director's consideration of the
transition to Candidate Recommendation
2. [5]Reminders about W3C process
3. [6]Addition of curves (NUMS and 25519) in Bug 25839
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839
4. [7]Addition of curves (bug #25839)
* [8]Summary of Action Items
__________________________________________________________
<trackbot> Date: 11 August 2014
<wseltzer> BAL: Can we invite the submitter of the 25519 curve?
<wseltzer> Virginie: As chair I'd like to invite Trevor
i can if necessary
<scribe> scribenick: kodonog
<scribe> scribe: kodonog
W3C Process and the Director's consideration of the transition to
Candidate Recommendation
Ryan Sleevi unable to make the call, Virginie will send an
extract of his email to mailing list
<wseltzer> [9]http://www.w3.org/2005/10/Process-20051014/tr#cfi
[9] http://www.w3.org/2005/10/Process-20051014/tr#cfi
<wseltzer>
services.w3.org/xslt?xmlfile=[10]http://www.w3.org/2005/08/01-t
ransitions.html&xslfile=http://www.w3.org/2005/08/transitions.x
sl&docstatus=cr-trza
[10]
http://www.w3.org/2005/08/01-transitions.html&xslfile=http://www.w3.org/2005/08/transitions.xsl&docstatus=cr-trza
<harry> Director = TimBL
Reminders about W3C process
<harry> but also acting COO and CEO act in his place sometimes,
i.e. Ralph Swick and Jeff Jaffe
Wendy need to assure W3C management that all the objections
raised during Last Call have been addressed.
Wendy: Need to have in our archive, minutes, and bugzilla the
discussions related to questions, sufficient to satisfy the
Director
<rbarnes> this is far from the most brutal LC process i've seen
Wendy: Not possible to reach perfection, but hopefully a
specification that will result in interoperable implementations
to satisfy most
virginie: Based on the amount of feedback during LC and our
efforts to address that feedback, are you (Harry and Wendy)
comfortable that we have sufficient data to satisfy.
<wseltzer> [not Jeff Jaffe but Philippe le Hegaret acting as
Director's desginee]
harry: What is less clear, is if the resolution is in order
based on some of the discussion on some of the bugs.
virginie: Do you see any bugs that have not been properly
closed?
harry: we need to wait until all the bugs are closed to
properly assess.
<harry> So obviously there's been some strong disagreement, and
the Director will look more closely at those, in particular
one's where formal objections have been filed.
Addition of curves (NUMS and 25519) in Bug 25839
[11]https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839
[11] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839
<harry> I believe there is one Member Formal objection that is
in principle resolved, and a non-member objection which is not
clearly resolved.
Addition of curves (bug #25839)
virginie: Three options detailed in email earlier today. 1) add
NUMS as an extension; 2) defer extension work; and 3) start
work on a new extension (have editor)
<wseltzer>
[12]http://lists.w3.org/Archives/Public/public-webcrypto/2014Au
g/0083.html
[12]
http://lists.w3.org/Archives/Public/public-webcrypto/2014Aug/0083.html
virginie: Call of decision over email in the next two weeks
markw: option 1 is not clear, do you mean writing a new
specification as a separate document?
virginie: yes, a separate document
<wseltzer> acl ba;
<wseltzer> acl bal
<harry> Zakim who's making noise?
bal: would like to add an option 2.5.
... given the political situation in the IETF and the CFRG and
the Internet at large, the W3C should not publish a spec with
only NIST curves at this time
<harry> +1
bal: if we are going to publish at this time, we need something
besides NIST curves.
<harry> The debate is CFRG is quite vigorous
bal: what those curves are exactly is going to be driven by the
IETF CFRG process
<harry> I think Trevor plans to add Ed25519
bal: move the spec forward with the NUMS curves as a
placeholder for whatever the IETF process results in
... if that doesn't get implemented, it can be addressed later
in the steps towards Recommendation
... put everything in extensions not appropriate at this time
virginie: so, you are proposing to add the additional
algorithms to the main spec now
<rbarnes> but if W3C does a separate process, we get to have 2x
the politics!
<virginie> other option is : integration of NUMS Non-NIST
curves in the main spec as a feature at risk and remove it at
Candidate Recommendation, if it happens that no interoperable
implementation is demonstrated and aligned with IETF/CFRG
recommendations
bal: we should not shovel this off to a parellel extensions
spec when the NIST curves are in the main spec
selfissued: arguing from the point of testing our extensibility
models, we need to have the extensions that didn't make the
deadline test the extension process
... 25519 gives us the opportunity to test our mechanism
<markw> +1 to what Mike says about needing an extension spec to
prove out our extensibility points - and needing to do the
editing to add the extension points
rbarnes: partially agree with Brian, we do need a path to get
away from NIST curves,
... I am less concerned that this needs to occur in the base
specification
... keep the main spec focused on what we have a lot of
experience with, but show working group committment to address
not-NIST curves
harry: we could add to main spec now and delete at a later
stage on the path of publication if there isn't IETF CFRG
consensus
... agree with Brian that we need something in the main spec,
agree with Mike that we need to test the extension mechanism
... Ryan is clearly very unhappy with the NUMS curves and
doesn't not support their addition
<harry> In generally, historically W3C wants to co-operate with
IETF and CFRG in this matter.
bal: what is the timeline for going to CR?
<harry> We should exit Last Call to CR at end of August (unless
we keep getting stucks on bugs)
harry: target 3 months but may take longer, at earliest we will
exit CR at the end of November
<virginie> note we still have few bugs open
[13]https://www.w3.org/Bugs/Public/buglist.cgi?quicksearch=web%
20crypto&list_id=42092
[13]
https://www.w3.org/Bugs/Public/buglist.cgi?quicksearch=web%20crypto&list_id=42092
<harry> We should exit CR at earliest end of Nov.
<harry> Assuming test suite goes well.
bal: if CFRG can't get a recommendation out by November there
probably won't be one soon
... as for implementations, we plan to put them in our Java
plug=ins
... it won't be implementation that is the problem, it will be
consensus of the cryptographic community
rbarnes: we can write an implementable spec with this feature
at risk approach, the real problem is a testable spec
... because of this I would prefer to stick with more mature
curves in the base spec
bal: another way to look at this is to take elliptic curves out
of the base spec
... and create an elliptic curve spec
... i offer this for completeness, but i don't think it is the
right way to go
rbarnes: there is a baby in that bathwater
virginie: ok, lets forget that option
selfissued: don't drop the NIST curves because they are in use
in embedded environments
<rbarnes> no, harry, it is :)
harry: if we are going to be fair, Brian's option makes some
sense.
<virginie> but no one is really supporting it...
<harry> bal, feel free to type it in IRC
<harry> I would like to see all options voted for.
virginie: we are going to provide something in the end
<harry> Rather than you just choosing one virginie.
<harry> In fact, that is the process we should do for each
remaining issue.
<virginie> Option 1 : integration of NUMS curve as an extension
to the Web Crypto API specification, based on what was proposed
by Brian LaMacchia (potentially removing NIST curves)
<rbarnes> where extension == separate doc
PROPOSED: Option 1 from the email.
<virginie> Option 1 : integration of NUMS curve as an extension
to the Web Crypto API specification, based on what was proposed
by Brian LaMacchia (potentially removing NIST curve is a
separate specs) where extension
<harry> Can you clarify the removing NIST curves?
<wseltzer> Option 1: addition of NUMS curve as an extension to
the Web Crypto API specification, based on what was proposed by
Brian LaMacchia
virginie: Option 1: (see Wendy's text)
<virginie> Option 1 : addition of NUMS curve as an extension to
the Web Crypto API specification, based on what was proposed by
Brian LaMacchia where extension is a separate document
<rbarnes> +1
<wseltzer> [+1 agree, -1 object, 0 can live with]
<selfissued> 0
+1
<bal> -1
<markw> +1 (possibly with note in main spec that this work is
ongoing)
<harry> -1
<nvdbleek> +1
<virginie> +1
<rbarnes> +1 (obo rsleevi)
<virginie> as a comment ryan would prefer separate document
PROPOSED: Option 3 from mailing list: put NUMS in main
specification with Feature at Risk notation
<virginie> Option 3 : integration of NUMS Non-NIST curves in
the main spec as a feature at risk and remove it at Candidate
Recommendation, if it happens that no interoperable
implementation is demonstrated, aligning with IETF / CFRG
virginie: with clarification that we would align with IETF CFRG
<rbarnes> -1
<selfissued> +1
<harry> +1
<bal> +1
<markw> 0
<virginie> [+1 agree, -1 object, 0 can live with]
<nvdbleek> 0
<virginie> ryan sleevu might object to this one
<rbarnes> -1 (obo rsleevi)
0 ( or -0.5)
<virginie> Option 2 : agreement as a principle to integrate the
NUMS curves into the WG deliverables, but expect Candidate
Recommendation to make decision to integrate the algorithm in
the main spec or as an extension, final set of algorithm would
align with IETF/CFRG recommendations for TLS deployment
PROPOSED: Option 2 (see Virginie text)
harry: Option 2 will probably mean a return to Last Call
rbarnes: doesn't believe that this is the case
<rbarnes> it seems like a new LC would be necessary either way
virginiie: Option 3 may also lead to LC
<rbarnes> maybe not technically, but it's significant enough
<harry> Which basically means we have to *explicitly* return to
this question before exiting CR.
<harry> It could go back to extension.
bal: if something is a feature at risk and gets dropped during
CR, does it get dropped completely or go to an extension
virginie: that would depend on the participants of the working
group, could become an extension
bal: I just want to clarify that it doesn't get dropped
completely
<selfissued> 0
virginie: that is the principal of having a road map that we
are committing to doing this work
<nvdbleek> 0
<markw> -0.5
<bal> 0
<rbarnes> -0.5
<harry> 0
<rbarnes> as in "0 but it would make me sad"
-0.5
<rbarnes> -0
<markw> ah, mine was "-1, but I don't feel really strongly"
virginie: I'm going to make a call for consensus over the
mailing list
... adding NUMS curves to the main spec is not something that
we can agree on
<harry> I mean, it is rather important to determine if -0.5
means "I can live with but am unhappy"
markw: it seems possible that we won't get consensus on the
mailing... if there is no consensus to make a change, then the
spec stays the same
virginie: that is my understanding as well
<harry> You can backoff to votes in exceptional circumstance:
[14]http://www.w3.org/2014/Process-20140801/#Votes
[14] http://www.w3.org/2014/Process-20140801/#Votes
wseltzer: that could be a way of the working group making a
decision, would the Director agree that this was a reasonable
way of making the decision
virginie: if we can't get consensus we will have to raise the
issue to the comments, and then the Director will decide
wseltzer: for all comments, we have to go back to the commenter
and ask if that satisfies the commenter
harry: we don't want to do voting, but sometimes we have to,
and if people aren't happy with the voting, there is a formal
objection process
<harry> Alot depends on how long CR takes.
virginie: another option is delaying our roadmap by six months
to allow maturity
<rbarnes> i would object to another 6mo delay
<markw> No, more delay will not make everyone happy!
<markw> Pulling out all the EC would be better
<harry> We could start working on the test-cases regardless of
CR and LC, but I'd prefer to go into CR as well.
<rbarnes> we'll see!
<harry> That's why I proposed "feature at risk" for the
non-NIST option
<rbarnes> i would totally +1 to adding a deliverable for
non-NIST
<rbarnes> just on a different timeline
virginie: we might have another call in two weeks because I
would really like to see progress
<harry> Whether or not timelines sync up is hard to tell at
this stage in terms of how messy the test-suite will be and how
TLS/CRFG discussion goes.
<selfissued> I agree we should have another call and keep
trying to make these decisions until they're decided
<markw> I think that (new deliverable) would be a good idea -
we can develop that whilst still keeping open the option of
later integration into the main specification
<harry> When should we do the next call?
<wseltzer> [25 August, Virginie proposes for next call]
<harry> August 25th
<virginie> august 25th
virginie: next call 25 aug at the same time
<harry> trackbot, end meeting
On 08/11/2014 11:25 PM, Ryan Sleevi wrote:
> I think the link was dropped?
>
> You mean http://www.w3.org/2014/08/11-crypto-minutes.html ,
> correct?
>
>
> On Mon, Aug 11, 2014 at 2:08 PM, GALINDO Virginie <
> Virginie.Galindo@gemalto.com> wrote:
>
>> (beware, indicative votes about bug 25839 and funny maths
>> inside)
>>
>> Regards,
>>
>> Virginie
>>
>> Chair of the web crypto wg
>>
>>
>> ------------------------------ 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)
iQIcBAEBAgAGBQJT6TV5AAoJEPgwUoSfMzqcFNwQAKhMKniuF8c8VhEEHTnSi/45
qyy5CAxNHzJPmSoQHf1R0JlG4qdlUYUpYd7udDcPgGxEWq8BYO2y0c27auK/LOgY
EWuvPrZcnzGcx7NxqAX0lgPj5DPMOKDLRZG32p9y7kFeHd2Tc1iUXq1rN8brZeLW
nHP74sLWz4iTwohp3WRNniaZMxS679Y4rQ03W/r30Pt9J1wA3rKoZJ020gNYg34s
9+4hoE/QsF9kZpHZFpdVXCWzkGhuICkIQFRGuJGw6wNMcVW07ZcS+fxgKz5xewWf
HrHxAdbEssl6acgZw3AonV7O+a3rYDRXwgESLQzfN0rUauYwSoOpKaA056iH+baO
OLEzG4g7TAKc5hMHCrg+MEy0fX9YhJ5YbC0YQ+QLNRpcL373so17Bi6cMDpXzMT/
etvBCgUOWVOoJTqfXD+CahetOuaNnwzd9dry8hvAf7cCNbvbvBD4FOddnwVf4NeD
FoRY57jBuEP6Vni8fKC6j1772RgXwVyqLpJO2qQroRVEzkRBjAOrV/zI+qKrzCv0
mEsUK2IN+tllpRwlGfTmCFFk7UWKseqbjw8WoJRjNsm2Snyu7aqkVKVzoPB3MHmR
L581mM0Y+6gWK7zN84bJndTSQe+0MWb7vB4v6knHa28ZHpJMcxiux37lqyS97YNv
+QnvOOi0bqhGgk9BtaFz
=Q33c
-----END PGP SIGNATURE-----
Received on Monday, 11 August 2014 21:28:35 UTC