> ----Mensaje original---- > De: mar...@martinpaljak.net > Fecha: 27/04/2011 7:21 > Para: "Juan Antonio Martinez"<jons...@terra.es> > CC: <opensc-devel@lists.opensc-project.org> > Asunto: Re: [opensc-devel] pkcs15-tool --read-public-keys [....] > > Ok, I finally did it. pkcs15-tool -D no longer shows "public keys" > > on my DNIe card > > > > pkcs15-tool trace says that no public key found, so looks for > > keys in cert, find it, tries to read certificate... > > ... And dies with "security status not satisfied": > > > > Remember that DNIe requires pin to read certificates, > > but sc_pkcs15_read_certificate() seems that does not take > > care on it and dies on -1211 error... > pkcs15-tool recently got --verify-pin option to verify a PIN before anything > else. That might work for pkcs15-tool, if documented. Yeap!. you're right: with "--verify-pin" now works fine. Attached comes a patch for pkcs15-tool.xml documentation :-) > You could re-use PIN cache inside sc_pkcs15_read_certificate, much like > everything else in libopensc/pkcs15-sec.c does as well > (the actual usefulness of it might be questionable for *certificates* though, > they are usually read only once) > I'm not sure if there is a silver bullet solution, eventually calling > application must consider the requirement > a PIN code before being able to read certificates. And ideally provide a > tunable for this (like what NSS does > but applications don't support very well) > But as I understand, *listing* certificates (not reading them, but becoming > aware of their existence) works without PIN codes? Yes, sure. Any pkcs15 structure parsing does not require pin; just read_binary() on certificares (and of course any sec operation) BTW: collateral effect is that pin_cmd starts secure message channel. Once SM is established every apdu must be securized > This should probably help a little (compared to a situation where even > becoming aware of the existence of certificates requires a PIN code) [...] > When binding to the card, looping all certificates and creating public key > objects, then filtering for duplicates in the pubkey > file and having fake pubkey objects after binding to the card already (so > that other pieces like pkcs15-tool or PKCS#11 > module would not have to do that separately) Glubs, I could try, but seems too heavy for me :-) > But yes, that would probably not solve the PIN issue. Sure not... but with your suggestions and my last patches for me is enought :-) BTW: I'm not sure of OpenSSH pkcs11 way to retrieve keys: afaik extract it from certificates, but not sure if also handles keys found in pukdf ¿anyone knows? Thanks for the support. Cheers Juan Antonio
Index: doc/tools/pkcs15-tool.xml =================================================================== --- doc/tools/pkcs15-tool.xml (revisión: 5399) +++ doc/tools/pkcs15-tool.xml (copia de trabajo) @@ -99,6 +99,11 @@ </varlistentry> <varlistentry> + <term><option>--verify-pin</option></term> + <listitem><para>Verify PIN after card binding and before issuing any command (without 'auth-id' the first non-SO, non-Unblock PIN will be verified)</para></listitem> + </varlistentry> + + <varlistentry> <term><option>--list-keys, -k</option></term> <listitem><para>Lists all private keys stored on the token. General information about each private key is listed (eg. key name, id and
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
