Thanks Carsten. This is very valuable input for the working group before it makes a critical decision.
--Mohit On 7/11/20 4:40 PM, Carsten Bormann wrote: > Hi Mohit, > > >> On 2020-07-11, at 15:27, Mohit Sethi M >> <mohit.m.sethi=40ericsson....@dmarc.ietf.org> wrote: >> >> Hi Michael, >> >> Thanks for the input. This is indeed something we should discuss at the >> upcoming virtual EMU meeting. >> >> Some colleagues (Ingles Sanchez et al.) have also investigated and >> documented the savings that might result from the use of CBOR in EAP-NOOB: >> https://hal.archives-ouvertes.fr/hal-02880326/document > That paper simply translates a JSON-like structure into CBOR, without using > any of the additional benefits of using CBOR (e.g., numeric map labels). > So I would expect the benefits of moving to CBOR to be larger than described > in this paper. > >> EAP-NOOB also relies on the JWK specification for encoding public keys. >> While CBOR equivalent is defined in RFC 8152, it is a rather large document >> that contains all the functionality of JWK, JWS, JWA (as far as I >> understand). Following smaller modular specifications was somehow easier at >> the time. > RFC 8152 does have a section structure, so you don’t need to read all of it > to just get the equivalent of JWK. > >> What is more important is that wpa_supplicant currently has a JSON encoder >> and parser >> (https://protect2.fireeye.com/v1/url?k=be5e912f-e0fe3fe2-be5ed1b4-866132fe445e-d1e084c426bf1ae9&q=1&e=3870678c-1f3b-4f09-8cde-269a88395e80&u=https%3A%2F%2Fw1.fi%2Fcgit%2Fhostap%2Ftree%2Fsrc%2Futils%2Fjson.c). >> I think you would agree that wpa_supplicant is probably the most important >> tool for those using EAP (at least on 802.11). >> >> One could use an external library since there are many CBOR implementations >> available: >> https://protect2.fireeye.com/v1/url?k=e6a1854a-b8012b87-e6a1c5d1-866132fe445e-29d16d211c0fc3e9&q=1&e=3870678c-1f3b-4f09-8cde-269a88395e80&u=https%3A%2F%2Fcbor.io%2Fimpls.html. >> However this has two major downsides: >> >> - Adding an external library dependency implies that the overall system >> becomes more brittle. > To the contrary. An implementation of JSON just for one application is > likely to have received less testing and overall development attention than > an industrial-strength library. If you for some reason don’t agree with > that, you can always create another CBOR implementation in an afternoon :-) > >> - Updating and maintaining two components is definitely harder than one. > Not sure I follow. > >> As said, this is worth discussing at the meeting since it would result in a >> large change to the existing EAP-NOOB implementations. > Certainly! > I just wanted to make sure you don’t make your decision for the wrong reasons. > > Grüße, Carsten > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
