See also: IRC log
<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]
Sign up for dinner at the URL above by noon
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 volunteers>
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
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*
[ 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
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/jacky/hacky/ Succeeded: s/etc/wtc/ Succeeded: s/not want/want/ FAILED: s/ekey/key/ Succeeded: s/th/the/ FAILED: s/localstroage/indexedDB/ FAILED: s/GET/get/ FAILED: 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/ FAILED: s/???/Alexandre Mogel/ FAILED: s/??1/alexandre morgaut/ FAILED: s/Protol/Protocol/ FAILED: s/nadir/nadim/ Found ScribeNick: selfissued Found Scribe: Mike_Jones Found Scribe: selfissued Inferring ScribeNick: selfissued Found ScribeNick: rbarnes Found ScribeNick: wtc Found ScribeNick: hhalpin Found ScribeNick: rsleevi Found Scribe: Ryan_Sleevi Scribes: Mike_Jones, selfissued, Ryan_Sleevi ScribeNicks: selfissued, rbarnes, wtc, hhalpin, rsleevi Default Present: arunranga, +33.4.72.82.aaaa Present: arunranga +33.4.72.82.aaaa Ryan_Sleevi olivier Gemalto David_Rogers invited_expert Wendy_Seltzer W3C Wan_Teh_Chang Google David_Dahl Mozilla Mountie_Lee Paygate/Mobile_Web_Forum Mike_Jones Microsoft Virginie_Galindo Richard_Barnes BBN Jonathan_Jeon Alex_Russell Eric_Rescorla Tobie_Langel Henry_Story Found Date: 01 Nov 2012 Guessing minutes URL: http://www.w3.org/2012/11/01-crypto-minutes.html People with action items: mountie rsleevi[End of scribe.perl diagnostic output]