RE: ACTION-38: "Should issue recommendation on the granularity of the security system" + proposal for a "Secure Credential API"

Hi,



Sorry if my previous post was difficult to follow due to missing indentations. Hope this is clearer :-)



Frederick,



See my answers inline below and an updated version of "Fine granularity access policy".



Claes



> -----Original Message-----

> From: Frederick Hirsch [mailto:frederick.hirsch@nokia.com]

> Sent: onsdag den 16 december 2009 15:16

> To: Nilsson, Claes1

> Cc: Frederick Hirsch; 'public-device-apis@w3.org'

> Subject: Re: ACTION-38: "Should issue recommendation on the granularity

> of the security system" + proposal for a "Secure Credential API"

>

> Claes

>

> Thanks for the proposals.

>

> Secure Cred Manager should be deferred to future work.

>

> I have a few questions regarding the "File Granularity Access Policy",

> to help me understand it:

>

> Is it correct to say that the essence of the  "file granularity access

> policy" proposal is to determine an application id from either the X.

> 509 cert or signed widget config, and then pass this application id in

> all API calls?



Claes:

Correct

>

> What value does this add? An example might help me understand the

> benefit.



Claes:

I believe there are several use cases.



- An obvious use case is restriction in a file API of access to certain data to certain applications. This is something that is supported by existing application environments.

- Another example is restriction to "read-only" for certain applications in the file or contacts API

- And of course, a "Secure credential manager" that I am proposing, is a good example where specific data must be accessible to a specific application only.



I have added these use cases to an updated version of my proposal that I attach.



>

> Who manages application ids, is there a registry? What prevents any

> widget from including any application id it wants?



Claes:

That must be a part of the signing process. The application id could for example be included in a widget's (signed) configuration document (assumes some kind of centralized widget signing) or it could be included in the certificate (makes distributed signing possible). I realize that I have been a bit unclear here. An application identity must be relative to the origin of the application, typically the PKI-identity, e.g. the Certificate Authority (CA) of a signed widget's certificate. This means that the CA must coordinate the application identities. So, an AppId actually consists of two parts:

- Origin of the application, typically the PKI-identity

- Actual name/id of application



I have updated my description to clarify this at page 6.



>

> What happens in a web case (not widget), where there is no such Id?

Claes:
This is more tricky but I believe that existing security mechanisms such as TLS/SSL can be used. The name/id of application can be included in the server certificate. The weakness here is that we can only verify the server, not the origin of the application. XMLDsig would be another alternative but it is not much used today. Furthermore, this issue exist for any domain based access security system also for verifying the TrustDomain.



>

> What if X.509 certs are not used in certain cases, where does the

> application id come from?



Claes:

In this case there is no method to securely verify the origin and integrity of the application and the application identity.



>

> Is there an "application id" lifecycle?



Claes:

Have my previous answers clarified this?



>

> regards, Frederick

>

> Frederick Hirsch

> Nokia

>

>

>

> On Dec 15, 2009, at 5:15 AM, ext Nilsson, Claes1 wrote:

>

> > Hi,

> >

> > I attach two proposals:

> >

> > 1.       "File granularity access policy". This is response to my

> > action 38. The proposal is based on "Policy Based Device Access

> > Security" (Steve Lewontin/Nokia

> http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/att-

> 0012/SecurityPolicy_09.pdf)

> >  that Steve presented at the Santa Clara meeting. My proposal adds a

> > finer granularity to restrict access to APIs based on application

> > identity.

> > 2.       "Secure Cred Manager". This proposal is based on 1 above

> > and is an API for retrieving securely stored data, "credentials", in

> > the device. A major use case for this API is Social Networking

> > Services web application application login to the service. I have a

> > humble view on this and understand the security issues with

> > JavaScript. However, by referencing existing security mechanisms

> > such as Digital signing, TLS/SSL and WARP, I believe that such an

> > API is possible. Furthermore, I realize that it is not possible to

> > include this API in the phase 1 delivery from DAP but I want to have

> > it in the list of "Future Work".

> >

> > Best regards

> >   Claes

> > Claes Nilsson M.Sc.E.E

> > Senior Staff Engineer

> > CTO - R&T Europe - UI/App/Web

> >

> > Sony Ericsson Mobile Communications

> >  Phone:  +46 10 80 15178

> > Mobile: +46 705 56 68 78

> > Switchboard: +46 10 80 00000

> > E-Mail: mailto:claes1.nilsson@sonyericsson.com

> > Visiting Address; Nya Vattentornet

> > SE-221 88 LUND,

> > Sweden

> > Disclaimer:

> > The information in this e-mail is confidential and may be legally

> > privileged. It is intended solely for the named recipient(s) and

> > access to this e-mail by anyone else is unauthorized. The views are

> > those of the sender and not necessarily the views of Sony Ericsson

> > and Sony Ericsson accepts no responsibility or liability whatsoever

> > or howsoever arising in connection with this e-mail.Any

> > attachment(s) to this message has been checked for viruses, but

> > please rely on your own virus checker and procedures. If you contact

> > us by e-mail, we will store your name and address to facilitate

> > communications. If you are not the intended recipient, please inform

> > the sender by replying this transmission and delete the e-mail and

> > any copies of it without disclosing it.

> >

> >

> > <Secure Cred Manager.pptx><File granularity access policy.pptx>