--On Wednesday, December 31, 2008 09:07:52 AM +0200 Alon Bar-Lev <alon.bar...@gmail.com> wrote:
>> Are they actually supposed >> to be private, per PKCS#15? None of the profiles I looked at do this; >> are you updating them all, or just cryptoflex? > > The PKCS#15 implementation already supported private data objects, if you > set --auth-id when you used the --store-data at pkcs15-init. The problem > is that nobody finished the task, and the profile always marked them as > public. The above change fixes PKCS#15 too... So that if you use > pkcs15-init you can store private and public objects. > Andreas changed all the profiles to support the new directory. I checked > it also using asepcos. OK; this now makes perfect sense to me. >> Why the change in fileid? It's not like I have the documentation in >> front of me, but I'm pretty sure that's not one of the special ones. >> In any case, the fileID's you mention are specific to the cryptoflex >> profile. > > Can you please check it out? Yeah, I'm pretty sure that only the PIN and KEY fileid's are magical; the others are just chosen to be conveniently different from anything else in the PKCS#15 DF and so that OR'ing them with a PIN or key ID doesn't result in something that collides with a magical ID (for example, 0000, 0100, or 1000 would be poor choices for prefixes). 4700 should be safe. I have a blank cryptoflex here I can test on; I'll give your changes a try in the next few days, just to give independent confirmation that everything works as expected. -- Jeff _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
