Possible solution for extractability

As discussed on yesterday's call, the following spec language is proposed
to resolve the 'extractability' impasse.

It provides the following guarantees:
1) Whatever the application (eg: executing JS) requests, the application
will get, or the operation will fail.
2) Whatever a key provider requests they MAY get - no guarantees are
provided at this time.

There are two clauses added, one to unwrapKey and one to importKey, that
attempt to resolve this:

Under "Unwrap Key"
- Let result be the result of executing the importKey algorithm, ...
- If result describes a Key object that is incompatible with the parameters
associated with unwrappingKey, terminate this algorithm with an error.

Under "importKey"
- If keyData specifies parameters that are inconsistent with the parameters
supplied to importKey, terminate this algorithm with an error.


This language attempts to leave maximum flexibility to handle a variety of
error conditions, such as:
- Attempting to import a JWK that may be tagged for one algorithm (as part
of the JWK), but where the caller specifies another, incompatible
algorithm. For example, importing an RSA key as an AES key.
- Any additional attributes that may be specified in the JWK (for example,
hypothetical extractable or key usage attributes)
- Situations where you may be dealing with secure elements that have
restrictions on their keys (eg: a CK_UNWRAP_TEMPLATE specified)

The 'reliability guarantee' is that IF you specify something via the
exposed API surface, it MUST be respected or the operation will fail. This
provides a consistency of API expectations.

It DOES NOT provide guarantees for service providers about the handling of
extended attributes. This is similar to the lack of guarantees that the API
provides regarding key storage (eg: they may be stored plaintext on the
users disk, or they may be stored in a secure element, etc).

Hopefully this proves to be acceptable to the the WG at large.