See also: IRC log
<virginie> this is SEC_WebCryp
<markw> Netflix team will be a few minutes late
<arunranga> Weird, I'm on the call.
<jyates> aaaa is jyates
<virginie> P2 is virginie
<virginie> ??P2 is virginie
<hhalpin> ISSUE-40: Key import/export
<trackbot> Notes added to ISSUE-40 How should we define key discovery, noting asynchronicity.
<markw> ISSUE-40 is not import/export
<hhalpin> There also needs to be a discussion over JOSE formats
<hhalpin> Lastly, I'd be interested in hearing opinions over algorithm and security considerations from folks other than Ryan as well.
<hhalpin> scribe: vgb
virginie: propose approving minutes - done w/ no objections
<hhalpin> RESOLVED: Approved minutes http://www.w3.org/2013/02/04-crypto-minutes.html
virginie: proposal to close issue 18
<virginie> PROPOSAL: Close ISSUE-18: Should it be possible to perform CryptoOperations as a 'streaming' operation with URI semantics?
virginie: some discussions on the mailing list - it seems like there is agreement to close
mike_jones: what resolution?
virginie: too complex, won't do it
<hhalpin> Aymeric on the phone?
hhalpin: what is Intel's view?
virginie: not sure if they are part of the WG
hhalpin: Aymeric mentioned something about this once. It would be good to get his view.
<hhalpin> Incomplete blocks
<hhalpin> Aymeric and EKR and Ryan
hhalpin: long thread on incomplete blocks
<hhalpin> I'd delay just to make sure Intel is on the phone.
@hhalpin - isn't that thread about clone ie issue 22?
<hhalpin> @vgb, yes but wouldn't that effect ISSUE-18 as well?
virginie: ok, so we'll provisionally close the issue and revisit if Aymeric objects
<hhalpin> i.e. assume streaing input, the stream ends before the input is complete, what is the result?
<hhalpin> If you don't allow streaming, then its not a problem.
<virginie> PROPOSAL: CLOSE ISSUE-40: How should we define key discovery, noting asynchronicity
@hhalpin - I thought Aymeric's use case was independent of streaming - you could argue of course that it makes it bigger not smaller
virginie: propose closing issue 40
<hhalpin> There's no KeyImport or KeyExport functions now.
markw: issue was addressed by creating key discovery draft
johnsim: wants confirmation that this is the resolution and not something else
markw: the issue was that FPWD did not allow async key discovery, this draft follows the pattern of the rest of the API. If anyone wants to keep the issue open for dealing with non-origin-specific keys, then okay, but there are no proposals on those lines.
hhalpin: key import and export are not in this draft, are they also gone from the other one?
markw: they should be in the main
... see them in the TOC
hhalpin: don't see them in Editor's Draft, and this leaves out use cases like importing keys from outside the browser.
<hhalpin> 15.2.8. The importKey method
hhalpin: 15.2.8 and .9 are blank
markw: always have been, have proposed text before
Mike_Jones: do we have an issue to address this?
markw: issue 35 - wrap/unwrap is closely related
<hhalpin> I think we may want to differentiate import/export and wrap.
markw: but Ryan thought they should be distinct
<hhalpin> Shall we raise that as a distinct new issue?
virginie: Mike_Jones could review MarkW's previous text and bring it up for inclusion in the draft.
<hhalpin> Should we open a new issue?
<hhalpin> for import/export in particular?
<scribe> ACTION: Mike_Jones to look at import/export proposal from Netflix and make suggestions for API draft [recorded in http://www.w3.org/2013/02/18-crypto-minutes.html#action01]
<trackbot> Error finding 'Mike_Jones'. You can review and register nicknames at <http://www.w3.org/2012/webcrypto/track/users>.
<hhalpin> So far we have no good multi-origin proposals
karen: is issue 40 specific to origin specific keys?
<hhalpin> so I think so far we're just dealing with origin-specific keys
virginie: no alternative
proposals, so have to close or postpone
... looks like no proposals for multi-origin even if there is interest
karen: MarkW, who would check origin?
MarkW: UA, just as it enforces other origin restrictions
karen: where in the API is the origin specified?
<hhalpin> The key is specified by the origin that generates it.
<hhalpin> i.e. the origin of the script
<hhalpin> This gets trickier with import/export
MarkW: the UA just knows
karen: should origin be in an attribute?
<hhalpin> which is one way to get rid of the problem is not allow import/export
MarkW: not necessarily
<virginie> [Key discovery API] https://dvcs.w3.org/hg/webcrypto-keydiscovery/raw-file/tip/Overview.html
MarkW: as long as pre-provisioning allows setting the origin, the interface does not have to expose it
<nvdbleek2> Are there any events to inform the script that there are new keys available/are no longer available (use case smart cards that are inserted/removed when the script is running)
<nvdbleek2> (We were prototyping an app and were missing notification events)
nvdbleek2: asking about events to indicate arrival/departure of keys while the app is running
<hhalpin> nvdbleek2, currently there is not anything in the spec I believe.
MarkW: Haven't written much about
this - not specific to named keys.
... we have to assume that any key may go away
... we concluded in our previous discussions that further operations would simply fail.
... maybe the issue could use more work
nvdbleek2: more interested in app knowing when a smart card is inserted for example
MarkW: currently only way is to poll
<hhalpin> That does seem inefficient :(
virginie: wrap/unwrap issue status?
MarkW: can update proposal based on the few comments, go from there
<ddahl_> virginie: so sorry about missing this meeting. it is a holiday for moz, and am hanging out with the kids all day
<scribe> ACTION: Mark to propose updated text for wrap/unwrap [recorded in http://www.w3.org/2013/02/18-crypto-minutes.html#action02]
<trackbot> Error creating new action - could not connect to Tracker. Please contact sysreq with the details of what happened.
<hhalpin> Maybe add an action to Ryan to add the text
virginie: at the stage where we
have to decide which features to include or postpone/close. if
you have new things to bring up, speak now.
... when we asked to extend charter by 6 months, question of high-level API came up. Should we extend by 8 months and try to get that done as well?
... any opinions? In Gemalto capacity, in favor.
<arunranga> +1 for high level API, but there isn't a lot of precedent for low+high
Mike_Jones: thinks it is important to deliver HL API.
<hhalpin> low level = bindings to OpenSSL
hhalpin: seems to be clear need for HL APIs - community has created a few. We should be more active in reaching out to those people since they may not be fully represented here.
virginie: HL APIs not yet mature and may be at risk if we stick to 6 months
<hhalpin> i.e. ask reps from Google's KeyCzar, NaCL, and Stanford (Emily - have you looked at it?)
<hhalpin> Maybe get a co-editor for the HL
<hhalpin> I'm happy to set up a call for review of the HL API
<hhalpin> maybe do it not next call, but call after?
<hhalpin> and keep in extension to 8 months?
virginie: apparently no strong
... secondary features - want to discuss with Mountie about certificate issues
... on the list
... maybe allocate time during f2f for this
<arunranga> Few real use cases have emerged about secondary features.
<hhalpin> The main use-case driving secondary features are certificates (Korean Banking use-case) and smart-card driven use-cases
virginie: f2f for april 23-25 at
... book tickets and suggest agenda items
<hhalpin> Maybe we should do a meeting next week?
<hhalpin> given that we need to make a few decisions and today was a holiday
hhalpin: working on setting up a
test suite with the HTML WG
... need to decide if this should be part of core HTML test suite. cjkula had volunteered to maintain it.
virginie: can't make it next week
but will send out takeaways
... do participate on list
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/issue 75/issue 35/ Succeeded: s/SSH/SSL/ Found Scribe: vgb Inferring ScribeNick: vgb WARNING: No "Topic:" lines found. WARNING: No "Present: ... " found! Possibly Present: IPcaller ISSUE-40 MarkW Microsoft Mike_Jones MitchZ Netflix P2 PROPOSAL SEC_WebCryp aaaa aabb aacc aadd aaee aaff active arunranga crypto ddahl ddahl_ emily hhalpin johnsim joined jyates karen nvdbleek nvdbleek2 rsleevi scottk slightlyoff terinjokes timeless tobie trackbot vgb virginie wseltzer You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting Got date from IRC log name: 18 Feb 2013 Guessing minutes URL: http://www.w3.org/2013/02/18-crypto-minutes.html People with action items: mark mike_jones WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]