FIDO: allow valid maximum domainId 65535 in extensions

[GN998]

feat: add support for 256-65535 domain index range

[p1gp1g]

For the details:

https://fidoalliance.org/specs/fido-v2.3-rd-20251023/fido-client-to-authenticator-protocol-v2.3-rd-20251023.html#hybrid-websocket-channel

The encoded tunnel service identifier is a uint16. Values zero through 255 are assigned, and values >= 256 are translated into a domain name by hashing. A “cable” label is prepended to hashed domains to allow for use of CNAME records.

The domain name by hashing is implemented, but it doesn't work because of the assertion.

@GN998: If I can give an advise, maybe you can rename the PR to start with FIDO: [...] or fix(fido) so it can easily be sorted 👍

[GN998]

Thanks for the suggestion.
Also, I'd like to share that my initial approach was:
require(domainId in 256..65535)
@p1gp1g

[p1gp1g]

Also, I'd like to share that my initial approach was:
require(domainId in 256..65535)

Indeed, that's what it should be

[peterhel]

Thanks for raising the ceiling here — I confirmed the field really is 16-bit (putShort(domainId.toShort())), so allowing up to 65535 is correct.

One catch though: require(domainId in 256..65535) also raises the floor to 256. Since the if (domainId < 2) above only handles the two fixed hosts, domainIds 2..255 currently go through the hash path — and they'd now throw IllegalArgumentException. That looks like an unintended regression; did you mean require(domainId in 2..65535) (or just require(domainId <= 65535))?

Built it locally on top of current master — compiles fine, just flagging the lower bound. 🙏

[p1gp1g]

2..255 indexes are reserved for potential new static domains: https://fidoalliance.org/specs/fido-v2.3-rd-20251023/fido-client-to-authenticator-protocol-v2.3-rd-20251023.html#hybrid-websocket-channel

[peterhel]

Ah — you're right, thanks for the spec link. I'd assumed 2..255 were valid because the old code hash-derived them, but per the CTAP 2.3 hybrid spec those indices are reserved for future static domains, so rejecting them (rather than hashing) is correct, and the hash path rightly starts at 256. My mistake — the change is good as-is. 🙏