Hi Viktor, Thanks for your response.
> > The first issue is that as per the IAS/ECC specifications, my key > > is enabled for KeyDecipher or Unwrap usage, and not Decrypt. However, > > it should still be made available as an AT_KEYEXCHANGE key, so that > > the unwrap is possible. > > Sorry, it's my omission. 'ANY_DECIPHER' should be used. Ok, I now see the USAGE_ANY_DECIPHER and USAGE_ANY_SIGN #defines - I agree that using these would work well. > > Secondly, I can't see the purpose of allowing one key to be available > > both as an AT_SIGNATURE and as an AT_KEYEXCHANGE key. In fact, in my > > testing, if this is done, only signatures work, decryption fails. I > > think this is because the keys have the same GUID's (they are the same > > key) and the Microsoft key storage provider cannot handle this - > > understandably! My understanding is that if a key can be used for both > > signature and decryption then it is made available as a AT_KEYEXCHANGE > > key. If it can only do signatures, then it is made available as an > > AT_SIGNATURE key. This mode of operation works well in the tests I > > have done, both for signing and decrypting. > > As you see from the comments I have some doubts about this commit. > Probably something was rotten in my tests when I was testing your > original patch. I'll re-test it. > > From the other side, as far as I understand specification, the key > container IS allowed to have both 'signature' and 'keyexchange' keys. > And further, there is no formal interdiction to have the same > underlying key for the both . > That's why, it would be nice to see the logs from the "only signatures > work, decryption fails" event. Looking at the specs again, I think you are correct, and the GUID seems to identify the key container which may then contain both a signing and an encryption key. However, I still can't see why you would do this if the keys are the same? Does it provide any advantages over just having one AT_KEYEXCHANGE key? I will try to get some logs for you. For the email decryption in Outlook, it seemed to be a key not found error. Certutil produced similar errors, when it tried to access the keys from the Key container. The initial AT_SIGNATURE/AT_KEYEXCHANGE tests worked fine in Certutil, but the second test where it used the key container failed. Cheers, Will _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
