See also: IRC log
<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...
<rigo> https://www.w3.org/Bugs/Public/buglist.cgi?quicksearch=web%20cryptography
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
<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
<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> <over/>
<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
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
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)
<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
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
<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
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
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
+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: <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
<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>
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> <over/>
<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> <clap clap clap/>
<rbarnes> ciao everybody
<virginie> great work to scribes and editors...
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/hhalpin: any/hhalpin, any/ Succeeded: s/hhalpin: ... requires/hhalpin, ... requires/ Succeeded: s/equesting/requesting/ Succeeded: s/???/PLC/ Succeeded: s/Michael/MichealH/ Succeeded: s/virgin/virginie/ Succeeded: s/ad/and/ Succeeded: s/didn't care/didn't care on this feature/ Succeeded: s/karen/kodonog/ Succeeded: s/burnes/barnes/ Succeeded: s/thin/think/ Succeeded: s/<something inaudible>/developers can implement their own high-level API, the low-level primitives are there/ Succeeded: s/2/14:00/ Succeeded: s/one/at least one/ Succeeded: s/this year/next year/ Succeeded: s/@@/Sangrae_Cho/ FAILED: s/@@/sangrae/ Succeeded: s/snagrae/sangrae/ FAILED: s/getCertficate/gencCertificate/ Succeeded: s/presenter/sangrae/ Succeeded: s/Scribenick: hhalpin/Scribenick: hhalpin_/ Found ScribeNick: kodonog Found Scribe: kodonog Inferring ScribeNick: kodonog Found ScribeNick: eroman Found ScribeNick: rsleevi Found ScribeNick: hhalpin_ Found ScribeNick: virginie Found ScribeNick: hhalpin Found Scribe: karen Found ScribeNick: kodonog Scribes: kodonog, karen ScribeNicks: kodonog, eroman, rsleevi, hhalpin_, virginie, hhalpin WARNING: Replacing list of attendees. Old list: vgb Wuzhou_east [Mozilla] New list: Wuzhou_east vgb rbarnes nvdbleek Default Present: Wuzhou_east, vgb, rbarnes, nvdbleek Present: Wuzhou_east vgb rbarnes nvdbleek Agenda: http://www.w3.org/2012/webcrypto/wiki/F2F_Shenzhen_Nov2013#Detailed_Agenda Found Date: 15 Nov 2013 Guessing minutes URL: http://www.w3.org/2013/11/15-crypto-minutes.html People with action items: hhalpin needs virginie[End of scribe.perl diagnostic output]