On Tue, 2011-04-26 at 17:21 +0200, Juan Antonio Martinez wrote:
> El mar, 26-04-2011 a las 16:25 +0200, Jean-Michel Pouré - GOOZE
> escribió:
> > Le mardi 26 avril 2011 à 16:38 +0300, Martin Paljak a écrit :
> > > For the sake of purity, I don^t think that --list-public-keys should
> > > display a fake public key object, which does NOT exist on the card in
> > > relevant PKCS#15 structures. but patches for documentation are most
> > > welcome.
> >
> > I understand your point of view.
> >
> > 1) IMHO the public key really exists on card as soon as it derives from
> > the private key. This is the duality of asymmetric key encryption.
>
> I have a similar problem with Spanish DNIe:
>
> As you can see in wiki [1] DNIe pkcs15 stores same DF in EF(PubK) and
> EF(PrivK). So pkcs15-tool --read-public-keys fails with an "access
> denied" when trying to read public keys. The only way to retrieve
> public keys is from certificate files
>
> Looking at pkcs15-tool.c code I can see that certificate files are
> only parsed when no public keys are declared in pkcs15 structure,
> In DNIe, as pubk is declared, this never happens and pkcs15-tool
> returns read failure
> ------------------
> (from pks15-tool.c)
> ........
> r = sc_pkcs15_find_pubkey_by_id(p15card, &id, &obj);
> if (r >= 0) {
> if (verbose)
> printf("Reading public key with ID '%s'\n",
> opt_pubkey);
> r = authenticate(obj);
> if (r >= 0)
> r = sc_pkcs15_read_pubkey(p15card, obj,
> &pubkey);
> } else if (r == SC_ERROR_OBJECT_NOT_FOUND) {
> /* No pubkey - try if there's a certificate */
> r = sc_pkcs15_find_cert_by_id(p15card, &id, &obj);
> ..........
> ( the SC_ERROR_OBJECT_NOT_FOUND is never returned as DNIe says that
> there is a pubk with requested id... but unreadable )
>
> ------------------
> So what's the correct way to work:
> - Take care on pkcs15-tool on read failures, and asume that private
> and public key are stored together, so then go to parse certificates
> - Use the pkcs15 emulation layer to hide pubk data from pkcs15, and
> leave pkcs15-tool untouched
I would prefer the second proposal, because the public keys are
unextractable anyway. Therefore there is no disadvantage in hiding them.
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
