7.1 Overview

Registrars shall not accept Devices they do not trust. The steps to determine trust are:

  1. Read all DeviceIdentity Certificates from the Device;
  2. Locate a Ticket that has a ProductInstanceUri that matches one or more DeviceIdentity Certificates;
  3. Validate the Ticket if it has not already been validated (see 6.4);
  4. Select and Validate DeviceIdentity Certificate that matches the Ticket;
  5. Establish a secure connection to the Device using the selected DeviceIdentity Certificate.
  6. Issue a DCA Application Instance Certificate to the Device that indicates that it has been authenticated.

The initial communication between the Registrar and the Device is secured with a DeviceIdentity Certificate. When using PushManagement (7.3), the Registrar is a Client that calls GetEndpoints via connection without security on the Device Configuration Application (DCA). The DCA shall provide at least one EndpointDescription for each DeviceIdentity Certificate. The Registrar chooses a DeviceIdentity Certificate, establishes a secure connection using an EndpointDescription that uses that Certificate. This provides proof that the Device possesses the PrivateKey associated with the Certificate. The Registrar uses the SecureChannel to provide an Application Instance Certificate to the DCA which will allow the DCA to be used to provision the other Applications running on the Device. This Certificate is called the DCA Certificate.

When using PullManagement (7.2) the DCA connects to the Registrar without security and calls the ProvideIdentities Method. The Registrar chooses a valid DeviceIdentity Certificate and returns it in the response along with a ApplicationId which is used to request new Certificates. The DCA reconnects using a new SecureChannel with the selected Certificate which provides proof that the Device possesses the PrivateKey associated with the Certificate. The DCA uses the SecureChannel to request a new Application Instance Certificate which will allow the DCA to provision the other Applications running on the Device. The DCA Application Instance Certificate cannot be used for any action other than configuring the DCA or other Applications managed by that DCA (for example, the host name/IP address of the Application being configured has the same host name/IP addresses assigned to the Device where the DCA is running).

Registrar first looks for a Certificate that has a ProductInstanceUri as a value in the subjectAltName of the Certificate. The Registrar first searches the set of pre-validated Tickets that were provided out-of-band for a match. If that fails it either calls the RequestTickets Method on the DCA (see PushManagement in 7.3), or returns a code from ProvideIdentities Method that tells the DCA to call the ProvideTickets Method (see pull management in 7.2).

If the matching DeviceIdentityTicket is referenced by a Composite Ticket (see CompositeIdentityTicketType in 8.2.4) then the Registrar looks for a Certificate that has both the CompositeInstanceUri and the ProductInstanceUri as values in the subjectAltName.

A Device that is part of a Composite should provide the Composite Tickets in the RequestTickets or ProvideTickets Method.

Partial matches to DeviceIdentityTickets in CompositeIdentityTickets are rejected (i.e. Certificates with the ProductInstanceUri but no CompositeInstanceUri).

If more than one Certificate had a matching Ticket the Registrar may choose any one of them. The one selected is logged.

If the matching Ticket came from the Device, the Registrar validates the Ticket (see 6.4).

Once the Registrar has found a valid Ticket that matches a DeviceIdentity Certificate, it can use the CertificateAuthority in the Ticket to validate the selected Certificate using the process described in OPC 10000-4 for Application Instance Certificates. The revocation status check may be online if the Manufacturer or CompositeBuilder adds the cRLDistributionPoints or authorityInfoAccess extensions (see RFC 5280) to the DeviceIdentity Certificates. If those extensions do not exist then the revocation check may be skipped. Skipped revocation checks shall be logged. If the Ticket is signed by a trusted Ticket signing authority and the timestamp is valid then expired CA Certificates may be ignored since the lifetime of a Device is usually longer than the lifetime of a CA Certificate.

The Registrar, and the storage it needs, is a critical part of the authentication process and needs to be protected from access by malicious actors.