CD signing keys are hard coded in SDK and they won't be able to revoke if they are compromised until code change

[j2fong]

Reproduction steps

Problem:
The CD signing keys are hard coded in Matter SDK. If these keys are compromised, the deployed SDK will not be able to revoke.

Proposed solution:

• Call DCL PKI certificate revoke API to check the revoke status of the certificate (https://zigbee-alliance.github.io/distributed-compliance-ledger/#/Query/RevokedCertificates)
• Then download the new approved certificate using https://zigbee-alliance.github.io/distributed-compliance-ledger/#/Query/ApprovedCertificates with the same subject and subject key ID

Bug prevalence

everytime

GitHub hash of the SDK that was being used

faad9e1

Platform

core

Platform Version(s)

No response

Anything else?

No response

[tcarmelveilleux]

We are not calling DCL APIs in SDK --> otherwise we have a service dependency with no official SLA, that would be called by a lot of common code, and would require the requisite error handling and multi-platform paths.

The DefaultAttestationVerifier allows overriding the trust store contents to add/remove CD keys, and PAAs. Anyone can also write their own DeviceAttestationVerifier.

A big part of the point of certification declarations is to replace the DCL. If we need to look-up a DCL replica first, then there is much less value to them, and offline commissioning fully based on resident infrastructure cannot take place.

There are provisions in SDK to add more certs that chain to the CSA root, or allow update of that code. We don't decide how different stakeholders implement all of attestation verification, and the SDK cannot be guaranteed to be used by all for that purpose.

[caipiblack]

We are not calling DCL APIs in SDK --> otherwise we have a service dependency with no official SLA, that would be called by a lot of common code, and would require the requisite error handling and multi-platform paths.

The DefaultAttestationVerifier allows overriding the trust store contents to add/remove CD keys, and PAAs. Anyone can also write their own DeviceAttestationVerifier.

A big part of the point of certification declarations is to replace the DCL. If we need to look-up a DCL replica first, then there is much less value to them, and offline commissioning fully based on resident infrastructure cannot take place.

There are provisions in SDK to add more certs that chain to the CSA root, or allow update of that code. We don't decide how different stakeholders implement all of attestation verification, and the SDK cannot be guaranteed to be used by all for that purpose.

We are building a Matter Commissioner/Controller, currently we was using GetTestAttestationTrustStore() function to get the truststore.

We understand that in the stack there is no function to load a truststore from DCL (online)

But there are functions to use a folder as « truststore »

Did someone know if there is an example somewhere to download the certificates from DCL to local folder ?

Do we need specific credentials to do it ?

What are the best practices about it?

• Download all the PAA on every boot and use previously downloaded if there is no connection ?