Web Cryptography Working Group Teleconference -- 15 Apr 2013

<trackbot> Date: 15 April 2013

<jyates> aaaa=jyates

<karen> aacc is Karen

<hhalpin> scribe: ddahl

<hhalpin> http://www.w3.org/2013/04/01-crypto-minutes.html

<hhalpin> PROPOSAL: http://www.w3.org/2013/04/01-crypto-minutes.html are the correct minutes

<hhalpin> RESOLVED: http://www.w3.org/2013/04/01-crypto-minutes.html are the correct minutes

Closing issues

<rsleevi> ISSUE-7?

<trackbot> ISSUE-7 -- Deciding if we integrate a high level API in our deliverable -- open

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/7

<hhalpin> ISSUE-7

<trackbot> ISSUE-7 -- Deciding if we integrate a high level API in our deliverable -- open

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/7

hhalpin: mainly dealing in housekeeping today
... issue 7 is first

<rsleevi> PROPOSAL: Close ISSUE-7

<arunranga> +1

<hhalpin> +1

<rsleevi> +1

<hhalpin> RESOLVED: http://www.w3.org/2012/webcrypto/track/issues/7 is CLOSED due to ddahl's document, but the document may not end up being Rec-track

<hhalpin> ISSUE-17

<trackbot> ISSUE-17 -- Define the scope and API for custom key attributes -- open

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/17

hhalpin: issue 17 was non-contreversial as well

<hhalpin> PROPOSAL: http://www.w3.org/2012/webcrypto/track/issues/17 is closed and the answer is "there iwll not be aan API for custom key attributes

<rsleevi> +1

<hhalpin> +1

<hhalpin> RESOLVED: http://www.w3.org/2012/webcrypto/track/issues/17is closed and the answer is there will not be an API for custom key attributes

hhalpin: next is issue 22

<hhalpin> http://www.w3.org/2012/webcrypto/track/issues/22

hhalpin: cloneable discussion

<hhalpin> I do not aymeric

<rsleevi> ISSUE-22?

<trackbot> ISSUE-22 -- Should CryptoOperations be clonable -- open

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/22

<hhalpin> does anyone else want clonability?

hhalpin: amyeric is the only one who wanted clonaeability

rsleevi: not stong feelings either way, aymeric's use cases and explanations were not ideal, not going to cry if it goes away, even though there may actualy be solid usecases

hhalpin: we could keep it open and if no uses cases come up, we close it

rsleevi: there are use cases, but, do we need thins in v. 1.0?

<arunranga> Can we list the strong use cases for .clone that are better than Aymeric's scary ones?

<hhalpin> PROPOSAL: Close ISSUE-22 until we have a more tighter use-case and then add a new issue for that use-case

<rsleevi> +1

<hhalpin> +1

<sangrae> +1

<nvdbleek> +1

<hhalpin> RESOLVED: Closed ISSUE-22 until we have a more tighter use-case and then add a new issue for that use-case

<hhalpin> http://www.w3.org/2012/webcrypto/track/issues/32

<hhalpin> that's in SysApps now

hhalpin: issue 32, secure element, moved to sysaps WG
... anyone here in sysaps? establishing a connection with them might make some sense

<hhalpin> anyone else from sysapps here?

hhalpin: sysaps WG should be notified that we are not doing anything with secure element

rsleevi: gemalto has proposed the secure element API
... not aware of any formal agreements on implementing it

<hhalpin> http://www.w3.org/2012/sysapps/

hhalpin: this is a scoping issue and we are agreeing to not handle smartcard/seciure element apis
... proposes that we close issue 32

<hhalpin> So we want to interoperate with any future work (likely via Key Discovery work) in terms of SmartCard and SecureElements, but we are not writing our own APIs for these areas

karen: question: assume the sec element api made its way into sysapps...

if we want to convert or map the sysapp key to the web crypto API?

<nvdbleek> sounds good to me, but keeping a door open for smart card access through a discovery API might be an option in my opinion

scribe: how is that done

<hhalpin> PROPOSAL: ISSUE-32 closed insofar as Secure Elements is now in SysApps, and interoperability with any future API will be done via interoperability with Key Discovery Draft.

karen: sooner or later we will need to deal with interoperability

rsleevi: not going to deal with apis not in scope or theoretical implenations
... we recognize that this is not a problem for this WG to take on at this time

karen: we don not want to solve the problem right now, but do WG generally work together with overlapping interests?

hhalpin: sometimes you have atask force between 2 WGs for related work

<sangrae> IPcaller is sangrae. Sangrae Cho from ETRI

hhalpin: we might want to clarify that we will handle keys from secure elements via key discovery api at alater time
... within a use case doc we can specify the interop here

rsleevi: the proposal in sysaps by gemalto is not the same as our own use case
... there is very clear charter sep. between the issues, but there are 2 different problems here between the WGs

<nvdbleek> you might also have a look at the wiki page I started about certificate discovery https://github.com/InventiveDesigners/webcrypto-key-certificate-discovery-js/wiki/API

<hhalpin> PROPSOAL: ISSUE-32 closed insofar as Secure Elements is now in SysApps, and interoperability with any future API will be done via interoperability with Key Discovery Draft.

<hhalpin> +1

<hhalpin> s/PROPOSOAL/PROPOSAL

<nvdbleek> +1

<mountie> +1

<rsleevi> -1, due to the committment on interoperability for as of yet unspecified APIs

i agree with rsleevi here

<rsleevi> Would prefer the second clause dropped

<sangrae> +1

<hhalpin> PROPOSAL: ISSUE-32 closed insofar as Secure Elements is now in SysApps

<rsleevi> +1

hhalpin: we could say possible future interop

<hhalpin> any objections to simpler terminology?

<hhalpin> RESOLVED: ISSUE-32 closed insofar as Secure Elements is now in SysApps

<rsleevi> @hhalpin - there are lots of other interop issues beyond key discovery (eg: handling of APDUs and crypto operations via smart cards, hence my objection

hhalpin: no objections, discussion next

<hhalpin> section: unwrap and wrapping

hhalpin: unwarp/ wrap and separation of alg and operation params again

markw: I am suggesting we just rename tsome things and move things around as there has been some confusion in reading the key gen / operation params
... we should separate and clarify the dictionaries used in algs and operations

rsleevi: naming is hard
... we should simplify things, however, not sure if there is no overlpa at all
... you don't want to be able to generate a key that you cannot use

<hhalpin> thus, the relationship to operation and algorithm parameters

markw: agree with the comments that this is hard to nail down here
... not sure how the operation params need to be re-specified once the key is already generated

<hhalpin> ack rsleevi?

rsleevi: i am in agreement in the idea of if we move paramters to the key we should not have to specify in operation, but there are edge cases here
... when we start writing example code the spec vastly changes
... some hesitation here yest

hhalpin: makes sense to walk through this very carefully in the face to face
... or not as time may be limited?

f2f scheduling

rsleevi: i am planning on working through the issues before our f2f

<hhalpin> www.w3.org/2012/webcrypto/wiki/F2F_April2013

rsleevi: [the devil is in the details]

<hhalpin> lunch -> 4:30 PM

<hhalpin> 2 hours and 30 minutes

hhalpin: lets look at the schedule to see where we can spend time on this

<hhalpin> Tuesday!

hhalpin: perhaps we can discuss this on Tuesday
... during the f2f

markw: we still need to discuss the wrap / unwrap

<hhalpin> Wednesday 24th of April

<hhalpin> 9-10 AM BigNum

<hhalpin> ACTION: hhalpin to make sure Microsoft can make Wednesday morning [recorded in http://www.w3.org/2013/04/15-crypto-minutes.html#action01]

<trackbot> Created ACTION-77 - Make sure Microsoft can make Wednesday morning [on Harry Halpin - due 2013-04-22].

hhalpin: we might discuss high-level during f2f

rsleevi: we should postpone highlevel discussions until we nail down the first deliverable
... we can mobve ny discussion like this till later in the day

<hhalpin> How about moving testing earlier in the day

<hhalpin> use-cases after lunch (would include, high-level and BigNum proposals as well as certificates)

<rsleevi> sgtm

<markw> http://www.w3.org/2012/webcrypto/wiki/KeyWrap_Proposal

unwrap/wrap

markw: proposal is on the wiki, a few minor changes based on discussions, fairly fleshed out now
... want to understand the process to move forward
... looking to use jwa jwk to soecify this api
... understand the JOSE specs are a moving target

rsleevi: wish we could have discussed this better by now
... JSON serialization vs Object representation
... discussion within JOSE right now about how to deal woth key wrapping
... algorithm names and key attrs are still being figured out here in both groups
... not convinced we will have an implementable spec yet
... we can move it into the spec with many caveats

markw: would like to move it into the spec with cveats understood
... implementable? i know a few people who have done this

<rsleevi> Note: I wasn't suggesting canonical JSON - just the issue of DOMString vs UTF-8 ArrayBuffer

markw: is this a style issue over serialization vs. object?

<rsleevi> whereas using a JSON dictionary matching the JWK (eg: the result of a hypothetical JSON.parse) was the more realistic result

<hhalpin> "Feature at risk"

<markw> @rsleevi: do you just mean the pain of converting between the two ?

hhalpin: we can have features "at risk" up until the test stage

<rsleevi> @markw: Both pain and idiomatic API usage. JOSE being a wire-format, whereas we're trying to focus on an API

hhalpin: any more agenda items?

<hhalpin> Meeting adjourned.

hhalpin: crickets

<hhalpin> See everyone at the face to face!

<markw> @rsleevi: ok, fair enough

<hhalpin> trackbot end meeting

- DRAFT -

Web Cryptography Working Group Teleconference

15 Apr 2013

Attendees

Contents

Closing issues

f2f scheduling

unwrap/wrap

Summary of Action Items

Scribe.perl diagnostic output