- From: Wendy Seltzer <wseltzer@w3.org>
- Date: Mon, 10 Dec 2012 11:13:03 -0500
- To: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Our next call will be 17 December, 2000 UTC.
Minutes from today's call here:
http://www.w3.org/2012/12/10-crypto-minutes.html
and below in text form:
Web Cryptography Working Group Teleconference
10 Dec 2012
See also: [2]IRC log
[2] http://www.w3.org/2012/12/10-crypto-irc
Attendees
Present
+1.571.335.aaaa, Wendy, Nat_Sakimura, +1.408.458.aabb,
Scott_Kelly, +1.303.543.aacc, zooko, ddahl,
+1.512.257.aadd, +1.415.867.aaee, markw, virginie,
arunranga, +47.40.22.aaff, +1.650.525.aagg, pal,
Havard_Molland, +82.22.14.0.aahh, mountie, Alex_Russell,
+1.512.343.aaii, karen, hhalpin, [Google], [Microsoft]
Regrets
Chair
Virginie
Scribe
wseltzer
Contents
* [3]Topics
1. [4]Use Cases
2. [5]New Spec Key Discovery
3. [6]Web Crypto API
4. [7]Group Life
* [8]Summary of Action Items
__________________________________________________________
<trackbot> Date: 10 December 2012
hi virginie
<mountie> hi
<zooko> hello!
<ddahl> hi zooko
<zooko> Hi ddahl
<arunranga> Use Cases document in HG:
[9]http://dvcs.w3.org/hg/webcrypto-usecases/raw-file/536a63a3f9
4c/Overview.html
[9]
http://dvcs.w3.org/hg/webcrypto-usecases/raw-file/536a63a3f94c/Overview.html
<mountie> I'm at home. not available to use voice
virginie: Thanks to people for making the effort to join this
call, especially US folks for whom it's early, Asia for whom
it's late
[agenda:
[10]http://lists.w3.org/Archives/Public/public-webcrypto/2012De
c/0005.html]
[10]
http://lists.w3.org/Archives/Public/public-webcrypto/2012Dec/0005.html
<scribe> scribenick: wseltzer
<virginie> [11]http://www.w3.org/2012/11/26-crypto-minutes.html
[11] http://www.w3.org/2012/11/26-crypto-minutes.html
virginie: any objection to previous minutes? Approved.
Use Cases
<arunranga> zakim unmute me
virginie: Arun, can you introduce the use cases?
arunranga:
[12]http://dvcs.w3.org/hg/webcrypto-usecases/raw-file/536a63a3f
94c/Overview.html
[12]
http://dvcs.w3.org/hg/webcrypto-usecases/raw-file/536a63a3f94c/Overview.html
<markw> I know, sorry!
arunranga: Still chasing down a few people, including Mark, to
give a bit more from a Netflix perspective.
... Goal is to give use cases, show sample code.
... Got lots of good feedback from Facebook, a real-world
use-case.
... Questions still remain, such as whether we can do better
with HMAC.
... Good feedback from Tantek, who wants to use public keys.
... If all follow up with me, we can have a draft by mid-week
for heartbeat.
virginie: questions for Arun?
... as you can see: banking transactions, video services, code
sanctity, encrypted communications
arunranga: nobody should be misled by the fact that I may have
used Korean names, not a one-to-one match with S. Korea
... tried to construct the use-case around mountie's email
<hhalpin> did we test to get consent to publish?
virginie: people who need to provide arun with additional
details, please have a close look
... we are trying to get this published at next heartbeat, WG
consensus to go forward for publication on 17 Dec.
<hhalpin> So everyone has a deadline to read it by the 17th :)
<zooko> +1
virginie: Any objection to having the spec go for publication
17 Dec?
<hhalpin> +1
<virginie> +1
<ddahl> +1
[+1 = no objection]
<mountie> +1
<hhalpin> Just this one for now
pal: is this publication of this spec alone, or others?
<hhalpin> although we hope to publish all three (API, Mark's
document, use-cases) in the next heartbeat
virginie: To start, I asked just about the Use Cases.
... I'd like to get consensus for publication of each
separately.
pal: Recommend asking the question specifically so people know
what they're approving.
virginie: Any objection to having Use Cases doc published 17
Dec?
pal: no objection
virginie: great, we'll go forward with the use cases on 17 Dec
arunranga: Main goal is to produce primary, achievable use
cases, that the API as it's emerging in draft can accomplish
... not secondary use cases
<hhalpin> Its OK to list secondary use-cases as long as they
are clearly marked as "secondary" and without consensus.
virginie: Did you make any statement re relation between
WebCryptoAPI and use cases?
arunranga: I'd be happy to take feedback and add a note to that
effect.
<scribe> ACTION: virginie to propose language on relation
between WebCryptoAPI and use cases [recorded in
[13]http://www.w3.org/2012/12/10-crypto-minutes.html#action01]
<trackbot> Created ACTION-70 - Propose language on relation
between WebCryptoAPI and use cases [on Virginie GALINDO - due
2012-12-17].
virginie: The way you're writing this, we could later add new
secondary features
arunranga: yes
markw: Clarify that use cases should be able to include
pre-provisioned keys?
arunranga: yes, we can include pre-provisioned keys. Looking to
you (markw) for detail
... we can include a caveat that this particular feature may
not be included in the WebCryptoAPI yet, but members of the WG
are actively discussing
markw: I don't consider it a secondary use case. It should
either be published in the main draft or in the additional doc
we're working on.
New Spec Key Discovery
virginie: I'm sure you're all aware of how Mark came to prepare
new specification on key discovery
... how to identify keys that may be pre-provisioned, so
separate document.
... is there any problem or objection, or anyone who'd like to
help Mark?
markw: The intent is that this spec will have the same
timeframe and Rec status as the main API
... either we should publish this at the same time as the main
API loses support for pre-provisioned keys, so it's an atomic
change
... when writing the new draft, only included suppor tfor
origin named pre-provisioned keys.
... no reason it couldn't include others, so the timeframe is
not impacted
<arunranga> Link to draft?
markw: added some material on privacy, based on indexdb
document
<virginie> Key discovery specification proposal
[14]http://lists.w3.org/Archives/Public/public-webcrypto/2012De
c/0001.html
[14]
http://lists.w3.org/Archives/Public/public-webcrypto/2012Dec/0001.html
<hhalpin> I'll work on this after the phone call
markw: Attached document to email because couldn't yet get it
into hg tree
<hhalpin> its possible there's an issue re permissions
virginie: when you say we're publishing at the same time, do
you mean heartbeat or more formal steps?
markw: I mean for the heartbeat.
<hhalpin> i.e. by Dec 17th
markw: can we do it this time?
virginie: I have no problem putting them on the same track.
Will we be ready for 17 Dec?
<arunranga> notes rsleevi is on the q
virginie: question for the group, who has something to say
about new spec? any objection to publishing?
<rsleevi_> +1
<hhalpin> +1
rsleevi_: My suggestion would be to keep different forms of key
discovery in different specs, for what implementers need.
... Mark's approach is good, useful to implementers interested
in that functionality.
... There are technical concerns, but no reason not to publish
the draft.
virginie: thanks
hhalpin: We can release multiple docs in the heartbeat.
... We need to specify when we release whether we expect them
to be normative.
... And we'll say with Mark's doc that we expect it will be
normative.
... Both API and Key Discovery will have to go through the same
process.
... To become W3C recs, they need implementation, testing, vote
from W3C AC
... let's send both docs down the normative track. Try to keep
them to the same schedule
virginie: +1 to what harry said.
<hhalpin> Just to make sure W3C process is clear here
virginie: Mark, anything more we need before publication?
<hhalpin> its OK to publish drafty things
markw: I expect comments over the week, but don't see any
problem with going ahead.
virginie: Any further comments? We'll go through formal process
to approve pub next week.
... Thanks Mark for doing this quickly.
... Thanks both Ryan and Mark for working on docs.
Web Crypto API
<rsleevi_> [15]https://dvcs.w3.org/hg/webcrypto-api/log
[15] https://dvcs.w3.org/hg/webcrypto-api/log
rsleevi_: obviously lots of changes.
... most of the focus is trying to resolve usability issues,
tighten up API
... total 22 changes, some more significant than others.
... Highlighting: removal of key storage and key attributes.
... keystorage has been discussed at length on ml.
... intent to add text highlighting key discovery elsewhere.
... Key attributes, tightly coupled with notion of key storage
... e.g. if something is stored on a smartcard, attributes
might change without the user agent
... exposing attribs as persistent not a good fit.
... so instead, make just the core functions of the key are
attribs; others are stored where you store the key.
... application-specific or advisory attribs should be defined
along with how you get the key from storage.
... e.g. synchronous, handles, etc.
... Concat added as an algorithm.
... Another change, overall workflow.
... earlier draft closer to PKCS11. init, process... , complete
... intent to share the objects, but implementers had concern
it was too specific.
... explicit initialization step removed.
... that also removes the recyclability of crypto ops.
... added ability to supply data to be processed in call, e.g.
hashing
... those are some of the major changes.
... easiest way to see them in practice is to look at examples
doc.
... process data flow and state machine transition simplified
for both developer and implementer.
virginie: Any questions for Ryan?
hhalpin: sounds sensible. 2 Qs: what did we do re zooko's
questions on taxonomy of labeling?
... did we have any usability feedback?
rsleevi_: taxonomy label distinct from security considerations.
<slightlyoff> I have provided some feedback to rsleevi_ in
private mail
rsleevi_: didn't think the taxonomy was a good fit.
<hhalpin> The taxonomy wasn't accepted I remember, but checking
on security considerations
<zooko> +q
rsleevi_: Security considerations have not yet been
incorporated.
... focus this time was usability.
hhalpin: we might want to have security considerations in this
round.
<rsleevi_> Security considerations will not happen in next ED
<slightlyoff> in particular, I continue to think that the
CryptoOperation class needs to be a form of Promise
<rsleevi_> (at least, I don't have time, ddahl?)
hhalpin: to address earlier comments, if we can.
<slightlyoff> and it's not today
rsleevi_: I disagree it's necessary for the next WD. Don't see
that I can add it.
... don't need to duplicate IRTF doc.
virginie: we might have more developments re security review
when David Rogers takes it up.
<rsleevi_> slightlyoff: A non-multi-part CryptoOperation yes,
but I don't think a multi-part operation fits in the promise
model
<mountie> for security consideration, we need to reference
WebAppSec WG CSP
<hhalpin> its generally good to be able to point to our
response from a previous heartbeat in a new hearbeat, but we do
of course only have so much time.
markw: We haven't discussed removal of key attribs before
... is the intent that other specs might add attribs?
<ddahl> rsleevi: Perhaps, I thought we had some new language
for that section?
markw: re pre-provisioned keys, we discussed ID attrib.
... re unwrapping, there might be attributes inside the
wrapper, exposed on unwrapping.
... that would resurrect the requirement for attribs on the
key.
rsleevi_: key attribs relies on things not yet specified by
JOSE
... would prefer not to include something on which there's no
proposal for how it's going to work.
<slightlyoff> rsleevi_: if there's a single answer to the
operation (a single result), then it fits.
rsleevi_: once there's more work from JOSE re key wrapping, we
may reconsider.
<rsleevi_> slightlyoff: Agreed
<Zakim> rsleevi_, you wanted to respond to mark
markw: can other specs add attributes?
<hhalpin> In W3C process terms, there's no problem with
specifying certain key attributes in a different document
arunranga: also my Q. if a web developer wants to determine
validity, they need to engage with the app?
<hhalpin> it just makes things more confusing for readers.
rsleevi_: start-date and end-date removed at our first
face-to-face. too much variation.
... all these notions of validity are more closely related to
application than to key storage.
... they're not universal concepts.
... very few APIs, except PKCS11, allow you to add attribs
<slightlyoff> rsleevi_: 12.1's multi-part steps suggest to me
that there's a single return value
rsleevi_: Problem: exposing attrib directly leaves it undefined
for all keys that don't have the attrib
... either you're defining default values or saying it may be
present.
... Problematic if the underlying external storage system
changes attribs, how do I reflect that to the caller? what's
the UA to do?
... so for key object, if you want to talk about validity,
stick it in indexdb, leave it to application to both store and
enforce.
<arunranga> ack
rsleevi_: having a key-value store doesn't really fit
virginie: does that make sense?
... does that mean we'll never have to use attributes in main
API?
zooko: I like Ryan's latest rev of the API.
<slightlyoff> it's not using promises yet
zooko: Consistently asynchronous using promises; a few
one-shot.
... still think it would be good for usability and security to
label algorithms as to whether they provide encryption,
hashing, or something else
<hhalpin> I'm partial to attributes personally, but I'm not
going to object.
rsleevi_: considering adding a table of contents, listing
algorithms and supported ops.
zooko: Sounds like a way to express what algorithms do, will
look.
markw: pre-provisioned keys creates a sub-class with attribs
virginie: any comments, send them and proposed resolution to
Ryan
... so prepare for WG decision on publication 17 Dec.
<hhalpin> US-friendly time.
<hhalpin> 20:00 UTC
virginie: Additional call next week, 17 Dec. 20 UTC (3pm
Boston, Noon Pacific)
... Quick question to David Dahl, progress on high-level API?
ddahl: Drafts on github, getting comments from Richard Barnes,
Mike Jones. Will ping them again.
<mountie> 20:00 UTC ==> 05:00 AM KST
virginie: please share on public list when in shape.
Group Life
<rsleevi_> @slightlyoff: Both single and multi-part operations
may result in multiple outputs (via progress events), along
with a final event (oncomplete) indicating that the operation
is completed / final values are calculated (or validated).
Example of multiple onprogress events would be an encrypt
(single part or multi-part), example of intermediate onprogress
events but a single oncomplete would be a decrypt/MAC verify
virginie: We'll have to decide when to hold our next meeting.
... We have offers from Korea and Boston for hosting.
... but first I'd like to find a date. Please fill out the
doodle.
... We'll continue alternating phone call timing.
... In January, one call every two weeks, alternating times.
<rsleevi_> @zooko: Consider something like Table 34 of
[16]http://www.cryptsoft.com/pkcs11doc/STANDARD/pkcs-11v2-20.pd
f or
[17]http://www.w3.org/TR/xmlenc-core1/#sec-Table-of-Algorithms
[16] http://www.cryptsoft.com/pkcs11doc/STANDARD/pkcs-11v2-20.pdf
[17] http://www.w3.org/TR/xmlenc-core1/#sec-Table-of-Algorithms
<slightlyoff> rsleevi_: so in the multiple progress for
multi-part encrypt, are the chunks handed to the progress
events also part of the final result?
virginie: Next week, 17 Dec call to prepare publication.
... thanks to all the editors for their hard work
<rsleevi_> @slightlyoff: That's what I think we're trying to
figure out and nail down ;)
virginie: Ryan, Arun, Mark, thank you!
<rsleevi_> @slightlyoff: Whether to follow the File API model
(which is "Yes"), or to follow the "save memory model" (which
is "no")
virginie: next week, focus on getting consensus to go for
publication.
... talk to you in a week and on ml.
RRSAgent: make minutes
<slightlyoff> rsleevi_: if we want a streaming crypto
operation, we should do that orthoginally
trackbot, end teleconf
<zooko> rsleevi_: this comment confused me:
<zooko> // Unlike the signing example, which showed multi-part
encryption, here we
<zooko> // will perform the entire AES operation in a single
call.
Summary of Action Items
[NEW] ACTION: virginie to propose language on relation between
WebCryptoAPI and use cases [recorded in
[18]http://www.w3.org/2012/12/10-crypto-minutes.html#action01]
[End of minutes]
__________________________________________________________
--
Wendy Seltzer -- wseltzer@w3.org +1.617.715.4883 (office)
Policy Counsel, World Wide Web Consortium (W3C)
http://wendy.seltzer.org/ +1.617.863.0613 (mobile)
Received on Monday, 10 December 2012 16:13:07 UTC