See also: IRC log
<trackbot> Date: 17 June 2013
<slightlyoff> alex russell
<slightlyoff> (just joined)
hi ale, can you identify yourself?
<rsleevi> and fjh
<sangrae> I think IPcaller is sangrae
<ale> arunranga, hi, I'm a student from Italy, and I'm using the WebCryptoAPI for my thesis
<israelh> Israelh is on the called muted
Happy to scribe!
<scribe> scribenick: arunranga
<ale> I've a question/proposal but I think this is not the right time to discuss that, so I'll just lurk here :)
RS: I'd like to make sure we can
nail down blockers for a public working draft.
... An email with the updates was pushed out.
... Key operation and Futures/Promises transition happened. We also updated ECDSA sample text.
... The main update is the Promises.
... We should also discuss wrap/unwrap issues.
VG: Using the two week draft, we'd like to initiate a heartbeat publication.
MW: I'd like to talk about
wrap/unwrap, which isn't implemented as per our
... We had a proposal, which the group did agree should be in the spec., but Ryan did some parts of this only partially vis-a-vis the original proposal. The part that's good is that Ryan has decoupled JWE from the actual key-wrapping format, which improves on the original.
... explicitly, a "wrap" is an "export+encrypt" and unwrap is "import+decrypt."
... But, in order to make it work per the original, we proposed that a key format supporting attributes must be included, which is currently left blank. The current text blocks that.
VG: Could we publish something that exposes the conflict?
RS: I've proposed on the list a
way to resolve these concerns. In particular, there isn't a
crypto api that does this type of attribute carrying key
... In the interim, I've described a solution on the list. I have an implementation that can implement those aspects. The point of contention seems to be whether or not this is something that the spec has to deal with this. I've proposed on the list a way that doesn't necessitate spec. changes.
MW: [asks for clarification about
... What Ryan was suggesting was that for named keys, with usage unwrap, could have a special behavior, such that when used, the result would always have result extractable as false.
... What I said was that on the one had it had this extra feature, and we need a solution that also works for named keys.
VG: do we publish as is, including a note, or do we keep two weeks to go ahead with further discussion.
MW: What we'd like is to determine whether a key delivered by our server, which is not extractable, can be used within wrap/unwrap.
<rsleevi> The proposal does not mandate Mark's proposal, but it does not prevent it either
MW: I'd like to poll the group to determine whether non-extractable keys are a part of this proposal (for wrap / unwrap)
PROPOSAL-Tentative: SHould the spec. include an explicit non-extractable key for use within wrap /unwrap?
<markw> +1 ;-)
<slightlyoff> -1, but only because I don't want to block the heartbeat; I don't see how the process issue informs the substantive debate
<rsleevi> That is not accurate.
<rsleevi> As described on the mailing list, I've put forward how it can be.
<markw> Qualifying, without using named keys
VG: I would suggest we add something into the specification that there is something more in order to address the complete use case.
MW: If the proposal of the group is to go ahead with the blank sections, but commit to including functionality accordng to the original proposal, I'm ok with that.
RS: I think this is unnecessary and redundant. But I'm happy to add an editorial note.
MW: more important than notes in the spec is to clarify what we're actually going to do in the spec.
<slightlyoff> yes, it's tactical
<rsleevi> -1 on technical for V1 (to be clear)
VG: I think we should move in a direction to make the non-extractable key not exposed to JS.
MW: Requirement is to do this in the main spec. WITHOUT using named keys.
<israelh> +1 to address this issue on the V1
MH: Why would a non-extractable key be exposed to anything?
MW: What we'd like to do is have
a key that's been wrapped in such a way that we can use the
unwrapping method to install that key into web crypto. There
would be NO way of getting that key in JS.
... The proposal is that there's a decrypt and an import. But if you want to apply that to a key, then you have to use a key format that carries that format. We can have a JWK format, which when decrypted and imported in one go ,will apply the attribute in the JWK over and above what's there.
... In JWE encapsulation, you'll have to do that in two steps.
... The content encryption key in the JWK, in the JWE structure, is the content encryption key wrapped with your pre-shared.
<slightlyoff> can whoever is typing mute themselves?
MW: (this is discussed on the listserv too): but the CEK (content encryption key) is specifically non-exportable.
MH: extractability is in two places?
MW: Yes. Since doing it in two
steps, you'd need to make sure what the usages are in each
... ANd because these are atomic operations, as far as web crypto knows, you don't have to know about the key format.
... But in order to make it work, you need to have attributes.
... What's atomic is the combination of decrypt and import. You'd have to do that twice.
MH: if the payload key is non-extractable, shouldn't the export fail?
MW: I'm describing an unwrap
using a CEK.
... If you have no attributes on the CEK, I could use CEK to decrypt the payload.
<slightlyoff> how is this a good use of our time?
RS: Quick note. He says we need to have attributes on the export key format, which I don't believe is the case.
Proposal-Tentative: We go for a next public working draft, but include caveats about wrap/unwrap
MW: Ryan, what you mention as a solution is to attach additional semantics to named keys.
RS: I've discussed multiple solution, and how they can look. I've tried to provide a short term to allow for the heartbeat, and we can discuss how longterm solutions might look, but that are also generic.
Proposal: We go for a next public
working draft, but include caveats about wrap/unwrap
... We go for a next public working draft, but include caveats about wrap/unwrap, including the open question of an explicit attributes and the non-named key case
: Proposal: We go for a next public working draft, but include caveats about wrap/unwrap, including the open question of explicit attributes and the non-named key case
<markw> @rsleevi - by "V1" do you mean the first version of our document that goes to Recommendation
RS: we are committed to try to
work towards a solution. I want to be clear that the proposal
isn't a "must have." We are committed to working on it, but
don't see it as an essential feature of the API.
... My clarification is that the solution as MW proposed won't be in the next public working draft.
MW: We had a long discussion about key wrapping and unwrapping, and a proposal to be included in the working draft. This has been partially implemented, and leaves some things blank. It would feel like a step backwards, if we say this would be in the "next version."
<rsleevi> It's entirely consistent with our statement of "Feature at Risk"
<rsleevi> and continues to keep Key Wrap/Unwrap in scope of our deliverable
RS: I want to make clear that we're committed to evolving an API that works.
<slightlyoff> I'm going to need to drop off the call
<slightlyoff> apologies, I'd hoped we'd get to Promises
IH: I'd like to get more
clarification on the meaning of "at risk."
... The way we've done it with other specs, like IndexedDB, when something is "at risk" we still went ahead.
<slightlyoff> israelh: that's one way to define that, and IndexedDB did that wrong IMO
IH: The way we define "at risk" was that if some implementors didn't implement it, it might have dropped off.
<ddahl> anyone else disconnected?
Proposal: The Working Draft includes an editor's note about the status of wrap / unwrap, notably a caveat about explicit attributes.
<rsleevi> +1 to specifying in the spec that wrap/unwrap is underspecified, that more work is needed, to continuing to work in the WG to find a solution, but not changing wrap/unwrap as a feature at risk
+1 with rsleevi clarifications
<slightlyoff> +1 to continuing to work in the WG to find a solution, but not changing wrap/unwrap as a feature at risk
<slightlyoff> (as rsleevi said)
markw, still there?
<wseltzer> RESOLVED: Publish working draft as next heartbeat
<slightlyoff> great, thanks
<slightlyoff> is there an ical feed for this WG's meetings?
<wseltzer> 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/propose a key to be included/proposed that a key format supporting attributes must be included/ Succeeded: s/clarifying it later/including functionality accordng to the original proposal/ Succeeded: s/CEK/attributes/ Succeeded: s/a explicit attributes/explicit attributes/ Found ScribeNick: arunranga Inferring Scribes: arunranga Default Present: +1.512.257.aaaa, +1.650.214.aabb, +1.415.294.aacc, rsleevi, Virginie_Galindo, MichaelH, nvdbleek, Wendy, arunranga, +1.512.257.aadd, karen, fjh, Tony_Nadalin, +1.408.540.aaee, [Microsoft], ddahl, Israel, mwatson, scottk, +1.415.997.aaff, slightlyoff, +1.857.928.aagg Present: +1.512.257.aaaa +1.650.214.aabb +1.415.294.aacc rsleevi Virginie_Galindo MichaelH nvdbleek Wendy arunranga +1.512.257.aadd karen fjh Tony_Nadalin +1.408.540.aaee [Microsoft] ddahl Israel mwatson scottk +1.415.997.aaff slightlyoff +1.857.928.aagg sangrae Found Date: 17 Jun 2013 Guessing minutes URL: http://www.w3.org/2013/06/17-crypto-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]