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
signature.asc
Description: Digital signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
