Re: crypto-ISSUE-11 (storage attribute): Is there a need for a storage attribute, indicating storage in a hardware token

On Fri, Aug 3, 2012 at 8:45 AM, Seetharama Rao Durbha
<S.Durbha@cablelabs.com> wrote:
>
> At the f2f, I argued that we do not need this attribute.
>
> In some ways, having this attribute is dangerous (leads to unsafe assumptions by developers). And in case developers are indeed cognizant of what they are doing, they will not need this, as they will be putting in place alternate trust mechanisms any way.
>
> However, for performance reasons, for search I think that we need a notion of 'fetch a key [reference] (probably satisfying other criteria as well) from a (given set of) provider(s)'. This way, any UI actions (to insert a card, for example) can be controlled/triggered by the application.
>
> Thanks,
> Seetharama

I agree with Seetharama that this would be a bad attribute, in that
it's meaningless under the web security model.

Additionally, as I mentioned at our face to face, there is no
interoperable way of defining providers between multiple cryptographic
implementations (whether raw implementation or implementations atop
PKCS#11, CNG, CryptoAPI, CDSA/CSSM, Keychain Services, RSA BSafe, JCA,
and others). As such, I do not believe that the notion of a provider
is something that can or should be shipped. Given that the argument
against a lack of mandatory algorithms is that it may harm interop, I
see such a proposal as being unworkable in practice.

The example, as given, seems very much limited to the smart card use
case, which according to our scope work excludes APIs that require
specific smart card behaviour. I believe that the notion of
"providers" (which is an overloaded term meaning many things) tends to
be directly tied to smart cards and secure elements.

As a counterpoint, an example of how a conforming implementation
could, if it desired, expose smart cards as you describe might involve
having the user/application register/detect smart cards that are
available. If a key discovery operation happens where the UA knows the
key exists on a smart card, it might choose to prompt the user to
insert the previously observed/registered key. I do not believe the
spec requires an implementation to constantly poll smart cards, if it
did decide to implement support for them.

This can be done wholly independent of and transparent of the web
application, which I believe is very important for interop. The more
that the application has to specify, the less usable this API is to be
to developers, and the less likely to be implemented by implementors.


>
>
>
> On 8/3/12 7:49 AM, "Web Cryptography Working Group Issue Tracker" <sysbot+tracker@w3.org> wrote:
>
> crypto-ISSUE-11 (storage attribute): Is there a need for a storage attribute, indicating storage in a hardware token
>
> http://www.w3.org/2012/webcrypto/track/issues/11
>
> Raised by: Virginie GALINDO
> On product:
>
> During our summer F2F meeting, some discussions were held about the need or not to have an attribute associated with a key, indicating the storage used for this key. This attribute, while being mentioned in our discussions several time, was challenged by the fact that the reliability of this attribute could be weak - how can you trust the environment when saying that the key bis stored in a hardware token ?
> This issue is to keep track of the discussion and make decision about endorsing or not such attribute, once the key object description will be made available.
>
>
>
>
>

Received on Friday, 3 August 2012 18:47:11 UTC