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 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.
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 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:
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.
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 following contains an unordered list of isues that will be dealt with in coming versions:
Date: January 13, 1997 .