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:
-
Template
defines the interface for registrations forms which the user must ill out
during registration
-
Registration
defines an interface for registered information about a user. In previous
versions of the certificate block this interface was needed on the client
side, but this is not necessary in the latest version. Thus this interface
is likely to be removed later on.
-
Certificate
implementing a certificate; and
-
RCModuleInterface
implementing services needed for registration and management of a certificate.
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):
-
semper.certificate.mmm.MmmTemplate implementing the Template.
-
semper.certificate.mmm.MmmRegistration implementing the Registration
(this one will not be needed in later versions).
-
semper.certificate.mmm.MmmTemplate implementing the Certificate.
-
semper.certificate.mmm.MmmTemplate implementing the RCModuleInterface.
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:
-
name of the CA
-
name of module (e.g., "dummy")
-
the public key of the CA for this module
-
the address of the CA
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
-
Registration level : This describes the level of certainty
with which the user is registered during the certification process
-
Identification level: This describes the amount of information about
the user in the certificates which certificates issued by CAs corresponding
to the CAInformation object must satisfy in order to be accepted in the
given situation.
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:
-
If no key was previously installed for this CA, the manger shows a fingerprint
ot the key in the TINGUIN and asks the user if the key should be installed.
-
If a key is installed and the installed key is the same as the new key
nothing is done.
-
If a key is installed different from the new one the user is shown fingerprints
of the two keys and is asked which one he wants to use.
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:
#semper.certificate.CADN name of CA (default GMD_SemperCA)
#semper.certificate.CAHost address of CA (default blankenbach.darmstadt.gmd.de)
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:
-
Support installation of modules
-
Add methods for revoking, extending (the validity period) and renewing
(new key) a certificate.
-
Add methods supporting attribute certificates (i.e., certificates stating
certain properties of the owner).
-
Add access control
-
Currently the user can in preferences only say if he always or never want
a certificate to be verified online. this should be refined.
-
Add fault tolerance
-
Add privacy protecting attribute certificates
Last updated: July 30, 1998