W3C

- DRAFT -

SV_MEETING_TITLE

18 Feb 2013

See also: IRC log

Attendees

Present
Regrets
Chair
virginie
Scribe
vgb

Contents


<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> NVDBleek?

<hhalpin> NVDBleek?

<hhalpin> Vijay?

<hhalpin> scribe: vgb

<virginie> http://www.w3.org/2013/02/04-crypto-minutes.html

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

<karen> +q

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 draft
... 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 opinions
... 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 Paypal premises
... 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

Summary of Action Items

[NEW] ACTION: Mark to propose updated text for wrap/unwrap [recorded in http://www.w3.org/2013/02/18-crypto-minutes.html#action02]
[NEW] 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]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2013/02/18 21:03:16 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]