Hello @QuantumCache
My apologies for the late response, and thank you for the information provided. Regarding DPS and certificate management i think its mostly clear now : The DPS will search the chain up to the first certificate it can validate and if that certificate is valid, the device will be allowed provision and if its invalid or disabled it will not be allowed to provision. This means that if the intermediate certificate is valid but its 'parent' certificate is not, the device will be allowed to provision. Is that correct?
You may be interested to read this document: Disallow specific devices in an enrollment group
This specifies what to do to block a device (make an individual device registration) but not how to obtain this registration if the device certificate was generated/signed by an intermediate certificate. How would one in that case obtain the device certificate to make this registration?
This document talks about the DPS and TLS support: TLS support in Azure IoT Hub Device Provisioning Service (DPS)
It does not say however if the device certificate is actually used in the TLS client authentication step. For now i'm assuming it is.
Please see this document : Understand extended offline capabilities for IoT Edge devices, modules, and child devices, for the certificate management, again it depends on the security needs of your solution.
This article is about a setup using an IoT Edge gateway device. In our setup we are not using a gateway.
One other question that came up during testing:
The device when connecting to the DPS service should provide the Scope ID of the DPS service. Is this Scope ID changed every time the DPS service is (re)created? That is, if a device was offline for a longer period of time, could the DPS ID Scope have changed if the DPS service was deleted and re-deployed in Azure?