Authenticator data flags reserved bits must be 0 or the figures would ideally be changed
zacknewman opened this issue · comments
According to flags, bits 1 and 5 are "reserved for future use" without any requirement they are 0; however Figure 3 and Figure 6 display those bits as 0. Are implementations expected to simply ignore those bits the way flags says; or are implementations supposed to ensure the bits are 0 as illustrated by the figures? Regardless of the answer, it would be nice if the spec were changed to make the figures and flags documentation align better. Specifically, if the bits must be 0, then flags should state that; otherwise the figures would ideally be updated to not explicitly show 0 (e.g., X or 0|1).
Interesting, so CTAP 2.2 seems to align with the figures and not flags documentation as it says, "let flags be a byte whose zeroth bit (bit 0, UP) is set, and whose sixth bit (bit 6, AT) is set, and all other bits are zero (bit zero is the least significant bit)" (emphasis added). This would suggest that flags should be updated to not only state the bits are "reserved for future use" but that in the meantime they must be 0.
It is defined under "Authenticators perform the following steps to generate an authenticator data structure" that:
However, the RP Operations procedures do not instruct to enforce that the flags be zero. Doing so would make any compliant RP implementations incompatible with future changes that allocate these flags to be used, like we have done in L3 with the BE and BS flags.
I'm confused. If something SHALL/MUST be something, then shouldn't that mean it's enforced independent of the RP Operations? If not, then using RFC 2119 terminology—specifically "MUST", "SHALL", "REQUIRED", "MUST NOT", and "SHALL NOT"—is not only completely pointless but worse confusing/contradictory (how can something be both required and not required?) since it's only the RP Operations that dictate what happens.
It would be nice if the flags documentation were updated to at least link to Authenticators perform the following steps to generate an authenticator data structure; so implementations that actually adhere to the RFC 2119 terms as stated in the Dependencies more easily find this requirement and don't accidentally ignore the bits instead.
It may be worth adding a small It's RECOMMENDED that RP's do not verify the reserved flags as future implementations MAY use them..
@zacknewman Not all requirements can be enforced in-protocol. Authenticators are required to set the RFU bits to zero for now, but RPs should not enforce this behaviour since that would break those RPs if the bits are allocated in the future. Certification programs - such as those run by FIDO for the CTAP2 implementation of the authenticator operations - could enforce that "the RFU bits SHALL be set to zero", but it's a bad idea to embed such enforcement in the protocol as that would undermine the point of the flags being "reserved for future use".