<div dir="ltr"><br><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">
A variation might be that PKCS #11 describes certain liberties that are revealed with a different key-creating and key-using command; I seem to recall, but haven't found back yet, that one process does not always get to see updates in another; and if the signer reads the entire zone list, including not-seen-before zones and only then reopens the HSM slot, things could go awry.<br>
</blockquote><div><br></div><div style>It could be the case the the signer finds the zone in the zone list, but it will newer find the signconf unless the keys are generated.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

In general however, the fault pattern seems to be caused by reading the zone list when an unknown zone is updated by the Enforcer.  The new zone list includes ones that have no keys assigned yet, which could lead to exceptional behaviour.  The SoftHSM avoids this behaviour, probably due to a global lock that holds its access to the Enforcer until it is entirely done?  Could you confirm that the SoftHSM lock is global?<br>
</blockquote><div><br></div><div style>The calling application won't get an object handle unless the key has been generated. So there is no need for a lock like that.</div><div style><br></div><div style>The Signer Engine cannot pick a key at random, it needs to know exactly which key to use. This is what the Enforcer tells the Signer Engine via the signconf.</div>
<div style><br></div><div style>// Rickard</div></div><br></div></div>