xmlsectool: binary jar file bails out when the built-from-source version works

[Weiwu Zhang]

On Mon, 28 Sep 2020, Ian Young wrote:

> It would also help if you could provide steps to generate a similar
> key (obviously not the one you're using).

Yes I did, and this time I forgot to use openssl's -noout parameter
when generating the key, resulting it mixing the output (the EC
parameter) and the result (EC KEY) into one single file. And
surprisingly the resulted file works with the same test case.

I dug into the issue more, and realised that such an output works:

❯ openssl ecparam  -name secp256k1 -genkey
-----BEGIN EC PARAMETERS-----
BgUrgQQACg==
-----END EC PARAMETERS-----
-----BEGIN EC PRIVATE KEY-----
MHQCAQEEIKYV1xoz6smkpdMksfgI8/3465V02UZdaKj4JSH30bBhoAcGBSuBBAAK
oUQDQgAEO1O+/xRGEVJgBEAOQorBveXPTQS3c7MA+9R+HEMP7TkscI9FONPclcRb
5sXZJjYHNYWhvxuXdGl8QrFVRIVBYg==
-----END EC PRIVATE KEY-----

However the following does not work:

❯ openssl ecparam -name secp256k1 -genkey -noout
-----BEGIN EC PRIVATE KEY-----
MHQCAQEEIHyx/m9I6/ZbvqN5XJ/fZSM6P7PIuvNDnWdp8STjlGqQoAcGBSuBBAAK
oUQDQgAEVGRwTHlFRgxmhnJNO4Vfdojmg2pni44U4SMFEziNM8YVhd62UzwB5L0+
n8EXsvTIv5Uj7COQd/1cTsdL9kin4w==
-----END EC PRIVATE KEY-----

The most plausiable explanation is that a certain version of
BouncyCastle expected a key file encoded in CER with both the EC
PARAMETERS and EC PRIVATE KEY.

Given it's asn1 at work, the library should learn what curve is used
from reading the key. That's the purpose of encoding keys in ASN1 in
the first place!  Otherwise one might as well encode the key in a
BigEndian unsigned 256-bit octet string.

Etherway, now I know how to write a tutorial for using xmlsectool (as
was needed in a part of our project).

> I'm still interested -- in principle -- in getting to the bottom of
> your issue, so please open a JIRA case.

Seems I need to be affiliated with an identity provider to file an
issue in JIRA. What's the organisation I should speak to if I am not
from Sweden? (I'm Sydney based.)