D3|\||\|!$ wrote:
The issue isn't with certificates; it is with private keys.I disagree with you...What if somebody deleted the private key from key3.db and its associated certificate entry in cert8.db??? Then added his own thing and went around playing with it...???
The keys in the key3.db will not match the certs in the cert8.db.Certs that have 'mojo' are the certs that have related private keys. They show up as 'user certs' to NSS users. If you delete key3.db, those certs will no longer show up as user certs, and in effect are no different that the peer certs the user has collected from S/MIME (for instance) to communicate with other S/MIME users.
The best bet is to allow the OS to secure the key3.db. NSS is certificate for FIPS 140-2 Level 2, but it assumes the OS is protecting the key3.db (requires an OS with manditory access control).You are right that private keys stored in files and protected by passwords can be attacked with dictionary attacks, rainbow tables, guessing, etc. The traditional counter-measure is to store the private-key in a FIPS 140-2 Level 2/3 certified hardware token that will not give up the private-key, and can lock up after some configurable number of incorrect password attempts.This arrangement will work fine on the server side; but necessitating the same thing for every client running the application... will be cumbersome!! I would rather be tempted to use the mechanism being used by browsers like Firefox and AOL communicator etc... If somebody could shed some light on that, I'd be very glad...
Warm Regards, D3|\||\|!$ _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
