W3C home > Mailing lists > Public > public-webcrypto@w3.org > April 2013

Re: crypto-ISSUE-41: Clean up algorithm normalization and support checks [design for Web Crypto API]

From: Ryan Sleevi <sleevi@google.com>
Date: Wed, 3 Apr 2013 11:11:32 -0700
Message-ID: <CACvaWvY+nO+gZ=D0MUyz0TBj=BTEUz9RWsY3M=On=HUE9e8Fcg@mail.gmail.com>
To: Web Cryptography Working Group <public-webcrypto@w3.org>
On Mon, Apr 1, 2013 at 8:03 AM, Web Cryptography Working Group Issue
Tracker <sysbot+tracker@w3.org> wrote:
> crypto-ISSUE-41: Clean up algorithm normalization and support checks [design for Web Crypto API]
>
> http://www.w3.org/2012/webcrypto/track/issues/41
>
> Raised by: Richard Barnes
> On product: design for Web Crypto API
>
> SUMMARY:
>
> We should move checks on algorithm support to the operations (out of the normalization) and clean up language about "registered" algorithms.
>
>
> DETAILS:
>
> The "encrypt" method and others need to verify two things about algorithm identifiers:
> (1) That the algorithm is supported by the UA
> (2) That the algorithm supports the requested operation
>
> Currently, (1) is done twice, once by algorithm normalization rules and once by the operation itself, and (2) is done in in the operation.
>
> In the algorithm normalization rules:
> """
> If name does not contain a recognized algorithm name, throw an InvalidAlgorithmError exception and return from this algorithm.
> """
>
> In encrypt():
> """
> If normalizedAlgorithm does not describe a registered algorithm that supports the encrypt operation, throw a NotSupportedError and terminate the algorithm.
> """
>
> Two problems here:
>
> First, checking support is not properly a part of algorithm normalization.  Whether an algorithm is supported by a UA is a separate question from whether its AlgorithmIdentifier is in a normal form.
>
> Second, the check on registration status in the operation is unnecessary.  The algorithm normalization rules already check that an algorithm is "recognized" by the UA, so the only thing that needs to be checked here is the algorithms support for the operation.  UAs may also support unregistered algorithms, for experimentation or for early deployment while specification update is in process. Part of this support is knowing which operations are supported for those algorithms.
>
>
> PROPOSAL:
>
> Remove the following step from the algorithm normalization rules:
> """
> If name does not contain a recognized algorithm name, throw an InvalidAlgorithmError exception and return from this algorithm.
> """
>
> Make the following change to encrypt, and corresponding changes to decrypt/sign/verify/digest:
> OLD:
> """
> If normalizedAlgorithm does not describe a registered algorithm that supports the encrypt operation, throw a NotSupportedError and terminate the algorithm.
> """
>
> NEW:
> """
> If normalizedAlgorithm does not describe a recognized algorithm, throw an AlgorithmNotSupportedError exception and terminate the algorithm.
>
> If normalizedAlgorithm does not describe an algorithm that supports encryption, throw an OperationNotSupportedError exception and terminate the algorithm.
> """
>
>
>
>

Hi Richard,

I've read this several times, and I'm still not sure I follow what
your issue is.

It seems like you're trying to find a way to say "Look, the UA can
support algorithms that nobody knows about and it doesn't tell anyone
about" - is that correct?

>From reading your new proposal, it seems to be doing exactly what
you're saying you're trying NOT to do - namely, you're forcing double
validation of the algorithm name (once during normalization, once
during operation).

The intent was that the normalization phase addresses any/all invalid
values, so that by definition, a 'normalized' algorithm only contains
recognized algorithms. At that point, post-normalization, any
operation can 'trust' that input and perform whatever secondary checks
it needs (eg: is it supported).

It seems with your proposal that you're wanting to treat the
normalized form as still untrusted.

Is this correct?
Received on Wednesday, 3 April 2013 18:12:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:16 UTC