Nguyễn Hồng Quân wrote: > I'm starting from the current codebase, which uses a emulation layer, > so I don't know other choice than continue with this approach.
First create the improved infrastructure in OpenSC that your work needs. > > Maybe it would be better to have a single "sticky pkcs15-ish mapping > > for a fixed profile card" in a single location (like the pkcs15 > > emulation drivers) and allow pkcs15-tool (which does not try to create > > any PKCS#15 structures) to re-generate exposed key slots and replace > > exposed certificate slots. And extend that API as needed. > > I don't really understand this idea. > - Now, to solve the problem of the path I mentioned at the beginning of > this mail thread, I change a bit in gpg_select_file, to automatically > ignore the part of DF PKCS15-AppDF (5015). Does it resemble the idea > "sticky pkcs15-ish mapping for a fixed profile card"? Yes and no. The point is that mapping between card layout and p15 will happen only in a single place. > - What "re-generate exposed key slots and replace exposed certificate > slots" is for? Code working with keys and certificates should never work with p15 operations for modifying structure, but be restricted to the structure exposed by the p15 mapping. Modifying that (virtual) p15 structure would use another API. //Peter _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
