<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
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
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].
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!