Are you certain that certutil is using the version of the NSS library that has ECC support compiled in? Most *nixes have a command called 'ldd' or such that will print the list of dynamic libraries that an executable depends on, as well as what files the system is using to match them.
Windows has a tool somewhat akin to this, but its path matching algorithm has changed in the past few years and I don't know how to determine it there. The tool is 'depends.exe', if I remember right, and it's available with the Windows SDK and Windows DDK. -Kyle H 2010/1/14 Kai Chan <[email protected]>: > Correction: certutil -R -s "CN=ectest, O=ectest, L=ectest, ST=ectest, C=US" > -p "123-456-7890" -o ectest.req -d . -k ec -q nistp256 -Z SHA256 > > During the parameter parsing in certutil_main() in cmd/certutil/certutil.c, > the '-Z' option should call SECU_StringToSignatureAlgTag() in > cmd/lib/secutil.c and return hashAlgTag as SEC_OID_SHA256. > When execution reaches SEC_GetSignatureAlgorithmOidTag(), the switch > statement should hit "case ecKey:" and set sigTag to > SEC_OID_ANSIX962_ECDSA_SHA256_SIGNATURE. > signAlgTag at line 294 in certutil.c shouldn't be SEC_OID_UNKNOWN, else I'd > have the "unknown Key or Hash type" error. > > I guess I'm confused as to what's causing the error. > > Thanks, > Kai > > On Thu, Jan 14, 2010 at 5:44 PM, Kai Chan <[email protected]> wrote: >> >> Thank you both for your responses. Yes, you are correct. I've compiled >> NSS with "NSS_ENABLE_ECC" and I can make EC keys, but am having problems >> with CSRs. Perhaps I'm doing something wrong with this certutil command: >> >> certutil -R -s "CN=ectest, O=ectest, L=ectest, ST=ectest, C=US" -p >> "123-456-7890" -o ectest.req -d . -k ec -q nistp256 >> >> The result I get is: >> certutil: signing of data failed: security library: invalid algorithm >> >> Thanks, >> Kai >> >> On Thu, Jan 14, 2010 at 4:49 PM, Wan-Teh Chang <[email protected]> wrote: >>> >>> 2010/1/14 Kai Chan <[email protected]>: >>> > Hi, >>> > >>> > NSS has ECDSA with SHA1 enabled in SEC_DERSignData() in secsign.c >>> > >>> > (http://mxr.mozilla.org/security/source/security/nss/lib/cryptohi/secsign.c), >>> > but will ECDSA with SHA256 and higher be supported in the future? Or >>> > is >>> > this something as simple as adding to the switch statement, since the >>> > other >>> > EC signature OIDs exist in SECOIDTag >>> > >>> > (http://mxr.mozilla.org/security/source/security/nss/lib/util/secoidt.h): >>> > SEC_OID_ANSIX962_ECDSA_SHA224_SIGNATURE = 277, >>> > SEC_OID_ANSIX962_ECDSA_SHA256_SIGNATURE = 278, >>> > SEC_OID_ANSIX962_ECDSA_SHA384_SIGNATURE = 279, >>> > SEC_OID_ANSIX962_ECDSA_SHA512_SIGNATURE = 280, >>> >>> The switch statement determines the default signature algorithm OID >>> if the caller doesn't specify it (by passing algID=SEC_OID_UNKNOWN). >>> >>> You can pass algID=SEC_OID_ANSIX962_ECDSA_SHA256_SIGNATURE >>> to SEC_DERSignData() to generate an ECDSA-with-SHA-256 signature. >>> >>> We may want to change the default ECDSA OID in that switch >>> statement to SEC_OID_ANSIX962_ECDSA_SHA256_SIGNATURE >>> at some point, since Suite B requires at least SHA-256. >>> >>> Wan-Teh >>> -- >>> dev-tech-crypto mailing list >>> [email protected] >>> https://lists.mozilla.org/listinfo/dev-tech-crypto >> > > > -- > dev-tech-crypto mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-crypto > -- dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
