See also: IRC log
<trackbot> Date: 24 July 2012
<wseltzer> We'll start at 9:30 Pacific
<rbarnes> test test
<arun> Yep, finally in.
WebCrypto F2F Meeting Convented
<scribe> scribe: hhalpin
<scribe> scribenick: hhalpin
<rbarnes> link to agenda?
<rsleevi> http://www.w3.org/2012/webcrypto/wiki/F2F_Mountain_View_July2012
virginie_gallindo: agenda is on wiki
<rbarnes> thanks
virginie_gallindo: we want the draft API out by this summer
... we will also look at the use-cases, integrate them API
... probably not necessary to do editorial tools
... start discussion about tests
mike_jones: we at microsoft just did a survey to figure out what is implemented, we'd like to share it
sdurbha_: We want to discuss stored keys, which includes smartcards
vgb: we want to clarify the relationship between secondary and primary use-cases
virgine_gallindo: we have possiblity of looking at use-cases
... did you look with channy?
wtc: the editing pass I made was just to correct errors, the content is just a compilation of all the emails we have received.
<virginie_galindo> http://www.w3.org/2012/webcrypto/wiki/Use_Cases
wtc: they vary in completeness, from one paragraph to whole background doc
virgine_galindo: we should point to specific functions for each use-cases?
wtc: like symmetric, pre-provisioned keys
... there are a few use-cases that need to be incorporated, the smartcard use-cases from MITRE
... use-cases require client certs may or may not be on smart card
... jim davenport had action to incorporate these use-cases
<rbarnes> what was that web-based irc client someone mentioned?
<wseltzer> irc.w3.org
wtc: netflix is the most complete
... issues with credit card processing, hard to understand these use-cases
vgb: anders brought up the point that you sign document, then you add certs at end of signature
sdurbha_: if you are discovering a certificate that is existing, the server-side has no idea whats being used
vgb: we need to have all primitives for a particular scenario
wtc: I think proposed is the low-level API should cover most of the use-cases
arun: is action-item to flesh out use-cases document
sdurbha_: are we assuming SSL? API depends on use-cases
arun: I'll take action with wtc to flesh that out
MitchZ: I'd like to see if my use-case could be implemented with the API
sdurbha_: we need to be clear on assumption, including interaction with TLS
MitchZ: Its more like an OpenSSL or PCKS#11 library rather than sound security principles
arun: I almost think that any use-case that refers to SSL behavior be put in a secondary bucket
<wseltzer> hhalpin: important to get low-level API out sooner than later
<rbarnes> could someone say in one sentence what we mean by low- and high-level in this context?
<wseltzer> ... certificates put into secondary not because they're not important, but because they can be trickier to solve
<wseltzer> ... if someone has a good solution, welcome to say
<arun> arun: e.g. like the "Korea use case" in banking, which is put in the secondary bucket.
<wseltzer> ... We will want to address certificate-handling later.
<wseltzer> ... re: scheduling, we don't have to publish use case doc at same time as API
<wseltzer> ... informative track, versus rec track.
<wseltzer> ... keep working on the use cases; as people review the API, they should consider: can it serve my use case?
<wseltzer> ... every 3 months, heartbeat check
<wseltzer> MitchZ: we can do with the draft API what we currently do with client certs
mitchZ: We can do client certs with the low-level we think by just getting a handle on the private key
sdurbha_: are we giving a good picture? like the Java API with attached use-cases
arun: lets look at the key
rsleevi: in one way to dodge certs, there's no good binary representation that JS can handle
... it can easily be mired
... I was thinking KeyQueryList, we can get a list of Distinguished Names and a list of keys
... we are trying to get BCrypt kind low-level API associaton of keys to DNs, then we can easily layer certs on top on them
... then we can do that kind of operation
virgine_galindo: we have to be clear with our use-cases in mind
... before we go for public review
<arun> arun: I wonder if key retrieval semantics can be "hot rodded" for cert retrieval semantics.
virgine_galindo: the primary/secondary features
hhalpin: we're going to add secondary use-cases dynamically throughout the lifetime of the working draft
... so its OK if they are not addressed in the first working draft
arun: should we put out-of-scope in use-cases
hhalpin: lets mention out-of-scope and in-scope in the API documents intro
... so developers can see it.
<wseltzer> ACTION: Wan-Teh and Arun to add missing use-cases [recorded in http://www.w3.org/2012/07/24-crypto-minutes.html#action01]
<trackbot> Created ACTION-13 - And Arun to add missing use-cases [on Wan-Teh Chang - due 2012-07-31].
wtc: we need to add the Technology Nexus use-case
... and some of Jim Davenport's cleint cert work
rsleevi: whats the behavior, state-machine, etc.
<virginie_galindo> http://www.w3.org/2012/webcrypto/WebCryptoAPI/
rsleevi: we are looking at use-cases to see if we can satisfy the operations
... I've sketched out the IDL for most of what's being discussed
... there's key association, a meaningful way to address a key in a way thats compatible across different applications and preserve privacy
... I've incorporated key generation
... are the keys truly generated, or can we re-use existing keys?
... do we want to use exisitng key associated with its elements
... a brief sketch of some of the algorithms
... algorithm support on different platforms is massively varied
... see Mike's survey on JOSE list
link?
rsleevi: tried to get CDSA (OSX level), PKCS#11, as well as Crypto API and Cryptograhy Next Generation (Vista and later)
... put those together in a kind of JS dictionary format
... number of algorithms to be addressed
<wseltzer> JOSE: tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-03#section-6.1.2
rsleevi: we tried to use native platform APIs whenever possible
... different browsers, different implementations
... we need implementation-independent data reps
... OpenSSL is largely modelled towards PCKS#11, so its harmonizing
... but I haven't looked in more detail at OpenSSL given they "give you enough rope to hang yourself with"
nadim: OpenSSL compatibility?
rsleevi: my concerns with SHOULD implement derivies from them
... often OpenSSL is exposed as PKCS#11
ddahl: the capabilities in different platforms
... action item to put together some sort of table to look at implementation
Mike_jones: I'll send this table out asap, we've already built this table
rbarnes: we should do this exercise once, as we should maximize compatibility
... we're going to have to do algorithm negotiation anwyays
rsleevi: I agree, but representation of non-wrapped keys
... symmetric keys
mike_jones: JOSE is not representing private keys
... to the extend this group wants to do that, so you'd extend the data-structures
rbarnes: we should at least agree on algorithm names with JOSE
rsleevi: I've only been lately following this work, but its a representation of messaging
... we're more at CNG level with the API
... Algorithm at low-level API there are more variety of parameters
... such as salt length
... with a messaging-based scheme, complete cipher suites are defined
... the low-level API might need to expose more parameters
... A256CBC is wrapped together in JOSE, but in PKCS#11 but we have idea of size and length parameters that can vary
... does exposing those parameters make sense?
<wseltzer> pointer to JOSE work from Mike Jones: http://lists.w3.org/Archives/Public/public-webcrypto/2012Jul/0119.html
rsleevi: overlap with JOSE 1-to-1
rbarnes: we can go after suites and profiles
mike_jones: just to provide more data
... some of our open issues we make only algorithm suites available, can we get finer grain control
... for encryption, we require integrity check for algorithms that don't have integrity check
... then we get encryption alg + integrity alg + key derivation alg, that is closer to low-level as ryan describes it
... it may be the case that the WG directs us to aggregated identifiers that suites that make sense
virginie_galindo: what's the major things we should discuss?
<kaepora> Who came up with the idea of adding AES-GCM to the draft?
rsleevi: I think we should 1) naming - represent key/key handling 2) key discovery and 3) key generation/key derivation
everyone, you can just figure out who added what by doing this:
http://www.w3.org/2012/webcrypto/WebCryptoAPI/Overview.html,cvslog
although you need to authorized as a member of the WG at this time
when we do FPWD we'll public the cvs log
agreement of editors
virginie_galindo: we can add editors
PROPOSAL: Adding Ryan as editor and (perhaps temporarily) removing jarred
RESOLUTION: Added Ryan as editor to Spec and (perhaps temporarily) removing jarred
<MitchZ> +q
<selfissued> selfissued is Mike Jones
sdurbha_: details we are expecting from the API
... how are we constrained by details that we cannot meaningful expose to through the API
... frankly, from my expectations, the browsers are going to be ubiquitous
... my hope is we get a particular browser for a particular platform, we want to run on all browsers on all different platforms
... we would prefer not to keep changing code for runtime
... a list of minimum expectations is crucial
rsleevi: two problems, how to represent an algorithm (input, outputs)
... ala AES how long counter is, least/most sig bits, what are parameters
... but we don't want a browser-by-browser basis
... then the code written for AES should work if all browsers support it
... but AES availability is also for configuration dependent
... which may be policy dependent, such as RSA mandatory strength for example in JSA - FIPS might disable key verificaiton for certain small key sizes
wtc: we are focussing on low-level, high-level stuff has been removed
arun: we should focus on lowest level primitives, let libraries wrap with better abstractions
<MitchZ> +1
ddahl: we should write off a high-level API
... that will ride on internals of this
... but I agree we should focus
<kaepora> Note: I am Nadim
vgb: higher-level API will take on significant extra-scope
lets publish lower-level first, then going to high-level
then go to a high level in a time dependent way
maybe dropping if we don't have time
mike_jones: we want to make sure we can built a higher-level version that works with JOSE on top of low-level API
vgb: JOSE has made those choices
<ddahl> arun: MDN will cover it;)
kaepora: I think I have a good solution, we could use really good documentation to show high-level API works
we could do that with a Primer document or Web Documenatation API
mike_jones: does W3C produce reference implementations?
not really
but we can point to things, produce test suites
MitchZ: I'd like to see Doc fill out with TBD, particularly on key exchange
rsleevi: I'd like to get the WebIDL working for even the TBD
MitchZ: we need to have a tech conversation about key exchange
vgb: do we need an initialized state, can we just specify the callbacks as part of creating the object, and got object in processing state
... that would simplify many things in state machine
... we could get rid of empty initializing
rsleevi: we are trying to discourage some patterns
... init state is trying to figure out if basic assumptions are correct before collecting data
... is that an argument for or against, the intent was to determine if we can use a ciphersuite
vgb: do we need both an empty and init state?
asad: could we just re-init an object?
vgb: that is a longer discussion re expensive nature of some objects
... is operation state expensive (key expansion?)
... key discovery is very expensive
... so we should re-use key objects
karen: we want to minimize the things to do in construction, that is why we want init
rsleevi: we shoudl remember that JS is single-threaded
... much of this API is decided to be async, anything that blocks is fatal
... same thread shared between a number of APIs
... we don't want to block thread at init
... not sure what we're backed by
... there are callbacks, the .init was trying to be consisnet inside object without a whole new object being exposed
... its a cryptooperation object, an interface that is returned to prevent
... if we had a "new" we'd still have a .init method
... we are trying to force a DOMObject being exposed to create a new API
... so instead of window.encrypt we'd use a new cryptoOperation
... we don't want to mix callbacks on object with DOM.
vgb: I tend to agree, but still processing
karen: crypto.encrypt returns the operator with an object with the .init
vgb: we have to be consistent to always,for example, return object and then do callback
rsleevi: I was trying to determine what best practices have been
... again, tring to minize verbose description
karen: encrypt is a verb, maybe we should do "getEncryptor"
ddahl: we don't want to confuse people
karen: getEncryptor would be better
rsleevi: or createEncryptor
<ddahl> virginie_galindo: just a scheduling note, lunch is here and ready:)
<scribe> ACTION: rsleevi to change naming scheme to use a "createX" approach rather than just "X" [recorded in http://www.w3.org/2012/07/24-crypto-minutes.html#action02]
<trackbot> Created ACTION-14 - Change naming scheme to use a "createX" approach rather than just "X" [on Ryan Sleevi - due 2012-07-31].
vgb: I'm OK with keeping init
... so you create a new object, it does an init and puts it into initalizing state, callback to tell you are in processing state
rsleevi: correct
sdurbha: it seems response is always a callback, not an event
rsleevi: this is a single-threaded concern
... event-based callback is to allow single-threaded concern
... browsers do JS in event loop
... we want to make things single-threaded
... and thus async
... although WebWorker, if something is exposed to WebWorker
... WebWorkers do postMessage() multi-threaded
... although there is this notion of objets
... this is where clonability comes up
... where is interaction between this and main thread
... FileAPI offers a sync version
sdurbha: how can we tell the difference?
rsleevi: we can curry a function that represents a step for different objects with parameters that tells you which objects
... or temporary functions with first-argument pre-bound, so entire object is smuggled in as argument
... when JS is fired, the source is crypto-operation itself
... when it posts the oninit for the event
... what objects process data, which objects are completed
... this in step 10.3
arun: we should put those steps in
rsleevi: intent there is a state machine
arun: a primer is one way
<scribe> ACTION: ddahl to insert in "right place" a description of high-level example [recorded in http://www.w3.org/2012/07/24-crypto-minutes.html#action03]
<trackbot> Created ACTION-15 - Insert in "right place" a description of high-level example [on David Dahl - due 2012-07-31].
so we have consensus on the init?
arun: more or less, lets think about it
sdurbha: specific parameters vs generic dictionary?
rsleevi: current draft removed that
... in order to keep it then we should just use a generic method
ckula: what's the case against an object that creates a key+algorithm
vgb: AES key, we could do almost anything with it.
... RSA key, you could sign with, you could encrypt with
... the key will not define algorithm completely, key is an algorithm family
... each of those is different
... we want a generic algortihm object, but JOSE algorithms are shorthands for those particular suites stanardized by JOSE
karen: for crypto operation states, we want to have an initialized state and an error state
rsleevi: error is handled by done state
... as in FileAPI
... an initalizing, initalized state?
karen: we only want to use it in intialized state
rsleevi: initalized->straight to processData
... there doesn't seem to be initialized state, except clonability or WebWorkers
... once the oninit has fired, the event source indicates the ojbect
karen: what if you receive callback and want to do something later
rsleevi: you know where you came from
karen: then you don't need enumeration if callback
rsleevi: do we need to expose readystate?
wtc: we need state as inconventi way to formally specify
s/invonventi/convenient
rsleevi: you've exposed this in the fileAPI?
... this is similar to FileReader
arun: I don't think most developers need to query the state
... we exposed it because there this's "readystate" in XHR
... but we don't need to access it
... its just internal flags
<wseltzer> arun: do we want a close/neuter
<wseltzer> rsleevi: we have complete. should that also close/neuter?
<wseltzer> virginie_galindo: do we reuse objects? how do we kill them?
<wseltzer> rsleevi: let's leave the object neutering as an open issue
<wseltzer> arun: key neutering / key object reference neutering
<wseltzer> ... may be a more useful discussion
<wseltzer> vgb: don't implicitly neuter keys
<wseltzer> [LUNCH break]
<wseltzer> rsleevi: distinguish between errors that can be cheaply checked, immediately throw invalid state transition or parameters; most will be async
<wseltzer> [Reconvene in 30 minutes; 1pm Pacific]
<wseltzer> scribenick: asad
<wseltzer> [back from lunch]
issues?
virginie_galindo: We will start with discussing key related issues
rsleevi: key IDs, are they unique between appliations or are they shared?
... How to discover what key objects support what operations?
We need to have some concept of Key ID, we know we have key material, but need to define ID
rsleevi: Family of key?
vgb: Functional aspect of key, that need to be exposed
MitchZ: Key may depend on the level of access the appliation has
... for example, app A can only encrypt and app B can only decrypt with the same key
... key can be hardware, or software, but the operation is restricted to specific functionality
rsleevi: This also matches breaking down operations into specific ones like, encrypt, decrypt, sign etc.
MitchZ: Policies tied to these operations can complicate things
rsleevi: It is related to access control, who has right to use what?
vgb: Are these kinid of constraints better handled in the application itself
@@ We should also consider encrypted keys in the API
<ddahl> rsleevi: another key property: expirationTime ?
<MitchZ> +q if we're talking about key wrapping now
karen: I want to follow up with key wrapping, there are several key wrapping algorithms, e.g. NIST ones
... these are needed for FIPS certificatons
rsleevi: key wrapping is an opertion that should be distinct from other opertions
karen: What is in scope and what is out of scope?
... for example for crypto operations, where is the key stored? browser local storage, OS storage
... if in OS storage, other applications running in computer can access key as well
... also where is the crypto performed? in the browser or in an external token such as a smart card
rsleevi: How will the browser have access to the secure token
vgb: What would the application do different if the choice of key location is available in the API
... what advantage can be achieved by the application if API suports choice of key location
karen: what is our trust model, who do we trust? do we trust the browser, if not then the complete web appliation model can colapse
... we should specify what is trusted and what is not trusted.
virginie_galindo: this trust related security statement should be in the editor's draft
richard: It will he helpful to have an explicit key discovery, storage API
rsleevi: key is more than just private bytes, it has other attributes as well, some of these can be specified by the application
virginie_galindo: instead of having an open discission, let us clacify the categories and then have discusion on them
vgb: three families of keys; functional, ancilary (trust related, what you choose to do with keys), scope related (global, short lived, etc.)
sdurbha_: I would like to play devil's advocate, key should be open blob, you can put anything you want to put in them.
richard: what is the policy model, if they are the same entity why separate them
vgb: There are many cases where you want a trusted meta data, e.g. query, show be all the keys with non-expired certificates
sdurbha_: two things, search on a set of attributes, and enforcement
vgb: API is not enforcing these policies, they are application specific.
... functional attributes are exposed to application
... ancilary, non functional attributes such as expiration date,certificate parameters
karen: if private key is in a smart card, then the crypto operation should also be done in the smart card
sdurbha_: why define these key attributes because then where do we stop, how many attrubutes?
rsleevi: should have a common ontoloty, so it is good to define a structural notation for attributes
vgb: The third key family is scope, and access control
... scoping is enforced by user agent, cannot be manipulated by application, and require human in the loop
... Storage and Operator are not visible at the API level - since you do the same thing, regardless of the storage location
sdurbha_: If I want to query if a key is in smart card, instead of HTML5 or local storage, how is that done
MitchZ: In case of Netflix we trust what comes back from the API
... for example open browser is more prone to attack than the PS3 scenario
<arun> q>
If your application knows where it is running, you can make assumptions about the trust
hhalpin: In the carter we kept the keys minimally specified
mike: we should keep devices that have javascript without a browser in the scope
arun: we must discuss how user consent is solicited - it is a hard topic
markw: We need to talk about the key identifier, so we don't forget
ddahl: No discussion of javascript crypto since there is no storage mechanism
hhalpin: In charter we were worried about storage (safe key storage), if we cannot do it safely, we should not attempt, but I think we can
... also worried about access control, and especially complex ones
... also we will not specify user interface components
... it can be a guideline, but nothing more than that
rsleevi: we should therefore have asynchronous entry point for access control
nadim: NodeJS implemented wrapper to OpenSSL
... is it a good idea to have some measure of entropy included in attributes
rsleevi: it will be hard to measure that, and no API that reliably privides that on any platform
vgb: It is a philosophical concept
sdurbha_: do we want to know what appliation created the key?
<hhalpin> however, if people want to specify any attribute in a defined way, they should be able to add it
vgb: provenance of keys can be indicated
karen: what about owner of the key?
... owner can be related to the identifier, certain domain
mikew: List of growing key attributes demonstrates the need for use cases, to decide what is really needed.
virginie_galindo: we are closing the key attributes topic, the white board has a comprehensive list of attributes
karen: function and usage of key is important, if it is for signature it should only be used for sign not for encryption
asad: any access control on who can set the key attributes
rsleevi: These can be handles once we define the API and attributes in key object
<hhalpin> +1 functional should be immutable
<hhalpin> other ones can be mutable
<hhalpin> (going to capture these in IRC)
<hhalpin> Key Attributes:
sdurbha_: Can attributes be changed after they are created?
<hhalpin> s: supplementary (to be enforced by application
<hhalpin> scope: to be enforced by UA, reuqires user agent but user interface is out of scope
<hhalpin> functional: enforced at creation by ua, immuatable
<hhalpin> 1. access control (scope)
<hhalpin> 2. timing (expiration) (supplementary)
<hhalpin> 3. storage (open issue)
sdurbha_: the temporary attribute of a key is an attribute or a function paramter?
<hhalpin> 4. usage (cipher, signnature, extractable) (functional)
<hhalpin> 5. public or private key or symmetric
<hhalpin> 6. type (algorithm family * size) (functional)
<hhalpin> 7. temporary/permant: scope
vgb: this is an attribute specified when the key is generated
<hhalpin> 8. algoithm (functionlal)
<hhalpin> 9. operator (who executes) (open issue)
virginie_galindo: what should the application be able to access in the list of attributes?
<hhalpin> 10. privoveance, possibly using associate with certificate (supplenetary)
<hhalpin> 11. identifier/naming (function)
vgb: scope should be quried by application, but the other functional attributes should be accessible by application
... like a TLS session key
virginie_galindo: Storage aspect of the key is an open issue for now, we need to decide later
... discuss discovery of key is important and
rsleevi: one proposal is window.crypto.key
<rbarnes> i heard window.crypto.keys
rsleevi: other proposal is that if you are granted access to keys you have access
karen: who grants this access?
rsleevi: based on the query or through events like smart card insertion event
vgb: I am a little worried about remove aspect of key reference
rsleeve: it was included for cases such as smart card removal, it has to be baked into init
vgb: this is like taking application state model and moving it into API state model, should be avoided
... for example application should set a callback to handle such cases, smart card removal
rsleevi: some operations need smart card access for each operation, such as each sign operation. In such cases it is useful to have a remove scenio if the smart card is removed
vgb: we are inventing this, there is no commonly implemented crypto API that does this
... we have this whole notion of key object and key life-cycle. How about having a key reference instead
rsleevi: this can be handle by the agent, e.g. only a reference can be created first and the actual object is created when the init() is called
rbarnes: when you say key object do you mean object with properties
<rbarnes> ^^^ do you mean an object that actually contains keymat
rsleevi: the actual action on the key material happens when the operation is performed, not at init
markw: finding out attributes about the keys becomes another opertion
hhalpin: they can be getter operations
markw: key and key object can have different life-cycles
karen: key idenfier and key object are different
MitchZ: we will have performance issues if we initialize everthing on page load
rsleevi: browser can store a bunch of key IDs and their origin mapping, so it will be lightweight
ddalh: do we need OnCryptoKeyReady ?
rsleevi: window.crypto.keys is easy to use, and the initial state can be zero
... this is same as keyquerylist with no criteria
... these are keys created by your application
rbarnes: If keys are application generated why are the API use then.
<hhalpin> quick question - where is the key discovery in the Editor's Draft? I can't find it...
MitchZ: even getting the names of keys can be an expensive operation
<ddahl> hhalpin: it was in an email
<rsleevi> hhalpin: Sorry, it was sent to the mail list, I didn't put it in the draft yet
<hhalpin> OK, so if we get consensus on this approach, we need to add this to the draft spec
vgb: For keyquery list, when this is called when do the callbacks stop?
<ddahl> vgb: i can see how the application can determine when to ignore the keyQueryList callbacks
wtc: can be find out if an origin based key is already existing or need to be generated
rsleevi: It needs to be balaced with privacy
wseltzer: what about private browsing? can keys be aware of this scenario
karen: if user grants access to the key in smart card, then the key should be included in the list of keys
rsleevi: API should be unified, but allow selection based on certian criteria
MitchZ: As an application you know what keys you want to use
karen: May not not, sometimes you may not
hhalpin: we have made progress on key discovery, we are now cycling on ways to do key discovery. should add it to the public draft
... I have not heard any objections to key discovery
wtc: who is specifying window.crypto.keys ?
It is in Domcrypt
<hhalpin> ACTION: rsleevi to add the key query mechanism to editors draft, checking in with ddahl's edit [recorded in http://www.w3.org/2012/07/24-crypto-minutes.html#action04]
<trackbot> Created ACTION-16 - Add the key query mechanism to editors draft, checking in with ddahl's edit [on Ryan Sleevi - due 2012-07-31].
vgb: As refered in email, we should separate out parameters to operations from the parameters to algorithms
... similar but related note, should result always be a scalar
rsleevi: instead of defining a separeate object, it should be in the result, e.g. result.value etc.
wtc: should provide a way for an app to say it has consumed the onprocess data
<Zakim> arun, you wanted to talk about Key object format.
arun: How should discuss how the key look like in JavaScript, arraybuffer views, etc.
nadim: If Id and cypher text is separated it can be a problem, e.g since the keys cannot be transferred easily.
rbarnes: Base64 everyhing
<hhalpin> notes that the answer is to use JSON Web Keys
<hhalpin> http://self-issued.info/docs/draft-ietf-jose-json-web-key.html
<hhalpin> (looking for most current IETF draft)
mike: observation about naming - key discovery appear to me like lookup operation
<hhalpin> http://tools.ietf.org/html/draft-ietf-jose-json-web-key
<hhalpin> latest IETF version
mike: some keys may not allow this lookup, but any allow the use of keys
... e.g. using a hardware and trusting it to do the right alogorithm and the right key
rsleevi: such a hardware is out of scope
virginie_galindo: Yes, it is true some smart card will not allow any infomation about the keys
<hhalpin> we can't dicatate if all things (i.e. some smartcards) respond to the key discovery/lookup procedure
sdurbha_: should support extensibility for key storage
<hhalpin> but those that can should be able to, but that may not be the set of all keys actually that can be used
rsleevi: browsers already do this, since they do not implement crypto themselves currently, they delegate to other crypto providers
<wseltzer> [BREAK: 20 minutes]
<kaepora> ddahl: In the topic of key import, we should put that as a secondary feature
<kaepora> ..CORRECTION: we should move it from secondary to primary
<kaepora> (I AM NOW SCRIBING)
<kaepora> rsleevi: We should be on the same page on where the keys come from, other issues
<arun> ScribeNick kaepora
<kaepora> virginie_galindo: Should we talk about mandating algorithms or keep that until next conference call?
<kaepora> hhalpin: We should do "musts" now and "shoulds" later
<kaepora> virginie_galindo: Key generation, identification, will be discussed today.
<kaepora> ...everything related to algorithms will be discussed tomorrow
<kaepora> kaepora: We should discuss random number generation tomorrow
<kaepora> Mike Jones: Some keys are going to live in certificates, while others will be bare keys. So we shouldn't design our API in such a way that assumes that all cerificate properties apply to keys
<kaepora> Ryan: I agree with Mike Jones
<kaepora> MitchZ: Is it fair to say that everything X509 specific is out of scope?
<kaepora> Mike Jones: Not necessarily out of scope. Example: in the current JOSE drafts, you can do key lookups using SHA-1 of certificates. Not beautiful, but it's practical.
<kaepora> Mike Jones: But that shouldn't be the only way to look up the key
<kaepora> MitchZ: If I wanted to, I could store that X509 as a blob of data in my local store. We could say this is all X509 specific and out of scope
<kaepora> rsleevi: I don't want to rule it out of scope, but I don't want to expose ASN.1 in one DOM tree
<kaepora> Mike Jones: I want the result to be usable and practical
<kaepora> rsleevi: Thanks
<kaepora> MitchZ: I agree with Mike Jones
<kaepora> arun: HTML5 spec specifies a keygen element. We can't decouple ourselves from it. We should do something with it (expand it?)
<kaepora> ..is it out of scope?
<kaepora> rsleevi: Yes, but <keygen> is not well-implemented. Even on the Google side we are unhappy with it (as well as Microsoft) because it uses MD5 etc.
<kaepora> ..it was only specified in HTML5 for historical reasons
<kaepora> ..Yes, the keygen element exists, but by any means if we can deprecate it, then we should.
<kaepora> hhalpin: I think we should note that our API is completely separable from <keygen> and we should explain why
<kaepora> hhalpin: The reason why we put certs in secondary features is because of X509
<kaepora> ...JOSE had similar issues with X509
<kaepora> hhalpin seems to be heading out of the discussion
<kaepora> arun: It seems that <keygen> is bad, we should focus on doing the better thing
<kaepora> rsleevi: Yes, I agree, it used MD5 at the core which was bad, and it was not flexible enough
<kaepora> arun: <keygen> can also be a cautionary tale for us
<kaepora> rsleevi: Yes, I agree
<kaepora> ddahl: A lot of poeple want to either fix <keygen> or get rid of it completely
<kaepora> rsleevi: <keygen> as an API does not generate keys with specific domain restriction requirements. That's actually useful because some CAs provide keygen as a way to generate key pairs.
<kaepora> ...but we have to be very careful with it still
<Zakim> arun, you wanted to talk about KeyGen element
<kaepora> virginie_galindo: When you talk about key generation, what is left to us and what do you want to describe in the scope of the API?
<kaepora> Mike Jones: Good question!
<kaepora> rsleevi: David put together a key generator object and I took some of the intitial parameters. We got this list of attributes now and it's useful to think if applications specify them on creation. Also, what attributes are useful to specify on creation, etc.
<kaepora> ddahl: Also expiration is an issue, and cross-domain is another issues. We should specify expiry date and on which domains I want to use that key
<kaepora> rsleevi: I want to create section 11 on the API draft
<rsleevi> Sorry, we /have/ a section 11 :) It's what we want to discuss
<kaepora> virginie_galindo: OK, so we need to discuss the key ID then
<kaepora> rsleevi: Thanks
<kaepora> virginie_galindo: Let's start with the key identifier, Marc?
<kaepora> ddahl: If you look at section 11, it's chicken and egg;
<kaepora> markw: You need identifiers for keys on each device
<kaepora> markw: If I send a key to the server-side, the server side needs to know which key was used to sign that message
<kaepora> rsleevi: The question is how to refer to keys in a unique way, then
<kaepora> markw: Exactly
<kaepora> rsleevi: Do you think it's possible to define a unique global namespace to define the key (to Mitch)
<kaepora> Sitarama: Applications are responsible for uniqueness within a single domain, not globally
<kaepora> rsleevi: We're saying that MitchZ's Netflix application will specify the key namespace
<kaepora> ..not globally
<kaepora> markw: With pre-provisioned keys, the identifier has to be created when the keyu is pre-provisioned
<kaepora> Vijay: Both the client and the server need to know the key identifier then, right?
<kaepora> ...why not let the application specify the pre-provisioned key
<kaepora> Vijay: the problem with pre-provisioned keys is that they're created outside the browser
<kaepora> Vijay: Would adding sidecar data satisfy Netflix key requirements?
<kaepora> MitchZ: Yes
<kaepora> markw: Identifiers are only required for server-side key operations
<kaepora> *server-side pre-provisioned key operations
<kaepora> MitchZ: I think unique identifiers are useful beyond pre-provisioned keys
<kaepora> Vijay: What if an application creates two keys for the same purpose by mistake?
<kaepora> karen: This is an application-specific problem, not our problem
<kaepora> arun: How do you get two keys by mistake?
<kaepora> MitchZ: Key renewal occurs frequently, mistakes may happen there
<kaepora> rsleevi: I feel that you can put whatever you want in a opaque client-side blob: there is a privacy concern there
<rsleevi> ACTION mitchz to review key generation and propose a way for user agents to expose unique IDs as first class
<trackbot> Sorry, couldn't find user - mitchz
<rsleevi> ACTION Mitch to review key generation and propose a way for user agents to expose unique IDs as first class
<trackbot> Created ACTION-17 - Review key generation and propose a way for user agents to expose unique IDs as first class [on Mitch Zollinger - due 2012-07-31].
<rsleevi> kaepora: In favor of proposal from Netflix and descriptions of the use case, but concerns regarding the exact referencing of Netflix and feels there should be a neutrality policy
<rsleevi> wseltzer: There is not a general problem with identifying the source of use cases, or of directly engaging the providers. It does become problematic if the API does start to sway towards a particular provider or implementor
<rsleevi> wseltzer: It's a valid response to say that the discussion about unique IDs may be tied to Netflix's needs
<rsleevi> virginie_galindo: Reasonable to describe some anonymized form, but the direct inclusion of Netflix's use case is perhaps fine, since they provided a complete use case
<ddahl> kaepora: The netflix use case is 100% about identifying a device properly so the proper type of stream can be sent to it - the stream is encrypted and all DRM is handled deep inside the graphics chipsets, etc
<kaepora> ddahl (NOT SCRIBING): So the Netflix use case is not DRM-protected content delivery?
<ddahl> kaepora: indeed
<kaepora> Um
<kaepora> I disagre
<rbarnes> kaepora: it's key agreement and client authentication
<kaepora> http://www.w3.org/wiki/index.php?title=NetflixWebCryptoUseCase&oldid=55948
<ddahl> kaepora: we discussed this at length in a meeting between moz, google and netflicx last year
<ddahl> kaepora: yep, it is a misnomer
<kaepora> How is "DRM" license exchanges a misnomer?
<kaepora> *"DRM license exchanges"
<ddahl> kaepora, if you are reading that in the use case those pieces should be renamed
<rbarnes> kaepora: neither "license" nor "DRM" appears in the use case doc
<rbarnes> http://www.w3.org/wiki/NetflixWebCryptoUseCase
<kaepora> Yes, they were edited out
<kaepora> http://www.w3.org/wiki/index.php?title=NetflixWebCryptoUseCase&oldid=55948
<kaepora> But they were there
<kaepora> They were edited out only after I complained about it a few months back
<kaepora> The rest of the spec was kept intact
<ddahl> kaepora, there is no way that the content owners would ever allow a browser DOM API handle decoded data
<rbarnes> kaepora: "such as..."
<kaepora> OK
<kaepora> I am unconvinced
<ddahl> kaepora, that's OK, you might be convinced once you chat with Mitch and Mark:)
<kaepora> "authorization to play movies" means DRM
<kaepora> Sorry
<kaepora> It's just the case
<kaepora> It's the textbook definition of DRM
<ddahl> kaepora, no, it is much more akin to "what kind of blue ray player are you and who is your owner?" that is the only thing they will do with this API
<kaepora> ddahl: Cryptographically verifying the owner is also cryptographically verifying whether they are allowed to play content
<kaepora> Which means DRM
<rbarnes> kaepora: so you're not cool with authentication?
<ddahl> kaepora, we can agree to disagree then. this is the least of our worries really
<kaepora> rbarnes, of course I am, that's not what I'm saying
<ddahl> arun++
<kaepora> rbarnes, I am arguing that Netflix is promoting DRM in the Use Case document
<arun> kaepora, above ^ is the actual "DRM spec" as intended for HTML5. You'll note that there's a difference in use cases.
<ddahl> kaepora, i think this might be an issue if netflix was SELLING movies. They are not, they are renting movies. Data you agree you do not own.
<kaepora> Wow, that Encrypted Media Extensions spec is sad and modestly horrifying
<kaepora> Since when do we think it's a good idea to allow DRM content in browsers?
ISSUE-2?
<trackbot> ISSUE-2 -- How to address pre-provisioned keys and managing ACLs -- pending review
<trackbot> http://www.w3.org/2012/webcrypto/track/issues/2
<kaepora> arun, I understand
<kaepora> That Encrypted Media Extensions spec is morally bankrupt
<kaepora> How is it OK to facilitiate DRM on the web?
<ddahl> kaepora, I certainly don't intend on using any DRM-based systems, however, in the world of "rental entertainment streaming" i feel it is mostly benign. You are using DRM to watch rented video streams. If the video was sold to you, and you had no way to extract the data for a backup, that is a different situation entrely
<kaepora> WTF?
<arun> kaepora, many many ppl would agree with you :) however, that debate occurs elsewhere. Read this, for example: http://lists.w3.org/Archives/Public/public-html/2012Feb/0274.html
<ddahl> kaepora, i reccommend we get a beer later
<rbarnes> kaepora: standards organizations do what the community wants to do. apparently there was community consensus around the Encrypted Media Extensions
<kaepora> ddahl, even if you intend that technology to be used for rented video, that doesn't mean it won't be used for everything else
<kaepora> rbarnes, I find that very hard to believe
<ddahl> kaepora, indeed. Like I said before there are way bigger issues to also ponder:)
<rsleevi> ACTION Ryan Sleevi to propose a method for key generation that fully specifies the intended algorithm usage (eg: RSA-PSS), not just the algorithm family (eg: RSA)
<trackbot> Created ACTION-18 - Sleevi to propose a method for key generation that fully specifies the intended algorithm usage (eg: RSA-PSS), not just the algorithm family (eg: RSA) [on Ryan Sleevi - due 2012-08-01].
<kaepora> ddahl, is Firefox going to implement Encrypted Media Extensions?
<arun> kaepora, yep. not in present form, but Mozilla generally will go in the direction of DRM in browsers.
<kaepora> arun, Not sure how Firefox promotes itself as a defender of user rights and freedoms then
<kaepora> arun, Isn't that its main marketing gig over Chrome?
<arun> kaepora, 'rights and freedom' is NOT narrowly defined. Read this, for example: http://brendaneich.com/2012/03/video-mobile-and-the-open-web/
<karen> Mitch: want lighter key exchange method than SSL
<karen> ... currently, using DH
<karen> ... would like to see DH in scope
<karen> Ryan: agree
<ddahl> was anyone still on the phone?
<ddahl> the call to the conference bridge died
<ddahl> i can re-dial if need be
<karen> Mitch: another important thing is key protection. Want to be able to protect the shared secret and transform it to a key
<karen> Ryan: key derivation is similar in scope as key generation
<kaepora> Mike Jones: Defining concat();
<kaepora> rsleevi: I propose have a key derivation proposal for ECDH
<kaepora> MitchZ: I am OK with handling action item proposed by rsleevi
<hhalpin> \me just made minutes
<wseltzer> virginie_galindo: When will we get through actions, be ready for publication of first working draft?
<wseltzer> hhalpin: Schedule had us at FPWD in June. We can slip some, but shouldn't slip for months.
<wseltzer> ... better to push out something rough, with open issues, than not publish.
<wseltzer> rsleevi: before FPWD, want to define major issues, e.g. key derivation, state machine IDL,
<wseltzer> wtc: 3 weeks out
<wseltzer> hhalpin: take a break next week (IETF), then back to work?
<wseltzer> virginie_galindo: close today, hold the algorithm discussion until tomorrow?
<wseltzer> ... Tomorrow: next steps to FPWD, review use cases;
<wseltzer> ... left from today, random generation, algorithms MUST/SHOULD
<wseltzer> cjkula: key import?
<wseltzer> ddahl: originally secondary feature, move it to primary?
<wseltzer> asad: external tokens? in or out of scope?
<wseltzer> ... may be helpful to narrow list of key attributes
<wseltzer> virginie_galindo: re: algorithms, Mike's table, SHOULD/MUSI is still open because some poeple are asking for MUST
<wseltzer> virginie_galindo: Thank you! Reconvene tomorrow at 9 Pacific.