<trackbot> Date: 16 July 2012

I will scribe

virginie_galindo: meeting started, agenda approved

virginie_galindo: No new members this week. Previous call's meeting minutes are approved with no objections.

Use Cases

Use case discussion:

Some certificate-based used cases are moved to the secondary feature use cases

JimD: (jdavenpo@mitre) does the smart-card based proposal from a few weeks ago conflict with the algorithm discovery

<karen_> June 4th

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

virginie_galindo: API should not rely on smart-card technology

virginie_galindo: insert smart cards use cases into use cases
... need to clarify "what is a smart card" with use cases

<rsleevi> ACTION: wtc to work with channy to improve the use cases document [recorded in http://www.w3.org/2012/07/16-crypto-minutes.html#action01]

<trackbot> ACTION-11

wtc: agrees that we need to include smart cards, need to improve language in the document

asad: API will not mandate use of smart cards, but it should not preclude the use of smart cards if the use wants to do that
... need to determine where the keys are stored (browser or external elements)

virginie_galindo: need clarification of scope of API regarding where keys are stored

<scribe> ACTION: JimD to clarify scope of API regarding key storage and smart card use due 2012-07-23 [recorded in http://www.w3.org/2012/07/16-crypto-minutes.html#action02]

<trackbot> ACTION-12

karen: smart cards use cases show more than just authentication use cases

vgb: need to support smart cards on API, but the web security model will be executed in potentially a "hostile environment" and therefore it may not be wise to allow outside execution of untrusted code

<rsleevi> +1 to vgb; it does not make sense to expose the details of how a key is stored

vbg: supports operations using keys from smart cards but not using crypto alrorithms from those cards (or external devices)

private keys cannot be retrieved from smart cards

private keys cannot be retrieved from (most) smart cards

<wtc> I volunteer to 1) make an editing pass over the Use Cases draft, and 2) go over the lists of primary and secondary features to make sure they're disjoint.

<karen_> and my use cases

Draft API review

ddahl: have not updated API draft yet
... will update with recent discussions
... significant recent discussion regarding key extraction and method naming in low-level API

virginie_galindo: had previous agreement with algorithm discovery

<wseltzer> ISSUE-3?

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

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

ryan: is discovery mechanism needed? completely agnostic WRT smart cards
... still a need for an asyncronous discovery mechanism

vgb: need to define what the discovery mechanism would look like. should discuss at the FTF

virginie_galindo: need to determine pros and cons. will add it as future agenda item, working on error management mechanism

vgb: proposal for managing alrorithms. will do "should" and not "must" in proposed document

drogersuk: will revise wording

<ddahl> SHOULD not MUST was indeed the last consensus we were approaching - I thought so anyway

virginie_galindo: for each SHOULD, need to specify test cases to allow for compliance testing

<rsleevi> +1, that's my understanding.

<wseltzer> trackbot, status?

drogersuk: need have a fresh start and so did not include older alrorithms.
... considered smaller/mobile devices
... please treat this as a starting point, but it will still need to be adjusted. Input welcomed.

virginie_galindo: should deliver something reliable to developers and therefore needs to have a succinct alrorithm list
... should have a smaller alrorithm set, which will have higher value than allowing a high number of algorithms

sdurbha: SHOULD vs MUST. Most developers will pay the most attention to the MUST requirements

virginie_galindo: will have a SHOULD and for each SHOULD, will have a test case

SHOULD gramatically implies "maybe it ought to"

<rsleevi> JimD: No, that's MAY

MUST implies that it has to

<rsleevi> According to the RFC terms

drogersuk: should agree to a base set of algorithms

<rsleevi> That was the consensus we had reached, as I understood it

drogersuk: first determine the base set of algorithms, and THEN argue about language

karen: for the list of algorithms, should include most commonly used algorithms
... like SHA-1
... and other common (even older) algorithms
... where do we draw the lines for the algorithm list?

drogersuk: there are active use cases that use older algorithms that will still be needed
... ECC is off the list

<drogersuk> q_

ryan: regarding the list of algorithms, specify how the algorithm should behave and what inputs are expected

<drogersuk> my comment on the call: if there are significant use cases for an older algorithm and you all agree it then include it, but it would be good to at least try and make a fresh start

ryan: if there is an algo that is useful, then the proponent of that algo should draft a use case and API mods as needed
... using app should have well-defined behavior by specifying parameters for each algo
... doesn't have to have a use case, but there should be a description of expected behavior for similar groupings of algorithms
... for test cases, there should be specific test cases for the API and for the output or "known answer test"

wseltzer: XMLsec PAG group is discussing ECC patent issues. will report later on progress of this item and whether this will impact this group

<wseltzer> [PAG = Patent Advisory Group]

drogersuk: recommend leaving ECC off dicussion and picking it up later when more is known

<rsleevi> Without defining MUST implement, I do not believe there are any problems with ECC. Historically, the problems have been MUST, which is why it's traditionally been OPTIONAL

virginie_galindo: we will work on list of algo, will ensure behavior is well described
... when list is stable, will then at that point discuss SHOULD vs SHALL

<wseltzer> ISSUE-1?

<trackbot> ISSUE-1 -- Should we have mandatory algorithms? -- open

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

ryan: can we close out issue 1 (MUST vs SHOULD)

virginie_galindo: we are defining a set of common algorithms. perhaps it should be reformulated as an issue regarding SHOULD vs SHALL

wseltzer: agree that we should reformulate question

virginie_galindo: Issue #1 is closed, will open a new one with SHOULD vs MUST

<wseltzer> RESOLVED: Close ISSUE-1, open new issue to address SHOULD versus MUST

ryan: whether or not a key is extractable depends on who and how the key was provisioned

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

ryan: if the app provisioned the key, then it should be allowed to extract the key
... but the browser and operating environment may prohibit the key extraction

virginie_galindo: Eric mentioned that it is up to the implementation as to whether the key is protected

<ddahl> rsleevi: yes, this is a subtle difference to my proposal, but sounds like a a good guideline where the browser may overrule the request

virginie_galindo: can rely on extractable/not-extractable key property

ryan: if you have a pre-provisioned key, it may not be extractable
... the underlying implementation may not allow key extraction
... will often be outside the control of the using app
... may not be extractable under various circumstances outlined in email
... clear error-handling needs to account for this

virginie_galindo: should this be considered as a new issue?
... the API, by design, could have a mechanism whereby the key is not extractable by another mechanism

ryan: there are different interpretations here for "may not be extracted"
... need to have a good definition for extractability/non-extractability

<rsleevi> ACTION: Ryan Sleevi to propose a strong definition of what "extractable" / "non-extractable" means [recorded in http://www.w3.org/2012/07/16-crypto-minutes.html#action04]

<trackbot> Created ACTION-10 - Sleevi to propose a strong definition of what "extractable" / "non-extractable" means [on Ryan Sleevi - due 2012-07-23].

virginie_galindo: should document API in most accurate way. editors should implement discussion items

sdurbha: when would someone need to have access to raw key previously provisioned?

<rsleevi> sdurbha: See thread "I would like to have raw key exchange", and the related discussion about custom key-derivation / key-agreement functions

<rsleevi> sdurbha: eg: implementing in JS an algorithm not provided by the browser (eg: ZRTP)

email topic is "unsafe key exchange"

ryan: there may be cases where someone may need access to the key with certain algorithms

<rsleevi> http://lists.w3.org/Archives/Public/public-webcrypto/2012Jun/0099.html is the relevant thread

<rsleevi> (for ZRTP)

<rsleevi> http://lists.w3.org/Archives/Public/public-webcrypto/2012Jun/0050.html for the conversation of lifetimes

asad: PKI implementation may need public key extraction and exchange
... other algorithms may have other key extraction needs, so the feature should be available

<virginie_galindo> http://www.w3.org/2012/webcrypto/track/actions/open

virginie_galindo: formal review of actions
... action 1 is "To help collect use-cases around key isolation"

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

MitchZ: will update thread with status

virginie_galindo: action 7 "a proposal for mapping strings (JOSE IETF work) to algorithm objects" is mostly done

ryan: proposal done to mailing list. no comments, so action closed

<rsleevi> ACTION-7: http://lists.w3.org/Archives/Public/public-webcrypto/2012Jul/0030.html

<trackbot> ACTION-7 a proposal for mapping strings (JOSE IETF work) to algorithm objects notes added

<asad> ACTION-2?

<trackbot> ACTION-2 -- Nadim Kobeissi to to start a wikipage to start collecting the use-cases for secondary features -- due 2012-07-02 -- OPEN

<trackbot> http://www.w3.org/2012/webcrypto/track/actions/2

virginie_galindo: action 2 (to start a wikipage to start collecting the use-cases for secondary features) might be closed... will check offline
... action 8 from David Rogers closed, proposal received
... Face to Face meeting agenda: have discussion of different variables with priority on APIs
... list different open points, items that need clarification
... 8 hours provisioned to go through different topics for dicussions

<ddahl> virginie_galindo: will we have a telecon next monday?

virginie_galindo: review API, and clarify technical aspects
... goal is to have people understand where we are, what are our problems, and create examples with appropriate vocabulary
... go through API line-by-line, go through test cases, tools

<MitchZ> +1: would like to review the examples in the the API spec

virginie_galindo: 11 or 12 people expected to attend. It's not too late to register, so please do if you have not already
... will start 0930 on first day, ending at 1730
... will work from 0900-1700 on other days

<wseltzer> trackbot, end telecon