Now, if we could get a few standardized "profiles" of CAs, e.g. a standardized "high assurance" profile, and a standardized "low assurance" profile, then perhaps a cert could include an extension that says "this CA conforms to standardized CA profile number XXXX".
RFC3280 : 4.2.1.5. Certificate Policies
The certificate policies extension contains a sequence of one or more policy information terms, each of which consists of an object identifier (OID) and optional qualifiers. [...]
In an end entity certificate, these policy information terms indicate the policy under which the certificate has been issued and the purposes for which the certificate may be used. In a CA certificate, these policy information terms limit the set of policies for certification paths which include this certificate.
Just normalize an OID for the "high assurance" profile and the standardized "low assurance" profile, and include them in a multi-valued Certificate Policies field. Everything is there for it to work like that.
If the certificate doesn't include the extension with the needed values, it is possible to use an external source to add that knowledge(*), it's just more complex to manage.
* Just like NSS currently uses external methods to handle the SSL/client/code signing trusted info for CA certificates and doesn't extract them from the certificate content.
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
