Discussion about Cancel-Lock support

[Julien ÉLIE]

Hi Russ,

>> The idea behind was to send a hash only for canlock* and verify hashes
>> for both canlock* and extra* but I agree it is a bit complex and
>> confusing.  During key rotation, we can still go on send both hashes,
>> and verify both hashes, then at one time remove the old password.  Looks
>> like simpler indeed, with canlock* lists.
> 
> Oh, I see.  In that case, maybe change extracanlockuser to
> canlockverifyuser?  That makes it clearer the extra user is for
> verification only.

It would then look like:

cancels {
     canlockuser:        [ password ]
     canlockverifyuser:  [ anotherpassword ]
     canlockadmin:       [ adminpassword ]
     canlockverifyadmin: [ anotheradminpassword ]
}

I am unsure it is clear by only looking at the names of the parameters 
that "canlockverifyuser" is for adding another password to verify. 
Looks like naively that the canlockuser password should also be set in 
canlockverifyuser so as to also be verified (and not solely used for the 
initial generation).
People generally do not know how Cancel-Lock works.

Having 4 parameters may appear to be a bad idea (though I initially had 
it in mind).  Your suggestion of only 2 makes it clearer I think. 
During key rotation, both hashes are sent and verified.  Simply.



cancels {
     canlockuser: [ password anotherpassword ]
     canlockadmin: [ adminpassword anotheradminpassword ]
}

seems simpler over all.

-- 
Julien ÉLIE

« Cela n'a rien de remarquable. Il suffit d'appuyer sur la bonne touche
   au bon moment et l'instrument joue tout seul. » (J.-S. Bach)