This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 26311 - Algorithm names should be enforced to be ASCII and normalized to lowercase
Summary: Algorithm names should be enforced to be ASCII and normalized to lowercase
Status: RESOLVED FIXED
Alias: None
Product: Web Cryptography
Classification: Unclassified
Component: Web Cryptography API Document (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Mark Watson
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 26536
  Show dependency tree / graph
 
Reported: 2014-07-11 16:15 UTC by Boris Zbarsky
Modified: 2014-09-26 18:21 UTC (History)
3 users (show)

See Also:

Attachments

Description Boris Zbarsky 2014-07-11 16:15:55 UTC 
See https://twitter.com/sleevi_/status/487625474156146688
Comment 1 Tim Taubert 2014-07-31 13:25:29 UTC 
We should probably rather normalize algorithm names to uppercase - users might be very surprised when their algorithm names are converted to lowercase, contrary to what is written in the spec.

The only problem would be "RSAES-PKCS1-v1_5" which is written with a lowercase "v" in the spec as well. Normalizing it to uppercase be rather surprising as well...
Comment 2 Tim Taubert 2014-07-31 14:02:27 UTC 
Make that RSASSA-PKCS1-v1_5 as RSAES-PKCS1-v1_5 was removed.
Comment 3 Tim Taubert 2014-07-31 14:08:42 UTC 
If the spec would require algorithm names to be normalized as written in the spec, implementers could convert to uppercase and add special rules for mixed-case algorithm names. That seems like the least surprising way to handle this.
Comment 4 Ryan Sleevi 2014-07-31 18:22:52 UTC 
(In reply to Tim Taubert from comment #3)
> If the spec would require algorithm names to be normalized as written in the
> spec, implementers could convert to uppercase and add special rules for
> mixed-case algorithm names. That seems like the least surprising way to
> handle this.

I don't think we need to special case anything. The point of normalization was to ensure that every algorithm had a single 'canonical' form following normalization.

We can make this normalized form 'spec-written'. The only meaningful thing was to make sure that the comparisons were (as an implementer) made in a case-insensitive manner (which this bug was about it having been dropped, accidentally)
Comment 5 Tim Taubert 2014-08-07 09:51:38 UTC 
(In reply to Ryan Sleevi from comment #4)
> We can make this normalized form 'spec-written'. The only meaningful thing
> was to make sure that the comparisons were (as an implementer) made in a
> case-insensitive manner (which this bug was about it having been dropped,
> accidentally)

Yes, that sounds great. I was a little too focused on implementation here, sorry.
Comment 6 Mark Watson 2014-09-22 17:58:16 UTC 
The specification currently says nothing about performing any case conversions on algorithm names (that I could find). String comparisons are case-sensitive.

Do we want to re-instate case-insensitive comparison (and normalization to 'standard' names as written in the specification) or shall we live with what we have in the specification now ?
Comment 7 Boris Zbarsky 2014-09-22 17:59:30 UTC 
Please see comment 0.  Apparently the current specification text is an editorial mistake, and doesn't match implementations or specification intent.
Comment 8 Mark Watson 2014-09-26 15:16:12 UTC 
Ok, so the change required here is in the algorithm normalization, which should perform case-insensitive matching on algorithm name and then normalize the name to the value registered by the algorithm.
Comment 9 Boris Zbarsky 2014-09-26 15:16:51 UTC 
Please make sure it's ascii-case-insensitive matching?
Comment 10 Mark Watson 2014-09-26 15:32:04 UTC 
Do you have a specific reference in mind for the definition of case-insensitive match ?