See also: IRC log
<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
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Data Error/DataError/ FAILED: s/big/bug (25815)/ Succeeded: s/bog/bug (25815)/ Succeeded: s/Travor: +1// Succeeded: s/list,/list for the next two weeks,/ Found Scribe: Karen Found Scribe: hhalpin WARNING: 0 scribe lines found (out of 276 total lines.) Are you sure you specified a correct ScribeNick? Scribes: Karen, hhalpin WARNING: No "Topic:" lines found. Default Present: +1.415.373.aaaa, +1.650.275.aabb, rsleevi, hhalpin, Karen, karen_oDonoghue, Virginie_Galindo, rbarnes, selfissued, Wendy, bal, trevp, vgb, markw, Michael_Hutchinson, +1.703.948.aacc Present: +1.415.373.aaaa +1.650.275.aabb rsleevi hhalpin Karen karen_oDonoghue Virginie_Galindo rbarnes selfissued Wendy bal trevp vgb markw Michael_Hutchinson +1.703.948.aacc Found Date: 20 Oct 2014 Guessing minutes URL: http://www.w3.org/2014/10/20-crypto-minutes.html People with action items: hhalpin WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]