On 11/13/2012 12:26 PM, Viktor Tarasov wrote: > Hello Andreas, > > On Tue, Nov 13, 2012 at 10:26 AM, Andreas Schwier > <andreas.schw...@cardcontact.de <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 <publicKeyCoefficients> 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 > <mailto: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 <tel:%2B49%20571%2056149> > --------- http://www.cardcontact.de > http://www.tscons.de > http://www.openscdp.org > > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > <mailto: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 <deeng...@anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
