The Device lifecycle shown in Figure 1 implies information needs to flow between businesses when there is a transfer of physical control over a Device (see 4.2.3). How this information is transmitted is out of scope but it could be email, a block chain ledger, cloud based webservice, a file on a USB stick or some other mechanism. This specification defines the format of a document that contains information that needs to be provided with a Device. A Ticket is the term used for a document that describes one or more Devices and has a Digital Signature that can be used to verify that the contents of the document have not been altered and that they confirm the origin of the Device.

Tickets are long lived documents which means the signing Certificate should be issued by a widely trusted root Certificate Authority that is likely to be in business even if the Manufacturer or CompositeBuilder has gone out of business. Tickets allow additional Signatures to be added at any time by an entity in the chain of physical control. The current owner of a Device validates the Ticket by choosing a Signature created by an authority it trusts.

For example, a CompositeBuilder re-signs the Tickets for the Devices to associate the CompositeInstanceUri with the Device Ticket (see 8.1). Customers of the CompositeBuilder will not need a relationship with the Manufacturer of the Device to validate the Ticket.

DeviceIdentity Certificates are typically signed with a chain ending in a root CA owned by the Manufacturer or CompositeBuilder. Tickets are typically signed with a Certificate issued to the Manufacturer by a well-known root CA. Issuer Certificates for Certificates used to sign Tickets shall have the cRLDistributionPoints or authorityInfoAccess extensions defined (see RFC 5280).

When physical control over Devices and/or Composites is transferred from one organization to another there needs to be a physical transfer of goods and an electronic transfer of the Tickets associated with the Devices and Composites. The Tickets allow the new user to verify the authenticity of the Devices and Composites they received by using the handshake defined in 7.

When transferring Devices, the sender provides a DeviceIdentityTicket (see 8.2.1) for each Device. When transferring Composites, the sender provides a CompositeIdentityTicket (see 8.2.4) for each Composite and a DeviceIdentityTicket for each externally visible Device in the Composite. The DeviceIdentityTickets and CompositeIdentityTickets should be created and signed by the original Manufacturer and/or CompositeBuilder, however, a trusted intermediary, such as a Distributor, could create the Tickets or add additional Signatures to the existing Tickets.

Properly verifying the origin of Devices requires that OwnerOperators and other downstream users of Devices have access to the Tickets and the CA that issued the signing Certificates. This usually requires a network connection that allows the revocation status to be checked. The Tickets are used to build a list of Devices and Composites which are allowed on the network. The ProductInstanceUri and CompositeInstanceUri are used to correlate a Device with a Ticket. A Ticket can be verified before the Devices are connected to the network or done when a new Device is detected.

When an OwnerOperator initially receives a Ticket, it may wish to validate them immediately and add a Signature with their own Certificate. A Signature shall only be applied to a Ticket that has been validated. This allows the Device to be stored until it is needed without any further need for access to an external system to check revocation lists. The OwnerOperator can also manage the issue of expiring Certificates by periodically re-validating and adding a new Signature before the previous Certificate that created the previous Signature expires. The re-signed Tickets should be stored in systems controlled by the OwnerOperator.

Automatic validation of Devices requires a service, called a Registrar, running on the network. The Registrar is able to communicate with new Devices and see if they match a Ticket known to the Registrar. The mechanism for providing the Tickets to the Registrar depends on the Registrar. A completely automated solution would integrate the Registrar with the corporate ERP system. This would allow the Registrar to receive the Tickets as part of the purchasing process. When such integration is not available, the Tickets could be uploaded manually by the technician installing the Devices or they could be read from the Device itself. If a Ticket is provided with the Device, the RegistrarAdmin shall provide the Registrar with the CAs that can sign Tickets which are trusted.

When a CompositeBuilder or Integrator receives a shipment of Devices it needs to connect them to their network and verify their authenticity. This process is automated by the use of a Registrar that detects new Devices added to the network, inspects their DeviceIdentity Certificates and finds the corresponding DeviceIdentityTicket. If a match was found the Device is accepted and can be provisioned for use on the network. See 7 for a complete description of this process.

There are two modes of operation that a Device can use depending on whether it is a Client or a Server. Clients use PullManagement which is defined in 7.2. Servers use PushManagement which is described in 7.3. Devices which are a Client and a Server may use either model.

The authentication process requires secure communication using OPC UA. A Device shall have a Client or Server installed on the Device which is used for Device Onboarding, application setup and configuration. This Application is called the “Device Configuration Application” or DCA. When a Device is first connected the DCA is configured to use any of its DeviceIdentity Certificates as its Application Instance Certificate. Note that DeviceIdentity Certificates will not have a DNS name or IP address because these values are not known when the DeviceIdentity Certificate is created. Therefore, the Registrar shall suppress host name validation errors when communicating with a DCA. The Registrar should verify that the DCA is running on a network designated by the RegistrarAdmin as a source for new Devices.

Once the Device has been authenticated by the Registrar, it is provided with an Application Instance Certificate, called a DCA Certificate, that is used for any subsequent communication. The DCA Certificate will have a shorter lifespan and a CA which is managed by the OwnerOperator. This Certificate allows all Applications running on the Device to automatically be onboarded and configured without human intervention.

When a Device is first deployed it may have out of date firmware that needs to be upgraded before it can participate in the network. The SoftwareUpdateManager may use the software update model (PushManagement only) in OPC 10000-100 or it may rely on proprietary mechanisms that are specific to the Device. The Device will not get access to the network until the SoftwareUpdateManager indicates that the Device is up to date and whether a software update was applied. Once the firmware is updated, the Registrar can issue an Application Instance Certificate to the DCA.

Application Instance Certificates issued to a DCA shall not be used for communication with any application other than the Registrar, SoftwareUpdateManager, CertificateManager or a configuration application that acts on behalf of those agents. The CertificateManager shall restrict the Applications that a DCA is permitted to manage. A simple restriction would limit Certificate Requests to the host names/IP addresses that appear in the DCA Certificates. More complex rules could exist for complex Devices. OwnerOperators may choose to create a special VLAN (Virtual LAN) that is only used for communication using the DCA Certificates.

The registration process here also applies to externally visible Devices that are contained in a Composite. In these cases, the CompositeBuilder provides the list of Devices.

When a Device is first connected to the network it may not have a properly synchronized clock (e.g., a battery backed clock set by the manufacturer). This means it will not be possible for the Device to check the validity period of the Certificates used to establish secure communication with the Registrar. In these situations, the Device should use a time synchronization protocol such as NTP to update the system clock at boot. If a time synchronization server is not available the Device may ignore the validity period for the Certificates provided by the Registrar.

Device authentication depends on a process for creating, distributing and validating Tickets which contain information needed to determine if any given Device is allowed to be connected to the OwnerOperator’s network.

There are two strategies for validating Tickets that depend on how the Tickets are acquired. The recommended approach is to rely on an out-of-band mechanism which provides the Tickets for the Devices and Composites that will be delivered to the facility before the Devices are connected to the network. This could be done automatically if the Registrar is integrated with the ERP. It can also be a manual process where a digital file is delivered to an RegistrarAdmin that uploads it to Registrar. When a new Device is detected on the network the matching Ticket is found which confirms that the Device is authorized.

The second strategy uses a Ticket that is distributed with the Device or Composite. This Ticket could be stored on the Device or on physical media that was delivered with the Device. When a Device is connected to the network the Ticket is either manually uploaded to the Registrar by the technician installing the Device or is read from the Device during the authentication process. For this strategy to be secure the Certificates used to sign the Tickets are provided to the Registrar in advance by the RegistrarAdmin. A Device is authorized to be on the network if the Ticket is valid, it matches the Device and is signed by a trusted Ticket authority.

The steps to validate a Ticket are as follows:

1. Verify that a signing Certificate is valid and trusted;
2. Verify the Signature is valid;

Tickets that are not valid shall not be used.

Tickets may have multiple signatures added by different actors in the supply chain. The Registrar only needs to find one Signature created by a trusted authority. This assumes that actors in the supply chain only add a Signature if at least one of the existing Signatures is valid and created by an authority the actor trusts. Registrars shall not trust authorities unless they are confident that the authority is properly validating Tickets before adding a Signature.

A signing Certificate is trusted if it is valid and the Certificate is recorded as a trusted Ticket signing Certificate with the Registrar or if the issuer is a trusted root CertificateAuthority. The latter criteria is only allowed if the Ticket was provided out of band.

The process of verifying a Certificate is described completely in OPC 10000-4, however, checks that are specific to Application Instance Certificates do not apply (e.g. the HostName and ApplicationUri checks).

Trusted root CertificateAuthorities used to issue Ticket signing Certificates are companies that maintain Internet accessible online revocation status checks. For example, companies that provide Certificates for code/document signing could be a root CertificateAuthority for Ticket signing. Each OwnerOperator is responsible for maintaining a list of trusted root CertificateAuthorities which are accepted by the organization.