5.2.3 Provisioning of DCA’s Application Instance (Certificate)

This section shows how interaction with GTA API on the local endpoint maps into the overall onboarding process. During the course of the onboarding process a new personality for the DCA is created. The following operations are of interest with respect to the trust anchor:

  • Generate a new public/private key pair
  • Sign the proof-of-possession
  • Optional: Store end-entity certificate chain as part of the personality
  • Store the list of trusted certificates belonging to the DCA personality

The examples in this section use the ECC profile org.opcfoundation.ECC-nistP256 (6.1). They can be easily adapted to RSA by simply exchanging the profile name.

5.2.3.1 Pull Management

Figure 12 illustrates the use of TrustAnchor capabilities integrated in the Pull Management process (See OPC 10000-21).

image016.jpg

Figure 12 – Onboarding of Device Configuration Application (Pull Management)

The process starts from selecting a DeviceIdentity(s) that are eligible for onboarding (see 5.2.2). The DCA client needs to maintain a mapping between DeviceIdentity certificates and the corresponding Device Identity personality.

The DCA client proposes all available DeviceIdentity to the Registrar which replies with the selected DeviceIdentity certificate.

The DCA client uses the selected DeviceIdentity to create a secure channel to the Registrar. Create SecureChannel involves the computation of a digital signature (gta_authenticate_data_detached()). Further details for establishing a secure channel are explained in 5.5. Since the DCA client did not yet store any trusted certificates there is no authentication of the Registrar.

The DCA client creates a new identifier for the DCA and creates a new DCA Identity Personality for that identifier (gta_identifier_assign(), gta_personality_create()). The identifier value and personality name are set according to 4.3.2.1 and 4.3.4.

After creation of the DCA Identity personality the DCA prepares to file a certificate signing request (CSR) for its own DCA Certificate (cf. OPC 10000-6 6.2, Table 45; https://reference.opcfoundation.org/Core/Part6/v105/docs/6.2). Upfront the device specific information that should be included in the CSR is setup (gta_context_set_attribute()). Finally the proof-of-possession is computed and the completed CSR is returned to the DCA client (gta_pesonality_enroll()) and forwarded to the Registrar.

After the Registrar has processed the certificate signing request it provides the DCA Certificate and the DCA TrustList, i.e., the list of certificates that the DCA shall regard as trustworthy for future communications with OPC UA infrastructure services (e.g., Registrar., Certificate Manager)

Storage of the DCA Certificate within the trust anchor is optional as the certificate is protected by the issuer’s signature.

The integrity of the DCA TrustList shall be protected by the TrustAnchor. The DCA creates a dedicated DCA TrustList personality using the local data protection profile ch.iec.30168.basic.local_data_integrity_only. Storage of the TrustList objects is left to the application. The integrity of the TrustList objects is protected using a seal computed with gta_authenticate_data_detached(). The returned integrity protection seal is to be stored along-side the respective TrustList object by the application.

5.2.3.2 Push Management

Figure 13 illustrates the use of TrustAnchor capabilities integrated in the Push Management process (See OPC 10000-21).

image017.jpg

Figure 13 – Onboarding of Device Configuration Application (Push Management)

In response to a GetEndpoints request received from the registrar the DCA server compiles a list of DeviceIdentity(s) that are eligible for onboarding (see 5.2.2). The DCA server needs to maintain a mapping between DeviceIdentity certificates and the corresponding DeviceIdentity personality. The list of EndpointDescriptions created from the available DeviceIdentity certificates is returned to the Registar.

The Registrar selects one DeviceIdentity and starts a create SecureChannel Request. Details for establishing a SecureChannel are explained in 5.5. The DeviceIdentity selected by the Registrar is indicated by the ReceiverCertificateThumbprint contained in the security header (See OPC 10000-6).

The subsequent actions of the DCA server towards the GTA API correspond to Pull Management.