I have this certificate sitting on the filesystem and it's a leaf cert,
not a CA. I am hitting a snag here trying to import the cert into the
database with JSS.
* NSS works fine:
certutil -A -d . -i cert.der -n "nickIWant" -t ",,"
* JSS:
byte[] certBytes = <read bytes of cert.der from filesystem>;
CryptoManager.importCertPackage(certBytes, "importNick");
throws org.mozilla.jss.crypto.NoSuchItemOnTokenException: Expected user
cert but no matching key?: (-8157) Certificate extension not found
I'm trying to do this so I can get a handle on a
org.mozilla.jss.crypto.X509Certificate which is what JSS is expecting to
deal with in most cases. I'm trying to build certificate chains and
export PKCS#7 so I need to call
CryptoManager.buildCertificateChain(X509Certificate leaf) and
CryptoManager.exportCertsToPKCS7(X509Certificate[] certs);
Other import methods:
* importCACertPackage throws CertificateEncodingException
* importCertToPerm can't be called as it needs a
org.mozilla.jss.crypto.X509Certificate
* importUserCACertPackage throws same error as importCertPackage
Basically, JSS is explicitly forbidding the user from importing this
type of certificate into the database while NSS allows it. <Contrived
example> If I was writing an email client in Java using JSS for S/MIME,
how would I ever import another user's email certificate into the DB so
I could use it to encrypt an message?
<stops to look at JSS code>
http://mxr.mozilla.org/security/source/security/jss/org/mozilla/jss/CryptoManager.java#1185
importCertPackage calls the native method importCertPackageNative(byte[]
certPackage, String nickname, boolean noUser, boolean leafIsCA) and
passes false for noUser. The comment on that method says "noUser true
if we know that none of the certs are user certs. In this case, no
attempt will be made to find a matching key for the leaf certificate."
Off the top of my head I can think of 2 changes to JSS would "fix" this.
1) Add another import method to CryptoManager that passes true for
noUser instead of false to importCertPackageNative
pro: easy fix, adds missing feature to JSS and brings parity with NSS
con: users need to know ahead of time if their cert is CA or not and
call appropriate method, yet another import method to confuse users
2) Before importCertPackage calls importCertPackageNative it should
inspect the certificate(s) and determine the appropriate flags use
pro: easier on users, people upgrading JSS would get the functionality
for free (though not sure you guys want the behavior of a method to
change like that...)
con: chance to mess up "detection", in addition, importCertPackage says
it takes a few different formats of input (DER cert, DER P7, PEM cert)
and that would have to be taken into account. These structures would
have to be decoded and inspected on the asn1 side?
I think this is within scope of my abilities and if a dev wants to work
me on this I'd be willing. I know there are no paid JSS devs anymore.
I miss Glen :(
Dave
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
