- From: Ryan Sleevi <sleevi@google.com>
- Date: Mon, 27 Aug 2012 14:42:40 -0700
- To: GALINDO Virginie <Virginie.GALINDO@gemalto.com>
- Cc: David Dahl <ddahl@mozilla.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Mon, Aug 27, 2012 at 2:32 PM, GALINDO Virginie <Virginie.GALINDO@gemalto.com> wrote: > Dear all, > > > > Trying to clean our issue tracker. > > > > Status on that one is that : > > - We do have a minimum set of algorithms required in our spec. > > - We already discussed pro and cons about the cost of discovering > algorithm versus the try&fail possibility. > > - And no one required/discussed this feature any more after our > F2F. > > > > To my understanding, this issue should be closed. Any other view ? > > > > Regards, > > Virginie > > Gemalto > > Chair of … > > I don't know if we've reached a satisfying conclusion, but at least I think we've reached a possible conclusion. The result of this was that the .supports() method proposed has been rolled into the explicit init() of a CryptoOperation. This means that, in order to discover if a given algorithm MAY be supported, it's necessary to create a CryptoOperation (which may require creating a Key first), then trying to .init() it and seeing if the CryptoOperation error event is raised. Thus, implementing algorithm-agile protocols, such as TLS, is NOT possible without SIGNIFICANT performance penalties. For example, to discover the available cipher suites to be negotiated, an implementation MUST first create keys of varying types (AES, DH, ECDH, etc), then try to .init() the operation.
Received on Monday, 27 August 2012 21:43:07 UTC