Re: Registered algorithm vs supported algorithm

Just to circle-back on this (old) issue.

The new language (
https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#algorithm-normalizing-normalize-an-algorithm
) should hopefully have addressed these issues.

NotSupportedError = 1, 2, 3, 4
If an implementation knows (in the UA) but doesn't support an algorithm (in
the library) (5/6), the algorithm normalizes, and the sub-operation returns
NotSupportedError, OperationError, DataError (depending on the details of
'not supported'; eg: data parsing issues, etc)




On Sat, Feb 1, 2014 at 10:39 AM, Jim Schaad <ietf@augustcellars.com> wrote:

>
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi@google.com]
> *Sent:* Friday, January 31, 2014 11:38 PM
> *To:* Jim Schaad
> *Cc:* public-webcrypto@w3.org
> *Subject:* Re: Registered algorithm vs supported algorithm
>
>
>
>
>
>
>
> On Fri, Jan 31, 2014 at 10:18 PM, Jim Schaad <ietf@augustcellars.com>
> wrote:
>
> When doing  generate call, I am not sure where the correct location for
> putting in a failure would go for an algorithm that is registered but is
> not implemented.
>
>
>
> The normalization function does not appear to check that the algorithm is
> supported – only that a recognized alias is given.  I would assume that
> this should fail with InvalidAlgorithmError if a recognized but not
> implemented name is given (as this would be the default with a new alias).
>
>
>
> However if a dictionary I given, there is no check there that name is in
> the implemented table.    The generate function would appear to say that a
> registered, but unimplemented algorithm would be treated as a
> non-registered algorithm as the check for support would fail and thus
> return NotSupportError.
>
>
>
> It would be nice of the same error would be returned in both cases,
> especially if I can normalize all of the algorithms at the time of
> implementation – but wanted to return a not supported error in the case it
> was not implemented.  I am not sure if this is reasonable behavior or not.
>
>
>
> Jim
>
>
>
>
>
> I'm not sure I follow why you'd want the same error for an invalid name -
> eg: AES-PCM - versus a string in the spec but not supportable by a UA. The
> latter is something that MAY be user actionable (for example: an admin may
> have disabled AES-GCM in an operating systems' crypto implementation, but
> the OS itself does support GCM), while the former is only actionable by
> either changing UAs (eg: if AES-PCM was some vendor-specific algorithm) or
> fixing the typo.
>
>
>
>
>
> Ok – There a number possibilities that I can think of:
>
>
>
> 1.       The algorithm name has never been registered
>
> 2.       The algorithm alias has never been registered
>
> 3.       The algorithm name has been registered, but my implementation
> does not know it
>
> 4.       The algorithm alias has been registered, but my implementation
> does not know it
>
> 5.       The algorithm name has been registered, my implementation knows
> it, but does not implement/enable it
>
> 6.       The algorithm alias has been registered, my implementation knows
> it, but the algorithm name is not implemented/enabled.
>
> 7.       The algorithm is registered and my implementation currently
> supports it.
>
> 8.       The algorithm alias is registered and my implementation
> currently supports the algorithm name
>
>
>
> When I said the same error – I was thinking in terms of algorithm name vs
> algorithm alias no in terms of enabled vs disabled.  In the above list
> items 1 to 6 are going to return some error while items 7 and 8 are going
> to return success.
>
>
>
> 2 and 4 return InvalidAlgorithmError (Normalization rule 3.4)
>
> 1 and 3  return NotSupportedError (Encrypt step #2)
>
> 5 and 6  return ???? (Implementation dependent)
>
>
>
> My expectation is that 1,2,3 and 4 return InvalidAlgorithmError and 5,6
> return NotSupportedError (or something similar)
>
>
>
> Jim
>
>
>
>
>