>> 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. Right, In NSS it's a bit confusing because if the certs all have the same subject, they will get the same nickname, or at least one nickname will refer to *all* the certs. Because of this you can't depend on nicknames to point to different certs (even if they have different 'labels' in the PKCS #11 module). NSS will still, under the covers, look up all the certs that match the subject of the referenced cert. > > > 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. Sigh, The 'can't change the nickname' isn't actually built into NSS. NSS can programatically change the nickname. It's a problem with the tools (the nss command line tools and the mozilla tools). It's a policy which I do not agree with, and leads to all sorts of different problems like the one you just described. The theory is that users don't know what they are doing and accidentally change the name of the cert and it make support harder. I never agreed with that policy, and now may be a good time to get this changed. It's even worse if you import a PKCS12 file form Microsoft. Microsoft gives it's cert an extremely ugly 'nickname', which will quite happily accept. > > 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.
File the bug anyway. We should do something when the CN field in blank, other then return a blank;). The component, I think, is PSM (NSS itself doesn't pick > > -Sean
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
