> > 'openssl asn1parse' recognizes the above DER as the 'secp256k1' OID.
NSS currently doesn't support secp256k1 and there are no plans to implement it afaik. I know that it's popular in certain circles but as far as I know those don't often overlap with scenarios in which NSS is used. That said patches are always welcome ;) Cheers, Franziskus On Wed, Feb 15, 2017 at 9:20 AM, Miklos Vajna <vmik...@vmiklos.hu> wrote: > Hi, > > On Tue, Feb 14, 2017 at 09:07:24AM -0800, Robert Relyea < > rrel...@redhat.com> wrote: > > You would need to install the -debug package for nss-softokn on the > distro > > to step into softoken (assuming you aren't using a hardware > accellerator). > > Thanks, I didn't realize there are multiple -debuginfo packages for the > same -debugsource ones. > > So here is exactly how CKR_DOMAIN_PARAMS_INVALID is set: > > ---- > (gdb) next > 1789 if (EC_FillParams(arena, &pubKey->u.ec.ecParams. > DEREncoding, > (gdb) next > 1791 crv = CKR_DOMAIN_PARAMS_INVALID; > (gdb) > 1789 if (EC_FillParams(arena, &pubKey->u.ec.ecParams. > DEREncoding, > (gdb) print crv > $5 = 0 > (gdb) next > 1841 *crvp = crv; > (gdb) print crv > $6 = 304 > (gdb) bt > #0 sftk_GetPubKey (object=object@entry=0x6b4fa0, key_type=key_type@entry=3, > crvp=crvp@entry=0x7fffffffced0) at pkcs11.c:1841 > #1 0x00007ffff572be7c in sftk_handlePublicKeyObject (session=<optimized > out>, key_type=3, object=0x6b4fa0) at pkcs11.c:970 > #2 sftk_handleKeyObject (object=0x6b4fa0, session=0x693170) at > pkcs11.c:1397 > #3 sftk_handleObject (object=object@entry=0x6b4fa0, session=session@entry > =0x693170) at pkcs11.c:1662 > #4 0x00007ffff572ece0 in NSC_CreateObject (hSession=<optimized out>, > pTemplate=<optimized out>, ulCount=<optimized out>, > phObject=0x7fffffffd098) at pkcs11.c:4296 > #5 0x00007ffff768e0e2 in PK11_CreateNewObject (slot=slot@entry=0x6929a0, > session=session@entry=0, theTemplate=theTemplate@entry=0x7fffffffd0a0, > count=count@entry=7, token=token@entry=0, > objectID=objectID@entry=0x7fffffffd098) at pk11obj.c:397 > #6 0x00007ffff7675c15 in PK11_ImportPublicKey (slot=slot@entry=0x6929a0, > pubKey=pubKey@entry=0x6ae8d0, isToken=isToken@entry=0) at pk11akey.c:232 > #7 0x00007ffff768e872 in PK11_VerifyWithMechanism (key=0x6ae8d0, > mechanism=<optimized out>, param=param@entry=0x0, > sig=sig@entry=0x7fffffffd2a0, > hash=hash@entry=0x7fffffffd280, > wincx=<optimized out>) at pk11obj.c:736 > #8 0x00007ffff768e99e in PK11_Verify (key=<optimized out>, > sig=sig@entry=0x7fffffffd2a0, > hash=hash@entry=0x7fffffffd280, wincx=<optimized out>) at pk11obj.c:690 > #9 0x00007ffff7673722 in VFY_EndWithSignature (cx=0x6a2d70, > sig=sig@entry=0x7fffffffd360) > at secvfy.c:596 > #10 0x0000000000418c31 in xmlSecNssSignatureVerify (transform=0x6ab4d0, > data=0x6b3700 "\257\237\003<\221\301\330X\ > 273J\307?\345n\177e|\254\362\345\242\317v\205\371{C\243\ > 246Q\027\277+\202M\223@4\354{\254\257M@\275\221\215\313Pw\ > 003f_l\031\062Wʼ7\016*ڱ", > dataSize=64, transformCtx=<optimized out>) at signatures.c:347 > #11 0x0000000000443b9a in xmlSecTransformVerifyNodeContent > (transform=0x6ab4d0, node=<optimized out>, > transformCtx=transformCtx@entry=0x7fffffffd710) > at transforms.c:1523 > #12 0x000000000044e0f4 in xmlSecDSigCtxVerify > (dsigCtx=dsigCtx@entry=0x7fffffffd450, > node=<optimized out>) at xmldsig.c:353 > #13 0x000000000040929c in xmlSecAppVerifyFile (filename=<optimized out>) > at xmlsec.c:1223 > #14 0x000000000040737d in main (argc=7, argv=0x7fffffffd9e8) at > xmlsec.c:1058 > (gdb) print pubKey->u.ec.ecParams.DEREncoding > $7 = {type = siBuffer, data = 0x6b3d08 "\006\005+\201\004", len = 7} > ---- > > > Fortunately you've provided enough information to get an idea of what is > > going on. EC keys have a der encoded parameter telling it what curve the > key > > is associated with (generally a der encoded oid pointing to the specific > > curve). The parameter is in the field u.ec.DerEncodedParams, and usually > > applications get this from the spki in a DER certificate, or a raw spki > > encoded structure. You'll need to map the xml way of identifying the > curve > > into the der encoding. NOTE: NSS only supports what's called the 'named > > curve' format of the parameters, so if xml is using raw curve parameters, > > then you'll have to map the raw curve parameters into known named curves. > > Aha. It seems that u.ec.ecParams.DEREncoding is already filled, > CKR_DOMAIN_PARAMS_INVALID is returned as EC_FillParams() fails. Here is > where it sets its error: > > ---- > 251 if (!params->cofactor) { > (gdb) > 252 PORT_SetError(SEC_ERROR_UNSUPPORTED_ELLIPTIC_CURVE); > (gdb) bt > #0 EC_FillParams (arena=arena@entry=0x6b35c0, > encodedParams=encodedParams@entry=0x6b3cf0, params=params@entry=0x6b3c30) > at ecdecode.c:252 > #1 0x00007ffff572b696 in sftk_GetPubKey (object=object@entry=0x6b4fe0, > key_type=key_type@entry=3, crvp=crvp@entry=0x7fffffffced0) at > pkcs11.c:1789 > #2 0x00007ffff572be7c in sftk_handlePublicKeyObject (session=<optimized > out>, key_type=3, object=0x6b4fe0) at pkcs11.c:970 > #3 sftk_handleKeyObject (object=0x6b4fe0, session=0x693170) at > pkcs11.c:1397 > #4 sftk_handleObject (object=object@entry=0x6b4fe0, session=session@entry > =0x693170) at pkcs11.c:1662 > #5 0x00007ffff572ece0 in NSC_CreateObject (hSession=<optimized out>, > pTemplate=<optimized out>, ulCount=<optimized out>, > phObject=0x7fffffffd098) at pkcs11.c:4296 > #6 0x00007ffff768e0e2 in PK11_CreateNewObject (slot=slot@entry=0x6929a0, > session=session@entry=0, theTemplate=theTemplate@entry=0x7fffffffd0a0, > count=count@entry=7, token=token@entry=0, > objectID=objectID@entry=0x7fffffffd098) at pk11obj.c:397 > #7 0x00007ffff7675c15 in PK11_ImportPublicKey (slot=slot@entry=0x6929a0, > pubKey=pubKey@entry=0x6ae8d0, isToken=isToken@entry=0) at pk11akey.c:232 > #8 0x00007ffff768e872 in PK11_VerifyWithMechanism (key=0x6ae8d0, > mechanism=<optimized out>, param=param@entry=0x0, > sig=sig@entry=0x7fffffffd2a0, > hash=hash@entry=0x7fffffffd280, > wincx=<optimized out>) at pk11obj.c:736 > #9 0x00007ffff768e99e in PK11_Verify (key=<optimized out>, > sig=sig@entry=0x7fffffffd2a0, > hash=hash@entry=0x7fffffffd280, wincx=<optimized out>) at pk11obj.c:690 > #10 0x00007ffff7673722 in VFY_EndWithSignature (cx=0x6a2d70, > sig=sig@entry=0x7fffffffd360) > at secvfy.c:596 > #11 0x0000000000418c31 in xmlSecNssSignatureVerify (transform=0x6ab4d0, > data=0x6b3740 "\257\237\003<\221\301\330X\ > 273J\307?\345n\177e|\254\362\345\242\317v\205\371{C\243\ > 246Q\027\277+\202M\223@4\354{\254\257M@\275\221\215\313Pw\ > 003f_l\031\062Wʼ7\016*ڱ", > dataSize=64, transformCtx=<optimized out>) at signatures.c:347 > #12 0x0000000000443b9a in xmlSecTransformVerifyNodeContent > (transform=0x6ab4d0, node=<optimized out>, > transformCtx=transformCtx@entry=0x7fffffffd710) > at transforms.c:1523 > #13 0x000000000044e0f4 in xmlSecDSigCtxVerify > (dsigCtx=dsigCtx@entry=0x7fffffffd450, > node=<optimized out>) at xmldsig.c:353 > #14 0x000000000040929c in xmlSecAppVerifyFile (filename=<optimized out>) > at xmlsec.c:1223 > #15 0x000000000040737d in main (argc=7, argv=0x7fffffffd9e8) at > xmlsec.c:1058 > (gdb) print encodedParams->len > $1 = 7 > (gdb) x/7xb encodedParams->data > 0x6b3d48: 0x06 0x05 0x2b 0x81 0x04 0x00 0x0a > ---- > > 'openssl asn1parse' recognizes the above DER as the 'secp256k1' OID. > > I may be wrong, but that looks like a named curve parameter to me. > > Does the above mean that this EC type is just not supported by NSS > currently? If so, how hard would it be to add support for this one? Is > this just a matter of adding a new constant to recognize it, or the > situation is more complex? > > (This parameter doesn't seem to be too rare, if you search for > "secp256k1" in your browser. :-) ) > > Thanks, > > Miklos > > -- > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto