Yes, it's pointing to the ECC-enabled NSS. I am able to generate EC keys using: certutil -G -d . -k ec -q nistp256
However, no luck with EC certificate requests with and without specifying the hash. Thanks, Kai On Thu, Jan 14, 2010 at 7:46 PM, Kyle Hamilton <[email protected]> wrote: > 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 >
-- dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
