Hi Andreas, Viktor TARASOV wrote: > Andreas Jellinghaus wrote: > >> Am Freitag 15 Januar 2010 14:48:30 schrieb Viktor TARASOV: >> >> >>> Any objections? >>> >>> >> looks good. >> >> >> >>> for a new pkcs15 object of a given type >>> the file index is chosen as a first value in the range from 'file-id' to >>> 'max-id', >>> excluding the values that are already assigned to the file indexes of >>> the existing >>> pkcs15 objects of the same type. >>> >>> >> hmm. I wonder about two things: >> a) why check "of the same type" only? sure, normally you wouldn't find >> a conflict, but if it is easy to check if there is anything with the >> filename you want to create, it would be best to take the next one. >> >> > > Ok. >
In fact, checking file-ids of the all objects may results in the unnecessary transactions with card. I've been wrong. When selecting file-id for a new object of a given type, the pkcs15 content can be not yet completely parsed. Complete parsing will cause these additional transactions. Instead, I propose to do sanity check of the key-domain template of the card profiles. It has to ensure that inside one template the base file-ids are sufficiently different. Minimal difference '32' will conform the most 'narrow' case -- gpk profile, where there are base file-ids 3200 and 3220 in the same template. (For this profile not more then 32 of DATA objects.) > Normally, there will be no conflicts, because the high byte of the file > index, > defined in card profile (key-domain template, ...), > have different values for the objects of the different types. > Select ID procedure concerns only the low byte of file index. > > With the actual 'select ID' mechanism, also, it's an error to have in > the card profile > the same high byte of file-id for the two different object types. > Sorry, it's not true. High byte can be the same, but inside template the base file-ids has to be 'sufficiently' different. >> b) for the first of each kind it is best to look at the profile. >> but what about the second of some kind? wouldn't it be better to mimic >> the obejct already installed? for example copy the filename (but increase >> by one) and copy the ACL settings? >> >> > > The file-id of the first object will be not in the heap of the possible > values > for the second one. > (And in fact, the second file-id will be an increased value of the first > one.) > > When this procedure is used, the card pkcs15 contents is already parsed and > available for analysis (for ex. to get know the file-id of existing > objects). > Once more, it's not completely true. Necessarily parsed only xDF that is related to a new object. > The ACLs for any new object file are always (afaik) taken from the profile. > > >> this could help with cards not initialized with opensc - if they put e.g. >> a certificate in some subdirectory, then opensc would follow that logic. >> >> but maybe this would be too complex, hard to implement or could cause more >> problems if people try to mix opensc with other software, than it is worth. >> >> > > This procedure is used in the pkcs15init part, so (for a while), > it concerns only the cards formatted with OpenSC. > > Anyway, there will be (if no objections) the possibility to implement > card specific 'select file-id' procedure. > And so, at the card level more complex scenarios could be implemented. > > >> >> >>> Later, I would like to add the possibility for the cards specific >>> pkcs15init to implement its own procedure (something like existing >>> 'select_key_reference' for the keys). >>> >>> >> seems to be a good idea. at least moving the current implementation >> to be the new default and going through the framework for this stuff >> would be nice, so we have the system and framework set up for 0.12, >> even if no card uses it with the first release. >> >> Regards, Andreas >> >> > > -- Viktor Tarasov <viktor.tara...@opentrust.com> _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
