[Bug 25618] New: 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

            Bug ID: 25618
           Summary: Extensibility: Offer spec-blessed ways to extend the
                    algorithms and curves, rather than monkey-patching the
                    spec
           Product: Web Cryptography
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Web Cryptography API Document
          Assignee: sleevi@google.com
          Reporter: sleevi@google.com
                CC: public-webcrypto@w3.org

To avoid monkey-patches to the Web Crypto spec, it should have defined
extension points for how additional algorithms can be implemented.

This is akin to the Structured Clone (
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#safe-passing-of-structured-data
), which includes language to the effect of 

"If input is an object that another specification defines how to clone
Let output be a clone of the object as defined by the other specification."

eg: Consider the comments from the W3C TAG review (
https://github.com/w3ctag/spec-reviews/issues/3#issuecomment-41521737 ) , which
notes the issue with monkey patches (
http://annevankesteren.nl/2014/02/monkey-patch )

Possible places where defined extension points are needed:
- JWK "alg" handling
- Named Curves
  - The string name (for JWK)
  - Debate on enum vs string (is it monkey patching the enum)
  - The ASN.1 encoding/decoding rules
- Hash algorithms used in signatures
  - How to invoke the underlying hash algorithm
  - The string names (for JWK)
  - The ASN.1 encoding/decoding rules
- Import/Export Key
  - ASN.1 handling of the algorithm OID
  - JWK "alg" handling

This is "conceptually" encapsulated in the spec already with the notion of
"registered algorithms". However, there have been issues raised about the
confusion of the language. As much as possible, the spec should be clear on
exactly how algorithms are resolved and extensions implemented.

A successful resolution of this bug will be ensuring that one can, in a way
that does not alter the Web Crypto spec, define an entirely new spec that adds
additional algorithm(s).

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

Received on Friday, 9 May 2014 00:13:34 UTC