The Certificate Service Block

The purpose of the certificate block is 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.

The certificate block only handles the user side. Thus RA/CA and DA functionality is outside SEMPER. The certificate manager (CertificateMan) interacts with the server using an underlying module. Thus if a CA server is to be used within SEMPER, then the a module, which can "talk with the server" and understands the certificates issued by the server, must be provided.

The certificate manager (CertificateMan) maintains a list of CAs which the user are willing to accept. Currently, we do not distinguish between the CAs in this list but it is reasonable to expect that the user will only trust certain CAs in certain applications. The manager also maintains a list of modules which are installed at the user's site. A CA is registered to be used with one or more modules. This means that in order to register a CA it is necessary to also list a module which the CA supports (registration of CA is implemented in CAManagement). If a CA supports more modules, it is possible either to register the CA more than once, or to use the CAManagement  Application and add modules to the CA. The module must have been installed prior to this.

The functionality offered by the certificate block is reflected by the public services of the manager. Below these services are discussed in more detail.

The Module

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:

Information about Modules and CAs Maintained by the Manager

The Certificate Manager maintains all information about available modules, trusted CAs and certificates. For the moment, certificates of the user are stored, as well as certificates received from other users. This information is needed to find out which modules, CAs and certificates should be used in a given situation.
 

Registered Modules

Use of a module requires two steps: installation of the classes implementing the module and registration of the module at the Certificate manager. The latter process makes the module known to the manger. Currently, module installation is not supported, but the manager provides methods for registering and unregistering a module with the manager. A module can only be registered if it is installed. To install a module  named mmm  manually, the following classes must be made accessible to the manager (i.e., be somewhere on the CLASSPATH): For the initial trials, SEMPER, has a 'dummy' module  implementing these interfaces in DummyTemplate, DummyRegistration, DummyCertificate and DummyRCModule. This module is matched by a class DummyCAHandler, which handles the server side of the supported services.

During initialisation, the manager initialises all modules for the CAs that use them (according to the trust domain). Thus, if module mmm is supported by three CAs: A, B and C, then mmm will be initialised three times. Handles to the initialised modules are kept in a ModuleInformation object. From this object it is possible to get, given the name of the module and the name of the CA, and handle to the actual, initialised module. This is needed when an operation of a particular module is requested.
 

Trusted CAs

The manager keeps a list of all trusted CAs in a TrustDomain object. A CA is simply classified as trusted if it is registered in the TrustDomain object. Using AcceptPolicy it is possible to state that certificates from a given CA can be used in given situations provided a certain  level of (registration) security is met. The TrustDomain object stores for each trusted CA (identified by the name of the CA) a vector of CAInformation objects, which for each CA keeps the information needed to use a particular module for this CA. Normally, one would expect that a CA only supports one module, but it may be possible that a CA supports several modules under the same name (e.g., GMD will support dummy and SecuDe). The information in each CAInformation object includes: It is possible to add CAs and information about the CA using the CAManagement application.
 

Information about the Received and the Users Own Certificates

Both the users own certificates and the received ones are stored in his archive. The user can view the certificates by using the Certificate Browser Application. It is anticipated that a user will have various certificates to be used in various situations. In the certificate block a situation is described by GeneralPolicyId and PolicyId, objects that implement the Situation  interface.

Currently, the PolicyId may specify the name of an entity and a name of the business application in which the certificate can be used. The name of the peer specifying that the user wants to talk with a particular person. The GeneralPolicyId specifies the name of the business application in which a received certificate can be used. The name of the BA must be defined by the provider of the BA and allows the user to specify the situation by specifying a particular application. Extensions to the Situation interface are conceivable such as saying that a certificate should only be used in certain legal settings (e.g., if certain contracts have been signed).

An CertBag object is used to describe the pseudonyms of  the user, as well as the pseudonyms of those who the user communicates with. More precisely the manager has two objects of this kind, one for his own certificates and one for the received ones. CertBag is basically a list of handles (represented by CertificateId objects) to all certificates. A list of Situation objects is associated with each certificates, specifying that the certificate can only be used in the situations described by these objects. A special Situation object can be used to specify that there is no restrictions on the use of a certificate. By default, i.e., when a certificate is issued, it has no restrictions. The user can inspect and modify the policy list for each certificate using the Certificate Browser.

CertBag is implemented using TwoKeyTable which makes it easy to get the chosen policies for a given Certificate and to get for a given Situation the list of Certificates to be used for situations described by this one.
 

Policy for Accepting Certificates

The manager uses an AcceptPolicy object to maintain information about  the user's policy for accepting certificates from other parties. This object specifies for a given situation (defined by a GeneralPolicyId object) a list of CertificateRequirement objects. A CertificateRequirement object describes for a given CA (described by a CAInformation object) requirements on the The requirements on the name is described in a NameRequirement object. Possible levels will depend on the module and the registration procedures supported by the CA.
 

Certificate Selection

Certificate Context

Chosen certificates are maintained in CertificateContext objects. Such an object contains a signature and an encryption certificate for a particular user. Thus in an interactive session two such objects are required - one containing certificates of the user and the other containing the certificates of the peer. A certificate context can be established by negotiating the certificates with the peer, as well as by retrieving certificates non-interactively, supposing that the user has already stored received certificates.
 

Negotiation of Certificates

CertificateMan has methods for negotiating the certificates to be used in a given situation. One part starts the negotiation using the requestChoice method, the peer (playing the server role) must answer this using chooseCertificates. Both of these functions take as argument CertificateContext objects, myContext and yourContext and a SituationDescription object situation, that describes the situation for which the certificates are required.
Initially each entity creates these two contexts as empty contexts just describing which certificates are required (signature and/or encryption). The situation describes the preferred pseudonym of the user, the preferred pseudonym of the peer, the name of the business application in which the certificates are to be used, as well as a SecaRequirement  object which describes the requirements on SECA certificates  . "Unspecified" indicates no restrictions for the two pseudonyms and the business application name. At the first step a Vector of appropriate GeneralPolicyId objects is created containing the Certificate Authorities trusted for the negotiation under the specified situation. The CA that have been issued the certificates should be in accordance with the policy. Afterwards the certificates are selected according to the SecaRequirement provided and the specified fields for the user and peer pseudonym and the business application name (i.e., not "Unspecified"). If there are specified fields the negotiation will only provide certificates if the restriction(s) can be met! Given these initial contexts and the situation the negotiation works as follows:
 
 
Requester
Responder
Create a Vector of policies for trusted CAs for the certificates from peer given PolicyId created according to the SituationDescription (BA) 
Send this Vector and the SituationDescription object to the peer		  
Ensure that the received SituationDescription does not contradict my own SituationDescription object. 
Find a Vector of policies (policy) for trusted CAs for the certificates that does not contradict with the one received from the peer given the PolicyId created according to the SituationDescription (BA). 
First select certificates based on the PolicyId (peer name, BA) and such that the selected pseudonym matches both the received PolicyId from peer and that for me (my name, BA)  (throw exception if not possible). The CA that have been issued the certificates should be in accordance with the policy. 
From these certificates select my own certificates that satisfy the SECArequirement as specified from the SituationDescription object. 
Send the selected certificates to Requester together with my Vector of policies for trusted CAs and the SituationDescription object, which describes the requirements on his name (peer name, BA) and the SECA.
Ensure that the received SituationDescription does not contradict my own SituationDescription object. 
Find the name of the peer (from the received certificates). 
First select certificates based on this name and such that the selected pseudonym  matches both the received PolicyId from peer and that for me (myName, BA) (throw exception if not possible). The CA that have been issued the certificates should be in accordance with the policy received from the responder. 
From these certificates select my own certificates that satisfy the SECArequirement as specified from the SituationDescription object. 
Send the selected certificates to responder.		  
 
 

Each pair of certificates is contained in a CertificateContext object. These objects can then be used to open a StatementTransaction and/or they can be stored in case they will be needed in the future.
 

Non-Interactive Negotiation of Certificates

CertificateMan has methods for retrieving non-interactively the certificates to be used in a given situation, supposing that there are  received certificates stored in the archive of the user. Two methods are provided by CertificateMan for the non-interactive negotiation:  chooseMyCertificates and choosePeerCertificates. Both of these functions take as argument a  CertificateContext object, myContext for the first and yourContext for the second, and a SituationDescription object situation, that describes the situation for which the certificates are required. At first these two contexts are created as empty contexts just describing which certificates are required (signature and/or encryption).

The method chooseMyCertificates is used for the selection of the user's own certificates for the given situation.  The situation describes the preferred pseudonym of the user, the preferred pseudonym of the peer, the name of the business application in which the certificates are to be used, as well as a SecaRequirement  object which describes the requirements on SECA certificates  . "Unspecified" indicates no restrictions for the two pseudonyms and the business application name. At the first step a Vector of appropriate GeneralPolicyId objects is created to specify which Certificate Authorities are trusted for the particular situation. Afterwards the certificates are selected according to the SecaRequirement provided and the specified fields for the user and peer pseudonym and the business application name (i.e., not "Unspecified"). If there are specified fields the negotiation will only provide certificates if the restriction(s) can be met! The pair of certificates is contained in the CertificateContext object, myContext.

The method choosePeerCertificates is used for the selection of the peer's certificates for the given situation. Now the situation describes the preferred pseudonym of the peer, the name of the business application in which the certificates are to be used and the requirements on SECA certificates. "Unspecified" indicates no restrictions. The selection of certificates will be performed as described above and the appropriate certificates will be provided, if any!!. The pair of certificates is contained in the CertificateContext object, yourContext.

These two CertificateContext objects can then be used to create a StatementTransaction object and create a session either for encrypting/decrypting information or making/verifying signatures or both of them.
 

CAManagement

Through a special application CAManagement it is possible to add and remove a CA from the list of trusted CAs. Currently a CA in the list is simply considered trusted. The application enables the user to assign policies for CAs and specify in which business applications the certificates issued by a CA can be used. The application offers the user the possibility to view, add and remove modules supported by a CA as well as to display the fingerprint of the CA's public key.

 Getting the public key of a CA

It is not necessary to have the public key of the CA when registering the CA. RCModuleInterface defines a service, getTrustedPK, which accesses the server and returns the public key of the server. Depending on the status of the CA at the client side one of the following actions then takes place in the manager:

Registration of a user

RCModuleInterface defines a service templateRequest for getting a registration form from the server. The user may fill out this form using the TINGUIN and the filled out form is returned to the CA (we don't distinguish the roles of RA and CA as this is an online registration) using the services sendFilledTemplate.

Note that these services may be used in connection of a out-of-band protocol defined by the CA (e.g. local registration).

The server my now decide to register the user and issue a certificate. The manager can get this certificate using the RCModuleInterface service getCertificate. The manager will then store the certificate. If the CA has not issued a certificate a return code will explain the reason.

Verification of a Certificate

The manager verifies the validity of a certificate using the Certificate service verifyCertificate. The manager provides the key of the CA as a parameter. If no key is supplied from the manager, it is up to the modules to determine how to handle the situation. The manager may also indicate if the modules should ask the server on-line during verification (determined from the user preferences).

Retrieving Installed Certificates

CertificateMan provides a number of services for retrieving installed certificates. The most convenient one to use is probably retrieveCertificate which allows to retrieve all certificates matching either the name of the CA, the name of the user or the identifier of the key. In this method it is also possible to request that a certificate should be retrieved from the server (via the module).
 
 

Configuration

The Certificate block (i.e., the manager) does not need any configuration parameters in the normal case. However, if you're not using the default CA (which in this version is GMD_SemperCA at blankenbach.darmstadt.gmd.de) another CA can be specified using: If you run a CA locally, remember to set in the configuration (as the local CA use the SEMPER ports).

To Do

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

Last updated: July 30, 1998