Re: Unique identifiers and WebCrypto

Alexander,

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.

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).

…Mark

On Nov 9, 2012, at 3:05 PM, Alexander Adolf wrote:

> Dear Seetharama,
> 
> Thanks for checking the cross-post, btw!
> 
> On 2012-11-09, at 18:46 , Seetharama Rao Durbha <S.Durbha@cablelabs.com> wrote:
> 
>> [...]
>> I am not sure I completely understand the solution you have put in place, but I gather that
>> 
>> 1.  you do not want the spec to dwell into those details
> 
> If "those details" means schemes for asking user consent, and schemes for keys of vertical ecosystems, then yes. If "those details" means the Key interface in setcion 10, I think also yes (but see below).
> 
>> 2.  You do not want the spec to mandate user authorization in a particular fashion
> 
> Now I'm confused. You refer to *user* authorisation, while Mark appears to refer to *device* authorisation? Or is your user authorisation meant to mean asking user consent?
> 
>> I think that my point about using device provided policy instead of explicit user authorization was intended for 2 above.
>> But if the above is not the crux of your argument, then please let us know if you would like specific aspects in the spec.
>> [...]
> 
> 
> As for asking user consent, I think we should provide a slot for people to plug in any scheme for user consent that they will need to use for their legal arrangements. It should be the Web app that decides if and what to ask the user, not the device. This of course requires trust to be established between device and app, to enable the app to modify the key store.
> 
> As for storing shared secrets, it seems there are two problem domains: Vertical (i.e. closed) ecosystems will have their own key hierarchies, and will not depend on anyone. Such apps will only be interested in finding counterparts on the device platform (like Smart Cards etc.) to interact with. Horizontal (i.e. open) ecosystems on the other hand, will not want to do anything but publishing their certificates. They would prefer the device platform to do everything for them.
> 
> Accommodating the verticals is fairly easy, and I described how to achieve that in my initial message. Accommodating the horizontals (which seems what you guys are thinking about) is tricky, because we need a set of requirements and use-cases to build the spec against.
> 
> So if we want to stay out of the oh-but-this-presents-a-threat discussions, and endless use-case listings - and I presume we want to stay out of either - the way to refer to keys would seem to need to adhere to just two simple requirements:
> 
> 1) it should be *sufficiently* unique (not globally)
> 
> 2) it should allow the issuer/user of the keys some headroom for renewability
> 
> Both to me seem to be met by using a string that conforms to URN syntax. Each issuer of keys could use their own prefix, avoiding name clashes, and satisfy 1). As under their prefix, each key issuer can do whatever they deem appropriate, 2) would be satisfied as well.
> 
> How would an app look such things up? With a little tweak, I think it could be easy: simulate a DOMDocument which holds all the keys, and let the app use XQuery to search for the URN-style prefix: //*[starts-with(@keyid,"urn:com:mycorp:")]
> 
> That would yield a list of all the keys for that provider, and the app from that provider would know what to do with them. Having said that, I think I would suggest to remove *all* the attributes from the Key interface in section 10, except for the DOMString id.
> 
> Also having said that, we could go for different simulated documents: one for the device's key store, one for Smart Cards, one for USB tokens, etc. Or just two: one for local key store, and the second one for removable tokens.
> 
> For standard operations which are defined in the Web Crypto API, and which all clients must implement, the URN style naming convention could also be used. An XQuery for //*[starts-with(@keyid,"urn:org:w3:webcrypt:enc:AES-CBC")] would e.g. return the device's current key for encryption using AES in CBC mode.
> 
> Thinking about it again, I think I would want the Key interface to have two attributes:
> 
> interface Key {
>  readonly attribute DOMString   keyid;    // vendor id 
>  readonly attribute DOMString[] stduse;   // urn:org:w3:webcrypt:...
> }
> 
> Web apps can then designate the possible uses of each key in the stduse array. Combining the two attributes could make for IMHO quite reasonable semantics:
> 
>    //*[starts-with(@keyid,"urn:com:mycorp:")
>        and starts-with(@stduse,"urn:org:w3:webcrypt:enc:AES-CBC")]
> 
> This would e.g. yield the AES encryption key for CBC mode from a specific source. Of course XPath offers much more.
> 
> Just my two cents anyway.
> 
> 
> Hoping to have helped (still),
> 
>  --alex
>

Received on Monday, 12 November 2012 20:23:47 UTC