Le 15/04/2011 20:57, Douglas E. Engert a écrit : > On 4/15/2011 12:33 PM, Viktor TARASOV wrote: >> Hello Douglas. >> >> Afais, the pkcs15 PIV emulator will ignore the certificate container if >> it cannot read and properly parse the its content. >> >> That's why my question. >> Can the certificate container be used for the temporary storage of the >> public key from the newly generated key ? > Do you mean (1) write the pub key to the card, so it could be read in > a separate session?
Yes. Afaiu, for NIST and PIV there is no public key object and there is no card in the 'intermediate' state -- already with a private key but still without a certificate . This card enrollment state is 'legal' for PKCS#11 and PKCS#15. That's where from the temptation to approach PIV card to the PKCS#11/15 . > Or (2) save it in memory as a PKCS15 pubkey object, so it can be used in > the same session to generate a certificate request? > > With (2) yes it could be done, and there are some comments in the code about > doing this. > > With (1) it might be possible, but it might also depend on the card vendor's > implementation of the PIV applet. The NIST 800-73 defines what TLVs should be > in the objects, and as you write them to a card, it is not clear what the > applet will validate. It could be interpreted as -- any middleware should be ready to encounter the unknown data tag or data format and to not fail . > 800-73-3 part 2 section 3.3.1 says PUT_DATA completely replaces the data, but > is the card memory wasted or recovered? I found nothing about object deleting in NIST. The well known card's reference guide talks that after key was deleted its EEPROM is fully released . > The applet should parse at least the length of the object. It could even parse > the "cert" to see if the key matches, but very unlikely. > > In either case, to write using PUT_DATA either a pubkey pretending to be > a certificate or a certificate to the card will require the use of the > "PIV Card Application Administrator" 800-73-3 part 2 Appendix A.1 > That's what the piv-tool -A option is doing. This will require the 9B > 3DES key which should be unique for the card, and know only to the > card administrator. > >> 'Temporary' means between the key generation and certificate import. > So (2) could be done without violating any of the 800-73 specs. > I never went that far basically using 3 scripts. (I can send you the > full set of scripts in a separate e-mail.) > > gen_key.sh: > > piv-tool -A M:9B:03 -G $KEYID:$ALGID -o cards/$1.$KEYID > > gen-req.sh > openssl<< EOT > engine dynamic -vvvv -pre > SO_PATH:$OPENSC_ENGINE/engines/engine_pkcs11.so -pre ID:pkcs11 -pre > NO_VCHECK:1 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:$MODULE > version > req $SSLEAY_CONFIG -engine pkcs11 -keyform engine -sha1 -new -key > slot_1-id_$ID -out cards/$1.myreq.$KEYID.pem -text > EOT > > put-cert.sh: > if [ $ZIP -eq 1 ] ; then > openssl x509 -in cards/$1.cert.$KEYID.pem \ > -outform DER -out cards/$1.cert.$KEYID.der > gzip -c cards/$1.cert.$KEYID.der> cards/$1.cert.$KEYID.gz > piv-tool -A M:9B:03 -Z $KEYID -i cards/$1.cert.$KEYID.gz > else > piv-tool -A M:9B:03 -C $KEYID -i cards/$1.cert.$KEYID.pem > fi > ;; I know everything could be done with the piv specific tools . I would like to use PIV card with the modules which have a standard APIs. >> So that there is no needs for the external public key storage. > Yes (2) could do that, but... > > If you goal in all of this is let some user update the key and cert on > their own card via a browser I would not consider that a good idea. You > would have to give them the 3DES administrator key, which means they > could do whatever they wanted to the card, include update other objects. It could be a badge office where card management application uses the standard (almost standard) modules . The keys could be securely imported/updated on the user's post with the help of secure messaging where the keysets are placed on the distant entity . Oberthur's PIV card supports SM. > Depending on the card vendor it could also mean that they might be able > to read private keys off the card. So if the 3DES administrator key > is stolen, the card should not be trusted. No, here I do not look for the general, long life solution. Especially for the PIV card . My actual goal is a short term one: enroll some card that supports EC with the help of applications that use the standard API . Unfortunately the only card supporting the EC keys that I have is a PIV card . Another goal is to test the support of EC keys in OpenSC . Probably, proposals and thoughts that happens on this road could be useful for the actual support of the PIV card in OpenSC . >> Kind wishes, >> Viktor. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
