<trackbot> Date: 01 April 2013

Mike Here

Virginie - confirmed the call agenda

<wseltzer> [agenda: http://lists.w3.org/Archives/Public/public-webcrypto/2013Mar/0158.html ]

<wseltzer> scribenick: selfissued

<wseltzer> previous call minutes:http://www.w3.org/2013/03/18-crypto-minutes.html

Virginie - the minutes of the previous call are approved

<hhalpin> RESOLVED: http://www.w3.org/2013/03/18-crypto-minutes.html are the correct minutes from the previous meeting

low-level API

Ryan: Active discussions of low-level API issues are ongoing
... Would like additional participation
... particularly on key wrapping proposal
... also on default parameters

<rbarnes> ack

Mark: We need forcing functions to actually close issues.

Ryan: Let's create issues and have them be focused
... Our discussions have often been at too abstract a level

<markw> Let's discuss http://www.w3.org/2012/webcrypto/track/issues/12

<rsleevi> eg: Issue-37

<rsleevi> Can we first resolve the issues from our past calls?

<rsleevi> The ones we felt we were progressing to closing?

<virginie> http://www.w3.org/2012/webcrypto/track/

<markw> Can we just close Issue-37 - noone has mentioned any problems with the current names for ages

Virginie: Proposes that we make decisions on open issues during next F2F meeting

Mike: Agrees with this proposal

Virginie: Not all issues are related to the low-level API
... We need to identify which ones the working group members need to look at

<markw> +1 to closing Issue-37

<rbarnes> +1 to closing ISSUE-37

Ryan: Many of these issues are historical and aren't closely related to the current drafts

<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

<rsleevi> 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

<rsleevi> ISSUE-22?

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

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

<rbarnes> +1 to resolving these historical issues

<hhalpin> Maybe the best way to go through this list quickly is just have a list of issues sent out over email with proposed resolutions, the we close them all out en masse next call.

<markw> +1 to closing ISSUE-17

<rsleevi> ISSUE-29?

<trackbot> ISSUE-29 -- Handling of block encryption modes and padding -- open

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

Ryan: Agree with Mark that we need a forcing function to close issues

<rbarnes> hhalpin: that sounds like a fine idea

<rsleevi> ISSUE-30?

<trackbot> ISSUE-30 -- How does the application know where the key is stored ? -- open

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

<hhalpin> i.e. the forcing function should be next meeting and then if there's any objections to closing them, we finalize that at our f2f.

<rsleevi> ISSUE-31?

<trackbot> ISSUE-31 -- Problems with keys attribute of the Crypto interface -- open

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

<rsleevi> ISSUE-32?

<trackbot> ISSUE-32 -- Section 5.2 in API draft should mention use of secure element in the context of key security -- open

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

<hhalpin> I do agree almost all of these should be closed.

<rsleevi> ISSUE-37?

<trackbot> ISSUE-37 -- Method naming -- open

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

<rsleevi> ISSUE-38?

<trackbot> ISSUE-38 -- Key initialization and "finalization" -- open

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

<rsleevi> ISSUE-40?

<trackbot> ISSUE-40 -- How should we define key discovery, noting asynchronicity -- open

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

<rsleevi> yes, lets talk bignum - but there's the quick list :)

<hhalpin> markw?

<rsleevi> the wrap/unwrap proposal is ISSUE-35

Virginie: Asked Mark for an update on the key wrap/unwrap draft

<hhalpin> maybe move to BigNum, markw doesn't seem to be here.

Mark: Updated draft on the wiki
... Proposed responses to the open issues
... Proposes to use JWE wrapping of JWK objects
... Added sections on using using RSA-OAEP and and AES Key Wrap

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

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

Ryan: What about key types that are not supported in JOSE?
... There needs to be a JWK representation
... Nervous about tight coupling to JOSE

<rsleevi> I think the question would be for DSA

<rbarnes> rsleevi: WebCrypto doesn't have DSA

<rbarnes> question would be DH

Mike: The JOSE WG agreed to put the private and symmetric key representations in the JWK sec
... If there are other key types that need JWK representations, they should be written up

Richard: +1 Mike - there's agreement on how to represent keys
... the continuing discussions are about how to best wrap those representations
... Both groups learn productive things from one another

<rbarnes> plus, webex is hosting the meeting, so we should have good remote participation :0

<rbarnes> :)

<rsleevi> @selfissued Sorry if I wasn't clearer: It was the representation of wrapped keys (eg: symmetric keys vs asymmetric keys as an example of the ongoing discussions)

Virginie: Now we will move to the bignum agenda item

Jason Mackey: Author of bignum proposal

<rbarnes> rsleevi: ABV makes sense for OAEP / AES-KW; i could see wrapKey/unwrapKey returning a serialized JSON object

scribe: Use cases: Several anonymous and blinded signature schemes
... U-Prove, elliptic curve pairing, attribute based encryption

<rsleevi> @rbarnes: Not sure it makes since for OAEP/AES-KW, since you're still returning a JWE-wrapped JWK (as per Mark's proposal)

scribe: Generally the ability to implement non-standard stuff, such as Chinese algorithms, etc...
... without having to revise the WebCrypto API itself
... performance reason to not write this in JavaScript
... JavaScript doesn't really have integers - just doubles

<rbarnes> rsleevi: ah, i was thinking that KW / OAEP could apply to encrypt/decrypt as well ...

<markw> @rsleevi The choice is serialized UTF-8 JSON objects returned in a ABV vs Javascript objects == IDL dictionary

scribe: Can only effectively use 16 bit integers in JavaScript

<virginie> Initial proposal by Microsoft : http://lists.w3.org/Archives/Public/public-webcrypto/2013Mar/0029.html

scribe: Bit operations also not supported - also not efficient

<rsleevi> @markw: json.stringify(), avoid the weird base64 dot-encoding of JWE

scribe: Garbage collection in the JavaScript runtime can't be controlled
... Not possible to ensure that key material has really been deleted

<rbarnes> rsleevi: +infinity

<rsleevi> @markw: It goes back to the "UTF8 is hard"

<markw> I don't see any problem returning a Javascript object - it would be the thing that when serialized produces the JWE JSON Serialization

scribe: Bignum support not likely to be added to JavaScript language
... Also, if added, it would likely be general-purpose - not optimized for crypto

<markw> someone mentioned canonicalization problems, but I don't think they apply since there's nothing calculated over the JSON serialization (which itself has no canonical version), AFAIK

scribe: Significant optimizations are possible by crypto-focused bignum operations

<rbarnes> markw: that's correct, the canonicalization issue was raised by someone who wanted to do JWK key fingerprints

scribe: Three pieces: High-level helper functions, integer group object, elliptic curve object

<hhalpin> My question will be 1) are these primitives more or less uniformly supported across different operating systems and 2) what's the reactions from other browser vendors?

scribe: Tried to be clear which functions are required and which are optional
... For instance, divide-by-2 operation is not essential, but provides efficiencies

Ryan: Discussed in-house in Google - a lot of opposition
... Want good definitions of use cases for the bignum work

<vgb> @rsleevi,markw regarding JSON-encoding JWE - are you saying we would define field names for the 4-5 parts that are now dot-separated? Some existing ciphertext fields don't have names in the JWE drafts.

On the other thread - JOSE also decided to add JSON Serializations to the JWS and JWE drafts

<vgb> i see - those are being defined now?

<markw> @vgb: JOSE have already defined a JSON serialization which puts the 5 parts into a JSON object, instead of dot-separated

Ryan: Support for using value proxies
... Mozilla has implemented them as a proof of concept

<vgb> @selfissued,markw thanks for the update

<markw> http://self-issued.info/docs/draft-jones-jose-jwe-json-serialization-02.html

Ryan: Value proxies are a robust way to extend JavaScript
... Concern about constant conversion between internal and external representations
... A big gap for multiplicative subgroups
... Supportive of the goals, but need a clear set of objective

<rbarnes> vgb: some of us are also trying to make the JOSE JSON format more JSON, less base64

Ryan: Will try to put the remarks together on the list

<rsleevi> http://wiki.ecmascript.org/doku.php?id=strawman:value_proxies

Harry: Question: Are these primitives uniformly implemented?

<rsleevi> No, the primitives are not widely exposed at all. MPI is almost always seen as part of the crypto boundary and entirely opaque

<hhalpin> And in particular, given the goal is that uniformity across browsers is importance, I'd like to hear Mozilla.

Harry: What is the feedback from other browser vendors?

Mike: bignum useful for Korean national algorithms

ArunRanga: There isn't a strong use case from Browser ID - discussed with Ben Adida

<hhalpin> I can see blind signatures being within scope in general, but we'd really need to clarify the use-cases

ArunRanga: Could also do Browser ID without bignum

<ddahl> arunranga: +1

<rbarnes> arunranga: +1

Arun: Wants to double down on getting the low-level API right

Ryan: Getting push-back from several sources in Google
... Bignum APIs tend to be buried in crypto API implementations and not exposed
... Not exposed in NSS

<rsleevi> Nope

<hhalpin> Is there a way to address the use-cases on a higher-level than a generic BigNum that works with NSS?

Jason: Ryan seems worried that people would misuse this or use it wrog

<hhalpin> (i.e. blind signatures use-cases)

Jason: Concern valid for any kinds of crypto APIs
... bignum enabling technology for advancing crypto functions in browsers
... Allows experts to build crypto libraries that perform well in the browser
... Easy with native code, but impossible with only access to current JavaScript APIs
... Eventual JavaScript support for 32 and 64 bit integers are a start, but don't complete the picture

<arunranga> I'm not totally sure the "startlingly slow" critique is spot on.

Jason: To Ryan: This wasn't meant to be the final draft of the API. If there's a problem, let's address it.

<arunranga> hhalpin, impossible to hear.

<arunranga> hhalpin's question about "universally implemented" had to do with the underlying operating systems.

<hhalpin> is it true or not re NSS and the underlying operating systems as regards these proposed BigNum primitives?

Ryan: I think my points were misunderstood - we can continue discussion on the mailing list

<arunranga> I hope Jason does attend.

Virgine: F2F meeting planning
... Asked Jason to attend

<rsleevi> @hhalpin: NSS, GnuTLS, and OpenSSL all treat their bignum implementations as internal APIs, *not* part of the public API and with no statements of portability or the like

<rsleevi> @hhalpin: From the start, the goal was to *not* bring the JS engine into the cryptographic boundary

<rsleevi> which this would

Virgine: Would like to not make low-level and high-level APIs at risk by adding bignum work
... Wants to continue bignum discussions on the list

Virginie: Please register for the F2F meeting
... Will send a draft agenda too
... Goal to close as many low-level API issues as possible
... together with key discovery API
... Don't have clear use cases for high-level API
... One proposal to spend two hours of our meeting on the high-level API, in part to work on use cases
... Possibly make it open to non-WG members

<arunranga> rsleevi, can we induce slightlylate to attend the "public" part of the meeting?

<arunranga> ^^slightlyoff

<rbarnes> if we do a public part, we might want to start with a brief tutorial on the current API, e.g., a walk-through of http://demo.polycrypt.net/hello/

Virginie: Wants to understand pepole's priorities for use of time at the meeting
... Next call will be one week before the F2F meeting in two weeks

<hhalpin> I can chair, no problem

<hhalpin> Do we want to keep 20:00 UTC or go to 19:00 UTC?

<hhalpin> Mountie?

<mountie> 20:00 UTC is better

Virginie proposes to have the call an hour earlier

+1 to moving to 19:00 UTC

<vgb> +1

<hhalpin> I'm OK with either.

<virginie> +1

<ddahl> either

(this would be Noon pacific)

<nvdbleek> +1 to moving to 19:00 UTC

<mountie> -1 for 19:00 UTC

<rbarnes> either

<MichaelH> +1

<rsleevi> +1 to 19:00

<arunranga> either

<jyates> either

<hhalpin> I am noticing that we would make the life much harder to for folks in Korea.

<hhalpin> Given that we still have the Korean banking use-case on the table, it makes sense to keep to 20:00

Virginie: We will not be changing the time, at least for the next call, as it would be very difficult in Asia

<hhalpin> I would be interested in hearing in more detail re Korean banking use case and the BigNum proposal, that was kinda unclear

<wseltzer> trackbot, end teleconf

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/minutes: /previous call minutes:/
Succeeded: s/Vijay/ArunRanga/
Found ScribeNick: selfissued
Inferring Scribes: selfissued
Default Present: markw, nvdbleek, hhalpin, +1.202.596.aaaa, rbarnes, rsleevi, jyates, +82.22.14.0.aabb, mountie, wseltzer, Virginie_Galindo, +1.512.257.aacc, mitchz, Michael_Hutchinson, ddahl, arunranga, Karen, Jason, Vijay, Tony, Mike_Jones, +31.61.877.aadd
Present: markw nvdbleek hhalpin +1.202.596.aaaa rbarnes rsleevi jyates +82.22.14.0.aabb mountie wseltzer Virginie_Galindo +1.512.257.aacc mitchz Michael_Hutchinson ddahl arunranga Karen Jason Vijay Tony Mike_Jones +31.61.877.aadd
Found Date: 01 Apr 2013
Guessing minutes URL: http://www.w3.org/2013/04/01-crypto-minutes.html
People with action items: