- From: Jarred Nicholls <jarred@webkit.org>
- Date: Tue, 15 May 2012 12:10:32 -0400
- To: GALINDO Virginie <Virginie.GALINDO@gemalto.com>
- Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
- Message-ID: <CANufG2PTbLKdgijOwz5sr0yM4a5QetA08p+mWtXVwvqzSEOiYg@mail.gmail.com>
On Tue, May 15, 2012 at 10:59 AM, GALINDO Virginie < Virginie.GALINDO@gemalto.com> wrote: > Dear all, > > Some people mentioned that a webapp may be able to discover the algorithms > supported the environment it is running in, thus identifying algorithms > available thanks to the Web Crypto API. There are several means to do that > (1) either by an actual discovery mechanism sending back the entire list of > algorithms, (2) or by creating ‘cipher suite’. In addition to that, we may > be able to mandate a minimum set of algorithms that should be supported > when implementing the API. > > I would like to get your feedback on that one, (or any alternative > proposal). > > Regards, > Virginie > gemalto > > I'd say a combination of 1 and 2 are satisfying. If there's a way to use 1 and then create/discover a particular permutation of a 'cipher suite', as well as a way to request it via a cipher suite identifying string for example, then I think we get the best of both worlds in terms of robustness and discoverability. Once again, it is my opinion that mandating a minimum set of algorithms is aggressive. While it does have its benefits in the short term like predictability for authors and establishing a deterministic test suite for the WG, there are a number of reasons I am against it: - It could cause bad decisions in the API that take advantage of knowing a particular algorithm is meant to be implemented, or even worse, are decided solely for a particular algorithm. The temptation could get the best of us ;) - It means that vendors will have to come to consensus (assuming they all care about being compliant to the spec) on that set of algorithms, and that can be a slippery slope and a time sink because there might be differences in requirements between some vendors and/or the locales they support. - Authors will undoubtedly write code that is not future proof, always assuming certain support with no feature detection. This will make it harder for vendors to deprecate & remove algorithm support in the future when e.g. the algorithm is no longer considered strong enough in the post-quantum cryptography world. If we can nail down easy discoverability and feature detection, then library authors will code defensively (as they should) without a lot of effort. Thanks, Jarred
Received on Tuesday, 15 May 2012 16:11:27 UTC