Patrick wrote: > > Ok thanks. > > About trust flags: > What if I do keep the intermediate CAs in my apps' cert db and I do flag > them as "Valid CA" (trust flags = "c,," )
There's no need to give them any trust flags at all. "c" is a trust flag. > - With the understanding that I don't need to trust them in my cert db as > long as the root is trusted. I figure that as long as a CA is in the cert > db, and it's not a root CA, I'd flag it as valid -, what does "Valid CA" > mean exactly? It means that the cert is a CA cert, even if it doesn't appear to be. It is an override. It means that the cert should be treated as a valid CA cert, even if it doesn't appear to be a CA cert at all. It does not imply that the cert is absolutely trusted, however. A cert flagged with "c" is one that is valid for the purpose - provided that it is subordinate to another cert that is absolutely trusted. It's really only relevant to intermediate CA certs that don't appear to be valid on their faces (e.g. because they are missing the "basicConstraints" extension). An ordinary properly formatted intermediate CA cert doesn't need it. > Does NSS perform the cert chain verification differently if an intermediate > CA is marked as a "Valid CA"? E.g., Does NSS skip any of the signature > checking on CA certs? AFAIK, it doesn't skip any signature checks. It merely skips the checks that determine that the cert is a CA cert (as opposed to being a leaf (non-CA) cert). If you have (say) an SSL client auth cert, and you use your cert to issue/sign an SSL client auth cert for some other user, attempts to do SSL client auth with the cert you issued would ordinarily fail because your SSL client auth cert is not a CA cert. Setting the "c" flag on your cert would cause NSS to treat your cert as if it was an intermediate CA cert. So, that if the CA that issued your client auth cert was trusted to issue SSL client auth certs, then the cert you issued would also be trusted. > And about the trsut for a root CA: > A root CA may only issue intermediate CAs. That's not generally true. Generally, a CA (root or intermediate) can issue leaf certs or subordinate intermediate CA certs. The latter is limited by the path length constraint (if present) from the root CA's cert. ? So really flagging it as "Trusted > CA for client/server certs" does not really fit... > Maybe there should be a flag for "Trusted to issue intermediate CA cert"?? If a root CA is trusted to issue client auth certs, then client auth certs issued by that CA or any of its subordinate CAs are trusted. > About cert7.db: > Is the cert7.db format here to stay as the storage place for certs in NSS? > Is there talk about using the key/cert store formats likethe ones used by > Sun's java tools (ie, the standard JCA KeyStore)? NSS may move to another format in some release, but I doubt it will be a Java format. JSS may have a requirement for JCA compliance, but NSS does not, IMO. > Finally, about certutil: > It does say "Trusted CA to certs (only server certs for ssl)" when I use it > against my cert7.db. This cert7.db I've had for a while. I may have been > created with NSS3.1. WHat that explain the different certutil output?? What command line arguments do you use to see that message? > -- P -- Nelson Bolyard Disclaimer: I speak for myself, not for Netscape
