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.