See also: IRC log
<trackbot> Date: 01 April 2013
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
Ryan: Active discussions of
low-level API issues are ongoing
... Would like additional participation
... particularly on key wrapping proposal
... also on default parameters
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?
<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
<trackbot> ISSUE-7 -- Deciding if we integrate a high level API in our deliverable -- open
<trackbot> ISSUE-17 -- Define the scope and API for custom key attributes -- open
<trackbot> ISSUE-22 -- Should CryptoOperations be clonable -- open
<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
<trackbot> ISSUE-29 -- Handling of block encryption modes and padding -- open
Ryan: Agree with Mark that we need a forcing function to close issues
<rbarnes> hhalpin: that sounds like a fine idea
<trackbot> ISSUE-30 -- How does the application know where the key is stored ? -- open
<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.
<trackbot> ISSUE-31 -- Problems with keys attribute of the Crypto interface -- open
<trackbot> ISSUE-32 -- Section 5.2 in API draft should mention use of secure element in the context of key security -- open
<hhalpin> I do agree almost all of these should be closed.
<trackbot> ISSUE-37 -- Method naming -- open
<trackbot> ISSUE-38 -- Key initialization and "finalization" -- open
<trackbot> ISSUE-40 -- How should we define key discovery, noting asynchronicity -- open
<rsleevi> yes, lets talk bignum - but there's the quick list :)
<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
... 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
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
... 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
<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,
... without having to revise the WebCrypto API itself
<rbarnes> rsleevi: ah, i was thinking that KW / OAEP could apply to encrypt/decrypt as well ...
<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
... Not possible to ensure that key material has really been deleted
<rbarnes> rsleevi: +infinity
<rsleevi> @markw: It goes back to the "UTF8 is hard"
scribe: Bignum support not likely
... 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
... Mozilla has implemented them as a proof of concept
<vgb> @selfissued,markw thanks for the update
Ryan: Value proxies are a robust
... 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
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
<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
<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
... 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
... Wants to continue bignum discussions on the list
Virginie: Please register for the
... 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?
<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?
<mountie> 20:00 UTC is better
Virginie proposes to have the call an hour earlier
+1 to moving to 19:00 UTC
<hhalpin> I'm OK with either.
(this would be Noon pacific)
<nvdbleek> +1 to moving to 19:00 UTC
<mountie> -1 for 19:00 UTC
<rsleevi> +1 to 19:00
<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, +22.214.171.124.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 +126.96.36.199.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:[End of scribe.perl diagnostic output]