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?
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. 800-73-3 part 2 section 3.3.1 says PUT_DATA completely
replaces the data, but is the card memory wasted or recovered?
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
;;
> 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.
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.
>
> Kind wishes,
> Viktor.
>
> _______________________________________________
> 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
