Hi,
On Monday, 28. May 2012, Martin Paljak wrote:
> I don't really understand how you would use ACL-s with the "gender"
> field, for example.
Let me try to explain what I want to achieve.
card-openpgp.c emulates a filesystem for the DOs on the card.
Now, some of the DOs are
* readable after VERIFY PIN2
some are
* writeable a VERIFY PIN2
some are
* writeable after VERIFY PIN3
...
(and the sets may overlap)
All this information is written in the spec only, and thus is implicit.
(i.e. the DO do not tell about their permissions)
This "implicit only" behaviour does not necessarily extend to the
emulated file system.
(i.e. the emulated files can have emulated ACLs, ... that can be
evaluated by tools)
My goal is to extend openpgp-tool in a way that it does not need
implicit information on the readability/writeablity of the DOs, but
can use standard-compliant data to get the information.
This way the mapping only needs to be done in card-openpgp.c only
instead of distributed over many places.
Let me try to show it graphically
On the Card
DO 0101
permissions (implicit from the spec)
read: always
write: VERIFY PIN2
|
| (this happens in card-openpgp.c)
|
v
Emulated File System
EF 0101
ACL: READ=always, WRITE=VERIFY CHV2
Currently the ACLs are not emulated yet.
But If they are, then standard-compliant applications can determine
what needs to be done in order to be able to e.g. write to an emulated EF.
So, the ACLs shall not in any way try to influnce what happens on the card (I
am very crealy aware that they can't), but tell to the outside world how the
permissions are laid out on an OpenPGP card.
This way not every application needs to know the specs of an OpenPGP
card, but can use the information provided by the emulation.
I hope that makes my goals clearer.
If this is not doable with either security attributes or/and ACLs, because
their intention and potential use cases conflict with that goal, please tell.
Best regards
Peter
--
Peter Marschall
pe...@adpm.de
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
