3.6.1 Validation Basics

Every UA must contain the public component of the IPRA as the root for its certificate validation database. Public components associated with PCAs must be identified as such, so that the certificate validation process described below can operate correctly. Whenever a certificate for a PCA is entered into a UA cache, e.g., if encountered in a PEM message encapsulated header, the certificate must NOT be entered into the cache automatically. Rather, the user must be notified and must explicitly direct the UA to enter any PCA certificate data into the cache. This precaution is essential because introduction of a PCA certificate into the cache implies user recognition of the policy associated with the PCA.

Validating a certificate begins with verifying that the signature affixed to the certificate is valid, i.e., that the hash value computed on the certificate contents matches the value that results from decrypting the signature field using the public component of the issuer. In order to perform this operation the user must possess the public component of the issuer, either via some integrity-assured channel, or by extracting it from another (validated) certificate. In order to rapidly terminate this recursive validation process, we recommend each PCA sign certificates for all CAs within its domain, even CAs which are certified by other, superior CAs in the certification hierarchy.

The public component needed to validate certificates signed by the IPRA is made available to each user as part of the registration or via the PEM installation process. Thus a user will be able to validate any PCA certificate immediately. CAs are certified by PCAs, so validation of a CA certificate requires processing a validation path of length two. User certificates are issued by CAs (either immediately subordinate to PCAs or subordinate to other CAs), thus validation of a user certificate may require three or more steps. Local caching of validated certificates by a UA can be used to speed up this process significantly.

Consider the situation in which a user receives a privacy enhanced message from an originator with whom the recipient has never previously corresponded, and assume that the message originator includes a full certification path in the PEM message header. First the recipient can use the IPRA's public component to validate a PCA certificate contained in an Issuer-Certificate field. Using the PCA's public component extracted from this certificate, the CA certificate in an Issuer-Certificate field also can be validated. This process cam be repeated until the certificate for the originator, from the Originator-Certificate field, is validated.

Having performed this certificate validation process, the recipient can extract the originator's public component and use it to decrypt the content of the MIC-Info field. By comparing the decrypted contents of this field against the MIC computed locally on the message the user verifies the data origin authenticity and integrity of the message. It is recommended that implementations of privacy enhanced mail cache validated public components (acquired from incoming mail) to speed up this process. If a message arrives from an originator whose public component is held in the recipient's cache (and if the cache is maintained in a fashion that ensures timely incorporation of received CRLs), the recipient can immediately employ that public component without the need for the certificate validation process described here. (For some digital signature algorithms, the processing required for certificate validation is considerably faster than that involved in signing a certificate. Use of such algorithms serves to minimize the computational burden on UAs.)