UAFX OfflineEngineering - 7.8 Descriptor digital signature

Digital signatures for Descriptors are based on the XML Signature specification and shall follow the structure and requirements defined in ISO/IEC 29500-2:2021, Clause 13.

A Descriptor shall have at least one digital signature.

The signing scope of each Descriptor signature shall include the following:

the Manifest,
all Information Model files,
all attachment files,
.rels files,
all Embedded Descriptors,
and all Common Services files.

The links to the external references, if any, in a Descriptor shall be included in the signature of the Descriptor. Content of external references shall not be included in this signature and should be digitally signed separately from the Descriptor signature.

There are two exceptions for including Common Services files into the scope of a digital signature:

[Content_Types].xml describing the used file name extensions is not included;
The relationship file of the digital signature origin file (e.g., “/package/services/digital-signature/_rels/origin.psdsor.rels” ) listing the contained digital signatures is not included. This allows adding a signature to the Descriptor without invalidating the existing ones.

Each Descriptor signature shall contain an X.509 certificate, which can be used for signature authentication.

The certificate can be associated with the identity of an individual, an engineering tool, a host, or an organization.

The certificate shall either be signed by a certificate authority or be self-signed.

If the certificate is not self-signed, the intermediate certificate chain shall be included in the X.509 Data element. The root certificate should be included (see 7.8.2), and the signing certificate shall be included.

Descriptors shall only use cryptographic mechanisms from OfflineEngineering security Profiles defined in OPC 10000-84.

Descriptor signatures shall be validated as specified in ISO/IEC 29500-2:2021.

According to ISO/IEC 29500-2:2021, each digital signature shall contain, in the SignatureProperty element, a timestamp indicating the time when the digital signature was created.

NOTE The timestamp can be set to arbitrary values (within the validity period of the signing certificate) by the signer. The validity period check-in procedure (see Table 3) assumes that the signer is trusted to not backdate the timestamp.

An engineering tool importing a Descriptor should support X.509 certificate technology for signer authentication. See Clause 8 for details on X.509 certificate technology usage.

Each digital signature is stored in a file with file name extension psdsxs in the folder “/package/services/digital-signature/xml-signature” in the Descriptor.

The folder “/package/services/digital-signature/_rels” contains the relationship file origin.psdsor.rels, which holds the relationship references to the signature files.

The following shows an example of a relationship reference to a digital signature file.

The digital signature file contains XML Signature markup with a subset of elements and attributes of the XML Digital Signature specification, e.g., the elements SignedInfo, SignatureValue, KeyInfo, X509Data and Manifest. The Manifest element lists the files of the signature scope.

An example of a digital signature is given in Annex I.

7.8.2 Certificate validation

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.