Re: [Jsdsi-users] ACL and AuthCert

[Sameer A. <aj...@gm...>]

Dav,

What you're describing is a distributed certificate chain search.  The
JSDSI Prover can do this for you, but it requires that you provide a
CertStore that does all the network communication for it.  Details
below...

> Do you mean Alice created a NameCert tying Bobby's pubkey to the name
> Family and then sent it to me and I add it to my CertStore? I have to
> maintain copies of the name certificates for everyone else's local
> name space?

You don't need to add those certs to your local CertStore.  However,
your local CertStore does need to know where to find those certs
(i.e., the ones issued by Alice).  Here's what will happen: the Prover
will realize that it needs to find all Name certs issued by Alice for
the name "Family".  To do this, it will call
certStore.getCertificates(new NameCertSelector(AlicePrincipal,
"Family")).  The CertStore implementation will need to know how to
find the requested certs given this information (i.e., Alice's public
key).  You can implement this however you want: you cna have all the
certs in a local collection (e.g., using jsdsi.CertStore), or you can
distribute the certs on many different sites (e.g., using
jsdsi.ldap.LDAPCertStore --- ask Luis Pedro for details on LDAP).

> Who creates that AuthCert, Bobby? Or do I have to maintain a
> comprehensive set of all possible authorizations for my resources?

You just need to create an AuthCert for each AclEntry.  The issuer of
these AuthCerts is essentially your access controller: some principal
that represent the process that controls access to your resources.  An
easy way to do this is to create a method like this:

void convertAclEntriesToAuthCerts(Acl acl, CertStore store) {
/**
For each AclEntry in acl:
1) Creates an AuthCert issued by "controller" whose subject is the
subject of the entry
2) Signs the cert using controller's private key.
3) Adds the signed cert to the CertStore.
**/
}


> I had been thinking that I only had to maintain my local namespace
> certificates and the AclEntries for my local resources.

True, but your CertStore needs to know where to find non-local certs,
as described above.

> I had thought that it would work something like this:
> - Bobby would create a request with his signature and send it to me.

Yes.

The Prover does all this for you:
> - I would look to see if I had a specific AclEntry for Bobby.
> - Not finding one, I would contact Alice's process (since some
> principal in her namespace does have an AclEntry) and see if she can
> map Bobby to Family using her local NameCerts and AuthCerts.
> - She would respond with something that signs Bobby's request
> verifying that he belongs to her Family
> - My process would now have a valid chain that links Bobby to the
> AclEntry for the resource and grants access.

Like I described in the last email, you just ask the Prover to try and
find a cert chain that proves that "controller" grants access to
Bobby.  The certs we generated above for the ACL provide the starting
point.  (The Prover notices that "controller" grants access to Alice")
 The Prover then uses the CertStore to find additional certs for the
chain.  (The Prover requests AuthCerts issued by Alice.  The CertStore
returns one that says "Alice grants access to 'Family'".  The Prover
then requests NameCerts issued by Alice for the name "Family."  The
Prover returns three: "Alice's Family includes MomPrincipal", "Alice's
Family includes DadPrincipal", and "Alice's Family includes
BobbyPrincipal".  At this point, the prover has a chain of 3 certs
that shows that the ACL ("controller") grants access to Bobby.)

Sameer

-- 
Sameer Ajmani
http://ajmani.net