Re: Crypto HW. Re: Web Cryptography Working Group scoping progressing...

2011/11/22 Anders Rundgren <anders.rundgren@telia.com>

> On 2011-11-21 15:08, Richard Barnes wrote:
> > Hey Harry,
> >
> > I think that's about the right balance.  It seems like what this API
> should
> > do is provide a set of primitives that can be provided by different
> types of
> > cryptographic services:
> > -- The browser
> > -- The OS
> > -- A TPM
> > -- A smart card
> > -- An HSM
> > -- Etc.
>
> I think this is a somewhat dangerous conclusion.
>
> DomCrypt (AFAICT) supports the *Creation* and *Usage* of cryptographic keys
> in some kind of "browser storage".  Extending the *Creation* part to the
> set of containers listed would extend the scope by a mile.
>

+1

But, I agree there is a need of interface for import/export of certificates
from security devices.
In Firefox, the validation of security device based on FIPS is already
possible. (Other browser?)
I guess Web Certificate Service API is needed to treat this kind of
interfaces in future.

Anyway we have better focus on primitive APIs for light-weight usecases.
Because all browsers have own key stroage. :)

Channy


>
> In addition, DomCrypt isn't suited for *Usage* by traditional kinds of
> tokens,
> particularly not for signature operations.
>
> That you could implement "browser storage" in a TPM is IMO an entirely
> different thing and *IS* of course within scope.  That would though be
> a platform/configuration issue and not require any user interaction.
>
> With "browser storage" I mean storage that is domain-oriented.  Traditional
> tokens are unrestricted, at least from a crypto client point of view.
>
> *If* some implementers still believe that "container selection" is a
> good idea for a light-weight domain-oriented solution, they can of
> course add such a (confusing) step without touching the API.
>
> Anders
>
> >
> > The one thing that seems like it would be required, though, is some way
> for applications to choose between these options, or at least know which of
> them is providing its crypto.  This would seem to call for a way for these
> things to be identified, probably by time (e.g., in something like the
> above taxonomy) and by instance (e.g., some identifier for a smart card).
> >
> > Suggested text for an item in scope: "Identification of the hardware or
> software service that is providing cryptographic services".
> >
> > --Richard
> >
> >
> >
> >
> > On Nov 17, 2011, at 9:48 AM, Harry Halpin wrote:
> >
> >>> IMO it doesn't make sense to include explicit support for Crypto HW
> >>> in a W3C WG.
> >>>
> >>> Rationale: This is already a lost case since the smart card industry
> >>> haven't even begun thinking about this issue although quite a bunch
> >>> of their favorite customers including the financial sector and
> >>> Government actually do request solutions that allow them to get
> >>> away from all the proprietary plugins they currently use.
> >>>
> >>> These guys have developed a "de jure" standard:
> >>>
> http://www.w3.org/2008/security-ws/papers/ISO24727-for-secure-mobile-web-applications-2008-10-30.pdf
> >>> Nobody outside of their backyard cares about it.
> >>>
> >>> BTW, I have yet to see a single proposal that bridges the gap
> >>> between the JS/JSON people and the ISO-7816/GP folks.  They have
> >>> probably never met :-)
> >>>
> >>> Please don't take this as criticism, it is just a friendly advice.
> >>
> >> Currently the charter does not explicitly include smartcard support or
> >> reference to any of the ISO standards around smartcards.
> >>
> >> However, the charter does include "key storage on the device" but puts
> out
> >> of scope "device-specific access to keying material" [1]
> >>
> >> The idea is that through some platform-specific tool, it might be
> possible
> >> to load a key from a smartcard from the JS API, but that the API itself
> >> would not include "special smartcard" specific instructions. Thus, the
> >> burden of doing that would lie on the smartcard programmers, not the
> >> browsers.
> >>
> >> Is that enough? Is there any different terminology you would prefer?
> >>
> >>            cheers,
> >>                harry
> >>
> >> [1] http://www.w3.org/wiki/IdentityCharter
> >>
> >>>
> >>> Anders
> >>>
> >>>
> >>
> >>
> >
> >
>
>
>