Re: Unique identifiers and WebCrypto

Dear Mark,

On 2012-11-12, at 21:23 , Mark Watson <watsonm@netflix.com> wrote:

> [...]
> Everything, so far, on the WebCrypto API, is origin-specific, so there is no need to define a new scheme to identify the 'issuer/user' of a key: origin is good enough and is implicitly known whenever using the API.
> 
> Given that, I don't think there's any need to further specify the format of any identifier, except perhaps some maximum length.

Thanks for the clarification. Under this assumption (known origin), I concur with you.

> I think one could expect that the list of keys available to a single origin is sufficiently small that it's reasonable to just iterate through them looking for the one you want, rather than needing any special search scheme (just yet).
> [...]

Agreed.

But what I am then missing is an explicit scoping operation on the KeyStorage. I guess to be able to modify keys, the app would need to authenticate to the KeyStore anyway? Not all origins are created equal, so they probably will not deserve the same trust levels. This authentication could also serve to implicitly define a visibility scope. Under this scope, an app would only ever be able to see keys it can authenticate for. From the current text it seems as this was implemented by implicitly having a separate KeyStorage per origin?

Peeking at issue 26, it would seem that maybe the association of an app (origin) with a KeyStorage might need to be made explicit? I could imagine, that when a KeyStorage is created for an origin, an authentication key could be stored along with the KeyStorage. Now, all other origins who successfully authenticate to this KeyStorage will have access to the keys it holds. This would solve the issue of sharing keys between origins. Type of key and algorithm should of course be at the discretion of the creating origin, and should be update-able.

The current section 5.1 (Security considerations for implementers) vaguely talks about this, but the interfaces don't yet provide any support for this. To me it seems as issue 25 might best be addressed in one together with issue 26?

On a related note: if a key issuer chooses an authentication method for a KeyStorage that requires the user to enter a passphrase, he implicitly requires asking the user's consent. If he chooses an authentication method that works without passphrase, he does not want the user to be asked for consent. So it seems that such a scheme would also solve Seetharma's concern (asking user consent), and mine (the app should decide when and how to ask for consent).


Hoping to have helped,

  --alex

Received on Monday, 12 November 2012 21:14:37 UTC