Looking for phone number...

<virginie_galindo> +1.617.761.6200, 27978#

Thanks.

<virginie_galindo> we will start in 5 minutes

<wtc> Hi. This is Wan-Teh Chang. I just dialed in.

<ddahl> ddahl is on the call

I don't hear anything on the line. I think I'm having phone trouble on my end...

<vgb> Hi. This is Vijay Bharadwaj from Microsoft.

<virginie_galindo> we are very quite :-)

Okay now I can hear.

<virginie_galindo> aadd is me

<christopherkula> 510-387-xxxx is me

<wtc> +1.650.214.aaee is wtc

I haven't done it before.

I'm going to make really long tedious

scribe: point and someone has to write it all down.

Like that?

Hhe.,

Heh.

<hhalpin> scribe: zooko

<hhalpin> Web Crypto WG 13:00 WG May 21st 2012 Convened

welcome

<wseltzer>

<hhalpin> Scribenick: zooko

<hhalpin> so if your not on the phone, your are not counted as attending unless you speak up on IRC

hhalpin: if you're not on the phone you're not counted as attending unless you speak up on IRC.

<sdurbha> sdurbha: I am on the phone as well

<fluffy> I am +1.403.244.aaii but forget hot to tell zakim that ( I am Cullen Jennings at Cisco )

<hhalpin> Zakim aaii is fluffy

<hhalpin> Tommy Krumer from Northrop Grummann

scribe failure -- my phone just went out again

<hhalpin> ??P3 is sdurbha

Hm. Now it works again.

<sdurbha> Cablelabs; Cable Televsion Laboratories (full name)

Primary Use-cases (ddahl survey)

<ddahl> Crypto API Survey: https://docs.google.com/spreadsheet/viewform?formkey=dHZ2aGw0YVRvRXVnN0d2bjFGR2FlN1E6MQ

ddahl: a lot of different things have come up as far as algorithms, and how this API is going to work, and the different intricacies of what we're trying to do,
... so I created a survey that at least the members of the working group could fill out, and also pass it on to other interested parties.
... some folks within Mozilla will fill it out and also perhaps give us some more in-depth use cases.
... at least figure out what to attack first and get our focus going on what we're trying to do in this working group.

virginie_galindo: this is also a conversation that is going on on the mailing list.
... please be as accurate as possible on the context of how you would use this API
... ... such as who are the users who are using this API.
... Don't hesitate to be narrative in your answers.

ddahl: If you see any questions missing from this survey, please send them to me and/or to the list and we'll consider adding them.

Who's speaking?

<hhalpin> PROPOSAL: Next week for adding questions to the survey

virginie_galindo: what was the deadline you proposed?

cool

<fluffy> yes, that was me

fluffy: one week deadline would elicit perhaps 5 responses, if you want 50 responses then perhaps a farther deadline.

I'm sorry, I didn't understand what you just said, virginie_galindo.

<ddahl> hhalpin ++

<virginie_galindo> virginie_galindo : proposing to have answers from the wg participants

<hhalpin> one week for editing the survey to add questions, then one month for answers

Dang, who said that about a month. I suck at scribing.

someone: maybe give it a week to get review for the survey, and then maybe a month for people to fill it out.

virginie_galindo: Since next Monday is a holiday in the U.S., let's give us two weeks.

<hhalpin> RESOLUTION: Two weeks to review survey, then one month after that deadline to collect all answers

virginie_galindo: The sooner would be the better to answer the survey.

<virginie_galindo> +1

<ddahl> +1

<fluffy> +1

<hhalpin> +1

+1

<vgb> +1

<emily> +1

<wtc> +1

<sdurbha> +1

<JimD> +1

<christopherkula> +1

<hhalpin> RESOLVED: Two weeks to review survey, then one month after that deadline to collect all answers

virginie_galindo: what is going to be the list of algorithms and how is it going to be reflected in the API.
... ... ?

<wseltzer>

wseltzer: http://lists.w3.org/Archives/Public/public-webcrypto/2012May/0066.html

Zakim: who's speaking?

Zakim: who's making noise?

hhalpin: I'm trying.

wtc: the microsoft proposal is informal.
... the algorithms included are all very common.
... I see no problem with it.
... it includes the older RSA PKCS 1 1.5 standard.
... some of these algorithms haven't been implemented in the NSS library used in Firefox and Chrome such as OAEP and GCM.
... But, it would be easy to fix that, so that shouldn't be a deterrent.

ddahl: wtc had a concern about not supporting older algorithms such as SHA-1 because of backwards compatibility needs.
... Other folks had said that it was dangerous to specify weak algorithms.
... Running on a parallel track with IETF JOSE
... would be a good idea -- they are making good specifications.

Thanks, wseltzer.

Does Zakim mute people who haven't enqueued?

virginie_galindo: do we have a resolution on this?

ddahl: It seems like the resolution is to accept the Microsoft proposal, with possible modifications. I don't know if that's a formal acceptance...
... It may be simpler for us to do this informally, and then have the editors try to check it into the spec.

+q

<rsleevi> +q

Can you hear me?

I seem to be muted.

<hhalpin> zooko: including a particular algorithm such as SHA1 would not be sufficient to interop

<hhalpin> ... if we are committing to do this interop, that's cool, but I need to figure out what that requires in our spec

<hhalpin> ... and if we're not, then we don't need to include older, weak algorithms in the spec

<rsleevi> sorry

<ddahl> q_

Sorry, I didn't understand ddahl.

The IETC specs don't include what?

emily: Which algorithms to implement is tied up with the question of what level of API we specify.

That's an excellent point.

emily: Did we decide on a level of the API?
... Because it seems like if the level of the API is something that doesn't require people to choose an algorithm, then this isn't even something that needs to be decided.

ddahl: We haven't decided. It's up in the air. I have the feeling we're going to do a lower-level API, but it isn't decided.

emily: I had one other question about interoperability.

<hhalpin> my guess is that people will need *some* choice, although we can have some simplified version of the API

emily: An easier type of interoperability that we might want to consider is allowing people to reimplement the Javascript that they're already using with this API.
... So if they're already using a 3rd party Javascript library then we would want them to be able to reimplement to use this API without changing the algorithms they're using.

ddahl: That's a valid concern. We haven't touched on this yet. We should keep that issue open as we move forward.

rsleevi: We've been talking about weak algorithms and the possibility of interoperating with weak algorithms such as SHA-1.
... How far will we go, such HMAC-MD5?
... HMAC-MD5 is weak but not broken, where MD5 as a hashing algorithm is broken.
... Do we consider standardizing both weak and broken?

virginie_galindo: Are there other algorithms that the group will have to take a position on?

rsleevi: Yes, DES, 3DES.
... If the group takes a position that we don't want to implement broken algorithms, what will that mean if SHA-1 has its final death now.
... Will it be valid to require implementations to remove support for that, or would we take a position that we maintain broken algorithms for interoperability.

virginie_galindo: This is also linked with the discussion that we have to have about the discovery mechanism.
... Will an application be able to discover which algorithms are available in the system it is running in?
... Will we mandate a specific core?
... If we say that everything is optional, then nothing prevents an implementor from implementing a weak algorithm.

rsleevi: I do think a discovery mechanism can address a lot of these points, whether high-level or low-level.

sdurbha: Who chooses which algorithm to use, whether to choose a weak or a strong algorithm. Is it the user of the API, or is it the browser itself saying "Hey you shall not use a weak algorithm."?

virginie_galindo: There are some algorithms for which state organizations are saying that they don't want to use certain algorithms and they deprecate its use.
... For example, if we decide that HMAC-MD5 is not recommended or even black-listed as it were, we can recommend not to use it.

sdurbha: Would the API communicate to the developer, Hey beware of this weak algorithm?

virginie_galindo: We may be able to have some comments about the different algorithms which are supported by this API.

+q

<hhalpin> zooko: despite being deprecated by HMAC-MD5, it is very common

<ddahl> I think we will be able to make recommendations via the spec and I think browser vendors can add warning logging that notifies consumers of the API

<hhalpin> ... so we should communicate

<hhalpin> +1 ddahl

<hhalpin> zooko: a namepsace to sequester known bad algorithms

hhalpin: I suppose Zooko's suggestion of namespacing, and also ddahl's suggestion on IRC (of implementations logging warnings that notifies consumers of the API).
... In the spec itself you could have a "Hey don't use this" sequestered namespace.
... Or, you could say "Using algorithms in this sort of sequestered namespace should throw an error or a warning to the developer".

<ddahl> window.crypto.broken.md5() :)

☺

hhalpin: Do people think that's a good idea? That might be one way out of this -- we can get interop but throw warnings when crypto is weak.

christopherkula: It seems like we shouldn't be defining new APIs with broken crypto.

vgb: The whole sequester idea kind of concerns me, because we write the spec at
... this point in time, and the spec lives on forever
... and you create situations where somewhere down the road some people think SHA-2 is broken and other people don't.
... Let's say SHA-256 is broken tomorrow

+q

scribe: maybe I still have shared data that I need to read.
... It isn't clear that such warnings would be (a) consistently implemented, or (b) actionable by the person who sees the warnings.

<ddahl> vgb: good point

(Sorry, I missed someone's contribution about people using MD5 and we'll let them.)

rsleevi: Until we're able to make a cut from some of this legacy baggage, we'll still see protocols with MD5 or other weaker constructs.
... I'd like to avoid even namespacing and say "Well you shouldn't really, but we'll let you do it."
... browsers may enable users to configure algorithm support.
... users, e.g. state agencies, may decide something is broken from their perspective, and they can remove support ahead of when browsers remove support.

virginie_galindo: Here is my proposal.
... We are going to integrate all the algorithm inside the API.
... After that we may discuss removing an algorithm for some reason or other.
... Let's put everything and remove it on a case-by-case basis.

<sdurbha> +1

<hhalpin> PROPOSAL: Get the editors to try to integrate the entire list of IETF algorithms into the spec, and then delete on case-by-case basis via WG feedback

hhalpin: Get the editors to integrate the entire set of algorithms, and then eliminate on a case by case basis.

<ddahl> +1

<vgb> +1

-0

:-)

hhalpin: Some of the cases may be clear cut.

Sorry, what's this list of IETF algorithms?

I've seen the Microsoft proposal.

<hhalpin> http://lists.w3.org/Archives/Public/public-webcrypto/2012May/0066.html

<christopherkula> +1

<ddahl> zooko: JOSE algs

virginie_galindo: the list of IETF algorithms is the one given by Microsoft in the mail.

<hhalpin> RESOLVED: Get the editors to try to integrate the entire list of IETF algorithms into the spec, and then delete on case-by-case basis via WG feedback

<emily> but if we do the msft proposal and then delete from it, then we're excluding SHA1?

<ddahl> zooko: i think it is also about how to refer to commonly used algs

<wseltzer> [I believe the algorithm list comes from https://www.ietf.org/id/draft-ietf-jose-json-web-algorithms-02.txt ]

<hhalpin> emily, I think we begin with including SHA1 and then argue it over :)

I no longer want the floor, Zakim. Leave me alone you bot.

Thanks, wseltzer!

<hhalpin> probably in the mailing list, and then via a WG vote

<ddahl> emily: there is still an open issue of adding additional algs specific to Web Crypo API

Sorry, what did virginie_galindo just ask?

<emily> hhalpin, ddahl: got it, thanks :)

<virginie_galindo> http://lists.w3.org/Archives/Public/public-webcrypto/2012May/0074.html

virginie_galindo: We have a proposal about how the web app is going to use the API. Is it going to discover each algorithm, or is it going to know that there is a set of algorithms implemented?

<hhalpin> I think the topic is how the algorithm can do discovery

virginie_galindo: What is the process for the application to decide how to run.

<hhalpin> of algorithms

+q

<hhalpin> as some platforms may not support all algorithms

virginie_galindo: It could be a combination of two -- get the complete set of algorithm lists or ask about a specific algorithm.

sdurbha: There should be a good set of algorithms that MUST be implemented.
... Not like the early browser implementations where all the support was widely different.
... The work that we do here should be reliable for implementations.
... So they don't have if then else conditions in their code.

<hhalpin> zooko: really good point

<hhalpin> ... we should have a core set of algorithms a coder can rely on

<hhalpin> ... if we can look at what algorithms are present, then we aren't dealing with a higher-level API

<hhalpin> ... on the highest level the coder should not be aware of what algorithms are being used at all

hhalpin: It's sort of a chicken and egg issue.
... We're going to have to specify a core set in order to specify a high-level API.
... I agree with sdurbha's point that we need a core set that all the browsers support reliably.
... That's the entire point of doing this at W3C, to allow that set to be reliable by web authors across browsers.
... There could also be a higher-level shim that chooses algorithms.
... Most web apps don't use crypto, because it is confusing and don't feel competent to choose.
... My guess is that we'll have to choose a core set first, make a test suite around that core set, and then make a higher-level developer-friendly shim.
... So they aren't mutually exclusive.

rsleevi: I disagree that we should have some mandatory to implement.

<ddahl> zooko: i think the box/unbox high-level API will be better written in content JS

rsleevi: When you have a core minimal set, algorithm agility is placed secondary or tertiary or not even considered

That's an excellent point, ddahl. Shall I enscribe it?

<ddahl> zooko: please do

rsleevi: Algorithm agility is going to be an important part of security.

ddahl: The high-level API will be better written in content JS.

rsleevi: If we say that all browsers must implement, say, SHA-256, then web developers are going to code to SHA-256.
... If we get to the point that SHA-256 is broken, that's going to be a significant engineering effort.

ddahl is awesome for writing domcrypt.

vgb: There are always two ends to these transactions.
... If we don't have a core crypto set, and even more details such as AES-GCM supported tag elgnth, and so on,
... then we end up with a de facto supported set anyway.
... People write their services based on what they know is implemented in every client.
... We are going to get in this position anyway, just due to the inherent interoperability need of two parties in every transaction.
... With regard to the point that if you have a high-level API, you don't need algorithm discovery,.
... You still do, because when you receive it you have to know "Can I decrypt this?"
... We should probably drive this more from the use cases.

<Zakim> wseltzer, you wanted to ask about the fingerprinting risks from making algorithms discoverable

<wseltzer> [I don't seem to be able to unmute]

<wseltzer> e]

<ddahl> vgb: the nice thing about the JOSE standards is that you get back a JSON object that I think will describe how the blob was encrypted

<wtc> ddahl: the output of your high-level crypto API will also needs to encode the algorithms used and even the version of the format.

fluffy: The point of standards is that people want to write something that they know will work on all the browsers.
... I as a developer will be forced to look at the four major browsers and choose whatever is common among them.
... Which may mean what's the worst security among the four major browsers.

<ddahl> wtc: I imagine it would as you may be decrypting via server software, correct?

emily: Should we specify a core set of functionality rather than specific algorithms.

<wtc> ddahl: not necessarily. Could also be output generated a long time ago by an older version of the browser.

emily: So there could be a high-level API that would have to be implemented, with box/unbox type functionality.

<wtc> ddahl: even different versions of the same product would run into this problem.

emily: But, per fluffy's point, people may have to code to the most available algorithms anyway.

Keyczar has done a lot of work on trying to do that high-level API stuff: http://www.keyczar.org/

<wtc> zooko: yes.

hhalpin: Maybe the solution would be, since there hasn't been this sort of debate about high-level vs. low-level ...
... If the algorithm is so high-level that the low-level is not really specified at all, then there's a coordination problem.
... So maybe include a sort of core set that any product implements them
... And then have a high-level API that chooses the best.

The process of versioning for new improved algorithms could be new revisions of the standard.

web-crypto 2012 is RSA-OAEP-AES-128-GCM-64, web-crypto 2014 remains to be determined...

hhalpin: It is better to make one that lasts a few years at least.

<hhalpin> just to clarify, the discovery problem is hard

<hhalpin> and the W3C tends not to want to maintain registries

virginie_galindo: We will continue to have both low-level and high-level functionalities anyway.

<hhalpin> but if the WG has a good proposal for this

virginie_galindo: And that we have a good evolution of our specification to take into account algorithms broken over time.

<hhalpin> and there seems to be sufficient interest to maintain a registry, I think the W3C could be convinced.

<ekr> FWIW, this "Algorithms broken" thing seems to me to be getting rather more attention than it really needs.

draft API discussion

random number generation

<ekr> After all, it's *still* not the case that there is no use for MD5, for instance.

<hhalpin> the situation with HTML5 doing random number generation

<hhalpin> what is already in HTML domain is enough

virginie_galindo: We heard two sounds on the mailing list -- some people saying what's described in HTML is enough, others no.

<hhalpin> while others were worried it was not robust

hhalpin: It wouldn't make sense to specify RNG in multiple W3C working groups.
... Is there any weakness or problem in the HTML5-specified RNG?

<ekr> If there is a weakness in the HTML5-specified RNG, then we should fix it, rather than replicate it.

rsleevi There wasn't a working group at the time, which is why the RNG was specified.

<hhalpin> My question was whether or not there are any known weaknesses there, and if not, we should just re-use

<hhalpin> if there are, we should push HTML WG to fix it rather than make a new RNG method

<hhalpin> but from a standards perspective, there are no issues with re-using something from HTML5 WG in this work, and referencing it from our spec

<ddahl> i think we should just re-use as this API method is already inside the crypto object

hhalpin: Is there any reason to believe there's a problem in the RNG?

ddahl: If you're talking about the implementation, that's a completely different question, but I don't see any problem with it at all.
... I implemented a patch for Gecko which implements it, just using "get random" from NSS.

ekr: There is a use that this API can't support which is to generate a random number that cannot exit the security boundary.

<wtc> ekr: the crypto API will have a GenerateKey function to do that.

Group Logistics

<hhalpin> http://www.doodle.com/ax642viksxhqdt85#table

<ekr> wtc: I'm fine with that.

<virginie_galindo> PROPOSED RESOLUTION : the regular call will be held every Mondays @ 19:00 UTC.

<hhalpin> tommy, emily, and mitch

<hhalpin> nat sakimura and others in Far East

<hhalpin> tommy

<hhalpin> is OK with after next week

<hhalpin> I'll send an email to Nat and the members from China/Japan/Korea

<wseltzer> virginie_galindo: Next call in two weeks

hhalpin: next call is in June. June 4.

<hhalpin> RESOLUTION: Skip next week, next call is June 4th

<rsleevi> I will not be able to

I can't attend.

<emily> -1

<fluffy> -1

<hhalpin> RESOUTION: Next call June 4th 15:00 UTC

<ddahl> +1

<hhalpin> +1

<vgb> +1

<virginie_galindo> +1

<wtc> +1

<emily> I probably won't have funding for a face to face meeting, unless its in SF or Boston

<hhalpin> It seems quite a few people can make it - and don't worry for IEs, we understand quite a few do not have funding for f2fs so that will not be held against.

virginie_galindo: How the editors of the API are going to work on new editions?

<hhalpin> public bugzilla or member-only bugzilla

<ddahl> hhalpin: public comments are ok

<rsleevi> Are there any IPR issues for non-members to comment on the bugzilla?

<wseltzer> any objections to a public bugzilla?

<hhalpin> wendy - are there legal issues re comments on the bugzilla from non-members?

<hhalpin> RESOLVED: Let's say its public unless the lawyers say otherwise for Bugzilla

<ddahl> virginie_galindo: +1

<hhalpin> Editors draft is essentially edited by the editors without approval for every change

<hhalpin> then the Public Working Drafts are published after approval by the WG

<hhalpin> so there's two versions of the API usually at any given time until we get to end of Last Call.

<hhalpin> Meeting Ending

<wseltzer> Thanks zooko for scribing!

<sdurbha> that is me, I guess (??PO)

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/ddah/ddahl/
Succeeded: s/IETC/IETF JOSE/
Succeeded: s/forwardf/forward/
Succeeded: s/?\/?/
Succeeded: s/leasdt/least/
Succeeded: s/@@/rsleevi/
Succeeded: s/NSS,./NSS./
Found Scribe: zooko
Found ScribeNick: zooko
Present: JimD Tommy christopherkula ddahl ekr emily fluffy hhalpin inserted rsleevi sdurbha someone timeless tjr tl1 vgb virginie_galindo wseltzer wtc zooko
Regrets: EKR
Got date from IRC log name: 21 May 2012
Guessing minutes URL: http://www.w3.org/2012/05/21-crypto-minutes.html
People with action items: