See also: IRC log
<rbarnes> virginie: any suggestions regarding the agenda? hearing none
<trackbot> Date: 18 March 2013
<wseltzer> scribenick: rbarnes
<virginie> http://www.w3.org/2013/03/04-crypto-minutes.html
chair requests approval of previous minutes. approved without objection.
<hhalpin> RESOLVED: http://www.w3.org/2013/03/04-crypto-minutes.html are approved for the minutes
virginie: important to update the charter about when and what we will deliver
discussion last time was between 6/9 months, no clear resolution
<hhalpin> Note we can turn things in at 6 months
w3c leadership / roessler suggested being conservative, going for 9 months
<hhalpin> But W3C felt that 9 months would be safe, and prevent us from revisiting this in case things slipped a bit.
<virginie> http://lists.w3.org/Archives/Public/public-webcrypto/2013Mar/0087.html
intention is to remove the notion of "high-level" and just say "api"
<hhalpin> PROPOSAL: Extend charter by 9 months and delete word "high-level" from "The mission of the Web Cryptography Working Group, part of the Security Activity, is to define a high-level API providing common cryptographic functionality to Web Applications."
<hhalpin> Just in case :)
<hhalpin> We can still deliver the high-level
<hhalpin> but...we don't have to!
<hhalpin> If we get end up focussing on low-level
<wseltzer> rbarnes: comment on removal of high-level; want to make sure we're clear that the audience for this API is general web developers, not those with degrees in crypto
ack
<wseltzer> ... should still be the group's objective to produce something usable by ordinary web developers
<rsleevi> does not agree to Richard's statement of our deliverables/use case
virginie: definitely, it's not a matter of making the API more complicated, still an objective to be usable by developers
<hhalpin> Anyways, in IRC - tlr (Thomas Roessler, domain lead for Security Area) wants to make sure ordinary web developers are in audience, but he felt we needed to be very clear if we were promising to deliver a high-level or not.
rsleevi: clearly our discussions focused on a low-level API, and we have an obligation to deliver on that
<hhalpin> I think tlr and some will be disappointed if we don't deliver that, but the WG is de-facto focussed on "low-level"
<wseltzer> rbarnes: some features of an API can make it easy for inexperienced developers to make mistakes
<rsleevi> We should probably take this to the list for further discussion.
<hhalpin> there's a great thread on indexedDB going on www-tag@w3.org about "easy-to-use" if folks want to read up on it.
virginie: we'll continue discussion on the list, focused on low-level; not much discussion of high-level
... so we will continue as planned: low-level, key discovery, maybe high-level
<hhalpin> We will keep the secondary features, but must be more use-case driven.
virginie: hearing rbarnes not as objection, just clarification, so hearing no objection to the proposal
<hhalpin> I think Apple just dropped
<wseltzer> PROPOSAL: extend charter as proposed in email
<hhalpin> +1
<virginie> PROPOSAL: Extend charter by 9 months and delete word "high-level" from "The mission of the Web Cryptography Working Group, part of the Security Activity, is to define a high-level API providing common cryptographic functionality to Web Applications."
<wseltzer> [http://lists.w3.org/Archives/Public/public-webcrypto/2013Mar/0087.html]
<karen> +1
+1
<markw_> +1
<rsleevi> +1
<ddahl> +1
<virginie> +1
<wseltzer> +1
<nvdbleek> +1
<hhalpin> RESOLVED: Extend charter by 9 months and delete word "high-level" from "The mission of the Web Cryptography Working Group, part of the Security Activity, is to define a high-level API providing common cryptographic functionality to Web Applications."
<hhalpin> ACTION: wseltzer, hhalpin, and virgine make sure this is communicated to W3C [recorded in http://www.w3.org/2013/03/18-crypto-minutes.html#action01]
<trackbot> Error finding 'wseltzer,'. You can review and register nicknames at <http://www.w3.org/2012/webcrypto/track/users>.
<hhalpin> (I'll do that email now)
<wseltzer> scribenick: wseltzer
rbarnes: I was at JOSE, not at CFRG
... JOSE is IETF group defining JSON- based object format
... instead of XML or ASN1, they're using JSON
... Perform a crypto op, algorightm ID, key, ciphertext or signature
... JOSE is a natural target for this API
... This group had talked to JOSE about wrapped key formats.
... WebCrypto API is producing a way to export wrapped keys;
... JWK format (JSON Web Key) is a JOSE format
... Right now, there's a syntax defined for public keys;
... in response to WebCrypto request, developing a format for private and symmetric keys, encrypting, defining attributes
... Agreement on what we were supposed to deliver.
... encode private and symm keys, encrypt, attach attribs
<hhalpin> +1 agreement that JOSE accepted the request from this WG :)
rbarnes: Now, figuring out how to do that.
... Working on a draft now, proceeding relatively quickly.
<hhalpin> How about algorithm identifiers??
rbarnes: Also work on encrypted signed objects
... CFRG what algorithms are appropriate to use in wrapped signed objects?
... Which algos will be possible in key-wrapping framework?
virginie: Do you have any specific references or timeline to share?
rbarnes: I was given an action by the WG to produce a combined draft
... will share a link when available.
... Timeline: loose, but expect to have a general idea of syntax in next 4-6 wks
virginie: will you have anything to share by our next f2f?
rbarnes: there will definitely be a publicly available draft
... Whether it's a WG draft depends on the WG
... not impossible we'd have a WG draft by f2f
vgb: When you talk about key-wrapping algorithms, is that a question of priorities, or will those not defined be forbidden?
rbarnes: a bit of both. discussion largely around syntax
... 2 main design. taking current encrypted object format, and wrapping keys, or @@
... there's a good chance we'll end up needing both
... please share feedback on use cases with list.
vgb: Approach 1: JWE, message is JWK
<rbarnes> 1. JWK within JWE, 2. JWE with empty message
vgb: Approach 2: JWE with empty message
... strong desire in crypto community not to use AES keywrap
markw_: How would 2d approach handle using RSA key to protect data of arbitrary size?
rbarnes: we'd need to add something like RSA-KEM
virginie: rbarnes, how can we best coordinate with JOSE?
rbarnes: I can post a message to JOSE list summarizing the group's feedback
... Members of the group can also post to the list, add use cases
<scribe> scribenick: rbarnes
mark: proposal was made to do wrap/unwrap using JWK within JWE
... [draft-miller-jose-jwe-protected-jwk, or something like that]
... haven't been that many contributions to that discussion
<virginie> http://lists.w3.org/Archives/Public/public-webcrypto/2013Mar/0076.html
<markw_> http://www.w3.org/2012/webcrypto/wiki/KeyWrap_Proposal
rbarnes: got to wait for JOSE anyway, to get private/symmetric format; wrapping not too much more latency; just say "we'll use what JOSE produces"
<hhalpin> The proposal looks sensible to me, format issues aside.
vgb: it would be good to understand the direction that JOSE is going to go
markw: there are also some pure web crypto choices, not dependent on JOSE
virginie: suggest that we have some additional discussion on this topic, hearing agreement that we're going to work with JOSE
<hhalpin> Ryan's concerns were just RSA-KEM it seemed...
markw: would like to make as much progress as we can independent of the JOSE proposal
<hhalpin> +1
markw: account for both cases, then just delete whichever one they don't choose
<markw_> @hhalpin: as rbarnes just pointed out, 'something like RSA-KEM' is needed for approach 2
virginie: would like to report here what the editor already mentioned: In order to shape a high-level API, we need use cases
... what kind of service do we want to create?
<vgb> rbarnes: Nobody implements KEM :) Windows does not, OpenSSL doesn't either AFAIK, etc.
ddahl: recent discussions in mozilla, we're focusing on low-level; high-level on the back burner
virginie: certificate discovery has moved to the top of the priority list among secondary features
... we may end up getting a milestone to do a certificates API; low-priority for now, but want to allow contributions
rbarnes: might be nice for key discovery and cert discovery to be similar to each other
<virginie> http://lists.w3.org/Archives/Public/public-webcrypto/2013Mar/0029.html
virginie: next question: bignum
... not sure how this integrates with our current work, but at least we have a proposal
vgb: this is probably a better question for tony; he has the use cases
... harry captured several of them accurately in the email thread
... there are some newer crypto algorithms that could benefit from a low-level primitive of this type
... could provide some new types of security properties
<hhalpin> re BigNum, we could do a dedicated call to it...
<virginie> Registration is open http://lists.w3.org/Archives/Public/public-webcrypto/2013Mar/0085.html
virginie: registration for f2f is open, see link
... hosted by paypal at their HQ, overlap with webappsec and html
... please register on the questionnaire whether you can attend 23/24 april
... no formal joint meeting planned with webappsec
<wseltzer> [Please register, or indicate if you want to participate remotely: https://www.w3.org/2002/09/wbs/54174/webcrypto-april-2013/ ]
virginie: nobody asked; maybe not enough synergy
... objective to progress seriously on the low-level API
... please give it a good read and make sure it fits your expectations
... we will also look at key discovery, HL API use cases, cert discovery, bignum
... in priority order
... will suggest an agenda in 1-2 weeks
... who will be at the f2f?
<jyates> +1
<virginie> +1 for going to the F2F meeting
<ddahl> +1
<mountie> +1
<wseltzer> +1
<rsleevi> +1
<karen> +1
<vgb> +0.9
<Andrew> +0.5 (24th only)
<markw_> +1
<mountie> 4 members from Korea
<ddahl> mountie: cool
<hhalpin> I think we were not having requirement levels
<wseltzer> [next IETF: July 28 - August 2, 2013, Berlin]
virginie: if we need more intensive synchronization, we might schedule something near the IETF meeting, or send an "official delegation"
<hhalpin> trackbot, end meeting