The Certificate Manager

The certificate block has the purpose of managing registration and handling certificates. The block consists, like other blocks, of a manager and one or more modules, where a module must support the operations needed for registration as well as management and use of certificates. Although SEMPER supports the functionality required for registration it is not required that SEMPER users register their keys this way. Later versions of the certificate block will allow keys generated and registered outside SEMPER to be used in SEMPER.

Registration of a user is done by a registration authority (RA) while issuing, changing and revocation of certificates is done by a certificate authority. In the present state the SEMPER certificate manager assumes that the roles of RA and CA are played by the same party. However, coming version will support the more general scenario of many RA's for each CA as well as many CAs.

SEMPER distinguishes three types of certificates: Attribute, Key Certificates and Hybrid Certificates. Here a key certificate is a plain certificate on a key (e.g., X.509) and attribute certificate is a certificate stating a certain property for a user (e.g., a proxy to sign on behalf of a company) and a hybrid certificate is a mixture of the two (i.e., a certificate n a key containing additinal information). Initially, the certificate manager onnly handles key certificates, but only few changes are expected to handle the other types as well.

The structure of the Certificate Block

The certificate manager is implemented by CertificateMan. This class provides a unified interface to all services needed for registration and handling of certificates. The actual implementation of this is implemented in the module. The certificate block has defined four (internal) interfaces:

Eventually it will be possible to use the SEMPER certificate manager in two ways. Either by doing registration and certification with the services of the Certificate maanger or by making this externally and simply bring the resulting certificates into the SEMPER application. In teh first case it is necdssary to implement all four interfaces, while the second possibility only require that the last two interfaces are implemented.

For the initial trials, SEMPER, has provided simple implementations of these four interfaces in DummyTemplate, DummyRegistration, DummyCertificate and DummyRCModule.

The Certificate Manager

Before the certificate manager can be used for anything it must be initialised (see init for details). During initialisation the manager will read from the configuration a number of parameters, including the distinguished name of the CA Furhtermore, the manager will dynamically load modules implementing the two interface mentioned above and the RCModule will be initiated.

The Registration Process

The Certificate block supports a two step approach to registration. In practice a module may use all or these, skip some of the steps or add further steps (e.g., if a client must show up in person or send a letter in order to register).

Before the user can get a certificate, (s)he has to retrieve a public key of the CA. This can be done using the following method of the Certificate manager: getTrustedPK.It is not important that the user gets the key using this method, butit must be installed in the Certificate Manager using the method,TINGUIN using showFingerprint.

Now, the two steps are:

  1. The user requests a registration form (called a Template) using sendTemplateRequest, fills out the form and returns it using sendFilledTemplate. Part of the information in the Template is the public key to be registered. The RA may request to get this by different means as well. In order to ensure that the user has the secret key corresponding to the publis key in the Template this filled out template is signed using this secret key.
  2. The RA makes a registration of the user. The user can request to see the registered information using getRegistration.While waiting for the registration the user can issue the commandcheckRegistrationStatus in order to see how things are going. After getting the registration the user should call installRegistration(Registration reg) to save the registration via ArchiveMan. This completes the registration part.

The Certificate issuing process

The client can after registrating at an RA as described above use the returned registration to get a certificate issued for him(her) by the CA (only one certificate will be issued per registration). The user calls issueCertificateReq. In reply to this the CA will look up the registration done by the RA and the particular serial number given in this request. If the certificate can be issued it will be sent back to the client.

The certificate can then be installed in archive by calling storeCertificate.

Other services to clients

Apart from issuing certificates the user of course wants to retrieve certificates and verify them as well. This is handled by getCertificate. This method will return a Vector of certificates, that match the the certificate provided as input. Furthermore, a boolean parameter indicates whether the manager should ask the CA online or just search the local archive. A more user-friendly version of this service is provided by retrieveCertificate

The user is able to call verifyCertificate(Certificate cert), which will verify the certificates signature, whether the certificate is still valid, etc.

The user can issue the commands sendChangeCertificateReq in order to change a certificate (e.g., in caseof extending the validity period, chaning the key or revoking the certificate).

The Server Side

On the CA-server side things are currently much easier forother managers/layers.The server has to call CertificateMan.init()just as the client has to do. The server can then go into anendless loop callinghandleRequest which understands the requests mentioned above. the only function which may not be done automatically (without user identification) are issuing and change of certificae. The CA can set the preferences sopecifying in which case interaction with an operator is necessary.

To Do

The following contains an unordered list of isues that will be dealt with in coming versions: