On 8/18/2011 10:32 AM, Robert Relyea wrote:
On 08/17/2011 08:23 PM, Sean Leonard wrote:
Is there a way to determine whether the NSS DB(s) are in V8 (aka
sdb->sdb_type = SDB_LEGACY) versus in V9 (aka sdb->sdb_type = SDB_SQL)
mode?
Unfortunately, I don't believe that is surfaced at the 'slot' level.
Ok.
Well, from analyzing the code, I have come up with this algorithm. It is
based on sftkpars.c (sftk_EvaluateConfigDir) and pk11pars.c
(secmod_configIsDBM). I am mainly writing this for the benefit of
'posterity'; right now, none of my internal code actually uses this
algorithm.
PK11_GetModule(PK11_GetInternalKeySlot())->libraryParams
Look for the substring configdir='[opttype:]/some/path/here'
In '[opttype:]/some/path/here', if opttype: is 'sql:' or 'dbm:' (or
'extern:'), you have your answer.
If not, then PR_GetEnv("NSS_DEFAULT_DB_TYPE"). If it is sql, dbm, etc.,
you have your answer.
If not, then try to divine the compilation flag 'NSS_DISABLE_DBM'.
(Divine = use various methods to figure this out.) If it was specified,
then the answer is sql. If it was not specified, then the answer is dbm
(legacy).
NOTE: the upper level of
NSS will still associate a nickname with *ALL* the certs with a given
subject, no matter how it's stored internally, This 'feature' was meant
to allow us to deal with user/identity. NSS would pick the appropriate
cert (unexpired, signer or key exchange, etc) for that user/identity
automatically. This has lead to confusion because people except nickname
to match cert, not groups of certs.
Good to know. My reason is much simpler: setting nicknames is a matter
of self-determination. Some people like to give certificates
(particularly certificates for which they have private keys, aka, "their
certificates") unique names to sort them out.
Actually, maybe I should mention this bug. There has been a trend among
some CAs to issue certificates that lack common names (CN). By default,
the security subsystems (specifically, I think PSM) name it "'s The
USERTRUST Network ID #2", because the CN is empty. Naming something
"'s..." is not a great scheme, especially if users can't change the
nicknames.
I thought about filing a bug for this but it is unclear what the
'default' nickname should actually be, and since I don't have a good
solution (beyond what the current behavior is), I am not sure the best
way to fix it. One could use the E= attribute if the CN= is absent, but
if there are multiple E=s, that needs to be considered.
-Sean
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
