FIDO's Passkey Export Standard: A Necessary Step with Flaws
The FIDO Alliance has published its Credential Exchange Format (CXF), a significant move to standardize the transfer of credentials like passkeys, passwords, and TOTP secrets between credential managers. Until now, exporting sensitive data often meant relying on plaintext CSV files, a less secure and less standardized method. The introduction of CXF promises a more robust and secure way to manage digital identities across platforms and applications. Apple has already integrated support for CXF into iOS 17, and third-party password managers like Bitwarden have begun adopting it, marking CXF as crucial infrastructure for the future of credential management.
However, the journey from a proposed standard to a production-ready implementation often reveals unforeseen challenges. As Youssef Mohammed, a developer and security enthusiast, discovered, diving deep into the implementation of a specification line by line is the most effective way to expose its intricacies and potential shortcomings. Driven by the lack of a readily available TypeScript implementation, Mohammed built cxf-kit, a comprehensive toolkit including data models, a parser, a serializer, and a conformance validator. This project was developed against the Proposed Standard of August 14, 2025, using the spec's CDDL grammar as the definitive source of truth. Crucially, it was interop-tested against Bitwarden's existing Rust implementation to ensure compatibility.
Critical Bugs Discovered in CXF Specification
Mohammed's deep dive into the CXF specification, facilitated by building his cxf-kit, unearthed five distinct bugs within the standard itself. These are not minor oversights but fundamental contradictions and omissions that could impact the security and usability of passkey management systems relying on CXF.
Bug 1: Contradictory Example and Grammar for `hmacSecret`
One of the most immediate issues found was a direct contradiction between the specification's grammar and its own example. Appendix A of the CXF specification includes a passkey example that carries the fido2Extensions.hmacSecret field with an algorithm specified as "HS256". However, the specification's formal grammar, defined in CDDL (Concise Data Definition Language), does not permit the hmacSecret field to be present when the algorithm is anything other than "HmacSHA256". This discrepancy creates ambiguity: should implementations follow the example, or the strict grammar? This could lead to interoperability issues where one manager exports data that another cannot correctly parse or validate.
Bug 2: Missing `algorithm` Field in `fido2Extensions`
Further examination revealed that the fido2Extensions structure in the specification is missing a crucial top-level algorithm field. While algorithms are specified within individual extension types (like hmacSecret), there is no overarching field to declare the primary algorithm used for the FIDO2 credential itself. This makes it difficult to determine the intended cryptographic operation without inspecting nested fields, potentially leading to misinterpretations and security vulnerabilities if the wrong algorithm is assumed.
Bug 3: Inconsistent `salt` Type for `hmacSecret`
The specification also exhibits inconsistency regarding the data type for the salt field within the hmacSecret extension. The CDDL grammar defines salt as a bytes type, which is appropriate for binary data. However, the normative text within the specification sometimes refers to it as a string. This ambiguity between the formal grammar and descriptive text can cause confusion during implementation and lead to parsing errors if implementations adhere to the textual description rather than the strict, machine-readable CDDL definition.
Bug 4: Ambiguity in `fido_u2f` Extension for `key_handle`
When dealing with older FIDO U2F credentials, the specification presents ambiguity around the key_handle field within the fido_u2f extension. The CDDL grammar defines key_handle as bytes, which is correct for raw key handles. However, the specification's text suggests it could also be a string. This dual interpretation could lead to implementations incorrectly encoding or decoding key handles, potentially rendering them unusable or, in a worst-case scenario, creating opportunities for injection attacks if not handled with extreme care.
Bug 5: Undefined `origin` Field for `webauthn` Extension
Finally, the webauthn extension within CXF has an undefined origin field. While the specification implies its presence and purpose (likely related to the relying party's origin), it fails to provide a clear definition or data type for this field in the CDDL grammar. This omission leaves implementers to guess the intended format and usage of the origin field, which is critical for WebAuthn security, potentially leading to non-compliant or insecure implementations.
The Path Forward for Secure Credential Exchange
Mohammed's work on cxf-kit not only provides a much-needed TypeScript implementation for developers but also serves as a critical validation of the FIDO CXF standard. The discovery of these five bugs highlights the inherent challenges in standardizing complex security protocols. While the FIDO Alliance aims for robust security, the devil is often in the details, and detailed implementation is key to uncovering these details.
The existence of these bugs does not invalidate the importance of CXF. Instead, it underscores the need for rigorous review and collaborative refinement of the specification. Developers building tools and integrations with CXF should proceed with caution, aware of these potential pitfalls. They should prioritize using implementations that rigorously validate against the CDDL grammar and ideally have undergone cross-implementation testing, much like Mohammed's interop tests with Bitwarden. The development of cxf-kit is a testament to the open-source community's ability to identify and help correct flaws in critical infrastructure, ensuring that the future of secure credential management is built on a solid, well-defined foundation.