[Bug 25198] Turn KeyFormat into an enum

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25198

--- Comment #8 from Mark Watson <watsonm@netflix.com> ---
(In reply to Anne from comment #7)
> (In reply to Mark Watson from comment #6)
> > KeyAlgorithm.name is extensible, though the defined process for registering
> > new algorithms and (unless I am mis-understanding) making it an enum would
> > interact badly with that extensibility point.
> 
> How does the extensibility work? Why can't the specification be revised?

Mostly, our procedures say things like 'perform the encrypt operation for the
algorithm identified by the name attribute ...' and so there is the possibility
there that this algorithm and operation are defined in another specification.

The algorithm normalization rules (Section 20.4) make use of an 'internal
object' [[supportedAlgorithms]] which contains argument normalization
information for all the algorithms supported by the UA. There is a sub-section
on what needs to go into this object when a new algorithm is added and again,
there is nothing which restricts the use of this mechanism to the current
specification.

If I understand correctly, though, if we made KeyAlgorithm.name an enum, then
adding values to this enum in another specification would be a monkey-patch.

> 
> 
> > I believe future specifications could also add new methods to SubtleCrypto,
> > which might come with new algorithms and new KeyUsage values, so I suggest
> > we leave KeyUsage as a DOMString.
> 
> New specification could also simply update the enum, I don't see the problem.

A new version of the WebCrypto specification could, but if other specifications
did that, surely that's the very essence of monkey-patching ?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Friday, 26 September 2014 15:39:05 UTC