<trackbot> Date: 29 September 2014

<wseltzer> [the call is in one hour]

<rbarnes> i'm on the way

<inserted> scribenick: harry

<scribe> scribe: hhalpin

Virginie: Welcome everyone
... we'll review the bugs with the editors
... then try to make formal decision to exit last call
... just to clarify, as regards rsleevi's call
... we'll have two weeks notice for opposition to the mailing list
... we'll also discussion decision for next steps
... and our f2f meeting
... discussion over deliverables of v.Next workshop 3 weeks ago

[roll call]

review of bugs by editors

bug review

<markw> https://docs.google.com/spreadsheets/d/1rpc7Q7o4nxoKjYT8Qx4MhueQ-rUuIIM53yp7miUuxnw/edit?usp=sharing

markw: extensibility approach

<markw> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#rsa-oaep

markw: so basically we went over two areas
... how we might do extensibility
... for example, adding hash algorithms

wseltzer: Are we all looking at the same list?

<wseltzer> "recent changes" tab

markw: Changes are in reverse order of time fixed
... for RSA-OEAP, how do you add a new hash algorithm?
... how could they add that hash algorithm without monkey-patching
... making changes so that people have no ideas what will happen in future
... we will instead give future extension points that are explicit
... as far as things go
... where it comes in first is "import key"
... see Annevk's post on the list
... other specs may specify use of additional hash algorithms

<rsleevi> I don't understand how this addresses extensibility

<rsleevi> you never make to step 3, do you?

markw: we say other specs can specify additional procedures and insert them into import procedures

<rsleevi> This seems to allow some other specification to wholly replace the import steps

<rsleevi> e.g. bypass steps 3+

<rsleevi> which doesn't seem desirable

<rbarnes> rsleevi: step 3 of which procedure?

<rsleevi> I was trying not to queue so that we can make progress on this call, while still raising the concern so that we can carry on

<rsleevi> Step 3 of Import Key ( https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#rsa-oaep )

if you know what to do rsleevi, do tell us!

<rsleevi> the current Step 2 language is equivalent to saying "Any other spec can wholly replace this section"

selfissued: "Other specifications" are the keyword, other specs in the algorithm in section 20, where I expected it to say "other specs may define new algorithm names", I didn't see that. Did you say it using different words?

<rbarnes> i think i'm +1 to rsleevi here. we don't need to provide forward references here -- wherever there's a list of fixed strings, there's an extensibility point

markw: I don't think you need to say anything cause we already have the algorithm string here

selfissued: I'd just suggest repeating the same language

markw: I'll file a bug and do that.

rsleevi: So I have some concerns with this approach
... any other spec can redefine the RSA-OEAP key *entirely*

which is pretty concerning for me

rsleevi: Could we move the step to "importKey" to the concrete extension points within the spec
... so if you move it to step 3
... there's a place, if we match all the way to step 3, then we can constrain the other specs
... so we don't have to respecify other specs entirely

<rbarnes> +1 to ryan

rsleevi: there are things we don't think into a parameter
... for example, SPKI and JWK

<rsleevi> I'm not sure where you're talking about "says up above" mark - https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#dfn-applicable-specifications is a dead link

maekw: it is intention that we can constrain that explicitly
... embedding the other points
... you have to make a tradeoff
... my preference is constraining not in the future
... implemeters come after users and authors

rsleevi: forward references is not quite what we want
... we want to be pretty careful here
... I'm not quite sure where want your concern is
... for example, we can decode parameters
... an algorithm id and an algorithm id object
... so I don't see your concern re the extension ball
... for example, step 3.7 - if you have that, everything else
... in general, concerned about forward references

<rbarnes> i agree with everything ryan just said

selfissued: I'm not concerned about forward referenes
... we should have parameterized hash fucntions in the future

markw: We had a long discussion on the list about htis
... re embedding, I think its fine

<rsleevi> I think writing it in the spec shows how it doesn't really work

<rsleevi> So I think we should be flexible to change

markw: we are already constraining extentesibility

rsleevi: I'm OK with continuing discussion with TAG
... so we are not really OK with this and our API design goals
... with blanket exceptions to exceptions

markw: Which API design goals?

rsleevi: Annevk said it - on forward references
... on the list.
... best solution on the discussion on the list.
... TAG might object

<rbarnes> i'm pretty much in agreement with annevk. not happy with forward references, but probably not sad enough to object.

harry: Sounds like a blocking to Last Call to me
... is it?

rsleevi: Haven't had chance to review the last edits
... no firm comments
... this alone is enough to raise concerns about last call
... the explanation is very valuable to last call

<selfissued> Yes, please keep going through the list

I basically think we should keep go through list

and see how far we can get consensus, and then try to move to Last Call

even if we can't get to it next week

virginie: Sounds good. Would like a definite proposal by next week?
... is that feasible by rsleevi?

rsleevi: Assuming whole internet doesn't break like it did last week, sure.

<markw> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#ecdsa

markw: A different kind of extensibility, extensibilty as regards EC curves
... possibility to add addition EC
... allow different specs to define sig, etc.
... for example, in sig steps
... if its one of the curves we define in our spec go with our spec, otherwise we follow those in other spec
... likewise for any spec

<selfissued> Sounds good to me

markw: for importkey/exportkey, back to previous issue

<selfissued> We shouldn't be taking time now discussing hypotheticals. When there are actual proposed language changes, we should discuss them then.

<markw> This is what the cloning thing says: https://dom.spec.whatwg.org/#other-applicable-specifications

<rsleevi> selfissued: This isn't a hypothetical

<rsleevi> The current spec is hypotheticals

<selfissued> It is hypothetical until there's a concrete proposed alternative language

<rsleevi> vgb: I like the ECDSA section more, as an implementor, because it reads better

<rsleevi> vgb: Question for Ryan, would you be satisfied with just an appendix that listed other specifications

<rsleevi> vgb: Question to Mark, ???

<vgb> vgb: one comment and 2 questions

<vgb> ... comment: i like the ECDSA approach a little more than the OAEP one, it reads cleaner

<vgb> ... question to Ryan: If we simply had a list of "applicable specifications" in an appendix (not the text itself, just references), would this satisfy your objection?

<vgb> ... question to Mark: Why doesn't the consideration about parametrized hashes apply to ECDSA?

<virginie> I suggest we actually create an action for each of the answer expected by each of the parties here, with deadline to answer next friday

<selfissued> The problem with an appendix listing other specifications is that keeping that up to date requires updating the main specification every time an extension spec is created. That's not a reasonable or scalable approach.

<rsleevi> vgb: the SPKI encoding of an EC key does not constrain the hash algorithm

<rsleevi> whereas the SPKI encoding of an RSA-OAEP key MAY constrain the hash algorithm

<rsleevi> (now, NIST specifications say you should only use hash X with curve Y, but that's not part of the core ECDSA op)

<rsleevi> so you could use a different hash alg with a single ECDSA key

<rsleevi> whereas with RSA-OAEP, SPKI/PKCS8 can prevent this

<rsleevi> virginie: I'm not scribing, I'm responding

<rsleevi> Bug 35382?

<MichaelH> 25382

<inserted> scribenick: wseltzer

markw: Add text to return an invalid access error
... skipping the less controversial ones

<vgb> @rsleevi: actually there is an algorithm OID for ecdsa-with-SHA1 and so on. you don't have to specify the hash in the SPKI, but you could

markw: cleaning up which error type was used
... a few re parameter validation
... In some cases, we explicitly validate params, in some cases we don't
... Validation error vs data or syntax error

<rsleevi> @vgb: Well, those keys aren't currently supported in the current draft :)

markw: Ryan has pointed out that if delegated to crypto library, don;t know why it failed
... So should just return operation error
... 25741

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

<MichaelH> 25741

<virginie> example 25741

<vgb> @rsleevi: then why not do the same for OAEP :)

<rsleevi> I have no feedback to offer, as I have not reviewed any of these changes

<virginie> question is what do you think about that bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=25741

markw: proposal, use operation error for all param validation errors

<rsleevi> @vgb: I think it's more of a bug with our current SPKI import code that it chokes on the ecdsa-with-* foo OIDs. Of course, this would make the ECDSA code the same problem as the OAEP code :)

<markw> @rsleevi: this is not changes, this is a question of principle as to what error is returned when there are parameter validation changes

<markw> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25741#c3

vgb: every time you make a call to underlying crypto library, you should expect informative error
... but if you want to check formatting before making the crypto call, that's bad

markw: but there are places we do param checks before calling crypto
... we could rip them all out
... but then we'd need to check the references
... Or, we could say they all return operation error
... and leave flexibility to the implementor to delegate to crypto library

vgb: sounds fine to change to operational error

israelh: concern that not providing enough info the library is useless in diagnosis
... how much granularity do we want to provide?

markw: If we specify different errors, then we're assuming crypto libraries expose that info, or requiring the UA to do the checks
... or you'd get different results on different platforms

israelh: On indexdb we have "unknown error," and that's not very useful

vgb: on this list, all are "check length"
... would we be forcing them to add extra length-checking?

markw: Please look at these bugs on error reporting

virginie: could you please start a mailing list discussion, Mark?

markw: sure

virginie: anything else you want to highlight?

markw: Look at the recent changes tab, the changes I made last week
... most of those are straightforward
... Think we've resolved in principle security considerations;
... we discussed extensibility here
... make keys non-extractable by default (25721)

virginie: We have been suggesting to WG that we'd try to exit LC today
... we'd like to get there
... Please make sure your orgs have enough bandwidth to review remaining bugs
... Do you have time this week?

vgb: I've been working to spin up again

rsleevi: I said I'd look through Mark's 39 changes and provide feedback by Friday

virginie: Deadline for text proposals to change is Friday
... Propose another call 13 October, 2000 UTC

<virginie> 13th of oct would be the call for trying to exit last call

virginie: fallback, 20 October

<virginie> unless opposition to the date on the coming 2 days

Virginie: F2F at TPAC, 30 October
... please register, http://www.w3.org/2014/11/TPAC/
... more discussion on the list

<selfissued> bye

[adjourned]

trackbot, end teleconf

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/scribe: rsleevi//
Succeeded: s/assume/expose/
Succeeded: i/invalid access error/scribenick: wseltzer
Succeeded: i/scribe: hhalpin/scribenick: harry
WARNING: No scribe lines found matching ScribeNick pattern: <hhalpin> ...
Found ScribeNick: harry
Found Scribe: hhalpin
Found ScribeNick: wseltzer
ScribeNicks: harry, wseltzer
Default Present: +1.503.712.aaaa, +1.512.257.aabb, virginie, Michael_Hutchinson, Wendy, Matt_Wood, +1.650.275.aacc, rsleevi, vgb, selfissued, markw, hhalpin, +1.434.941.aadd, rbarnes, nvdbleek, israelh, +1.503.528.aaee
Present: +1.503.712.aaaa +1.512.257.aabb virginie Michael_Hutchinson Wendy Matt_Wood +1.650.275.aacc rsleevi vgb selfissued markw hhalpin +1.434.941.aadd rbarnes nvdbleek israelh +1.503.528.aaee
Found Date: 29 Sep 2014
Guessing minutes URL: http://www.w3.org/2014/09/29-crypto-minutes.html
People with action items: