Dina wrote: > > > Huie-Ying Lee wrote: >> Dina wrote: >>> >>> >>> Valerie Bubb Fenwick wrote: >>>> Hi gang - >>>> >>> ... >>>> I am having issues with testing elfsign's -T option, which come >>>> down to >>>> issues with using pktool to generate a key/certificate pair to test >>>> *with*, >>>> but when I attempt to test it now with a key/cert pair that don't >>>> match >>>> I do get requested for the SCA 6000's PIN (whereas before I simply got >>>> "unable to access token"). I am working with Dina on trying to get >>>> a full test working for that, but all of the kmf_api tests and all >>>> of the "ef" tests (which includes elfsign) pass on a T1000 machine and >>>> an AMD64 machine (with the exception of the tests that failed on >>>> snv_117 >>>> on those same systems). >>>> >>> ... >>>> Valerie >>> >>> On Valerie's problem with generating a key/cert pair using pktool, >>> this should've worked, but it doesn't ... and with a very unhelpful >>> error message: >>> >>> % pktool gencert \ >>> keystore=pkcs11 \ >>> token=bubbstore \ >>> label=dinaElfsignCert \ >>> subject="CN=dinak, OU=hotep, C=US" \ >>> serial=0x100 \ >>> keytype=rsa \ >>> keylen=2048 \ >>> keyusage=critical:digitalSignature \ >>> eku=codeSigning >>> >>> Enter PIN for bubbstore: >>> Error creating certificate and keypair: >>> libkmf error: KMF_ERR_INTERNAL >>> % >>> >>> >>> I've been able to generate a key/cert pair using certutil instead, >>> hooked into the crypto framework so the key/cert pair ends up on >>> the SCA600. And "pktool list keystore=pkcs11 token=bubbstore" >>> can see it after it's been created with certutil (see below key >>> and cert #2), but I'm thinking "pktool gencert ..." might have a bug??? >>> >>> >> What kind of keystore is used in the above example ? If it is mars >> card, then this is a known problem. Mars cards do not support >> CKM_SHA1_RSA_PKCS algorithm. The last step of generating a >> self-signed cert is to sign the certificate with the private key. >> The current KMF/pktool design, the signing process is performed in >> the token level. Therefore, "pktool gencert" will fail if the token >> doesn't support the signing algorithm. A CR was filed with a >> suggested solution in March. For more info, please see CR6814527. >> >> BTW, "pktool gencert" should work fine with the softtoken keystore. >> Huie-Ying >> >> > > The keys/cert were on the SCA6000, so that's the keystore used. > So SCA6000 supports mars card ? > That Paul W is saying "*another* way is to use ikecert", or I'm > saying "*another* way is to use certutil"... hmm... > > Looked at the CR, thank you. The solution depends on the private > key being extractable. I don't know about ikecert, but I know > that certutil will work even if the key is non-extractable: the > operation should be broken down into its component algorithms, > SHA1 over the data off-token and RSA encrypt the result on-token, > which SCA6000 can do the second op. > Right, if the private key can not be extractable, then the operation needs to be broken down.
Not sure about the implementation details of NSS' self-signed cert generation. However, "ikecert" can generate a self-signed cert on mars card and its implementation is to extract the private key from the token and does the signing in the framework level. Huie-Ying > D. > >> _______________________________________________ >> crypto-discuss mailing list >> crypto-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/crypto-discuss
