On 4/16/2011 12:18 PM, Viktor TARASOV wrote:
> 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 .
Correct. That is why the piv-tool writes out the pubkey after generating it,
and the pkcs15-piv.c will
read the pubkey from a file if the environment variable:
PIV_9A_KEY, PIV_9C_KEY, PIV_9D_KEY or PIV_9E_KEY is set.
See comments in pkcs15-piv.c around lies 850.
>
> 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 .
NIST left the card enrollment details up to the card vendors, so each can mey
be different.
>
>> 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 .
Yes it "could" be read that way, but was not true for some beta cards I had a
few years ago.
>
>> 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 best I have found was to write a null object. For example is a clear_cert.sh
with $OIT=05, 0A, 0B, or 01 See NIST 800-73-3 part 1 table 2 for the Tags,
or the card-piv.c piv_object piv_objects[].tag_value.
piv-tool -A A:9B:03 -s 00:DB:3F:FF:07:5C:03:5F:C1:$OIT:53:00
An old cert needs to be cleared out before generating a certificate request,
so the pkcs15-piv.c will read the public key from a file, rather then
from the old certificate.
>
>
>> 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.
On its not just writing the keys, you need to authenticate to the
card to write any object. Maybe Oberther also supports this with SM,
but this is not part of the PIV standards.
Have you talked to Oberther at all about what else you could
do with the ID-ONE and can you write PIV objects using SM?
I would suspect you could, as a good card management station
would need that.
>
>
>> 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 .
Since the PIV is not a native PKCS#15 card, I never added any code to try and
create
any object on the card via PKCS#11 or PKCS#15. But it might be possible to have
the
card-piv.c write the pubkey after the key generation to a file, rather then
having the
piv-tool do it. It could look for the PIV_9*_KEY env variables.
But As I said, using scripts that call piv-tool to generate an EC key on the
card,
combined with OpenSSL using opensc-engine and libp11, (both with EC mods) I can
use OpenSSL to sign with ECDSA a request, and can get OpenSSL demo CA to sign
generate a certificate form the request. The piv-tool then loads the certificate
on to the 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 .
Yes the ECDH will require C_DeriveKey, which will require at a minimum some
PKCS#11
secretkey session objects to hold the Derived key, so it can be retrieved by
the application.
My goal in all this was to allow PIV cards issued by others to be used
with common applications: Login, IE, FireFox, Outlook, Thunderbird,
on any platform, Windows Mac, Linux.
>
>
>>> 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
