Engineering tools should never import a Descriptor that they do not trust. An engineering tool decides if a Descriptor is trusted by checking whether each certificate associated with the digital signature of the Descriptor is trusted. A certificate is only trusted if its chain can be validated. Trust can be established by following the validation steps of Table 3 or by manually establishing trust in case the validation steps fail by deliberately suppressing an error.

Engineering tools should rely on lists of certificates provided by the administrator to determine trust. There are two separate lists: a list of trusted certificates and a list of issuer certificates. The list of trusted certificates may contain a certificate issued to another entity, or it may be a certificate belonging to a CA. The list of issuer certificates contains CA certificates needed for chain validation that are not in the list of trusted certificates.

When building a chain, each certificate in the chain shall be validated back to a CA with a self-signed certificate (i.e., a root CA). If any validation error occurs, then the trust check fails. Some validation errors are non-critical, which means they may be suppressed by a user of an engineering tool with appropriate privileges. Suppressed validation errors should be reported via log messages.

Determining trust requires access to all certificates in the chain. The certificate used to sign the Descriptor, and all intermediate certificates shall be provided with the Descriptor. Validation fails if a certificate in the chain cannot be found. A certificate is trusted if the certificate or at least one of the certificates in the chain is in the list of trusted certificates for the engineering tool and the chain is valid.

Table 3 specifies the steps used to validate a certificate in the order that they shall be followed. These steps are repeated for each certificate in the chain. Each validation step has a unique error log message that shall be reported if the check fails. Validation check failures shall be displayed to the user unless suppressed. It shall be possible for the user to suppress validation check failures individually or permanently.

Details on the validation steps in Table 3 are in IETF RFC 5280, 6.

Table 3 – Certificate validation steps

Step	Description
Certificate Structure	The certificate structure is verified.
Build Certificate Chain	The trust chain for the certificate is created.
Signature	A certificate with an invalid signature shall always be rejected. A certificate signature is invalid if the issuer certificate is unknown. A self-signed certificate is its own issuer.
Security Policy Check	A certificate signature shall comply with the CertificateSignatureAlgorithm, MinAsymmetricKeyLength and MaxAsymmetricKeyLength requirements for the used SecurityPolicy defined in OPC 10000-84.
Trust List Check	If the certificate signing the Descriptor is not trusted, and none of the CA certificates in the chain are trusted, the certificate validation shall fail.
Validity Period	The current time shall be after the start of the validity period. The time at which the signature was created shall be after the start of the validity period and before the end.
Certificate Usage	Each certificate has a set of uses for the certificate. For the certificate signing the Descriptor, the keyUsage shall include digitalSignature. The certificate shall not have a Basic Constraints extension with the CA flag set to TRUE. For CA certificates, the uses shall match use as a CA certificate (see OPC-10000-6). If the validation fails, it shall be reported if the usage is mandatory.
Find Revocation List	Each CA certificate may have a revocation list. This check fails if this list is not available (e.g., a network interruption prevents the engineering tool from accessing the list). No error is reported if the Security Administrator disables revocation checks for a CA certificate.
Revocation Check	The certificate shall not be revoked. Whether a certificate is revoked shall be checked as specified in IETF RFC 5280, 6.3.