<virginie_galindo> +agenda 1- Welcome

<virginie_galindo> +agenda Welcome

<wseltzer> Callers, please stand by. We're working on the dial-in bridge.

<JimD> I was just about to ask. Thanks.

<rbarnes> telephone bridge isn't letting me in, "code invalid"

<virginie_galindo> hi all, wendy is working on the bridge, to let us all enter

<wseltzer> Our usual bridge is down. Please use code 1932 (1WEB) instead.

<jmdacruz> same here

<ddahl> hello

<emily> virginie: just letting you know, I'll have to leave after about 30 mins today

<vgb> hi, is anyone else having trouble with the passcode on the phone call?

<ddahl> vgb: code is now 1932

<rbarnes> zakim who is on the line?

<sdurbha> I think ??P21 is me

zakim aahh is Google

<vgb> Zakinm, [Microsoft.a] is me

<virginie_galindo> Zakim aaee is virginie_galindo

<wseltzer> Note to callers, our usual bridge is down. Please use code 1932 (1WEB) instead.

Zakim: aahh is Google

<virginie_galindo> Zakim:aaee is virginie_galindo

<wseltzer> scribenick: wtc

<wseltzer> scribe: wtc

virginie_galindo: survey, technical discussions of draft API, and group life, 20 minutes on each topic.
... Dutch Telecom is a new group member.

<virginie_galindo> http://www.w3.org/2012/05/21-crypto-minutes.html

Survey about Web Crypto API use cases and features

<rbarnes> where can we see the answers?

virginie_galindo: we have received 36 answers to the survey.

<rsleevi> Google regretfully didn't submit a response in time - we were still collecting some internal responses, hopefully we'll be able to add more details following this call

ddahl: I'm still analyzing the answers. I will send the entire result set to the mailing list.
... we have received a lot of good info. It would be nice to give the raw data to everyone.

virginie_galindo: I find it interesting that many people told us how they plan to use the API.
... people requested both high-level and low-level APIs. We will need to accomodate that.

<ddahl> let me know if you can access the summary and data here: https://docs.google.com/spreadsheet/gform?key=0Ah178LzElb1CdHZ2aGw0YVRvRXVnN0d2bjFGR2FlN1E&hl=en#chart

ddahl: the link to the survey is https://docs.google.com/spreadsheet/gform?key=0Ah178LzElb1CdHZ2aGw0YVRvRXVnN0d2bjFGR2FlN1E&hl=en#chart

<rsleevi> ddahl: Attempting as sleevi@google.com indicates requesting access is necessary. Would it make more sense to bring this to the wiki?

virginie_galindo: do the editors need help to analyze and summarize the responses?

<ddahl> rsleevi: sure. I can export a spreadsheet

ddahl: a summary can be automatically generated by Google docs. Need to figure out how to make that available.

wseltzer: we started from primary features in the charter. We're using the survey to clarify the ambiguity, in particular around the secondary features and other questions.

<ddahl> rsleevi: does this link work? https://docs.google.com/spreadsheet/pub?key=0Ah178LzElb1CdHZ2aGw0YVRvRXVnN0d2bjFGR2FlN1E&output=html

<rsleevi> ddahl: Yes

<ddahl> ok, that is the raw data in a google docs spreadsheet

Draft API technical discussion

virginie_galindo: moving on to the technical discussions on the draft API.
... is there any noticeable change in the update to the Editor's Draft?

ddahl: I have very rough drafts of feature discovery API and algorithm identifiers in github.

<rsleevi> ddahl: +1 to w3c hg

ddahl: I will send a link out to it.

<ddahl> Link to a "rough ideas" github: https://github.com/daviddahl/web-crypto-ideas

virginie_galindo asked wseltzer if it's fine to use an external tool such as github for collaborating on early rough drafts.

ddahl: I am agnostic to the location of the repository. I used github simply because I'm familiar with it.

<ddahl> I will add links in the README to the w3c sites/official repo

ddahl: the link to the "rough ideas" github is: https://github.com/daviddahl/web-crypto-ideas

virginie_galindo: two open issues from the last conference call: random number generation and the list of algorithms.

<wseltzer> [I will add these links to the group homepage]

<Karen> q

virginie_galindo: question to the working group: if we use the random number generator from the HTML group, would you be happy with that?

Karen: a crypto API doesn't seem complete without a random number generator.
... second, if we need a better RNG that what's provided by the OS or the HTML working group, such as one that's FIPS compliant, we should be able to do that.

rsleevi: I'd like to first respond to Karen's comment. Nothing in the HTML RNG spec precludes the use of a FIPS-compliant RNG.
... I support having an RNG in the crypto API. Perhaps the HTML RNG can point to the RNG in the crypto API in the future.

vgb: how would a programmer know whether the RNG in the crypto API or in the HTML5 is cryptographically strong?

asad: how would an application dictate that the random numbers be generated by the browser or delegated to a more secure element such as a smart card?

<rsleevi> vgb, asad: How would/could a web application trust any response it receives, given that the javascript is a hostile environment

asad: the application should be able to specify their RNG requirements rather than relying on the decision made by the browser.

<wseltzer> virginie_galindo: hears demand for RNG in the crypto API

<wseltzer> wtc: the HTML5 RNG will be a strong random generator, don't need to deprecate (or duplicate) that

Karen: how would one prove a RNG is cryptographically strong?

<rsleevi> Karen: I think any FIPS compliance issue is entirely at the whim of the browser/implementation, and not something that the web application could guarantee

virginie_galindo: there was a discussion of managing the keys by key identifiers (also known as "key isolation"), but not sure if we have reached a consensus.

<MitchZ> what does "keys by data" mean?

rsleevi: if we support the use of secure elements such as smart cards, then opaque keys (using keys by key identifiers) are a must.

<ddahl> Karen: proving the strength of the RNG from content JS is basically not possible - this may be possible via some kind of additional browser features that via UI?UX you can signal to the user that the current RNG operation is strong and legitimate

<rsleevi> MitchZ: The raw key material

rsleevi: passing the raw key bytes to functions would be the most flexible.

<rsleevi> wtc: passing the raw key bytes would be the /least/ flexible

<ddahl> rsleevi: how about an API to access specific key material via the ID if the key was generated with this in mind?

MitchZ: support rsleevi's opinion that managing the keys by identifiers would be the most flexible.

<ddahl> in which case you could then use the raw bytes

<rsleevi> ddahl: I don't believe accessing key material, by ID or not, is a use case that can be supported by secure elements

<ddahl> rsleevi: ok

<rsleevi> ddahl: The point of the secure elements is that the key bytes cannot be extracted :)

<ddahl> rsleevi: i just remember ekr saying we might need this functionality for certain operations

sdurbha: I'd like to hear more about the security implications of making the raw key bytes available to JavaScript.

<ddahl> rsleevi: i would rather not have access to the raw material for 99% + of operations

<rsleevi> ddahl: Yes. My point is that you cannot ever implement opaque key with raw bytes, but you can implement raw byte keys with key IDs

<ddahl> rsleevi: ok, cool

<rsleevi> ddahl: So if you do need raw bytes, you /may/ be able to extract the raw bytes from a key id, but it's not a must

<MitchZ> +1: for 100% of our current key usage, we don't want the app to have any access

<ddahl> rsleevi ++

vgb: we can skip the key isolation discussion if we agree that there is a requirement for "using keys by key IDs".

asad: making private or secret keys available to JS lose the nonrepudiation aspect of that.

<rsleevi> sdurbha: I believe there is still a need for ACLs, potentially origin bound. This was discussed in the hierarchy of temporary, persistent, and high-value keys

sdurbha: how to stop unauthorized use of a key identified by an identifier? So rules for key use are still needed.

<rsleevi> sdurbha: If there is an existing key with a key ID, it may be up to the browser to determine how to determine access. It may prompt the user (eg: similar to geolocation APIs), it may look at pre-defined origin rules, etc. So I don't think having a key identifier means all origins must be aware of that key identifier. This is especially important for privacy

<ddahl> the initial ideas were to bind most keys by ID and origin. However, this is limiting, so we might want to think about a smart way to optionally allow cross-domain key usage

Karen: sometimes an application needs to extract a key, even from a secure element.
... for example, to improve performance. But it must be done carefully, for example, it should be encrypted with a key encryption key and should be erased after use.
... a key identifier/handle is not sufficient for the security of the API.

<rsleevi> ddahl: I see two types of key bindings we may wish to support. During key generation (when generated via an app), it may wish to enumerate the origins allowed access to that key. For pre-provisioned keys, they may be pre-provisioned with origins or prompt the user.

Karen: so again the caller (an web app) needs to prove they are authorized to use the key.

<ddahl> rsleevi: yes, that does sound like a nice way to allow additional access

<ddahl> or rather usage

Karen: this is especially important if the provider holds multiple keys that belong to more than one security domain, web site A should not be allowed to use a key that belongs to web site B.

rsleevi: in the original editor's draft, keys are bound to the origin. This is likely to remain true.
... key identifiers may be bound to a particular origin, but we need to allow them to refer to a underlying key that can be shared.

virgine_galindo: consensue: managing keys by key IDs. consensus: managing keys by origin.

ddahl: I can propose something for key identifiers and key origin for the next conference call.

virginie_galindo: I have a question about a "safe" and "unsafe" APIs mentioned on the mailing list.

<ddahl> I can see an API for key generation to look like: generateKeys("ALGORITHM_ID", ["mozilla.org", "google.com"])

<rsleevi> virginie_galindo: It's unfortunate without ekr and some of the proponents for 'safe' APIs on the call

rsleevi: it seems more "security agile" for "API safety" to be enforced by the implementation as security threats evolve over time, rather than specifying it in the standard.

Group Life (F2F, liaison)

virginie_galindo: moving on to the fourth item, group life. F2F meeting.
... possible dates for F2F meeting are 23-24 July and 16-17 August.

wseltzer: I suggest announcing the two candidate dates on the mailing list. Should finalize it as soon as possible.

<wseltzer> virginie_galindo: Anyone not planning to attend TPAC in Lyon?

virginie_galindo: the next F2F meeting will be during TPAC in Lyon.
... we can meet with the Web Security and Web Apps WGs at TPAC.
... please let me know if there is any IETF group we should liaise with.
... the location of the first F2F meeting will be in the Americas.

ddahl: we are considering Vancouver, BC, Canada.

virginie_galindo: the reason for Vancouver is that the IETF will meet in the following week.
... please look at github for the feature discovery and algorithm identifiers.
... we have discussed key identifiers and relation to the same origin policy.
... next week we'll look at the results of the survey.
... next call will be in seven days at the same time.

wseltzer: this will be our regular time.

This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Lyons/Lyon/
Found ScribeNick: wtc
Found Scribe: wtc
Inferring ScribeNick: wtc
Default Present: +1.203.436.aaaa, +1.512.257.aabb, +1.703.284.aacc, +54541320aadd, emily, JimD, +33.6.13.23.aaee, [Microsoft], ddahl, +1.512.257.aaff, +1.408.540.aagg, christopherkula, Netflix, +1.650.214.aahh, rbarnes, wseltzer, vgb, Intel, sdurbha, virginie_galindo, Asad, Karen, wtc, rsleevi, +46.7.02.69.aaii, Samuel
Present: +1.203.436.aaaa +1.512.257.aabb +1.703.284.aacc +54541320aadd emily JimD +33.6.13.23.aaee [Microsoft] ddahl +1.512.257.aaff +1.408.540.aagg christopherkula Netflix +1.650.214.aahh rbarnes wseltzer vgb Intel sdurbha virginie_galindo Asad Karen wtc rsleevi +46.7.02.69.aaii Samuel
Got date from IRC log name: 04 Jun 2012
Guessing minutes URL: http://www.w3.org/2012/06/04-crypto-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.