On 12/9/2010 2:29 PM, Wan-Teh Chang wrote:
The "(-8157) Certificate extension not found" part
is most likely wrong (a stale error code). Please try to track that down
and fix it.
I remember Nelson saying pretty much anytime that error pops out it's a
bug in NSS.
I would go with adding an importNonUserCertPackage method,
or add a new method that exposes both the boolean noUser
and boolean leafIsCA parameters of the native method
importCertPackageNative.
I didn't think of your option 2. I actually like that the best. It's
the easiest and won't affect backwards compatibility.
Note: importCertPackage is documented to detect and handle
user certificates automatically, so ideally we should try to make
it work as documented. This may require adding a new
native method to do that. To avoid duplicating too much code,
some refactoring of the existing native method
importCertPackageNative would be necessary.
Actually, I read through the javadoc a few times and I do think it
behaves the way it is documented.
- "The leaf certificate may be a a user certificate..." (or a CA)
- The exception makes me think it's working the way it's supposed to:
"NoSuchItemOnTokenException If the leaf certificate is a user
certificate, but the matching private key cannot be found."
I guess part of the confusion is terminology.
User: leaf cert that has matching key on a token
CA: I think we can agree NSS knows what a CA is
???: leaf cert that has no matching key on a token
The Javadoc for importCertPackage doesn't really mention the 3rd
category of cert.
Dave
--
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto
