See also: IRC log
<trackbot> Date: 02 November 2012
<rsleevi> angeda+ Korean use case demo
<rbarnes> bonjour!
<rsleevi> scribe: Ryan_Sleevi
<rsleevi> scribenick: rsleevi
Reviewing http://www.w3.org/2012/webcrypto/wiki/F2F_TPAC_Lyon_Nov2012
virginie: Lots of different views
on what "high level" means, depending on peoples'
backgrounds
... need to come to a common definition/understanding of what a
high level API means
ddahl: Demo'd an API called
DOMCrypt at TPAC last year
... wanted to put well-designed crypto in the hands of people
who don't know crypto
... talking to Brendan Eich, mentioned "You're handing people a
gun, a footgun"
... high level, low level, both still fairly dangerous
... even a low level API tends to be an API wrapped in an API
wrapped in an API wrapped in an API
... question as to whether the original API was low level or
high-level
[ ddahl presenting an IDL ]
ddahl: always wanted something
high level
... looking over feedback from community, lots of people asking
"Where is the new crypto? The webby crypto? The API for web
developers"
... the low-level API is not necessarily that, very difficult
to approach if not versed in crypto
... lots of time going back and forth with rsleevi on outlets
like hacker news engaging community
... discussions with other Mozilla people, "no reason you cant
do both" - a high level and low level
... take something that just has a few methods, use JOSE for
all inputs and outputs
... hopefully end up with something that's pretty easy to
use
... very little choices for developers
... will not suffice for most use cases in this group
... but will give developers of new applications good
crypto
... no concerns for legacy/backwards compatibility
... entirely domain bound (same origin policy)
... methods such as "encryptAndSign" or
"verifyAndDecrypt"
... keys are mostly pairs, identified by an id
... mostly event driven
[ demo-ing example JS for this API ]
ddahl: The whole concept is to
make it as idiot proof as possible
... sort of an introductory concept
... want to investigate looking at perhaps two tracks
virginie: Is it too early for
technical details and discussion?
... WG needs to decide if it wants to engage/work on this
... question is whether WG feels it will detract from work on
low-level API
... do we need to re-design proposal, now that we have a
proposal, based on use cases?
... want to get comments in that sense
mountie: when we look at the
documents in the WG, we can see the secondary features
... and high level API is in secondary
... some interest in high-level APIs, but some interest in
other secondary features
... wasn't sure the distinction between secondary features and
if they were part of the high level API
... current JS mechanism is not ideal for non-unicode encoding
(eg: shift-jis)
... how will encrypt work and concerns about page encodings
selfissued: To the extent of a
high level, we should make sure not to go create new
formats
... if we do something at the high level, we should look at
produce and consuming JOSE data formats
ddahl: Sort of thought JOSE was assumed here
selfissued: Would be important to state it in the proposal
ddahl: The work going on in JOSE paves the way for this
selfissued: Curious why all APIs use public keys, but not symmetric keys
ddahl: Not designed yet
rsleevi: Existing platform APIs
tend to be just two APIs (protect and unprotect)
... mentioned OS X Keychain APIs, windows DPAPI
... wanting to understand the design rationale for this API
(encryptAndSign/decryptAndVerify) as opposed to something
called just "box" and "unbox"
ddahl: Not a full proposal yet. Possibly still not high-level enough. Considered "box" and "unbox"
hhalpin: clarification:
high-level and low-level API are different than the
primary/secondary features
... That is, high-level API does not necessarily mean secondary
features
... concerned that we're still not down with the low-level API
that covers all the primary features
... spending 3-4 months discussing high-level API, that's 3-4
months less spent discussing low-level API
... on a scheduling level, there's 2-3 important
questions
... Do we have enough time?
... Do we have agreement on a draft?
... Do we have agreement on what a high-level API should
be?
... If we do have time, and we should do it, do we do it as one
draft put out in time for our next heartbeat publication, or do
we do it after we've published a new low-level API
... Do you (ddahl) feel confident enough that you can put it
into a draft quickly
ddahl: Not quite happy with the
API as being proposed. Other APIs we can crib from (mention
Nacl's box/unbox).
... Think we can come up with something quickly, using JOSE for
formats
... as far opinions about scheduling, switching contexts, etc,
would want more opinions from WG
... personally holding out for a high-level API
... trying to integrate and address feedback/criticism from
public
drogers: I think there is an
argument for the API
... discussing recent papers/security research that came out in
the past few weeks regarding crypto being hard
... that APIs are technically correct, but combined in
misimplemented ways
... then when trying to fix the implementation, people make it
worse
... Can we as a WG make things easier/safer - default safe
even
<wseltzer> https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html
drogersuk: Convinced me we need to do something easier for people
mountie: thinks we need three
tracks
... low level for primary features, low level for secondary
features, high level
... concerned that secondary features have more priority than
high level API
... can one single high-level API cover multiple operations
that would be safe?
... normally designing web applications/services has some sort
of sequence of operations
... one single high level API can remove some common
mistakes
... but need secondary features
selfissued: the value of a draft
high-level API using JOSE formats is currently JOSE formats are
malleable
... to the extent that developing an API and using them,
discovering that there is a difficulty or mismatch, we can
course correct work in JOSE and this WG
... if we make a mistake in either group (JOSE, here), we can
fix them if we do it sooner than later
... that said, make it a separate work item from the low level
spec
... completely distinct from the low-level API
... with possibly a different set of editors
rbarnes: chiming in, +1 to the
davids (drogersuk, ddahl) and mike (selfissued)
... good that it can remove a lot of rope from the API
... question about choosing a lot of defaults for people
... is there a way to take concepts of smoothing out some of
the bumps that can make the low-level API easier to use, like
the high-level API seems to be
virginie: What were the actual
use cases that you think the current high-level API can
address?
... what is the story for this API?
ddahl: solves the sort of
chat/messaging use case
... solves document storage in the cloud
... not trusting the server
... local storage/encryption
<hhalpin> Should do a straw-poll just to see how many people "want to add this work-package?"
ddahl: personally would use it for conceptual ideas like "never use email", replacing it with a completely webby toolkit
virginie: How does key exchange
work in this API if key exchange is out of scope
... people want "one click crypto", where negotiation is part
of the API
ddahl: keyex is out of scope, but other APIs may be possible
rsleevi: this API doesn't really
work if you don't trust the server (eg: doc ex)
... So what's the security properties here
ddahl: it does somewhat, like if
you put encrypted data on a server, and that server is seized,
the data is still sitting on the server in an unopenable
state
... Chief use case is messaging
... Messaging has won the web. email is dying. This can fit in
with that
hhalpin: Given that there's a lot
of prior work with high-level APIs, it should be possible to
create a spreadsheet comparing other high-level APIs
... eg: keyczar, sjcl, nacl
... real question is given the amount of work needed on the low
level API, does this WG want to take on the low-level API
... originally during the WG, we did a survey from the
community re: high-level vs low-level API, WG said low-level
API
... PROPOSAL: straw-poll in the WG as to whether we should
adopt this in the WG
ddahl: Traditionally in DOM APIs,
we start off with something low-level, then abstract it higher
(eg: DOM -> jQuery)
... it feels to me that now that we've experimented with some
of the low-level API, it might be a quicker win to get
something to market by doing something very high level
<hhalpin> Note that I would like the straw poll!
rbarnes: Back to use
cases/stories, the upside of having all the prior art is that
we can choose what variety of things we want to support
... think it should be possible to support a variety of use
cases with a high level API
... thinks losing configuration/key management operations may
not be a bad thing
... thinks its an 80/20% problem, and 80% of problems can be
addressed by the high-level
<hhalpin> \me the real question is what is the crypto API for the 99% :)
rbarnes: seems like there is energy in the room to work on the high level
cjkula: not sure if high-level wrappers (ala jquery) can provide the same assurances that implementing in the browser
opoto: If the entire high-level
API can be implemented in JS using the low-level API, why
should we standardize the high-level API?
... looking at DOM vs jQuery - there have been many high-level
APIs adopted in the market (besides jQuery) depending on the
use case
... built on the common DOM/low-level API
... maybe this will be the case for crypto to - there will be
several high-level APIs based on different domains/use
cases
... should this WG impose just one?
... not convinced about imposing a single high-level API
mountie: David's proposal is
different that what I expected
... many Korean users expected high-level API to touch on
secondary features
... for these types of high-level APIs, there are so many other
developers, let other teams (like jQuery team) develop
them
... and we can propose low-level APIs, like secondary
features
markw: It would be a good thing
if people implemented JOSE libraries implemented atop low-level
API
... good if there were multiple of those, perhaps as student
projects
... help work out JOSE issues, help prove out the low level
API
... but it might be too early to jump into standardizing a JOSE
library
... JOSE library may not be that complex to implement in
JS
... wouldn't want this group to be distracted from getting the
low level API to work
... want to make sure you really have users and implementors
really driving for that work
... which there is for the low-level API
tlr: Confused by this
discussion
... considering this charter discusses where the high-level API
sits
... discussion here rehashes the chartering discussions
... need to decide if the WG can't meet the chartered goal, and
perhaps have a chartering discussion
... a bit uncomfortable with where this discussion is going
w/r/t charter
selfissued: response to markw's
comments
... I think there's value in prototyping an API that uses
JOSE
... proves out JOSE, proves out the low-level API
... sympathetic to mark's comments regarding whether it's time
to standardize
... can easily publish a draft leaving open a timeframe as to
when it actually becomes a standard
... building an end-to-end implementation is one of the more
valuable things we can do
markw: Agree that it's good to
implement, but not within this group
... people can implement and bring their feedback to the
group
... but don't start standardizing yet
virginie: many opinions within
the group
... Who is interested in this work?
... How will it be worked on? Seems consensus for secondary
doc
... seems like no one is opposing this work
... various questions to work out if this group decides to work
on a high level API
<hhalpin> PROPOSAL: Should the Working Group engage with a higher-level API as demonstrated by ddahl?
<ddahl> +1
<hhalpin> +1
<selfissued> +1
<drogersuk> +1
<cjkula> +1
<wseltzer> [Charter: The mission of the Web Cryptography Working Group, part of the Security Activity, is to define a high-level API providing common cryptographic functionality to Web Applications. "]
<sangrae> +1
<mountie> -1
+1
<opoto> +1
<rbarnes> +1
<wseltzer> +1
<wtc> +1
http://www.w3.org/2011/11/webcryptography-charter.html
<hhalpin> PROPOSAL: Who would volunteer to work on the higher-level API as a deliverable?
<ddahl> +1
<rbarnes> +1
<selfissued> +1
virginie: Sounds like this can be
done separate from the main WG, perhaps on a different
dedicated call
... would really like it to be clear what the use cases and
operations that this high-level will help
<hhalpin> PROPOSAL: The Web Crytpo WG adds a high-level API as a deliverable to the working group contigent on the activity level of those in the WG who volunteer for this task
<hhalpin> Any objections?
drogersuk: Doesn't a high-level API go against our charter?
[ laughter ]
<drogersuk> @rsleevi that's not what I said
hhalpin: Discussing the history of proposal as it stands vs low-level API during chartering
<drogersuk> the proposal as it stands goes against the charter
<hhalpin> To be more clear, I don't want this proposal to be interpreted as the "high-level" API taking priority for the entire WG over the lower-level API
virginie: If you say a high level API shouldn't disturb a low-level API, you can't force that. It's contribution driven. If ddahl focuses on a high-level API, that can affect the low-level API
<hhalpin> PROPOSAL: The Web Crytpo WG adds a high-level API as a deliverable to the working group that does not stop the low-level API
tlr: concerned about this WG working on two docs - market confusion, confusion within the group, confusion about the charter
<hhalpin> We could say "PROPOSAL: The Web Crytpo WG adds a high-level API as a Rec-track deliverable to the working group, and the WG does not stop work on its a current Rec-track API"
markw: Netflix's position was
always that what the charter calls for is what the WG is
working on now (the LG)
... So whether it's called high level or low level, it needs to
support the cases in the charter
drogersuk: Concern is not high-level vs low-level, but is it usable?
rbarnes: I'm not convinced at this point that there's actually separate documents, but the proposal implies it
virginie: Even if we've triggered some negative remarks with our low-level API, there are still people very interested in the low level API, so we should not abandon this work
<hhalpin> I was not answering the question of whether its one Rec-track document or two quite yet until we get the drafts further along.
virginie: Important to have it done as two separate efforts, so that we don't have a dependency between the two. We may merge them later
rbarnes: In agreement that this is mostly a usability concern
<hhalpin> virginie, perhaps re-open queue
<virginie> yeap
rbarnes: Proposes simplifying the low-level API
[ 10 minute break ]
virginie: in terms of priority,
main priority stays low-level API
... virginie and tlr to work on messaging and ensuring its
consistent
... high level API is worked on by a separate group in
parallel
cjkula: It didn't seem to me that
we didn't say we were never doing a high level API
... just that we had to focus on the low-level primitives we
needed in order to enable a high level API
virginie: We never made a decision to close discussion on high-level API
selfissued: Actually, we just closed that issue
hhalpin: When we started with
DOMCrypt, it became clear in a few calls that most of the use
cases would not be satisfied with DOMCrypt
... put out several proposals on IRC, didn't really get closure
on
<virginie> http://www.w3.org/2012/webcrypto/track/issues/7
ISSUE-7?
<trackbot> ISSUE-7 -- Deciding if we integrate a high level API in our deliverable -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/7
<virginie> issue 7 is related to do we work or not on high level api
hhalpin: regarding usability, there are sort of two different APIs going on within the cryptographic space
rbarnes: The distinction for me
is APIs that deal on octets and APIs that deal on data
structures
... there seems to be a bright line and we need to decide where
we sit
... on one hand, getting the octet based API is key, but it
needs to be simple
... current API is octets and not simple
<hhalpin> PROPOSAL: The Web Crypto WG adds a higher-level API as a Rec-track deliverable to the working group but does not stop the WG work on the current API
rbarnes: david's proposal is
simple and not octets
... we perhaps need something different
tlr: What I hear is there are a
set of use cases that correspond to a set of use cases that are
on the low level API
... things like OpenPGP, thinks those are distinctly not in the
charter
... hears use cases like what rbarnes said, I want to box
something, ship it up to a web app, send it to another server,
unbox it, not have to worry about it
... so what is the correct understanding of the high-level
API?
pal: What are the implications of adding something to Rec-Track in the context of the existing work?
<hhalpin> its really a matter of exposing parameters as well, not just operating on octets.
pal: Does it make that work contingent upon this work?
virginie: no
ddahl: When we talk about
high-level/low-level, I think we need to still have more
discussion on what the distinction between them
... What I'm thinking of when we talk high-level, I'm thinking
only consumes JOSE, or higher, and has little
configuration
... Has only two to four methods
virginie: The task of the contributors will be to explain the differences clearly
hhalpin: There were some use
cases that we thought we could with high level
... but after looking at the use cases we had, it was clear
they could only be accomplished with something lower
level
... it seemed that most of the use cases were actually
motivated by exposing configuration options and details
... it sounds plausible when you first think about it, that a
high level API can solve all the problems
... but it actually wasn't the case
... high level API hides the configuration details, which
intuitively seems good, but its not clear yet what use cases it
identifies
tlr: It's important that everyone in the group has a shared mental model for this work
rsleevi: We need to have an
understanding as to what *is* a high level API
... would like those who want to work on a high level API to
actually put a proposal forward to make it clear what they
think a high level API is
ddahl: I never intended DOMCrypt to address all the use cases. Just those use cases related to messaging
<hhalpin> PROPOSAL: The Web Crypto WG attempts to define a draft higher-level API as deliverable but not stop work on the current API
<hhalpin> Any objections?
<ddahl> +1
<mountie> +1
<sangrae> +1
<wtc> +1
<selfissued> +1
<JonathanJ1> +1
<cjkula> +1
<hhalpin> +1
<opoto> +1
<hhalpin> You can abstain explicitly Markw
<hhalpin> RESOLUTION: The Web Crypto WG attempts to define a draft higher-level API as deliverable but not stop work on the current API
<hhalpin> ACTION: ddahl (and others) to bring back functions and a draft WebIDL for the higher-level API [recorded in http://www.w3.org/2012/11/02-crypto-minutes.html#action01]
<trackbot> Created ACTION-62 - (and others) to bring back functions and a draft WebIDL for the higher-level API [on David Dahl - due 2012-11-09].
<hhalpin> ACTION: virginie and tlr to handle any concerns from public and communications about WG's work [recorded in http://www.w3.org/2012/11/02-crypto-minutes.html#action02]
<trackbot> Created ACTION-63 - And tlr to handle any concerns from public and communications about WG's work [on Virginie GALINDO - due 2012-11-09].
<wseltzer> [break]
<wtc> scribenick wtc
<wtc> Zakim: scribenick: wtc
<wtc> markw: the discussion of ISSUE-25 will start at 11:30
<wtc> virginie: I suggest we discuss the security framework during the 20 minutes before 11:30.
<wtc> ... we have been discussing the security assets that are coming together with our API.
<wtc> ... Security Framework: building a common understanding on what the Web Crypto API brings to the web security
<wtc> virginie: received questions about the actual value of our API after the FPWD was published.
<wtc> ... (goes over the slides of the presentation)
<wtc> ... security features of the API is left to UA know how. Crypto capabilities rely on OS capabilities.
<wtc> ... Web app quality evaluation is left to the user. The actual security of the API is left to implementers know how.
<wtc> ... such as: *integrity of the API, *local storage protection (TPM, secure elements, etc.), *WebApp identification/execution
<wtc> ... The value of our deliverable is: * standardizing the functional behavior of crypto operations, * help developers use the crypto operations correctly, * include the features of secure elements in the API (an controversial issue).
<wtc> virginie: I pose two questions to the working group:
<wtc> ... 1. why not writing down this value propositon? 2. can we make it better?
<wtc> virginie: any questions?
<drogersuk> http://w3cmemes.tumblr.com/image/34766205708
<wtc> hhalpin: we should have stated up front this is an API that adds new capacity to web apps but doesn't changes the security aspects.
<wtc> ... it might be useful to add a few brief sentences to clclarify that. We seem to have done that.
<wtc> hhalpin: this should be in the first paragraph or even the abstract, not in section 5.
<hhalpin> Well, what I was suggesting to be exact was that we have a *very* brief mention of these in the intro and status parts of the API, and then point people to the Security Considerations in Section 5.
<wtc> rbarnes: I agree we should have a forward reference of the security considerations at the beginning of the API spec.
<wtc> scribenick: wtc
markw: would be useful to
enumerate the security models relevant to this API.
... there are models that have different levels of trust for
the user agent and the JavaScript code.
<rsleevi> ISSUE-21?
<trackbot> ISSUE-21 -- Requiring Content-Security-Policy -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/21
mountie: for ISSUE-21:
content-security policy
... Tobie of Facebook talked about the protection of JavaScript
code yesterday.
... It is our role to suggest a solution for the integrity of
JS code.
hhalpin: a question for tlr: we
need one or two sentences at the beginning.
... Is there a document from the WebAppSec group that we can
point to?
tlr: I think it's useful to describe the security models and how our API behaves in the security models.
drogersuk: the security and
threat models, we have to decide which are in scope.
... the dependency on the work of the WebAppSec WG -- should we
iterate...
<hhalpin> To be clear, I was suggesting that we work on this document *with* WebAppSec WG if they already have a document they are working on. The other option is for us to try to work on that document by ourselves.
virginie: if we have an internal document describing the security models we have in mind, with someone editing it, then we can have a liaison with the WebAppSec WG.
drogersuk: 1. we have to make it
clear we have a direct dependency on the security and threat
models.
... 2. We need to say "security and threat" model, not just
security model.
virginie: who would like to lead that? drogersuk?
drogersuk: I'd be happy to help. I won't be able to commit until January.
virginie: can you come up with a description of the security and threat model for this WG, that would be helpful.
tlr: WebAppSec doesn't usually work on crypto issues.
drogersuk: how do you think the liaison between our WG and WebAppSec WG would work?
rbarnes: the easiest thing to do would be draft up some text and take it to the WebAppSec WG.
hhadlpin: most of the reviewers were looking for security considerations for "users".
rsleevi: there are no real differences in security considerations for this API and, say, full screen mode.
<virginie> Security considerations in the spec http://www.w3.org/2012/webcrypto/track/actions/55 and http://www.w3.org/2012/webcrypto/track/actions/52
<virginie> some actions that may answer harry expectation from the spec
rsleevi: my view as an implenter
is there is no fundamental difference between this API and
storing keys in the local storage.
... there is nothing special.
<pal> time check
rsleevi: if you need constant-time crypto operations, then this can best be provided by our API. This is why the security considerations focus on developers.
drogersuk: when people hear crypto, people expect security.
virginie: next topic is ISSUE-25: Global Unique ID for pre-provisionned symetric keys
<rsleevi> ISSUE-25?
<trackbot> ISSUE-25 -- How do we provision Global Unique ID for pre-provisionned symetric keys -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/25
<hhalpin> ACTION: drogersuk to draft security and threat model for WebCrypto API given considerations of Web Application Security Model [recorded in http://www.w3.org/2012/11/02-crypto-minutes.html#action03]
<trackbot> Sorry, couldn't find drogersuk. You can review and register nicknames at <http://www.w3.org/2012/webcrypto/track/users>.
virginie: ACTION-17 is associated.
virginie: markw provided a proposal on Oct. 29.
<virginie> http://lists.w3.org/Archives/Public/public-webcrypto/2012Oct/0131.html
markw: we had an action item to
propose global unique IDs for pre-provision keys.
... if you need to use a pre-provisioned key, you need an
identifier on the server side to look up the symmetric
key.
... we want a common way for TV manufacturers for
pre-provisioned symmetric keys.
... we are interested in origin-specific pre-provisioned
keys.
... if user agents need pre-provisions keys for different
origins, those should be different keys.
... I suggested deleting the text about suggeting deriving keys
from a master key.
... the main part of the proposal is the designate a property,
"uid" for pre-provisioned symmetric keys.
... rsleevi suggested we should specify the properties of the
"uid" property.
... the proposal s
http://lists.w3.org/Archives/Public/public-webcrypto/2012Oct/0131.html
ddahl: is this property optional?
markw: yes, it has to be
optional.
... depends on the aplications whether they want to provide
it.
ddahl: I have seen specs with optional items like this that caused problems.
rsleevi: my concern has been this
optional attrbute will never be implementable in desktop
browsers (as opposed to TVs or devices).
... I wonder how much of this has to be specified, and how much
of this should be left to the video streaming industry and the
device vendors.
pal: what does an "optional" unique identifier mean?
rsleevi: there are ways to
uniquely identify a symmetric key.
... my concern is as an implementer, if I read the spec, I
don't know if I need to implement it.
markw: the spec is http://lists.w3.org/Archives/Public/public-webcrypto/2012Oct/0131.html
virginie: do you see any means to make it better?
<markw> http://lists.w3.org/Archives/Public/public-webcrypto/2012Nov/0012.html
markw: correction: the proposal
is
http://lists.w3.org/Archives/Public/public-webcrypto/2012Nov/0012.html
... this clarifies what the identifier would look like.
... some text characterizing the global unique identifier.
<markw> The second email is extended text to be added to the first
hhalpin: there are two options we
have. It's clear not all implementers are going to implement
"uid". The issue is where to put it in the spec.
... option 1: in the spec, but mark as optional. option 2: not
specified in the spec.
markw: putting in the spec will save some messy code that needs to be written by developers (if different vendors use different properties).
rsleevi: putting it in the spec
won't resolve the ambiguity to the implementors.
... I don't know how consistent this will be.
... I don't know if we have enough people with the right
background to know if this is the right global unique
identifier to standardize.
pal: assigning a unique
identifier to a key is not an exceptional thing.
... if the semantics of the id is the id shall be unique, then
it's up to the provider of the id to make sure it is global. I
don't see the downside of specifying an optional uid
attribute.
hhalpin: what we need to decide
is whether to put this in "extra attributes" or as an
(optional) first-class attribute.
... is there any other member of the WG, besides Netflix, who
would like to use "uid"?
markw: I just need to standardize the attribute's name and semantics. It is fine to us for it to be in the "extra attributes".
<hhalpin> so just to clarify, its part of "extra" in 10.2
<hhalpin> thus, it should be clear to implementers that its optional, but we need some more text around "extra"
markw: we (Netflix) would be
implementing the user side of it...
... the Web Crypto API will be on our list of web/HTML
technologies for device manufacturers.
virginie: speaking as Gemalto, I
see some value of this feature.
... speaking as the chair, I see there is a "market" probem,
but not a technical problem.
<markw> I suggest we ask the Web & TV Interest group for opinions on whether the proposal meets the requirements they have raised earlier in the week
virginie: The market problem: markw should make it clear it's the market, not just Netflix, that is interested in it.
pal: it's clear there is
interested in this feature.
... I am interested in understanding whether there are
technical challenges for implementing global unique
identifiers.
rsleevi: we have several members
of the WG who have participated in the WG since the beginning,
and the features they want are not yet in the current API
spec.
... the technical challenge is "you know it when you see
it"...
... in addition, pre-provisioned keys have different security
attributes than "browser-mediated" keys.
... there are some user tracking issues with the global unique
identifiers. These have to be considered.
... we should focus on features that improve the security of
the current state of "JS crypto" on the web...
markw: if we have to drop features, we should drop features that don't have a proposal.
drogersuk: the tracking
aspect...
... maybe we need to think about it more and rewrite it.
pal: thank you (rsleevi) for
pointing out the issues.
... if there is interest in a global id, it will help
interoperabilty...
hhalpin: we should write a
proposal.
... it's clear the focus is on a uid attribute, minus the
certificate aspect.
... as long as it's clearly labeled as "extra", it should not
confuse implementers. This is one proposal.
... the other proposal is to continue discussion until the
proposal is worked out ...
rsleevi: I am concerned about how fast we can find consensus on a minimum set of features.
drogersuk: we can't let this descend into the debate of PCs vs. other devices.
selfissued: since markw has done the work of writing up a concrete proposal for their use case, it would be good for the working group to consider his proposal...if it meets the editors' requirements...
<hhalpin> PROPOSAL: Accept Netflix's proposal for a uid under "extra" minus the certificate aspect, as long as the technical details are worked out to the editor's satisfaction
<npdoty> scribenick: npdoty
virginie: we are here just to
provide an API
... slide with members of the WG, 53 participants
... 10 to 20 people on a weekly conference call
... 11 invited experts too
... deliverables: Web Crypto API, currently in FPWD
... wiki list of use cases, which maybe will move to an actual
specification
... have started to discuss security
... a "high level api", an abstraction
... Use Cases for Web Crypto
... client confirming the integrity of data, p2p communication,
protected storage (local or remote)
... just a wiki page at the moment, clear among the WG but want
to formalize
... Web Crypto API
... great job by the editors, Ryan and David
... generate, import, export, encrypt, decrypt, sign, verify,
digest, rng
... recommended set of algorithms, but not mandatory
... 30 issues at the moment
<odinho_> i/scribenick: npdoty/Topic: Joint meeting, Crypto and WebAppSec
virginie: would like reviews from
WebAppSec
... possible collaboration with WebAppSec
... received some comments that this is a dangerous API because
it requires expertise, because JS is not secure,
because.....
... decide explicitly the value of this API, write down which
security problems we are responsible for and what we are
not
... the "API value proposition"
... could collaborate because you know the state of the art of
web security
... links! [help the scribe by dropping them in please]
<sgodard> slide links please ?
bhill2: can introduce the scope of webappsec work....
<virginie> Our main page http://www.w3.org/2012/webcrypto/
<virginie> Our wiki http://www.w3.org/2012/webcrypto/wiki/Main_Page
bhill2: three deliverables that may have some to little relevance for what crypto is doing
<virginie> Our mailing list http://lists.w3.org/Archives/Public/public-webcrypto/
bhill2: least to most
relevant:
... 1) clickjacking vulnerabilities and secure mashups across
origins, embedding iframes and other content
... confusing user interface, breaking the visual integrity of
a page when it's embedded
... nothing cryptographic in the response, more about
heuristics and comparing visual images
... richer than today's X-Frame-Options header
... a policy model with a feedback channel, more fine-grained,
to enable integrated mashup applications currently considered
unsafe
... 2) content security policy, about to go to CR next
week
... reducing the attack surface of applications to injection
vulnerabilities, like XSS
... voluntarily declare a more-restrictive least privilege
environment, limit which origins are allowed for embedding
images, scripts
... be able to white-list the origin of external content
... in 1.1 of CSP, discussing only inline script blocks that
match to a hash or similar; may be comparable to signed
applications
... start with the assumption that the DOM environment is
untrusted, so would probably want cryptographic enforcement to
be done in the user agent rather than in the DOM itself
ekr: +1
bhill2: so I'm not sure those
elements would be consumers of a DOM-based crypto API
... but if you were producing formats for cryptographic
signatures over a block of JavaScript, that could be a
reference or joint work with webappsec
... what's the format of the thing you're going to sign?
... 3) cross-origin resource sharing (CORS)
... xhr between domains in a more secure fashion
... allow for permission-relaxing by a resource declaring that
it can be accessed more permissively across different
origins
... developers may be interested in applying different security
services for resources that were fetched from a cross-origin
request
... always recommend in security considerations that you do
some verification of the content that is retrieved
... for data that wasn't confidential but needed to have
integrity
... an area where developers would be most interested in using
the two groups' work in concert
... what's the canonical format for signatures of
content?
... going to be re-chartering soon, contemplating deliverables
around link fingerprinting/hashing -- an attribute of an HTML
tag/URI including a hash/fingerprint of a resource
... could include large javascript libraries or other blobs and
verify that they haven't changed
... I want to load this analytics javascript from a 3rd-party
site, but want to make sure it's a particular version that I've
code reviewed
... don't want my site to be compromised when the 3rd-party
host has been compromised
... regarding performance, can more effectively use CDNs and
other types of caching
... just in the strawman idea phase for a possible
charter
... overlap with this group in delivering signed objects
odinho_: XHR is a common use of CORS, btw. img feth for use in canvas, eventsource, track element/video, fonts etc are other uses as well :)
bhill2: csp going to CR next
week; CORS is hoping to go to PR once we have test suites to
prove that interoperable implementations are ready
... hoping to go to Rec in the next 4 to 6 months
... clickjacking to go to Rec in the next 12 to 18 months,
depending on implementations
... csp will probably be at fpwd later this month, maybe Feb
2014 for Rec
... rechartering, not sure whether the new deliverable (link
fingerprinting) will spark controversy
... ~3 month process
... expect that would be a one year time frame, to Rec around
Feb 2014
@@: any approach if the user environment is compromised?
<rsleevi> s/@@/mountie/
bhill2: minimize the impact of
injection vulnerabilities by setting a strong least-privilege
policy
... prevent some of the cases where reflected vulnerabilities
will turn into active content
... everything is only best effort, resource owners won't know
how much the user agent has implemented
... just prevent the execution of content
... a defense in depth measure to reduce attack surface and
privileges of resource, so that the damage is limited when
compromises happen
virginie: you have a long section in your spec to limit your own liabilities?
bhill2: yes. I think it's not our
group's purpose to tell the Web platform what it should/should
not do
... security can't just be on the server side any more, our
group was chartered with the idea that applications are
full-fledged and need security capabilities on the user agent
side
... in fact, the UA is the only place where some of these
defenses can be built
... we are working on the same assumption that the web app is a
first-class citizen
@@@: we all assume that the features will be there and that developers will screw them up <laughter>
hhalpin: when we asked for public feedback, we got feedback on the nature of our algorithms, but also got less helpful feedback via twitter
<rsleevi> s/@@@/Ryan_Ware/
<ware> s/@@@/ware/
<bhill2> http://www.w3.org/2001/tag/2011/02/security-web.html
hhalpin: still trying to clarify
our high-level view of what our purpose is, drogersuk
volunteered to edit
... might be interesting joint work between our two groups
(since CSP also has specific limited scope)
... 2) link-fingerprinting is similar to a request from tobie
about storing resources in local storage to prevent constant
reloading over the network
... 3) both want feedback from the crypto community, the
security community and from the web app developer
community
... how can we get an adequate level of review that we're not
sure that we have that you have received?
bhill2: document from the TAG,
presented by larry masinter, as an input document
... what are the security properties of the Web and what is the
history of the model
... might have more bandwidth available to pick up these
non-normative and definitional documents
... maybe something I should include in our rechartering
discussions
... room for joint work with web crypto
... architecture documents that don't exist, like documenting
what is CSRF
... would be nice to have a real, peer-reviewed explanation
rather than just pointing to (in the academic fashion) the
first instance, which might just be a short blog post
[scribe not following this response]
bhill2: the hard part is canonicalizing the boundaries of signing
mike: JOSE specifically takes the position that no canonicalization will occur, just base64 everything including white space, so you can sign or encrypt anything without canonicalization
<DanD> +q
<hhalpin> I believe bhill2 said that "Yes, there are a lot of use-cases for integrity checks on content, but the problem is not API-level but on the level of the boundaries of said object in its context in the DOM"
bhill2: not sure that works for
everything that looks like an HTTP resource
... might care about more than just the body of the resource,
including headers that affect the security properties
mike: if you're signing a structured thing you still have to solve the problem
bhill2: while I'm an advocate of "don't canonicalize, just sign the byte stream", I don't know if that will work here
mountie: which vendor is working as an implementer? @@@@
bhill2: lots of implementations
of CORS even in niche mobile browsers; CSP has both a Chrome
and Firefox implementation; partial implementation of sandbox
features by IE
... Opera is a member, complete implementation of CORS, not
sure about the other features
... user interface safety built in a firefox plugin, and
willingness to build in
rsleevi: opportunities for more
overlap; within our current spec we're not addressing the "key"
security concerns
... things that you cannot consistently implement in a JS
environment
... but key security is critical in understanding the security
model
... using origin-based security for keys -- good because it's a
consistent model
... but potentially grants an entire origin the possibility to
execute operations with keys
... could use a path-based model like in cookies, or
expiration
<tlr> relevant: http://w2spconf.com/2008/papers/s2p1.pdf
<hhalpin> Perhaps we should list our WebAppSec related issues
rsleevi: a similar concern (to
CSRF) is going to exist with keys which are used to
authenticate a particular request
... if an app can perform a key operation, it might have the
same technical effect as sending a particular cookie
through
<hhalpin> http://www.w3.org/2012/webcrypto/track/issues/21 Requiring Content-Security-Policy
bhill2: we are chartered to do joint work with the ietf websec working group
<hhalpin> http://www.w3.org/2012/webcrypto/track/issues/26
<hhalpin> Should key generation be allowed to specify multi-origin shared access
bhill2: justifying why CORS isn't
making it worse, and writing up a non-normative document
explaining why would be helpful
... purview of the ietf websec group, with which you might want
to have more formal liaisons
... certainly willing to provide security reviews
<hhalpin> http://www.w3.org/2012/webcrypto/track/issues/33: arify text in section 5.1 with respect to how key tainting is handled with multi-origin scenario
bhill2: finer-grained origins
probably a bad bad idea
... header that specifies which resources shouldn't be given
access to the crypto (resources that are user-generated or
somesuch)
... send an email to our group's list documenting those use
cases
... something we're willing to consider
drogersuk: volunteered to build
the threat/security model
... based on the general feedback, developers see this inherent
link between crypto and security
... we have a direct dependency on the security model of the
Web
... should clearly map that out for some of our detractors to
be able to answer them quickly
... understand our level of robustness
... can make a meaningful statement about what threat models
we're protecting against
... protecting media content vs. protecting dissidents in
hostile countries, vastly different use cases
DanD: <shepazu/villager
joke>
... Web security for dummies documentation could be in the
WebPlatform docs
<tlr> very good point
DanD: currently have just a stub, but we could have a lot of hierarchical documentation there
<drogersuk> +1 to Dan's points
DanD: that's where you could document the threats
npd: +1, and we've talked about that as a place for documenting privacy practices for Web developers as well
shepazu: like a11y, like i18n,
should be documented across
... happy to work with anybody to help make that a reality
hhalpin: would be good to get an opinion on these currently open issues so we can close them
issue-21?
<trackbot> ISSUE-21 -- Requiring Content-Security-Policy -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/21
hhalpin: different opinions on these, is this orthogonal? is this something we need to guide implementers on?
issue-26?
<trackbot> ISSUE-26 -- Should key generation be allowed to specify multi-origin shared access -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/26
issue-33?
<trackbot> ISSUE-33 -- Clarify text in section 5.1 with respect to how key tainting is handled with multi-origin scenario -- open
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/33
hhalpin: should we have some
multi-origin key generation?
... need to decide that at some point in the next year; could
use feedback on
<hhalpin> opinion on these issues in IRC would be great even
virginie: can collaborate on our
api security value
... use cases on signing of javascript
... review respective specs
<hhalpin> since the first is clearly related to how to do security considerations in general, even though it calls out CSP in particular
virginie: come to each other's groups regularly
<hhalpin> the second two are of course similar to issues brought up by CORS
virginie: ask for feedback on
specific issues
... at least we now know each other
<kicks everyone out :)>
<mountie> http://prezi.com/ic9jbxr7u0wq/present/?auth_key=gftap1b&follow=xcv2fpybjd1u
<wseltzer> ScribeNick: wseltzer
mountie: showing
http://prezi.com/ic9jbxr7u0wq/present/?auth_key=gftap1b&follow=xcv2fpybjd1u
... credit card processing as common in Korea, using
certificate previously issued to browser
... [screenshots: certificate, plug-in, user selects bank,
enters info]
... [UI for national certificate-related plugins; user enters
password]
... activeX plugin for Korean national government tax website;
visit site, requests to install plugin
... user clicks yes, next login attempt, another plugin
requests to install
... loading time about 3min30
... [video showing website: http://www.hometax.go.kr/]
selfissued: accepting an activeX control
mountie: another provider's
plugin
... now, no more plugins required, users enter ID and
password
... user gets requested to reboot os, then finally successfully
logs in
... showing digital certificate stored in the user's
environment; issued based on face-to-face verification at bank
branch
... stored in smart card or @@
... users are educated to "yes" on all plugins, became a
national security hole
... IE about 65%, so only 65% of users can make payments using
this binary plugin
selfissued: plugins don't work in other browsers?
mountie: mostly, no
... plus, metroUI doesn't allow any plugins
... regulations force the use of binary plugins . EFTA,
Consumer Protection Act, Privacy...
[slide: technical requirements by regulations]
mountie: slide shows how
requirements currently met by ActiveX could be implemented in
JS with WebCrypto
... requirements: identify and authenticate; encrypt
transmission; non-repudiation; protect user environment
... on-screen keyboard=mouse-based visual keyboard
... to defeat screen-scrapers, one of the requirements
randomizes keys
... [slide: special interests]
... SEED, Korean standard alternative to AES; Certificates
ekr: threat model? who does the
certificate validate?
... why do we need validation on the client-side?
... only the browser chrome can check validity, not the JS
provided by the site you want to check.
rsleevi: or plugins, SysAPI-level, but not JS
mountie: we want to minimize requests to users to verify
<rsleevi> correction: point was to use SysApps - but not exposed/implemented in content JS
ekr: suggest an additional
scoping restriction, to origin *and* national PKI
... if the security property you need is to have browser
enforce that signatures in this system are only those from
national PKI; JS validating server cert just can't work unless
you're in sysapps-installed-apps mode
<ekr> What I would suggest is simply a signature mode which includes trusted attributes over the origin of the JS.
<tlr> ekr, q+?
<ekr> yeah, I guess so. q+
dme
s/dme//
mountie: government is planning
to revise regs
... current regs have two tracks: binary plugins and web
applications audited by government committee
... second route instigated by iPhone
... 2010 regs changed to allow non-plugin electronic
transactions
ddahl: what's being typed in?
mountie: usually a password
ddahl: probably encoded in
Korean-language codepage
... also, all these URLs are http. Is there lots of fraud?
mountie: hacking and keylogging is a problem
ekr: it would be useful to describe the threat model and implied security demands, rather than starting from the end of the tentacle as the system is currently designed
<hhalpin> We can check digital signatures with pre-provisioned keys I think.
wseltzer: let's try to understand the problem and its security requirements off-line
rsleevi: we want to help; we
don't want to help by implementing insecure "solutions"
... it would be bad if we just tried to implement what exists
in CryptoAPI; let's try to find the solution broader than
WebCrypto
<tlr> ScribeNick: tlr
mountie: @@
rsleevi: as implementer,
something we care a lot about. Would like good solution on
technical merits.
... not sure if there's an action item -- there is engagement
to be ha
... would like to be sure we can implement or deploy
... maybe an action item to take
... don't think the way things are done today aren't good
technically
mountie: don't expect every
browser vendor to implement it
... work on alternatives
... if vendors are ever to implement, then that would be
beneficial
<hhalpin> its a prezi, so I believe mountie could add the URI to IRC once he has a sec
virginie: still important to
understand use case better, then we can understand solution
better
... recommended minimum set of algorithms -- not sure that was
part of list?
... has to be discussed further
<hhalpin> SEED was not part of the list, I think SEED is in Firefox, but is it in Webkit?
virginie: think it's feasible to
at least describe the algorithms you would need
... certificate management is a borderline feature
... signed javascript?
mountie: webappsec?
... want to find out how to allow multi-origin access
... can discuss more
virginie: discussed with Brad Hill about signed JavaScript
<hhalpin> So SEED support is not currently an outstanding issue for at least desktop, but is a problem for mobile rsleevi?
virginie: important question - what are boundaries of code so you sign appropriate information?
<ekr> I don't have a problem with assigning a code point for SEED, but I hardly think it's appropriate to recommend it.
virginie: @@
<rsleevi> hhalpin: Requiring SEED won't work, but I am 100% supportive of specifying how SEED should behave IF a UA implements it
<hhalpin> I guess what I'm trying to figure out is should we add SEED to the API as an option, although not in the minimum required set.
mountie: interesting in JS functions - JS validation, require complex design. How protect js code?
<rbarnes> hhalpin: i didn't know we had a minimum required set
<rsleevi> hhalpin: And I'm saying yes, we should. Mountie has made a proposal to the list to do just that, and I have no objection to it
<ekr> rbarnes: I don't think so.
<rbarnes> in fact, i thought we explicitly said we *weren't* going to have any required algorithms
hhalpin: want to be clear about
what can and can't do
... digital signature component might be part of this
rsleevi: web crypto is a component part of any solution that is meaningful to Korean use case
<ekr> seed is an alternative to AES
hhalpin: not quite sure where in the flow seed is at
rsleevi: support adding seed -- any algorithm that is meaningful
<hhalpin> However, would adding SEED actually help this use-case?
rsleevi: there are things that can't be done in JS, but Web Crypto is well positioned to do.
<ekr> ROT13
<hhalpin> We could add SEED as a matter of principle, but having a use-case would help.
<ekr> Actually, we should do triple-ROT13. It's more secure
ekr: no problem adding SEED
... any algorithm that is plausibly defined
... I would have problems with very weak algorithms
... certificate thing- very marginal case for any application I
have seen yet
... that brings us down to signed JS -- that belongs in
sysapps
... SEED should be optional, not recommended
<ekr> my point is that certificates should be a tertiary feature
<wseltzer> tlr: many countries with similar requirements and similar flaws; opportunity to get together to understand the requirements better
<wseltzer> ... among implementers, country-based participants
<wseltzer> ... window of opportunity to understand this set of markets and their needs
<hhalpin> one way to operationalize this, off the top of my head, would be to detail out the use-case
<wseltzer> ... W3C could help to provide a forum, CG or BG; we'd need help from implementers and contacts
<hhalpin> and then seeing if we need to drag in other WGs from both IETF and W3C
<wseltzer> virginie: Arun compiling use-cases
<wseltzer> rsleevi: as implementers, we've been having these conversations, we think it's important
<wseltzer> ... as far as timing, start with the places API can be ussable now
<hhalpin> and then if that goes through, there's always the possibility of a W3C workshop in the future on this particular topic, not just for Korea but for similar countries
<hhalpin> So I think I am hearing we get an action to add SEED as an option?
yes
<wseltzer> ekr: Certificates are a tertiary feature
<rsleevi> +1
<hhalpin> rsleevi, you happy with an action to add SEED?
<rsleevi> @hhalpin: Yes
<wseltzer> virginie: we'll work on the use cases.
<wseltzer> ... Thank you, mountie
<hhalpin> ACTION: rsleevi to add SEED to WebCrypto API [recorded in http://www.w3.org/2012/11/02-crypto-minutes.html#action04]
<trackbot> Created ACTION-64 - Add SEED to WebCrypto API [on Ryan Sleevi - due 2012-11-09].
<wseltzer> selfissued: that video looks very complicated. How many Korean users can get through it?
<wseltzer> mountie: Korean users are well-experienced clicking-through
<JonathanJ1> mountie's demo is very normal case in korea.
<wseltzer> rsleevi: there are many moving parts here, we want to get it right
<wseltzer> [break]
<wseltzer> ScribeNick: wseltzer
virginie: I was planning a
summary, but my brain is fried
... take-aways:
... address a few logistics issues
<hhalpin> notes that we also had a request to change meeting times
virginie: next F2F. I'm used to 4x/year, but W3C tends towards less frequent.
rsleevi: I'd suggest East Coast; estark, rbarnes
rbarnes: I could look at Boston options
ddahl: Mozilla Toronto
<rbarnes> … or dc
mountie: We could host in Korea
virginie: Looking at March dates
rbarnes: IETF is March 10-15
[Orlando, Florida]
<hhalpin> March 9-17 is SXSW
virginie: I'll organize a poll for where/when
<hhalpin> We can be flexible, we don't have to meet exactly every 4 months, but a few weeks in or out should be fine
virginie: Next, conference call
timing; old action item to look for time that's better for
Asian participants
... What about 8AM San Francisco; 11 Boston; 1600 France;
midnight Korea
hhalpin: 8 is possible but early for west coast
<hhalpin> It does not sound early but I have noticed last time that I tried to do a WG with this proposal people fell off.
<JonathanJ1> I think we can host next F2F meeting in Seoul.
<JonathanJ1> we were already hosted many W3C WG meeting. DAP WG, Media Annotation, MWBP WG ...
<ddahl> JonathanJ1: yay!
<hhalpin> I think its important people are realistic about their attendance at very late or very early hours
mountie: midnight or 1 am would be possible
<hhalpin> Not just possible, but something that can be done weekly
<hhalpin> I'd like to hear from the rest of the participants outside of Mountie if possible?
virginie: progress. high-level
API to come back in one month with timeline
... priority in conference call; low-level API and use-cases;
then in one month, change to high-level
... Dec., check status for next working draft
<hhalpin> 3 month heartbeat requirement puts us around new years
virginie: by Christmas we'll need another draft.
mountie: other volunteers in China; midnight better than 1 am
virginie: thanks to the scribes
<ddahl> wseltzer: +1
virginie: next Monday's meeting
is canceled
... Next meeting: Nov. 12 at usual time 1900 UTC.
<JonathanJ1> how about make a questionary for next F2F schedule decision ?
virginie: I've noted that on my 25-item action list
thanks to Virginie, Ryan, editors
[applause]
trackbot, end meeting
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 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/ddahl/ Succeeded: s/high-level API/proposal as it stands/ Succeeded: s/scribenick wtc/scribenick: wtc/ Succeeded: s/thread/threat/ FAILED: i/scribenick: npdoty/Topic: Joint meeting, Crypto and WebAppSec FAILED: s/@@/mountie/ FAILED: s/@@@/Ryan_Ware/ FAILED: s/@@@/ware/ Succeeded: s/arify/clarify/ FAILED: s/dme// Succeeded: s/ha/had/ Found Scribe: Ryan_Sleevi WARNING: No scribe lines found matching ScribeNick pattern: <Ryan_Sleevi> ... Found ScribeNick: rsleevi Found ScribeNick: wtc Found ScribeNick: npdoty Found ScribeNick: wseltzer Found ScribeNick: tlr Found ScribeNick: wseltzer ScribeNicks: rsleevi, wtc, npdoty, wseltzer, tlr Present: Jonathan_Jeon sgodard WARNING: Fewer than 3 people found for Present list! Found Date: 02 Nov 2012 Guessing minutes URL: http://www.w3.org/2012/11/02-crypto-minutes.html People with action items: ddahl drogersuk others rsleevi tlr virginie[End of scribe.perl diagnostic output]