Happy new year everyone! I was offline for a week or so, and due to a mail problem all my email was lost. So what is our current status?
Did anyone have time to test the opensc pre-release, does it work for you? Any new changes added since then or stuff we need to add? Late reply to jeffreys mails (I read them in our web archive): 1.) yes, we reduce usability with these changes. 2.) I think those are better defaults, you think otherwise. what does everyone else think about these changes? my take is "doesn't work - ah, the card can't generate an rsa key, so I need to turn on this option" won't happen very often, because nearly every card can do that. even if so, the user might understand this quite well. on the other hand "you did what? generate the key on the pc?" is much harder to explain - the usability might have worked for the user, but explaining the security tradeoff and why it was necessary later is a pain. 3.) similiar to lock_login. also (not 100% sure here), I think some apps behave differently (e.g. you get strange warnings etc) if lock_login is off. I'd be happy to hand over opensc and friends to someone who wants to continue to improve them. but as it stands there is not a single core developer left working on opensc, I don't have any clue on the core myself, could only with lots of debugging figure out how to fix the private data object stuff, and in general don't work on opensc at all - only apply some patches from time to time and create some releases, and would be happy to hand over even that to someone else. I'm not using opensc in my daily life either. private data objects are used for storing secrets, e.g. the aes key you use for decrypting your hard disk. data objects are blobs to the card, it can't do anything other than store them, and allow to read them. private means you should be only allowed to read or write to them after your pin was verified. I did change all profile files to add the new priv-data class. but I could only test cryptoflex myself. (note: I didn't edit the oberthur profile, I have too little clue about it, but I hope it was correct in the beginning, since IIRC the code was initially written for this card). your commend on "no so pin" is strange - "pkcs15+onepin" option is exactly the way opensc initializes a card to have a single pin (i.e. no sopin). the change in file id's: it seems that every type of object had a special file id as starting number, so I hope this works. 4600 is some opensc specific default I think, couldn't find anything on it in the spec. but again, I only searched in the spec, I'm no expert on it, and not even sure if I ever read it completely. about the ACL for PIN objects: currently you need only the transport key to delete a card. I find this nice for testing and learning. but it is not the most secure setting, I agree. maybe we could use an option mechanism for such a change? also if cryptoflex has it this way, most other cards will be the same I think. I wouldn't change anything, as I don't know the opensc core well, nor the relevant standards, nor do I have enought time for working on opensc. also I'm not sure how many card driver authors are still active and could test and verify any change. so right now I'm happy at least we could find and fix a security issue, and my plan is only to get some feedback whether that change works, write a security advisory, and publish a new release. also it would be good to push the new release to debian and friends, as they didn't update opensc for quite some time - I guess because the build process was changed and some changes introduced problems, but those have been fixed in the meantime, as far as I know. Regards, Andreas _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
