Le 04/01/2012 16:38, Hunter William a écrit : > 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 do not insist on the double key usage, and will re-test your original patch. > 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. Ok, thanks. Probably it will not be our usage case, but it's nice to get know why it fails. > Cheers, > Will Kind regards, Viktor. _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
