> 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...???
> 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
