RE: Security standards for Mobile Device vs "PCs"

"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

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

Received on Monday, 30 July 2012 18:56:39 UTC