On 8.10.2014 18:25, Francis Dupont via RT wrote:
> On Wed Oct 08 16:06:09 2014, pspacek@redhat.com wrote:
>> It seems that all versions of BIND with native PKCS#11 support are
>> limited to
>> 32 bytes of PIN length and didn't actually check the PIN length which
>> can later cause login failures.
>
> => yes, the PIN length should be limited to something
> reasonable and 32 octets seemed the right value.
> In fact the PIN maximum length is a property of the HSM
> so I'll dig in the new PKCS#11 v2.40 specs I copied from OASIS
> some hours ago to see if there is useful about it in them...
>
>> First patch adds check for PIN length to prevent too long PINs from
>> causing login failures later.
>
> => IMHO it is a good idea.
>
>> Second patch extends maximal PIN length to 1023 bytes so it should be
>> enough for everyone including me :-)
>
> => 1023 octets are a very large value for a PIN. BTW
> with an enforced low limit of retries a short (4 digits) value
> is common, i.e.:
>   - a PIN is not a password

I'm not opposing to that however I do not see a reason to artificially limit 
PIN length on *client* side. HSM will deal with it if the PIN value is too 
long for that particular implementation of PKCS#11.

IMHO maximum PIN length advertised by HSM for purposes of PIN initialization 
to let user know what PIN he can enter for that particular HSM.

>   - no limit at all on retries is a *bad* idea
>    (explain this to Apple with its cloud :-).

In this particular case I'm using SoftHSM so there is no secure way how to 
enforce limit on retries. That is the reason why I wanted to use very long PIN.

I hope it explains my motivation.

(And yes, I know that SoftHSM is really cheap HSM :-))

Have a nice day!

-- 
Petr Spacek  @  Red Hat