- From: Wendy Seltzer <wseltzer@w3.org>
- Date: Mon, 28 Jul 2014 17:11:26 -0400
- To: GALINDO Virginie <Virginie.Galindo@gemalto.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
- CC: Harry Halpin <hhalpin@w3.org>
Thanks to all who participated in today's WebCrypto WG call. Draft
minutes can be found at:
http://www.w3.org/2014/07/28-crypto-minutes.html
and in text below.
--Wendy
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Web Cryptography Working Group Teleconference
28 Jul 2014
See also: [2]IRC log
[2] http://www.w3.org/2014/07/28-crypto-irc
Attendees
Present
karen_oDonoghue, Wendy, +1.503.712.aaaa, JYates,
Matt_Wood, BAL, Michael_Hutchinson, rbarnes,
Virginie_Galindo, Karen, hhalpin, rsleevi, markw,
[Microsoft], vgb, Mike_Jones
Regrets
Chair
Virginie_Galindo
Scribe
wseltzer
Contents
* [3]Topics
1. [4]Intro
2. [5]Bug 25607, Security Recommendations
3. [6]Bug 25985, Interoperability
4. [7]Bug 25839, NUMS and 25519
* [8]Summary of Action Items
__________________________________________________________
<trackbot> Date: 28 July 2014
<rbarnes> is there an agenda posted somewhere?
scribenick wseltzer
Intro
Virginie: Agenda will begin by focusing on sensitive bugs
<bal> dialing back in...
<rsleevi> bug 25607?
->
[9]http://lists.w3.org/Archives/Public/public-webcrypto/2014Jul
/0097.html
[9]
http://lists.w3.org/Archives/Public/public-webcrypto/2014Jul/0097.html
<MichaelH> - 25607 on security recommendation :
[10]https://www.w3.org/Bugs/Public/show_bug.cgi?id=25607
[10] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25607
Bug 25607, Security Recommendations
<rsleevi>
[11]https://www.w3.org/Bugs/Public/show_bug.cgi?id=25607
[11] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25607
<bal> muted now, thanks
Virginie: Security recommendations
... Have some editorial notes; still have open comment that we
should make reference to know attacks
... Akamai comments, post from Graham Steele
... CFRG could maintain document with reference to attacks and
potential vulnerabilities in WebCrypto algorithms
<harry> Essentially, we have a security considerations doc in
the IETF CFRG, and Rich Salz from Akamai is happy with that
solution as long as we link to said document when it exists.
<harry> Graham Steel will make a first version.
Virginie: Proposed resolution: close the bug by endorsing
clarifications in ED and referencing IETF CFRG
... adding that reference when the doc is available
rbarnes: Sounds fine to me
BAL: Not sure CFRG has yet agreed to take up the work
Wendy: CFRG expressed interest, although not formal commitment
Harry: Response generally positive; no objections
<harry> Note that we did formally ask the CFRG as well, no
objections.
<harry> i.e. Individual Submission - and the W3C did commit to
helping with that process.
BAL: This could certainly proceed as an ID (individual
submission); it would take process for it to become official
work of CFRG
<harry> So that people in the WG do not have to pay attention -
unless they want to :)
Virginie: Is that still a good resolution?
BAL: We'll need to see text, but in principle, sounds as though
it can work
<harry> I'm happy to take that action.
Harry: Happy to take the action to get a suitable first version
from Graham Steel, put it through the IETF proces
MichaelH: What is the timeline for having a trackable ID from
CFRG?
Harry: expect a document by early September
<MichaelH> ack
<harry> Worse case, if IETF doesn't accept we could make it a
WG note.
Harry: and IETF response shortly after (weeks, not months)
<harry> [looking]
Proposed resolution: The WG to resolve the bug 25607 by (1)
endorsing clarifications from the recent editors draft and (2)
referencing to a document listing algorithms attacks and
vulnerabilities, maintained by IETF CFRG (to be added in the
specification by the editors as soon as available).
<rsleevi> +1
<MichaelH> +1
<rbarnes> +1
Virginie: +1 if you agree, -1 if you object
<bal> +1
<vgb> +1
<kodonog> +1
<Karen_> +1
<harry> virginie +1
<harry> looks like resolution!
RESOLUTION: The WG to resolve the bug 25607 by (1) endorsing
clarifications from the recent editors draft and (2)
referencing to a document listing algorithms attacks and
vulnerabilities, maintained by IETF CFRG (to be added in the
specification by the editors as soon as available).
<MichaelH> - 25985 on interoperability
[12]https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985
[12] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985
Bug 25985, Interoperability
-> [13]https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985 Bug
25985
[13] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985
Virginie: This bug on interoperability received lots of
comments
... one suggestion, what about writitng browser profile after
we have done implementation testing?
... This profile would be non-normative
... So potential resolution, wait for testing, write
non-normative profile
<rbarnes> comments from anne, like annevk?
<rsleevi> yes
<harry> yes, annevk
<harry> Annvk has not objected nor is he member of the WG, I
think he may just want an explanation at this stage (i.e.
non-browser implementations)
Virginie: potential resolution, bug stays open, then later
write non-normative profile
rsleevi: there could be several profiles.
... There's a use case for smart TVs, traditional web, sysapps
... So suggestion was that all use cases benefit from normative
requirements, but their sets of normative reqs differ
... It will be tricky to nail down normative reqs for each use
case, but we could do so
... They don't have to be non-normative
MichaelH: Trying to understand how we'd make browsers
interoperable
... keys are stored in the browser
rsleevi: The issue of interop is not about key storage, but the
set of algorithms exposed to the Web
... so, e.g., web devs can know that if a browser claims to
support WebCrypto, it supports SHA1
... interop requriment is that web devs don't have to guess
about algo support
MichaelH: Is that even achievable?
rbarnes: At the level we have now, there's not such a
combinatorial issue
... you'd batch them into API levels
... e.g. WebCrypto level 1 is what everyone does now; level 2
is next version
... I'm fine having normative requirements, but that might make
us more conservative
... PKCS1 is everywhere; PSS not so widespread
rsleevi: Spec will not have normative requirements; a
dictionary of algorithms and very precise implementations
<rbarnes> most of the impact of that conservatism is probably
on EC curves
rsleevi: but not requirement on what UAs implement what algos
<rbarnes> (i hope it's obvious that EC curves are an important
element here)
rsleevi: requirements documents will await testing and
determination of use cases
... consensus among browsers seems to be that browser profile
should be normative
... but different use cases may have different interop
requirments
selfissued: Whether it's normative or not, we do need to keep
at least one profile so we can achieve interop
... Choices should be driven by what's commonly available
... and interoperable set sufficient for interop with JOSE
... PCKS1, 1.5 signatures, RSA encryption, AES keywrap. GCM
highly recommended
Wendy: don't need to set normativity/non-normativity of
profiles
<rsleevi>
[14]https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Over
view.html#algorithm-recommendations-implementers
[14]
https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#algorithm-recommendations-implementers
<rbarnes> note that we've already broken JOSE compatibility by
removing "RSA1_5"
Virginie: Several profiles possible
Proposed Resolution: Leave bug open; expect resolution after
testing phase with development of one or more profiles
<harry> Just communicate to Boris and Annevk that we *will*
have profiles that will achieve interop within clearly defined
subsets of implementations, as should be known after
test-suite.
MichaelH: We should resolve the question of
normative/non-normative now
Virginie: we could say normative, if people agree
Harry: It's harder to say what exactly will be least common set
before implementation, testing
... it's kicking the can down the road until we can see what
implementations will exist
MichaelH: We should say that at least one or more profile will
be normative
<harry> I think the idea was that different kinds of
implementations may have different sets, possibly without LCDs
<rsleevi>
[15]https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Over
view.html#algorithm-recommendations-implementers
[15]
https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#algorithm-recommendations-implementers
rbarnes: Our objective with the profile is to specify what's
both desirable and feasbile to implement
... what subset of the current proposal
... current proposal: see what's implemented, then document
that
Virgine: prefer to resolve that we will address after testing
phase
Proposed Resolution: Leave the bug open; expect to resolve it
after testing phase by developing one or more profiles
<rsleevi> +1
<rbarnes> +!
Virginie: +1 to agree, -1 to object
<selfissued> +1
<markw> +1
<rbarnes> +1
<mdwood> +1
<Karen_> +1
<rbarnes> yeah!!!!
RESOLUTION: Leave the bug open; expect to resolve it after
testing phase by developing one or more profiles
<MichaelH> - 25839 on curve25519
[16]https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839
[16] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839
<harry>
[17]https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839
[17] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839
Bug 25839, NUMS and 25519
<harry> Brian's proposed changes are here:
[18]http://lists.w3.org/Archives/Public/public-webcrypto/2014Ju
l/0041.html (attached as WORD Doc)
[18]
http://lists.w3.org/Archives/Public/public-webcrypto/2014Jul/0041.html
Virginie: Microsoft and BAL have provided us with a document
... Will we include this curve in our main spec, as provided by
Microsoft, or
... will we make it a dedicated extension, with its own rec
track
<harry> Note extenisve comments and notice also that Trevor
Perrin has resolved to direclty address 25519
Virginie: Recently, we got an offer from Trevor to write up
25519 as an extension
<harry> Also note extensive discussion in CFRG on named curves
for TLS
<rbarnes> harry: yes, taking action on this seems a little
premature given that
Virginie; I have suggested that we vote to endorse Microsoft's
description either within API directly or as extension
<kodonog> +1 (for 25985 ... <didn't hit return>)
<harry>
[19]http://www.ietf.org/mail-archive/web/cfrg/current/maillist.
html
[19] http://www.ietf.org/mail-archive/web/cfrg/current/maillist.html
<rbarnes> what was the proposed resolution?
BAL: I want to make everyone in the WG aware that this was the
topic of extensive discussion at last week's IETF
... both NUMS, 25519, and others at higher level
... No resolution yet from CFRG
... Requirements-gathering for a few more weeks, then 4-week
comment period
... When I wrote the doc, I put in 4 curves
... There does not seem to be much interest in the Weirstrass
curves, more interest in the performant versions
... If I were rewriting it now, I'd probably include only
twisted-Edwards
... prefer to see a non-NIST optiom in the main spec
<bal> Slight correction: *6* curves were added initially
<harry> wseltzer: It seems discussions are energetic in IETF
and CFRG
<bal> I'd scale back to *3*
<bal> for the main spec
<harry> ... so now is not the best time to have new curves
although what is recommended to TLS will likely have wide
implementation
<harry> ... it would be good if we could be synchronized with
what ends up being recommended by TLS
rbarnes: I sympathize with Brian's desire to get non-NIST
curves included as soon as possible
<markw> +1 to what Richard said
rbarnes: procedurally, it would be easier to handle this as an
extension
<rbarnes> in other words, let's have the fight once, in CFRG :)
selfissued: My main concern is that we should have an easy way
to add algorithms without having to revise the spec
... we need an extension mechanism
bal: a further complication; TLS WG took action to take all
their existing EC specs to standards track
<harry> See here for extensibility bug:
[20]https://www.w3.org/Bugs/Public/show_bug.cgi?id=25618
[20] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25618
bal: so a subsequent discussion for TLS will be what should be
mandatory to implement
... Right now, nothing EC is MTI
... but depending how we do this, extensions, profiles, we
might need to make extension specs mandatory for some interop
profiles
... I have a preference to get this into the spec quickly
<Zakim> rsleevi, you wanted to respond to selfissued
rsleevi: I don't think in practice that extension spec or main
spec will change availability for the web
... procedural track and availability/implementation differ
<harry> I am wondering aloud if this should be resolved in the
same way we resolved "profiles", i.e. get a good extension
mechanism and then kick this down the road - and then fix
normativity at same time as BAL mentions.
rsleevi: I dont' think it would be a problem to support
extensions as part of MTI profile
<MichaelH> Harry +1
rsleevi: interdependencies are part of the extensibility bug
... We don't yet have a good point for extensibility
... so hearing from implementers would be helpful
<harry> So we merge that into the extensibility mechansim and
try to fix that process before going out of Last Call.
rsleevi: WG needs to do more review, to identify extensibility
bugs and resolve them
... definitely need to make the spec extensible, let every algo
stand on its own
... concern re naming of algos
... think of main spec as just
... "colleciton of extensions"
<harry> Sounds like we may need a good proposal on
extensibility and then a call next week.
markw: We do have an extension point; you can add more
algorithms
<rsleevi> Well, our extension plan is buggy, that's my point :)
<rsleevi> Not that we don't ahve one, it's just buggy
bal: The extensions that allow you to add new algs don't really
work well with EC, or mirror IETF
<rsleevi> I do agree with bal@ that we do need to fix curve
extensibility :)
<rbarnes> +1 to having curves be a separate extension point
bal: implementatoins; independent libraries can be updated
relatively quickly
harry: This bug sounds as though it's merging with the
extension bug
... so I suggest we focus on extensibility
bal: Depends on process. There's some text on the bug
... I'd like to get a pre-acceptance of extension spec
... showing commitment to offer customers a non-NIST option
<rbarnes> +1 to a "non-NIST curves" deliverable
<harry> sounds reasonable to me.
bal: if we don't put it into the main spec today
Virginie: Feeling that including the contribution as an
extension is reasonable
... so propose resolution "wg endorses curve provided by
Microsoft as extension document"
<rsleevi> As mentioned on the Curve25519 thread, I have no
issues towards having people bring extension specs for
discussion about adding to REC track. The only thing that
really speaks to UA concerns would be MTI, but that's
orthogonal to a REC track for (NUMS, Curve25519, 3DES, MD5,
SEED, GOST, etc)
Virginie: we need to fix both extensibility and adding curves
<rsleevi> (Well, and any hypothetical IPR concerns about
bringing an alg towards REC, but that's just W3C process)
bal: I'd rather have something opposite NIST directly in the
spec
<harry> The text is "The WG is endorsing the curve description
provided by Microsoft, in a dedicated extension, which will
have its own track to become a Recommendation."
bal: but if we must do it elsewhere, make sure it's on the smae
timeline
<harry> Maybe we could have a straw poll on "main spec" vs.
"extension"?
<MichaelH> Could the NIST curves also be in extension spec?
<harry> wseltzer: Could we move the decision about whether text
is in main spec or extension spec to later?
<harry> ... when we know how situation develops in IETF and
CFRG.
<rsleevi> @MichaelH: as mentioned, conceptually, *all*
algorithms are extension spec
Virginie: think we'll have to move the discussion to mailing
list
<harry> I would have a call on "extension mechanisms"
<bal> +1
Virginie: propose a dedicated call
<vgb> +1
<rsleevi> 2 weeks seems like too long. But +1 to a dedicated
call
<kodonog> +1
<rbarnes> +1
<markw> +1 (sooner)
<selfissued> +1
<harry> Next week is fine with me if we make progress
<selfissued> or in one week is ok
<rsleevi> It seems like it'd be much more useful to just hash
out on the mailing list, come to a proposed RESOLUTION, and
just put that out on the list
<rsleevi> there seems to be a few requirements:
<rsleevi> - If an ext spec, main spec needs to support
extension points
<rsleevi> - If an ext spec, it needs to be REC track
Virginie: Call in 2 weeks
<harry> Depends likely how contentious mailing list discussion
is.
<rsleevi> - If an ext spec, it should be on the same timeline
as the main spec (I don't think we can commit to this, but for
mailing list)
<rsleevi> I think these at least bear discussing, I think some
of these are non-controversial and easy to resolve
<markw> @rsleevi - do you have a proposal for extension points
?
Wendy: let's try to resolve or converge on mailing list
Virginie: last bug we'll bring to the mailing list
RESOLUTION: Next call in 2 weeks, same time
[adjourned]
trackbot, end teleconf
Summary of Action Items
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [21]scribe.perl version
1.138 ([22]CVS log)
$Date: 2014-07-28 21:05:13 $
__________________________________________________________
--
Wendy Seltzer -- wseltzer@w3.org +1.617.715.4883 (office)
Policy Counsel and Domain Lead, World Wide Web Consortium (W3C)
http://wendy.seltzer.org/ +1.617.863.0613 (mobile)
Received on Monday, 28 July 2014 21:11:29 UTC