Re: Comment on the paper by Rotondi, et al.

On 6 Feb 2014 at 2:39, Karp, Alan H wrote:
Hi Alan, 
thanks for the comments.
See inline mine.
Ciao
   Domenico
    Some more comments.  (I bet you thought you were through with me.)
     
    Section 5.4:  We found that using the standard SAML Authorization assertion gave our 
    Zebra Copy work a lot of credibility.  Have you received any resistance because you’re 
    using a non-standard schema?

We actually just defined a couple of new element types that we were not able to find 
in the SAML and XACML specs. Of course we used the "extension mechanism" 
they define. Anyway, we haved used our capabilities only within the ENS 
middleware, so no interoperability problem, nor we received comments or resistance 
by others
     
    Section 6: You discuss the issue of privacy in two senses, delegatees can’t identify the 
    delegator the delegator can’t identify the delegatee.  I believe you can achieve the same 
    properties using petnames and one-off public/private key pairs.  Consider the example in 
    Figure 11.  Start with the root capability, which has an empty Assigner ID in your scheme. 

Actually a Root Capability in our scheme is characterized by having the Assigner ID 
equal to the AssigneeID (and a trust relationship with the service profider, e.g., 
www.SYP.com in the figure you mention). 

It gets delegated to [email protected], but the Assignee ID can be anything that the 
delegator finds meaningful, say Fred.  This designation will be meaningless to Bob when the 
[email protected] creates Access Capability A1.  Furthermore, if Bob uses a zero 
knowledge proof to demonstrate that he should have the capability, Bob can use a one-off 
public key when requesting the delegation.  Nobody will be able to associate this public key 
or the Assignee ID with Bob.  Of course, you can always encrypt the Auth. Capability if 
contains recognizable identifiers.
yes you are right regarding the use of one-off key by Bob. Anyway, we propose to 
encrypt the capability A1 because it contains the authorization chain (i.e., the set of 
capabilities from the Root one to the "Bob anonymous one", which can provide some 
identification info to the www.HPQ.com service.
     
    Section 7: I don’t believe you need a full Public Key Infrastructure, but you do need to be 
    able to handle public/private key pairs.  It all comes down to how the delegator knows that 
    the delegatee should be given the capability.  For example, Bob authenticates to SYP.com 
    using a userid/password and presents a one-off public key.  SYP.com will delegate a 
    capability to that public key, which Bob can use because he knows the corresponding private 
    key.  PK but no PKI.
You're right when stating that we don't need a PKI. Indeed in section 7 we state that 
we are using X509 certificate for convenience but the system doesn't depend from 
X509. Actually the key elements are: be able to prove that a capability token belong 
to you, how the delegator identifies the delegatee.
One possibility, mentioned in the paper, is to use an Identity Based Encryption (so 
that a delegator can create a token simply using for example the email address of the 
delegatee; and the delegatee can prove the ownesship fo his capability because he 
knows the private key associated to his email dientity - or any other identity you 
want to use).
The XEROX Casca applciation uses what you call one-off keys.
     
    Bottom line: Nice work and a nice paper describing it.

Thanks
     
    ________________________
    Alan Karp
    Principal Scientist
    Enterprise Services, Office of the CTO
    Hewlett-Packard Company
    1501 Page Mill Road
    Palo Alto, CA 94304
    (650) 857-3967, fax (650) 857-7029
    http://www.hpl.hp.com/personal/Alan_Karp

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk