[Bug 25618] Extensibility: Offer spec-blessed ways to extend the algorithms and curves, rather than monkey-patching the spec

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

--- Comment #9 from Mark Watson <watsonm@netflix.com> ---
Registries are necessary to manage a namespace where there are multiple ways /
parties who might add new entries to that namespace. They also provide a
convenient reference for someone looking to see all the values defined to date.

However, we have a more fundamental problem here that some of our namespaces
are not extensible at all (e.g. named curves) without 'monkey patching' which
is considered a bad thing (TM).

To be concrete, named curves are where this started. We have two options:
(a) do not allow extension of our existing EC algorithms and require new
algorithms to be defined for new curves
(b) modify the specification to support non-monkey-patch addition of new curves

For (b) we must introduce a concept of the "supported curves list" and define
the information that must be provided for each supported curve (at least, curve
name, algorithms supported, import / export procedures, algorithm procedures
for each algorithm )

We already have this for algorithm normalization, defined in terms of nested
abstract associative containers (a little abstruse if you ask me, but that's
stylistic).

This algorithm extension mechanism is very powerful. It is limited only by the
text in Section 15.3 which defines the method procedures. I see two problems
with that text, namely "recognized key format values" and "recognized key usage
values". For both of these we should explain in the definition that they may be
extended and the information necessary to comprise a definition. In several of
the procedures there is a switch across key format values which needs an
"otherwise, if the key format is defined in another specification, follow the
procedures of that specification" in structured-clone style.

The above may be sufficient. New algorithms may be defined which are more
extensible than the existing ones. However, enabling new key formats to be
defined for the existing algorithms is straightforward once the notion has been
introduced  as above: each switch on key format in algorithm-specific
procedures needs the same "otherwise ..." clause.

Ryan also mentions JWK "alg" values. I am not sure there is much to do here. We
expect the site to support WebCrypto algorithm identifiers and all we do with
JWK "alg" is check for consistency. Is the suggestion that JOSE may define new
values in future which happen to be consistent with existing WebCrypto
algorithms ?

Finally, recursive algorithm normalization has a slight problem in that we do
not have generality in terms of the operation against which a sub-field which
is an AlgorithmIdentifier should be normalized. This is easily fixed and I will
file a separate bug for this.

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

Received on Wednesday, 30 July 2014 01:16:08 UTC