Servers may use PushManagement which is illustrated in Figure 6.

image009.gif

Figure 6 – Device Authentication using Push Management

See 7 for a complete description of the authentication process.

Each of the DeviceIdentity Certificates is returned in EndpointDescriptions returned by GetEndpoints. The Registrar looks for a pre-validated Ticket that matches the Certificate in one of the Endpoints. If none found it chooses any one and establishes a SecureChannel and calls RequestTickets. The Registrar needs to validate the Tickets returned by the Device which requires access to the Certificate that created one of the Signatures and the ability to check its revocation status.

If the Registrar finds an EndpointDescription that matches a valid Ticket it will create a new SecureChannel using that EndpointDescription. It provides the DCA Certificate and TrustList to the Device. Once a Device has a DCA TrustList and all software updates have been applied, it will not accept connections from untrusted Registrars. In this state, the DCA shall only return EndpointDescriptions that use the DCA Certificate when GetEndpoints is called.

The Registrar may then pass control to the SoftwareUpdateManager which is responsible for checking if the Device software is up to date and uploading a new image if required. Once complete the SoftwareUpdateManager or an agent acting on its behalf calls UpdateSoftwareStatus Method on the Registrar.

Once the Device has updated software the CertificateManager will be able to push Application Instance Certificates and TrustLists for all Applications exposed via an ApplicationConfiguration Object (see 9.3.6) in the DCA AddressSpace. This process is shown in Figure 7.

image010.gif

Figure 7 – Updating Certificates using Push Management

If multiple Registrars are on the network, the DCA shall accept the first one to provide an Application Instance Certificate and a TrustList. Once configured, the DCA shall reject connections from Registrars that are not in the TrustList. The OwnerOperator should have a strategy to detect and remove rogue Registrars since the DCA always trusts the first Registrar that provides a Certificate.

Some Devices with limited resources may only support a single Server which acts as both the DCA and the operational Application. DCAs report this requirement to the Registrar by setting the IsSingleton Property to TRUE on the ProvisionableDevice Object (see 9.3.2). Registrar that shall provide a normal Application Instance Certificate to the DCA that cannot be used to configure other Applications.