The idea of our (Grid Distribute) access control’s design is somewhat simple one. To maintain maximum security, it turns out that we must keep the directory highly consistent, to prevent ACL distribution problems.

Our approach is depending on certificate chains. The vendor will release its ID (we denote here, 「Vendor ID」, which consists a universal unique identifier, a public key, as well as an expiry period applied on it. It will be easy to employ a X.509 Certificate to accomplish the job. A consumer, who wants data from the vendor, must have a signed certificate chain, which contains the intermediate certificate authority’s certificate (signed by vendor), as well as his or her public – signed by the intermediate certificate authority.

Once a node received a request, it will check it against the Vendor ID by traversing the certificate chain. Our implementation will be simple – once a certificate is verified (say, it was signed by its parent) and not revoked by its parent (or a publicly available CRL which is also distributed through GD, ha-ha…), will be treated as fully trusted and hence service access is granted.

It then turns out that how we will implement the Distribute Sets and how good it will be. When a distribution set is sent out, it must be accompanying with an ACL, even when anonymous access is granted. In the anonymous case, the ACL will also be signed, to show that the vendor grants anonymous access. An ACL will contain the up most level of signing certificate tree, say, and its root. When multiple access grants are needed, there may contain more roots.

So someone will jump out and ask the question: What will happen when a malicious node gets data and distribute it out? Let’s analysis it:

1. When a malicious node is connected, it will be granted to access only when it has a correctly signed certificate chain. This is a equal situation as in traditional way we distribute data and when we have a recreant, so this does not increase the security risk.
2. When a malicious node is distributing the data, it will not be accessed if it changes the access control list, because that will need the vendor’s signature.

Therefore, I believe our approach is at least as secure as the traditional one. The only important thing we must keep safe is the vendor private key, and with the private key, we can revoke certificates.

This turns out to be another problem – How to distribute the CRL? The current idea is to internally distribute it under a special Distribution Set. What’s your idea?