Re: [opensc-devel] PublicKey ASN1 decoding

2012-11-13 Thread Douglas E. Engert 


On 11/13/2012 12:26 PM, Viktor Tarasov wrote:
> Hello Andreas,
>
> On Tue, Nov 13, 2012 at 10:26 AM, Andreas Schwier 
> mailto:andreas.schw...@cardcontact.de>> 
> wrote:
>
> What I've still on my list is to fix the EC Public Key encoding. The
> current encoding (basically just the EC point) does not allow to carry
> domain parameter, so I would like to change that to the
> SubjectPublicKeyInfo Format.
>
>
> Douglas was implementing support of EC curves. (Somewhere there are still few 
> TODOs of him.)

I know. I Have my hands full with Shibboleth at the the present time.
And yes using the SPKI would be a good idea for EC.

>
> For me there are no objections to change the format.
>
> If 'raw' choice has been encoded as object's value for EC key,
> also has to be encoded the 'keyInfo' parameter to point to the appropriate 
> tokenInfo's algorithmInfo.
> This algorithmInfo should contain the domain parameter as 
> 'algorithmInfo.parameters'.
>
> It seems that SPKI (instead of 'raw') choice is easier to use -- no need to 
> encode 'keyInfo'.
>
> What I'm not sure about is whether the encoding format for other key 
> types (RSA,DSA,GOST etc) should change to
> SPKI as well.
>
>
> GOST are also elliptic curves, and can have different algorithm.parameters.
> For GOST the SPKI format should be more practical as well.
>
> The RSA and DSA have no algorithm parameters and so, for them there is no 
> difference.
>
>
> Do you have an overview which cards store the public key encoded with
> sc_pkcs15_encode_pubkey ?
>
> sc_pkcs15_encode_pubkey() is used by general pkcs15init part, to encode 
> 'direct' value for PukDF.
> Currently it used by the cards that have 'native' public key (stored in SDOs).
> (If all these cards implement the card specific 'read-public-key' handler -- 
> there is no need to add 'direct' value fo PukDF.)
>
>
>
> Andreas
>
>
> Kind regards,
> Viktor.
>
>
> Am 13.11.2012 10:10, schrieb Viktor Tarasov:
>  > Hello,
>  >
>  > it seems that the reason of recent segmentation faults related to the
>  > uninitialized public key components (t451, t455) is here:
>  > 
> https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-pubkey.c#L373
>  >
>  >/* this  should be required, not optional.
>  > But it is missing in some siemens cards and thus causes warnings */
>  >/* so we silence these warnings by making it optional - the card
>  > works ok without. :/ */
>  >
>  > 'Optional' means that if the encoding of the public key do not conform
>  > PKCS#1 (as expected by OpenSC)
>  > the ASN1 decoding procedure silently returns the publicKey data with
>  > uninitialized components.
>  >
>  > The checking of input parameters in OpenSC is not always 
> present/perfect
>  > and this provokes segmentation fault in the modules that use the
>  > 'read-public-key' procedure (tools, pkcs#11).
>  >
>  > As for me, the common library part has to be free of the card specific
>  > issues -- all card specific issues has to be implemented in card 
> drivers.
>  > For that reason, recently was introduced new card operation
>  > 'read-public-key'.
>  > For a while this handler is designed to read out the 'native' public
>  > key (stored in SDOs),
>  > but it can be extended to allow the read out of the non-PKCS#1 content
>  > of the public key EFs .
>  >
>  > If no objections, I will turn off 'optional' flag for the
>  > 'publicKeyCoefficients' and will extend the argument list of
>  > 'read-public-key' handler.
>  > Then 'someone' who interested in support of the proprietary formats in
>  > OpenSC will implement the corresponding parsing procedure in card 
> driver.
>  >
>  > Kind regards,
>  > Viktor.
>  >
>  >
>  >
>  > ___
>  > opensc-devel mailing list
>  > opensc-devel@lists.opensc-project.org 
> 
>  > http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
>
> --
>
>  -CardContact Software & System Consulting
> |.##> <##.|   Andreas Schwier
> |#   #|   Schülerweg 38
> |#   #|   32429 Minden, Germany
> |'##> <##'|   Phone +49 571 56149 
>  - http://www.cardcontact.de
> http://www.tscons.de
> http://www.openscdp.org
>
> ___
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org 
> 
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
>
>
>
> ___
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>

-- 

  Douglas E. Engert  
  Argonne National Laboratory
  9700 Sou

Re: [opensc-devel] PublicKey ASN1 decoding

2012-11-13 Thread Viktor Tarasov 
Hello Andreas,

On Tue, Nov 13, 2012 at 10:26 AM, Andreas Schwier <
andreas.schw...@cardcontact.de> wrote:

> What I've still on my list is to fix the EC Public Key encoding. The
> current encoding (basically just the EC point) does not allow to carry
> domain parameter, so I would like to change that to the
> SubjectPublicKeyInfo Format.


Douglas was implementing support of EC curves. (Somewhere there are still
few TODOs of him.)

For me there are no objections to change the format.

If 'raw' choice has been encoded as object's value for EC key,
also has to be encoded the 'keyInfo' parameter to point to the
appropriate tokenInfo's algorithmInfo.
This algorithmInfo should contain the domain parameter as
'algorithmInfo.parameters'.

It seems that SPKI (instead of 'raw') choice is easier to use -- no need to
encode 'keyInfo'.



> What I'm not sure about is whether the encoding format for other key types
> (RSA,DSA,GOST etc) should change to
> SPKI as well.
>

GOST are also elliptic curves, and can have different algorithm.parameters.
For GOST the SPKI format should be more practical as well.

The RSA and DSA have no algorithm parameters and so, for them there is no
difference.


Do you have an overview which cards store the public key encoded with
> sc_pkcs15_encode_pubkey ?
>

sc_pkcs15_encode_pubkey() is used by general pkcs15init part, to encode
'direct' value for PukDF.
Currently it used by the cards that have 'native' public key (stored in
SDOs).
(If all these cards implement the card specific 'read-public-key' handler
-- there is no need to add 'direct' value fo PukDF.)



> Andreas
>

Kind regards,
Viktor.


>
> Am 13.11.2012 10:10, schrieb Viktor Tarasov:
> > Hello,
> >
> > it seems that the reason of recent segmentation faults related to the
> > uninitialized public key components (t451, t455) is here:
> >
> https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-pubkey.c#L373
> >
> >/* this  should be required, not optional.
> > But it is missing in some siemens cards and thus causes warnings */
> >/* so we silence these warnings by making it optional - the card
> > works ok without. :/ */
> >
> > 'Optional' means that if the encoding of the public key do not conform
> > PKCS#1 (as expected by OpenSC)
> > the ASN1 decoding procedure silently returns the publicKey data with
> > uninitialized components.
> >
> > The checking of input parameters in OpenSC is not always present/perfect
> > and this provokes segmentation fault in the modules that use the
> > 'read-public-key' procedure (tools, pkcs#11).
> >
> > As for me, the common library part has to be free of the card specific
> > issues -- all card specific issues has to be implemented in card drivers.
> > For that reason, recently was introduced new card operation
> > 'read-public-key'.
> > For a while this handler is designed to read out the 'native' public
> > key (stored in SDOs),
> > but it can be extended to allow the read out of the non-PKCS#1 content
> > of the public key EFs .
> >
> > If no objections, I will turn off 'optional' flag for the
> > 'publicKeyCoefficients' and will extend the argument list of
> > 'read-public-key' handler.
> > Then 'someone' who interested in support of the proprietary formats in
> > OpenSC will implement the corresponding parsing procedure in card driver.
> >
> > Kind regards,
> > Viktor.
> >
> >
> >
> > ___
> > opensc-devel mailing list
> > opensc-devel@lists.opensc-project.org
> > http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
>
> --
>
> -CardContact Software & System Consulting
>|.##> <##.|   Andreas Schwier
>|#   #|   Schülerweg 38
>|#   #|   32429 Minden, Germany
>|'##> <##'|   Phone +49 571 56149
> -http://www.cardcontact.de
>  http://www.tscons.de
>  http://www.openscdp.org
>
> ___
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] PublicKey ASN1 decoding

2012-11-13 Thread Andreas Schwier 
Dear Viktor,

that's fine with me.

What I've still on my list is to fix the EC Public Key encoding. The
current encoding (basically just the EC point) does not allow to carry
domain parameter, so I would like to change that to the
SubjectPublicKeyInfo Format. What I'm not sure about is whether the
encoding format for other key types (RSA,DSA,GOST etc) should change to
SPKI as well.

Do you have an overview which cards store the public key encoded with
sc_pkcs15_encode_pubkey ?

Andreas

Am 13.11.2012 10:10, schrieb Viktor Tarasov:
> Hello,
>
> it seems that the reason of recent segmentation faults related to the
> uninitialized public key components (t451, t455) is here:
> https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-pubkey.c#L373
>
>/* this  should be required, not optional.
> But it is missing in some siemens cards and thus causes warnings */
>/* so we silence these warnings by making it optional - the card
> works ok without. :/ */
>
> 'Optional' means that if the encoding of the public key do not conform
> PKCS#1 (as expected by OpenSC)
> the ASN1 decoding procedure silently returns the publicKey data with
> uninitialized components.
>
> The checking of input parameters in OpenSC is not always present/perfect 
> and this provokes segmentation fault in the modules that use the
> 'read-public-key' procedure (tools, pkcs#11).
>
> As for me, the common library part has to be free of the card specific
> issues -- all card specific issues has to be implemented in card drivers.
> For that reason, recently was introduced new card operation
> 'read-public-key'. 
> For a while this handler is designed to read out the 'native' public
> key (stored in SDOs),
> but it can be extended to allow the read out of the non-PKCS#1 content
> of the public key EFs .
>
> If no objections, I will turn off 'optional' flag for the
> 'publicKeyCoefficients' and will extend the argument list of
> 'read-public-key' handler.
> Then 'someone' who interested in support of the proprietary formats in
> OpenSC will implement the corresponding parsing procedure in card driver.
>
> Kind regards,
> Viktor.
>
>
>
> ___
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel


-- 

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

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] PublicKey ASN1 decoding

2012-11-13 Thread Viktor Tarasov 
Hello,

it seems that the reason of recent segmentation faults related to the
uninitialized public key components (t451, t455) is here:
https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-pubkey.c#L373

   /* this  should be required, not optional. But it
is missing in some siemens cards and thus causes warnings */
   /* so we silence these warnings by making it optional - the card works
ok without. :/ */

'Optional' means that if the encoding of the public key do not conform
PKCS#1 (as expected by OpenSC)
the ASN1 decoding procedure silently returns the publicKey data with
uninitialized components.

The checking of input parameters in OpenSC is not always present/perfect
and this provokes segmentation fault in the modules that use the
'read-public-key' procedure (tools, pkcs#11).

As for me, the common library part has to be free of the card specific
issues -- all card specific issues has to be implemented in card drivers.
For that reason, recently was introduced new card operation
'read-public-key'.
For a while this handler is designed to read out the 'native' public key
(stored in SDOs),
but it can be extended to allow the read out of the non-PKCS#1 content of
the public key EFs .

If no objections, I will turn off 'optional' flag for the
'publicKeyCoefficients' and will extend the argument list of
'read-public-key' handler.
Then 'someone' who interested in support of the proprietary formats in
OpenSC will implement the corresponding parsing procedure in card driver.

Kind regards,
Viktor.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel