In an ideal world all implementations would move to this shared model of trust policy as soon as possible. However in the real world these things take time. Here we discuss various strategies for retrofitting existing implementations to be able to consume this stored data.
While such retrofits result in ignoring certain trust policy by a given implementation, there are concrete benefits of sharing even just some of the trust information. Such an interim retrofit produces coherent results for many current real world use cases. It is thus better than having all the crypto library implementations use their own source for trust policy.
Such a retrofit should be an interim measure.
If a crypto library expects an input of a set of anchor certificate authorities and nothing more, then it is possible to lookup all acceptable anchors from the store. Anchors that no not match the necessary trust policy would be filtered out before handing them over to the validation algorithms.
If a crypto library allows access to the certificate chain before, during (via a callback) or after validation, then it is possible to check each certificate\ in the chain against the blacklist.
It is possible to model NSS PKCS#11 trust objects on top of an underlying storage based on attached certificate extensions. This will only enforce the KeyUsage and ExtendedKeyUsage extensions. Blacklists are modeled by marking all usages as untrusted.