Re: ISSUE-3: Algorithm discovery

On Tue, Jul 10, 2012 at 7:38 AM, Anthony Nadalin <tonynad@microsoft.com>wrote:

>  Even with this approach you still don’t know if the algorithm is
> supported given the various input parameters****
>
> **
>

I thought this concern had already been addressed, so can you provide an
example of an input parameter that would not be able to be passed via
.supports?

I've identified the operation (encrypt/decrypt/sign/verify) as a known
deficiency, but your reply and the past discussion suggest that there may
be some other parameter/set of parameters not being considered, so it would
be good to have a concrete example for the WG to consider.

As demonstrated in the pseudo-algorithm-registry for the original strawman
and in the current draft, parameters such as IV were to be passed via the
Algorithm/AlgorithmParams dictionary.

 **
>
> *From:* Ryan Sleevi [mailto:sleevi@google.com]
> *Sent:* Monday, July 09, 2012 6:27 PM
> *To:* public-webcrypto@w3.org
> *Cc:* David Dahl; Mike Jones
> *Subject:* ISSUE-3: Algorithm discovery****
>
> ** **
>
> In the original straw-man and current draft, I proposed an API****
>
> ** **
>
> bool supports(Algorithm algorithm, optional Key key);****
>
> ** **
>
> This was to allow determining whether or not a given algorithm was
> supported, without having to actually create a CryptoStream object. The
> intent was to provide a way to discover whether the necessary complete set
> of ciphers was available for an application, before beginning potentially
> expensive operations (key generation, data download, key discovery that may
> result in user interaction, etc).****
>
> ** **
>
> However, as some have pointed out, there are implicit facilities for
> algorithm discovery, by virtue of the fact that
> .encrypt/.decrypt/.sign/.verify need to have some well-defined behaviour
> for handling invalid or unsupported Algorithms. It has also been raised
> that whether or not a given algorithm is supported is dependent upon the
> key being used, although I believe I addressed that point via the optional
> "Key" parameter, since it allows a user optionally to determine if a
> particular key supports the algorithm, rather than just whether or not an
> implementation exists.****
>
> ** **
>
> However, I'm now thinking that the currently defined synchronous interface
> is neither desirable nor sufficient. It seems to me that, for at least some
> key storage types, determining whether or not a particular algorithm is
> supported may involve some form of user interaction or, in the case where
> key storage is backed by hardware, some form of hardware communication. For
> example, if using PKCS#11, this may involve calls to C_GetMechanismInfo,
> which may involve talking to a token/slot.****
>
> ** **
>
> These calls may be slow - especially if other programs are using the token
> or key storage mechanism (including software storage systems that need to
> have locks) - so it would seem like this should be an asynchronous call. It
> would also seem that my straw man proposal fails to distinguish the uses of
> a particular algorithm - for example, a key may only support verification,
> but not signatures. These sorts of scenario arises even if raw keying
> material is exposed and implementations are fully software, I believe,
> since there are still limitations on how a key may be used.****
>
> ** **
>
> Ultimately, this means that the current proposed synchronous API is likely
> insufficient.****
>
> ** **
>
> Based on what was proposed in the strawman-now-draft, this would seem to
> imply that the error/exception for an invalid Algorithm would not be able
> to be raised until the first call to .processData on the CryptoStream.****
>
> ** **
>
> eg:****
>
> try {****
>
>   var stream = window.crypto.encrypt("RS256", key);****
>
> } catch (err) {****
>
>   if (err instanceof InvalidAlgorithmException) {****
>
>     // "RS256" does not parse as a valid Algorithm****
>
>   }****
>
> }****
>
> stream.onerror = function(err) {****
>
>   if (err instanceof UnsupportedAlgorithmException) {****
>
>     // "RS256" is parsed, but either the key or the underlying
> implementation doesn't support it.****
>
>   }****
>
> }****
>
> // Until this is called, it's unknown whether or not "stream" will
> actually work. If it ends up failing, stream.onerror will be called.****
>
> stream.processData(...);****
>
> ** **
>
> ** **
>
> Note that none of the above semantics would necessarily be altered by a
> MUST-IMPLEMENT registry (ISSUE-1), since there would still need to be some
> form of error handling for invalid constants/strings and for unsupported
> key+algorithm+operation tuples.****
>
> ** **
>
> Further, attempting to discover an algorithm by sending 'junk' data
> (constants or random) may result in user agents having to interact with the
> user, since there may be security concerns about even calling
> .processData() on an object (regardless of .complete()), which is some of
> what ISSUE-2 may be related to.****
>
> ** **
>
> As an implementer, the above semantics look both undesirable and limiting
> to potential consumers. How do others in the WG feel? Should there be an
> explicitly asynchronous call to determine whether or not an
> algorithm/algorithm+key pair/algorithm+key+operation tuple is supported,
> without requiring .processBytes()? Are there alternate proposals that would
> simplify or could replace the above API?****
>
> ** **
>
> Cheers,****
>
> Ryan****
>