3.6.3 Validation Procedure Details

3.6.3 Validation Procedure Details

Every PEM implementation is required to perform the following
validation steps for every public component employed in the
submission of an ENCRYPTED PEM message or the delivery of an
ENCRYPTED, MIC-ONLY, or MIC-CLEAR PEM message. Each public component
may be acquired from an internal source, e.g., from a (secure) cache
at the originator/recipient or it may be obtained from an external
source, e.g., the PEM header of an incoming message or a directory.
The following procedures applies to the validation of certificates
from either type of source.

Validation of a public component involves constructing a
certification path between the component and the public component of
the IPRA. The validity interval for every certificate in this path
must be checked. PEM software must, at a minimum, warn the user if
any certificate in the path fails the validity interval check, though
the form of this warning is a local matter. For example, the warning
might indicate which certificate in the path had expired. Local
security policy may prohibit use of expired certificates.

Each certificate also must be checked against the current CRL from
the certificate's issuer to ensure that revoked certificates are not
employed. If the UA does not have access to the current CRL for any
certificate in the path, the user must be warned. Again, the form of
the warning is a local matter. For example, the warning might
indicate whether the CRL is unavailable or, if available but not
current, the CRL issue date should be displayed. Local policy may
prohibit use of a public component which cannot be checked against a
current CRL, and in such cases the user should receive the same
information provided by the warning indications described above.

If any revoked certificates are encountered in the construction of a
certification path, the user must be warned. The form of the warning
is a local matter, but it is recommended that this warning be more
stringent than those previously alluded to above. For example, this
warning might display the issuer and subject DNs from the revoked
certificate and the date of revocation, and then require the user to
provide a positive response before the submission or delivery process
may proceed. In the case of message submission, the warning might
display the identity of the recipient affected by this validation
failure and the user might be provided with the option to specify
that this recipient be dropped from recipient list processing without
affecting PEM processing for the remaining recipients. Local policy
may prohibit PEM processing if a revoked certificate is encountered
in the course of constructing a certification path.

Note that in order to comply with these validation procedures, a
certificate cache must maintain all of the information contained in a
certificate, not just the DNs and the public component. For example
the serial number and validity interval must be associated with the
cache entry to comply with the checks described above. Also note
that these procedures apply to human interaction in message
submission and delivery and are not directly applicable to forwarding
processes. When non human interaction is involved, a compliant PEM
implementation must provide parameters to enable a process to specify
whether certificate validation will succeed or fail if any of the
conditions arise which would result in warnings to a human user.

Finally, in the course of validating certificates as described above,
one additional check must be performed: the subject DN of every
certificate must be subordinate to the certificate issuer DN, except
if the issuer is the IPRA or a PCA (hence another reason to
distinguish the IPRA and PCA entries in a certificate cache). This
requirement is levied upon all PEM implementations as part of
maintaining the certification hierarchy constraints defined in this
document. Any certificate which does not comply with these
requirements is considered invalid and must be rejected in PEM
submission or delivery processing. The user must be notified of the
nature of this fatal error.