Symbian
Symbian OS Library

SYMBIAN OS V9.3

[Index] [Spacer] [Previous] [Next]



Certificate Validation in PKIX


Certificate Chain

Certificate validation is a recursive process. It begins with the need to verify the signature on some data presented by an End Entity (EE). This involves checking that the key pair is actually owned by that EE. To do this the public signing key of that EE is acquired by getting its certificate. That certificate would have been signed by the EE's certification authority (CA), so the signature on the certificate can be verified by getting the CA's public signing key. In turn the CA's certificate maybe need verifying in which case the process is repeated until the process bottoms out when an entity which is already trusted is reached; that entity is usually self signed. This process is illustrated in the figure below:

Certificate chain

Certificate chain

The set of certificates from an EE up to a trusted root CA certificate is called a certificate chain. Once a certificate chain has been constructed the EE's key pair at the start can validated.

[Top]


Input to Certificate Validation

The following inputs need to be supplied to the validation process:


End Entity & Intermediate Certificates

A set of certificates, from the entity requesting authentication up to, but not including, one already trusted by the relying party.

Where these certificates come from is potentially a difficult problem if certificate management is expected to search for intermediate certificates in remote repositories; however for TLS at least servers are required to supply a complete, ordered set of certificates in the form of DER encoded ASN.1; so client code can just pass this into the certificate chain object.


Trusted Root Certificates

Authentication cannot be done entirely by software: there must be a point at which the user confirms that they trust a particular entity. The validation algorithm can only ascertain that if the user trusts certificate X then they may also trust certificate Y. Certificates which the user trusts directly are called root certificates because they are the root of the validation chain. They are usually self-signed.

It is likely that different applications will have different requirements about which certificates may be considered trust roots and for the level of protection they require for trust roots. To this end, applications will pass in a unique ID (TUid) which Certificate Management will use to identify the application, and so work out which certificates can be considered trusted for that application.

For additional flexibility, an overload is provided enabling clients to pass a set of root certificates directly into the validation function.

For more detailed discussion of the storage and management of root certificates see Root Certificate Management, Storage, and Client registration.


Validation Time

The time for which validation will be performed.


Acceptable Policies

A set of OIDs, each of which represents a certification policy acceptable to the application. This enables client code to restrict the certificates that may occur in a valid certificate chain. Client code does not have to specify any preferred policies here. An empty set is interpreted as any policy.

[Top]


Chain Validation


Chain Construction

The chain object parses the encoded set of certificates. The first certificate is considered to be the EE certificate, and subsequent certificates must each certify the preceding one. The chain object then searches the set of trusted root certificates for a certificate trusted by the client and whose subject name matches the issuer name in the last certificate in the decoded set. If two or more match, it will attempt to resolve this be comparing the authority key ID in the last certificate with the subject key ID in each candidate root. If this extension is not present, it will attempt to find a single root by signature verification. If no root is found validation will fail immediately with an error.


Initialisation of Chain Validation Algorithm

The certificate chain initialises the following state variables:


Validation Algorithm

Validation of a certificate chain starts at the root and ends at the End Entity. It returns a result object which includes:

The reason the warnings are present is that it is sometimes impossible for Certificate Management to work out if an irregularity is an error or not, because it depends on the context of the certificate (e.g. the use to which its key will be put) which is only known by client code. Warnings give client code a chance to evaluate these irregularities.

For each certificate the actions described below are performed:

Additionally, for each certificate:

When validation is complete the Acceptable Policies variable will be copied into the set of policies in the result object.