Web Cryptography Working Group Teleconference -- 20 Oct 2014

<trackbot> Date: 20 October 2014

<selfissued> It was me - I'm muted now

<harry> scribe: Karen

<selfissued> And Mike

<rbarnes> and all i know about IETF errata is that i always mark them "rejected" :)

<bal> FYI, I will only be able to stay on the call for the first 30 minutes

<rbarnes> harry: my proposal was just for a box where you would link to the updates. i don't care if you put stuff in the box with errata, full WG process, or an IANA registry

<Karen_> virginie: one bug left: extensibility

<harry> there's still some debate going on re the mailing list

<harry> but I think rbarnes has a proposal, Microsoft has some concerns, and then the CFRG might end up wrapping up with a decision before we get out of Last Call.

<Karen_> virginie: status of web crypto API

<harry> we could go for extensibility bug first for the fun of it

<Karen_> ... we made status of the bugs

<harry> Note re the infamous "Rich Salz security considerations bug" Graham should ship a doc to CFRG quite shortly.

<Karen_> mark: extensibility, implemented proposal from Richard

<harry> If he doesn't do it, I'll do it on his behalf. It will just be an Informational Note that is basically his blog post with some padding for everyone on CFRG to discuss.

<virginie> Note : the list of bug is available here : https://www.w3.org/Bugs/Public/buglist.cgi?quicksearch=web%20crypto&list_id=45901

<Karen_> ... implemented a couple of proposals

<Karen_> virginie: 15 bugs open, most of them have been discussed

<Karen_> richard: algorithm alias - string name map to object name

<rsleevi> 24878

<rbarnes> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24878

<Karen_> mark: should be easy to implement, just have to make a decision

<rsleevi> there was consensus on the list previously

<rbarnes> actually, i think it was ryan's proposal :)

<Karen_> virginie: no objection.

<harry> The rest of them seemed sensible - I think Ryan is right re HMAC key length being larger than block size

<harry> so that should just be closed as a "WONTFIX"

<harry> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26950

<Karen_> ... any bug that deserves attention?

<harry> Yeah, that one should be closed - no reason to restrict key length to output length

<wseltzer> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25815

<rbarnes> without looking up the references, i can live with closing that one

<rbarnes> ryan looks right enough :)

<Karen_> 26950

<rbarnes> where "that one" == 26950

<Karen_> mark: 25815

<harry> I'm no expert there but it seems that if one had plaintext and one wanted key, keeping key longer than output of hash seems sensible.

<Karen_> sorry I cannot follow this :(

<harry> Basically, Markw is normalizing the error codes

<wseltzer> mark: Should we say import/export will always report DataError

<Karen_> mark, can you briefly enter your comments?

<harry> As long as we don't have separate padding errors :)

<Karen_> mark: can implement change

<wseltzer> Virginie: No objection

<rsleevi> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26950

<Karen_> harry: may be Ryan can explan on 26950

<markw> The objective of the bug (25815) was to ensure that validation errors on import/export all return the same error so that there is no requirement on UAs to distinguish error cases themselves - they are free to delegate checking to libraries

<rbarnes> ack

<markw> s/big/bug (25815)/

<harry> Does everyone agree with Ryan this should be a WONTFIX?

<markw> Almost all cases for import/export are already normalized to DataError, so my proposal is to standardize on that, rather then OperationError for import/output

<Karen_> Ryan: comment 3 was intentional text

<Karen_> ... to generalize hmac construct

<Karen_> ... to have max security strength

<Karen_> Richard: no point that the extra security going over the hmac length

<Karen_> Ryan: if you to generate a hmac key of L,it will not be the max security. see reference

<Karen_> virginie: this bug is not a problem?

<Karen_> Richard: no

<harry> So just chime in on Bugzilla and it will be a WONTFIX

<Karen_> virginie: you read the document and we have it resolved.

<rbarnes> of course, i have no idea what the process requirement is for exiting LC. but i'm not going to object.

<Karen_> virginie: mark - can you give a short description on where we are on making a agreement?

<virginie> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25618

<Karen_> mark: where need extensibility

<Karen_> ... add note saying so and reference

<Karen_> mark: cleanup exten for EC

<Karen_> ... need - format of the private key

<Karen_> virginie: everyone agree with Mark?

<Karen_> ... let's do a formal vote

<markw> Changes based on Richard's proposal have been implemented. Extension specifications will be explicitly listed in the specification - list to be updated with Errata. No longer possible to completely override existing algorithms. New hash algorithms can be added. EC curve extensisbility inteneded to allow a variety of new curves, not just those that align with NIST ones.

<Karen_> ... for extensibility

<wseltzer> PROPOSED RESOLUTION: If you're happy with Mark's proposal, +1, if not, -1

<harry> I think the idea is to avoid "monkey patching"

<wseltzer> trevp: does this resolution make it more difficult to add new algorithms as a new spec?

<wseltzer> markw: you can still add new algorithms

<Karen_> Mark: we can still add new algorithms

<harry> bal, before you leave could you type in IRC whether or not you agree with Richard's "forward reference" solution re errata updating?

<harry> bal: They are assuming an uncompresssed for same IPR reasons everyone else does

<Karen_> sorry, the line is off for me...

<harry> ... for PKCS#8, that's already taken care of

<markw> One remaining change is necessary to make the format of private EC keys defined by the extensions specification (currently it is asymmetrical: import assumed ECPrivateKey but export does not - or vice versa. Needs to be symmetrical, without the assumption).

<Karen_> can some scribe?

<wseltzer> [bal and rbarnes leave, after saying this solution is fine with them]

<rbarnes> +1

<harry> self-issued: Is this an explicit decision to not use compressed curves?

<harry> trevorp: It's just unclear where you put it - would you put it in x co-ordinate

<harry> ... but yeah, we can deal with that later

<harry> scribe: hhalpin

<Karen_> I am back

<harry> virginie: Would your common be objection?

<harry> trevor: I think some details need to be fleshed out

<harry> ... but we can anticipate a lot of things

<harry> ... but dont want to preclude ourselves

<harry> selfissued: discussions here won't change that

<Karen_> mike: you should review JOSE draft 35

<harry> selfissued, please type up your point

<selfissued> If you have concerns about the JWK langauge, you shoudl review the -35 draft

<selfissued> And send comments to jose@ietf.org

<selfissued> Disussinos here won't change JWK

<Karen_> harry: don't think it is a blocking bug

<selfissued> But I don't think there's anything blocking WebCrypto from proceeding in JWK

<Karen_> ... can fix in JWK in future

<harry> i.e. we can specify that in the extension spec

<harry> and that we should clarify this with JWK

<Karen_> Travor: I am not rejecting anything, just want to make sure extension is possible

<harry> so I don't think its blocking exiting Last Call per se

<selfissued> There was an explicit JOSE working group decision not to use compressed point representations

<Karen_> ryan: compressed point is not supported in the spec

<Karen_> ... the spec is going to be a living one

<Karen_> ... if is need for compressed curve, we consider

<virginie> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25618

<Karen_> Virginie: any objection to mark's proposal?

<Karen_> ... Ryan and Richard agree

<markw> +1 (on the basis that we fix the one remaining change to make the format of private EC keys defined by the extensions specification.)

<selfissued> +1

<vgb> +1 to closing with Mark's proposal (regarding one more small change he needs to make)

<kodonog> +1

<Karen_> +1

<MichaelH> =1

<MichaelH> +1

<wseltzer> [+1 is "no objection"]

<harry> Trevorp: 0 (abstain)

<vgb> i believe bal and rbarnes expressed +1 before leaving

<Karen_> Virginie: agree to exit last call?

<markw> +1

<kodonog> +1

<Karen_> ... we can leave 2 weeks for people online

<harry> We should go over the errata discussion real quick

<wseltzer> PROPOSED: Exit last call

<Karen_> mark: let people on the call to vote or talk

<harry> Basically, the answer is "yes" we can update errata re forward references

<markw> +1

<harry> If people want to delve into errata management, I'm happy to do that.

<vgb> +1

<wseltzer> [with the understanding that this decision will go out on the mailing list for the next two weeks, per usual WG practice]

<kodonog> +1

<Karen_> +1

<MichaelH> +1

<wseltzer> RESOLVED: Exit last call, after confirming on mailing list

<harry> ACTION: hhalpin to create Last Call Exit request document [recorded in http://www.w3.org/2014/10/20-crypto-minutes.html#action01]

<trackbot> Created ACTION-148 - Create last call exit request document [on Harry Halpin - due 2014-10-27].

<Karen_> virginie: thank you everyone for making the efforts

<Karen_> ... F2F meeting on 10/30th

<Karen_> ... agenda: webcrypto roadmap, key discovery

<Karen_> ... may be news of security recommendation from IETF

<Karen_> ... tools, respository

<Karen_> ... debrief of the workshop in Sept and rechartering

<Karen_> wendy: web app security WG is also re-chartering and interested what items will fit between groups

<Karen_> ... credential API

<Karen_> ... I will help to coordinate

<Karen_> virginie: anything else?

<Karen_> Wendy: thank you virginie and everyone! next step would be implementation and testing

<Karen_> mark: multiple implementations exit already

<Karen_> wendy: yes, we need to test them to get a uniform platform

<harry> thanks everyone!

<Karen_> bye

<harry> trackbot, end meeting

- DRAFT -

Web Cryptography Working Group Teleconference

20 Oct 2014

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output