The system for distributed configuration, as implemented now, works something like this:
We create our own OpenSSL Certificate Authority for signing certificates related to the operation of Domtool 2. Every check mentioned below will only accept certificates signed by this authority.
When a user wants to push out some new configuration, he opens an SSL connection to the dispatcher daemon. The user looks in the shared AFS filesystem for his personal, automatically-generated certificate and private key. The certificate is world readable, while the permissions on the key are such that only that user can read it. (This means that we are depending on the security of AFS/Kerberos/whatever else we use.) The server verifies that the certificate is made out to the user's UNIX username and then performs the usual SSL handshake to make sure the party on the other end of the connection really has read access to the private key.
If everything has gone properly, at this point the dispatcher is convinced that it's talking to a particular UNIX user. The dispatcher consults a special Domtool access control list, telling which filesystem paths, domains, etc., that user is authorized to use. These settings are used to determine the meanings of some custom base types in the Domtool language. The dispatcher type-checks the user's configuration source in that context, aborting if type-checking fails.
The dispatcher now executes the configuration to update the directory tree (on AFS) representing network-wide configuration. The dispatcher opens an SSL connection to each server affected by the changes in turn. The other server verifies that the connecting party's certificate is signed by our CA and that it is made out to the dispatcher's hostname. If it is, the other server can accept the list of configuration files that have changed. We again trust AFS security, as the other server reads the updated files from AFS and makes the appropriate local changes.