--On Thursday, January 08, 2009 11:40:54 AM +0100 Andreas Jellinghaus <a...@dungeon.inka.de> wrote:
> 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? It sure would be nice if anyone at all would comment on this. I'm not going to push real hard on this one, though; if you think disabling off-card key generation by default is the better choice, and no one else objects, then let's try it. > 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. This I'm a little more concerned about, because I don't like the idea of firefox or whatever sitting on any token it sees and preventing anything else from using it. I have plenty of uses for smartcards that have nothing to do with my web browser. As I said, I think the long-term answer is to fix opensc so we can handle multiple clients without lock_login. Of course, that will require some developer time, and as you point out, we're a bit short on that right now. In the meantime, as long as I can turn lock_login off, I suppose I can live with the default changing. Again, it'd be nice if there were anyone else commenting on this stuff. > 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). Yup; I figured that out from alon's explanation. Thanks. > 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). I think I was talking about the difference between '-p pkcs15+onepin' and '--no-so-pin'. It's probably not important. > 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. Yeah, this makes sense. When I wrote that, I was confused into thinking you'd changed the behavior for non-private data objects, rather than adding support for private ones. What you did makes sense to me, now that I understand what's going on. > 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. It looks to me like only cryptoflex, cyberflex, and oberthur currently have this behavior. It's not urgent to me, and in fact I prefer being able to wipe a card clean without having to know any of the existing PIN's. I just thought I'd bring up the issue for people to consider, given that the comments in the profile indicate the intent was always to change it eventually. > 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. Hrm. Some would argue that the change for that issue should be in its own release, separate from anything else. In practice, it probably doesn't matter in this case. > 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. It looks like debian-testing has 0.11.4, which is not too bad. I bet they'd pick up a newer release if someone prodded them. -- Jeff _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
