issue with a lot of certificates and keys in DB
I have a DB that has just shy of 7000 keys/certs in it. From the command line using certutil -L takes ~5 mins or so and then finally starts showing output all at once after the delay. It ends up using 80-90MB of ram (according to task manager). certutil -K, however, starts listing keys right away with no delay, all 6957 of them. Do you have an idea of a # that I should stay below to avoid this behavior or have you not really tested this most likely not-too-common case? I understand the development of NSS is directed primarily to the need of the commercial organizations funding it and those server products normally wouldn't have a need for ~7000 key/cert pairs. The problem first manifested itself while I was running a Java app and called the JSS method PK11Store.getCertificates() which calls the native method PK11Store.putCertsInVector(Vector certs). This is with cert8.db and key3.db formats. Dave -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: issue with a lot of certificates and keys in DB
On Wed, Jun 3, 2009 at 7:02 AM, David Stutzman dstutz.m...@nospam.dstutz.com wrote: I have a DB that has just shy of 7000 keys/certs in it. From the command line using certutil -L takes ~5 mins or so and then finally starts showing output all at once after the delay. It ends up using 80-90MB of ram (according to task manager). certutil -K, however, starts listing keys right away with no delay, all 6957 of them. I inspected the code of ListCerts and ListKeys in certutil.c: http://mxr.mozilla.org/security/ident?i=ListCerts http://mxr.mozilla.org/security/ident?i=ListKeys Both of them first get a list of all certs or keys, and then iterate through that list. So I can't really explain why ListKeys can start listing keys right away with no delay. Perhaps because keys are much smaller than certs? Another difference I see is that PK11_ListPrivKeysInSlot goes right to PKCS #11 to find the private key objects in a slot, whereas PK11_ListCerts or PK11_ListCertsInSlot needs to go through an intermediate layer (codename Stan). Perhaps that intermeidate layer also adds overhead to listing certs. It would be nice if you could file a bug report, and provide two call stacks of ListCerts and ListKeys. The need for the call stacks is that ListCerts and ListKeys (especially ListCerts) have several possible code paths, so we'd need to know exactly which code path is taken when you run certutil -L and certutil -K on your cert and key databases. Wan-Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: issue with a lot of certificates and keys in DB
On 2009-06-03 07:02 PDT, David Stutzman wrote: I have a DB that has just shy of 7000 keys/certs in it. From the command line using certutil -L takes ~5 mins or so and then finally starts showing output all at once after the delay. It ends up using 80-90MB of ram (according to task manager). certutil -K, however, starts listing keys right away with no delay, all 6957 of them. This is Bug 433105: lg_searchKeys always must traverse all keys to find one See especially https://bugzilla.mozilla.org/show_bug.cgi?id=433105#c8 Do you have an idea of a # that I should stay below to avoid this behavior or have you not really tested this most likely not-too-common case? I understand the development of NSS is directed primarily to the need of the commercial organizations funding it and those server products normally wouldn't have a need for ~7000 key/cert pairs. This is a problem with key3.db. It's not a problem with key4.db. (Or perhaps I should say, it's much much less of a problem with key4.db.) Since we want people to migrate to the new DBs anyway, fixing this problem with the key3.db is not going to be a high priority. I predict it will never be fixed for key3. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
