Hi, Thanks for your responses. So it seems like I want to create X.509 certificates from my keys and add them to the PKCS 11 data store in firefox. I want my certificates to be protected by a password to access them so does this mean they require their own slot? And if so, how do I create a new slot?
Thanks, Dan On Oct 14, 2:18 pm, Robert Relyea <[EMAIL PROTECTED]> wrote: > Nelson B Bolyard wrote: > > [EMAIL PROTECTED] wrote, On 2008-10-13 13:52: > > >> I have a crypto library which I connect to a Firefox extension using > >> Xpcom. The library generates custom size public and private key pairs > >> which I would like to store securely in Firefox. How would this be > >> done? > > > If I'm not mistaken, Firefox stores only > > a) private keys and > > b) certificates bearing public keys. > > It does not store public keys except inside certificates. > > This is true except the last statement should read (It does not store > public keys except inside a certificate or paired with a private key).> > Typical use is to generate a key pair, then generate a signed PKCS#10 > > certificate signing request (CSR) which contains the public key, and > > send that to a CA. Once sent, the public key is forgotten until the > > certificate is received from the CA, bearing that same public key. > > Actually this public key is still 'stored', but is only accessible if > the token is logged in (That's because the keys are actually stored in > the key database as part of the private key)*. This statement is true of > the old databases. The shared database does store public keys as > independent entities, and they are accessible without logging in. > > From a practical point of view, however, nelson is correct. NSS does > not provide an easy way of referencing any types of bare asymetric keys > without accessing them through a certificate. Firefox itself only ever > uses certificates to do asymetric operations (including extracting > public keys or finding corresponding private keys). > > * More exact detail. NSS always asks for both keys, when generating > them, to be permanent. I believe NSS also imports public keys when > importing keys from PKCS #12. Under the covers in softoken, NSS > 'accepts' imports of public keys for which the corresponding private key > already exists. Whether or not there was an actual import, NSS > 'provides' the public key for any private key in the old database. When > using the shared database, this underlying trickery is not needed. The > Shared database will store public keys separately from private keys just > like most well written PKCS #11 modules. Firefox, in general however, > does not use these bare keys, but the doe exist. No trust is given to > these keys, and the ability to reference them is not necessarily > coherent (they are usually referenced either by checking for their > existence (we already have the public key, we just want to see if the > token has it), or by use the the private key (NSS has a function to get > the public key from the corresponding private key). > > > Do you have certificates for your public keys? > > _______________________________________________ > > dev-tech-crypto mailing list > > [EMAIL PROTECTED] > >https://lists.mozilla.org/listinfo/dev-tech-crypto > > > > smime.p7s > 4KViewDownload _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
