PIV: signature output format

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

PIV: signature output format

Viktor TARASOV-2
Hi Douglas,

I'm trying to get signature with the PIV card and verify it with the 'openssl pkeyutl'.
I use EC key #04 "CARD AUTH Key".

It fails because of the 'raw' output format of the signature produced by OpenSC.
OpenSSL expects the signature as a ASN1 sequence of two integers.

I've seen in card-piv.c your comments:
https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/card-piv.c#L2023
>         /* The PIV returns a DER SEQUENCE{INTEGER, INTEGER}
>          * Which may have leading 00 to force positive
>          * TODO: -DEE should check if PKCS15 want the same

It seems that PKCS#15 really wants it.

>          * But PKCS11 just wants 2* filed_length in bytes
Can you explain more? Why it wants 'raw' data?

>          * So we have to strip out the integers
>          * if present and pad on left if too short.
>          */


I would propose to keep the ASN1 encoded data at the PKCS#15 level,
and, if needed, to convert it to the 'raw' format by dedicated procedure in the pkcs15 framework of pkcs11.

Kind regards,
Viktor.










--
Viktor Tarasov <[hidden email]>

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PIV: signature output format

Douglas E. Engert
Just back from vacation...

On 6/21/2012 9:50 AM, Viktor TARASOV wrote:

> Hi Douglas,
>
> I'm trying to get signature with the PIV card and verify it with the 'openssl pkeyutl'.
> I use EC key #04 "CARD AUTH Key".
>
> It fails because of the 'raw' output format of the signature produced by OpenSC.
> OpenSSL expects the signature as a ASN1 sequence of two integers.
>
> I've seen in card-piv.c your comments:
> https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/card-piv.c#L2023
>>          /* The PIV returns a DER SEQUENCE{INTEGER, INTEGER}
>>           * Which may have leading 00 to force positive
>>           * TODO: -DEE should check if PKCS15 want the same
>
> It seems that PKCS#15 really wants it.
>
>>           * But PKCS11 just wants 2* filed_length in bytes
> Can you explain more? Why it wants 'raw' data?

PKCS#11 v2.30: says:

    6.3.1 EC Signatures
    For the purposes of these mechanisms, an ECDSA signature is an octet string of even
    length which is at most two times nLen octets, where nLen is the length in octets of the
    base point order n. The signature octets correspond to the concatenation of the ECDSA
    values r and s, both represented as an octet string of equal length of at most nLen with the
    most significant byte first. If r and s have different octet length, the shorter of both must
    be padded with leading zero octets such that both have the same octet length.

PKCS#11 2.20 in Section 12.3.1 says the same as above.

PKCS#11 2.01 11.4.3 says basically the same thing, but assumes a fixed size of  nLen=20.

So PKCS#11 is not returning ASN1 but just the concatenation of r and s.

>
>>           * So we have to strip out the integers
>>           * if present and pad on left if too short.
>>           */
>
>
> I would propose to keep the ASN1 encoded data at the PKCS#15 level,
> and, if needed, to convert it to the 'raw' format by dedicated procedure in the pkcs15 framework of pkcs11.

Where do you see in PKCS#15 that a ECDSA signature is in ANS1?

If it needs to be ASN1, then yes the conversion could be done in the framework.


>
> Kind regards,
> Viktor.
>
>
>
>
>
>
>
>
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PIV: signature output format

Viktor Tarasov-3


On Mon, Jun 25, 2012 at 9:22 PM, Douglas E. Engert <[hidden email]> wrote:
Just back from vacation...


On 6/21/2012 9:50 AM, Viktor TARASOV wrote:
Hi Douglas,

I'm trying to get signature with the PIV card and verify it with the 'openssl pkeyutl'.
I use EC key #04 "CARD AUTH Key".

It fails because of the 'raw' output format of the signature produced by OpenSC.
OpenSSL expects the signature as a ASN1 sequence of two integers.

I've seen in card-piv.c your comments:
https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/card-piv.c#L2023
        /* The PIV returns a DER SEQUENCE{INTEGER, INTEGER}
         * Which may have leading 00 to force positive
         * TODO: -DEE should check if PKCS15 want the same

It seems that PKCS#15 really wants it.

         * But PKCS11 just wants 2* filed_length in bytes
Can you explain more? Why it wants 'raw' data?

PKCS#11 v2.30: says:

  6.3.1 EC Signatures
  For the purposes of these mechanisms, an ECDSA signature is an octet string of even
  length which is at most two times nLen octets, where nLen is the length in octets of the
  base point order n. The signature octets correspond to the concatenation of the ECDSA
  values r and s, both represented as an octet string of equal length of at most nLen with the
  most significant byte first. If r and s have different octet length, the shorter of both must
  be padded with leading zero octets such that both have the same octet length.

PKCS#11 2.20 in Section 12.3.1 says the same as above.

PKCS#11 2.01 11.4.3 says basically the same thing, but assumes a fixed size of  nLen=20.

So PKCS#11 is not returning ASN1 but just the concatenation of r and s.

Ok,  thanks.

         * So we have to strip out the integers
         * if present and pad on left if too short.
         */


I would propose to keep the ASN1 encoded data at the PKCS#15 level,
and, if needed, to convert it to the 'raw' format by dedicated procedure in the pkcs15 framework of pkcs11.

Where do you see in PKCS#15 that a ECDSA signature is in ANS1?
If it needs to be ASN1, then yes the conversion could be done in the framework.

Ok, there is no signature in ASN.1 in pkcs#15, but there some practical reasons.

The card itself (Oberthur's PIV) returns the signature encoded in ASN.1;
OpenSSL, for which the pkcs15-tool have to provide data in a suitable format, needs also the ASN.1 encoding.

So, my suggestion is to keep the encoding returned by the card at the pkcs#15 level,
and change it to the 'raw' mode on the pkcs#11 side.

Finally, I have no preference, if you prefer to keep it like it is now, we'll be living with.



Kind regards,
Viktor.











--

 Douglas E. Engert  <[hidden email]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439
 <a href="tel:%28630%29%20252-5444" value="+16302525444" target="_blank">(630) 252-5444




_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PIV: signature output format

Andreas Schwier (ML)
Hi Viktor and Douglas,

I do also favour to keep the DER signature format at the interface
between the card driver and the pkcs15 framework.

At the card driver level we don't know the field size, but we do at the
pkcs15 framework level. And all cards I know use the DER encoded
signature format anyway.

Maybe we can reuse Douglas code and do a conditional conversion in
sc_pkcs11_signature_final.

Andreas


Am 26.06.2012 08:06, schrieb Viktor Tarasov:

>
>
> On Mon, Jun 25, 2012 at 9:22 PM, Douglas E. Engert <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Just back from vacation...
>
>
>     On 6/21/2012 9:50 AM, Viktor TARASOV wrote:
>
>         Hi Douglas,
>
>         I'm trying to get signature with the PIV card and verify it
>         with the 'openssl pkeyutl'.
>         I use EC key #04 "CARD AUTH Key".
>
>         It fails because of the 'raw' output format of the signature
>         produced by OpenSC.
>         OpenSSL expects the signature as a ASN1 sequence of two integers.
>
>         I've seen in card-piv.c your comments:
>         https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/card-piv.c#L2023
>
>                     /* The PIV returns a DER SEQUENCE{INTEGER, INTEGER}
>                      * Which may have leading 00 to force positive
>                      * TODO: -DEE should check if PKCS15 want the same
>
>
>         It seems that PKCS#15 really wants it.
>
>                      * But PKCS11 just wants 2* filed_length in bytes
>
>         Can you explain more? Why it wants 'raw' data?
>
>
>     PKCS#11 v2.30: says:
>
>       6.3.1 EC Signatures
>       For the purposes of these mechanisms, an ECDSA signature is an
>     octet string of even
>       length which is at most two times nLen octets, where nLen is the
>     length in octets of the
>       base point order n. The signature octets correspond to the
>     concatenation of the ECDSA
>       values r and s, both represented as an octet string of equal
>     length of at most nLen with the
>       most significant byte first. If r and s have different octet
>     length, the shorter of both must
>       be padded with leading zero octets such that both have the same
>     octet length.
>
>     PKCS#11 2.20 in Section 12.3.1 says the same as above.
>
>     PKCS#11 2.01 11.4.3 says basically the same thing, but assumes a
>     fixed size of  nLen=20.
>
>     So PKCS#11 is not returning ASN1 but just the concatenation of r
>     and s.
>
>
> Ok,  thanks.
>
>                      * So we have to strip out the integers
>                      * if present and pad on left if too short.
>                      */
>
>
>
>         I would propose to keep the ASN1 encoded data at the PKCS#15
>         level,
>         and, if needed, to convert it to the 'raw' format by dedicated
>         procedure in the pkcs15 framework of pkcs11.
>
>
>     Where do you see in PKCS#15 that a ECDSA signature is in ANS1?
>     If it needs to be ASN1, then yes the conversion could be done in
>     the framework.
>
>
> Ok, there is no signature in ASN.1 in pkcs#15, but there some
> practical reasons.
>
> The card itself (Oberthur's PIV) returns the signature encoded in ASN.1;
> OpenSSL, for which the pkcs15-tool have to provide data in a suitable
> format, needs also the ASN.1 encoding.
>
> So, my suggestion is to keep the encoding returned by the card at the
> pkcs#15 level,
> and change it to the 'raw' mode on the pkcs#11 side.
>
> Finally, I have no preference, if you prefer to keep it like it is
> now, we'll be living with.
>
>
>
>         Kind regards,
>         Viktor.
>
>
>
>
>
>
>
>
>
>
>
>     --
>
>      Douglas E. Engert  <[hidden email] <mailto:[hidden email]>>
>      Argonne National Laboratory
>      9700 South Cass Avenue
>      Argonne, Illinois  60439
>      (630) 252-5444 <tel:%28630%29%20252-5444>
>
>
>
>
>
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel


--

    ---------    CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#       #|   Schülerweg 38
   |#       #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 171 8334920
    ---------    http://www.cardcontact.de
                 http://www.tscons.de
                 http://www.openscdp.org

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PIV: signature output format

Douglas E. Engert


On 8/11/2012 1:26 PM, Andreas Schwier (ML) wrote:
> Hi Viktor and Douglas,
>
> I do also favour to keep the DER signature format at the interface
> between the card driver and the pkcs15 framework.


OK, we could do that. I would like to wait till after 0.13.0 is released,
as the current code is working.

What is your scheduling requirements?


>
> At the card driver level we don't know the field size, but we do at the
> pkcs15 framework level. And all cards I know use the DER encoded
> signature format anyway.
>
> Maybe we can reuse Douglas code and do a conditional conversion in
> sc_pkcs11_signature_final.
>
> Andreas
>
>
> Am 26.06.2012 08:06, schrieb Viktor Tarasov:
>>
>>
>> On Mon, Jun 25, 2012 at 9:22 PM, Douglas E. Engert <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>      Just back from vacation...
>>
>>
>>      On 6/21/2012 9:50 AM, Viktor TARASOV wrote:
>>
>>          Hi Douglas,
>>
>>          I'm trying to get signature with the PIV card and verify it
>>          with the 'openssl pkeyutl'.
>>          I use EC key #04 "CARD AUTH Key".
>>
>>          It fails because of the 'raw' output format of the signature
>>          produced by OpenSC.
>>          OpenSSL expects the signature as a ASN1 sequence of two integers.
>>
>>          I've seen in card-piv.c your comments:
>>          https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/card-piv.c#L2023
>>
>>                      /* The PIV returns a DER SEQUENCE{INTEGER, INTEGER}
>>                       * Which may have leading 00 to force positive
>>                       * TODO: -DEE should check if PKCS15 want the same
>>
>>
>>          It seems that PKCS#15 really wants it.
>>
>>                       * But PKCS11 just wants 2* filed_length in bytes
>>
>>          Can you explain more? Why it wants 'raw' data?
>>
>>
>>      PKCS#11 v2.30: says:
>>
>>        6.3.1 EC Signatures
>>        For the purposes of these mechanisms, an ECDSA signature is an
>>      octet string of even
>>        length which is at most two times nLen octets, where nLen is the
>>      length in octets of the
>>        base point order n. The signature octets correspond to the
>>      concatenation of the ECDSA
>>        values r and s, both represented as an octet string of equal
>>      length of at most nLen with the
>>        most significant byte first. If r and s have different octet
>>      length, the shorter of both must
>>        be padded with leading zero octets such that both have the same
>>      octet length.
>>
>>      PKCS#11 2.20 in Section 12.3.1 says the same as above.
>>
>>      PKCS#11 2.01 11.4.3 says basically the same thing, but assumes a
>>      fixed size of  nLen=20.
>>
>>      So PKCS#11 is not returning ASN1 but just the concatenation of r
>>      and s.
>>
>>
>> Ok,  thanks.
>>
>>                       * So we have to strip out the integers
>>                       * if present and pad on left if too short.
>>                       */
>>
>>
>>
>>          I would propose to keep the ASN1 encoded data at the PKCS#15
>>          level,
>>          and, if needed, to convert it to the 'raw' format by dedicated
>>          procedure in the pkcs15 framework of pkcs11.
>>
>>
>>      Where do you see in PKCS#15 that a ECDSA signature is in ANS1?
>>      If it needs to be ASN1, then yes the conversion could be done in
>>      the framework.
>>
>>
>> Ok, there is no signature in ASN.1 in pkcs#15, but there some
>> practical reasons.
>>
>> The card itself (Oberthur's PIV) returns the signature encoded in ASN.1;
>> OpenSSL, for which the pkcs15-tool have to provide data in a suitable
>> format, needs also the ASN.1 encoding.
>>
>> So, my suggestion is to keep the encoding returned by the card at the
>> pkcs#15 level,
>> and change it to the 'raw' mode on the pkcs#11 side.
>>
>> Finally, I have no preference, if you prefer to keep it like it is
>> now, we'll be living with.
>>
>>
>>
>>          Kind regards,
>>          Viktor.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>      --
>>
>>       Douglas E. Engert  <[hidden email] <mailto:[hidden email]>>
>>       Argonne National Laboratory
>>       9700 South Cass Avenue
>>       Argonne, Illinois  60439
>>       (630) 252-5444 <tel:%28630%29%20252-5444>
>>
>>
>>
>>
>>
>> _______________________________________________
>> opensc-devel mailing list
>> [hidden email]
>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PIV: signature output format

Andreas Schwier
Hi Douglas,

I'm fine with that. I already changed our card driver to provide the
r||s format anyway.

After 0.13.0 we should work on the issue.

Did anyone already considered implementing support for PKCS#1 PSS format ?

We have support for it in the SmartCard-HSM and want to add it to OpenSC.

Andreas

Am 13.08.2012 00:45, schrieb Douglas E. Engert:

>
> On 8/11/2012 1:26 PM, Andreas Schwier (ML) wrote:
>> Hi Viktor and Douglas,
>>
>> I do also favour to keep the DER signature format at the interface
>> between the card driver and the pkcs15 framework.
>
> OK, we could do that. I would like to wait till after 0.13.0 is released,
> as the current code is working.
>
> What is your scheduling requirements?
>
>
>> At the card driver level we don't know the field size, but we do at the
>> pkcs15 framework level. And all cards I know use the DER encoded
>> signature format anyway.
>>
>> Maybe we can reuse Douglas code and do a conditional conversion in
>> sc_pkcs11_signature_final.
>>
>> Andreas
>>
>>
>> Am 26.06.2012 08:06, schrieb Viktor Tarasov:
>>>
>>> On Mon, Jun 25, 2012 at 9:22 PM, Douglas E. Engert <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>>      Just back from vacation...
>>>
>>>
>>>      On 6/21/2012 9:50 AM, Viktor TARASOV wrote:
>>>
>>>          Hi Douglas,
>>>
>>>          I'm trying to get signature with the PIV card and verify it
>>>          with the 'openssl pkeyutl'.
>>>          I use EC key #04 "CARD AUTH Key".
>>>
>>>          It fails because of the 'raw' output format of the signature
>>>          produced by OpenSC.
>>>          OpenSSL expects the signature as a ASN1 sequence of two integers.
>>>
>>>          I've seen in card-piv.c your comments:
>>>          https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/card-piv.c#L2023
>>>
>>>                      /* The PIV returns a DER SEQUENCE{INTEGER, INTEGER}
>>>                       * Which may have leading 00 to force positive
>>>                       * TODO: -DEE should check if PKCS15 want the same
>>>
>>>
>>>          It seems that PKCS#15 really wants it.
>>>
>>>                       * But PKCS11 just wants 2* filed_length in bytes
>>>
>>>          Can you explain more? Why it wants 'raw' data?
>>>
>>>
>>>      PKCS#11 v2.30: says:
>>>
>>>        6.3.1 EC Signatures
>>>        For the purposes of these mechanisms, an ECDSA signature is an
>>>      octet string of even
>>>        length which is at most two times nLen octets, where nLen is the
>>>      length in octets of the
>>>        base point order n. The signature octets correspond to the
>>>      concatenation of the ECDSA
>>>        values r and s, both represented as an octet string of equal
>>>      length of at most nLen with the
>>>        most significant byte first. If r and s have different octet
>>>      length, the shorter of both must
>>>        be padded with leading zero octets such that both have the same
>>>      octet length.
>>>
>>>      PKCS#11 2.20 in Section 12.3.1 says the same as above.
>>>
>>>      PKCS#11 2.01 11.4.3 says basically the same thing, but assumes a
>>>      fixed size of  nLen=20.
>>>
>>>      So PKCS#11 is not returning ASN1 but just the concatenation of r
>>>      and s.
>>>
>>>
>>> Ok,  thanks.
>>>
>>>                       * So we have to strip out the integers
>>>                       * if present and pad on left if too short.
>>>                       */
>>>
>>>
>>>
>>>          I would propose to keep the ASN1 encoded data at the PKCS#15
>>>          level,
>>>          and, if needed, to convert it to the 'raw' format by dedicated
>>>          procedure in the pkcs15 framework of pkcs11.
>>>
>>>
>>>      Where do you see in PKCS#15 that a ECDSA signature is in ANS1?
>>>      If it needs to be ASN1, then yes the conversion could be done in
>>>      the framework.
>>>
>>>
>>> Ok, there is no signature in ASN.1 in pkcs#15, but there some
>>> practical reasons.
>>>
>>> The card itself (Oberthur's PIV) returns the signature encoded in ASN.1;
>>> OpenSSL, for which the pkcs15-tool have to provide data in a suitable
>>> format, needs also the ASN.1 encoding.
>>>
>>> So, my suggestion is to keep the encoding returned by the card at the
>>> pkcs#15 level,
>>> and change it to the 'raw' mode on the pkcs#11 side.
>>>
>>> Finally, I have no preference, if you prefer to keep it like it is
>>> now, we'll be living with.
>>>
>>>
>>>
>>>          Kind regards,
>>>          Viktor.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>      --
>>>
>>>       Douglas E. Engert  <[hidden email] <mailto:[hidden email]>>
>>>       Argonne National Laboratory
>>>       9700 South Cass Avenue
>>>       Argonne, Illinois  60439
>>>       (630) 252-5444 <tel:%28630%29%20252-5444>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> opensc-devel mailing list
>>> [hidden email]
>>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>>


--

    ---------    CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#       #|   Schülerweg 38
   |#       #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 171 8334920
    ---------    http://www.cardcontact.de
                 http://www.tscons.de
                 http://www.openscdp.org

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PIV: signature output format

Douglas E. Engert


On 8/13/2012 3:00 AM, Andreas Schwier wrote:
> Hi Douglas,
>
> I'm fine with that. I already changed our card driver to provide the
> r||s format anyway.
>
> After 0.13.0 we should work on the issue.
>
> Did anyone already considered implementing support for PKCS#1 PSS format ?

Not that I know of. Cards that do support padding on the card may need changes
to the card driver modules to take advantage of PSS.

For the PIV all padding is done in by the calling application
or by the OpenSC software if OpenSSL is used. The PIV card
supports only the RSA RAW operation, so it has not been an issue
so far. NIST 800-78-2 says PSS it is an acceptable padding to use.

>
> We have support for it in the SmartCard-HSM and want to add it to OpenSC.
>
> Andreas
>
> Am 13.08.2012 00:45, schrieb Douglas E. Engert:
>>
>> On 8/11/2012 1:26 PM, Andreas Schwier (ML) wrote:
>>> Hi Viktor and Douglas,
>>>
>>> I do also favour to keep the DER signature format at the interface
>>> between the card driver and the pkcs15 framework.
>>
>> OK, we could do that. I would like to wait till after 0.13.0 is released,
>> as the current code is working.
>>
>> What is your scheduling requirements?
>>
>>
>>> At the card driver level we don't know the field size, but we do at the
>>> pkcs15 framework level. And all cards I know use the DER encoded
>>> signature format anyway.
>>>
>>> Maybe we can reuse Douglas code and do a conditional conversion in
>>> sc_pkcs11_signature_final.
>>>
>>> Andreas
>>>
>>>
>>> Am 26.06.2012 08:06, schrieb Viktor Tarasov:
>>>>
>>>> On Mon, Jun 25, 2012 at 9:22 PM, Douglas E. Engert <[hidden email]
>>>> <mailto:[hidden email]>> wrote:
>>>>
>>>>       Just back from vacation...
>>>>
>>>>
>>>>       On 6/21/2012 9:50 AM, Viktor TARASOV wrote:
>>>>
>>>>           Hi Douglas,
>>>>
>>>>           I'm trying to get signature with the PIV card and verify it
>>>>           with the 'openssl pkeyutl'.
>>>>           I use EC key #04 "CARD AUTH Key".
>>>>
>>>>           It fails because of the 'raw' output format of the signature
>>>>           produced by OpenSC.
>>>>           OpenSSL expects the signature as a ASN1 sequence of two integers.
>>>>
>>>>           I've seen in card-piv.c your comments:
>>>>           https://github.com/OpenSC/OpenSC/blob/staging/src/libopensc/card-piv.c#L2023
>>>>
>>>>                       /* The PIV returns a DER SEQUENCE{INTEGER, INTEGER}
>>>>                        * Which may have leading 00 to force positive
>>>>                        * TODO: -DEE should check if PKCS15 want the same
>>>>
>>>>
>>>>           It seems that PKCS#15 really wants it.
>>>>
>>>>                        * But PKCS11 just wants 2* filed_length in bytes
>>>>
>>>>           Can you explain more? Why it wants 'raw' data?
>>>>
>>>>
>>>>       PKCS#11 v2.30: says:
>>>>
>>>>         6.3.1 EC Signatures
>>>>         For the purposes of these mechanisms, an ECDSA signature is an
>>>>       octet string of even
>>>>         length which is at most two times nLen octets, where nLen is the
>>>>       length in octets of the
>>>>         base point order n. The signature octets correspond to the
>>>>       concatenation of the ECDSA
>>>>         values r and s, both represented as an octet string of equal
>>>>       length of at most nLen with the
>>>>         most significant byte first. If r and s have different octet
>>>>       length, the shorter of both must
>>>>         be padded with leading zero octets such that both have the same
>>>>       octet length.
>>>>
>>>>       PKCS#11 2.20 in Section 12.3.1 says the same as above.
>>>>
>>>>       PKCS#11 2.01 11.4.3 says basically the same thing, but assumes a
>>>>       fixed size of  nLen=20.
>>>>
>>>>       So PKCS#11 is not returning ASN1 but just the concatenation of r
>>>>       and s.
>>>>
>>>>
>>>> Ok,  thanks.
>>>>
>>>>                        * So we have to strip out the integers
>>>>                        * if present and pad on left if too short.
>>>>                        */
>>>>
>>>>
>>>>
>>>>           I would propose to keep the ASN1 encoded data at the PKCS#15
>>>>           level,
>>>>           and, if needed, to convert it to the 'raw' format by dedicated
>>>>           procedure in the pkcs15 framework of pkcs11.
>>>>
>>>>
>>>>       Where do you see in PKCS#15 that a ECDSA signature is in ANS1?
>>>>       If it needs to be ASN1, then yes the conversion could be done in
>>>>       the framework.
>>>>
>>>>
>>>> Ok, there is no signature in ASN.1 in pkcs#15, but there some
>>>> practical reasons.
>>>>
>>>> The card itself (Oberthur's PIV) returns the signature encoded in ASN.1;
>>>> OpenSSL, for which the pkcs15-tool have to provide data in a suitable
>>>> format, needs also the ASN.1 encoding.
>>>>
>>>> So, my suggestion is to keep the encoding returned by the card at the
>>>> pkcs#15 level,
>>>> and change it to the 'raw' mode on the pkcs#11 side.
>>>>
>>>> Finally, I have no preference, if you prefer to keep it like it is
>>>> now, we'll be living with.
>>>>
>>>>
>>>>
>>>>           Kind regards,
>>>>           Viktor.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>       --
>>>>
>>>>        Douglas E. Engert  <[hidden email] <mailto:[hidden email]>>
>>>>        Argonne National Laboratory
>>>>        9700 South Cass Avenue
>>>>        Argonne, Illinois  60439
>>>>        (630) 252-5444 <tel:%28630%29%20252-5444>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> opensc-devel mailing list
>>>> [hidden email]
>>>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>>>
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel