[Opendnssec-develop] How to replicate signer-stuck with SoftHSM

[Rick van Rein (OpenFortress)]

Hello Rickard,

>> 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.
> 
> 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.

I imagine this scenario:
 - Enforcer creates keys in one view, say on HSM #1
 - Enforcer creates signconf
 - Enforcer sends an update for the zone to the Signer
 - Signer looks up keys from another view, possibly on HSM #2
 - This view does not contain the keys yet
     --> we'd have to establish if this is PKCS #11 compliant (making it a Signer bug) or not (making it an HSM bug)

>> 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?
> 
> 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.

OK.  Then I continue to wonder why the Signer does not run on the 1st zone while the Enforcer is generating keys for its 2nd zone.  Especially with 1-5 seconds random delay that I built into C_GenerateKeyPair.

> 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.

Of course.  But it is not quite clear if the 2nd zone being updated gets stuck during the first run (where it finds it has no signconf yet) or on a second run (where it accesses signconf-defined keys that are not present in the HSM view it has).

-Rick