See also: IRC log
<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.
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.
<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: 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
... I added a new issue for encrypted/signed scripts and encrypted images.
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.
<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
... 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].
virginie: next agenda item: rsleevi to present the recent revisions to the API draft.
<ddahl> -1 : was on holiday
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.
<trackbot> ISSUE-16 -- Definition for Key Expiration -- raised
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.
<trackbot> ISSUE-14 -- Representation of raw key material -- raised
rsleevi: I'd like to discuss issue 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)
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.
<trackbot> ISSUE-13 -- Relationship between the W3C Web Cryptography work product and the IETF JOSE WG -- raised
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: 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
... 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
... 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, +18.104.22.168.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 +22.214.171.124.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.[End of scribe.perl diagnostic output]