RE: Registered algorithm vs supported algorithm

 

 

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