Dana, can you please provide some pointers on how we could do that? Thank you.

In general, revocation information is processed in this function: https://searchfox.org/mozilla-central/rev/36aa22c7ea92bd3cf7910774004fff7e63341cf5/security/certverifier/NSSCertDBTrustDomain.cpp#670
I imagine we'd want to gather whatever information we need there and stash it in the NSSCertDBTrustDomain like we do with e.g. the status of OCSP stapling: https://searchfox.org/mozilla-central/rev/36aa22c7ea92bd3cf7910774004fff7e63341cf5/security/certverifier/NSSCertDBTrustDomain.h#269
(NB: any accumulated state should be cleared in ResetAccumulatedState: https://searchfox.org/mozilla-central/rev/36aa22c7ea92bd3cf7910774004fff7e63341cf5/security/certverifier/NSSCertDBTrustDomain.cpp#1499)
The stashed information will have to be passed back up through VerifySSLServerCert, AuthCertificate, and the two result runnables we have (one for if the socket process is enabled, one otherwise), to AuthCertificateSetResults: https://searchfox.org/mozilla-central/rev/36aa22c7ea92bd3cf7910774004fff7e63341cf5/security/manager/ssl/SSLServerCertVerification.cpp#828, where the TransportSecurityInfo will receive that data.
Adding a field to TransportSecurityInfo involves extending its Read, Write, SerializeToIPC, and DeserializeFromIPC functions: https://searchfox.org/mozilla-central/rev/36aa22c7ea92bd3cf7910774004fff7e63341cf5/security/manager/ssl/TransportSecurityInfo.cpp#168,487,732,762
From there you can add a field to nsITransportSecurityInfo, and any nsIChannel over https should have access to it via its securityInfo field.