W3C

- DRAFT -

Web Cryptography Working Group Teleconference

22 Jul 2013

Attendees

Present
+82.22.14.0.aaaa, +1.617.253.aabb, +1.540.809.aacc, +1.503.554.aadd, +1.650.214.aaee, ddahl, Virginie_Galindo, +1.408.540.aaff, jyates, vgb, Netflix, rsleevi, hhalpin, jimsch, kodonog, mountie, markw, sangrae, +1.512.257.aagg, MichaelH, wseltzer
Regrets
Chair
virginie
Scribe
rsleevi

Contents


<trackbot> Date: 22 July 2013

<mountie> good morning

<sangrae> This is sangrae, I am on the phone.

<jimsch> zakrin 554 is jimsch

<jimsch> zakrim aadd is jimsch

<sangrae> I think IPcaller is sangrae

<virginie> genda?

I can scribe

<scribe> scribenick: rsleevi

<scribe> scribe: rsleevi

<hhalpin_> chair: Virginie

<scribe> chair: virginie

virginie: Agenda bashing and review

<virginie> http://www.w3.org/2013/07/08-crypto-minutes.html

virginie: call for approval of minutes of previous meeting, 8 July 2013
... minutes are approved

Certificates

virginie: Secondary feature, not critical, but if we can reach consensus on this use case, that would be helpful
... sangrae to present proposal previously made on mailing list

sangrae: want to present from powerpoint slides from http://lists.w3.org/Archives/Public/public-webcrypto/2013Jul/0006.html
... current Korean banking use case uses browser to generate public key
... sends public key to CA server
... CA server then issues certificate to user
... then user can use certificates for various purposes/online transactions (eg: online banking, stock trading)
... reliant on trusted third party
... credentials come from TTP, but credentials are used with other websites
... in this flow, the origin of the certificate issuing site is != the origin for certificate use
... [discussing slide 3]

<virginie> http://lists.w3.org/Archives/Public/public-webcrypto/2013Jul/0099.html

sangrae: first precondition is JS API to discover certificates
... input parameter is trusted CA list
... API can return certificates that are issued by trusted CA list
... if certificates do not match trusted CA list, then certificate follows the SOP
... relies on existing PKI when a trusted CA list is provided

second condition: Certificate 1 is issued from bank.com, Certificate 2 is issued from ca.com

scribe: first certificate is under bank.com (SOP)
... second certificate is under Trusted Third Party model
... [discussing how trusted third party allows SOP exception]

virginie: Would like to collect comments on Sangrae's proposal to add exception to same origin policy

<hhalpin_> rsleevi: Security Problems may cause problems with regards to SOP

<hhalpin_> ... from the browser-side, the Hacker.com can ask to see list of Trusted Certs

rsleevi: the SOP is designed to protect vicim.com from attacker.com
... in this model, you replace ca.com for victim.com and attacker.com with bank.com

mountie: From our experience, the certificates can already be used for many sites
... for the trusted CA list, browsers already have it / can be discovered from the browser

<hhalpin_> rsleevi: CA list is server certificats, not client certs. Only server certs have audit

rsleevi: The root CA list used in browsers is for server certificates, not for client certificates.

MichaelH: As I understand it, the certificates they want to store the server certificate

sangrae: When server wants to authenticate user, we do a certificate from a trusted third party. In TLS protocol, server sends trusted CA list to browser for browser to select any certificate that matches
... the proposed solution comes from that idea

virginie: How do we progress on this issue?
... is it a correct understanding - if we don't allow certificates for different origins, the web certificate API doesn't help
... you only want the web certificate API with this exception, correct?

mountie: user always visits ca.com to issue, revoke, update certificates for bank.com
... need to allow ca.com to be able to provision those certs

virginie: Are there any browsers implementing your proposal who can bring their experience to the WG?

rsleevi: In the TLS case, the browser handles all the key material access and operation.

sangrae: the key material stays in the browser/UA

rsleevi: That wasn't the point - doing any form of signature/operation with the key, even if it stays in the browser, is a security risk

<vgb> question is: why even do the operation in JS instead of using client auth in TLS?

vgb: Why is this API superior - why does TLS client auth not work for this?

mountie: TLS client auth is just useful for the TLS protocol. We cannot control the TLS sessions (which is currently listed in secondary features)
... that is the best option, if we can control that session
... If a certificate is issued using CMP for a key generated with webcrypto, that key cannot be used with other websites for TLS client auth

<virginie> note the actual certificate API is available here : http://mountielee.github.io/webcertapi/webcertapi_draft.html

mountie: want to make sure key/cert can be used for other sites with SOP exceptions

vgb: My question was: Let's say you had a certificate issued that was in the certificate store, and you did client auth with that cert, and you setup a TLS session to bank.com
... and over that TLS connection you did whatever operations you wanted (transactions, etc)
... is there an attack that is prevented in that scenario that is prevented by allowing the certificate to control the cert private key

mountie: We have multiple layers. need to protect messages from client to server backends. TLS only protects server.

vgb: If I understand correctly, in your scenario, you have a particular security context at the TLS connection level, and because the application layer doesn't have access to that security context, it must independently verify the security context of the client

mountie: the TLS client auth handles message encryption and authentication, but does not provide for any digital signatures

vgb: Do you do any form of channel binding? How do you verify the client is the one performing the operation?

mountie: In Korea, we use the TLS connection for protection, but then you have to use the same certificate to perform a digital signature

vgb: Does bank.com do something to ensure the TLS connection is the same cert used for the signature

mountie: No, we don't use client certificates for the TLS. We only use it for the authentication & signing at the application layer.

<mountie> JS -> Browser -> (TLS session) -> WebServer -> ServerApplication

<vgb> thanks sangrae and mountie, will follow up on the list

virginie: Several ways to proceed - gather feedback without the SOP exception
... gather feedback to see if there is no strong exception

<mountie> JS (Certificate Handline) -> Browser -> Web Server -> ServerApplication (Verification or other operation)

virginie: Would be valuable if the WG can work on this API and try to improve it
... will review a new version of this API during conf call, perhaps in Sept

Key Discovery

virginie: Any objections to taking ED named, pre-provisioned key discovery to WD

<hhalpin_> PROPOSAL: Take Web Crypto Key Discovery to Working Draft

<markw> +1

<virginie> +1

<hhalpin_> +1

<mitchz> +1

<jimsch> +1

<MichaelH> +1

<kodonog> +1

<mountie> +1

<hhalpin_> RESOLVED: Take Web Crypto Key Discovery to Working Draft

<hhalpin_> ACTION: hhalpin with markw to make sure it goes through WD via W3C TR

<trackbot> Created ACTION-107 - With markw to make sure it goes through WD via W3C TR [on Harry Halpin - due 2013-07-29].

Use cases

virginie: Reminder - use cases is not a deliverable of the WG / not normative
... but it is trying to capture the use cases of what the API being delivered contains
... suggest we go for public working draft on use cases

<virginie> PROPOSAL : - Proposed resolution : Go for next public working draft based on 19th of July version https://dvcs.w3.org/hg/webcrypto-usecases/raw-file/5765a3364579/Overview.html

<wseltzer> [WD just puts things into long-term /TR space]

rsleevi: What does it mean to go to a WD for a non-normative/non-rec track document

hhalpin: Some WG don't send their stuff through, keep it in a wiki
... if we think we want to keep this stable, allow other WG to refer it, generally makes sense to publish it as a WG note
... won't have a test suite, won't go through the IPR process
... purely informative note that is stable
... useful for things like LC, where people may try to broaden scope and add use cases

<hhalpin_> the name is "Working Group Note"

<hhalpin_> re status

<hhalpin_> +1

<virginie> +1

<sangrae> +1

<markw> +1

PROPOSAL: Resolution to go forward with use cases doc as a WG note draft

<mitchz> +1

<mountie> +1

<ddahl> +1

<MichaelH> +1

<hhalpin_> RESOLVED: Go for next public working note draft based on 19th of July version https://dvcs.w3.org/hg/webcrypto-usecases/raw-file/5765a3364579/Overview.html

hhalpin: Working on stylesheet distinctions for REC track docs and notes

<wseltzer> [we use a boilerplate "status of the document" session to indicate that notes are not consensus positions]

virginie: Trying to understand current status of wrap/unwrap and the web crypto API
... not sure if we have time for discussion
... request for people to review the recent mail and make sure views are captured about the summary and the way to proceed

rsleevi: issue is with JWK (DOMString vs ArrayBuffer vs Dictionary)
... Other issue is the handling of JWK attributes

jimsch: If any extra JWK attributes are desired, it would be good before the next IETF JOSE meeting (IETF 87 in Berlin)

<markw> I am on vacation

virginie: It may be a bit short to have that discussion/resolution. Can we have another call next week to discuss this point?

<kodonog> that is the week of ietf

virginie: Goal for next public WD is in Sept

<markw> @jimsch I have proposed that WebCrypto define an "extractable" attribute to carry the WebCrypto Key attribute of the same name. If there is a reasonable WebCrpyto-independent version of that it would make sense for JOSE to define that (IMO)

<kodonog> ietf is next week... not the week after...

virginie: Thanks to editors working on specs. Starting to see implementations, which is great
... next call in 2 weeks if we have sufficient people, otherwise 4 weeks

<hhalpin_> trackbot, make minutes

<trackbot> Sorry, hhalpin_, I don't understand 'trackbot, make minutes'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.

no RRSAgent

<hhalpin_> just painful!

Summary of Action Items

[NEW] ACTION: hhalpin with markw to make sure it goes through WD via W3C TR
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2013-07-26 06:08:11 $