In PKCS#15, there is discussion of offcard storage of certs, and the usage
of cert "references". How does this map on PIV? Or, does it?
" 6.5.5 Certificate Directory Files (CDFs)
These elementary files can be regarded as directories of certificates known
to the PKCS #15 application. They are optional, but at least one CDF must be
present on an IC card which contains certificates (or references to
certificates) known to the PKCS #15 application. They contain general
certificate attributes such as labels, identifiers, etc. When a certificate
contains a public key whose private key also resides on the card, the
certificate and the private key must share the same identifier (this is
indicated with a dashed-arrow in Figure 4). Furthermore, certificate
directory files contain pointers to the certificates themselves. There can
be any number of CDFs in a PKCS #15 DF, but it is anticipated that in the
normal case there will only be one or two (one for trusted certificates and
one which the cardholder may update). The certificates themselves may reside
anywhere on the card (or even outside the card, see Section 8). The ASN.1
syntax for the contents of CDFs is described in Section 7.6."
Does PIV enforce the implied "normal" architecture of PKCS#15 - that card
user (i.e. those denoted by the CHUID) cannot update/modify the set of
"_trusted (root)_ certificates"?
In PIV, is there an acl controlling what cert values/refs the CHUID-denoted
person can modify, or is the acl implied by the standard (and subject to
conformance testing, as a critical-class SEF?)
From: "Peter Williams" <[EMAIL PROTECTED]>
Reply-To: MUSCLE <[email protected]>
To: [email protected]
Subject: [Muscle] PKC#$15, GCs, PIV, musclecard architecture of VMs/FS
Date: Fri, 24 Mar 2006 04:29:58 -0800
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?
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"?
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?
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?
Peter.
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
