<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Are you using the same key for signing as for encryption with this<br>
setup, or does your S/MIME cert somehow have a separate signing key from<br>
an encryption key?</blockquote><div><br></div><div>With the free Comodo certs you get one key. But sometimes for other setups you have two keys, one for signing and one for encryption.</div><div><br></div><div>I think the idea behind this is that the signing key has no copies and this policy can be enforced by the HSM firmware that generates it. Because, if you lose a signing key, you can just revoke it and generate a new one. The encryption key is generated in a different way that would allow for backups and copies to be made. Thus signing with the encryption key gives you lower assurance, because someone might have stolen it from a backup. But with the signing/"non repudiation" key, there are no backups anywhere and thus it's safer.</div><div><br></div><div>This can be enforced with key usage flags in the certificate.</div><div><br></div><div>My gut feeling is that this complexity causes more problems than it solves. Before the dreaded OS X Yosemite upgrade, my signing stick worked for encryption just fine. Post Yosemite now the OS seems to think it's only usable for signing. I suspect the key usage restrictions are somehow involved.</div></div></div></div>