crypto-ISSUE-33 (Clarify key tainting): Clarify text in section 5.1 with respect to how key tainting is handled with multi-origin scenario [Web Cryptography API]

crypto-ISSUE-33 (Clarify key tainting): Clarify text in section 5.1 with respect to how key tainting is handled with multi-origin scenario [Web Cryptography API]

http://www.w3.org/2012/webcrypto/track/issues/33

Raised by: Asad Ali
On product: Web Cryptography API



> Section 5.1, security considerations:
>
> This section has the following text in the third paragraph,
>
> “Such mitigations may include restricting a generic key ("tainting") 
> once it has been used with a specific algorithm or operation, and only 
> permit applications to use that key with that same algorithm or 
> operation in the future.”
>
> This mitigation suggestion is misleading. The reader may understand 
> that the tainting could be made by the user agent. If it were the 
> case, it would introduce fragmentation in application behavior. The 
> tainting should be under the control of the application itself and 
> should not fall in the scope of user agent initiative.

comments from Ryan:

It's not misleading. That was the intent. The user agent SHOULD handle tainting.

This is especially critical if multi-origin access is to be permitted, since there is no way for multiple origins to agree upon the acceptable usage of a shared key - and worse, if they could, it may offer a side-channel for communication that undermines the browser privacy/security model.

If this justification isn't enough, we should open an ISSUE on it, but I think this one is important, and perhaps normatively so. If it's controversial, we can remove it, but I think any hope of multi-origin access MUST have this.

Further, the only reliable place to store this tainting information is within the key attributes, assuming we implement them. Because keys may live longer than other storage mechanisms (eg: IndexedDB, Web Storage), the only way to reliably store tainting information is with the key. Thus, is it reasonable to expect every other application to do this same thing?

Note that the concept of tainting is not unique to this proposal, and other proposals (notably, anything related to CORS) already requires user agents implement such mechanisms, although doing so regarding origins.

It does sound like an ISSUE needs to be open about this.

Received on Tuesday, 28 August 2012 17:28:57 UTC