Re: DAP Mail List Etiquette? [Was: "Something else"]

No rules, personally I prefer people to have some freedom combined  
with responsibility....

This one was hard to follow, first time I've seen a response without  
any indication of original vs response.

I'd rather just ask Claes to resend rather than impose more rules on  

regards, Frederick

Frederick Hirsch

On Dec 19, 2009, at 9:45 AM, Barstow Art (Nokia-CIC/Boston) wrote:

> Does the DAP WG have any process/guidelines/rules/etc. re mail list
> etiquette? If yes, please send me the pointer(s).
> In particular, I'm looking for the recommended mechanism for
> responses, since, with my mailer, some responses are difficult to
> know who said what (see example below); and recommendations on top-
> posting.
> -Art Barstow
>> -----Original Message-----
>> From: Frederick Hirsch []
>> Sent: onsdag den 16 december 2009 15:16
>> To: Nilsson, Claes1
>> Cc: Frederick Hirsch; ''
>> 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?
>> 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 (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 in order to verify 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

Received on Sunday, 20 December 2009 19:41:04 UTC