On Mar 16, 2010, at 10:18 , Andreas Jellinghaus wrote: > Am Montag 15 März 2010 22:08:28 schrieb Douglas E. Engert: >> Andreas Jellinghaus wrote: >>> Hi everyone, >>> >>> here is a bug report with a patch for pkcs11-tool. >>> >>> I'm no expert on this subject, so feedback is very welcome. >>> it looks good in general, except maybe more return codes/ >>> error checking etc., and a different code path if >>> pkcs11-tool is compiled without openssl. >>> >>> the author asks about two attributes where he isn't >>> sure what to do best. I don't know either, so if anyone >>> can take care of the bug&patch, that would be great. >> >> Just looking at the code with no way to test it, do you want >> the pubkey private? > > no, I guess that doesn't make sence. > >> CKA_WRAP, CKA_VERIFY, CKA_VERIFY_RECOVER, CKA_WRAP are token specific, >> and/or maybe should match any attributes of a certificate that may contain >> the same public key? Should these be options, as well as CKA_PRIVATE? Configurable CKA_PRIVATE makes sense.
> a public key is not meant to be used. with a software token, maybe it is. > but with opensc I guess we don't implement public key operations at all. > so if those set the useage of the key, we should default to none of > that - software can download the public key, and do whatever they want > themself in software. Having support of CKA_WRAP is admirable but right now the whole wrap/unwrap for *hardware* operations (what should be the task of OpenSC) is broken. So the usage could be reviewed but AFAIK currently no card driver implements the wrapping that would be expected when using a hardware token. -- Martin Paljak http://martin.paljak.pri.ee +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
