W3C home > Mailing lists > Public > public-webcrypto@w3.org > May 2012

Re: [W3C Web Crypto WG] Deciding if we need a discovery mechanism

From: Wendy Seltzer <wseltzer@w3.org>
Date: Mon, 21 May 2012 12:34:30 -0400
Message-ID: <4FBA6E96.3070809@w3.org>
To: Jarred Nicholls <jarred@webkit.org>
CC: GALINDO Virginie <Virginie.GALINDO@gemalto.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On 05/15/2012 12:10 PM, Jarred Nicholls wrote:
> 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, 

I'd like to hear a bit about the fingerprinting possibilities that a
discovery mechanism opens up.  Inspecting the browser's crypto
properties could introduce privacy and security concerns.


(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

Wendy Seltzer -- wseltzer@w3.org +1.617.863.0613
Received on Monday, 21 May 2012 16:34:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:01:01 UTC