Web Cryptography Working Group Teleconference -- 15 Nov 2013

<rbarnes> working on joining the audio...

<vgb> yeah, i got "this conference is restricted at this time"

<rigo> oh

<rigo> no zakim

<rigo> trackbot, start meeting

<trackbot> Date: 15 November 2013

<rbarnes_> is the conference code 27978# (like usual) or 26633# (like yesterday)? the former works for me (i'm there now), but the latter is "restricted"

<rigo> I'm about to find out

<rigo> Agenda:

<kodonog> scribenick: kodonog

<rigo> scribe: kodonog

<rbarnes> i might *like* to leave before 02:30 ;)

<rigo> tough luck :)

some participants need to leave by 3:30 local time...

Buglist

<rigo> https://www.w3.org/Bugs/Public/buglist.cgi?quicksearch=web%20cryptography

<rsleevi> https://www.w3.org/Bugs/Public/buglist.cgi?component=Web%20Cryptography%20API%20Document&list_id=29868&order=bug_id&product=Web%20Cryptography&query_based_on=&query_format=advanced&resolution=---

order for today, bug review, webRTC,

<mountie> bug# ?

<hhalpin> trackbot, start meeting

<israelh> bug#23660

<rigo> sure

<trackbot> Meeting: Web Cryptography Working Group Teleconference

<trackbot> Date: 15 November 2013

<virginie> bug 23660

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

Finishing Up Going through Bugzilla on API

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

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

finish specification

23695 - public keys are always extractable, extracability of private key pairs is TBD, probably look like MS implementation

MichaelH: put private extractable as an enum in your list?

rsleevi: there is no word for extractable

confusing this with the conversation about usages

<virginie> to all attendees, reminder : our wiki agenda is here : http://www.w3.org/2012/webcrypto/wiki/F2F_Shenzhen_Nov2013#Detailed_Agenda

Mete: why do we not have a generate key pair method and just a singluar generate key

rsleevi: a couple of answers
... if you split along the notion of key pair, you would need parallel operations,
... this creates a significant surface for all those

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

rsleevi: doing this would cause significant rework of api

bug 23728: spec needs to be clear, operations are asynchronous, what happens to the underlying data

scribe: interpretations
... one is you freeze the object
... caller cannot reuse that object but would need to reallocate new memory
... another interpretation you can use copy on write
... apple engrs concerned about performance implications
... you'd be adding a copy on every write
... would only be meaningful for webcrypto but would have broader implications
... third options implementation copies on callers data, any further mutations of underlying data are not reflected in the cryptographic operations
... spec will do third

israel: can we infer some of these strategies based on array buffer or arraybuffer view

rsleevi: (missed his answer)

<rsleevi> answer: in terms of WebIDL, there's no requirement that we make a copy of the ArrayBuffer. The spec needs to clarify explicitly to make a copy

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

23729: implications inconsistent error handling

<virginie> [note to the attendees interested in web RTC, richard posted some slides here http://www.w3.org/2012/webcrypto/wiki/images/b/bc/Webrtc.pdf]

23729: likely will go with a DOM string, error handling will be consistent
... mostly a webIDL clarification
... instead of a sequence of keys would be a sequence of DOMstrings
... reason this is important
... 2 interpreattions... you ignore them or you error out
... because this is a security api, blindly accepting things is not good practice

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

related to key usages, how a default key usage behaves

proposed resolution, key usage is a mandatory attribute,

scribe: in the case of JWK, the caller would need to know the import key and
... same behavior for handling different algorithms
... if caller is specifying a set of key usages the aren't supported, it would fail

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

23779: dup and cleanup bug on webIDL semantic nits

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

23786: request for clarification on import key, similar to previous discussion
... if parameters are an incompatible intersection, it fails

each algorithm would define the set of parameters

some algorithms don't have this problem

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

23796: in case of JWA, how to JWA and webcrypto algorithms meet,
... mark working with JOSE wg on JWA algorithm registry,
... jose has a use were enc means encrypt/decrypt/wrap, and unwrap

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

23796: need to figure out how to parse these in an attribute preserving way
... discusssion on the list...

23831"

filled yesterday by mete to add HMAC-SHA1

will be done...

MichaelH: HMA-SHA1 as a recommended?

<hhalpin> it would likely be better to use a less loaded term than "recommended"

<hhalpin> such as just "supported"

rsleevi: we can debate whether it is recommended for legacy or

accordinga

Israel: in the webIDL, are we creating an array of arraybuffers

rsleevi: sequence is treated as a contiguous buffer
... goal is to prevent a JS author from having to copy

Israel: complicates implementation and increases the test matrix
... make copies in some cases and not others means you have to decide when to copy
... do we need this level of detail?

rsleevi: we could take this out
... it was added in the april version
... downside to taking it out, once we force a particular pattern on a JS author we can never optimize that pattern

Israel will file a bug about sequence and we will go back to a single operation model

<Zakim> rigo, you wanted to ask about algorithms

<hhalpin> +1 adding 25519

Rigo: question on algorithms potentially impacted by Snowden revelations

rsleeve: the few people that have raised concerns are not reinforced by the cryptographic community
... including the cfrg in the community

<rigo> my concerns have been addressed

hhaplin: what is the browser support

<hhalpin> just wondering if there was any plan to add brainpool to default implementations

<hhalpin> and any plans to add or not?

vijay: microsoft out of the box for the 3 suiteB curves

<hhalpin> 25519 is not covered yet (ditto Brainpool), still in TLS WG

<hhalpin> there will be a test-suite

<hhalpin> that should specify clearly what developers can rely on.

<hhalpin> +1 rsleevi's epic trip through issue list and bugzilla

<hhalpin> Richard's slides: http://www.w3.org/2012/webcrypto/wiki/images/b/bc/Webrtc.pdf

WebRTC and WebCrypto

<rbarnes> http://www.w3.org/2012/webcrypto/wiki/images/b/bc/Webrtc.pdf

Richard Barnes

webRTC meeting earlier this week

scribe: rbarnes presenting referenced slide set
... need some way for applications to control which keys are used in the handshake

<hhalpin> notes the point re "never been accessed to JS" re private key material

scribe: proposal add two things, specific key usage and flag

<rsleevi> vgb: It would be legal, but it would be an error

<rsleevi> that is, the usage would result in an error, because unsupported usages = throw an error

<vgb> rsleevi: but an implementation could support it and not violate the spec, right?

<rsleevi> the only change is that it goes from a sync error (webIDL) to an async error (reject the promise)

<rsleevi> vgb: Correct

<vgb> so... can we take that off the table as a spec issue?

scribe: webcrypto would be a reasonable way to implement this because most of the requirements are already met

<rsleevi> @vgb: You still need/want a spec to describe how this new key usage works ;)

<rsleevi> @vgb: Otherwise, you end up in a situation where one UA uses a keyUsage of "dtls", another uses a keyusage of "webrtc"

<rsleevi> @vgb: The latter one being the 'right' one ;)

<vgb> rsleevi: true, but that spec does not need to be this one?

rsleevi: as an implementor I have zero interest in this.
... disagree that it is easy to implement
... if i wanted to use ECDH how is that communicated in the dtls certificate
... define a set of webcrypto objects that can't be used with webcrypto
... i don't see a way that this api makes sense to expose
... a whole host of algorithms that just don't work
... better suited for the webRTC group to explore
... webRTC could explore their needs for crypto, if they wanted to expose those to JS developers

(rsleevi... you might want to better summarize for the minutes)

Mountie: I agree with Ryan.
... if webcrypto handles certificates then this might be workable

<rbarnes> ekr: appropriate kind of keys here are ECDSA and RSA

<rbarnes> ekr: true that you couldn't impose an AES key, but surely that's true all over webcrypto, not webrtc's problem if the class hierarchy isn't rich enough

<rbarnes> ekr: pfs is not a problem

<rbarnes> ... if webrtc wants this, they should ask for it -- that's what this is

<rbarnes> ... could make up some other class of key objects that you use only with webrtc, but that seems like of inferior

<rbarnes> ... if we want webrtc to say "please use rsa/ecdsa", we would need to restate everything that web crypto has already done

<hhalpin> ekr, could you put this in IRC?

<rbarnes> i've been trying to scribe ekr

<ekr> What rbarnes is saying is fairly accurate

<ekr> (in terms of my scribing)

<ekr> Well, we discussed this last week

<ekr> or rather M-T

<ekr> and then decided to bring it to webcrypto

hhalpin: we should continue the discussion over the mailing list

<ekr> MichaelH: the property here is that "this key was internally generated and never marked exportable"

hhalpin: 2 new things, DTLS key usage and guarantee not used by webcrypto

<ekr> rsleevi: the guarantee is that it was *generated* by webcrypto but never available for private computations by the JS

<Zakim> AndyF, you wanted to say it seems like we are moving encryption to far up on the stack to have it at the application programming level

AndyF: from webRTC working group

<virginie> note : andy is from Verisign, as an observer here

AndyF: looking at putting dtls certificate into api

<ekr> andy: WebRTC has already decided to do DTLS. That's not an open question.

AndyF: why is this being done at this level? how do I guarantee the integrity of that keystore

<rbarnes> andy: also, the dtls is all done by the browser, this is only giving the app a degree of control over how it's odne

<hhalpin> it seems like this distinction between extractibility in terms of generation vs. unwrapped/imported is interesting and orthogonal to the DTLS key usage. I'd be interested in knowing if any other use-cases need finer grain storage/generation concerns beyond how we currently specify extractability.

<ekr> hhalpin, I think that's arguably true, though it's a sort of limited guarantee because you have to trust the browser.

<ekr> … that's true for WebRTC, but it's not that common a setting.

rigo: meta discussion... w3c part of research project looking at webrtc security

<mete> hhalpin, any financial related implementation requires finer grained controls/knowledge related to key storage/generation

<mete> hhalpin, ... requires or can benefit from it

rigo: together with IAB will organize a workshop prior to next IETF,
... this would be a good topic for that workshop
... project is to create a research roadmap

<Zakim> rsleevi, you wanted to respond to ekr

<hhalpin> ekr, I think we just have to say the browser is a trust anchor with this API - would still be interested in a more detailed proposal re extractability

rsleevi: webrtc cares about identity, certificates

<wseltzer> we need to carefully scope the claims we make about key security

<rigo> +1

rsleevi: these are problems we have intentionally deferred from v1 of the api

<ekr> clearly, we don't care if it's "DTLS" or "WebRTC"

<rbarnes> "peerconnection" was also suggested

<ekr> quite the contrary, we don't want to share them across origins

<ekr> actually, you probably could use RSA-PSS.

<ekr> In some future TLS world

<ekr> (Though I don't think that that's a material change)

rsleevi: this is the certifications plus conversation and is a fundamental design issue
... webrtc should deal with it at a high level

<rbarnes> webrtc has decided to separate identity from the crypto

<rbarnes> dtls provides the key exchange and proof of possession

<rbarnes> identity providers bind public keys to identity

<rbarnes> so the work we're talking about, at the dtls layer, is not bound into the identity part, it's more crypto-focused

<rbarnes> we don't really care about the certs in the DTLS exchange, just the keys

<rbarnes> SDP exchanges key fingerprints, which get bound to identities at a different layer

<ekr> as rbarnes is saying: the certificate is just a key carrier because of the way DTLS works.

<ekr> session description protocol

<rbarnes> Session Description Protocol

<rbarnes> jinx!

<rbarnes> so really all we're talking about here is *key* management, not *identity* management

virginie: this topic is for future work
... no direct endorsement, need more description
... this is not a small adjustment, it is a new requirement

<rbarnes> i disagree with the characterization of this as a huge change. it fits on a slide, as would the implementation.

<rsleevi> @rbarnes: No it wouldn't :)

<rbarnes> but i will take this to the list. clearly there's a need to expand more on the context

<rbarnes> rsleevi: challenge accepted :)

virginie: i don't agree with ryan on the complexity

<ekr> rsleevi, {\tiny \begin{verbatim} …. \end{verbatim}}

<rsleevi> @rbarnes: Having been involved in both implementations in Chrome, they're entirely different stacks and security models. Getting keys from one to the other is a non-trivial change with fundamental security implications

virginie: happy with other groups coming to us

<ekr> rsleevi: I'm not sure it's as hard as you think it is, but I'd be happy to talk to you about chrome

<ekr> :)

<rsleevi> break for 30

<rbarnes> we back yet?

<rbarnes> is 30 minutes different in china?

<virginie> we will start in few seconds... get ready !

<rsleevi> rbarnes: 30 minutes is a SHOULD implement, not a MUST implement

upcoming wrap/unwrap import, key discovery

<rsleevi> scribenick: eroman

Wrap/Unwrap

virginie requesting rsleevi to give a status update on wrap/unwrap

rsleevi: No outstanding technical issues. There is text to integrate into the spec from Netflix discussions but otherwise nothing major

Mark Watson: We are happy with the approach that we proposed and there are just some details to work out. There are details to work out on the "usage" attribute for the JWK

rsleevi: Matter of coordinate with JOSE on how it works

Mark Watson: We need to decide what we want to register. They [JOSE] provide the registry. Way to differentiate what applies to JWK

scribe: If anyone thinks that we don't need to accurately represent a WebCrypto Key in JWK then can bring it up now

virginie: We can definitely close this topic and switch to topic of Key Discovery API

Key Discovery API

Mark Watson: The API has not changed, just 1 issue with the text (add API for discovering the names)

Virginie: There are no outstanding issues, just this one new request that we are about to discuss

MichaelH: The intent here is there is a mechanism by which we can have a "data concentrator" which has access to the internet which has subordinate devices which don't have access to the internet. Example: Home automation system. Device controller is a UA talking to the internet via a PLC. Each device has a key-pair. When the service provider needs to update

it will quiz the concentrator to say what keys have certificates that I can use. Those certificates are identified by a "GetKey" function which will return only keys that match the certificate origin.

rsleevi: I feel like this is changing the API to meet a particular usecase
... What about a "GetKeyByID" mechanism instead

MarkW: Doesn't know what the IDs are

rsleevi: the whole idea of named keys is the server can ask the UA
... in this particular home automation device... can assign unique device IDs to light switch 1 etc..

<hhalpin> So he wants a GetKey by origin essentially?

rsleevi: getKeyByDevice(0)

<rsleevi> clarification to eroman:

<rsleevi> getKeyById("device0")

<rsleevi> getKeyByName("device0"), getKeyByName("device1")

<rsleevi> @vgb: You have to get the Key object first; pre-provisioning IDB isn't (yet) supported, which is why we have named key discovery to begin with

MarkW: Just to fix some of the context things... It is getkeybyname not getkeyby id. The idea is these have an ID and a name. The name is pre-provisioned thing that identifies this key among a small number of keys that were bound to the device is our use case. So you have this notion of factory pre-provisioning a device with particular keys for the origin.

i.e. key1, key2, or whatever we decide to call them. and then they have IDs that identify the keys among all the devices. and then there was this idea of what if i don't know the names. we didn't have a use case where we didn't know the names. this is a use case that was brought up.

<vgb> rsleevi: could an implementation do that on its own and still be compliant with the spec?

scribe: Ryan is right you could have these names dynamically allocated from a known set (device0, device1 and so on). we might decide this is awkward because next time you reboot the device they may have all changed around. this is awkard.
... maybe the key is associated to something completely different like a person. we have agreed this is out of scope for version 1.
... the API proposed is pretty simple. so if we decide to support this use case shouldn't be too complicated. however we would have to think about the privacy considerations.
... question for the working group is if it is something we want to address.

<vgb> @rsleevi: primarily i'm seeing a general trend of wanting richer searching and organization of keys, and i wonder if we can leverage other existing pieces that do such things well

<rsleevi> @vgb: I agree. I'd like to avoid creating "yet another" storage mechanism, and yet another query mechanism

mete: I wonder if there are multiple key stores in the device. And I can't say in the API from which I do the query.
... "get this from the embedded TPM" "get this from the key card"

MarkW: We are not addressing smart cards, that is out of scope

<rigo> "get this from URI"?

<rsleevi> @vgb: The sorting/filtering/discovering of keys is the 'messy' API that we keep punting, which is why named, pre-provisioned key discovery was working specifically because you could *avoid* the need for any searching, because by definition, you know the name of the key a-priori

mountie: Who benefits from this specification?

MichealH: "Whoever provides devices into the world"

rsleevi: Any device manufacturer that is implementing user agent, and wants to expose keys to the user agent.

mountie: Brings up issue of name collision, if there are many manufacturers vending names

MichaelH: This is just a way to find them

<hhalpin> It seems like we need to be careful re ad-hoc solutions to key management, agree with @vgb there should be someway to do this with other cross-platform standards.

MarkW: .. Another solution that a device manufacturer can adopt. They can implement a generic mechanism that can create a pre-provisioned key for an origin on request, using a root key by hashing it together with the origin for example.

<rigo> xkms is the current W3C spec on key management

MichelH: you still need to have a negotiation for interchange to happen (i.e. postMessage). These names are specific to an origin. So not really an issue

virginie: In order to progress on this topic there are three choices: (1) integrate into spec (2) park it for future work (3) object to it
... We are going to make a formal vote

<vgb> virginie: what is "it"?

<hhalpin> I saw a use-case for key-discovery by GetKeysbyOrigin?

<rsleevi> @hhalpin: GetKey*s*ByName I believe

virginie: The "it" being referred above is the GetKeysByName() by Mike

<rsleevi> ACTION-114?

<trackbot> ACTION-114 -- Michael Hutchinson to Make proposal to amend api -- due 2013-09-23 -- OPEN

<trackbot> http://www.w3.org/2012/webcrypto/track/actions/114

<rsleevi> http://lists.w3.org/Archives/Public/public-webcrypto/2013Sep/0048.html

<hhalpin> I'd be interested what implementers have to say about the chances of this being implemented in addition to KeyDiscovery?

<hhalpin> I.e. its unclear if a real product is driving this or a hypothetical use-case

<rsleevi> The proposed addition, based on https://dvcs.w3.org/hg/webcrypto-keydiscovery/raw-file/tip/Overview.html#overview

<rsleevi> is added methods "getKeys" and "getKeyById"

MarkW: This is about whether we want to add it in concept, and then figure out the details

<hhalpin> all non-extractable keys :)

mete: <inaudible>

<hhalpin> Nothing would prevent URIs from being used - the question is should they be required.

<hhalpin> and keys are already origin specific so one could craft a URI scheme or origin+string :)

rsleevi: [restating and responding to Rigo's question] The issue you are pointing out is disambiguating name collisions. As it relates and speaking on behalf of Mark: Names are essentially decided by the user agent (origin specific keys), so the handling of collisions between names is done by user agent. So yes there is a potential of naming issues if you

have multiple user agents exposing pre-provisioned keys (which you can file as question for Mark). Names are not chosen by the site, they are chosen by the user agent.

<rbarnes> harry is inaudible

<rigo> harry, looks like low hanging fruit, but if it is not needed....

<hhalpin> Mark is definitely implementing, not sure re everyone else.

<hhalpin> So TV folks would implementing Key Discovery, and thus perhaps this GetKeyName discovery work.

MarkW: So right now I don't have an example that I can bring to the group. This is something that we at Netflix wanted to use to run our HTML application on TVs and set-top boxes. So this is not for desktop browsers (which are the people here). Those devices are less powerful that desktop machines, so the evolution of HTML5 on those devices is not as far

advanced as on desktop devices. So not much more I can say about that.

<virginie> resolutionq?

mountie: When the key is generated or in the user agent (not factory installed), can this GetKeyByName be used ??? by the user agent itself

rsleevi: A variety of implementations are possible. The spec doesn't require any particular one. So long as when you call GetKeyByName and that origin is authorized then a key is returned. For instance it could choose to derive a new key using the master key in response to GetKeyByName().

MichaelH: Clarification: This is restricted to keys that have certificates (not all keys in the store)

mountie: To remove any misunderstanding, I think we need more information on the user

<rsleevi> PROPOSA: Do we address in v1 of the Web Crypto Key Discovery API this use case (ex: getKeys / getKeyById)

<rsleevi> PROPOSAL: Do we address in v1 of the Web Crypto Key Discovery API this use case (ex: getKeys / getKeyById)

virginie: Question: Do we want to address in version 1 of the WebCrypto Disovery API

<MichaelH> +1

<rsleevi> -1

<hhalpin> 0

<markw> 0

<rbarnes> 0

<ekr> 0

virginie: this use case

<hhalpin> Stunning agreement

<vgb> i vacillate between 0 and -1

<Anders> +1

<mete> 0

<sangrae> 0

<jin> 0

<virginie> hhalpin is speaking

<mountie> 0 until spec updated and understandable

Harry Halpin: Is the editor of the key discovery... does he want to sync his last call to the discovery last call. I seem to recall that Mark didn't care on this feature.

MarkW: I was expecting that the progress of this draft would match that of Web Crypto API, and go to last call at same time

<hhalpin> I'd be happy to leave it as added as "Feature at Risk" at editor's discretion

Vijay: We really need to talk about it more perhaps on this list, before it is ready for consideration for inclusion
... it just seems to indicate that the discussion around it is not mature enough to commit to putting it into V1

virginie: It is quite clear to me as chair that we are not going to work on this in the V1 of the spec
... that there is low endorsement in the group
... I also hear that there is need of some clarification
... it is not a dead topic, and could be part of V2

<hhalpin> mwatson, Key Discovery will require proofs of two separate implementations per feature

<hhalpin> for exiting CR

<hhalpin> I'm sure you'll have lots of implementers, but just make sure the WG has at least two that can be public

viriginie: Topic is closed (Web Crypto Key Discovery addition)

milestones

Milestones: When do we want to go to Last Call

<hhalpin> Notes we're already about a month behind re Last Call

virginie: Ryan, when do you think we will be ready for last call? What is a reasonable timing (for Ryan to finish edits and for group to review)

rlseevi: My first feeling is hard to gauge. In light both of the number of bugs open, and other professional responsibility. 43 bugs and 6 or so issues to close out. So I'm going to unfortunately have to defer on that a bit. I don't know if i can give a reasonable commitment. The next version of spec will be significantly longer (to address the open issues)

and a require a substantial review effort.

virginie: When do you think the next version will be available?

rsleevi: Again, I can't commit to a date on that... There is only 1 editor at this point
... <reinforcing the amount of work to expand the spec>

<hhalpin> Realistically, it would be great to have a new version within a month

rsleevi: "It is very hard to answer that today"
... I think a better answer is: On our next call following this, once I've had a chance to coordinate with my colleges and work though scheduling efforts I can give a better idea.

MarkW: <Offers to help on making the spec edits to help out Ryan>

virginie: Let's talk about that during our next call in 2 weeks (or a little bit more)

virigine: The TAG is tasked with reviewing our specification. There are 2 aspects to review: Review the spec for the sake of spec, and then the use of Promises.

virginie: Action for the chair is to "resend them that"

<hhalpin> ACTION: virginie to re-ping Alex Russell on status of Promises and WebCrypto [recorded in http://www.w3.org/2013/11/15-crypto-minutes.html#action01]

<trackbot> Created ACTION-129 - Re-ping alex russell on status of promises and webcrypto [on Virginie GALINDO - due 2013-11-22].

virginie: We received some intermediate comments from Privacy group (particularly on Key Discovery), Mark has started to address that

<hhalpin> ACTION: virginie needs to check that the review by the PING has been answered [recorded in http://www.w3.org/2013/11/15-crypto-minutes.html#action02]

<trackbot> Created ACTION-130 - Needs to check that the review by the ping has been answered [on Virginie GALINDO - due 2013-11-22].

virginie: Action for the chair is to make sure they are happy with those answers
... Comment from experts (Dan Bonneh), make sure they are happy with our answers

<hhalpin> ACTION: hhalpin to schedule Dr. Boneh to return to see if he's satisfied with current answers to his review. [recorded in http://www.w3.org/2013/11/15-crypto-minutes.html#action03]

<trackbot> Created ACTION-131 - Schedule dr. boneh to return to see if he's satisfied with current answers to his review. [on Harry Halpin - due 2013-11-22].

virginie: "synchronizing with the IETF security work". This is more like a general concern that the IETF is having some high activity on the security aspects. But at the moment we don't have any direct action.
... As chair I am very happy to have feedback from other working groups (i.e. Web RTC).

HarryH: <???>
... As far as IETF coordinate we just have to email them, and then it is in their hands

<hhalpin> As regards co-ordination with the rest of IETF and W3C, we should ping everyone when we hit Last Call

MarkW: If you have something that can be done with JOSE structures that is not part of that (JWK/JWE work), then do it in your own registries.

<hhalpin> And we should not limit or hold up this work if we do not get a response, if we do, we deal with it using normal Last Call comment process.

rsleevi: In order to have an IANA registry, JOSE needs to get their stuff out.

<hhalpin> We can not hold up progress based on future work, we should assume future work will use the API in its current form or ask new features in v.Next of WebCrypto

rsleevi: <Points out the chicken-and-egg problem with needing registry to already exist>

<rbarnes> in case that was inaudible, JOSE is really getting toward finishing their specs

kodonog: I think we are looking for working group last call in January. All the normative changes are in "dash 18" part of the specification.

virginie: Let me finish with the review
... I think we are done unless you have some comments

future work of WebCrypto

virginie: So we can start the discussion of the future work now, before lunch. So let's take 20 minutes for the high level API

High level API for future work

<hhalpin> notes that if anyone wants to make a draft high-level API, I am happy to set-them up with a space to do so

virginie: Background: High level API is about doing some action without worrying about the lower level mechanisms (Like a one click button)

<rsleevi> notes that previously rbarnes mikejones and ddahl were tasked with proposing a high level API

richard barnes: I think we had one call after the last face to face. So no progress on this one.

<kodonog> (backing up briefly... the latest status of the jose specifications are represented in this email... http://www.ietf.org/mail-archive/web/jose/current/msg03700.html)

mete: I believe there needs to be a high level API, but it doesn't need to be specified here

<rbarnes> mete is not audible

<mountie> +1 no need high level API

mete: developers can implement their own high-level API, the low-level primitives are there

<rsleevi> +1 to Vijay's comments

<rsleevi> +1 to markw

vijay: We have been talking about the high level API for a long call. Perhaps we should wait to see how people use v1 and then make a decision. For instance if something is extremely common in v1 we can make a better decision about it in v2.

MarkW: <Points out that developers can build a high level API built on top of the low level API>

<rbarnes> as i've said before, when you screw up your webgl, (1) it's obvious or it doesn't matter, and (2) sensitive data isn't exposed. crypto is special

Israel: <missed it>

rsleevi: I really want to echo a strong +1
... I think we will say a variety of use cases. (Gives example of Mozilla's pdf.js). "So big +1 to giving other libraries a chance to figure it out"

<israelh> answer rbarnes: very few people use webgl directly, they use libraries.

MichaelH: <Also +1s the sentiment>

MarkW: We should be on the lookout for what people can't do with the low level API, and then consider targeting small extensions the low level API to make them possible

<hhalpin> that being said, I'd be interested if anyone *actually* has plans to make a high-level API - and if someone sees one in the wild being developed, please email the mailing list so we are aware of it.

Richard Barnes: <Points out that the mission statement for this Working Group includes defining a high level API>

<rbarnes> i still believe in the cause, it's just fallen behind some other things in the queue

<mete> hhalpin, we can develop one surely, for specific use cases probably

rsleevi: [Talking to Harry] When we rechartered I thought we agreed to clarify that wording.

<hhalpin> ACTION: hhalpin to remove "high-level" term in next revision of charter [recorded in http://www.w3.org/2013/11/15-crypto-minutes.html#action04]

<trackbot> Created ACTION-132 - Remove "high-level" term in next revision of charter [on Harry Halpin - due 2013-11-22].

virginie: I must first get some feedback for the usage of the current specification
... < Doesn't want to kill the topic>

Israel: I would close the issue, and not deal with it until libraries show up. So in a sense a little bit of the opposite of what you are saying. Take it off the charter. More than happy to give feedback on people writing libraries. More than happy to help people writing libraries. But I wouldn't say it is in our charter because it confuses things. We can

come back next year and say we are at a stage where we can add it back to the charter. But I don't think keeping it in the charter now is going to help.

virgine: Next time we recharter for a good reason we take out the high level API

<mountie> +1 rechartering removing high-level API

virgine: not enough market maturity, will remain low priority for now

virginie: <Discussing the topics that will be covered after lunch>

<rsleevi> Break for 1.5 hours

virginie: Break for 1.5 hours. Reconvene at 2 Shenzhen time. See you in an hour and a half!

<virginie> thnaks eric for scribing

<virginie> hello crypto poeple !

<rbarnes__> virginie: there seems to be an issue with zakim

<rbarnes__> i tried both of the codes, and neither one worked

<virginie> to richard : we are trying to fix it

<virginie> to remote attendees, we are on the bridge

<virginie> hello P1 ? who are you ?

<rbarnes__> zakim ??P1 is me

<virginie> hi richard

<rbarnes__> there's some weirdness going on on zakim. "the callee is busy now, please try again later"

<vgb> anyone having luck with the voice call?

<virginie> richard, can u hear us ?

<virginie> sorry, high confusion, here

<vgb> now we can hear you

<hhalpin> :)

<rsleevi> scribenick: rsleevi

Testing

virginie: In the last F2F, we met with rberjon explaining the status of testing within the W3C
... is now the right time to speed up on the testing? Is there existing material? Do we need to setup a training program for people interested?
... I imagine tests will come when the implementations progress
... is there anything we can do now

rsleevi: I think implementors will be writing tests as they're doing their implementation
... and then working to contribute those up

israelh_: We've been writing tests, but they're based on our event-based implementation. Not exactly useful for the current version of the spec
... Generally pretty good at getting tests upstream though

virginie: Do we need someone who will manage test activities? How do we organize testing?
... Do you need someone else to examine the work? What's the status?

israelh_: I think it'd be great to have a person in charge of collecting tests and connect with efforts like Test the Web Forward
... similar to how WebApps is progressing
... would be good from their end to have someone to coordinate with and work on coverage

<virginie> to nick ; we just started the test discussion

MichaelH: Is the format for your internal tests the same format as the W3C tests?

israelh_: No, we convert to the W3C format. Still working on the transition to the new testing

rsleevi: Implementors tend to do continuous integration tests, regardless of the W3C testing infrastructure. Usually have two sets of tests

MichaelH: Are you saying there are different types of tests - unit tests vs system tests

<hhalpin> the test-suite for this will be substantial and I'm happy to take a volunteer as test-suite manager

israelh_: Yes; there are different parts to testing. Some are positive tests (does this work), some are negative (make sure this doesn't work)

<hhalpin> however, we can wait for that until some tests actually appear

israelh_: need to decide what sort of sequences we want to test. It's not 'just' a simple API test

<hhalpin> that people want to contribute

israelh_: will be doing end-to-end testing, but will be based on specific scenarios and use-cases. Not sure if that belongs in the W3C or not, looking for feedback

<rbarnes> that's kind of silly. couldn't we at least say you MUST implement at least one algorithm per operation type?

<hhalpin> x=2

<hhalpin> there will be matrix of supported algorithms before leaving CR

<nvdbleek> In other groups 2 implementations of an optional features is enough

mete: Can we just test the recommended algorithms?

rsleevi: Our exit criteria for CR is X number of interoperable implementations. You could implement the WebCrypto spec without implementing any algorithms. We've been talking about X number of implementations of a given algorithm, and each of those algorithms would have tests

hhalpin: As implementors progress on implementation, if they want help with writing tests, can contact hhalpin and work with tobie on test training
... I will double check to make sure we go through CR properly. We'll likely have a matrix of algorithms, what implementations support what algorithms
... the main hard thing is making sure the tests are checked in

mete: Can help somehow, but not sure how, if someone can provide guidance

<hhalpin> Note we've had several people volunteer but it's kinda pointless until tests appear

virginie: Harry & Tobie can help organize

<hhalpin> I'll re-send out the testing email.

<hhalpin> ACTION: hhalpin to remind people how it the test repo works [recorded in http://www.w3.org/2013/11/15-crypto-minutes.html#action05]

<trackbot> Created ACTION-133 - Remind people how it the test repo works [on Harry Halpin - due 2013-11-22].

<virginie> thxs harry

<hhalpin> Here's an example from Canvas in HTML of testing for CR with features at risk:

<hhalpin> http://dev.w3.org/html5/misc/canvas-implementation.html

MichaelH: When MSFT contributes a test, would you run it against other implementations?

<hhalpin> Here's the master HTML test-suite: http://w3c-test.org/web-platform-tests/master/tools/coverage/

rsleevi: Yes. If MSFT contributed tests, we'd run it against Blink. Likewise, if Chromium contributed tests, we'd run it against MSFT's implementation

MichaelH: What about if you don't implement an algorithm? Would one implementation pass the test, another fail?

rsleevi: Yeah, but that's fine. We'd have the matrix of support ala WebApps

V2

virginie: We've had a lot of topics raised on the mailing list that we've said "That'd be nice, but let's revisit that in the future"
... goal is not to establish a mandatory roadmap binding members to next steps
... but just to get an idea of what features are important for members
... so that we can establish a wiki and begin tracking steps

<hhalpin> tests are now centralized here BTW: https://w3c-test.org/

<hhalpin> I'll send an update here.

mountie: We have waited for many months for certificates
... we have seen the mailing list interest in certificates
... we only have one line in our charter regarding certificates
... may need to recharter to clarify what aspects of certificates are in scope and which are out of scope
... There is a lot of interest from the Korean membership in certificate management - issuing, renewing, and revoking
... which are the baseline for managing certificates

<hhalpin> Secondary API Features that *may* be in scope are: ... the lifecycle control of credentials such enrollment, selection, and revocation of credentials with a focus enabling the selection of certificates for signing and encryption.

virginie: We've allocated time for certificates

mete: As mentioned on the mailing list, the first thing desired would be access to the hardware components (smart cards, etc)
... will this ever be possible? Is there any blocking issue?
... wanted to know from browsers/UAs what the issues would be. Is it too hard? Will it just take time?
... the next thing would be more attributes or features of the keys
... eg: a way to be sure that a key is locked to a specific computer

israelh_: Just to make sure we continue talking about streams and multi-part as the natural evolution

hhalpin: I think there's two separate things going on. One is a desire to hardware/smartcard features
... the other is streams
... hardware/smartcard is a huge discussion. Maybe another spec. Maybe need a workshop to figure out scope, to get more vendors
... streams may be more straightforward. May not even be a major revision

<nvdbleek> +1 for smart card (secure elements) access in the next version of the spec

hhalpin: Question for the group: Would the group be OK with going to management and saying "Yes, more or less as a WG we'd like to be rechartered for V1.1 or V2.0"
... similar to how WebApps/WebAppsSec operate
... that is, keep the group rechartering as we take on new work
... Next question is: Does the WG support going directly to hardward/smartcard features?

<mete> any technical reasons ?

rsleevi: +1 to working on streams / multi-part
... not that interested in hardware elements
... lots of concerns related security and privacy implications; technical interoperability

israelh_: There is interest in hardware, but not sure if it's part of the WebCrypto API
... need to work through the real world use cases and what the API looks like

<Anders> anders q+

israelh_: the days of "Hey, I have something, I want the API to support it" may be over. Want to make sure a solution is usable for the market, but that may look different than existing solutions

mete: The current API is not useful for financial use cases.

virginie: Clarification - Do you mean the crypto or the keys?

mete: Keys and how they're used

mountie: The use of smart cards or secure element is connected with securing the key storage
... Still have questions regarding how keys can be protected from the attackers
... maybe in the next version, we can set guidelines for how the key store can/should be protected

anders: I'm interested in something key discovery, such as Michael had suggested, but smartcards may be a completely different issue and standardization effort

<hhalpin> PROPOSAL: The WebCrypto Working Group expects to be rechartered for future versions on an ongoing basis (similar to WebApps)

<israelh_> +1

<mete> +1

<mountie> +100

<nvdbleek> +1

<sangrae> +1

<kodonog> +1

<jin> +1

<rbarnes> +1

<MichaelH_> +1

<hhalpin> Sounds like consensus

RESOLUTION: hhalpin to discuss with W3C leadership the future of the group

<hhalpin> PROPOSAL: the W3C should have a workshop next year looking at smartcards and hardware token use-cases and existing landscape API landscape

<nvdbleek> +1

<sangrae> +1

<mete> +1

<jin> +1

clarification: next year (2014)

<MichaelH_> +2

<mountie> +1

<hhalpin> RESOLVED: the W3C should have a workshop NEXT year looking at smartcards and hardware token use-cases and existing landscape of APIs

<kodonog> +1

virginie: It seems Streams is a natural next step as it keeps coming up
... as long as Streams gets stable
... <confirms that we have members who participate/follow the Streams activity>

rsleevi: <confirms>

Manu to discuss Web Payments CG

manu: <introductions>

<manu1> manu: In general, the purpose of the Web Payments work at W3C is to integrate payments into the core architecture of the Web.

<manu1> manu: The work touches on identity, security, mobile, banking, and financial industry in general. There is a lot of coordination that will need to be done if we are going to be successful. One of the groups that we need to coordinate with is the Web Crypto group.

<manu1> manu: These are the moving parts associated with the Web Payments work:

<manu1> manu: SysApps - Secure Element API is vital for high-value financial transactions. How does it work with Web Crypto, NFC, Offline and the Web Payments stack?

<manu1> manu: WebCrypto - Web Crypto API is important for doing client-side digital signatures for purchasing. How do you coordinate a Secure Element w/ the Web Crypto API to perform a digital signature on a purchase request or purchase authorization?

<manu1> manu: NFC - NFC API is important for both online and offline purchases, does it integrate cleanly with Secure Element, Web Crypto, and Web Payments?

<manu1> manu: Geolocation - There are use cases where you would want to use geolocation to determine an indoor location when performing a purchase, such as access to a particular portion of a building (like a museum) based on payment. Authorization of purchases is also important (is your mobile phone in the same vicinity as the physical purchase you're performing?)

<manu1> manu: Offline - How do you perform an offline purchase using SysApps, WebCrypto and Web Payments. Is there a clear integration story for all of the applications?

<manu1> manu: Web Payments - Making sure that the use cases are defined clearly up front with clear pointers to where and when Web Crypto is used.

<hhalpin> maybe you can explain what WebPayments is and what vendors currently support it?

<manu1> manu: In general, make sure there are clear technology integration stories for the crypto and identity use cases and be very aggressive at making sure the Working Groups are coordinated to ensure the realization of those use cases.

<manu1> manu: Here are a couple of useful links for learning a bit more about Web Payments

<manu1> manu: We had a breakout session on Wednesday that provided a quick introduction to the space: http://www.w3.org/wiki/TPAC2013/session-web-payments

<manu1> manu: The minutes from the breakout session are here: http://lists.w3.org/Archives/Public/public-webpayments/2013Nov/0035.html

<manu1> manu: We are planning a W3C Web Payments Workshop during the last week of March 2014 in Paris, we'll notify this group when we put out the Call for Position Papers. As you can imagine, cryptography plays a pivotal role in this work, so we hope to have participation from members in this group.

<manu1> manu: If you want a technical introduction to the space, you can go here: https://payswarm.com/intro

<manu1> manu: If you want to join the Web Payments CG, instructions on how to do so are here: https://payswarm.com/join

virginie: <echoes hhalpin's IRC question>

manu: There are a variety of participants, not just browsers. Mozilla, Bloomberg, Orange. Additionally, several governments and banks "that are interested, but can't publicly commit yet". Very broad set of players with various, sometimes conflicting, interests

hhalpin: When the workshop is ready, an email to the list would be good

<manu1> Web Payments use cases: https://payswarm.com/specs/source/use-cases

virginie: Web Payments is a huge space. Can you keep something focused and specific, so it's not a matter of reading hundreds of pages of use cases?

manu: Sure. The core is "Web Payments exists. We're dependent on Web Crypto. We should work together"

virginie: Good action item is when you host the workshop, circulate on the list for participants, as well as report back on the workshop

JSON-LD signature requirements

<manu1> manu: Switching to a parallel track. There is one set of specs that deals with JSON-LD based digital signatures.

<manu1> manu: I saw that this group is dealing with the JOSE/JWK/JWT stack and has defined a key import mechanism for that.

<manu1> manu: The HTTP Keys spec (aka: Secure Messaging spec) defines a public key infrastructure built on top of the Web: https://payswarm.com/specs/source/http-keys/

<manu1> manu: In this specification, there is a way of expressing key information in JSON-LD. How do we import those keys using the Web Crypto API? Is there a way to extend the import mechanism for keys in the Web Crypto API?

<rbarnes> manu1: would be interested to hear why JOSE didn't meet your use case, but that's probably for offline

<rbarnes> no, there isn't :)

<hhalpin_> I think another key format would have to be justified.

manu: Main question is there a way to extend the import mechanism. Is there a generic key import mechanism

<rbarnes> jwk is so braindead simple, just use it?

rsleevi: Echoes IRC comments. No generic import, supports JWK, pkcs8, and SPKI - just convert your keys to that

manu: Mentions theres a blog post explaining why JWK wasn't sufficient, very long, may not be worth discussing during the F2F

<manu1> manu: Secure Messaging vs. JOSE: http://manu.sporny.org/2013/sm-vs-jose/

virginie: <Calls for any further comments on future work>

Workgroup life

virginie: Wanted to confirm that the current approach to the WG is working. Is meeting every two weeks productive?

<hhalpin_> +1

<sangrae> +1

<nvdbleek> +1

<virginie> +1

<jin> +1

virginie: Is meeting every two weeks helpful

<kodonog> +1

<mete> +1

-1

<rbarnes> ack

<mountie> +1 with time adjusted for asian members

<rbarnes> mistook the phone list for the queue

<rbarnes> agree with ryan that 2-week calls are not necessarily needed

<hhalpin_> Probably a co-editor would help progress more than more meetings

<rbarnes> might be worth having a longer call to look at LC comments

<rbarnes> well, a call of appropriate length for the volume of LC comments :)

<hhalpin_> I'm fine with either biweekly or monthly (every 4 weeks)

rsleevi: For Web Crypto API, not sure as much value from meeting every two weeks. Of course, WG has more than just Web Crypto API

virginie: As Chair, want to make sure members are aware of technical issues and have a chance to discuss
... Perhaps meeting for Web Crypto API once a month, and every other call discusses other topics (eg: Web Payments CG, future work, certificates)

<nvdbleek> 21:00 UTC is quite late for Europe when we go back to summer time

virginie: Next, there's been a request for rescheduling the call

<mountie> 1500 UTC / 8am San Francisco / 11am Boston / 4pm London

rsleevi: Requests that if we deferred decision making to the list, rather than phone calls, the choice of time for the calls would be less critical

<sangrae> +1

<rbarnes> +!

<virginie> +1

<rbarnes> er, +1

<mountie> +1

<markw> -1

<MichaelH> +1

<mete> +1

<jin> +1

PROPOSAL: Move meeting time to 1500 UTC

-1

<hhalpin_> +1

<nvdbleek> 0

<vgb> -1

<hhalpin_> Well, West Coast people are unhappy with 8:00 AM.

<mountie> 1600 UTC can be ok

<hhalpin_> Given all implementers are giving -1, we should take that seriously

<rbarnes> any later, and it will be even more unworkable for the asian crowd

<rbarnes> apparently the east coast is in the happy zone, so i don't care

PROPOSAL: What about 1600 UTC

<rbarnes> +1

<hhalpin_> +1

<mountie> +1

<virginie> +1

<sangrae> +1

<jin> +1

<vgb> +1 i can live with this though i don't know about israel

<MichaelH> +1

<mete> +1

+1 can live with it; especially if we move key decision making to the list

virginie: Ok, let's move to 1600, and if no one from W3C can make it, we can revisit
... also, can revisit decision making on the call

MichaelH: Can I request people on the mailing list provide some sort of indication to what they're replying to?

<hhalpin_> IETF is I think March 1-7th in London

rsleevi: +1. Some members' mail clients aren't configured ideally. W3C has various guides on mailing list etiquette. If you're not sure how your messages look, check the HTML mail archives

<hhalpin_> We'd have to have f2f *after* IETF or the week before the IETF meeting, as there's a Web Security workshop I believe during that weekend.

virginie: IETF is having a meeting in March. Would it make sense to co-locate a F2F near the IETF in order to have good overlap
... Question: Would it make sense to have a F2F in march

<nvdbleek> +1

<hhalpin_> Maybe can we ask "Who would come to London for a f2f"?

<rbarnes> i will be there for the ietf meeting

<rbarnes> would be willing to stick around / come early

<sangrae> +1

<virginie> +1

<hhalpin_> +1

<israelh> ?1

+0 - not sure if I'll be going to IETF, but if I am, I would be happy to stick around

<jin> +1

<mete> +1

<markw> +1

<rigo> +1

<kodonog> +1 (in the sense that I'll be there and would stay)

virginie: These answers aren't binding, just gauging interest. We'll only hold a F2F is there's an interesting agenda of topics to discuss. Will likely revisit this in January when we have a better idea of further work

Break for 30 minutes

<rbarnes> just my luck, the coffee maker here is missing critical parts :(

<rbarnes> i hate it when zakim is enigmatic

<wseltzer> [re-starting: code: 26631]

<virginie> hello, seems we are in...

<virginie> hello

<hhalpin_> Scribenick: hhalpin_

Sangrae_Cho: from ETRI
... future work for certificates
... will show demo and work on Certificate API

<jin> s/@@/sangrae

<virginie> http://www.w3.org/2012/webcrypto/wiki/images/e/e8/WebCert_Requirement_.ppt

<vgb> thanks!

<virginie> presentation is available on the link above

sangrae: the banking use case in Korea
... caserver.com issues a certficate to the browser
... public key pair is generated in browser
... then the user connects to bank.com and uses a signature generated by the client and gives it to the bank
... then there is a backchannel connection
... between cacserver.com and bank.com

MichaelH: What origin is this certificate generated for?

<MichaelH> ack

<mete> cert is issued to caserver.com

sangrae: key is generated with caserver.com origin

<jin> Answer is that certificate is issued by caserver.com.

sangrae: going to look at API

then same key is then used on *other* origin? i.e. bank.com?

That seems to be same problem we had last f2f with that design

sangrae: getCertificate UA->CA

s/getCertficate/gencCertificate

CA sends a handleRep -> CA

genConfirm -> CA

Discussion of Cert interface

israelh: you should probably take on Promises to make this async
... otherwise usual problem of blocking a UI thread

sangrae: discussion of how Apps fit on top of API, and then how ETRI implements API in browser on top of CMP and PKCS#11

<rbarnes> so, it's clearly possible to do CMP in JS, without any help from the browser at all. we have a polycrypt demo that makes self-signed certs; you could just as well make a CMP request. http://demo.polycrypt.net/tls/

israelh: are these all done in binary?

sangrae: not a plug-in, it's our own version of Firefox

<mountie> http://sangraecho.github.io/WebCert/WebCertAPI-1011.html for latest spec

sangrae: demoing the issue of certificate with password
... gets a Confirm Message
... then demos that ou can revoke it
... requires generatoion of public key, then import

MichaelH: You want to use WebCrypto for this?

sangrae: yes, if it's done in JS
... response is then pushed into CMP
... for digital signature verification and then storage of private key/cert to DB

MichaelH: How do you sign it with private key?

sangrae: It should be in memory or temporary storage
... requirements:

1) Private key wrapped/unrwapped using a password

2) Private key wrapped when not in use

3) Password policy required for strong password

4) Digital Singature API should support PKCS#7 or JOSE

5) Cert STorage API where API can access a key and certificate DB i browser

6) External secure device support, needs tpviate key to be sotred in smartcard/USIM in Kore (PKCS#11 compatible)

7) Guideline to suggest better UI

Israelh: Is that a secure store for the Cert object?

sangrae: yes

markw: Why not use indexedDB?

mountie: security concerns

markw: putting in indexedDB does not change where key is stored
... key object just a reference to key in smartcard

mountie: would prefer to store key in smartcard or then in OS

markw: still, why not place cert of key in indexedDB?

mountie: the second problem is we cannot keep same origin policy
... otherwise signature can only be generated on CA server
... this is too different from current architecture

MichaelH: Why not use postMessage to send it across?

israelh: but you'd have to give them permissions

mountie: but there's lots of infrastructure already prepared (lists them)
... certificate issued for human

israelh: certificate is assigned to human, not to domain
... you want to open it up to banks, but not everybody else

<virginie> to remote attendees : is the sound ok with you guys ?

mountie: it should not be used on serverside, but the user wants
... to override, then this is a problem
... they should be able to expose their certificate to any domain

<vgb> @virginie: occasionally a bit choppy, but understandable

<virginie> cool, and we have a great scribe (thanks hhalpin_)

<vgb> @virginie: but i just lost a few phrases from what Michael said back there

<rbarnes> MIC: this sort of user-controlled access is exactly what systems like OpenID and OAuth are designed to provide. they are all implemented using postMessage / redirects, without browser modifications. it seems like you could achieve the control you want using WebCrypto in that sort of framework.

<rbarnes> virginie: the sound is a little choppy, but basically OK. would help if people could stay close to the mic

(discussion of private key material threats and smartcards)

mete: what is indexedDB's security model?

israelh: per domain
... we have not specified how keys cannot be serialied and abused cross domain
... or you could create a special cross-domain "user domain" for certificates where user has a password to authorize access to that special storage
... but you'd have to certify your browser per solution unless you want to

markw: wherever key material is stored, it should not get more or less securiy if key reference is in indexedDB

israelh: but if I take that DB somewhere else

<rbarnes> markw speaks the truth

markw: but if key material is bound to a device, then you can't copy that indexedDB somewhere else and use it

israelh: what kind of veneer to you put on top of that storage?
... can you mount key references as a new database?
... that's what we need to figure out?

markw: do you need to see inside certificate on client side or can it be an opaque blob?

<rbarnes> israelh: i don't think it makes sense at all to have the card be another DB. it's just a backing store for keys, more or less transparently to the applicatoin

sangrae: you need to see it

markw: why?

<rbarnes> ... of course, there's an deep well of complexity in making smart cards work, which has no relation to this certs api

markw: I don't see why we need all of this certificate passing
... I generate key pair, send keypair, get some certificate

<israelh> answer to rbarnes: The reason is that you don't want to have the IDB infrastructure to be proxying requests to other stores. This creates a multi-transaction coordination between the IDB in the system and the smart card.

<virginie> scribenick : virginie

markw: why do you need to look at the certificate ?

sangrae: you are not always able to access the public repository

michael: the question is would the client ever look inside ?

sangrae: when it is expired, you need to update it, for example

markw: yes, but the CA would inform you about that
... looking inside at the certificate is not a simple think, as such I am looking for use cases

<rbarnes> x.509 in js: https://github.com/digitalbazaar/forge#x509

israel: mark says that if it is opaque, then we might not need to look at it...

michaelH: the fact is that the client shows you the certificate before u sign it

sangrae: the client can access the certificate sometimes, to edit, or just to propose it in a list

markw: yes, but the server can offer you the same service

mointie: is the server is compromised, it could be a problem
... the certificate should be kept to avoid that threat

israel: the reason why the certificate is kept, is I want to check my name is correctly written in it
... but is it goign to be managed directly by the client, sounds that no

markw: the server is usefull to serve you the appropriate and same information

sangrae: the server can not send you the certificate, you dont need to contact the CA, and use the local version to shop and go to your bank...

[other conversation i could not catch]

sangrae: going back to the requirement list in the presentation

http://www.w3.org/2012/webcrypto/wiki/images/e/e8/WebCert_Requirement_.ppt

israel: is the demo, when goign to the user asking for the certificate, do u expect that a user in real life will do that ?

sangrae: smart card is not used at the moment

mountie: today keys are stored in file system

<hhalpin> scribenick: hhalpin

<virginie> sangrae : in the future it will be secure token based

anders: one comment focuussed on CMP
... CMP is not an end-to-end solution
... the key container is the endpoint

<virginie> scribe : karen

<kodonog> scribenick: kodonog

mountie: we have different definitions of end-to-end

anders: if you are going to smart cards, you need to rethink provisioning

<virginie> adding harry in the queue

anders: end to end means different things, people to people, people to device
... end user's don't understand security

sangrae: lastly we need to a UI for certificate management & usage

virginie: misunderstood that you were presenting some new requirements
... apologize for deferring the discussion
... will go back to the working group to see if it is useful work

<MichaelH> ack

Anders: you want to have a PIN or password policy, how are you going to enforce that

sangrae: not sure yet, considering some options

virginie: this a big effort that will open lots of debate and controversial discussions,
... need to park this somewhere.

Israelh: how many banks or financial institutions have come to you to indicate that they are ready to go with this

sangrae: this is already in place, they want to standardize the feature

israelh: are you being proactive when you ask

mountie: if this is implemented in the browser major korean banks will move today

israelh: how quickly? a year?

mountie: within a year perhaps half the CAs will start the service (Korean)

sangrae: CA server doesn't have to be changed if put in the browser

mountie: major institute in Korea and working with a major
... certificate authority

Israelh: when will they be ready to deploy?

virginie: need to identify new features for v2 and get working group consensus

<mete> +1

QUESTION: who is interested in working on the certificate specification as it currently exists.

<rbarnes> -1

<mountie> +1

<jin> +1

<Anders> 0+ This is not related to webcrypto in its current form

<sangrae> +1

hhalpin: 2 things, certificate processing and same origin

<rbarnes> harry is inaudible

<israelh> hhalpin: another thing is CERTs that don't have the same origin.

<virginie> current version of the certificate api is available under http://www.w3.org/2012/webcrypto/wiki/Deliverable_web_certificate_API

sangrae: there are no same origin issues for certificate management

<Anders> vpns email and similar apps also needs a "cert api"

virginie: in the current version of the spec, you are using the same origin policy so there is no problem?

MichaelH: so you've issued a certificate, but you can't use it?

IsraelH: so that doesn't seem that useful?

sangrae: certificate management and certificate use don't have to be put into the same API.

israelh: if you do one specification that deals with one part of the problem without doing the other specification, you never have a solution

sangrae: i have a plan to do the other specification

<rbarnes> typing...

<rbarnes> this discussion was helpful in clarifying things

<rbarnes> i am not convinced that the *current* approach in the document is appropriate

<rbarnes> as israel and michael, etc, pointed out, there are several alternative approaches that have lighter requirements for webcrypto

<rbarnes> focus on coming up with the minimal set of things the browser needs to do

virginie: we should work more on this for future work
... we will revisit this on a regular basis

<rbarnes> to be clear: i am definitely supportive of solving the korean banking use case. it's just not clear that pushing all the cert stuff into the browser is the answer.

virginie: i have created a section in the wiki for future work.
... Leaders for the various pieces will be responsible for populating the wiki.

MichaelH: what is the usage, one bank, two banks... ?

sangrae: currently 5 CAs in Korea, people have a small but greater than one bank

<virginie> note to partcipants : future wirk will be maintained on our wiki

<virginie> http://www.w3.org/2012/webcrypto/wiki/Main_Page#WG_Future_Work

<rbarnes> no problem!

virginie: we can close the meeting, thanks for scribes, remote participants, local participants...

<rbarnes> being an irc lurker is kind of fun :)

<rbarnes> ciao everybody

<virginie> great work to scribes and editors...

- DRAFT -

Web Cryptography Working Group Teleconference

15 Nov 2013

Attendees

Contents

Buglist

Finishing Up Going through Bugzilla on API

WebRTC and WebCrypto

Wrap/Unwrap

Key Discovery API

milestones

Milestones: When do we want to go to Last Call

future work of WebCrypto

High level API for future work

Testing

V2

Manu to discuss Web Payments CG

JSON-LD signature requirements

Workgroup life

Summary of Action Items

Scribe.perl diagnostic output