On 10/23/2013 5:13 PM, CardContact Software & System Consulting wrote:
> In src/libopensc/pkcs15-pubkey.c:
>
>>
>> -	r = sc_asn1_encode(ctx, asn1_ec_pointQ, buf, buflen);
>
> I don't quite understand why you change from encode to decode ?

The code was originally written to be used with PKCS#11 and non-PKCS#15 type cards.
Since then others have added code to pkcs15init routines.

For EC keys, PKCS#11 attribute CKA_EC_POINT is a "DER-encoding of a X9.62 ECPoint value P"

But in a spki the ECPoint is stored in a ASN1 bit string.

In the OpenSC code the ecPoint was stored as a ANS.1 octet string, which can be
returned for PKCS#11 without doing an encoding.  But to get the ECpoint out of the
octet string so it can be placed in a bit string, requires a decode from octet string.

That is very confusing, partly because PKCS#15 does not define how the ECPoint should
be stored. And then what does it mean to encode the ECpoint?

With a true PKCS#15 card, what does the card return as the ECpoint?

With a PIV card, when a EC key is generated on the card, the operation
returns a TLV with the value "04||X||Y". Which is ECpoint in uncompressed format,
and X and Y may have leading zeros.

What should probable be done, is to store in the sc_pkcs15_pubkey not an ASN.1 version
of the ECpoint, but the actually bytes and length and then fix up the code in pkcs15init
too.

>
> This breaks the encoding of a newly generated public key in sc_pkcs15init_generate_key().

As I said, the way to encode/decode an ECpoint is confusing, and the line of code
you point out could also be a bug. (I don't have true PKCS#15 cards to test with.)

Do you have some code changes, or debugging traces showing the problem?



>
> —
> Reply to this email directly or view it on GitHub <https://github.com/OpenSC/OpenSC/pull/191/files#r7173705>.
>

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444