Problems with MyEID and fundamental changes to the storing of the ECC ecpointQ

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

Problems with MyEID and fundamental changes to the storing of the ECC ecpointQ

Douglas E. Engert
During the discussion on pull request #191 "Enhanced ECC handling (#191)"
It has become apparent that:

    Commit 457426543dfa02597895d57013dde94cc9e7d038
    Author: sjoblomt <[hidden email]>  2012-11-28 04:52:43
    Committer: Viktor Tarasov <[hidden email]>  2012-12-03 07:37:13
    "MyEID ECDSA Support"

had made a fundamental change in the way the ecpointQ was stored.

The previous code stored the ecpointQ as an ANS1 DER OCTET_STRING,
and the decode and encode routines in pkcs15-pubkey.c just copied
the DER encoding.

Comments in pkcs15-pubkey.c had:

   /*
    * We are storing the ec_pointQ as a octet string.
    * Thus we will just copy the string.
    * But to get the field length we decode it.
    */

pkcs15.h had:
   sc_pkcs15_der_t    ecpointQ; /* note this is der */

The "myEID ECDSA Support" changed the way the ecpointQ was stored
from an ASN1 DER OCTET STRING to just storing "an arbitrary
string of octets (eight-bit values)" i.e. the value of the
ASN1 DER OCTET STRING.

I have issues with how the "myEID  ECDSA Support"  was handled:

   * This change was made at the last minute before the 0.13.0 release.

   * No questions or comments were posted to the mailing list
     to ask why the ecpointQ was stored as DER.

   * No comments where made to the mailing list that this
     fundamental change was made.

   * No changes where made to the comments to indicate
     only the value of the ecpointQ was being stored.
     The coments still indicate DER.

   * No attempt was made to change the other two card drivers
     that supported EC was made.

   * This broke the SmartCard-HSM code. CardContact Software & System Consulting
     reported: "Yes, I remember I even complained about this last minute change
     for the 0.13 release, because it broke our SmartCard-HSM code..."

The myEID changes did not break the PIV code right away, as the PIV kept
storing and using the ecpointQ as a DER OCTET STRING. But newer changes
such as Pull request #191 "Enhanced ECC handling" ran into the
problems with how the ecpointQ was now being stored.

Because of all of this,

  (1) I am withdrawing the #191 pull request for now, so it can be rewritten.

  (2) I intend to proposed changes to continue to store the ecpointQ
      as the value of the DER encoding as it is the more straight forward way.
      I will also fix up the comments to point this out...

  (3) I intend to submit changes to the PIV card driver and any other code
      that depends on how the ecpointQ is stored.

  (4) Resubmit a modified "Enhanced ECC handling".

We as a project, when we submit code changes like this, the changes need a
good explanation of what code is being changed and what issues might
arise from the changes, especially if:

  * Some code used by everyone is being changed in some fundamental way.

  * Some code might effect card drivers that the author of the change can not test.



Comments?

--

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

------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problems with MyEID and fundamental changes to the storing of the ECC ecpointQ

Andreas Schwier (ML)
Hi Douglas,

I fully agree with your position, however I think the current encoding
based on X9.62 chapter A.5.7 should remain rather than changing again to
the ECPoint DER encoding from chapter E.6 of the same standard.

It's much easier to convert from the current octet string encoding to
ECPoint or BITSTRING (SPKI) or Tag 86 (CVCs).

Andreas

On 11/04/2013 08:54 PM, Douglas E. Engert wrote:

> During the discussion on pull request #191 "Enhanced ECC handling (#191)"
> It has become apparent that:
>
>     Commit 457426543dfa02597895d57013dde94cc9e7d038
>     Author: sjoblomt <[hidden email]>  2012-11-28 04:52:43
>     Committer: Viktor Tarasov <[hidden email]>  2012-12-03 07:37:13
>     "MyEID ECDSA Support"
>
> had made a fundamental change in the way the ecpointQ was stored.
>
> The previous code stored the ecpointQ as an ANS1 DER OCTET_STRING,
> and the decode and encode routines in pkcs15-pubkey.c just copied
> the DER encoding.
>
> Comments in pkcs15-pubkey.c had:
>
>    /*
>     * We are storing the ec_pointQ as a octet string.
>     * Thus we will just copy the string.
>     * But to get the field length we decode it.
>     */
>
> pkcs15.h had:
>    sc_pkcs15_der_t    ecpointQ; /* note this is der */
>
> The "myEID ECDSA Support" changed the way the ecpointQ was stored
> from an ASN1 DER OCTET STRING to just storing "an arbitrary
> string of octets (eight-bit values)" i.e. the value of the
> ASN1 DER OCTET STRING.
>
> I have issues with how the "myEID  ECDSA Support"  was handled:
>
>    * This change was made at the last minute before the 0.13.0 release.
>
>    * No questions or comments were posted to the mailing list
>      to ask why the ecpointQ was stored as DER.
>
>    * No comments where made to the mailing list that this
>      fundamental change was made.
>
>    * No changes where made to the comments to indicate
>      only the value of the ecpointQ was being stored.
>      The coments still indicate DER.
>
>    * No attempt was made to change the other two card drivers
>      that supported EC was made.
>
>    * This broke the SmartCard-HSM code. CardContact Software & System Consulting
>      reported: "Yes, I remember I even complained about this last minute change
>      for the 0.13 release, because it broke our SmartCard-HSM code..."
>
> The myEID changes did not break the PIV code right away, as the PIV kept
> storing and using the ecpointQ as a DER OCTET STRING. But newer changes
> such as Pull request #191 "Enhanced ECC handling" ran into the
> problems with how the ecpointQ was now being stored.
>
> Because of all of this,
>
>   (1) I am withdrawing the #191 pull request for now, so it can be rewritten.
>
>   (2) I intend to proposed changes to continue to store the ecpointQ
>       as the value of the DER encoding as it is the more straight forward way.
>       I will also fix up the comments to point this out...
>
>   (3) I intend to submit changes to the PIV card driver and any other code
>       that depends on how the ecpointQ is stored.
>
>   (4) Resubmit a modified "Enhanced ECC handling".
>
> We as a project, when we submit code changes like this, the changes need a
> good explanation of what code is being changed and what issues might
> arise from the changes, especially if:
>
>   * Some code used by everyone is being changed in some fundamental way.
>
>   * Some code might effect card drivers that the author of the change can not test.
>
>
>
> Comments?
>


------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problems with MyEID and fundamental changes to the storing of the ECC ecpointQ

Douglas E. Engert


On 11/5/2013 7:48 AM, Andreas Schwier wrote:
> Hi Douglas,
>
> I fully agree with your position, however I think the current encoding
> based on X9.62 chapter A.5.7 should remain rather than changing again to
> the ECPoint DER encoding from chapter E.6 of the same standard.

I believe that is what I said in (2) below:
   "I intend to proposed changes to continue to store the ecpointQ
    as the *value* of the DER encoding as it is the more straight forward way."

By "continue" I meant to use what is the git master, but change the comments
as there is also a problem of semantics, as "octet string" could refer to a
a ASN1 DER OCTET STRING or to its value, especially as it is defined as:
sc_pkcs15_der_t    ecpointQ; /* note this is der */
With der being uses twice.

For an uncompressed ecpointQ  "04||X||Y" with a 256 bit curve would have a
length of 1+32+32 = 65 bytes. A 394 bit curve would have length 1+48+48=97

>
> It's much easier to convert from the current octet string encoding to
> ECPoint or BITSTRING (SPKI) or Tag 86 (CVCs).

Yes, I should have done that with the original ECC code.

>
> Andreas
>
> On 11/04/2013 08:54 PM, Douglas E. Engert wrote:
>> During the discussion on pull request #191 "Enhanced ECC handling (#191)"
>> It has become apparent that:
>>
>>      Commit 457426543dfa02597895d57013dde94cc9e7d038
>>      Author: sjoblomt <[hidden email]>  2012-11-28 04:52:43
>>      Committer: Viktor Tarasov <[hidden email]>  2012-12-03 07:37:13
>>      "MyEID ECDSA Support"
>>
>> had made a fundamental change in the way the ecpointQ was stored.
>>
>> The previous code stored the ecpointQ as an ANS1 DER OCTET_STRING,
>> and the decode and encode routines in pkcs15-pubkey.c just copied
>> the DER encoding.
>>
>> Comments in pkcs15-pubkey.c had:
>>
>>     /*
>>      * We are storing the ec_pointQ as a octet string.
>>      * Thus we will just copy the string.
>>      * But to get the field length we decode it.
>>      */
>>
>> pkcs15.h had:
>>     sc_pkcs15_der_t    ecpointQ; /* note this is der */
>>
>> The "myEID ECDSA Support" changed the way the ecpointQ was stored
>> from an ASN1 DER OCTET STRING to just storing "an arbitrary
>> string of octets (eight-bit values)" i.e. the value of the
>> ASN1 DER OCTET STRING.
>>
>> I have issues with how the "myEID  ECDSA Support"  was handled:
>>
>>     * This change was made at the last minute before the 0.13.0 release.
>>
>>     * No questions or comments were posted to the mailing list
>>       to ask why the ecpointQ was stored as DER.
>>
>>     * No comments where made to the mailing list that this
>>       fundamental change was made.
>>
>>     * No changes where made to the comments to indicate
>>       only the value of the ecpointQ was being stored.
>>       The coments still indicate DER.
>>
>>     * No attempt was made to change the other two card drivers
>>       that supported EC was made.
>>
>>     * This broke the SmartCard-HSM code. CardContact Software & System Consulting
>>       reported: "Yes, I remember I even complained about this last minute change
>>       for the 0.13 release, because it broke our SmartCard-HSM code..."
>>
>> The myEID changes did not break the PIV code right away, as the PIV kept
>> storing and using the ecpointQ as a DER OCTET STRING. But newer changes
>> such as Pull request #191 "Enhanced ECC handling" ran into the
>> problems with how the ecpointQ was now being stored.
>>
>> Because of all of this,
>>
>>    (1) I am withdrawing the #191 pull request for now, so it can be rewritten.
>>
>>    (2) I intend to proposed changes to continue to store the ecpointQ
>>        as the value of the DER encoding as it is the more straight forward way.
>>        I will also fix up the comments to point this out...
>>
>>    (3) I intend to submit changes to the PIV card driver and any other code
>>        that depends on how the ecpointQ is stored.
>>
>>    (4) Resubmit a modified "Enhanced ECC handling".
>>
>> We as a project, when we submit code changes like this, the changes need a
>> good explanation of what code is being changed and what issues might
>> arise from the changes, especially if:
>>
>>    * Some code used by everyone is being changed in some fundamental way.
>>
>>    * Some code might effect card drivers that the author of the change can not test.
>>
>>
>>
>> Comments?
>>
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

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

------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problems with MyEID and fundamental changes to the storing of the ECC ecpointQ

Douglas E. Engert
Please see pull request #194, https://github.com/OpenSC/OpenSC/pull/194
This address the ecpointQ issues as outlined below.

It partially addresses the issue that EC parameters are stored in two places.

It stores the ecpointQ as raw in the pubkey->ec.u.ecpointQ, and stored it in
DER in pubkey->data. Note the framework-pkcs15.c will use the pubkey->data
for the CKA_EC_POINT attribute.

I think it will address Tim's issues with using the pubkey from a certificate
with PIV cards, as the problem was related.

Comments?


On 11/5/2013 8:28 AM, Douglas E. Engert wrote:

>
>
> On 11/5/2013 7:48 AM, Andreas Schwier wrote:
>> Hi Douglas,
>>
>> I fully agree with your position, however I think the current encoding
>> based on X9.62 chapter A.5.7 should remain rather than changing again to
>> the ECPoint DER encoding from chapter E.6 of the same standard.
>
> I believe that is what I said in (2) below:
>     "I intend to proposed changes to continue to store the ecpointQ
>      as the *value* of the DER encoding as it is the more straight forward way."
>
> By "continue" I meant to use what is the git master, but change the comments
> as there is also a problem of semantics, as "octet string" could refer to a
> a ASN1 DER OCTET STRING or to its value, especially as it is defined as:
> sc_pkcs15_der_t    ecpointQ; /* note this is der */
> With der being uses twice.
>
> For an uncompressed ecpointQ  "04||X||Y" with a 256 bit curve would have a
> length of 1+32+32 = 65 bytes. A 384 bit curve would have length 1+48+48=97
>
>>
>> It's much easier to convert from the current octet string encoding to
>> ECPoint or BITSTRING (SPKI) or Tag 86 (CVCs).
>
> Yes, I should have done that with the original ECC code.
>
>>
>> Andreas
>>
>> On 11/04/2013 08:54 PM, Douglas E. Engert wrote:
>>> During the discussion on pull request #191 "Enhanced ECC handling (#191)"
>>> It has become apparent that:
>>>
>>>       Commit 457426543dfa02597895d57013dde94cc9e7d038
>>>       Author: sjoblomt <[hidden email]>  2012-11-28 04:52:43
>>>       Committer: Viktor Tarasov <[hidden email]>  2012-12-03 07:37:13
>>>       "MyEID ECDSA Support"
>>>
>>> had made a fundamental change in the way the ecpointQ was stored.
>>>
>>> The previous code stored the ecpointQ as an ANS1 DER OCTET_STRING,
>>> and the decode and encode routines in pkcs15-pubkey.c just copied
>>> the DER encoding.
>>>
>>> Comments in pkcs15-pubkey.c had:
>>>
>>>      /*
>>>       * We are storing the ec_pointQ as a octet string.
>>>       * Thus we will just copy the string.
>>>       * But to get the field length we decode it.
>>>       */
>>>
>>> pkcs15.h had:
>>>      sc_pkcs15_der_t    ecpointQ; /* note this is der */
>>>
>>> The "myEID ECDSA Support" changed the way the ecpointQ was stored
>>> from an ASN1 DER OCTET STRING to just storing "an arbitrary
>>> string of octets (eight-bit values)" i.e. the value of the
>>> ASN1 DER OCTET STRING.
>>>
>>> I have issues with how the "myEID  ECDSA Support"  was handled:
>>>
>>>      * This change was made at the last minute before the 0.13.0 release.
>>>
>>>      * No questions or comments were posted to the mailing list
>>>        to ask why the ecpointQ was stored as DER.
>>>
>>>      * No comments where made to the mailing list that this
>>>        fundamental change was made.
>>>
>>>      * No changes where made to the comments to indicate
>>>        only the value of the ecpointQ was being stored.
>>>        The coments still indicate DER.
>>>
>>>      * No attempt was made to change the other two card drivers
>>>        that supported EC was made.
>>>
>>>      * This broke the SmartCard-HSM code. CardContact Software & System Consulting
>>>        reported: "Yes, I remember I even complained about this last minute change
>>>        for the 0.13 release, because it broke our SmartCard-HSM code..."
>>>
>>> The myEID changes did not break the PIV code right away, as the PIV kept
>>> storing and using the ecpointQ as a DER OCTET STRING. But newer changes
>>> such as Pull request #191 "Enhanced ECC handling" ran into the
>>> problems with how the ecpointQ was now being stored.
>>>
>>> Because of all of this,
>>>
>>>     (1) I am withdrawing the #191 pull request for now, so it can be rewritten.
>>>
>>>     (2) I intend to proposed changes to continue to store the ecpointQ
>>>         as the value of the DER encoding as it is the more straight forward way.
>>>         I will also fix up the comments to point this out...
>>>
>>>     (3) I intend to submit changes to the PIV card driver and any other code
>>>         that depends on how the ecpointQ is stored.
>>>
>>>     (4) Resubmit a modified "Enhanced ECC handling".
>>>
>>> We as a project, when we submit code changes like this, the changes need a
>>> good explanation of what code is being changed and what issues might
>>> arise from the changes, especially if:
>>>
>>>     * Some code used by everyone is being changed in some fundamental way.
>>>
>>>     * Some code might effect card drivers that the author of the change can not test.
>>>
>>>
>>>
>>> Comments?
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> November Webinars for C, C++, Fortran Developers
>> Accelerate application performance with scalable programming models. Explore
>> techniques for threading, error checking, porting, and tuning. Get the most
>> from the latest Intel processors and coprocessors. See abstracts and register
>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Opensc-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>

--

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

------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problems with MyEID and fundamental changes to the storing of the ECC ecpointQ

Douglas E. Engert
I have not heard anything from the MyEID developers. The discussion of the
problem started on 11/04/13, last week.

Unless I here anything, I plain on committing #194 tomorrow, 11/12/13.


On 11/6/2013 5:01 PM, Douglas E. Engert wrote:

> Please see pull request #194, https://github.com/OpenSC/OpenSC/pull/194
> This address the ecpointQ issues as outlined below.
>
> It partially addresses the issue that EC parameters are stored in two places.
>
> It stores the ecpointQ as raw in the pubkey->ec.u.ecpointQ, and stored it in
> DER in pubkey->data. Note the framework-pkcs15.c will use the pubkey->data
> for the CKA_EC_POINT attribute.
>
> I think it will address Tim's issues with using the pubkey from a certificate
> with PIV cards, as the problem was related.
>
> Comments?
>
>
> On 11/5/2013 8:28 AM, Douglas E. Engert wrote:
>>
>>
>> On 11/5/2013 7:48 AM, Andreas Schwier wrote:
>>> Hi Douglas,
>>>
>>> I fully agree with your position, however I think the current encoding
>>> based on X9.62 chapter A.5.7 should remain rather than changing again to
>>> the ECPoint DER encoding from chapter E.6 of the same standard.
>>
>> I believe that is what I said in (2) below:
>>      "I intend to proposed changes to continue to store the ecpointQ
>>       as the *value* of the DER encoding as it is the more straight forward way."
>>
>> By "continue" I meant to use what is the git master, but change the comments
>> as there is also a problem of semantics, as "octet string" could refer to a
>> a ASN1 DER OCTET STRING or to its value, especially as it is defined as:
>> sc_pkcs15_der_t    ecpointQ; /* note this is der */
>> With der being uses twice.
>>
>> For an uncompressed ecpointQ  "04||X||Y" with a 256 bit curve would have a
>> length of 1+32+32 = 65 bytes. A 384 bit curve would have length 1+48+48=97
>>
>>>
>>> It's much easier to convert from the current octet string encoding to
>>> ECPoint or BITSTRING (SPKI) or Tag 86 (CVCs).
>>
>> Yes, I should have done that with the original ECC code.
>>
>>>
>>> Andreas
>>>
>>> On 11/04/2013 08:54 PM, Douglas E. Engert wrote:
>>>> During the discussion on pull request #191 "Enhanced ECC handling (#191)"
>>>> It has become apparent that:
>>>>
>>>>        Commit 457426543dfa02597895d57013dde94cc9e7d038
>>>>        Author: sjoblomt <[hidden email]>  2012-11-28 04:52:43
>>>>        Committer: Viktor Tarasov <[hidden email]>  2012-12-03 07:37:13
>>>>        "MyEID ECDSA Support"
>>>>
>>>> had made a fundamental change in the way the ecpointQ was stored.
>>>>
>>>> The previous code stored the ecpointQ as an ANS1 DER OCTET_STRING,
>>>> and the decode and encode routines in pkcs15-pubkey.c just copied
>>>> the DER encoding.
>>>>
>>>> Comments in pkcs15-pubkey.c had:
>>>>
>>>>       /*
>>>>        * We are storing the ec_pointQ as a octet string.
>>>>        * Thus we will just copy the string.
>>>>        * But to get the field length we decode it.
>>>>        */
>>>>
>>>> pkcs15.h had:
>>>>       sc_pkcs15_der_t    ecpointQ; /* note this is der */
>>>>
>>>> The "myEID ECDSA Support" changed the way the ecpointQ was stored
>>>> from an ASN1 DER OCTET STRING to just storing "an arbitrary
>>>> string of octets (eight-bit values)" i.e. the value of the
>>>> ASN1 DER OCTET STRING.
>>>>
>>>> I have issues with how the "myEID  ECDSA Support"  was handled:
>>>>
>>>>       * This change was made at the last minute before the 0.13.0 release.
>>>>
>>>>       * No questions or comments were posted to the mailing list
>>>>         to ask why the ecpointQ was stored as DER.
>>>>
>>>>       * No comments where made to the mailing list that this
>>>>         fundamental change was made.
>>>>
>>>>       * No changes where made to the comments to indicate
>>>>         only the value of the ecpointQ was being stored.
>>>>         The coments still indicate DER.
>>>>
>>>>       * No attempt was made to change the other two card drivers
>>>>         that supported EC was made.
>>>>
>>>>       * This broke the SmartCard-HSM code. CardContact Software & System Consulting
>>>>         reported: "Yes, I remember I even complained about this last minute change
>>>>         for the 0.13 release, because it broke our SmartCard-HSM code..."
>>>>
>>>> The myEID changes did not break the PIV code right away, as the PIV kept
>>>> storing and using the ecpointQ as a DER OCTET STRING. But newer changes
>>>> such as Pull request #191 "Enhanced ECC handling" ran into the
>>>> problems with how the ecpointQ was now being stored.
>>>>
>>>> Because of all of this,
>>>>
>>>>      (1) I am withdrawing the #191 pull request for now, so it can be rewritten.
>>>>
>>>>      (2) I intend to proposed changes to continue to store the ecpointQ
>>>>          as the value of the DER encoding as it is the more straight forward way.
>>>>          I will also fix up the comments to point this out...
>>>>
>>>>      (3) I intend to submit changes to the PIV card driver and any other code
>>>>          that depends on how the ecpointQ is stored.
>>>>
>>>>      (4) Resubmit a modified "Enhanced ECC handling".
>>>>
>>>> We as a project, when we submit code changes like this, the changes need a
>>>> good explanation of what code is being changed and what issues might
>>>> arise from the changes, especially if:
>>>>
>>>>      * Some code used by everyone is being changed in some fundamental way.
>>>>
>>>>      * Some code might effect card drivers that the author of the change can not test.
>>>>
>>>>
>>>>
>>>> Comments?
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> November Webinars for C, C++, Fortran Developers
>>> Accelerate application performance with scalable programming models. Explore
>>> techniques for threading, error checking, porting, and tuning. Get the most
>>> from the latest Intel processors and coprocessors. See abstracts and register
>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Opensc-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>
>>
>

--

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

------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problems with MyEID and fundamental changes to the storing of the ECC ecpointQ

Andreas Schwier (ML)
Hi Douglas,

I've done a full regression test and the code still works with the
SmartCard-HSM.

However the EC_PARAMS are still not available at the PKCS#11 interface
for a newly generated key. I will have a look at that issue.

Andreas

On 11/11/2013 09:31 PM, Douglas E. Engert wrote:

> I have not heard anything from the MyEID developers. The discussion of the
> problem started on 11/04/13, last week.
>
> Unless I here anything, I plain on committing #194 tomorrow, 11/12/13.
>
>
> On 11/6/2013 5:01 PM, Douglas E. Engert wrote:
>> Please see pull request #194, https://github.com/OpenSC/OpenSC/pull/194
>> This address the ecpointQ issues as outlined below.
>>
>> It partially addresses the issue that EC parameters are stored in two
>> places.
>>
>> It stores the ecpointQ as raw in the pubkey->ec.u.ecpointQ, and stored
>> it in
>> DER in pubkey->data. Note the framework-pkcs15.c will use the
>> pubkey->data
>> for the CKA_EC_POINT attribute.
>>
>> I think it will address Tim's issues with using the pubkey from a
>> certificate
>> with PIV cards, as the problem was related.
>>
>> Comments?
>>
>>
>> On 11/5/2013 8:28 AM, Douglas E. Engert wrote:
>>>
>>>
>>> On 11/5/2013 7:48 AM, Andreas Schwier wrote:
>>>> Hi Douglas,
>>>>
>>>> I fully agree with your position, however I think the current encoding
>>>> based on X9.62 chapter A.5.7 should remain rather than changing
>>>> again to
>>>> the ECPoint DER encoding from chapter E.6 of the same standard.
>>>
>>> I believe that is what I said in (2) below:
>>>      "I intend to proposed changes to continue to store the ecpointQ
>>>       as the *value* of the DER encoding as it is the more straight
>>> forward way."
>>>
>>> By "continue" I meant to use what is the git master, but change the
>>> comments
>>> as there is also a problem of semantics, as "octet string" could
>>> refer to a
>>> a ASN1 DER OCTET STRING or to its value, especially as it is defined as:
>>> sc_pkcs15_der_t        ecpointQ; /* note this is der */
>>> With der being uses twice.
>>>
>>> For an uncompressed ecpointQ  "04||X||Y" with a 256 bit curve would
>>> have a
>>> length of 1+32+32 = 65 bytes. A 384 bit curve would have length
>>> 1+48+48=97
>>>
>>>>
>>>> It's much easier to convert from the current octet string encoding to
>>>> ECPoint or BITSTRING (SPKI) or Tag 86 (CVCs).
>>>
>>> Yes, I should have done that with the original ECC code.
>>>
>>>>
>>>> Andreas
>>>>
>>>> On 11/04/2013 08:54 PM, Douglas E. Engert wrote:
>>>>> During the discussion on pull request #191 "Enhanced ECC handling
>>>>> (#191)"
>>>>> It has become apparent that:
>>>>>
>>>>>        Commit 457426543dfa02597895d57013dde94cc9e7d038
>>>>>        Author: sjoblomt <[hidden email]>  2012-11-28 04:52:43
>>>>>        Committer: Viktor Tarasov <[hidden email]>
>>>>> 2012-12-03 07:37:13
>>>>>        "MyEID ECDSA Support"
>>>>>
>>>>> had made a fundamental change in the way the ecpointQ was stored.
>>>>>
>>>>> The previous code stored the ecpointQ as an ANS1 DER OCTET_STRING,
>>>>> and the decode and encode routines in pkcs15-pubkey.c just copied
>>>>> the DER encoding.
>>>>>
>>>>> Comments in pkcs15-pubkey.c had:
>>>>>
>>>>>       /*
>>>>>        * We are storing the ec_pointQ as a octet string.
>>>>>        * Thus we will just copy the string.
>>>>>        * But to get the field length we decode it.
>>>>>        */
>>>>>
>>>>> pkcs15.h had:
>>>>>       sc_pkcs15_der_t        ecpointQ; /* note this is der */
>>>>>
>>>>> The "myEID ECDSA Support" changed the way the ecpointQ was stored
>>>>> from an ASN1 DER OCTET STRING to just storing "an arbitrary
>>>>> string of octets (eight-bit values)" i.e. the value of the
>>>>> ASN1 DER OCTET STRING.
>>>>>
>>>>> I have issues with how the "myEID  ECDSA Support"  was handled:
>>>>>
>>>>>       * This change was made at the last minute before the 0.13.0
>>>>> release.
>>>>>
>>>>>       * No questions or comments were posted to the mailing list
>>>>>         to ask why the ecpointQ was stored as DER.
>>>>>
>>>>>       * No comments where made to the mailing list that this
>>>>>         fundamental change was made.
>>>>>
>>>>>       * No changes where made to the comments to indicate
>>>>>         only the value of the ecpointQ was being stored.
>>>>>         The coments still indicate DER.
>>>>>
>>>>>       * No attempt was made to change the other two card drivers
>>>>>         that supported EC was made.
>>>>>
>>>>>       * This broke the SmartCard-HSM code. CardContact Software &
>>>>> System Consulting
>>>>>         reported: "Yes, I remember I even complained about this
>>>>> last minute change
>>>>>         for the 0.13 release, because it broke our SmartCard-HSM
>>>>> code..."
>>>>>
>>>>> The myEID changes did not break the PIV code right away, as the PIV
>>>>> kept
>>>>> storing and using the ecpointQ as a DER OCTET STRING. But newer
>>>>> changes
>>>>> such as Pull request #191 "Enhanced ECC handling" ran into the
>>>>> problems with how the ecpointQ was now being stored.
>>>>>
>>>>> Because of all of this,
>>>>>
>>>>>      (1) I am withdrawing the #191 pull request for now, so it can
>>>>> be rewritten.
>>>>>
>>>>>      (2) I intend to proposed changes to continue to store the
>>>>> ecpointQ
>>>>>          as the value of the DER encoding as it is the more
>>>>> straight forward way.
>>>>>          I will also fix up the comments to point this out...
>>>>>
>>>>>      (3) I intend to submit changes to the PIV card driver and any
>>>>> other code
>>>>>          that depends on how the ecpointQ is stored.
>>>>>
>>>>>      (4) Resubmit a modified "Enhanced ECC handling".
>>>>>
>>>>> We as a project, when we submit code changes like this, the changes
>>>>> need a
>>>>> good explanation of what code is being changed and what issues might
>>>>> arise from the changes, especially if:
>>>>>
>>>>>      * Some code used by everyone is being changed in some
>>>>> fundamental way.
>>>>>
>>>>>      * Some code might effect card drivers that the author of the
>>>>> change can not test.
>>>>>
>>>>>
>>>>>
>>>>> Comments?
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>> November Webinars for C, C++, Fortran Developers
>>>> Accelerate application performance with scalable programming models.
>>>> Explore
>>>> techniques for threading, error checking, porting, and tuning. Get
>>>> the most
>>>> from the latest Intel processors and coprocessors. See abstracts and
>>>> register
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>>>
>>>> _______________________________________________
>>>> Opensc-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>
>>>
>>
>


------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problems with MyEID and fundamental changes to the storing of the ECC ecpointQ

Douglas E. Engert


On 11/14/2013 3:38 AM, Andreas Schwier wrote:
> Hi Douglas,
>
> I've done a full regression test and the code still works with the
> SmartCard-HSM.
>
> However the EC_PARAMS are still not available at the PKCS#11 interface
> for a newly generated key. I will have a look at that issue.

Look at what I had to do in sc_pkcs15_pubkey_from spki to copy the
params around. Similar code may be needed somewhere else.

>
> Andreas
>
> On 11/11/2013 09:31 PM, Douglas E. Engert wrote:
>> I have not heard anything from the MyEID developers. The discussion of the
>> problem started on 11/04/13, last week.
>>
>> Unless I here anything, I plain on committing #194 tomorrow, 11/12/13.
>>
>>
>> On 11/6/2013 5:01 PM, Douglas E. Engert wrote:
>>> Please see pull request #194, https://github.com/OpenSC/OpenSC/pull/194
>>> This address the ecpointQ issues as outlined below.
>>>
>>> It partially addresses the issue that EC parameters are stored in two
>>> places.
>>>
>>> It stores the ecpointQ as raw in the pubkey->ec.u.ecpointQ, and stored
>>> it in
>>> DER in pubkey->data. Note the framework-pkcs15.c will use the
>>> pubkey->data
>>> for the CKA_EC_POINT attribute.
>>>
>>> I think it will address Tim's issues with using the pubkey from a
>>> certificate
>>> with PIV cards, as the problem was related.
>>>
>>> Comments?
>>>
>>>
>>> On 11/5/2013 8:28 AM, Douglas E. Engert wrote:
>>>>
>>>>
>>>> On 11/5/2013 7:48 AM, Andreas Schwier wrote:
>>>>> Hi Douglas,
>>>>>
>>>>> I fully agree with your position, however I think the current encoding
>>>>> based on X9.62 chapter A.5.7 should remain rather than changing
>>>>> again to
>>>>> the ECPoint DER encoding from chapter E.6 of the same standard.
>>>>
>>>> I believe that is what I said in (2) below:
>>>>       "I intend to proposed changes to continue to store the ecpointQ
>>>>        as the *value* of the DER encoding as it is the more straight
>>>> forward way."
>>>>
>>>> By "continue" I meant to use what is the git master, but change the
>>>> comments
>>>> as there is also a problem of semantics, as "octet string" could
>>>> refer to a
>>>> a ASN1 DER OCTET STRING or to its value, especially as it is defined as:
>>>> sc_pkcs15_der_t        ecpointQ; /* note this is der */
>>>> With der being uses twice.
>>>>
>>>> For an uncompressed ecpointQ  "04||X||Y" with a 256 bit curve would
>>>> have a
>>>> length of 1+32+32 = 65 bytes. A 384 bit curve would have length
>>>> 1+48+48=97
>>>>
>>>>>
>>>>> It's much easier to convert from the current octet string encoding to
>>>>> ECPoint or BITSTRING (SPKI) or Tag 86 (CVCs).
>>>>
>>>> Yes, I should have done that with the original ECC code.
>>>>
>>>>>
>>>>> Andreas
>>>>>
>>>>> On 11/04/2013 08:54 PM, Douglas E. Engert wrote:
>>>>>> During the discussion on pull request #191 "Enhanced ECC handling
>>>>>> (#191)"
>>>>>> It has become apparent that:
>>>>>>
>>>>>>         Commit 457426543dfa02597895d57013dde94cc9e7d038
>>>>>>         Author: sjoblomt <[hidden email]>  2012-11-28 04:52:43
>>>>>>         Committer: Viktor Tarasov <[hidden email]>
>>>>>> 2012-12-03 07:37:13
>>>>>>         "MyEID ECDSA Support"
>>>>>>
>>>>>> had made a fundamental change in the way the ecpointQ was stored.
>>>>>>
>>>>>> The previous code stored the ecpointQ as an ANS1 DER OCTET_STRING,
>>>>>> and the decode and encode routines in pkcs15-pubkey.c just copied
>>>>>> the DER encoding.
>>>>>>
>>>>>> Comments in pkcs15-pubkey.c had:
>>>>>>
>>>>>>        /*
>>>>>>         * We are storing the ec_pointQ as a octet string.
>>>>>>         * Thus we will just copy the string.
>>>>>>         * But to get the field length we decode it.
>>>>>>         */
>>>>>>
>>>>>> pkcs15.h had:
>>>>>>        sc_pkcs15_der_t        ecpointQ; /* note this is der */
>>>>>>
>>>>>> The "myEID ECDSA Support" changed the way the ecpointQ was stored
>>>>>> from an ASN1 DER OCTET STRING to just storing "an arbitrary
>>>>>> string of octets (eight-bit values)" i.e. the value of the
>>>>>> ASN1 DER OCTET STRING.
>>>>>>
>>>>>> I have issues with how the "myEID  ECDSA Support"  was handled:
>>>>>>
>>>>>>        * This change was made at the last minute before the 0.13.0
>>>>>> release.
>>>>>>
>>>>>>        * No questions or comments were posted to the mailing list
>>>>>>          to ask why the ecpointQ was stored as DER.
>>>>>>
>>>>>>        * No comments where made to the mailing list that this
>>>>>>          fundamental change was made.
>>>>>>
>>>>>>        * No changes where made to the comments to indicate
>>>>>>          only the value of the ecpointQ was being stored.
>>>>>>          The coments still indicate DER.
>>>>>>
>>>>>>        * No attempt was made to change the other two card drivers
>>>>>>          that supported EC was made.
>>>>>>
>>>>>>        * This broke the SmartCard-HSM code. CardContact Software &
>>>>>> System Consulting
>>>>>>          reported: "Yes, I remember I even complained about this
>>>>>> last minute change
>>>>>>          for the 0.13 release, because it broke our SmartCard-HSM
>>>>>> code..."
>>>>>>
>>>>>> The myEID changes did not break the PIV code right away, as the PIV
>>>>>> kept
>>>>>> storing and using the ecpointQ as a DER OCTET STRING. But newer
>>>>>> changes
>>>>>> such as Pull request #191 "Enhanced ECC handling" ran into the
>>>>>> problems with how the ecpointQ was now being stored.
>>>>>>
>>>>>> Because of all of this,
>>>>>>
>>>>>>       (1) I am withdrawing the #191 pull request for now, so it can
>>>>>> be rewritten.
>>>>>>
>>>>>>       (2) I intend to proposed changes to continue to store the
>>>>>> ecpointQ
>>>>>>           as the value of the DER encoding as it is the more
>>>>>> straight forward way.
>>>>>>           I will also fix up the comments to point this out...
>>>>>>
>>>>>>       (3) I intend to submit changes to the PIV card driver and any
>>>>>> other code
>>>>>>           that depends on how the ecpointQ is stored.
>>>>>>
>>>>>>       (4) Resubmit a modified "Enhanced ECC handling".
>>>>>>
>>>>>> We as a project, when we submit code changes like this, the changes
>>>>>> need a
>>>>>> good explanation of what code is being changed and what issues might
>>>>>> arise from the changes, especially if:
>>>>>>
>>>>>>       * Some code used by everyone is being changed in some
>>>>>> fundamental way.
>>>>>>
>>>>>>       * Some code might effect card drivers that the author of the
>>>>>> change can not test.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Comments?
>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>>
>>>>> November Webinars for C, C++, Fortran Developers
>>>>> Accelerate application performance with scalable programming models.
>>>>> Explore
>>>>> techniques for threading, error checking, porting, and tuning. Get
>>>>> the most
>>>>> from the latest Intel processors and coprocessors. See abstracts and
>>>>> register
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>>>>
>>>>> _______________________________________________
>>>>> Opensc-devel mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>>
>>>>
>>>
>>
>
> .
>

--

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

------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problems with MyEID and fundamental changes to the storing of the ECC ecpointQ

Andreas Schwier (ML)
Hi Douglas,

I've opened a pull request that changes the format in which EC Public
Keys are stored as direct values in PuKDF. This way domain parameter are
preserved during the encode / decode cycle that happens in
framework-pkcs15.c/pkcs15_gen_keypair.

The code tries to preserve backwards compatibility with cards that
already store the EC Public Key in raw format.

@Toni: Please check with myEID card.

Kind regards,

Andreas


On 11/14/2013 04:31 PM, Douglas E. Engert wrote:

>
>
> On 11/14/2013 3:38 AM, Andreas Schwier wrote:
>> Hi Douglas,
>>
>> I've done a full regression test and the code still works with the
>> SmartCard-HSM.
>>
>> However the EC_PARAMS are still not available at the PKCS#11 interface
>> for a newly generated key. I will have a look at that issue.
>
> Look at what I had to do in sc_pkcs15_pubkey_from spki to copy the
> params around. Similar code may be needed somewhere else.
>
>>
>> Andreas
>>
>> On 11/11/2013 09:31 PM, Douglas E. Engert wrote:
>>> I have not heard anything from the MyEID developers. The discussion
>>> of the
>>> problem started on 11/04/13, last week.
>>>
>>> Unless I here anything, I plain on committing #194 tomorrow, 11/12/13.
>>>
>>>
>>> On 11/6/2013 5:01 PM, Douglas E. Engert wrote:
>>>> Please see pull request #194, https://github.com/OpenSC/OpenSC/pull/194
>>>> This address the ecpointQ issues as outlined below.
>>>>
>>>> It partially addresses the issue that EC parameters are stored in two
>>>> places.
>>>>
>>>> It stores the ecpointQ as raw in the pubkey->ec.u.ecpointQ, and stored
>>>> it in
>>>> DER in pubkey->data. Note the framework-pkcs15.c will use the
>>>> pubkey->data
>>>> for the CKA_EC_POINT attribute.
>>>>
>>>> I think it will address Tim's issues with using the pubkey from a
>>>> certificate
>>>> with PIV cards, as the problem was related.
>>>>
>>>> Comments?
>>>>
>>>>
>>>> On 11/5/2013 8:28 AM, Douglas E. Engert wrote:
>>>>>
>>>>>
>>>>> On 11/5/2013 7:48 AM, Andreas Schwier wrote:
>>>>>> Hi Douglas,
>>>>>>
>>>>>> I fully agree with your position, however I think the current
>>>>>> encoding
>>>>>> based on X9.62 chapter A.5.7 should remain rather than changing
>>>>>> again to
>>>>>> the ECPoint DER encoding from chapter E.6 of the same standard.
>>>>>
>>>>> I believe that is what I said in (2) below:
>>>>>       "I intend to proposed changes to continue to store the ecpointQ
>>>>>        as the *value* of the DER encoding as it is the more straight
>>>>> forward way."
>>>>>
>>>>> By "continue" I meant to use what is the git master, but change the
>>>>> comments
>>>>> as there is also a problem of semantics, as "octet string" could
>>>>> refer to a
>>>>> a ASN1 DER OCTET STRING or to its value, especially as it is
>>>>> defined as:
>>>>> sc_pkcs15_der_t        ecpointQ; /* note this is der */
>>>>> With der being uses twice.
>>>>>
>>>>> For an uncompressed ecpointQ  "04||X||Y" with a 256 bit curve would
>>>>> have a
>>>>> length of 1+32+32 = 65 bytes. A 384 bit curve would have length
>>>>> 1+48+48=97
>>>>>
>>>>>>
>>>>>> It's much easier to convert from the current octet string encoding to
>>>>>> ECPoint or BITSTRING (SPKI) or Tag 86 (CVCs).
>>>>>
>>>>> Yes, I should have done that with the original ECC code.
>>>>>
>>>>>>
>>>>>> Andreas
>>>>>>
>>>>>> On 11/04/2013 08:54 PM, Douglas E. Engert wrote:
>>>>>>> During the discussion on pull request #191 "Enhanced ECC handling
>>>>>>> (#191)"
>>>>>>> It has become apparent that:
>>>>>>>
>>>>>>>         Commit 457426543dfa02597895d57013dde94cc9e7d038
>>>>>>>         Author: sjoblomt <[hidden email]>  2012-11-28
>>>>>>> 04:52:43
>>>>>>>         Committer: Viktor Tarasov <[hidden email]>
>>>>>>> 2012-12-03 07:37:13
>>>>>>>         "MyEID ECDSA Support"
>>>>>>>
>>>>>>> had made a fundamental change in the way the ecpointQ was stored.
>>>>>>>
>>>>>>> The previous code stored the ecpointQ as an ANS1 DER OCTET_STRING,
>>>>>>> and the decode and encode routines in pkcs15-pubkey.c just copied
>>>>>>> the DER encoding.
>>>>>>>
>>>>>>> Comments in pkcs15-pubkey.c had:
>>>>>>>
>>>>>>>        /*
>>>>>>>         * We are storing the ec_pointQ as a octet string.
>>>>>>>         * Thus we will just copy the string.
>>>>>>>         * But to get the field length we decode it.
>>>>>>>         */
>>>>>>>
>>>>>>> pkcs15.h had:
>>>>>>>        sc_pkcs15_der_t        ecpointQ; /* note this is der */
>>>>>>>
>>>>>>> The "myEID ECDSA Support" changed the way the ecpointQ was stored
>>>>>>> from an ASN1 DER OCTET STRING to just storing "an arbitrary
>>>>>>> string of octets (eight-bit values)" i.e. the value of the
>>>>>>> ASN1 DER OCTET STRING.
>>>>>>>
>>>>>>> I have issues with how the "myEID  ECDSA Support"  was handled:
>>>>>>>
>>>>>>>        * This change was made at the last minute before the 0.13.0
>>>>>>> release.
>>>>>>>
>>>>>>>        * No questions or comments were posted to the mailing list
>>>>>>>          to ask why the ecpointQ was stored as DER.
>>>>>>>
>>>>>>>        * No comments where made to the mailing list that this
>>>>>>>          fundamental change was made.
>>>>>>>
>>>>>>>        * No changes where made to the comments to indicate
>>>>>>>          only the value of the ecpointQ was being stored.
>>>>>>>          The coments still indicate DER.
>>>>>>>
>>>>>>>        * No attempt was made to change the other two card drivers
>>>>>>>          that supported EC was made.
>>>>>>>
>>>>>>>        * This broke the SmartCard-HSM code. CardContact Software &
>>>>>>> System Consulting
>>>>>>>          reported: "Yes, I remember I even complained about this
>>>>>>> last minute change
>>>>>>>          for the 0.13 release, because it broke our SmartCard-HSM
>>>>>>> code..."
>>>>>>>
>>>>>>> The myEID changes did not break the PIV code right away, as the PIV
>>>>>>> kept
>>>>>>> storing and using the ecpointQ as a DER OCTET STRING. But newer
>>>>>>> changes
>>>>>>> such as Pull request #191 "Enhanced ECC handling" ran into the
>>>>>>> problems with how the ecpointQ was now being stored.
>>>>>>>
>>>>>>> Because of all of this,
>>>>>>>
>>>>>>>       (1) I am withdrawing the #191 pull request for now, so it can
>>>>>>> be rewritten.
>>>>>>>
>>>>>>>       (2) I intend to proposed changes to continue to store the
>>>>>>> ecpointQ
>>>>>>>           as the value of the DER encoding as it is the more
>>>>>>> straight forward way.
>>>>>>>           I will also fix up the comments to point this out...
>>>>>>>
>>>>>>>       (3) I intend to submit changes to the PIV card driver and any
>>>>>>> other code
>>>>>>>           that depends on how the ecpointQ is stored.
>>>>>>>
>>>>>>>       (4) Resubmit a modified "Enhanced ECC handling".
>>>>>>>
>>>>>>> We as a project, when we submit code changes like this, the changes
>>>>>>> need a
>>>>>>> good explanation of what code is being changed and what issues might
>>>>>>> arise from the changes, especially if:
>>>>>>>
>>>>>>>       * Some code used by everyone is being changed in some
>>>>>>> fundamental way.
>>>>>>>
>>>>>>>       * Some code might effect card drivers that the author of the
>>>>>>> change can not test.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Comments?
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> November Webinars for C, C++, Fortran Developers
>>>>>> Accelerate application performance with scalable programming models.
>>>>>> Explore
>>>>>> techniques for threading, error checking, porting, and tuning. Get
>>>>>> the most
>>>>>> from the latest Intel processors and coprocessors. See abstracts and
>>>>>> register
>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Opensc-devel mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>>>
>>>>>
>>>>
>>>
>>
>> .
>>
>


------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problems with MyEID and fundamental changes to the storing of the ECC ecpointQ

Douglas E. Engert
I will try and test this this week.

I still have not got the cards.

On 11/15/2013 5:00 AM, Andreas Schwier wrote:

> Hi Douglas,
>
> I've opened a pull request that changes the format in which EC Public
> Keys are stored as direct values in PuKDF. This way domain parameter are
> preserved during the encode / decode cycle that happens in
> framework-pkcs15.c/pkcs15_gen_keypair.
>
> The code tries to preserve backwards compatibility with cards that
> already store the EC Public Key in raw format.
>
> @Toni: Please check with myEID card.
>
> Kind regards,
>
> Andreas
>
>
> On 11/14/2013 04:31 PM, Douglas E. Engert wrote:
>>
>>
>> On 11/14/2013 3:38 AM, Andreas Schwier wrote:
>>> Hi Douglas,
>>>
>>> I've done a full regression test and the code still works with the
>>> SmartCard-HSM.
>>>
>>> However the EC_PARAMS are still not available at the PKCS#11 interface
>>> for a newly generated key. I will have a look at that issue.
>>
>> Look at what I had to do in sc_pkcs15_pubkey_from spki to copy the
>> params around. Similar code may be needed somewhere else.
>>
>>>
>>> Andreas
>>>
>>> On 11/11/2013 09:31 PM, Douglas E. Engert wrote:
>>>> I have not heard anything from the MyEID developers. The discussion
>>>> of the
>>>> problem started on 11/04/13, last week.
>>>>
>>>> Unless I here anything, I plain on committing #194 tomorrow, 11/12/13.
>>>>
>>>>
>>>> On 11/6/2013 5:01 PM, Douglas E. Engert wrote:
>>>>> Please see pull request #194, https://github.com/OpenSC/OpenSC/pull/194
>>>>> This address the ecpointQ issues as outlined below.
>>>>>
>>>>> It partially addresses the issue that EC parameters are stored in two
>>>>> places.
>>>>>
>>>>> It stores the ecpointQ as raw in the pubkey->ec.u.ecpointQ, and stored
>>>>> it in
>>>>> DER in pubkey->data. Note the framework-pkcs15.c will use the
>>>>> pubkey->data
>>>>> for the CKA_EC_POINT attribute.
>>>>>
>>>>> I think it will address Tim's issues with using the pubkey from a
>>>>> certificate
>>>>> with PIV cards, as the problem was related.
>>>>>
>>>>> Comments?
>>>>>
>>>>>
>>>>> On 11/5/2013 8:28 AM, Douglas E. Engert wrote:
>>>>>>
>>>>>>
>>>>>> On 11/5/2013 7:48 AM, Andreas Schwier wrote:
>>>>>>> Hi Douglas,
>>>>>>>
>>>>>>> I fully agree with your position, however I think the current
>>>>>>> encoding
>>>>>>> based on X9.62 chapter A.5.7 should remain rather than changing
>>>>>>> again to
>>>>>>> the ECPoint DER encoding from chapter E.6 of the same standard.
>>>>>>
>>>>>> I believe that is what I said in (2) below:
>>>>>>        "I intend to proposed changes to continue to store the ecpointQ
>>>>>>         as the *value* of the DER encoding as it is the more straight
>>>>>> forward way."
>>>>>>
>>>>>> By "continue" I meant to use what is the git master, but change the
>>>>>> comments
>>>>>> as there is also a problem of semantics, as "octet string" could
>>>>>> refer to a
>>>>>> a ASN1 DER OCTET STRING or to its value, especially as it is
>>>>>> defined as:
>>>>>> sc_pkcs15_der_t        ecpointQ; /* note this is der */
>>>>>> With der being uses twice.
>>>>>>
>>>>>> For an uncompressed ecpointQ  "04||X||Y" with a 256 bit curve would
>>>>>> have a
>>>>>> length of 1+32+32 = 65 bytes. A 384 bit curve would have length
>>>>>> 1+48+48=97
>>>>>>
>>>>>>>
>>>>>>> It's much easier to convert from the current octet string encoding to
>>>>>>> ECPoint or BITSTRING (SPKI) or Tag 86 (CVCs).
>>>>>>
>>>>>> Yes, I should have done that with the original ECC code.
>>>>>>
>>>>>>>
>>>>>>> Andreas
>>>>>>>
>>>>>>> On 11/04/2013 08:54 PM, Douglas E. Engert wrote:
>>>>>>>> During the discussion on pull request #191 "Enhanced ECC handling
>>>>>>>> (#191)"
>>>>>>>> It has become apparent that:
>>>>>>>>
>>>>>>>>          Commit 457426543dfa02597895d57013dde94cc9e7d038
>>>>>>>>          Author: sjoblomt <[hidden email]>  2012-11-28
>>>>>>>> 04:52:43
>>>>>>>>          Committer: Viktor Tarasov <[hidden email]>
>>>>>>>> 2012-12-03 07:37:13
>>>>>>>>          "MyEID ECDSA Support"
>>>>>>>>
>>>>>>>> had made a fundamental change in the way the ecpointQ was stored.
>>>>>>>>
>>>>>>>> The previous code stored the ecpointQ as an ANS1 DER OCTET_STRING,
>>>>>>>> and the decode and encode routines in pkcs15-pubkey.c just copied
>>>>>>>> the DER encoding.
>>>>>>>>
>>>>>>>> Comments in pkcs15-pubkey.c had:
>>>>>>>>
>>>>>>>>         /*
>>>>>>>>          * We are storing the ec_pointQ as a octet string.
>>>>>>>>          * Thus we will just copy the string.
>>>>>>>>          * But to get the field length we decode it.
>>>>>>>>          */
>>>>>>>>
>>>>>>>> pkcs15.h had:
>>>>>>>>         sc_pkcs15_der_t        ecpointQ; /* note this is der */
>>>>>>>>
>>>>>>>> The "myEID ECDSA Support" changed the way the ecpointQ was stored
>>>>>>>> from an ASN1 DER OCTET STRING to just storing "an arbitrary
>>>>>>>> string of octets (eight-bit values)" i.e. the value of the
>>>>>>>> ASN1 DER OCTET STRING.
>>>>>>>>
>>>>>>>> I have issues with how the "myEID  ECDSA Support"  was handled:
>>>>>>>>
>>>>>>>>         * This change was made at the last minute before the 0.13.0
>>>>>>>> release.
>>>>>>>>
>>>>>>>>         * No questions or comments were posted to the mailing list
>>>>>>>>           to ask why the ecpointQ was stored as DER.
>>>>>>>>
>>>>>>>>         * No comments where made to the mailing list that this
>>>>>>>>           fundamental change was made.
>>>>>>>>
>>>>>>>>         * No changes where made to the comments to indicate
>>>>>>>>           only the value of the ecpointQ was being stored.
>>>>>>>>           The coments still indicate DER.
>>>>>>>>
>>>>>>>>         * No attempt was made to change the other two card drivers
>>>>>>>>           that supported EC was made.
>>>>>>>>
>>>>>>>>         * This broke the SmartCard-HSM code. CardContact Software &
>>>>>>>> System Consulting
>>>>>>>>           reported: "Yes, I remember I even complained about this
>>>>>>>> last minute change
>>>>>>>>           for the 0.13 release, because it broke our SmartCard-HSM
>>>>>>>> code..."
>>>>>>>>
>>>>>>>> The myEID changes did not break the PIV code right away, as the PIV
>>>>>>>> kept
>>>>>>>> storing and using the ecpointQ as a DER OCTET STRING. But newer
>>>>>>>> changes
>>>>>>>> such as Pull request #191 "Enhanced ECC handling" ran into the
>>>>>>>> problems with how the ecpointQ was now being stored.
>>>>>>>>
>>>>>>>> Because of all of this,
>>>>>>>>
>>>>>>>>        (1) I am withdrawing the #191 pull request for now, so it can
>>>>>>>> be rewritten.
>>>>>>>>
>>>>>>>>        (2) I intend to proposed changes to continue to store the
>>>>>>>> ecpointQ
>>>>>>>>            as the value of the DER encoding as it is the more
>>>>>>>> straight forward way.
>>>>>>>>            I will also fix up the comments to point this out...
>>>>>>>>
>>>>>>>>        (3) I intend to submit changes to the PIV card driver and any
>>>>>>>> other code
>>>>>>>>            that depends on how the ecpointQ is stored.
>>>>>>>>
>>>>>>>>        (4) Resubmit a modified "Enhanced ECC handling".
>>>>>>>>
>>>>>>>> We as a project, when we submit code changes like this, the changes
>>>>>>>> need a
>>>>>>>> good explanation of what code is being changed and what issues might
>>>>>>>> arise from the changes, especially if:
>>>>>>>>
>>>>>>>>        * Some code used by everyone is being changed in some
>>>>>>>> fundamental way.
>>>>>>>>
>>>>>>>>        * Some code might effect card drivers that the author of the
>>>>>>>> change can not test.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Comments?
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>> November Webinars for C, C++, Fortran Developers
>>>>>>> Accelerate application performance with scalable programming models.
>>>>>>> Explore
>>>>>>> techniques for threading, error checking, porting, and tuning. Get
>>>>>>> the most
>>>>>>> from the latest Intel processors and coprocessors. See abstracts and
>>>>>>> register
>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Opensc-devel mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> .
>>>
>>
>
> .
>

--

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

------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problems with MyEID and fundamental changes to the storing of the ECC ecpointQ

Douglas E. Engert
In reply to this post by Andreas Schwier (ML)
I received the two cards, and USB stick today.
Thanks.

Is there any documentation?

I have also started to look at the pull request #197.
It compiles and the PIV card works with ECC but I need to look closer
at how pkcs11-tool and pkcs15-tool handle pub keys. something does not
look right. It may not be in you new code.



On 11/15/2013 5:00 AM, Andreas Schwier wrote:

> Hi Douglas,
>
> I've opened a pull request that changes the format in which EC Public
> Keys are stored as direct values in PuKDF. This way domain parameter are
> preserved during the encode / decode cycle that happens in
> framework-pkcs15.c/pkcs15_gen_keypair.
>
> The code tries to preserve backwards compatibility with cards that
> already store the EC Public Key in raw format.
>
> @Toni: Please check with myEID card.
>
> Kind regards,
>
> Andreas
>
>
> On 11/14/2013 04:31 PM, Douglas E. Engert wrote:
>>
>>
>> On 11/14/2013 3:38 AM, Andreas Schwier wrote:
>>> Hi Douglas,
>>>
>>> I've done a full regression test and the code still works with the
>>> SmartCard-HSM.
>>>
>>> However the EC_PARAMS are still not available at the PKCS#11 interface
>>> for a newly generated key. I will have a look at that issue.
>>
>> Look at what I had to do in sc_pkcs15_pubkey_from spki to copy the
>> params around. Similar code may be needed somewhere else.
>>
>>>
>>> Andreas
>>>
>>> On 11/11/2013 09:31 PM, Douglas E. Engert wrote:
>>>> I have not heard anything from the MyEID developers. The discussion
>>>> of the
>>>> problem started on 11/04/13, last week.
>>>>
>>>> Unless I here anything, I plain on committing #194 tomorrow, 11/12/13.
>>>>
>>>>
>>>> On 11/6/2013 5:01 PM, Douglas E. Engert wrote:
>>>>> Please see pull request #194, https://github.com/OpenSC/OpenSC/pull/194
>>>>> This address the ecpointQ issues as outlined below.
>>>>>
>>>>> It partially addresses the issue that EC parameters are stored in two
>>>>> places.
>>>>>
>>>>> It stores the ecpointQ as raw in the pubkey->ec.u.ecpointQ, and stored
>>>>> it in
>>>>> DER in pubkey->data. Note the framework-pkcs15.c will use the
>>>>> pubkey->data
>>>>> for the CKA_EC_POINT attribute.
>>>>>
>>>>> I think it will address Tim's issues with using the pubkey from a
>>>>> certificate
>>>>> with PIV cards, as the problem was related.
>>>>>
>>>>> Comments?
>>>>>
>>>>>
>>>>> On 11/5/2013 8:28 AM, Douglas E. Engert wrote:
>>>>>>
>>>>>>
>>>>>> On 11/5/2013 7:48 AM, Andreas Schwier wrote:
>>>>>>> Hi Douglas,
>>>>>>>
>>>>>>> I fully agree with your position, however I think the current
>>>>>>> encoding
>>>>>>> based on X9.62 chapter A.5.7 should remain rather than changing
>>>>>>> again to
>>>>>>> the ECPoint DER encoding from chapter E.6 of the same standard.
>>>>>>
>>>>>> I believe that is what I said in (2) below:
>>>>>>        "I intend to proposed changes to continue to store the ecpointQ
>>>>>>         as the *value* of the DER encoding as it is the more straight
>>>>>> forward way."
>>>>>>
>>>>>> By "continue" I meant to use what is the git master, but change the
>>>>>> comments
>>>>>> as there is also a problem of semantics, as "octet string" could
>>>>>> refer to a
>>>>>> a ASN1 DER OCTET STRING or to its value, especially as it is
>>>>>> defined as:
>>>>>> sc_pkcs15_der_t        ecpointQ; /* note this is der */
>>>>>> With der being uses twice.
>>>>>>
>>>>>> For an uncompressed ecpointQ  "04||X||Y" with a 256 bit curve would
>>>>>> have a
>>>>>> length of 1+32+32 = 65 bytes. A 384 bit curve would have length
>>>>>> 1+48+48=97
>>>>>>
>>>>>>>
>>>>>>> It's much easier to convert from the current octet string encoding to
>>>>>>> ECPoint or BITSTRING (SPKI) or Tag 86 (CVCs).
>>>>>>
>>>>>> Yes, I should have done that with the original ECC code.
>>>>>>
>>>>>>>
>>>>>>> Andreas
>>>>>>>
>>>>>>> On 11/04/2013 08:54 PM, Douglas E. Engert wrote:
>>>>>>>> During the discussion on pull request #191 "Enhanced ECC handling
>>>>>>>> (#191)"
>>>>>>>> It has become apparent that:
>>>>>>>>
>>>>>>>>          Commit 457426543dfa02597895d57013dde94cc9e7d038
>>>>>>>>          Author: sjoblomt <[hidden email]>  2012-11-28
>>>>>>>> 04:52:43
>>>>>>>>          Committer: Viktor Tarasov <[hidden email]>
>>>>>>>> 2012-12-03 07:37:13
>>>>>>>>          "MyEID ECDSA Support"
>>>>>>>>
>>>>>>>> had made a fundamental change in the way the ecpointQ was stored.
>>>>>>>>
>>>>>>>> The previous code stored the ecpointQ as an ANS1 DER OCTET_STRING,
>>>>>>>> and the decode and encode routines in pkcs15-pubkey.c just copied
>>>>>>>> the DER encoding.
>>>>>>>>
>>>>>>>> Comments in pkcs15-pubkey.c had:
>>>>>>>>
>>>>>>>>         /*
>>>>>>>>          * We are storing the ec_pointQ as a octet string.
>>>>>>>>          * Thus we will just copy the string.
>>>>>>>>          * But to get the field length we decode it.
>>>>>>>>          */
>>>>>>>>
>>>>>>>> pkcs15.h had:
>>>>>>>>         sc_pkcs15_der_t        ecpointQ; /* note this is der */
>>>>>>>>
>>>>>>>> The "myEID ECDSA Support" changed the way the ecpointQ was stored
>>>>>>>> from an ASN1 DER OCTET STRING to just storing "an arbitrary
>>>>>>>> string of octets (eight-bit values)" i.e. the value of the
>>>>>>>> ASN1 DER OCTET STRING.
>>>>>>>>
>>>>>>>> I have issues with how the "myEID  ECDSA Support"  was handled:
>>>>>>>>
>>>>>>>>         * This change was made at the last minute before the 0.13.0
>>>>>>>> release.
>>>>>>>>
>>>>>>>>         * No questions or comments were posted to the mailing list
>>>>>>>>           to ask why the ecpointQ was stored as DER.
>>>>>>>>
>>>>>>>>         * No comments where made to the mailing list that this
>>>>>>>>           fundamental change was made.
>>>>>>>>
>>>>>>>>         * No changes where made to the comments to indicate
>>>>>>>>           only the value of the ecpointQ was being stored.
>>>>>>>>           The coments still indicate DER.
>>>>>>>>
>>>>>>>>         * No attempt was made to change the other two card drivers
>>>>>>>>           that supported EC was made.
>>>>>>>>
>>>>>>>>         * This broke the SmartCard-HSM code. CardContact Software &
>>>>>>>> System Consulting
>>>>>>>>           reported: "Yes, I remember I even complained about this
>>>>>>>> last minute change
>>>>>>>>           for the 0.13 release, because it broke our SmartCard-HSM
>>>>>>>> code..."
>>>>>>>>
>>>>>>>> The myEID changes did not break the PIV code right away, as the PIV
>>>>>>>> kept
>>>>>>>> storing and using the ecpointQ as a DER OCTET STRING. But newer
>>>>>>>> changes
>>>>>>>> such as Pull request #191 "Enhanced ECC handling" ran into the
>>>>>>>> problems with how the ecpointQ was now being stored.
>>>>>>>>
>>>>>>>> Because of all of this,
>>>>>>>>
>>>>>>>>        (1) I am withdrawing the #191 pull request for now, so it can
>>>>>>>> be rewritten.
>>>>>>>>
>>>>>>>>        (2) I intend to proposed changes to continue to store the
>>>>>>>> ecpointQ
>>>>>>>>            as the value of the DER encoding as it is the more
>>>>>>>> straight forward way.
>>>>>>>>            I will also fix up the comments to point this out...
>>>>>>>>
>>>>>>>>        (3) I intend to submit changes to the PIV card driver and any
>>>>>>>> other code
>>>>>>>>            that depends on how the ecpointQ is stored.
>>>>>>>>
>>>>>>>>        (4) Resubmit a modified "Enhanced ECC handling".
>>>>>>>>
>>>>>>>> We as a project, when we submit code changes like this, the changes
>>>>>>>> need a
>>>>>>>> good explanation of what code is being changed and what issues might
>>>>>>>> arise from the changes, especially if:
>>>>>>>>
>>>>>>>>        * Some code used by everyone is being changed in some
>>>>>>>> fundamental way.
>>>>>>>>
>>>>>>>>        * Some code might effect card drivers that the author of the
>>>>>>>> change can not test.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Comments?
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>> November Webinars for C, C++, Fortran Developers
>>>>>>> Accelerate application performance with scalable programming models.
>>>>>>> Explore
>>>>>>> techniques for threading, error checking, porting, and tuning. Get
>>>>>>> the most
>>>>>>> from the latest Intel processors and coprocessors. See abstracts and
>>>>>>> register
>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Opensc-devel mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> .
>>>
>>
>
> .
>

--

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

------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problems with MyEID and fundamental changes to the storing of the ECC ecpointQ

Douglas E. Engert
IN regard to pull request #197...

On 11/25/2013 2:07 AM, Andreas Schwier wrote:
> Hmmm,
>
> sc_pkcs15_encode_pubkey_ec_spki() encodes the point as BIT STRING - it
> takes the raw public key (04 || X || Y) and puts it in the BIT STRING
> object.

OK, I see sc_pkcs15_encode_pubkey_ec_spki does it correctly.

But I also see some other issues.

pkcs15-tool.c has a pubkey_pem_encode that tries to output a PEM
encoded pubkey which is in fact a SPKI.  The pubkey_pem_encode
is broken for EC. It puts the ASN1 DER OCTET STRING encoding of
the ecpointQ in the BIT STRING.  It works for for RSA and looks like it
was written to work for GOST, as it has GOST specific code to handle the
alg_id params. I would like to see pubkey_pem_encode replaced with a call
to a new sc_pkcs15_encode_pubkey_as_spki. (See below.)


The modifications I withdrew, Pull request 191, had mods to
pkcs15-tool to use a "spki" routine from the library, so RSA, EC,
and GOST would all produce a PEM public key.

For testing, (See attached patch) I have modified the pkcs15-tool.c
to call both  sc_pkcs15_encode_pubkey_with_param and the older
pubkey_pem_encode.


The sc_pkcs15_encode_pubkey_with_param is inconsistent.
For EC, sc_pkcs15_encode_pubkey_with_param produces a spki, but
not for any other algorithms.  According to PKCS#15, RSA, DSA, EC
and (I assume GOST) could have their pubkeys stored as spki.


I would like to see the sc_pkcs15_encode_pubkey_with_param
replaced with a new sc_pkcs15_encode_pubkey_as_spki
based on sc_pkcs15_encode_pubkey_ec_spki. The new routine
would have a case statement that would handle any params, and
handle the fact that the ecpointQ is raw.
The other algorithms could use the sc_ pkcs15_encode_pubkey_* routines.
if possible.

For example sc_pkcs15_encode_pubkey_as_spki
would handle the GOST parameters like the pubkey_pem_encode.

I had something like this in Pull request 191.

pkcs15-tool.c would then replace the pubkey_pem_encode
with sc_pkcs15_encode_pubkey_as_spki.

Although the pkcs15-piv.c still works, but not with pkcs15-tool.c
I also had to modify the pkcs15-piv.c to call
sc_pkcs15_encode_pubkey_with_param, but would like to have it
use the sc_pkcs15_encode_pubkey_as_spki.

If the sc_pkcs15_encode_pubkey_as_spki worked as expected, I
could greatly simplify the code in pkcs15-piv.c.

I am going to try and look at the sc_pkcs15_encode_pubkey_as_spki
tomorrow.

Comments? Especially from Viktor, and the myEID people.

>
> Andreas
>
> On 11/23/2013 05:02 PM, Douglas E. Engert wrote:
>> Thanks.
>>
>> I have beeb thinking over the weekend, and I think I have found some
>> issues with the encoding of the ecpointQ, There are two ways it is encoded
>> depending on the context. Normally it would be DER ASN1 OCTET STRING.
>> But in a SPKI, the raw ecpointQ is encoded in bit string. The OpenSC
>> routines are encoding the DER ASN1 OCTET STRING in the BIT STRING,
>> which is the way the RSA modulus and exponent are done, but for
>> some historical reasons, the ecpointQ in encoded directly
>> in the BIT STRING.
>>
>> So although your code may work, the SPKI is not correct. And this
>> could cause problems id the SPKI was used or provided in some
>> other way for some other card.
>>
>> I believe I tried to address this in previous notes.
>>
>> Will look closed on Monday.
>>
>>
>>
>>
>> On 11/23/2013 3:47 AM, Andreas Schwier wrote:
>>> Hi Douglas,
>>>
>>> good news. The user manual is at the CDN [1]. You can use a
>>> SmartCard-HSM to get access [2]. However I've attached the current
>>> version.
>>>
>>> Andreas
>>>
>>> [1] https://devnet.cardcontact.de/projects/smartcard-hsm/documents
>>> [2] http://www.cardcontact.de/cdn/activation.html
>>>
>>>
>>> On 11/21/2013 09:24 PM, Douglas E. Engert wrote:
>>>> I received the two cards, and USB stick today.
>>>> Thanks.
>>>>
>>>> Is there any documentation?
>>>>
>>>> I have also started to look at the pull request #197.
>>>> It compiles and the PIV card works with ECC but I need to look closer
>>>> at how pkcs11-tool and pkcs15-tool handle pub keys. something does not
>>>> look right. It may not be in you new code.
>>>>
>>>>
>>>>
>>>> On 11/15/2013 5:00 AM, Andreas Schwier wrote:
>>>>> Hi Douglas,
>>>>>
>>>>> I've opened a pull request that changes the format in which EC Public
>>>>> Keys are stored as direct values in PuKDF. This way domain parameter
>>>>> are
>>>>> preserved during the encode / decode cycle that happens in
>>>>> framework-pkcs15.c/pkcs15_gen_keypair.
>>>>>
>>>>> The code tries to preserve backwards compatibility with cards that
>>>>> already store the EC Public Key in raw format.
>>>>>
>>>>> @Toni: Please check with myEID card.
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Andreas
>>>>>
>>>>>
>>>>> On 11/14/2013 04:31 PM, Douglas E. Engert wrote:
>>>>>>
>>>>>>
>>>>>> On 11/14/2013 3:38 AM, Andreas Schwier wrote:
>>>>>>> Hi Douglas,
>>>>>>>
>>>>>>> I've done a full regression test and the code still works with the
>>>>>>> SmartCard-HSM.
>>>>>>>
>>>>>>> However the EC_PARAMS are still not available at the PKCS#11
>>>>>>> interface
>>>>>>> for a newly generated key. I will have a look at that issue.
>>>>>>
>>>>>> Look at what I had to do in sc_pkcs15_pubkey_from spki to copy the
>>>>>> params around. Similar code may be needed somewhere else.
>>>>>>
>>>>>>>
>>>>>>> Andreas
>>>>>>>
>>>>>>> On 11/11/2013 09:31 PM, Douglas E. Engert wrote:
>>>>>>>> I have not heard anything from the MyEID developers. The discussion
>>>>>>>> of the
>>>>>>>> problem started on 11/04/13, last week.
>>>>>>>>
>>>>>>>> Unless I here anything, I plain on committing #194 tomorrow,
>>>>>>>> 11/12/13.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 11/6/2013 5:01 PM, Douglas E. Engert wrote:
>>>>>>>>> Please see pull request #194,
>>>>>>>>> https://github.com/OpenSC/OpenSC/pull/194
>>>>>>>>> This address the ecpointQ issues as outlined below.
>>>>>>>>>
>>>>>>>>> It partially addresses the issue that EC parameters are stored
>>>>>>>>> in two
>>>>>>>>> places.
>>>>>>>>>
>>>>>>>>> It stores the ecpointQ as raw in the pubkey->ec.u.ecpointQ, and
>>>>>>>>> stored
>>>>>>>>> it in
>>>>>>>>> DER in pubkey->data. Note the framework-pkcs15.c will use the
>>>>>>>>> pubkey->data
>>>>>>>>> for the CKA_EC_POINT attribute.
>>>>>>>>>
>>>>>>>>> I think it will address Tim's issues with using the pubkey from a
>>>>>>>>> certificate
>>>>>>>>> with PIV cards, as the problem was related.
>>>>>>>>>
>>>>>>>>> Comments?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 11/5/2013 8:28 AM, Douglas E. Engert wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 11/5/2013 7:48 AM, Andreas Schwier wrote:
>>>>>>>>>>> Hi Douglas,
>>>>>>>>>>>
>>>>>>>>>>> I fully agree with your position, however I think the current
>>>>>>>>>>> encoding
>>>>>>>>>>> based on X9.62 chapter A.5.7 should remain rather than changing
>>>>>>>>>>> again to
>>>>>>>>>>> the ECPoint DER encoding from chapter E.6 of the same standard.
>>>>>>>>>>
>>>>>>>>>> I believe that is what I said in (2) below:
>>>>>>>>>>          "I intend to proposed changes to continue to store the
>>>>>>>>>> ecpointQ
>>>>>>>>>>           as the *value* of the DER encoding as it is the more
>>>>>>>>>> straight
>>>>>>>>>> forward way."
>>>>>>>>>>
>>>>>>>>>> By "continue" I meant to use what is the git master, but change
>>>>>>>>>> the
>>>>>>>>>> comments
>>>>>>>>>> as there is also a problem of semantics, as "octet string" could
>>>>>>>>>> refer to a
>>>>>>>>>> a ASN1 DER OCTET STRING or to its value, especially as it is
>>>>>>>>>> defined as:
>>>>>>>>>> sc_pkcs15_der_t        ecpointQ; /* note this is der */
>>>>>>>>>> With der being uses twice.
>>>>>>>>>>
>>>>>>>>>> For an uncompressed ecpointQ  "04||X||Y" with a 256 bit curve
>>>>>>>>>> would
>>>>>>>>>> have a
>>>>>>>>>> length of 1+32+32 = 65 bytes. A 384 bit curve would have length
>>>>>>>>>> 1+48+48=97
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> It's much easier to convert from the current octet string
>>>>>>>>>>> encoding to
>>>>>>>>>>> ECPoint or BITSTRING (SPKI) or Tag 86 (CVCs).
>>>>>>>>>>
>>>>>>>>>> Yes, I should have done that with the original ECC code.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Andreas
>>>>>>>>>>>
>>>>>>>>>>> On 11/04/2013 08:54 PM, Douglas E. Engert wrote:
>>>>>>>>>>>> During the discussion on pull request #191 "Enhanced ECC
>>>>>>>>>>>> handling
>>>>>>>>>>>> (#191)"
>>>>>>>>>>>> It has become apparent that:
>>>>>>>>>>>>
>>>>>>>>>>>>            Commit 457426543dfa02597895d57013dde94cc9e7d038
>>>>>>>>>>>>            Author: sjoblomt <[hidden email]>  2012-11-28
>>>>>>>>>>>> 04:52:43
>>>>>>>>>>>>            Committer: Viktor Tarasov <[hidden email]>
>>>>>>>>>>>> 2012-12-03 07:37:13
>>>>>>>>>>>>            "MyEID ECDSA Support"
>>>>>>>>>>>>
>>>>>>>>>>>> had made a fundamental change in the way the ecpointQ was
>>>>>>>>>>>> stored.
>>>>>>>>>>>>
>>>>>>>>>>>> The previous code stored the ecpointQ as an ANS1 DER
>>>>>>>>>>>> OCTET_STRING,
>>>>>>>>>>>> and the decode and encode routines in pkcs15-pubkey.c just
>>>>>>>>>>>> copied
>>>>>>>>>>>> the DER encoding.
>>>>>>>>>>>>
>>>>>>>>>>>> Comments in pkcs15-pubkey.c had:
>>>>>>>>>>>>
>>>>>>>>>>>>           /*
>>>>>>>>>>>>            * We are storing the ec_pointQ as a octet string.
>>>>>>>>>>>>            * Thus we will just copy the string.
>>>>>>>>>>>>            * But to get the field length we decode it.
>>>>>>>>>>>>            */
>>>>>>>>>>>>
>>>>>>>>>>>> pkcs15.h had:
>>>>>>>>>>>>           sc_pkcs15_der_t        ecpointQ; /* note this is der */
>>>>>>>>>>>>
>>>>>>>>>>>> The "myEID ECDSA Support" changed the way the ecpointQ was
>>>>>>>>>>>> stored
>>>>>>>>>>>> from an ASN1 DER OCTET STRING to just storing "an arbitrary
>>>>>>>>>>>> string of octets (eight-bit values)" i.e. the value of the
>>>>>>>>>>>> ASN1 DER OCTET STRING.
>>>>>>>>>>>>
>>>>>>>>>>>> I have issues with how the "myEID  ECDSA Support"  was handled:
>>>>>>>>>>>>
>>>>>>>>>>>>           * This change was made at the last minute before the
>>>>>>>>>>>> 0.13.0
>>>>>>>>>>>> release.
>>>>>>>>>>>>
>>>>>>>>>>>>           * No questions or comments were posted to the
>>>>>>>>>>>> mailing list
>>>>>>>>>>>>             to ask why the ecpointQ was stored as DER.
>>>>>>>>>>>>
>>>>>>>>>>>>           * No comments where made to the mailing list that this
>>>>>>>>>>>>             fundamental change was made.
>>>>>>>>>>>>
>>>>>>>>>>>>           * No changes where made to the comments to indicate
>>>>>>>>>>>>             only the value of the ecpointQ was being stored.
>>>>>>>>>>>>             The coments still indicate DER.
>>>>>>>>>>>>
>>>>>>>>>>>>           * No attempt was made to change the other two card
>>>>>>>>>>>> drivers
>>>>>>>>>>>>             that supported EC was made.
>>>>>>>>>>>>
>>>>>>>>>>>>           * This broke the SmartCard-HSM code. CardContact
>>>>>>>>>>>> Software &
>>>>>>>>>>>> System Consulting
>>>>>>>>>>>>             reported: "Yes, I remember I even complained about
>>>>>>>>>>>> this
>>>>>>>>>>>> last minute change
>>>>>>>>>>>>             for the 0.13 release, because it broke our
>>>>>>>>>>>> SmartCard-HSM
>>>>>>>>>>>> code..."
>>>>>>>>>>>>
>>>>>>>>>>>> The myEID changes did not break the PIV code right away, as the
>>>>>>>>>>>> PIV
>>>>>>>>>>>> kept
>>>>>>>>>>>> storing and using the ecpointQ as a DER OCTET STRING. But newer
>>>>>>>>>>>> changes
>>>>>>>>>>>> such as Pull request #191 "Enhanced ECC handling" ran into the
>>>>>>>>>>>> problems with how the ecpointQ was now being stored.
>>>>>>>>>>>>
>>>>>>>>>>>> Because of all of this,
>>>>>>>>>>>>
>>>>>>>>>>>>          (1) I am withdrawing the #191 pull request for now, so
>>>>>>>>>>>> it can
>>>>>>>>>>>> be rewritten.
>>>>>>>>>>>>
>>>>>>>>>>>>          (2) I intend to proposed changes to continue to store
>>>>>>>>>>>> the
>>>>>>>>>>>> ecpointQ
>>>>>>>>>>>>              as the value of the DER encoding as it is the more
>>>>>>>>>>>> straight forward way.
>>>>>>>>>>>>              I will also fix up the comments to point this out...
>>>>>>>>>>>>
>>>>>>>>>>>>          (3) I intend to submit changes to the PIV card driver
>>>>>>>>>>>> and any
>>>>>>>>>>>> other code
>>>>>>>>>>>>              that depends on how the ecpointQ is stored.
>>>>>>>>>>>>
>>>>>>>>>>>>          (4) Resubmit a modified "Enhanced ECC handling".
>>>>>>>>>>>>
>>>>>>>>>>>> We as a project, when we submit code changes like this, the
>>>>>>>>>>>> changes
>>>>>>>>>>>> need a
>>>>>>>>>>>> good explanation of what code is being changed and what issues
>>>>>>>>>>>> might
>>>>>>>>>>>> arise from the changes, especially if:
>>>>>>>>>>>>
>>>>>>>>>>>>          * Some code used by everyone is being changed in some
>>>>>>>>>>>> fundamental way.
>>>>>>>>>>>>
>>>>>>>>>>>>          * Some code might effect card drivers that the author of
>>>>>>>>>>>> the
>>>>>>>>>>>> change can not test.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Comments?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> November Webinars for C, C++, Fortran Developers
>>>>>>>>>>> Accelerate application performance with scalable programming
>>>>>>>>>>> models.
>>>>>>>>>>> Explore
>>>>>>>>>>> techniques for threading, error checking, porting, and tuning.
>>>>>>>>>>> Get
>>>>>>>>>>> the most
>>>>>>>>>>> from the latest Intel processors and coprocessors. See abstracts
>>>>>>>>>>> and
>>>>>>>>>>> register
>>>>>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Opensc-devel mailing list
>>>>>>>>>>> [hidden email]
>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> .
>>>>>>>
>>>>>>
>>>>>
>>>>> .
>>>>>
>>>>
>>>
>>
>
> .
>
--

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

------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

testing-pull-197.git.diff (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problems with MyEID and fundamental changes to the storing of the ECC ecpointQ

Douglas E. Engert
Attached is a set of mods to be applied on top of Pull request 197
and replaces the patches I sent yesterday 11/25.

I am looking for comments from Victkor and MyEID developers.

These changes do the following:

   sc_pkcs15_encode_pubkey_as_spki replaces sc_pkcs15_encode_pubkey_with_param.
   The name implies what the format of the returned value, a SPKI.

   The support for spki as a pkcs15 format of a pubkey, is extended to
   work for any algorithm not just EC pubkeys. PKCS#15 appears to allow this.

   sc_pkcs15_decode_pubkey_with_param will look for a SPKI
   and attempt to use it for any algorithm, including RSA.
   (RSA is the null case, as there are no algorithm parameters.)

   sc_pkcs15_encode_pubkey_as_spki is exported from libopensc

   pkcs15-piv.c will use sc_pkcs15_encode_pubkey_as_spki to load public keys
   as SPKI for RSA and EC.

   The pubkey->data is never a SPKI, it is the DER encoding of the
   pubkey without the parameters.  If an spki is needed, use the
   sc_pkcs15_encode_pubkey_as_spki  to get the DER encoding of the spki.

   As in the previous set of patches, pkcs15-tool.c will output both
   sc_pkcs15_decode_pubkey_with_param and its internal.
   This was left for testing, and the pubkey_pem_encode should be deleted


TODO:

   The pubkey_pem_encode has special code for GOST. Vicktor, can you look at this?
   See the "case SC_ALGORITHM_GOSTR3410:"  in sc_pkcs15_encode_pubkey_as_spki
   in pkcs15-pubkey.c that should handle this.

   Routines in pkcs15init may need options to allow the use of storing
   an SPKI version of a pubkey. There may be cards that can not handle it.

   sc_pkcs15_encode_pubkey, and sc_pkcs15_decode_pubkey should continue
   to work as before. The major change is if the buf starts with a sequence,
   it will be assmed to be a spki.

   There is still the issue that algorithm parameters can be defined in
   two places, off the algorithm_id->params (which is used by ASN1 when
   encoding and decoding an algorithm) and in the pubkey.u.* for EC and
   GOST and DSA.
   This should be fixed to only use the algorithm_id->params. There may
   be places in the code where. This is not new to pull request #197,
   buy goes back to when the MyEID code was added.


   The MyEID people have not responded to any of the recent discussions
   about ecpointQ format or EC parameters.




On 11/25/2013 2:21 PM, Douglas E. Engert wrote:

> IN regard to pull request #197...
>
> On 11/25/2013 2:07 AM, Andreas Schwier wrote:
>> Hmmm,
>>
>> sc_pkcs15_encode_pubkey_ec_spki() encodes the point as BIT STRING - it
>> takes the raw public key (04 || X || Y) and puts it in the BIT STRING
>> object.
>
> OK, I see sc_pkcs15_encode_pubkey_ec_spki does it correctly.
>
> But I also see some other issues.
>
> pkcs15-tool.c has a pubkey_pem_encode that tries to output a PEM
> encoded pubkey which is in fact a SPKI.  The pubkey_pem_encode
> is broken for EC. It puts the ASN1 DER OCTET STRING encoding of
> the ecpointQ in the BIT STRING.  It works for for RSA and looks like it
> was written to work for GOST, as it has GOST specific code to handle the
> alg_id params. I would like to see pubkey_pem_encode replaced with a call
> to a new sc_pkcs15_encode_pubkey_as_spki. (See below.)
>
>
> The modifications I withdrew, Pull request 191, had mods to
> pkcs15-tool to use a "spki" routine from the library, so RSA, EC,
> and GOST would all produce a PEM public key.
>
> For testing, (See attached patch) I have modified the pkcs15-tool.c
> to call both  sc_pkcs15_encode_pubkey_with_param and the older
> pubkey_pem_encode.
>
>
> The sc_pkcs15_encode_pubkey_with_param is inconsistent.
> For EC, sc_pkcs15_encode_pubkey_with_param produces a spki, but
> not for any other algorithms.  According to PKCS#15, RSA, DSA, EC
> and (I assume GOST) could have their pubkeys stored as spki.
>
>
> I would like to see the sc_pkcs15_encode_pubkey_with_param
> replaced with a new sc_pkcs15_encode_pubkey_as_spki
> based on sc_pkcs15_encode_pubkey_ec_spki. The new routine
> would have a case statement that would handle any params, and
> handle the fact that the ecpointQ is raw.
> The other algorithms could use the sc_ pkcs15_encode_pubkey_* routines.
> if possible.
>
> For example sc_pkcs15_encode_pubkey_as_spki
> would handle the GOST parameters like the pubkey_pem_encode.
>
> I had something like this in Pull request 191.
>
> pkcs15-tool.c would then replace the pubkey_pem_encode
> with sc_pkcs15_encode_pubkey_as_spki.
>
> Although the pkcs15-piv.c still works, but not with pkcs15-tool.c
> I also had to modify the pkcs15-piv.c to call
> sc_pkcs15_encode_pubkey_with_param, but would like to have it
> use the sc_pkcs15_encode_pubkey_as_spki.
>
> If the sc_pkcs15_encode_pubkey_as_spki worked as expected, I
> could greatly simplify the code in pkcs15-piv.c.
>
> I am going to try and look at the sc_pkcs15_encode_pubkey_as_spki
> tomorrow.
>
> Comments? Especially from Viktor, and the myEID people.
>
>>
>> Andreas
>>
>> On 11/23/2013 05:02 PM, Douglas E. Engert wrote:
>>> Thanks.
>>>
>>> I have beeb thinking over the weekend, and I think I have found some
>>> issues with the encoding of the ecpointQ, There are two ways it is encoded
>>> depending on the context. Normally it would be DER ASN1 OCTET STRING.
>>> But in a SPKI, the raw ecpointQ is encoded in bit string. The OpenSC
>>> routines are encoding the DER ASN1 OCTET STRING in the BIT STRING,
>>> which is the way the RSA modulus and exponent are done, but for
>>> some historical reasons, the ecpointQ in encoded directly
>>> in the BIT STRING.
>>>
>>> So although your code may work, the SPKI is not correct. And this
>>> could cause problems id the SPKI was used or provided in some
>>> other way for some other card.
>>>
>>> I believe I tried to address this in previous notes.
>>>
>>> Will look closed on Monday.
>>>
>>>
>>>
>>>
>>> On 11/23/2013 3:47 AM, Andreas Schwier wrote:
>>>> Hi Douglas,
>>>>
>>>> good news. The user manual is at the CDN [1]. You can use a
>>>> SmartCard-HSM to get access [2]. However I've attached the current
>>>> version.
>>>>
>>>> Andreas
>>>>
>>>> [1] https://devnet.cardcontact.de/projects/smartcard-hsm/documents
>>>> [2] http://www.cardcontact.de/cdn/activation.html
>>>>
>>>>
>>>> On 11/21/2013 09:24 PM, Douglas E. Engert wrote:
>>>>> I received the two cards, and USB stick today.
>>>>> Thanks.
>>>>>
>>>>> Is there any documentation?
>>>>>
>>>>> I have also started to look at the pull request #197.
>>>>> It compiles and the PIV card works with ECC but I need to look closer
>>>>> at how pkcs11-tool and pkcs15-tool handle pub keys. something does not
>>>>> look right. It may not be in you new code.
>>>>>
>>>>>
>>>>>
>>>>> On 11/15/2013 5:00 AM, Andreas Schwier wrote:
>>>>>> Hi Douglas,
>>>>>>
>>>>>> I've opened a pull request that changes the format in which EC Public
>>>>>> Keys are stored as direct values in PuKDF. This way domain parameter
>>>>>> are
>>>>>> preserved during the encode / decode cycle that happens in
>>>>>> framework-pkcs15.c/pkcs15_gen_keypair.
>>>>>>
>>>>>> The code tries to preserve backwards compatibility with cards that
>>>>>> already store the EC Public Key in raw format.
>>>>>>
>>>>>> @Toni: Please check with myEID card.
>>>>>>
>>>>>> Kind regards,
>>>>>>
>>>>>> Andreas
>>>>>>
>>>>>>
>>>>>> On 11/14/2013 04:31 PM, Douglas E. Engert wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 11/14/2013 3:38 AM, Andreas Schwier wrote:
>>>>>>>> Hi Douglas,
>>>>>>>>
>>>>>>>> I've done a full regression test and the code still works with the
>>>>>>>> SmartCard-HSM.
>>>>>>>>
>>>>>>>> However the EC_PARAMS are still not available at the PKCS#11
>>>>>>>> interface
>>>>>>>> for a newly generated key. I will have a look at that issue.
>>>>>>>
>>>>>>> Look at what I had to do in sc_pkcs15_pubkey_from spki to copy the
>>>>>>> params around. Similar code may be needed somewhere else.
>>>>>>>
>>>>>>>>
>>>>>>>> Andreas
>>>>>>>>
>>>>>>>> On 11/11/2013 09:31 PM, Douglas E. Engert wrote:
>>>>>>>>> I have not heard anything from the MyEID developers. The discussion
>>>>>>>>> of the
>>>>>>>>> problem started on 11/04/13, last week.
>>>>>>>>>
>>>>>>>>> Unless I here anything, I plain on committing #194 tomorrow,
>>>>>>>>> 11/12/13.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 11/6/2013 5:01 PM, Douglas E. Engert wrote:
>>>>>>>>>> Please see pull request #194,
>>>>>>>>>> https://github.com/OpenSC/OpenSC/pull/194
>>>>>>>>>> This address the ecpointQ issues as outlined below.
>>>>>>>>>>
>>>>>>>>>> It partially addresses the issue that EC parameters are stored
>>>>>>>>>> in two
>>>>>>>>>> places.
>>>>>>>>>>
>>>>>>>>>> It stores the ecpointQ as raw in the pubkey->ec.u.ecpointQ, and
>>>>>>>>>> stored
>>>>>>>>>> it in
>>>>>>>>>> DER in pubkey->data. Note the framework-pkcs15.c will use the
>>>>>>>>>> pubkey->data
>>>>>>>>>> for the CKA_EC_POINT attribute.
>>>>>>>>>>
>>>>>>>>>> I think it will address Tim's issues with using the pubkey from a
>>>>>>>>>> certificate
>>>>>>>>>> with PIV cards, as the problem was related.
>>>>>>>>>>
>>>>>>>>>> Comments?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 11/5/2013 8:28 AM, Douglas E. Engert wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 11/5/2013 7:48 AM, Andreas Schwier wrote:
>>>>>>>>>>>> Hi Douglas,
>>>>>>>>>>>>
>>>>>>>>>>>> I fully agree with your position, however I think the current
>>>>>>>>>>>> encoding
>>>>>>>>>>>> based on X9.62 chapter A.5.7 should remain rather than changing
>>>>>>>>>>>> again to
>>>>>>>>>>>> the ECPoint DER encoding from chapter E.6 of the same standard.
>>>>>>>>>>>
>>>>>>>>>>> I believe that is what I said in (2) below:
>>>>>>>>>>>          "I intend to proposed changes to continue to store the
>>>>>>>>>>> ecpointQ
>>>>>>>>>>>           as the *value* of the DER encoding as it is the more
>>>>>>>>>>> straight
>>>>>>>>>>> forward way."
>>>>>>>>>>>
>>>>>>>>>>> By "continue" I meant to use what is the git master, but change
>>>>>>>>>>> the
>>>>>>>>>>> comments
>>>>>>>>>>> as there is also a problem of semantics, as "octet string" could
>>>>>>>>>>> refer to a
>>>>>>>>>>> a ASN1 DER OCTET STRING or to its value, especially as it is
>>>>>>>>>>> defined as:
>>>>>>>>>>> sc_pkcs15_der_t        ecpointQ; /* note this is der */
>>>>>>>>>>> With der being uses twice.
>>>>>>>>>>>
>>>>>>>>>>> For an uncompressed ecpointQ  "04||X||Y" with a 256 bit curve
>>>>>>>>>>> would
>>>>>>>>>>> have a
>>>>>>>>>>> length of 1+32+32 = 65 bytes. A 384 bit curve would have length
>>>>>>>>>>> 1+48+48=97
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> It's much easier to convert from the current octet string
>>>>>>>>>>>> encoding to
>>>>>>>>>>>> ECPoint or BITSTRING (SPKI) or Tag 86 (CVCs).
>>>>>>>>>>>
>>>>>>>>>>> Yes, I should have done that with the original ECC code.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Andreas
>>>>>>>>>>>>
>>>>>>>>>>>> On 11/04/2013 08:54 PM, Douglas E. Engert wrote:
>>>>>>>>>>>>> During the discussion on pull request #191 "Enhanced ECC
>>>>>>>>>>>>> handling
>>>>>>>>>>>>> (#191)"
>>>>>>>>>>>>> It has become apparent that:
>>>>>>>>>>>>>
>>>>>>>>>>>>>            Commit 457426543dfa02597895d57013dde94cc9e7d038
>>>>>>>>>>>>>            Author: sjoblomt <[hidden email]>  2012-11-28
>>>>>>>>>>>>> 04:52:43
>>>>>>>>>>>>>            Committer: Viktor Tarasov <[hidden email]>
>>>>>>>>>>>>> 2012-12-03 07:37:13
>>>>>>>>>>>>>            "MyEID ECDSA Support"
>>>>>>>>>>>>>
>>>>>>>>>>>>> had made a fundamental change in the way the ecpointQ was
>>>>>>>>>>>>> stored.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The previous code stored the ecpointQ as an ANS1 DER
>>>>>>>>>>>>> OCTET_STRING,
>>>>>>>>>>>>> and the decode and encode routines in pkcs15-pubkey.c just
>>>>>>>>>>>>> copied
>>>>>>>>>>>>> the DER encoding.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Comments in pkcs15-pubkey.c had:
>>>>>>>>>>>>>
>>>>>>>>>>>>>           /*
>>>>>>>>>>>>>            * We are storing the ec_pointQ as a octet string.
>>>>>>>>>>>>>            * Thus we will just copy the string.
>>>>>>>>>>>>>            * But to get the field length we decode it.
>>>>>>>>>>>>>            */
>>>>>>>>>>>>>
>>>>>>>>>>>>> pkcs15.h had:
>>>>>>>>>>>>>           sc_pkcs15_der_t        ecpointQ; /* note this is der */
>>>>>>>>>>>>>
>>>>>>>>>>>>> The "myEID ECDSA Support" changed the way the ecpointQ was
>>>>>>>>>>>>> stored
>>>>>>>>>>>>> from an ASN1 DER OCTET STRING to just storing "an arbitrary
>>>>>>>>>>>>> string of octets (eight-bit values)" i.e. the value of the
>>>>>>>>>>>>> ASN1 DER OCTET STRING.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have issues with how the "myEID  ECDSA Support"  was handled:
>>>>>>>>>>>>>
>>>>>>>>>>>>>           * This change was made at the last minute before the
>>>>>>>>>>>>> 0.13.0
>>>>>>>>>>>>> release.
>>>>>>>>>>>>>
>>>>>>>>>>>>>           * No questions or comments were posted to the
>>>>>>>>>>>>> mailing list
>>>>>>>>>>>>>             to ask why the ecpointQ was stored as DER.
>>>>>>>>>>>>>
>>>>>>>>>>>>>           * No comments where made to the mailing list that this
>>>>>>>>>>>>>             fundamental change was made.
>>>>>>>>>>>>>
>>>>>>>>>>>>>           * No changes where made to the comments to indicate
>>>>>>>>>>>>>             only the value of the ecpointQ was being stored.
>>>>>>>>>>>>>             The coments still indicate DER.
>>>>>>>>>>>>>
>>>>>>>>>>>>>           * No attempt was made to change the other two card
>>>>>>>>>>>>> drivers
>>>>>>>>>>>>>             that supported EC was made.
>>>>>>>>>>>>>
>>>>>>>>>>>>>           * This broke the SmartCard-HSM code. CardContact
>>>>>>>>>>>>> Software &
>>>>>>>>>>>>> System Consulting
>>>>>>>>>>>>>             reported: "Yes, I remember I even complained about
>>>>>>>>>>>>> this
>>>>>>>>>>>>> last minute change
>>>>>>>>>>>>>             for the 0.13 release, because it broke our
>>>>>>>>>>>>> SmartCard-HSM
>>>>>>>>>>>>> code..."
>>>>>>>>>>>>>
>>>>>>>>>>>>> The myEID changes did not break the PIV code right away, as the
>>>>>>>>>>>>> PIV
>>>>>>>>>>>>> kept
>>>>>>>>>>>>> storing and using the ecpointQ as a DER OCTET STRING. But newer
>>>>>>>>>>>>> changes
>>>>>>>>>>>>> such as Pull request #191 "Enhanced ECC handling" ran into the
>>>>>>>>>>>>> problems with how the ecpointQ was now being stored.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Because of all of this,
>>>>>>>>>>>>>
>>>>>>>>>>>>>          (1) I am withdrawing the #191 pull request for now, so
>>>>>>>>>>>>> it can
>>>>>>>>>>>>> be rewritten.
>>>>>>>>>>>>>
>>>>>>>>>>>>>          (2) I intend to proposed changes to continue to store
>>>>>>>>>>>>> the
>>>>>>>>>>>>> ecpointQ
>>>>>>>>>>>>>              as the value of the DER encoding as it is the more
>>>>>>>>>>>>> straight forward way.
>>>>>>>>>>>>>              I will also fix up the comments to point this out...
>>>>>>>>>>>>>
>>>>>>>>>>>>>          (3) I intend to submit changes to the PIV card driver
>>>>>>>>>>>>> and any
>>>>>>>>>>>>> other code
>>>>>>>>>>>>>              that depends on how the ecpointQ is stored.
>>>>>>>>>>>>>
>>>>>>>>>>>>>          (4) Resubmit a modified "Enhanced ECC handling".
>>>>>>>>>>>>>
>>>>>>>>>>>>> We as a project, when we submit code changes like this, the
>>>>>>>>>>>>> changes
>>>>>>>>>>>>> need a
>>>>>>>>>>>>> good explanation of what code is being changed and what issues
>>>>>>>>>>>>> might
>>>>>>>>>>>>> arise from the changes, especially if:
>>>>>>>>>>>>>
>>>>>>>>>>>>>          * Some code used by everyone is being changed in some
>>>>>>>>>>>>> fundamental way.
>>>>>>>>>>>>>
>>>>>>>>>>>>>          * Some code might effect card drivers that the author of
>>>>>>>>>>>>> the
>>>>>>>>>>>>> change can not test.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Comments?
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> November Webinars for C, C++, Fortran Developers
>>>>>>>>>>>> Accelerate application performance with scalable programming
>>>>>>>>>>>> models.
>>>>>>>>>>>> Explore
>>>>>>>>>>>> techniques for threading, error checking, porting, and tuning.
>>>>>>>>>>>> Get
>>>>>>>>>>>> the most
>>>>>>>>>>>> from the latest Intel processors and coprocessors. See abstracts
>>>>>>>>>>>> and
>>>>>>>>>>>> register
>>>>>>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Opensc-devel mailing list
>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> .
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> .
>>>>>>
>>>>>
>>>>
>>>
>>
>> .
>>
>
>
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
--

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

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

testing-pull-197-v2.git.diff (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Problems with MyEID and fundamental changes to the storing of the ECC ecpointQ

Douglas E. Engert
If I don't hear any objections, I plan on committing #197 Tuesday 12/1
and the doing a pull request on my mods to go on top of it.


On 11/26/2013 11:36 AM, Douglas E. Engert wrote:

> Attached is a set of mods to be applied on top of Pull request 197
> and replaces the patches I sent yesterday 11/25.
>
> I am looking for comments from Victkor and MyEID developers.
>
> These changes do the following:
>
>    sc_pkcs15_encode_pubkey_as_spki replaces sc_pkcs15_encode_pubkey_with_param.
>    The name implies what the format of the returned value, a SPKI.
>
>    The support for spki as a pkcs15 format of a pubkey, is extended to
>    work for any algorithm not just EC pubkeys. PKCS#15 appears to allow this.
>
>    sc_pkcs15_decode_pubkey_with_param will look for a SPKI
>    and attempt to use it for any algorithm, including RSA.
>    (RSA is the null case, as there are no algorithm parameters.)
>
>    sc_pkcs15_encode_pubkey_as_spki is exported from libopensc
>
>    pkcs15-piv.c will use sc_pkcs15_encode_pubkey_as_spki to load public keys
>    as SPKI for RSA and EC.
>
>    The pubkey->data is never a SPKI, it is the DER encoding of the
>    pubkey without the parameters.  If an spki is needed, use the
>    sc_pkcs15_encode_pubkey_as_spki  to get the DER encoding of the spki.
>
>    As in the previous set of patches, pkcs15-tool.c will output both
>    sc_pkcs15_decode_pubkey_with_param and its internal.
>    This was left for testing, and the pubkey_pem_encode should be deleted
>
>
> TODO:
>
>    The pubkey_pem_encode has special code for GOST. Vicktor, can you look at this?
>    See the "case SC_ALGORITHM_GOSTR3410:"  in sc_pkcs15_encode_pubkey_as_spki
>    in pkcs15-pubkey.c that should handle this.
>
>    Routines in pkcs15init may need options to allow the use of storing
>    an SPKI version of a pubkey. There may be cards that can not handle it.
>
>    sc_pkcs15_encode_pubkey, and sc_pkcs15_decode_pubkey should continue
>    to work as before. The major change is if the buf starts with a sequence,
>    it will be assmed to be a spki.
>
>    There is still the issue that algorithm parameters can be defined in
>    two places, off the algorithm_id->params (which is used by ASN1 when
>    encoding and decoding an algorithm) and in the pubkey.u.* for EC and
>    GOST and DSA.
>    This should be fixed to only use the algorithm_id->params. There may
>    be places in the code where. This is not new to pull request #197,
>    buy goes back to when the MyEID code was added.
>
>
>    The MyEID people have not responded to any of the recent discussions
>    about ecpointQ format or EC parameters.
>
>
>
>
> On 11/25/2013 2:21 PM, Douglas E. Engert wrote:
>> IN regard to pull request #197...
>>
>> On 11/25/2013 2:07 AM, Andreas Schwier wrote:
>>> Hmmm,
>>>
>>> sc_pkcs15_encode_pubkey_ec_spki() encodes the point as BIT STRING - it
>>> takes the raw public key (04 || X || Y) and puts it in the BIT STRING
>>> object.
>>
>> OK, I see sc_pkcs15_encode_pubkey_ec_spki does it correctly.
>>
>> But I also see some other issues.
>>
>> pkcs15-tool.c has a pubkey_pem_encode that tries to output a PEM
>> encoded pubkey which is in fact a SPKI.  The pubkey_pem_encode
>> is broken for EC. It puts the ASN1 DER OCTET STRING encoding of
>> the ecpointQ in the BIT STRING.  It works for for RSA and looks like it
>> was written to work for GOST, as it has GOST specific code to handle the
>> alg_id params. I would like to see pubkey_pem_encode replaced with a call
>> to a new sc_pkcs15_encode_pubkey_as_spki. (See below.)
>>
>>
>> The modifications I withdrew, Pull request 191, had mods to
>> pkcs15-tool to use a "spki" routine from the library, so RSA, EC,
>> and GOST would all produce a PEM public key.
>>
>> For testing, (See attached patch) I have modified the pkcs15-tool.c
>> to call both  sc_pkcs15_encode_pubkey_with_param and the older
>> pubkey_pem_encode.
>>
>>
>> The sc_pkcs15_encode_pubkey_with_param is inconsistent.
>> For EC, sc_pkcs15_encode_pubkey_with_param produces a spki, but
>> not for any other algorithms.  According to PKCS#15, RSA, DSA, EC
>> and (I assume GOST) could have their pubkeys stored as spki.
>>
>>
>> I would like to see the sc_pkcs15_encode_pubkey_with_param
>> replaced with a new sc_pkcs15_encode_pubkey_as_spki
>> based on sc_pkcs15_encode_pubkey_ec_spki. The new routine
>> would have a case statement that would handle any params, and
>> handle the fact that the ecpointQ is raw.
>> The other algorithms could use the sc_ pkcs15_encode_pubkey_* routines.
>> if possible.
>>
>> For example sc_pkcs15_encode_pubkey_as_spki
>> would handle the GOST parameters like the pubkey_pem_encode.
>>
>> I had something like this in Pull request 191.
>>
>> pkcs15-tool.c would then replace the pubkey_pem_encode
>> with sc_pkcs15_encode_pubkey_as_spki.
>>
>> Although the pkcs15-piv.c still works, but not with pkcs15-tool.c
>> I also had to modify the pkcs15-piv.c to call
>> sc_pkcs15_encode_pubkey_with_param, but would like to have it
>> use the sc_pkcs15_encode_pubkey_as_spki.
>>
>> If the sc_pkcs15_encode_pubkey_as_spki worked as expected, I
>> could greatly simplify the code in pkcs15-piv.c.
>>
>> I am going to try and look at the sc_pkcs15_encode_pubkey_as_spki
>> tomorrow.
>>
>> Comments? Especially from Viktor, and the myEID people.
>>
>>>
>>> Andreas
>>>
>>> On 11/23/2013 05:02 PM, Douglas E. Engert wrote:
>>>> Thanks.
>>>>
>>>> I have beeb thinking over the weekend, and I think I have found some
>>>> issues with the encoding of the ecpointQ, There are two ways it is encoded
>>>> depending on the context. Normally it would be DER ASN1 OCTET STRING.
>>>> But in a SPKI, the raw ecpointQ is encoded in bit string. The OpenSC
>>>> routines are encoding the DER ASN1 OCTET STRING in the BIT STRING,
>>>> which is the way the RSA modulus and exponent are done, but for
>>>> some historical reasons, the ecpointQ in encoded directly
>>>> in the BIT STRING.
>>>>
>>>> So although your code may work, the SPKI is not correct. And this
>>>> could cause problems id the SPKI was used or provided in some
>>>> other way for some other card.
>>>>
>>>> I believe I tried to address this in previous notes.
>>>>
>>>> Will look closed on Monday.
>>>>
>>>>
>>>>
>>>>
>>>> On 11/23/2013 3:47 AM, Andreas Schwier wrote:
>>>>> Hi Douglas,
>>>>>
>>>>> good news. The user manual is at the CDN [1]. You can use a
>>>>> SmartCard-HSM to get access [2]. However I've attached the current
>>>>> version.
>>>>>
>>>>> Andreas
>>>>>
>>>>> [1] https://devnet.cardcontact.de/projects/smartcard-hsm/documents
>>>>> [2] http://www.cardcontact.de/cdn/activation.html
>>>>>
>>>>>
>>>>> On 11/21/2013 09:24 PM, Douglas E. Engert wrote:
>>>>>> I received the two cards, and USB stick today.
>>>>>> Thanks.
>>>>>>
>>>>>> Is there any documentation?
>>>>>>
>>>>>> I have also started to look at the pull request #197.
>>>>>> It compiles and the PIV card works with ECC but I need to look closer
>>>>>> at how pkcs11-tool and pkcs15-tool handle pub keys. something does not
>>>>>> look right. It may not be in you new code.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 11/15/2013 5:00 AM, Andreas Schwier wrote:
>>>>>>> Hi Douglas,
>>>>>>>
>>>>>>> I've opened a pull request that changes the format in which EC Public
>>>>>>> Keys are stored as direct values in PuKDF. This way domain parameter
>>>>>>> are
>>>>>>> preserved during the encode / decode cycle that happens in
>>>>>>> framework-pkcs15.c/pkcs15_gen_keypair.
>>>>>>>
>>>>>>> The code tries to preserve backwards compatibility with cards that
>>>>>>> already store the EC Public Key in raw format.
>>>>>>>
>>>>>>> @Toni: Please check with myEID card.
>>>>>>>
>>>>>>> Kind regards,
>>>>>>>
>>>>>>> Andreas
>>>>>>>
>>>>>>>
>>>>>>> On 11/14/2013 04:31 PM, Douglas E. Engert wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 11/14/2013 3:38 AM, Andreas Schwier wrote:
>>>>>>>>> Hi Douglas,
>>>>>>>>>
>>>>>>>>> I've done a full regression test and the code still works with the
>>>>>>>>> SmartCard-HSM.
>>>>>>>>>
>>>>>>>>> However the EC_PARAMS are still not available at the PKCS#11
>>>>>>>>> interface
>>>>>>>>> for a newly generated key. I will have a look at that issue.
>>>>>>>>
>>>>>>>> Look at what I had to do in sc_pkcs15_pubkey_from spki to copy the
>>>>>>>> params around. Similar code may be needed somewhere else.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Andreas
>>>>>>>>>
>>>>>>>>> On 11/11/2013 09:31 PM, Douglas E. Engert wrote:
>>>>>>>>>> I have not heard anything from the MyEID developers. The discussion
>>>>>>>>>> of the
>>>>>>>>>> problem started on 11/04/13, last week.
>>>>>>>>>>
>>>>>>>>>> Unless I here anything, I plain on committing #194 tomorrow,
>>>>>>>>>> 11/12/13.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 11/6/2013 5:01 PM, Douglas E. Engert wrote:
>>>>>>>>>>> Please see pull request #194,
>>>>>>>>>>> https://github.com/OpenSC/OpenSC/pull/194
>>>>>>>>>>> This address the ecpointQ issues as outlined below.
>>>>>>>>>>>
>>>>>>>>>>> It partially addresses the issue that EC parameters are stored
>>>>>>>>>>> in two
>>>>>>>>>>> places.
>>>>>>>>>>>
>>>>>>>>>>> It stores the ecpointQ as raw in the pubkey->ec.u.ecpointQ, and
>>>>>>>>>>> stored
>>>>>>>>>>> it in
>>>>>>>>>>> DER in pubkey->data. Note the framework-pkcs15.c will use the
>>>>>>>>>>> pubkey->data
>>>>>>>>>>> for the CKA_EC_POINT attribute.
>>>>>>>>>>>
>>>>>>>>>>> I think it will address Tim's issues with using the pubkey from a
>>>>>>>>>>> certificate
>>>>>>>>>>> with PIV cards, as the problem was related.
>>>>>>>>>>>
>>>>>>>>>>> Comments?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 11/5/2013 8:28 AM, Douglas E. Engert wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 11/5/2013 7:48 AM, Andreas Schwier wrote:
>>>>>>>>>>>>> Hi Douglas,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I fully agree with your position, however I think the current
>>>>>>>>>>>>> encoding
>>>>>>>>>>>>> based on X9.62 chapter A.5.7 should remain rather than changing
>>>>>>>>>>>>> again to
>>>>>>>>>>>>> the ECPoint DER encoding from chapter E.6 of the same standard.
>>>>>>>>>>>>
>>>>>>>>>>>> I believe that is what I said in (2) below:
>>>>>>>>>>>>          "I intend to proposed changes to continue to store the
>>>>>>>>>>>> ecpointQ
>>>>>>>>>>>>           as the *value* of the DER encoding as it is the more
>>>>>>>>>>>> straight
>>>>>>>>>>>> forward way."
>>>>>>>>>>>>
>>>>>>>>>>>> By "continue" I meant to use what is the git master, but change
>>>>>>>>>>>> the
>>>>>>>>>>>> comments
>>>>>>>>>>>> as there is also a problem of semantics, as "octet string" could
>>>>>>>>>>>> refer to a
>>>>>>>>>>>> a ASN1 DER OCTET STRING or to its value, especially as it is
>>>>>>>>>>>> defined as:
>>>>>>>>>>>> sc_pkcs15_der_t        ecpointQ; /* note this is der */
>>>>>>>>>>>> With der being uses twice.
>>>>>>>>>>>>
>>>>>>>>>>>> For an uncompressed ecpointQ  "04||X||Y" with a 256 bit curve
>>>>>>>>>>>> would
>>>>>>>>>>>> have a
>>>>>>>>>>>> length of 1+32+32 = 65 bytes. A 384 bit curve would have length
>>>>>>>>>>>> 1+48+48=97
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> It's much easier to convert from the current octet string
>>>>>>>>>>>>> encoding to
>>>>>>>>>>>>> ECPoint or BITSTRING (SPKI) or Tag 86 (CVCs).
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, I should have done that with the original ECC code.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Andreas
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 11/04/2013 08:54 PM, Douglas E. Engert wrote:
>>>>>>>>>>>>>> During the discussion on pull request #191 "Enhanced ECC
>>>>>>>>>>>>>> handling
>>>>>>>>>>>>>> (#191)"
>>>>>>>>>>>>>> It has become apparent that:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>            Commit 457426543dfa02597895d57013dde94cc9e7d038
>>>>>>>>>>>>>>            Author: sjoblomt <[hidden email]>  2012-11-28
>>>>>>>>>>>>>> 04:52:43
>>>>>>>>>>>>>>            Committer: Viktor Tarasov <[hidden email]>
>>>>>>>>>>>>>> 2012-12-03 07:37:13
>>>>>>>>>>>>>>            "MyEID ECDSA Support"
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> had made a fundamental change in the way the ecpointQ was
>>>>>>>>>>>>>> stored.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The previous code stored the ecpointQ as an ANS1 DER
>>>>>>>>>>>>>> OCTET_STRING,
>>>>>>>>>>>>>> and the decode and encode routines in pkcs15-pubkey.c just
>>>>>>>>>>>>>> copied
>>>>>>>>>>>>>> the DER encoding.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Comments in pkcs15-pubkey.c had:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>           /*
>>>>>>>>>>>>>>            * We are storing the ec_pointQ as a octet string.
>>>>>>>>>>>>>>            * Thus we will just copy the string.
>>>>>>>>>>>>>>            * But to get the field length we decode it.
>>>>>>>>>>>>>>            */
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> pkcs15.h had:
>>>>>>>>>>>>>>           sc_pkcs15_der_t        ecpointQ; /* note this is der */
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The "myEID ECDSA Support" changed the way the ecpointQ was
>>>>>>>>>>>>>> stored
>>>>>>>>>>>>>> from an ASN1 DER OCTET STRING to just storing "an arbitrary
>>>>>>>>>>>>>> string of octets (eight-bit values)" i.e. the value of the
>>>>>>>>>>>>>> ASN1 DER OCTET STRING.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have issues with how the "myEID  ECDSA Support"  was handled:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>           * This change was made at the last minute before the
>>>>>>>>>>>>>> 0.13.0
>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>           * No questions or comments were posted to the
>>>>>>>>>>>>>> mailing list
>>>>>>>>>>>>>>             to ask why the ecpointQ was stored as DER.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>           * No comments where made to the mailing list that this
>>>>>>>>>>>>>>             fundamental change was made.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>           * No changes where made to the comments to indicate
>>>>>>>>>>>>>>             only the value of the ecpointQ was being stored.
>>>>>>>>>>>>>>             The coments still indicate DER.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>           * No attempt was made to change the other two card
>>>>>>>>>>>>>> drivers
>>>>>>>>>>>>>>             that supported EC was made.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>           * This broke the SmartCard-HSM code. CardContact
>>>>>>>>>>>>>> Software &
>>>>>>>>>>>>>> System Consulting
>>>>>>>>>>>>>>             reported: "Yes, I remember I even complained about
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>> last minute change
>>>>>>>>>>>>>>             for the 0.13 release, because it broke our
>>>>>>>>>>>>>> SmartCard-HSM
>>>>>>>>>>>>>> code..."
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The myEID changes did not break the PIV code right away, as the
>>>>>>>>>>>>>> PIV
>>>>>>>>>>>>>> kept
>>>>>>>>>>>>>> storing and using the ecpointQ as a DER OCTET STRING. But newer
>>>>>>>>>>>>>> changes
>>>>>>>>>>>>>> such as Pull request #191 "Enhanced ECC handling" ran into the
>>>>>>>>>>>>>> problems with how the ecpointQ was now being stored.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Because of all of this,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>          (1) I am withdrawing the #191 pull request for now, so
>>>>>>>>>>>>>> it can
>>>>>>>>>>>>>> be rewritten.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>          (2) I intend to proposed changes to continue to store
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> ecpointQ
>>>>>>>>>>>>>>              as the value of the DER encoding as it is the more
>>>>>>>>>>>>>> straight forward way.
>>>>>>>>>>>>>>              I will also fix up the comments to point this out...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>          (3) I intend to submit changes to the PIV card driver
>>>>>>>>>>>>>> and any
>>>>>>>>>>>>>> other code
>>>>>>>>>>>>>>              that depends on how the ecpointQ is stored.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>          (4) Resubmit a modified "Enhanced ECC handling".
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We as a project, when we submit code changes like this, the
>>>>>>>>>>>>>> changes
>>>>>>>>>>>>>> need a
>>>>>>>>>>>>>> good explanation of what code is being changed and what issues
>>>>>>>>>>>>>> might
>>>>>>>>>>>>>> arise from the changes, especially if:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>          * Some code used by everyone is being changed in some
>>>>>>>>>>>>>> fundamental way.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>          * Some code might effect card drivers that the author of
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> change can not test.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Comments?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> November Webinars for C, C++, Fortran Developers
>>>>>>>>>>>>> Accelerate application performance with scalable programming
>>>>>>>>>>>>> models.
>>>>>>>>>>>>> Explore
>>>>>>>>>>>>> techniques for threading, error checking, porting, and tuning.
>>>>>>>>>>>>> Get
>>>>>>>>>>>>> the most
>>>>>>>>>>>>> from the latest Intel processors and coprocessors. See abstracts
>>>>>>>>>>>>> and
>>>>>>>>>>>>> register
>>>>>>>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Opensc-devel mailing list
>>>>>>>>>>>>> [hidden email]
>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> .
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> .
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> .
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Shape the Mobile Experience: Free Subscription
>> Software experts and developers: Be at the forefront of tech innovation.
>> Intel(R) Software Adrenaline delivers strategic insight and game-changing
>> conversations that shape the rapidly evolving mobile landscape. Sign up now.
>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>>
>>
>>
>> _______________________________________________
>> Opensc-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

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

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel