[Question] Support for certificate revocation

[MGTheTrain]

Hi there,

I haven't found any documentation regarding certificate revocation, suggesting it's not supported yet.

Can we expect certificate revocation to be included in the current roadmap?

It would be intriguing to learn about this as it presents an interesting scenario to consider when working with X.509 certificates.

Best regards

[MGTheTrain]

Just to add a bit more context here are some methods to check the revocation status of a certificate:

Certificate Revocation List (CRL):

A CRL is a list of revoked certificates published by the Certificate Authority (CA). Systems can download and check this list to determine if a certificate has been revoked.

Online Certificate Status Protocol (OCSP):

OCSP is a protocol used to obtain the revocation status of a certificate in real-time. It allows systems to query the CA for the status of a specific certificate without needing to download the entire CRL.

[arsing]

Certs of servers that we connect to as a client (IoT Hub, DPS, EST server) are not checked for revocation. That's expected for the internet in general, since internet PKI generally tends towards using short-lived certs rather than expect clients to perform revocation checks / require OCSP stapling.

Certs issued by certd using local issuance (local CA / self-signed) do not have any revocation information tracked anywhere, nor is there any API in certd to mark a previously-issued cert as revoked.

Certs issued by certd using EST will contain revocation information if the EST server put it.

[MGTheTrain]

Hi arsing,

Thank you for the detailed response.

I understand that certs for servers we connect to (like IoT Hub, DPS, EST server) are not typically checked for revocation due to the general trend in internet PKI towards using short-lived certificates rather than relying on clients to perform revocation checks or require OCSP stapling.

I also acknowledge that certs issued by certd using local issuance (local CA / self-signed) do not have any revocation tracking or API support for marking a certificate as revoked.

However, I have a few follow-up questions to further clarify the handling of certificate revocation:

1. For certificates issued by certd using EST that contain revocation information, what mechanisms are available to check the revocation status? Are there any best practices or recommended approaches for this scenario?

2. Considering the reliance on short-lived certificates, how should we handle scenarios where immediate revocation is necessary? For example, if a private key is compromised, what is the recommended process to mitigate this risk in environments using certd?

3. Are there any plans to introduce API support or additional features in certd to manage and track the revocation status of certificates?

Understanding these aspects will help us better align our security practices with the capabilities and limitations of certd. Any guidance or recommendations you can provide would be greatly appreciated.

Best regards

[arsing]

1. For certificates issued by certd using EST that contain revocation information, what mechanisms are available to check the revocation status?

The certd API gives the cert as a PEM blob to your client, so your client can parse it and do whatever the cert says to check its revocation (CRL / OSCP).

2. Considering the reliance on short-lived certificates, how should we handle scenarios where immediate revocation is necessary?

For EST-issued certs, have your EST server issue certificates with revocation info and make sure all your clients check for revocation.

For locally-issued certs, key compromise is not a concern because they key is local to the device and the cert is only trusted locally as well. If the key is compromised then that means the whole device is compromised, so you'd handle that instead of bothering to revoke its certs.

3. Are there any plans to introduce API support or additional features in certd to manage and track the revocation status of certificates?

No.

[MGTheTrain]

Hi arsing,

Thank you for the quick and comprehensive response. I'll go ahead and close the issue.

Best regards