Re: [Web Crypto WG] Agenda for next call on 14th of May (15:00 EDT/19:00 UTC)

On Wed, May 9, 2012 at 12:05 PM, Mark Watson <watsonm@netflix.com> wrote:

>
> On May 9, 2012, at 8:45 AM, David Dahl wrote:
>
> > I spent some time on the phone with Wan-Teh and Ryan Sleevi yesterday to
> discuss the editor's draft.Some questions and issues we came up with about
> the preliminary work on the spec are:
> >
> > 1. Feature (algorithm and capability) detection. We should provide a
> method by which the API can be queried for features/algorithms/cipher
> suites/etc that allows a script to bail out early before attempting an
> operation that will fail. e.g.: we need a version attribute as well,
> "window.crypto.pk.version" to start
> >
> > 2. Specifying algorithms for crypto operations other than RSA might
> become more complicated than the preliminary spec proposes
> >
> > There was a discussion about perhaps changing the API to look more like:
> >
> > window.crypto.rsa.generateKeys() encryptAndSign() verifyAndDecrypt()
> >
> > I think we can design this in a more 'general purpose' way (similar to
> the current ED) using an options parameter that specifies the algorithm,
> padding, hash/mac,or cipher suite, etc.
>

I dislike the idea of a static object property that effectively namespaces
a particular algorithm.  The benefit of easy feature detection is rather
out matched by the fact that the API is being hamstrung.

If the property were dynamic and used standard algorithm/padding/etc.
strings like the current ED alludes, then that would be a lot more flexible
and still yield easy feature detection.  E.g.:

var rsa = crypto.pk['rsa2048']; // default to pkcs1 padding
if (rsa) {
    // do something
}

var symm = crypto['aes-256-cbc'];
if (symm) {
    // do something
} else if (symm = crypto['3des-cbc']) {
    // fallback to 3des
}

Ignoring the obvious missing pieces and the algorithms exampled above, and
focusing on the idea of a dynamic property to easily request a permutation
of cipher/padding/etc. might be of interest.  The idea of it at least
leaves the API very agnostic.  It's also a little more 'magical' with no
deterministic enumerations of supported key sizes, paddings, or cipher
algorithms, which is usually the price you pay to keep things agnostic.  Of
course a more purposeful API, as was mentioned, could complement this where
each of cipher/padding/etc. are passed through in an options object or
parameters, along with an API to query for supported algorithms.


>
> We do have an internal draft API, very much along those lines, with quite
> a few details worked out. We haven't posted this, because the direction was
> to build on DOMCrypt. But if the direction is to re-think the API a little,
> then we'd be happy to contribute that.
>
> >
> > 3. Potential need for a parallel set of low-level interfaces. I still
> think we should avoid this as a potential sinkhole. My initial desire to
> provide an "easy-and-safe-to-use" interface is I think the point of this
> API. A parallel, low-level interface is also desired.
> >
> > 4. The interest in secondary features seemed high in the public call. We
> need to prioritize. (I think this all falls on use-cases to sort out)
> >
> > 5. I need to run the current spec through where it is using ECC in place
> of RSA to see how it looks/feels - regardless of whether or not browser
> vendors can implement. This also brings up the issue of not stating
> algorithms as MUST IMPLEMENT
> >
> > 6. We should adopt JOSE specs for all input and output. This gives more
> credence to a very high-level API using cipher suites, which will remove
> most of the ambiguity of a 'generic API'. Of course, using cipher suites is
> not a silver bullet, as Ryan said, SSL has 117+ cipher suites maintained by
> IETF.
>
> I'm not sure about this. It should be possible to easily implement JOSE
> using this API, but I don't think JOSE is appropriate for exchanges over
> the API itself. These should largely be opaque byte strings, whereas JOSE
> defines serialized encoded JSON objects.
>

I agree with Mark instinctively and feel that WebCrypto ought to provide
the means to implement JOSE, but not enforce its use.  However I'd like to
hear the reasons behind this idea and any use cases that would apply.


>
> >
> > 7. For the symmetric API, we need to examine the use cases (notably, the
> Netflix use-case) and figure out what the starting point looks like. Mark
> Watson and Mitch Zollinger of Netflix are interested in another F2F meeting
> to discuss this.
>
> Our use-case, as posted in December, is here
> http://www.w3.org/wiki/NetflixWebCryptoUseCase. We'd be happy to run
> through this on the call.
>
> >
> > We want to avoid creating the "Netflix API"and I think there are use
> cases in common with what they have proposed.
>
> Absolutely, we're keen to ensure that the API is generic and not specific
> to this use-case at all - we may ourselves have other use-cases too!
>
> …Mark
>
> >
> > Wan-Teh, Ryan: is there anything else I forgot to mention?
> >
> >
> > Regards,
> >
> > David
> >
> > ----- Original Message -----
> > From: "GALINDO Virginie" <Virginie.GALINDO@gemalto.com>
> > To: public-webcrypto@w3.org
> > Cc: "Wendy Seltzer" <wseltzer@w3.org>, "Harry Halpin" <hhalpin@w3.org>
> > Sent: Wednesday, May 9, 2012 9:48:23 AM
> > Subject: [Web Crypto WG] Agenda for next call on 14th of May (15:00
>  EDT/19:00 UTC)
> >
> > Dear all,
> >
> > Please remember that our first conference call will be held next Monday
> > - 14th of May
> > - 15:00 EDT (19:00 UTC)
> > - +1.617.761.6200, 27978# (CRYPT)
> > - IRC irc.w3.org:6665 #crypto
> >
> > Starting from now, I suggest that people having comments on the editors
> draft Web Crypto API could express themselves on the mailing list, so that
> we can start discussing, sharing views. As a note, the list is also open to
> any discussion related to group organization (e.g. we are looking for an
> editor for the Usecases and Requirements part, if you want to volunteer,
> just mention it on the list...), new usecases, or general information that
> would help us to build our web crypto vision.
> >
> > For our next call, I am suggesting the following agenda - feel free to
> suggest other items:
> >
> > 1. Introduction
> > 2. "Virtual round table" of delegates
> > 3. Agenda approval
> > 4. Review of editor's draft API (by editors) - available under
> http://www.w3.org/2012/webcrypto/WebCryptoAPI/
> > 5. Review of comments on draft Web Crypto API (if any)
> > 6. Web Cryptography Usecases and Requirements
> > 7. Test Suite for Web Crypto API
> > 8. Feedback from public conf call - available
> http://lists.w3.org/Archives/Public/public-webcrypto/2012May/0002.html
> > 9. F2F meetings (summer, TPAC)
> > 10. Regular conference call scheduling
> > 11. Liaisons with other groups (IETF, ECMA, W3C CG)
> >
> >
> > Virginie
> > gemalto
> >
> >
> >
>
>
>