7 Directories

1. The S.E.E. Project Team has done little work in the area of directories, and has no recommendations to offer. Instead we include here a discussion on the key issues we have considered and need help to resolve.

2. There are several reasons for having directories.

• directories can simplify PKT application usage, e.g. an email client finding the certificate for a recipient,

• directories can simplify application design, e.g. an application needn't store staff/manager relationships,

• directories can be useful for their own sake, e.g. a phone list,

• directories can simplify administration, e.g. lookup of users when changing authorisations / permissions,

• directories can store authorisation information, e.g. Lesley is allowed to access this application.

2 Distributed versus centralised directories

1. PKT-enabled applications could look at more than one directory, but this seems complex and slow. Various options are:

• We could have a directory for each CA, we could have a directory for each agency, or we could have a single directory for all agencies.

• We could run distributed directories side by side with a single global directory.

• We could munge directories together into one big directory, although this is complex, there is a lack of standards, and there are likely to be problems about what data is in each directory.

• We could create a virtual global directory that forwards requests to the distributed directories and returns amalgamated results.

• We could manually maintain both distributed directories and a single global directory.

2. The existence of a certificate in a directory should not be used to determine if the certificate is valid: instead standard validity checks must be performed (CRLs/OCSP, CA trust, date checking and signature checking). This requirement also reduces the need for a single centralised directory.

3 Directory attributes

1. What must the directory contain? Probably at a minimum the directory should contain each individual's name, email address, agency, and digital certificate.

2. What else could it contain? Ideas here are limitless. The directory could drive a telephone directory; or it could contain complex authorisation information. The fact that a directory could store any information about anything, doesn't mean that it should, and of course maintaining the information in the directory will be more complex the more attributes are added.

3. Also see the section on Authorisation in section 8.3.

4 Directory security

1. The S.E.E. Project Team has briefly touched on this area. There are several aspects:

Protection from hackers

Granular authorisation to change parts of the directory, based on organisation, organisation unit, individual or attribute, for example

• can we let individuals change their own phone number, but not their authorisation to access an application?

• can an agency manage the information about their employees but not information specific to another agency's application, e.g. application authorisation information?

• can an agency manage just particular attributes of another agencies' employees, e.g. application authorisation information?

Can access to view some parts of the directory or some attributes in the directory be restricted to particular sets of users, e.g. individuals' security vetting levels should perhaps not be viewable by the public but may be useful to some applications?

Authentication of access to the directory, e.g. by using LDAP over transport layer security (TLS) and client certificates

How much of the directory should be accessible to non-S.E.E. agencies if any?

1. If a directory is used to store information used for authorisation to other systems, the security of the directory must be at least as strong as those other associated systems.

5 Standards

1. While there are many "LDAP" directories, LDAP is just a directory access protocol. There appear to be few appropriate standards around access control within directories, replication among directories, and authentication to directories.