See also: IRC log
<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]
<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:[End of scribe.perl diagnostic output]