authenticatorConfig minPinLength test has dirty state

[BryanJacobs]

By submitting this issue you are acknowledging that any information regarding this issue will be publicly available.

If you have privacy concerns, please email conformance-tools@fidoalliance.org

FIRST PRE CHECK

• [X] I SOLEMNLY SWEAR THAT I HAVE SEARCHED DOCUMENTATION AND WAS NOT ABLE TO RESOLVE MY ISSUE

What protocol are you implementing?

• [ ] FIDO2 Server
• [ ] CTAP2.0
• [X] CTAP2.1
• [ ] UAF 1.1
• [ ] U2F 1.1
• [ ] U2F 1.2

NOTE: UAF 1.0 certification have been officially sunset. U2F 1.2 only supported version of U2F.

What is your implementation class?

• [X] Security Key / FIDO2 / U2F authenticators
• [ ] Server
• [ ] UAF Client-ASM-Authenticator combo
• [ ] UAF Client
• [ ] UAF ASM-Authenticator

If you are platform authenticator vendor, please email conformance-tools@fidoalliance.org

What is the version of the tool are you using?

1.7.14

What is the OS and the version are you running?

For desktop tools

• [ ] OSX
• [X] Windows
• [ ] Linux

For UAF mobile tools

• [ ] iOS
• [ ] Android

Issue description

Test Authr-AuthenticatorConfig-AuthenticatorConfig P-3 sets minPinLength to a value longer than it previously held.

My authenticator implementation doesn't store pinCodePointLength, so any increase in minPinLength sets forceChangePin to true. This behavior is not disallowed by the specification - I believe an authenticator should not be required to store the PIN or its length to function correctly.

Because P-3 triggered a forceChangePin, the P-4 test before hook fails, as the PIN can't be used.

I think test P-3 should reset the authenticator after executing, to ensure that the next test is able to execute with a clean state instead of a dirty one.

[iirachek]

The specification for CTAP 2.1 states that during new PIN setup, the authenticator has to store the new PIN code length internally, as can be seen in section 6.5.5.5 point 5.11. You will need to update your authenticator implementation to match specification.

The idea behind storing PINCodePointLength is that the user shouldn't be bothered to change their current PIN if it's already sufficiently long to meet the new min PIN length requirements. Forcing PIN change every time, while not explicitly prohibited, is also not explicitly permitted and isn't ideal experience for the user.

The specification outlines in section 6.11.4 point 5 that a forced PIN change is needed only when the new min length is greater than the PINCodePointLength. Since authenticator is required by specification to store PINCodePointLength (section 6.5.5.5 point 5.11), cases for when PIN is set but its length is unknown are not described.

[BryanJacobs]

Very well, I'll store the PIN code length when the setMinPinLength extension is available.