Agenda bashing and review

High level API

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

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

<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

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

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

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.

Global Unique Identifiers

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.

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

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]

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

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

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

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

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

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

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.

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

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