Web Cryptography Working Group Teleconference -- 17 Jun 2013

<trackbot> Date: 17 June 2013

<slightlyoff> alex russell

<slightlyoff> (just joined)

<slightlyoff> thanks

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 :)

Focus on Web Crypto API

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 discussions.
... 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 format.
... 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 listserv]
... 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

<karen> +1

MW: I'd like to poll the group to determine whether non-extractable keys are a part of this proposal (for wrap / unwrap)

<mitchz> +1

<markw> +1

<sangrae> +1

<slightlyoff> -1

PROPOSAL-Tentative: SHould the spec. include an explicit non-extractable key for use within wrap /unwrap?

<markw> PROPOSAL: Key unwrapping should include support for unwrapping of non-extractable keys without the key material being exposed to Javascript

<markw> +1 ;-)

<mitchz> +1

<scottk> +1

<karen> +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.

MW: Ryan's proposal would not allow you to construct a wrapped key in such a way that it would be non-extractable and not exposed to JavaScript.

<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.

VG: Ryan, would you agree to add something into the section that there is a need to clarify the "non-extractable and not exposed to JavaScript use case" within wrap/unwrap?

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 steps.
... 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

<slightlyoff> +1

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

<rsleevi> Sure

<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

<ddahl> +1

<virginie> +1

<karen> +1

<nvdbleek> +1

<sangrae> +1

<israelh> +1

<MichaelH_> +1

+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?

<MichaelH_> -MichaelH_

<wseltzer> trackbot, end teleconf

- DRAFT -

Web Cryptography Working Group Teleconference

17 Jun 2013

Attendees

Contents

Focus on Web Crypto API

Summary of Action Items

Scribe.perl diagnostic output