Each CA certificate in nssckbi should link in some manner to documentation of its approval for inclusion in Mozilla products. This would have two major benefits: 1. PSM could show the link to the user (I will file a dependent bug). 2. It would provide a means for an automated process to check consistency of nssckbi with the current set of approved CAs (linked from https://www.mozilla.org/projects/security/certs/).
Let me help you understand the scope of your proposal. nssckbi is a PKCS#11 module. It implements the standard PKCS#11 API. That API defines a standard set of object types (classes, except that the definitions are in C, not C++) which have a standard set of attributes and a standard set of methods for each class. Standard object types include: public key, private key, symmetric key, certificate. The PKCS#11 API also allows implementations to extend it by implementing "vendor defined" object types, and vendor defined attributes for any of the objects (standard or vendor defined). It does not allow vendor defined methods. What you are proposing is the creation of a new attribute for certificate- type objects, an attribute that would hold a URL. You might propose it as a new standard attribute, which might come out in the next new revision or amendment of the PKCS#11 standard, or you might propose it as a "vendor defined" attribute. The latter probably makes most sense, and is certainly most expedient. In addition to defining and implementing this new certificate object attribute in the nssckbi PKCS#11 module, you are proposing that the NSS libraries that use PKCS#11 modules via the PKCS#11 API be enhanced with the addition of at least a few methods in NSS's higher layer APIs by which to access the new attribute(s). This is not a *BAD* idea, but it's a quite new idea, and the demand for it doesn not yet appear to be great. There are many other bugs and enhancement requests for which the demand seems much greater at present, and the pool of NSS developers is at an all time record low right now, so I wouldn't expect this to happen very soon. But you could certainly start exploring what it would take to write a patch to add that new vendor-defined attribute to nssckbi. NSS already has several other vendor-defined attribute types so there are examples to follow in the code base.