The certificate used to create the signature needs to be linked to a trusted certificate authority (CA) certificate through a chain of trust to establish trust in the authenticity of a Descriptor’s digital signature. Since the root CA certificate has not been issued by another CA – it is by definition at the tip of the trust chain – trust in it is not established through technical means but through organizational measures.

The root certificates of a number of commercially operated CAs are included in operating system installations and are trusted by default, although users may decide to mark some of these root certificates untrusted (thereby revoking trust in them). A digital signature that can be linked to such a certificate is the most reliable way to establish trust in a Descriptor’s authenticity.

A company may also decide to operate an in-house root CA and share its root CA certificate with its customers, who then import it into their store of trusted certificates.

An engineering tool needs the capability to create a signing certificate and enrol it with a CA, thereby linking it to the CA’s certificate, to create digital signatures that can be trusted by parties other than the signer. The CA the certificate is enrolled with is typically a sub-CA of either a commercially operated or an in-house root CA.

While using a self-signed certificate in an engineering tool can be useful in special situations, it puts the burden of establishing trust in the certificate on the receiver of the Descriptor. Ideally, this is limited to scenarios where the signer has a secure way to transmit the certificate to the receiver of the Descriptor, e.g., by handing it over in person on a physical medium.

Several options exist for protocols to enrol a certificate with a CA:

  • Simple Certificate Enrollment Protocol (SCEP) is a general-purpose enrollment protocol specified in RFC 8894.
  • Enrollment over Secure Transport (EST) is an enrollment protocol that uses HTTPS as transport and relies on TLS for its security. Due to its reliance on HTTPS, it can be integrated into complex environments requiring the use of proxies. It is specified in RFC 7030.
  • Certificate Management Protocol (CMP) is a complex but flexible enrollment protocol that provides end-to-end security. It is specified in RFC 4210 and RFC 4211.
  • Certificate Management over CMS (CMC) is similar to CMP. It is specified in RFC 5272 and RFC 5273.

As an alternative to managing a private key and certificate itself, an engineering tool may make use of a remote signing service to digitally sign a Descriptor. In this case, a hash value representing the Descriptor’s content is submitted to the service along with some form of authorization. Provided the submitter is authorized, the service replies with a matching digital signature. The private key and certificate are maintained by the signing service instead of the engineering tool.

Communication between the engineering tool and the signing service may be automated by deploying a remote signing protocol. Such a protocol is specified by the Cloud Signature Consortium (https://cloudsignatureconsortium.org). It uses HTTPS as the transport protocol and OAuth 2.0 as the authorization protocol and fulfils the requirements of the EU’s electronic identification and trust services (eIDAS) regulation. While it is primarily intended for public signing services, it can be implemented as an in-house service as well.

Bibliography

Whitepaper AutomationML Edition 2.1 Part1 – Architecture and General Requirements

https://www.automationml.org/about-automationml/specifications/

AML Whitepaper AutomationML in a Nutshell, November 2015

https://www.automationml.org/about-automationml/specifications/

ECMA-376 Edition 5 – Office Open XML file formats

https://www.ecma-international.org/publications-and-standards/standards/ecma-376/

W3C XML Schema Structures, XML Schema Part 1: Structures (Second Edition)

https://www.w3.org/TR/xmlschema-1/

W3C XML Schema Datatypes, XML Schema Part 2: Datatypes (Second Edition)

https://www.w3.org/TR/xmlschema-2/

RFC 3987: Internationalized Resource Identifiers (IRIs)

https://www.rfc-editor.org/info/rfc3987

OPC2AML Conversion Tool

https://github.com/OPCF-Members/Opc2Aml