>
> '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
