Possible solution for extractability (ACTION-115)

Thanks Ryan for setting up that proposal.

I suggest that anyone having a problem with that solutions presents arguments and help to improve it.
We will target to have that wording integrated in our next spec release (which depending on the cycle we choose may be our LC, this will have to be discussed in our next call).

Regards,
Virginie

From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: mardi 17 septembre 2013 20:04
To: public-webcrypto@w3.org
Subject: 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.

________________________________
This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus