Re: Security standards for Mobile Device vs "PCs"

On Mon, Jul 30, 2012 at 11:54 AM, Lu HongQian Karen <karen.lu@gemalto.com>wrote:

> "The Working Group is expected to deliver APIs designed for use with
> JavaScript." http://www.w3.org/2012/05/sysapps-wg-charter.html
>
> Therefore, as imagined by David, a web page should be able to access a
> secure element via the SE API.
>
> Regards,
> Karen
>

Hi Karen,

The exposure of bindings via JavaScript does not necessarily mean the same
thing as a "web page," at least not how I believe it was be used.

As the charter mentions, such work is predicated on defining a new security
model and runtime environment that traditionally associated with web pages.

The point being is that APIs defined through the SysApps WG are not
necessarily APIs that will be available to "any" application, since they
may be operating under the "traditional" web security model.

Does that clarify things?

Cheers,
Ryan


>
> -----Original Message-----
> From: David Dahl [mailto:ddahl@mozilla.com]
> Sent: Monday, July 30, 2012 12:34 PM
> To: Ryan Sleevi
> Cc: public-webcrypto-comments@w3.org; Anders Rundgren
> Subject: Re: Security standards for Mobile Device vs "PCs"
>
> Thanks for the clarification, Ryan.
>
> Cheers,
>
> David
>
> ----- Original Message -----
> From: "Ryan Sleevi" <sleevi@google.com>
> To: "David Dahl" <ddahl@mozilla.com>
> Cc: public-webcrypto-comments@w3.org, "Anders Rundgren" <
> anders.rundgren@telia.com>
> Sent: Monday, July 30, 2012 12:09:51 PM
> Subject: Re: Security standards for Mobile Device vs "PCs"
>
> Note that the SysApps WG is about defining privileged APIs that, by and
> large, are NOT granted to "web" pages.
>
> I don't believe David's example may best reflect the interaction between
> these two. Examples that may be suitable includes:
> - Polyfilling the Web Crypto API using APDUs to interact with the SE to
> enumerate keys and algorithms, without requiring browser/OS specific
> support for the SE. This includes adding new/custom algorithms
> - Secure key provisioning that then causes keys to be available via the
> Web Crypto API.
> - Proof of possession primitives beyond those afforded by the base web
> crypto API.
>
> Again, these APIs are /not/ intended for the "general" web (see their
> charter for more details).
> On Jul 30, 2012 10:00 AM, "David Dahl" <ddahl@mozilla.com> wrote:
>
> > I think an psuedo-example of how this might work with the Web Crypto
> > API
> > is:
> >
> > 1. A page uses the Secure Element API to query for hardware devices 2.
> > The script finds the SE to use, sets it as default for the current
> > page 3. The Web Crypto API is employed for a crypto operation: the
> > current default hardware module is used instead of the
> > browser-supplied software, to create a signature, etc.
> >
> > Again, this is just a stab in the dark at how these two APIs *might*
> > work together.
> >
> > Regards,
> >
> > David
> >
> > ----- Original Message -----
> > From: "Anders Rundgren" <anders.rundgren@telia.com>
> > To: "David Dahl" <ddahl@mozilla.com>
> > Cc: public-webcrypto-comments@w3.org, "Ryan Sleevi"
> > <sleevi@google.com>
> > Sent: Monday, July 30, 2012 11:45:50 AM
> > Subject: Re: Security standards for Mobile Device vs "PCs"
> >
> > On 2012-07-30 18:08, David Dahl wrote:
> > > Anders:
> > >
> > > Have you seen the draft charter for the SysApps WG?
> > http://www.w3.org/2012/05/sysapps-wg-charter.html
> >
> > Thank you David!
> > I hadn't heard about one.  There's too much noise out there :-)
> >
> > I also took a peek at Gemalto's API write-up.
> > Personally, I don't see that 7816 and APDUs have a mission to carry
> > out on the web.
> >
> > In fact, in my take on this topic there is no (web) API at all!
> >
> > This will *very* interesting...
> >
> > Cheers,
> > Anders
> >
> >
> > >
> > > "Secure Elements API
> > > An API enabling the discovery, introspection, and interaction with
> > hardware tokens (Secure Elements) that offer secure services such as
> > tamper-proof storage, cryptographic operations, etc. Example: Gemalto
> > Secure Elements."
> > >
> > > This looks like it might be a nice complement to the web crypto API
> > >
> > > Cheers,
> > >
> > > david
> > >
> > > ----- Original Message -----
> > > From: "Anders Rundgren" <anders.rundgren@telia.com>
> > > To: "Ryan Sleevi" <sleevi@google.com>
> > > Cc: public-webcrypto-comments@w3.org
> > > Sent: Monday, July 30, 2012 1:34:10 AM
> > > Subject: Re: Security standards for Mobile Device vs "PCs"
> > >
> > > On 2012-07-29 09:59, Ryan Sleevi wrote:
> > >> Thank you for your feedback, Anders.
> > >>
> > >> I'm not sure I understand how this relates to the work of the Web
> > >> Cryptography Working Group. As has been mentioned before, smart
> > >> card provisioning is out of scope for the efforts of this working
> group.
> > >> While I realize you and others may have many thoughts to offer on
> > >> the matter, I think it is important for the continued progress of
> > >> the working group that we're able to focus our efforts on in-scope
> work.
> > >> For general comments about the future of (PKI, certificates, keys,
> > >> arbitrary crypto schemes), there may be other forums better suited
> > >> for such thoughts and ruminations.
> > >
> > > Ryan,
> > > You should look at this as a comment from the outside.
> > >
> > > The term "Smart Card" is misnomer.
> > >
> > > *Nobody* is trying to make traditional smart cards usable in PCs.
> > >
> > > *Everybody* is working with provisioning of embedded SEs including
> > Google.
> > >
> > > That's about it.  It might be a future step for Web Crypto or it
> > > might be something entirely different.
> > >
> > > br
> > > ar
> > >
> > >>
> > >> In addition, speculation about Apple's motives does not seem
> > >> appropriate, the least of all being that it's not at all an
> > >> accurate representation. Apple has made it very clearly publicly
> > >> that they're moving away from the CDSA and CSSM framework that
> > >> underpinned the TokenD effort (as well as underpinning their X.509
> > >> and PKI handling), so naturally it means that every TokenD written
> > >> is incompatible with the new APIs (eg: Security Tranforms). This is
> > >> not at all an issue with "smart cards" vs "non-smart-cards", but
> > >> instead simply a matter of cryptographic APIs and the need to
> deprecate the legacy APIs.
> > >>
> > >> While feedback is very much welcome on the ongoing Editor's Drafts,
> > >> please do try to keep comments in scope, and please keep in mind
> > >> that there will be problems and use cases that we cannot and will
> > >> not address within the either the FPWD or within the first
> > >> delivered version of this API.
> > >>
> > >> Regards,
> > >> Ryan
> > >>
> > >> On Sat, Jul 28, 2012 at 10:53 PM, Anders Rundgren
> > >> <anders.rundgren@telia.com> wrote:
> > >>> A thing that I feel will affect the outcome of many security
> > standardization initiatives is how they relate to the two major
> platforms.
> > >>>
> > >>> If we for example take the smart card issue, it has proven beyond
> > doubt to be unsolvable in the PC while being piece of cake in mobile
> > devices.
> > >>> What do I mean with unsolvable?  The ability to enroll credentials
> > >>> in
> > smart card via a browser.  It is actually so difficult just getting a
> > "standard" smart card to work for logging in that Apple removed
> > support for all cards but the US PIV card in their latest MacOS!
> > >>>
> > >>> How come it is piece of cake in a mobile devices?  Because
> > >>> embedded
> > SEs like the NXP chip powering the Google Wallet eliminate readers,
> > third-party middleware and the mapping guesswork.
> > >>> IMO this is the only way to make smart cards "first class
> > >>> citizens" in
> > consumer computers.
> > >>>
> > >>> Web Crypto haven't taken a position on these issues in an attempt
> > >>> to
> > keep neutrality.   Personally, I'm more interested in the 80% than in
> > supporting a very difficult < 5% audience.
> > >>>
> > >>>
> > http://news.cnet.com/8301-1023_3-57481166-93/oauth-2.0-leader-resigns-
> > says-standard-is-bad
> > >>>
> > >>> Anders
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >
> > >
> > >
> >
> >
> >
>
>