On Mar 5, 2024, at 5:46 AM, Jan-Frederik Rieckers <rieck...@dfn.de> wrote: > Well, the beauty of CBOR is that it is very easily extendable. > I completely agree that, with the limited list of map keys, using CBOR > instead of TLVs seems like shooting cannons at mosquitos, but if in the > future we want to do more with this, we can.
Extensibility also has its downsides. If we're not sure we need the functionality, then *unused* functionality is ripe for exploits or issues. > Resource exhaustion is a problem in CBOR, as it is in any other > serialization/deserialization solution. If we only need 3 pieces of data, none nested, then CBOR has more issues than TLVs, due to it's inherent nesting. i.e. the temptation for implementors is to pass the raw CBOR data to a CBOR library. Which means nested structures, complex maps, etc. And none of that will be used by EAP-FIDO. For now I'd suggest concentrating on getting the crypto right, and the request / response exchange. Data encoding can always be changed before it's widely implemented. > They also limit the length of a CBOR message, with a recommendation that > every authenticator MUST support at least messages of 1024 bytes and that > platforms have to respect the max message length signaled by the > authenticator. So EAP-FIDO would also need to negotiate / signal message length? > We could say something similar about the allowed depth and length of the CBOR > messages sent in EAP-FIDO. Is that fixed, or negotiated? Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
