3.6.1 Validation Basics

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.)