Root Certificate Management, Storage, and Client registration

• Root Certificate Management and Storage

• Client registration

• Location of the certificate store and certificate applications store

To do a certificate validation a client (also known as an 'application') must have at least one certificate that it trusts directly - a root certificate. It's pretty clear that different clients are going to trust different certificates, for example, TLS might trust VeriSign's secure server root, but Software Install would not.

There is a single 'file' certificate store (certstore), CACerts.dat, initially populated with default root certificates, located in c:\system\data\ (or a private directory). When a certstore object is constructed it looks for the store in this location. If it cannot be found the original store is copied over from ROM.

A certificate is marked with zero or more UIDs, each of which identifies an application that trusts this certificate. These can be edited and the resulting entry put back in the store, this changes the trust settings for that certificate.

The certificate applications (certapps) store, certclients.dat, which is used by the file certstore, contains a set of zero or more clients. Each client consists of a UID and a human-readable name, and represents an application that requires the services of Certificate Management (certman). For example, TLS is a client, as is Software Installation. The word 'application' is used in its broadest possible sense; the UIDs do not have to be Symbian OS application UIDs, although this may be a sensible choice. Each certificate is marked as trusted by zero or more of these clients, this is what makes it a root certificate for that application.

The CCertificateAppInfoManager class (see below) provides functions to add, remove and list these UID/name pairs. A certman application can retrieve the UID/name pairs for all clients of Certificate Management. The TCertificateAppInfo class (see below) encapsulates the UID/name pairs.

Clients that use certificates register with certificate storage by providing a UID and a name. To reiterate, each certificate is marked with zero or more of these UIDs, indicating that it is trusted by that particular application. This enables a client(s) to mark a certificate as being trusted for use by a particular program.

In practice, known applications that use certification, such as a web browser or the software installer, will already be registered. Currently, the following applications/UIDs are defined:

Client/Application name UID Description SWInstall 268452523, 0X100042AB Certificate is suitable for software installation (SIS files) SWInstallOCSP 268478646, 0X1000A8B6 Certificate is suitable for OCSP checking (SIS files) MidletInstall 270506792, 0X101F9B28 Certificate is suitable for Java MIDlet installation, which includes OCSP checking TLS/SSL 268441661, 0X1000183D Certificate is suitable for SSL/TLS server authentication.

These UIDs are stored in certclients.dat; see the Location of the certstore and certapps store section below.

An application using the certificate validation interface needs to supply the appropriate UID to the certificate validation object, which uses this to select the subset of certificates that are trusted by that application: these form the set of 'candidate' root certificates.

For a client to work with certificate validation, it needs:

• an entry for the application added to the list of clients

• any needed certificates added to the store

• any of the above certificates marked as trusted by the client.

The CCertificateAppInfoManager class provides the following functions for client registration:

• Add a new client

  IMPORT_C void AddL(const TCertificateAppInfo& aClient);

  Leaves with KErrPermissionDenied if the caller does not have the required capability

• Remove an existing client

  IMPORT_C void RemoveL(const TUid& aUid);

  Leaves with KErrNotFound if the client does not exist, and KErrPermissionDenied if the caller does not have the required capability

• List the registered clients

  IMPORT_C const RArray<TCertificateAppInfo>& Applications() const;

  The returned array becomes the property of the caller who is responsible for its destruction.

When a certificate is added to the certstore it is added along with a set of trusters: this set can be edited subsequently. Then, when clients retrieve sets of certificates they can parameterise the request with a set of trusters, and only certificates trusted by those trusters will be retrieved. See:

• Adding certificates

• Certificate applications and trust

• Retrieving certificates

This simple class consists of a UID and a name. The UID does not have to be the application UID, but must be unique; it is anticipated that this can be ensured through the standard UID allocation scheme. Certificate storage does not check UIDs for uniqueness.

IMPORT_C TCertManClientInfo(const TUid& aUid, const TName& aName);
IMPORT_C TCertificateAppInfo(const TUid& aUid, const TName& aName);

IMPORT_C const TUid& Id() const;
IMPORT_C const TUid& Id() const;

IMPORT_C const TName& Name() const;
IMPORT_C const TName& Name() const;

• Certificates are stored, along with suitable trust settings, in a file called CACerts.dat

• Clients (i.e., certificate applications, or UID/name pairs) are stored in a separate file called certclients.dat

These files are located in ROM on a phone. They are necessary for applications such as Software Install and SSL/TLS.

On a cold boot the store is copied over to system\data (or, on Symbian OS v9.0, to a private directory) on the device's internal RAM drive. Subsequently, certificate storage will look for the store on that hardcoded path. If the store can't be found there, the original will be copied from ROM.