Web Cryptography Working Group Teleconference -- 01 Nov 2012

<trackbot> Date: 01 November 2012

<selfissued> How did it feel, Virginie?

<rsleevi> http://www.w3.org/2012/webcrypto/wiki/F2F_TPAC_Lyon_Nov2012

<rsleevi> http://www.w3.org/2012/webcrypto/track/

<rsleevi> Agenda & Issues, respectively

<rsleevi> virginie: Agenda overview, scribe hunting

<rsleevi> scribenick: selfissued

<rsleevi> scribe: Mike_Jones

<markw_> Is it possible to avoid the key format discussions overlapping with the Encrypted Media and Media Source discussions in HTML ?

<markw_> I will can you exactly when those are scheduled shortly

Mike Jones - I am the scribe for this hour

<hhalpin> trackbot start meeting

<wseltzer> [agenda on the wiki: http://lists.w3.org/Archives/Public/public-webcrypto/2012Oct/0149.html ]

<wseltzer> [http://www.w3.org/2012/webcrypto/wiki/F2F_TPAC_Lyon_Nov2012#Proposed_agenda]

<hhalpin> tpacbot, start meeting

<hhalpin> chair: virginie_gallindo

<hhalpin> scribe: selfissued

Virginie: We want to understand what our disagreements are and why we have them
... We have lots of open issues - we should be creating actions during this meeting to close them

The WG can eat together at Bouchon lyonnais

<rsleevi> http://www.w3.org/2012/webcrypto/wiki/F2F_TPAC_Lyon_Nov2012

<virginie_galindo> https://www.w3.org/2012/10/TPAC/live/schedule/

<wseltzer> [tpac live app https://www.w3.org/2012/10/TPAC/live/schedule]

Mountie: Asks us to consider call times that work for Asian members

We have 53 group participants

We have 11 invited experts

We have 20 organizations

We have 10-20 participants in each call

We have 17 group members registered for this F2F

We have a 2 year charter

Virginie: FWPD draft published
... very few formal comments
... Formal comments from Oxford, DT
... Some informal comments in tweets, etc. criticizing the premise behind the work
... We have 30 open issues and 9 high-priority issues
... They are sorted into specific domains: crypto, functional, design, key, definition, next usability

<wseltzer> [issues list: http://www.w3.org/2012/webcrypto/track/issues/open?sort=product ]

Virginie: We have a wiki with use cases and an editor for it - Arun from Mozilla
... We are almost ready to make a blog post about the work
... Proposed next steps for two upcoming months
... Publish a new working draft incorporating solved issues
... Create a use case specification

<hhalpin> blogpost will be posted as soon as tlr gets a chance to look over a version, happy to discuss his issues first thing in the morning

Virginie: Create a draft security document
... Possibly a draft high level API description

Mike: We would need to decide whether to have a high-level API at all or not at this point

<rsleevi> priority list: https://docs.google.com/spreadsheet/ccc?key=0Atia00Ba4s7XdGNtYTJBdTFELXV3eWZfMEVud09RV1E#gid=0

Mountie: Asked about issue prioritization

Virginie: Certificate management is currently categorized as a secondary feature
... The working group is contribution based

At this point in the agenda, Ryan Sleevi will give an overview of the state of the API

Ryan: Goal recommendation-track specification
... Long list of primary features
... Also list of secondary features
... (Many of the secondary features about keys and key management)
... Why are there so many features?
... Today Web Apps have JavaScript that runs in a browser
... Today most Web Apps use cryptography only through SSSL
... Today a few have JavaScript crypto libraries
... Today native apps can use crypto without even being aware of it, such as protected storage
... Some native apps use crypto APIS such as CAPI, CNG, CDSA, CC, PKCS#11, etc.
... Some native apps use software and smart card cryptographic providers
... The full picture can be even more complex, including NFC, Bluetooth, USB, ISA, Smart Card, PC/SC, etc.
... Sometimes national crypto features as well
... In Asia and Europe, often browser plugins used to give access to native crypto implementations
... Plugins are not the future
... They will not work across mobile browsers, etc.
... Standards are often set on a national basis
... We need to understand the problem space to produce a workable solution
... The problem space is huge
... Tomorrow Web Apps should be able to use crypto without being highly aware of it (just like native apps today)
... Tomorrow Web Apps should be able to directly use crypto APIs (just like native apps today)
... There are lots of other W3C efforts that relate to this
... Web intents, accessibility, UI, NFC, Smart Card API, etc.
... Lots of middleware in W3C WGs
... Gemalto will be proposing a smart card API in another WG
... We want to move from plugin-based solutions to standards-based solutions
... Combined, the different W3C APIs and efforts can provide a rich standards-based Web App platform
... We shouldn't feel like we have to do everything

Virgine: We should use the work of other WGs to drive UI decisions - not make them ourselves

Ryan: One current hole is key storage
... We may need UI to inform users that the web application has access to sensitive information
... Some UI elements, such as presentation of document to sign, may be the subject of national standards

David Rogers: What levels of assurance do we think are achievable?

Ryan: We need to assure that what is shown to the user is what is actually acted upon
... For instance, sending $100, rather than saying that $100 is being sent and actually sending $1000
... We may want to capture some of this through Web intents
... We need to prevent the intent provider from being owned
... This is being addressed in the Web App sec WG

David: Criminals do client side attacks
... Our security model needs to encompass this

Harry: We split the Crypto API work out of the WebApp security work, but we still depend upon WebAppSec

David: We need to clearly state our security considerations to do a professional job

Mike: Does the web intent and UI work you're describing result in work for this WG?

Ryan: No, my point was that end-to-end solutions will necessarily depend upon work in other WGs as well

(the WG is now taking a 15 minute break)

<trackbot> Sorry, wseltzer, I don't understand 'trackbot, make logs public'. Please refer to http://www.w3.org/2005/06/tracker/irc for help.

<wseltzer> ISSUE-12?

<trackbot> ISSUE-12 -- Should the API distinguish between algorithm and operation parameters? -- open

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/12

<wseltzer> ISSUE-14?

<trackbot> ISSUE-14 -- Representation of raw key material -- open

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/14

<wseltzer> ISSUE-19?

<trackbot> ISSUE-19 -- Does it make sense to have authorized-origin and specific-origin keys -- open

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/19

<rbarnes> hello, i will be your scribe this hour

<wseltzer> scribenick: rbarnes

virginie: intro

ddahl: <getting presentation set up>

selfissued: suggest people who didn't introduce themselves introduce themselves

mark, harry, cjkula, rbarnes

ddahl: as we're working through these usability issues, keep in mind things like code examples

… don't know any web developers who could use the API today

… that's OK, but we should keep that in the back of our heads

hhalpin: to rsleevi: what is your feeling on high level vs. low level

rsleevi: probably part of a holistic look at the API and how we make it easier to use

ddahl: i'm also keeping in mind that there will be a "jQuery of web crypto" to create abstractions

… so we don't need to address everything here

rsleevi: it creates more objects to be defined, could get back into the problems with key generation/derivation

… creating ontologies and applying them consistently is a hard problem

… algorithm vs. operation is a tricky question

… e.g. if you're only using the objects once, maybe it's not even meaningful

wtc: it's clear that certain things belong to operation, e.g., IV

… so if we make IV a parameter of the algorithm identifier, we run into problems with algorithm comparison

mountie: the current spec has many algorithms, but there are lots of others

… e.g., Korea has several local algorithms

… updating specs can be difficult, maybe separating things could help adaptability

virginie_galindo: we decided as WG that we are going to recommend some algorithms and describe them a bit more

… we know we can't address all the algorithms in the world

… but we need to provide some guidance to web developers

<Zakim> rsleevi, you wanted to respond to mountie

rsleevi: quick response to mountie: sounds like that issue is slightly different than what we're discussing

… more about document organization / modularization, do that later

… in response to wtc on algorithm normalization: don't think it requires a change to the rules

… the normalization rules were our hacky way to deal with using strings in some places and not others

… this issue is about calling convention

selfissued: in terms of doc organization, we should be very clear about what things are part of the algorithm vs. which are data

… e.g., mgf vs. iv / authenticated data

… don't have a strong opinion on the need to separate as a calling convention, but should be clear editorially

markw: pretty confusing when people look at this at first and see all this stuff in AlgorithmIdentifier

hhalpin: from a process standpoint, agree with ryan that this is part of a larger usability issue

… should we just have the usability discussion now?

… what we need in the spec is, what is the larger pattern / anti-pattern for parameterization?

… my intuition is that keeping operations separate kind of makes sense, but it also makes things more complicated

virginie_galindo: you're looking at ryan, but everybody should be concerned

wtc: seems a little extreme to have to make two dictionaries just to do a simple CBC operation

… if i want an AES-CBC mode key, don't want to specify an IV parameter

… maybe we should separate namespaces for "key algorithms" and "operation algorithms"

rsleevi: feedback from i've received from internal developers is that the use of a single dictionary is seen as a natural point

… many APIs are preferring dictionaries over positional arguments

… i wouldn't worry about using dictionaries here

… to respond to wt.'s point, we do have some separation now, between key generation parameters and operation parameters

selfissued: could we project the part of the spec that says that?

<virginie_galindo> example of issue impact http://www.w3.org/2012/webcrypto/WebCryptoAPI/ section 24.3.2

rsleevi: <projects, shows RSAKeyGenParams>

… so there is some separation now

… in a broader sense of improving usability, let's get some concrete proposal

… if we're going to split, then someone needs to propose text

… absent a proposal, we're going to continue to circle on this

ddahl: was going to say the same thing that wtc did

markw: we can talk about whether it's a good idea in principle, then someone can go off and write something specifc

… you could even go as far as creating an Algorithm object

… regarding things like AES keys, could be useful to separate key algorithms from operational algorithms

… my implementors were like "there's no such thing as an AES-CTR key, there's an AES key"

rsleevi: that's a separate point, and a reasonable one to discuss

… don't want to mix keys in some spaces

… when you're dealing with an implementation's cryptographic spec, does it support CBC but not CTR

… or not GCM

… you could create a key for GCM, but not be able to use it

… for AES, it's less of a big deal, for asymmetric, might waste a lot of time on keygen if say there's no OAEP

markw: well, there should be capability discovery

rsleevi: for now, the key is the starting point for capability discovery

… if we're going to revisit discovery, we would need some proposals

… the way that it works today is that trying to initialize the operation is the point at which you learn about unsupported algorithms

rogers: isn't that kind of inefficient?

rsleevi: yes, kind of. but you might not find out until operation time (e.g., with a smart card)

… this starts to move toward secondary features, like multiple key stores and how to deal with that

virginie_galindo: who would like to volunteer to improve the parameters / identifiers

wtc: want to propose a solution, but it might not separate operational parameters

… see a hole in the current editor's draft in specifying parameters for key generation

rsleevi: that's not the ISSUE-12 problem, that's a new problem

hhalpin: maybe wtc can solve ISSUE-12 while he's at it

virginie_galindo: markw and wtc can work together

<rsleevi> ACTION Wan-Teh and Mark to work on proposal for ISSUE-12

<trackbot> Created ACTION-58 - And Mark to work on proposal for ISSUE-12 [on Wan-Teh Chang - due 2012-11-08].

<rsleevi> scribenick: wtc

<selfissued> To sign up for dinner, log in at https://www.w3.org/2012/10/TPAC/live/schedule and click on the start next to "Web Crypto WG dinner" so that the star turns gold

virginie_galindo: in this session we will start with usability and then switch to key formats.

<rsleevi> ISSUE-14?

<trackbot> ISSUE-14 -- Representation of raw key material -- open

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/14

ddahl: ISSUE-14: representation of raw key material. We are going back and forth on how to represent key material.
... ASN.1 DER seems natural for a low-level API, but JSON should also be supported. Perhaps there should be a way to convert between the formats.
... are there any key types that can't be represented in JSON?

<wseltzer> tantek: is this meant to cover the use-case of someone posting public key on a web page?

Celik: will this allow people to publish their public keys on their websites?

<hhalpin> My thinking re key publication is that folks will keep using armored ASCII key encryption of their public keys

<hhalpin> This is more app-facing

<rsleevi> @hhalpin: You mean the form that is not specified/standardized anywhere?

ddahl: Yes. But we need to cover other types of keys. There is a lot of back and forth about this. I am not sure how to solve this issue.

<hhalpin> when you see people publish keys, its usually something like this: http://www.ibiblio.org/hhalpin/harryhalpin.asc.gpg

<rsleevi> @hhalpin: What, no WebID love? ;)

<hhalpin> i.e. on "their webpage" which was Tantek's question, as hje's a microformat guy

ddahl: we could standardize on using ASN.1 DER internally and then specify which key types could be exported in JSON.

slightlyoff: could you give an example of a key type that couldn't be represented in JSON?

<hhalpin> well, we have to chose one :)

rbarnes: why do we need to even standardize on a key format?

<hhalpin> re import, export - but that's in secondary features in particular

rsleevi: we need to find out what is easier for developers in practice.
... there are cases where JSON would make sense or ASN.1 DER would make sense.
... requiring an application to convert from other formats to the format we choose would be acceptable.

<hhalpin> https://tools.ietf.org/html/draft-ietf-jose-json-web-key-06

rsleevi: I raised this issue because at that time it wasn't clear based on the use cases which format would be optimal.

selfissued: the JOSE working group felt that there are compelling reasons not to reinvent a new format.
... for certain use cases we would recommend just using ASN.1 DER for things like keys used in an attestation chain.
... the Editor's API is in a good position because the import/export methods take a key format argument.
... In the JOSE working group I will ask if the private key document should become a working group document.
... I'd like opinions on whether we would like a standard JSON representation of shared (symmetric) keys.

olivier: I'd need strong motivation to invent new formats for keys. DER encoding is sufficient for using the crypto API. What's the motivation for a new format?

ddahl: to give web developers who are not familiar with crypto a more transparent view of what's in the key.

markw: If you have JSON, you have serialization. Whereas JavaScript objects don't.
... we need a serialization format for every key type that we need to wrap.
... also the key attributes.
... I don't know if such standard exists.
... I'd prefer if the JOSE working group take on the representation of private keys and symmetric keys.
... extending JSON web keys seems to be a good way to reach our goal (of facilitating key wrapping).

<rbarnes> fwiw, i would be fine with doing JWK or PEM-encoded DER. i just don't see that this is a hugely difficult question

ekr: in most cases apps don't need to inspect the keys, so transparency of the key format isn't important in those cases. But when they do, it would be a hassle to have to write a DER decoder.
... why not support multiple formats?

markw: there is no DER format for key attributes (for key wrapping).

hhalpin: it would be dangerous if web developers need to do DER encoding themselves. So I think we need to support ASN.1 DER. The question is whether we should *also* support a JSON format.

rsleevi: usability is an issue. If we give developers 10 options for key format, it would be hard to figure out which format would be appropriate for the particular application.
... so we need to focus on usability. Also, I'd like to clarify the DER format. It is actually a much larger set because DER is just an encoding format. For example, there are two ways to represent an RSA public key in the DER format.

<hhalpin> I think *also* support JSON Web Key as its probably not too hard and much easier for developers to understand.

rsleevi: can we make our API as easy to use as jQuery, so that they don't need to become a crypto expert to use it?

<slightlyoff> what rsleevi said = )

selfissued: is there a DER key format which is just a bare key?

rbarnes: yes, SubjectPublicKeyInfo.

markw: the important issue is the format of the key to be wrapped, because the key format for unwrapped key can be converted (just a matter of programming).

rbarnes: have support for ASN.1 based formats when there are requirements to work with legacy systems, but prefer JWK for other applications.

<hhalpin> just to clarify, it seems like for legacy reasons ASN.1 import/export is necessary, and since its not too hard, lets use JOSE(++) keys that map directly to the JSON objects in the API as well.

<hhalpin> this helps usability as we cannot expect webdevs to deal with ASN.1 formats, but we ideally do want keys to be sent around using JSON in the future.

<hhalpin> :)

rbarnes: the focus here is on just the keys, not X.509 certificates.

virginie_galindo: we need a volunteer to write a proposal for this issue.

<ekr> SPKI in this case = http://tools.ietf.org/html/rfc5280#section-4.1.2.7

rsleevi: the current Editor's API has a KeyFormat argument for the key import and export APIs.

<ekr> This list needs to add SPKI

<rsleevi> @ekr: Is that volunteering to propose additional text? ;-)

<virginie_galindo> was about to ask the same

<rsleevi> (or perhaps this is an issue for the editors to clarify edition)

<ekr> "subjectpublickeyinfo" "The RFC 5280 SubjectPublicKeyInfo format"

<ekr> Actually, I would remove both PKCS#1

<ekr> values

<ekr> in favor of the wrapped versions

rsleevi: the need to support many formats would be extra burden for implementors of the API and also usability concerns for developers who will use the API.

<rsleevi> ISSUE-35?

<trackbot> ISSUE-35 -- Handling of wrap/unwrap operations -- open

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/35

markw: ISSUE-35: handling of key wrap/unwrap operations.

<rbarnes> for reference, SPKI = PKCS#1 + algorithmIdentifier

markw: ISSUE-35: handling of key wrap/unwrap operations.
... (goes over his proposal for ISSUE-35).

virginie_galindo: format for raw keys, and format for wrapping keys and attributes together.

<cjkula> Trying to understand this issue better -- is there any reason that a legacy encoding method cannot be wrapped in JSON? Reasons for this being 1) providing additional semantic information about the key, and 2) providing a standard-format structure that can be key-wrapped, for instance. I wouldn't think this imposes a great additional burden on end coders...

virginie_galindo: should we add a SubjectPublicKeyInfo format to Section 15: KeyImporter interface?

rsleevi: the proposal is to replace "pkcs1-public" with SubjectPublicKeyInfo because SPKI can also represent non-RSA public keys.

<ekr> as wtc says. Also, they are typed.

selfissued: JOSE is an open group. If anyone would like JOSE to specify the formats for private keys and symmetric keys, send a request to the JOSE working group.

markw: we need a format for wrapping a key with its attributes. We need to ensure a path to success for this issue.

selfissued: this week would be a good time to send the request because JOSE will meet in Atlanta next week.
... rbarnes, ekr, and I can act as coordinators.

rsleevi: the handling of key attributes is a secondary feature.

hhalpin: that refers to just the attributes that aren't necessary to primary features.

<rsleevi> ACTION Ryan to update the formats to remove PKCS#1 and add SPKI

<trackbot> Created ACTION-59 - Update the formats to remove PKCS#1 and add SPKI [on Ryan Sleevi - due 2012-11-08].

virginie_galindo: Action item: ddahl to update the key format list in the API draft.
... ISSUE-19: does it make sense to have authorized-origin and specific-origin keys

<wseltzer> ISSUE-35?

<trackbot> ISSUE-35 -- Handling of wrap/unwrap operations -- open

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/35

virginie_galindo: ISSUE-35: handling of wrap/unwrap operations.

markw: proposal was emailed on Oct. 30.

<virginie_galindo> http://lists.w3.org/Archives/Public/public-webcrypto/2012Oct/0142.html

markw: make wrap/unwrap a sub-case of export/import.
... see http://lists.w3.org/Archives/Public/public-webcrypto/2012Oct/0142.html for the proposal
... added boolean attribute 'wrapped'.
... added createKeyImporter method.

<ekr> q

markw: similarly for createKeyExporter method.
... with all the descriptions.

<ekr> btw, bad idea to use the term "extractor" here. It's a term of art in crypto.

<ekr> Unfortunately, "exporter" is a term of art in TLS, but that's probably less confusing

marks: rules for resolving conflicts between the attributes and usages inside and outside the wrapped keys are specified.

markw: (goes over specification of RSA PKCS #1 v1.5 and OAEP and AES key wrap for key wrapping.

ekr: can you talk about the JavaScript security model for your proposal?

markw: a key that is not exportable should not be exported in either raw format or wrapped format.

rsleevi: I'd like to make sure we have enough diversity of use cases for key wrapping so that we design a good key wrapping API that solves the problem space.

<ekr> the only reason this needs to be inside the API boundary is the type enforcement on import

<ekr> everything else could be implemented outside the API boundary

<markw> @ekr: yes

rbarnes: without key wrapping, an app would need to export the raw key and encrypt the key as data.

<cjkula> I feel that key wrapping is integral to key import-export. Aren't keys (otherwise) being shuffled around unprotected?

hhalpin: I really appreciate the proposal by markw. It is a great contribution to the WG.

<hhalpin> ekr, for non-native English speakers, could you write you not on trust boundaries in in IRC?

virginie_galindo: members should look at markw's proposal and send comments to the mailing list.

<selfissued> FYI, JOSE currently only uses RFC 3394 key wrapping, not RFC 5649 key wrapping, because it didn't have a need for wrapping keys of arbitrary size

<hhalpin> i.e. enforcement on wrapped import is making "the assumption" that the JS is itself not trusted here.

virgine_galindo: we will continue the discussion during the Use Cases session later.

<ekr> Sure. The point i was making is that in general, the key exportable features in this API are designed against some future compromise of the JS. This is a design in which the JS has thee key in its hand and yet you're saying you don't trust it.

selfissued: FYI, JOSE currently only uses RFC 3394 key wrapping, not RFC 5649 key wrapping, because it didn't have a need for wrapping keys of arbitrary size

virginie_galindo: we'll reconvene at 2:00 PM.

<tantek> re: Issue 14, I've started collecting real world examples of public publishing of public keys on web pages: http://microformats.org/wiki/key-examples

<tantek> hopefully that will provide some useful input for Issue 14

<ddahl> tantek: thanks

<tantek> http://www.w3.org/2012/webcrypto/track/issues/14

<hhalpin> thanks tantek!

<ddahl> tantek: I also have a deep interest in key publishing

<hhalpin> We're going through the use-cases at 4:00 PM if you could be there, that could be useful to talk about this more

<hhalpin> scribenick: hhalpin

rsleevi: ISSUE-17: Scope and API for custom key attributes, lets delay till Mark can be here

<rsleevi> ISSUE-17?

<trackbot> ISSUE-17 -- Define the scope and API for custom key attributes -- open

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/17

lets do key storage now

<virginie> How does the application know where the key is stored ? http://www.w3.org/2012/webcrypto/track/issues/30

rsleevi: Previously, we considered key storage do be done in localStorage
... however, there was concern re having yet another mechanism to key storage
... that could then track users
... my proposal is not to store raw key in localstorage

<ekr> can you reopen the queue pls

rsleevi: then we remove our notion of key storage
... and then web storage should be re-iused

<rsleevi> http://lists.w3.org/Archives/Public/public-webcrypto/2012Oct/0133.html

rsleevi: and then our key material can then by WebIntents, workers, etc.

ekr: thinking re key storage, you have a key in some non-persistant storage
... IndexDB stores the key object

rsleevi: and the app doesn't have to see the key material

ekr: but if key is just a handle to something to a token, then you need alot of special logic to sync up IndexedDB object with key storage
... worried about this getting out of sync

rsleevi: that problem exists regardless of where we do key storage
... it stores the permission set and can know you have the key authorized, how to retrieve the key
... we return all that data from indexeddb
... you can try to do that and key may be gone
... but that's just like removing a smartcard, you only discover this if you try to use th ekey

s/ekey/key

ekr: if this is going to have right semantics so that structure of handle guarantees

alexrussell: we're returning opaque handle

rsleevi: we don't have token storage thought out
... but we can guarantee for localstorage

s/localstroage/indexedDB

<ekr> here's the sequence of events I'm concerned about: I generate a key with a token and get a handle to it. I then store the key in indexdb. Sometime later, the user tells indexb to erase it's local storage. Does this cause the side effect of garbage collecting the key.

<rbarnes> ack

rbarnes: I'm not sure if this really helps, as we want special handling anyways
... for keys

mountie: queston for UI part
... you are dependent on the browser vendor
... for the korean users we need to modify the selection, getting user consent
... we would like to add messages
... delivered in the UI itself

<rbarnes> it also seems a little funny that other groups are free to define new storage modalities, but this group can't?

just noting that I did run Ryan's proposal by HTML WG, IndexedDB was seen as the preferable storage modalities

definitely to be preferred over localstorage, which has various speed etc. interests

and webapp frameworks being developed in other WGs are moving to consensus to not define new many storage modalities

rsleevi: while localstorage does only strings, indexeddb can to the same lifetime considerations
... so the argument is that it makes lifetime management easier
... as regards UI considerations
... so we're focussed first on non-token key storage
... but remember that as regards key storage, its after user has already gone through a UI
... so we're assuming that actually works

<slightlyoff> ack

slightlyoff: my general point was to go with structured clone, not go to localstorage or indexeddb
... as there might be yet another storage mechanism
... so stay neutral on storage
... but do not define another keystrorage

ddahl: does the developer have to do it the storage mechanism directly, or does the API handle this?

rsleevi: we are imaginging that what is stored is like a pointer
... local storage does a GET on this value

s/GET/get

scribe: what my proposal gets away from is another storage mechanism, we just deal with structured clone
... whether its FileAPI or IndexedDB or whatever

ddahl: mozilla would prefer indexeddb

rsleevi: but we as the group don't worry about it
... we just don't get another storage mechanism

slightlyoff: we've backed away from localstorage due to issues with sync
... but that be a big deal in the future
... but imagine that we could make localstorage
... we want to create invariance around card/key

<rsleevi> hhalpin: From a process perspective, unless implementor objection, lets get consensus

<rsleevi> hhalpin: Proposal: Remain neutral on the nature of storage and do *not* define a key storage mechanism in our API

<rsleevi> virginie: objections?

RESOLUTION: For non-token backed keys, we do not specify any particular Web storage mechanism, but we use a Web storage mechanism rather than an independent key storage object

<scribe> ACTION: rsleevi to specify text that makes it clear we do not specify any particular Web storage mechanism, but we use a Web storage mechanism rather than an independent key storage object [recorded in http://www.w3.org/2012/11/01-crypto-minutes.html#action01]

<trackbot> Created ACTION-60 - Specify text that makes it clear we do not specify any particular Web storage mechanism, but we use a Web storage mechanism rather than an independent key storage object [on Ryan Sleevi - due 2012-11-08].

<rsleevi> ISSUE-3?

<trackbot> ISSUE-3 -- Decide whether algorithm discovery is necessary -- pending review

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/3

<rsleevi> ISSUE-38?

<trackbot> ISSUE-38 -- Key initialization and "finalization" -- open

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/38

<virginie> reminder priority table of issues is here : https://docs.google.com/spreadsheet/ccc?key=0Atia00Ba4s7XdGNtYTJBdTFELXV3eWZfMEVud09RV1E#gid=0

rsleevi: ISSUE-38
... we imagine that keys can be marked so we can't back-up key
... or that we actually can

<virginie> we are managing http://www.w3.org/2012/webcrypto/track/issues/38

rsleevi: and once key is intialized, we can change it.

ekr: why can't we just move key to a non-exportable container and just delete it

I'm thinking that if this work around is used a lot, I could see an ease-of-use issue for including this as a class of keys

ddahl: I want to avoid too many features, so let's keep it low priority

rsleevi: lets make sure the WG doesn't want it, but I agree with ddahl

cjkula: how about the case where the export gets screwed up?

rsleevi: but we're still OK in terms of crashing

virginie: PROPOSAL: lets cloes ISSUE-38 to reclassify it as a next version

any objections?

<rsleevi> ISSUE-3?

<trackbot> ISSUE-3 -- Decide whether algorithm discovery is necessary -- pending review

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/3

RESOLUTION: loes ISSUE-38 to reclassify it as a next version

ISSUE-3: Decide whether algorithm discovery is necessary

<trackbot> ISSUE-3 Decide whether algorithm discovery is necessary notes added

rsleevi: we have two kinds of keys, browser-generated and maintained keys
... and storage-backed keys
... how do we manage discovery?
... first proposal, can we know if a browser as implemented a particular operation?
... its hard, since AES-128 may be supported by a browser but not a smartcard
... and since the important point that smartcard doesnt give up key material
... so the intial proposal is we can't do discovery
... we just try to do the key

PROPOSAL: We don't have a generic algorithm discovery procedure

<drogersuk> Re: algo discovery - we need to consider about broken algorithms and people using old (insecure) versions of browsers

mountie: we want to make sure algorithm is available, if browser returns true or false, that helps, we dn't need a true list

<drogersuk> this may lead us to the solution to the discovery problem

ekr: I don't like your solution but lets go with it as it will never work.

<ekr> hhalpin: that's not quite what I was saying.

<ekr> More "this is distasteful but it's the best we know how to do I suspect"

s/I don't like your solution but lets go with it as it will never work/his is distasteful but it's the best we know how to do I suspect

<ekr> The best we can do is define clear semantics for what "I don't support it" looks like"

rsleevi: we want to discuss the warning itself separately
... for your point mountie, the problem is in the details, it may only support with all parameters listed
... or you just initialize the key

drogersuk: if we do have the notion of list of discoverable crypto algs, how do we handle spoofing attack?
... how do you handle algorithm export issues

mountie: I'm thinking browser environment we may to support in order to run certain apps

ddahl: maybe we can just punt that piece of code to web-developers

<slightlyoff> can't do this via the queue, so let me do this here: it won't work that way. JS libraries are going to try to feature detect

rsleevi: how do you trust algorithm list is authentic, does not change with what we currently do
... server should never trust client JS

I might add it has no choice

<slightlyoff> and that means that punting to them is all about "them" having some visibility into what you can do in each situation

rsleevi: its a feature to polyfill new algs in the agent
... not a bug
... markw shows that they have some trustworthy operation
... that only they can perform
... algs do get turned off in regulatory environments by user as well, not just browser
... less than ideal discivery, but new proposals welcome

<ddahl> I am going to assume developers will do this regardless - especially since we will probably not be able to produce a comprehensive, pre-init() algorithm discovery api

<slightlyoff> sorry, that's just not the world that library authors will get behind...you can't keep the libraries up to date, so they try to make what they know about the world conditional based on what they can observe

rsleevi: if you don't have a seed key and not sure if its' available, lets try is a good way to do
... versioning APIs is terrible on the Web, feature discovery is better way
... browser capabilities etc.

<Zakim> rsleevi, you wanted to respond to drogersuk

drogersuk: the polyfill is a threat, is it not?
... can not attacker go after it?

rsleevi: we need to discuss this more, but during break

PROPOSAL: Do not have a generic algorithm discovery procedure

<scribe> ACTION: mountie to determine if a generic algorithm procedure is necessary for his use-case [recorded in http://www.w3.org/2012/11/01-crypto-minutes.html#action02]

<trackbot> Created ACTION-61 - Determine if a generic algorithm procedure is necessary for his use-case [on Mountie Lee - due 2012-11-08].

<virginie> Break 15 minutes reconvening @ 15:30

<rsleevi> scribenick: rsleevi

<scribe> scribe: Ryan_Sleevi

Presentation by Richard Barnes regarding implementation experience

rbarnes: BBN is working on a pure polyfill implementation of the API
... Start prototyping the API, keeping up with it as it evolves
... allows developers to start experimenting with the API and getting used to the concepts
... attempts to provide an abstraction that prevents access to the raw API
... get feedback as to how usable the API is
... provides a space for experimentation of new features
... plan is to be open source and collaborative
... implemented in JS, has all the existing caveats
... *not* intended for real applications
... perhaps in the future, after security analysis, but not recommended nor a goal for now
... trying to emulate the web crypto API separation in JS
... Current Web Crypto: Keys stored (raw) in localStorage or IDB
... All key material is accessible to content
... Implementation/Experimental API: Provide an API separation from content for key storage
... Does so via origin separation
... Get people used to not having access to the raw key bytes
... maybe some security benefits
... eg: encrypting key store, forced key expiration

drogersuk: Q regarding last pass. There's a hardware token you can get with lastpass, how does that relate?

rbarnes: Not quite familiar with the LastPass implementation

rsleevi: re: LastPass - authentication security, not a key storage security

rbarnes: Just getting started. Basic framework for cross-origin operations
... Funded by US DHS STD

http://code.google.com/p/html5-crypto-api/

<hhalpin> note that W3C/MIT is getting a grant from NGRC for continuing this work.

<hhalpin> So if people are looking for funding in this area, I think now is a good time to strike

rsleevi: Hooray for the implementation. Demonstrates that this API is polyfillable today

virginie: Question for Mozilla and Microsoft as to when they'll be implementing

selfissued: Not aware of any committment to implement. Not to say there is no committment, just not sure

ddahl: Been focused on Firefox OS. Needs to finish Mozilla's implementation of getRandomValues
... Next step to consider extension implementations as an experimental API
... Working to get excitement and feedback from other Mozilla engineers. Difficult at present with focus on Firefox OS

drogersuk: Just ask them about what security do they want in FirefoxOS

rsleevi: Agenda item for this quarter to begin working and looking at the implementation, need to work out some very obvious usability issues before exposing to developers

???: Working on server implementation, in particular in node.js

virginie: Not yet formal WG member. Do you know when you will join?

???: Not yet, working on it

s/???/Alexandre Mogel/

[ working out details and waiting for Arun to call and join ]

[ small break ]

<virginie> [discussion about crypto node.js]

<ddahl> arunranga: you are our only hope

<hhalpin> Arun, can you dial in?

<drogersuk> zakim is a name not a number...

<drogersuk> 6

<ddahl> arunranga: i was joking about you appearing like a tupac hologram to discuss use cases

<hhalpin> OK, its always the same

<hhalpin> 1.617.761.6200 code 1932

<arunranga> I am the first participant in the new conference. The old conference id, namely 27978# is not working.

@arunranga: We're having technical difficulties

@arunranga: Phones are hard. We're going shopping.

<arunranga> Heh :)

<arunranga> Comparisons to Tupac are always welcome, BTW

<virginie> oups...legal working on it (legal team :))

<virginie> a bit of reading about use cases http://dev.w3.org/2006/webapi/FileAPI/OverviewUseCases.html

<ddahl> HI ARUN

virginie: notes 150 people present in the room

[ laughter ]
...: 20 people

virginie: Objective is to discuss use cases and get your (arun) view on use cases we have and in the wiki

arunranga: Don't be thrown off by the fact that the document shared in IRC is from FileAPI
...: Had the repository as easy access to hg on a w3c server
... Goal is to find a way to publish a use cases document
... likes the role model document we have - the scenarios document for the media api
... good template for how we can model our use cases
... most of the use cases that are in the wiki are good, but wanted to focus on the use cases that were declared as pressing problems
... wanted to make sure that the API could address them
... no real apple-apples comparison between what we've got (as an API) and what they (media api) do
... but we can use the model as a point of discussion

<slightlyoff> OH HAI arunranga

<arunranga> :)

tobie: introductions
... here to talk about their (Facebook) use cases if it's valuable

arunranga: Good to talk about those use cases at some point
... Try to break use cases in terms of rich scenarios and break them up into required components
... broke spec into cluster of requirements

[ reviewing operation types from the draft ]

arunranga: Break any rich scenario type into these sets of operation types
... When you consider the S. Korea use case, it may not actually be possible with the API to meet those needs
... assuming everyone reviewed the document that was sent

virginie: Any questions about this document or to the editor

mountie: For the use case for the korean banking, many things are missing

arunranga: Yeah. Are many things missing from the actual API, or simply details from the use case?

mountie: certificate enrollment is an important part of the process, but just described simply, without trusted key generation or cert enrollment process
... Without those types, this scenario cannot be implemented

arunranga: Acknowledged. We have origin scoped keys, but over there, no one can see it's an origin scoped certificate, it comes from a central source, correct?
... When we impose the technology requirement of an origin scoped set of keys, we can't really do the central authority scenario

<hhalpin> ISSUE-19 is still open http://www.w3.org/2012/webcrypto/track/issues/19

virginie: Not sure if we want to have online discussion of the use cases, or if it would be more useful to have the right people to interview

<hhalpin> i.e. whether or not we should allow "specific" origin keys

<bblfish> you can interview me :-)

arunranga: I like the idea of interviewing. It would have been nice to do it in person, but there were hurricanes and things

bblfish: Has a use case, is this the right time to give a quick use case?

arunranga: have you had a chance to read the API?

bblfish: I have a general use case, but I haven't followed the API closely
... Wants an API to log out the TLS layer
... has a use case similar to browser ID, working with Web ID
... Is that something someone can do with this API?
... Do a browser ID sign on with the cryptographic material

virginie: Question for clarification regarding browser id

ddahl: I would not want to conflate what we're doing here with browser ID
... browser ID has polyfills for other browsers regarding APIs
... Mozilla is building into natively for Firefox, but that's completely separate

bblfish: So you're not going to use this API to do things like signing?

ddahl: Already implemented via polyfills

hhalpin: One thing to do is to order the use cases, perhaps by the most urgent
... Then ask about other use cases people want to go through

<wtc> arun: I like the Gangman Bank's name "-)

<ekr> What does "TLS log out" mean?

<ekr> Seriosuly, I have no idea what it's supposed to mean

<wtc> ekr: if the TLS session uses a client certificate, invalidate that TLS session.

rsleevi: Is the document meant to describe what our API (version 1) did, or what the API (product of the WG over iterations) will do?

<virginie> our reference for use cases used to be here : http://www.w3.org/2012/webcrypto/wiki/Use_Cases

<ekr> wtc. thanks

<hhalpin> use-cases were in a wiki but not maintained

<ekr> That seems like a bit of a niche feature.

arunranga: It sounds like what Henry is asking for is not really quite in scope
... goal would be to construct use cases and scenario as fully in scope of doing
... that should be the test that we hold to our API
... definitely want to hear more from those present and be able to maybe follow up with them online

hhalpin: Just know that TLS logout is within secondary scope

arunranga: Kind of want to get all the primary ducks lined up

[ virginie loads document for presentation ]

virginie: Would like to know for which use cases do you have someone to talk to, to complete the description, or do you want to look for someone now?

arunranga: All of the use cases are based on what we've seen go around
... wants to follow up with tobie to discuss the caching scenario
... What Netflix currently has on the wiki is very technical, doesn't quite disclose a scenario or workflow. Want to work out more high-level details

virginie: 3.1 - Mountie will comment. 3.2 - Netflix will comment. 3.3 - Tobie for comment

arunranga: 3.4/3.5 for discussion with nadim

mountie: Who is the use cases target audience? Non-developers or for developers?
... This document seems like for normal process showing some examples / sharing some stories, not for help for developers
... We should focus more for developers
... Banking has a sequence of very complex operations

<hhalpin> http://dev.w3.org/2006/webapi/FileAPI/OverviewUseCases.html

mountie: If we split out what operations and what functionalities, that would be helpful for more developers

<hhalpin> use-case docu

virginie: The objective is to have very story-driven scenario first, then functional requirements, then technical requirements

hhalpin: The document is not for ordinary users (developers). It's to drive the discussion about what features are in and are not the API, to help the WG drive work
... To make sure it's clear to the editor what features should or should not be introduced to the api
... in the process of describing the banking use case, we'll describe the use case in the most accurate possible manner
... and then the WG will discuss how the use case affects the design of the API
... if the WG decides it's important, then the use case could drive change to the API

mountie: For smaller topics, like implementing non-repudiation, implementing secure channels, identifying users
... for non-repudiation, there are so many use cases that can be involved
... for online banking, there's too many operations, it's too wide
... suggestion: Split into things like non-repudiation for online banking, and just discuss the non-repudiation aspect

hhalpin: We're not clear what the needs are. Can you discuss the use case?

arunranga: Agreed. It would be pretty invaluable to see if we can pit our API against the existing technology stack
... Thinks the origin policy is at odds with the korean use case

<hhalpin> so we need more info re the banking use-case and the use-case doc is the place to do it.

virginie: Looking for name of motivated people to drive the story

[ harry volunteers to help arun work on documents in the cloud ]

tobie: Do you have specific questions on the use case?

arunranga: Where we left off, you guys are using local storage and wanting to make sure any code or local resources you cache/store don't get tampered with by third parties

<tantek> rsleevi - no, I am wondering if any of these use cases touch on public key discovery on the web.

arunranga: one way to do that would be to send across some sort of trusted / private-key signed hash to verify the resources
... is there more detail that you want fleshed out

tantek: Tried to look through use cases quickly - do any touch on public key discovery on the web?
... If not, would that be a reasonable case to add?

<bblfish> !+ for tantek

<bblfish> +1 for tanktek

rsleevi: Nothing in the current doc about it. If you're volunteering to write one, that'd be good

<tantek> here's some research I've done of pages on the web that currently *do* publish public keys in visible text: http://microformats.org/wiki/key-examples

<ddahl> tantek: no, but it sounds a lot like my AddressbookAPI from DOMCrypt: https://github.com/daviddahl/domcrypt/blob/master/extension/domcrypt/content/addressbookManager.js#L103

arunranga: So far, it doesn't

rsleevi: suggests its something tantek should write one

[ wtc volunteers for documents int he cloud use case ]

arunranga: Another area for feedback is the MO that we're using (breaking things into requirements and then using requirements to describe use cases/scenario) is the right way to go
... There's more than one way to look at the API, is breaking it up the way it's done the right way?

<wtc> arunranga: the "nigori" protocol used in Chrome is specified in http://www.links.org/files/nigori-protocol.html . I think Firefox Sync would be another good use case.

rsleevi: does the signed code use case actually require signatures and keys?

tobie: No, it's just a hash

arunranga: That's actually a good clarification

<virginie> adding alex morgaut on the speaker queue

arunranga: assumed what was happening was that it was not just a hash, but a hash signed by a private key
... and on the client side we'd have to duplicate the hash and verify the signature

<Zakim> rsleevi, you wanted to respond to arun

tobie: That's... much safer... than we were looking for
... Just wanted to make sure that the code has not been tampered with. Really does not require more than a checksum
... getting a hash from the network and just comparing it with the data

<bblfish> My use case was mostly about enabling to do what BrowserId does currently ( or at least what I read up on it 5-6 moths ago)

tobie: We're using HTTPS, so we assume the network is safe/secure, and we trust the browser

<bblfish> but it looks like the right people are here anyway....

arunranga: I think we can actually give you your use case and raise you one

[ laughter ]

arunranga: I think the hash part is easy and that our API can do
... and I think we can give you cryptographic validity for the hash
... we can probably do your use case and better

cjkula: Arun's story is storing javascript *and other resources*

tobie: That wasn't the initial use case. It was just javascript, which is code we need to run
... it might extend to CSS, due to the fact that CSS may be executable in IE
... but not needed for other resources

cjkula: Kinda said, I liked the idea of other resources

tobie: Yeah, but we don't need it

arunranga: I assumed what we could do for script we could use for other things

tobie: I actually don't need more than that

??1: When we implemented localStorage, we also implemented userStorage

<virginie> alexandre morgaut

<hhalpin> note that re the "code-signing" in storage use-case is also necessary for a number of other projects from OITP (Open Internet Tools Project).

<virginie> from 4D company, a new W3C member

scribe: I wonder if implementing userStorage, which would be encrypted with some user authentication, if that would be useful for you

tobie: If user meant web user, and not OS user, that might be useful, yes
... worried about two (logical) users using the same desktop or mobile device (with same OS user / mobile user)
... it's not uncommon to have four to five different sessions/users back to back on the same device

s/??1/alexandre morgaut/

alexandre: just wondering if userStorage would be useful

tobie: I don't think turning forms based auth into http auth would be useful for us

mountie: similar concerns with protecting JS source and verifying integrity of JS source
... want signed JS to verify that the JS code is correct
... not sure how we can verify the JS code
... If we had enough confidence that JS confidence is the same as from the server, that'd be very helpful

virginie: New person for arun to interview

<Zakim> arunranga, you wanted to ask mountie a question

arunranga: There's a slight difference from mountie's description (JS code verification vs activeX) and tobies, which is merely to make sure that sources that have been cached that haven't been tampered with
... with activex, there is a digitally signed cab file where running code must be signed
... not sure if that case is met
... if simply verifying something that is cached, that may be an apples-apples comparison
... but not sure if that's the case
... lots of stuff that is arguably out of scope in the existing market

mountie: thinks the cases are the same

<tantek> I've written up a step-by-step use case scenario - is this approximately the format that is appropriate for the Use Cases document for the Crypto API? http://microformats.org/wiki/key-examples#meeting_someone_and_sending_private_messages

rsleevi: Describes proposal for encrypted indexedDB, does that fit into facebook's threat model
... "key" would actually come from Facebook server, given to user, user can use the key, key is removed when user logs out. Just couples localStorage to HTTP session auth

tobie: Seems reasonable. Users do log out of the page before giving phone away, so this would likely prevent tampering / address the threat model

hhalpin: Question regarding what makes Korean use case out of scope

<tantek> if the use case I wrote up seems in scope, sufficiently relevant, and in a good enough format, please feel free to incorporate it copy/paste etc. as you see fit - I shared it per CC0 (PD). a citation back to the URL http://microformats.org/wiki/key-examples#meeting_someone_and_sending_private_messages would be appreciated but is not required.

arunranga: It seems that when we look at how we're doing key generation, etc, we subject it to SoP
... in the korean case, keys come from a central cert authority, which is a different origin from the sites that wish to use the credentials
... so not sure how other origins would have access to the key material
... existing certificates are a lot like multi-origin cert, which differs fundamentally from what we're discussing

<hhalpin> http://www.w3.org/2012/webcrypto/track/issues/19

hhalpin: Wonders if allowing slight variations to SoP would address the korean use case
... also about code signing

arunranga: Yeah, current spec definitely seems like a show-stopper
... was wondering if we could mold some of those use cases into what we're trying to do here
... not sure

<markw> <offtopic> FYI for everyone in WebCrypto - HTML WG would like to use JWK with symmetric keys to pass keys to the "clearkey" keysystem </offtopic>

<ddahl> tantek: is there any effort in W3 to standardize a Contacts WebAPI (like the Firefox OS API)?

<Zakim> rsleevi, you wanted to respond to arun

rsleevi: thinks that the current API can actually be suitable to meet the korean use cases without changing the security guarantees

<tantek> ddahl: yes I'm writing up our contacts API for submission to SysApps WG.

mountie: One of the issues includes verifying certificates, accessing certificate extensions, OCSP
... For secondary features, can discuss more about the needs

virginie: OCSP?

<ddahl> tantek: awesome

mountie: OCSP is for revocation checking when verifying certificates.

<jin> OCSP - Online Certificate Status Protol

virginie: Understands the technology - but not sure how this is in scope for the API

<jin> s/Protol/Protocol

mountie: Wants an API to verify the certificate

virginie: Definitely a secondary feature

drogersuk: Not a fan of OCSP, esp for mobile

virginie: Any more questions for Special Guest Tobie?

arunranga: will be following up with additional people
... Is this the right approach for this document? This approach of the draft

virginie: What has been suggested to the WG is that the use cases are part of the next WG deliverable
... what you have described is the right way to progress

<arunranga> Strong +1 to rsleevi

<arunranga> Namely we should describe what we *can* do (and are doing).

rsleevi: Would like to see sort of two parallel efforts - which is use cases document (to be published) shows what *is* possible with draft API
... and wiki or some sort of separate tracking for what we'd *like* to do

arunranga: Thinks it's important the use cases document exposes what we can do with the API
... Secondary place for what we'd like to do and scope future work
... helps focus security discussion of primary features
... and can categorically show if something is possible or not possible
... secondary document to serve as roadmap

virginie: reports previous discussion of key wrapping / unwrapping
... it wasn't clear if it was an urgent use case for others beyond Netflix
... Question for arun while going through use cases is where key wrap/unwrap fit in

arunranga: short answer is yes, it seems possible to cobble together with existing API

<wseltzer> [I just wanted to suggest that we not spend too much energy on editorial selection among use cases at this point. Better to get the wishlist well-documented, and then see what we can accomplish in-scope.]

[ tobie volunteers himself for discussion with arun ]

virginie: Thanks for calling in arun

<ddahl> thanks arunranga !

<arunranga> :)

virginie: Last issue that we have to solve that is high level is the one that is related to origin

ISSUE-19?

<trackbot> ISSUE-19 -- Does it make sense to have authorized-origin and specific-origin keys -- open

<trackbot> http://www.w3.org/2012/webcrypto/track/issues/19

virginie: Good progress on today's issues
... Reminder: Tomorrow is 8:*30*

Agenda review for Friday

[ virginie is presenting proposed agenda again ]

virginie: Big question: What is a "high-level" API

<ddahl> arunranga: the secure messaging use case also needs "SIGN"

virginie: What we think it is, what can the group deliver

<arunranga> ddahl, good point. i'll probably follow up with you and nadir.

<ddahl> arunranga: anytime:)

<arunranga> s/nadir/nadim

virginie: PROPOSAL: Stop the meeting
... RESOLUTION: The meeting is stopped.

<wseltzer> trackbot, end meeting

- DRAFT -

Web Cryptography Working Group Teleconference

01 Nov 2012

Attendees

Contents

Presentation by Richard Barnes regarding implementation experience

Agenda review for Friday

Summary of Action Items

Scribe.perl diagnostic output