[Ejbca-develop] Why does "ejbca.sh cryptotoken setpin" require the old PIN in this use case?

[Jaime H. E. <hab...@gm...>]

Let's say I have a PKCS #11 crypto token deactivated and having
auto-activation disabled. Now, if I want to activate the crypto token and
turn on auto-activation using the local CLI I need to use the following
command:

$ ejbca.sh cryptotoken setpin --token ManagementCA --oldpin
partitionpassword --newpin partitionpassword

Where --oldpin is a mandatory parameter, but... why?, given that the new
PIN should suffice to activate the partition and enable auto-activation.

Furthermore, I can see the following code being executed for the previous
operation (where currentAuthenticationCode corresponds to --oldpin).

// If we don't have an auto-activation pin to compare the supplied PIN to,
we need to verify the supplied
// PIN can be used in a de-activation/activation cycle.
final boolean wasInactive = !isCryptoTokenStatusActive(authenticationToken,
cryptoTokenId);
cryptoToken.deactivate();
cryptoToken.activate(*currentAuthenticationCode*);
if (wasInactive) {
  // Note that there is a small glitch here where the token was active, but
we have no other options to verify the pin
  cryptoToken.deactivate();
}

But I can't figure it out the reason to exercise this
de-activation/activation cycle in the current scenario. Why would you want
to test the previous or current PIN when you are about to set a new one?.

Can you please provide some explanation on the reason to require --oldpin
and what the previous code is doing?

Note: Previous commands and code snippets apply to EJBCA CE 6.5.0.4.

-- 
Jaime Hablutzel -  RPC 994690880