Figure 14 illustrates the update of the DCA Personality Set using PullManagement. The DCA Personality Set is assumed to be the result of the process described in 5.2.3.1.

As long as GTA API does not offer a functionality for in-place update of an existing personality (for example, &ix=1) the update process needs to create a new personality (for example, &ix=2) and removes the outdated personality (&ix=1) once the process has completed successfully.

Figure 14 – Update of Device Configuration Application (Pull Management)

As a precondition for all subsequent information exchanges between the DCA Client and the Certificate Manager, the DCA Client creates a secure channel to the Registrar using the existing DCA Identity Personality (4.3.4) named urn:manufacturer.com:2024-10:myproduct:SN51235?cg=DefaultApplicationGroup&ct=EccNistP256&ix=1. Details on how to establish a secure channel using an existing personality are described in 5.5.

As the existing personality (&ix=1) is required until the update finishes successfully the DCA application creates a new personality named urn:manufacturer.com:2024-10:myproduct:SN51235?cg=DefaultApplicationGroup&ct=EccNistP256&ix=2 to accept the updated security objects. After receiving the new DCA Certificate, the old DCA Identity Personality is removed (gta_personality_remove()).

As in the initial onboarding process gta_personality_authenticate_data_detached() is used to compute integrity protection seals for the updated TrustList Objects.

Update of the DCA Identity Personality and TrustList can be performed in independent processes.

Update of the DCA Personality Set using Push Management works accordingly. The interactions between DCA application and GTA API are not affected by using either Push or Pull Management.