The dacskey utility generates encryption keys for DACS that are cryptographically sound. Keys are represented externally as an XML document called a keyfile. The program can also validate a keyfile or display a key.

Keys are created for at least three different purposes, although every keyfile has the same format:

• Keys that are shared by all of the jurisdictions within the same DACS federation, identified by the virtual filestore item type federation_keys. It is through these "master" keys that any jurisdiction is able to decrypt and validate credentials created by any other jurisdiction within the same federation quickly and without any additional communication. These keys are generated initially by a designated federation administrator at the time a federation is created. These keys can be generated at any jurisdiction within the federation.

Ideally, new keys should be generated at regular intervals and also whenever warranted to maintain security, such as when a jurisdiction leaves the federation or if a key may have been compromised. When a jurisdiction joins a federation, it must receive a copy of the current keys. There is currently no automated key management support; administrators must distribute these keys to all jurisdictions over a secure channel whenever they are changed. Besides using some method of encryption to ensure the keys remain private during distribution, take care not to mangle the XML document (e.g., through line breaks or truncation).

• Keys that are used by a jurisdiction for its own purposes, identified by the virtual filestore item type jurisdiction_keys. These keys are kept private to the jurisdiction (they are not shared with any other jurisdiction) and are ordinarily generated at that jurisdiction. These keys should be regenerated periodically as a routine security measure.

• Keys that are used by a DACS application at a particular jurisdiction for its own purposes (m[blue]dacsgrid(1)m[][2], for instance). These keys should be regenerated periodically, but take care to retain the old keys so that they can be used for decryption before information is re-encrypted using the new keys.

The program ordinarily uses OpenSSL's m[blue]ssl(3)m[][3] library to acquire high-quality random material. In certain situations, an experienced administrator might find the -p and -pf options useful; others should avoid them, however.

When keys are generated, the output is written to keyfile, which is either created or truncated. In this context, keyfile must be a pathname. Unless directly written to where federation_keys (or jurisdiction_keys) points, keyfile must be copied there.

Assuming that the default site configuration file (conf/site.conf-std, which establishes default locations for these files) has been installed:

% dacskey -u mysite.example.com -q fkeys
% install -o root -g www -m 0640 fkeys \
      /usr/local/dacs/federations/example.com/federation_keyfile
% dacskey -u mysite.example.com -q jkeys
% install -o root -g www -m 0640 jkeys \
      /usr/local/dacs/federations/example.com/mysite/jurisdiction_keyfile

The owner, group, and mode assigned to these files in this example are typical but are only suggestions.

Security

A keyfile generated by this command must be accessible (readable and writable) only by DACS web services and the DACS administrator. It must be kept unreadable and unwritable by all others.

When not generating keys, by default keyfile is a pathname. If the -vfs flag is given, then keyfile is a DACS URI, item type, or absolute pathname.