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

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.