Avoid establishing a shared secret for CTAP 2.0 authenticators when hmac-secret is not requested

[jschanck]

In Bug 1936283 we have an example of an authenticator that returns a COSEKey with the wrong algorithm field in its GetKeyAgreement response. The authenticator has a built-in fingerprint reader, and does not support the getPinUvAuthTokenUsingUvWithPermissions function, so we should not need to establish a shared secret, however we establish one opportunistically in case we need to use the hmac-secret extension:

authenticator-rs/src/ctap2/mod.rs

Lines 293 to 295 in 1959330

	if info.supports_hmac_secret() {
	let _shared_secret = dev.establish_shared_secret(alive)?;
	}

We should avoid establishing a shared secret for CTAP 2.0 authenticators when hmac-secret is not explicitly requested.

[Grief]

@jschanck how complex is the fix? I thought it would be as simple as removing three lines of code, wouldn't it?

[jschanck]

This was fixed by #342. The change hasn't been uplifted to Firefox yet, if that's why you're asking about it. I can take it as an action item to cut a new release.

[Grief]

@jschanck is it known which release will include the fix? I still have the issue on v137.0b10