> I don't know what went wrong here.
>
> Wan-Teh
>
Yeah, me neither. As far as the selection of certs goes in the UI, If I
select a cert that has key usage of 'Digital Signature, Non-Repudiation
(c0)' for signing, it prompts me if I would like to also use it for
encryption. Obviously this cert is not meant for encryption. I am given
the prompt: <ok> <cancel> -- shouldn't it be yes/no? But regardless, I
should never even be offered the choice -- the certificate I selected
does not have key usage of encryption.
Here is another note: If I say yes (even though it makes no sense to be
asked in the first place), then the Key with Digital Signature,
Non-Repudiation (c0) will actually show up as the key for encryption.
This can't be right!
Here is what else we have discovered from testing:
The problem occurs every time there are two different certs. If there is
just 1 for signing, the signing goes through.
If there are two, TB will accept both with the above usability caveats,
but then when you try to send a signed message it fails. We can
reproduce this behavior with file-based certs as well. So this clearly
is not a problem with the card or the PKCS11 implementation.
I guess I will have to submit a bug report but that doesn't help us for now.
As for your question about the 3rd cert, it is a policy decision and not
a technical one to include the 3rd cert. It can do signing and client
authentication. It's meant for getting into doors in a building and
such. I can't explain why they thought you should have 3 certs, but they
did.
Christian
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
