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

Claes

Thanks for clarifying the message.

It looks like application id is  acting like role or group - this  
almost seems on the path toward attribute certificates and the related  
infrastructure.

I'm still not sure I understand how this would integrate in practice  
on a web without centralized authority - perhaps ignored unless  
understood?

regards, Frederick

Frederick Hirsch
Nokia



On Dec 21, 2009, at 5:30 AM, ext Nilsson, Claes1 wrote:

> 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>
>
> <Fine granularity access policy.pptx>

Received on Thursday, 31 December 2009 16:48:29 UTC