On Wed, Jul 21, 2010 at 13:44, Martin Paljak <mar...@paljak.pri.ee> wrote:
> Reading the code it all feels hairy, the patchwork that sets the flags in > pkcs15.c and the try-and-fail approach in card-cardos.c > Stricter mapping of actual card and its capabilities to something like card > flags and proper failing with a debug message would be much better. Currently > it seems to me that mysterious failures can happen. Agreed. I hope the somebody else can chime in on this; I'm under the impression that CardOS has too many versions and installable packages to determine this with some degree of certainty. (Unfortunately the same applies, to a smaller extent, to the CNS card… 12 mask manufacturers, an ever-varying number of authorized issuers, and I'm still trying to hunt down who is responsible for what.) > Exact knowledge of what is supported as input (hash, raw data, padded data > etc), what gets fed to the card and what is expected as the return should be > very explicit. As should be the hacks that are supported. > I don't have any cardos cards to try it out. If I understand correctly, the problem with those cards (and possibly not only those) is twofold. I'll write my findings here so that I can stand corrected, and that the resulting discussion can be later googled: 1. a single private key will not support both signing and encryption: if a key is supposed to do both, then the software is supposed to perform a signature by calling the encryption command. This is already implemented at the PKCS #15 emu layer (I've noticed pkcs15-cardos.c:522 and following for initialization, and pkcs15-sec.c:194 and following for usage); 2. with CardOS, the padding to be used for signature is determined at BSO creation time. So, beside trial-and-error, the solution (IMHO) would be having an upper layer set it explicitly. My interpretation is that the code in pkcs15-sec.c already does this based on the "flags" argument of sc_pkcs15_compute_signature(), so there should be no need for the trial-and-error logic in card-cardos.c, but… perhaps I'm missing something here? [Give random] > No real preference, I think a comment about ETSI origin in both the header > file as well as source file would do just fine. Will do so. > I attached a modified patch to the original ticket (#177). Comments: > > * No dead code (#if 0 and #if 1) in the patch > * The card should be read-only (correct?) and pkcs15-emulated, so it does not > support key generation -> no flags should be set about it. In fact, I'm not > sure SC_ALGORITHM_ONBOARD_KEY_GEN is useful at all. It should be checked if a > pkcs15init driver exists that does currently not support key generation. We could support it, in principle, but probably nobody would ever use it (unless a certified issuer decides to adopt OpenSC). > * Same applies to SC_ALGORITHM_NEED_USAGE. Are you sure about it? I think I am; if I'm not mistaken, without that flag, the code at pkcs15-sec.c:197 and following will try to invoke PSO_CDS on keys that require DECipher. > * I don't understand "itacns_ops = *(sc_get_incrypto34_driver()->ops);" when > initializing the card driver, why so? Why not use the ISO function > overloading as other drivers do? At some point I wanted to use those functions by default, because they happened to be correct for the CNS card, but you're right – it's much cleaner if I invoke them directly, or copy them into the itacns driver. > * MAX_LE and ITACNS_MAX_PAYLOAD, would it make sense to resort on one single > value that gets fed to card max_recv_size? Yes. I copied that from the incrypto34 driver, where apparently it isn't even used any more. So I'll get rid of one or both of them. I'll work on this stuff and remove any remaining dead code, then resubmit. Thanks! -- Emanuele _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
