Peter Williams wrote:
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Douglas,
Perhaps could you explain where I may be mis-understanding recent
issues, on the PIV/PKCS#15 topic, on the list? The misunderstanding
comes in respect ot PKCS$15 - which is a cross between a stream, and a
"file _system_" defined over 7816-4 files (and their acls).
PKCS#15 is esseentialy a file system defined over the ISO 7816-4 files -
MF/DF/EFs,m etc. V1.1 is obtained from
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-15/pkcs15v1.doc. The cited URL
links to the document that was - apparently - the progenitor for ISO
7816-15 (drafts). But, what is the relationship formally of
PKCS#15/7816-15 to PIV, and where can that info be seen in USG-issued
_public_ documents?
NIST 80-73 Table 1 and Appendix A lists the objects on the card, and
also lists what they call a "Container ID". These could be looked at as
the EF in the current directory. (They maybe holdovers from some previous
documents.) Also note that the PIV SELECT command is a 7816-4 select DF.
But the PIV application is not required to respond to read/write binary,
or any other select command, only to the GET/PUT DATA commands, that don't
use these Container IDs, but rather use the BER-TLV Tags from Table 6.
What I was saying was that in the OpenSC there is the concept of emulation
of a PKCS#15 file system on cards that are not PKCS#15. This is the
approach I took, so the OpenSC PKCS#11 implementation could be used against
the PIV card. The OpenSC pkcs15-tool and pkcs11-tool and libp11 can then
access the objects on the card. So the usable API is PKCS#11 not PKCS#15.
If we reference muscle, we also know that musclecards come in a variety
of card-types, for a common card-edge: the javacard ("VM"?) form of the
muscle applet that Karsten has recently amended, and the ISO FS form
sold by some vendors (apparently). The muscle download area has C-coded
plugins for the two sets of wire format PDU encoders, bendath a common
musclecard API - for the VM [aka javacard] applet, and the FS card. But
the FS card does not export a PKCS#15 file system - it simply provides
the muscle card-edge!
Is the PIV concept of a FS card type an extension of the muscle FS card
concept? ... in which the card edge can not only be implemented in terms
of classical 7816-4 file access/management instructions (READ/WRTIE
BUFFER etc) but the collection of files MUST also conform to PKCS#15 (or
7816-15) - creating a "PKCS#15 filesystem"?
I don't think it is that formal. The PIV does not support READ/WRITE only
GET/PUT. As I stated above the ContainerID looks a lot like a EF,
but the ContainerID are not used on the card, the BER-TLV Tags for
the objects in Table 6 are used with the Get/PUT DATA.
Now, finally, when discussing OpenSC, and its "PIV driver mode": can I
assume that this host-side driver is willing to emulate the existance of
a PKCS$15 complygin file system on a PIV card - even when the card only
implements a VM type card edge?
Yes, but its a fixed files system with 4 certificates, 4 public keys,
4 private keys, 2 pins, and 6 or 7 objects. (NIST 800-73-1 has only one
fingerprint object now.) The public key objects don't really exist at all
but the public key can by derived from the certificate.
You can not added additional objects of your own.
How far could such an emulation go? for example, if one wanted to clone
a card and thus get the source card to export the entire PKCS#15
ASN.1-defined BER stream, could the SC driver perform that "sttream"
level of emulation, and then the reverse process...write a stream back
to a set of GC instance(s) and their PIV-data containers - on a VM-style
PIV card?
Some of this. But you can't read the private keys from the card.
The PIV is designed to be issued by some agency, using the tools of the
card vendor to initialize the card when all the objects are written to the card.
NIST 800-73 does not standardized the personalization processes. It really
only standardizes the use of the card in the field which is read objects and
certificates and use the private key for crypto operations.
But there is enough code in the OpenSC piv-tool to let you do most of the
administration if you know some specifics about the vendor's card. The
piv-tool can change the pins, generate keypairs, and write certificates and
other objects to the card. I made no attempt to try and format the CCC,
CHUID, Fingerprint buffer or security object buffer. The piv-tool could
write them to a card given a file with the object. The PKCS#11 could read
them if they are on the card.
One of the problems is getting cards from the vendors, as they are still under
development and each has its own set of bugs. The chaining of the GET/PUT DATA
is also new, and some early cards did not handle this well. Since thse are test
card, I have not atempted to finailize the cards in any way.
Just this month, NIST with 800-73-1 removed the restriction on the certificates
being protected by the pin. Some of the cards I have enforce this, others don't.
The test cards with the fewest bugs,enforced the protection, so I need some new
test cards...
During my testing, I have generated keys, used these to generate certificate
requests, which where signed by a Microsoft CA, and the certificate written
to the card. Then using the OpenSC PKCS#11 with Mozilla used the card
with https:, and with the Heimdal Kerberos with PKINIT authenticated
to Windows Active Directory from Linux and Mac OS.
Peter.
_______________________________________________
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle
--
Douglas E. Engert <[EMAIL PROTECTED]>
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