Hi Douglas,
see below.
Andreas
Am 20.09.2012 17:12, schrieb Douglas E. Engert:
>
> On 9/19/2012 6:11 PM, Andreas Schwier (ML) wrote:
>> Dear all,
>>
>> we've come across a strange behaviour of the pkcs15-lib in OpenSC when
>> we generate an EC key pair:
>>
>> After generating an fresh EC key pair, our code returns a
>> sc_pkcs15_pubkey containing the EC public key and DER encoded domain
>> parameter. The public key is then encoded in sc_pkcs15init_generate_key
>> and added to the DF in the framework when it's immediately decoded again.
>>
>> During this encode / decode step the domain parameter are lost.
> Looked at PKCS#15 v1.1 section 6.4.3 The value is a EC_PubKeyChoice, that
> can be a raw ECPoint or a spki SubjectPublicKeyInfo.
>
> It looks like the sc_pkcs15_encode_pubkey_ec is just returning the
> ECPoint.
>
> sc_pkcs15_decode_pubkey_ec is also assuming the ECPoint.
>
> It looks like that code has never been fully tested, and the
> above code should be modified to use the spki SubjectPublicKeyInfo
> if there are domain parameters.
>
> With the EC work I have done in OpenSC including writing the above two
> routines, I have not looked at the pkcs15init code at all, as the PIV
> card is not a PKCS#15 card but rather the PKCS#15 is emulated, and the
> emulation layer is base on the decoded entries. The PIV does not use the
> pkcs15init code at all, but rather a special pivtool can be used for test
> cards to generate a key. It also turns out that the PIV card does not store
> a pubkey object at all, but derives the pubkey from the certificate.
>
>> I'm wondering why this encode / decode step is done ?
> No one has a PKCS#15 cards that support EC to test this part of the code.
We do have a card that supports EC ;-)
>
>> If it is required for some reason, then I would rather encode the public
>> key in SubjectPublicKey structure that would also preserve the domain
>> parameter in AlgorithmIdentifier.
> Can you come up with a patch?
Yes, we can certainly do that. I just wanted to make sure that I
understand the rational behind the current implementation.
>
>> Andreas
>>
--
--------- CardContact Software & System Consulting
|.##> <##.| Andreas Schwier
|# #| Schülerweg 38
|# #| 32429 Minden, Germany
|'##> <##'| Phone +49 571 56149
--------- http://www.cardcontact.de
http://www.tscons.de
http://www.openscdp.org
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
