<trackbot> Date: 06 August 2012

<mitch_z> aaee is mitch_z

<mitch_z> aaee is mitch_z and markw

<asad> +1.512.257.aabb is asad

<wseltzer> virginie: do we have a volunteer to scribe?

<wseltzer> scribenick: wtc

<wseltzer> scribe: wtc

virginie: are there any comments on the minutes of the July face-to-face meeting?
... the meeting minutes are approved.

<wseltzer> [F2F minutes: http://www.w3.org/2012/07/24-crypto-minutes.html and http://www.w3.org/2012/07/25-crypto-minutes.html]

virginie: there have been some new discussions on the mailing list about use cases, and Ryan Sleevi posted an updated API draft.
... in this conf call, we will bring everyone up to date on the current status and issues.

+q

Use Cases

<wseltzer> wtc: many of the use cases suggested by Technology Nexus are out of scope

<wseltzer> ... some related to signing a challenge sent by user are covered by JimD and Asad's

<wseltzer> [use cases: http://www.w3.org/2012/webcrypto/wiki/Use_Cases]

virginie: we may have opened an issue for the use case of signed scripts.

<rsleevi> http://www.w3.org/TR/capture-scenarios/

rsleevi: related to use cases, one of the changes I made to the Editor's draft is to describe the relation of the API to the use cases at a high level. Please review it and make sure the use cases are representational.
... I added a new issue for encrypted/signed scripts and encrypted images.

<rsleevi> http://www.w3.org/2012/webcrypto/WebCryptoAPI/#use-cases

rsleevi: please review that and think about how the API might work to support those use cases.

asad: I want to bring up issue #11.

<cjkula> We had a first round of communication with the FB use case. Need to follow up.

asad: regarding specifying the location as an attribute of the key.

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

<cjkula> (Signed scripts)

asad: question: in the absence of a location/storage attribute, how does an app determine if a key is in a secure element?

<Zakim> rsleevi, you wanted to respond to asad

rsleevi: as a hypothetical example, if the application (service provider) provides the smart card, then they know if a user has a certain key, the key must be on the smart card.

<hhalpin_> we could "informatively" suggest user-interface interactions, but normatively the best we can say is "*some* user interaction is happens here"

<virginie> thanks chris for the reference to the FB usecase http://www.w3.org/2012/webcrypto/track/actions/28

rsleevi: in the other scenario, how the smart card is exposed to the user is implementation independent. I think if the user agent could remember the key is stored on the smart card and prompt the user to insert the smart card.
... the spec should not prescribe the behavior of the implementation/UI.

<hhalpin_> can't an application-defined attribute handle that?

<hhalpin_> unless you want a attribute for "all possible smartcards", but then that's hard to enforce :(

rsleevi: the user experience may be similar to SSL/TLS client authentication.

<rsleevi> ACTION: Ryan to update the editor's draft regarding ISSUE-11, based on harry's suggestion to add informative suggestion [recorded in http://www.w3.org/2012/08/06-crypto-minutes.html#action01]

<trackbot> Created ACTION-30 - Update the editor's draft regarding ISSUE-11, based on harry's suggestion to add informative suggestion [on Ryan Sleevi - due 2012-08-13].

Updated API

virginie: next agenda item: rsleevi to present the recent revisions to the API draft.

<ddahl> -1 : was on holiday

<virginie> http://www.w3.org/2012/webcrypto/WebCryptoAPI/

rsleevi: I sent the update to the mailing list. I had been travelling, so only had time to update it over the weekend.
... I focused on updating the use cases section (section 2). I didn't update sections 3-8 and 9.
... section 10 (the key interface) needs continuous discussion.
... I added an IDL definition and opened issues for issues that need to be addressed.

<wseltzer> ISSUE-16?

<trackbot> ISSUE-16 -- Definition for Key Expiration -- raised

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

rsleevi: start date and end date are to support key expiration and validity period (issue 16).

virginie: where is "origin" indicated in the key definition?

rsleevi: key authorized origin is an attribute that isn't exposed.
... sections 13-14 (key generation) are also new.

<wseltzer> ISSUE-14?

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

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

rsleevi: I'd like to discuss issue 14.

<rsleevi> https://www.w3.org/2012/webcrypto/track/issues/14

rsleevi: issue 14: how key material should be exposed.
... in other words, what does a key look like?

vgb: two use cases for passing key material around. For AES keys, just the key bytes because there are no structures to it.
... for signature verification we need to import the public key into the system. The most common format of public keys is ASN.1 encoded. If I have to pick a format, I'd pick PKCS #1 (for RSA public keys)

<hhalpin_> www.cosic.esat.kuleuven.be/publications/article-1432.pdf

halpin: ASN.1 is the de facto format for public keys.
... there is a desire to also support a simper, JSON-based format as well.
... we should not force people to use ASN.1 if they don't have to, but I am open to this issue.
... we should encourage people to use JWK, but I'd like to hear people's opinions on this.

rsleevi: JWK cannot represent private keys, and only has a version 1 format of public keys.

<wseltzer> ISSUE-13?

<trackbot> ISSUE-13 -- Relationship between the W3C Web Cryptography work product and the IETF JOSE WG -- raised

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

rsleevi: broader issue is issue 13: how closely should our API be tied to JOSE.

halpin: we don't want to depend on JOSE in such a way that they block us, on the other hand, JOSE should finish their work before us.
... issues are whether we need another JSON-based format, and how do we make it easy for web apps to use ASN.1.
... for backward compatibility, we'll need to support some ASN.1.

<rsleevi> +1 SGTM. That was my motivation in raising ISSUE-13 and ISSUE-14, to make sure people start considering these issues as we move forward.

halpin: can't force people to use formats they aren't using.

<ddahl> it seems like we are better off using ASN.1 as really no one right *now* actually uses JOSE, and JOSE does not cover all of our uses

<hhalpin_> Yes, Mike is the official liason

<ddahl> that being said, I can see later adding some utility methods to covert to JOSE where applicable

virginie: we'll assign an action to Mike Jones to address the key format issue...

<hhalpin_> My take is ASN.1 in low-level makes sense *if* we need it, but put a note about possible use of JOSE formats to get feedback from community would be appropriate

<ddahl> pubKey.toJOSE(), etc

rsleevi: we can use issue 14 to track this discussion.

<cjkula> Maybe JOSE should represent the core supported set of formats, with a recommended set of utilities to support ASN.1?

rsleevi: for now we'll presume ASN.1, but equally expect that it may change.

<rsleevi> ddahl: Yeah, in also thinking about sync vs async export, it probably needs to be a method/object, in which case the caller can specify the format

rsleevi: issue 16: key exiration.

<ddahl> cjkula: that is also an approach we can think about, we should put together a matrix that explains what key/data JOSE will be able to encapsulate in our work - what are all of the missing links?

rsleevi: not all APIs have the notion of key expiration, and the semantics for applications may differ (e.g., whether an expired key can still be used).

mitch_z: if we're defining certificates as a first-class object, that seems to imply X.509 certificates seem to be preferred over other kinds of authentication technology such as Kerberos. I wonder if we can define authentication tokens in a more generic way.

rsleevi: one motivation for making certificates first-class is that they are part of the working group's charter.

<rsleevi> http://www.w3.org/2011/11/webcryptography-charter.html

rsleevi: they're in the secondary features.

mitch_z: we should be able to include one authentication technology without excluding others.

rsleevi: I'd prefer to avoid having certificates as first-class objects if possible. We should continue to discuss this.

<mitch_z> Virginie, did you want me to open an action? or start an email thread?

<rsleevi> mitch_z: My vote would be a new thread that references ISSUE-15 (so we know it's tied to certs), but we can discuss the specific points exclusively in that thread

vgb: key start date and end date: I suggest keeping them advisory.

<mitch_z> i'll add something to the Netflix use case as well as send out an email

vgb: can't use the private signing key after expiration, but should be able to use an expired public key to verify old signatures.

<rsleevi> Right, I hopefully captured vgb's point in http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug/0022.html

vgb: better leave this to the application to determine the appropriate behavior.

virginie: so the user agent should do nothing other than exposing the start/end dates?

rsleevi: yes, some key attributes are intrinsic, whereas others we just stuff them in the key object.
... issue 17: how should key attributes be stored? In our own storage or in an existing key-value store in the web API.
... the issues are the lifetime of attributes and whether some attributes are read-only.
... we have enough issues raised on the mailing list and in the issue tracker :)

virginie: next Monday we will do the conf call.

ddahl: having user attributes that are user customizable, I don't think they will cause confusion. Seems like a handy thing to have.

karen: question on issue 17: are we considering to store key attributes in different places?

rsleevi: this is up to the OS APIs/implementations.
... some attributes are read only or defined only at creation time.

virginie: group life: book your hotel and fight for TPAC.

<wseltzer> [TPAC info: http://www.w3.org/2012/10/TPAC/ ]

virgine: next week we'll review the actions.

<wseltzer> trackbot, end teleconf

This is scribe.perl Revision: 1.136  of Date: 2011/05/12 12:01:43  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: i/wtc: many of the use cases/Topic: Use Cases
Found ScribeNick: wtc
Found Scribe: wtc
Inferring ScribeNick: wtc
Default Present: +1.773.939.aaaa, +1.512.257.aabb, +1.650.214.aacc, drogersuk, WSeltzer, +1.510.387.aadd, +1.408.540.aaee, cjkula, +1.707.799.aaff, ddahl, +33.6.13.23.aagg, emily, Google, rsleevi, virginie, wtc, mitch_z, markw, vgb, +1.512.257.aahh, karen, hhalpin
Present: +1.773.939.aaaa +1.512.257.aabb +1.650.214.aacc drogersuk WSeltzer +1.510.387.aadd +1.408.540.aaee cjkula +1.707.799.aaff ddahl +33.6.13.23.aagg emily Google rsleevi virginie wtc mitch_z markw vgb +1.512.257.aahh karen hhalpin
Found Date: 06 Aug 2012
Guessing minutes URL: http://www.w3.org/2012/08/06-crypto-minutes.html
People with action items: ryan

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.