> On 29. Jun 2022, at 03:54, Jürgen Schönwälder > <[email protected]> wrote: > > On Tue, Jun 28, 2022 at 11:40:55PM +0200, Carsten Bormann wrote: >> On 2022-06-28, at 22:50, Carsten Bormann <[email protected]> wrote: >>> >>> The alternative would be to trigger on the data, so any string that looks >>> like 2022-06-28T20:48:15Z would turn into 1(1656449295). That has some >>> interesting security considerations, though. >> >> Hmm, that is starting to become more attractive to me. >> >> As long as we can make sure that the same string comes back out again, this >> can be safe even if we don’t get the typenames right. >> >> Of course an efficient implementation might still be triggered by typenames, >> but it wouldn’t create a problem if that guesses wrong. >> > > This sounds super scary. So how in CBOR would you make sure that the > timezone suffix Z remains Z and the suffix +00:00 remains +00:00?
Clearly, the idea only makes sense if the packing/unpacking function is a bijection. So 1(1656449295) can only stand for 2022-06-28T20:48:15Z and not, at the same time, for 2022-06-28T20:48:15+00:00. The application can then decide that it really wants to use 2022-06-28T20:48:15Z because that packs better, and not 2022-06-28T20:48:15+00:00. All that works best if we have something like a canonical representation for some application data. (Without that, it becomes less transparent for an application what the cost of a specific data item is going to be.) So far I’m aware of date-time and IP addresses as obvious candidates for this. Anything else that would benefit significantly? Grüße, Carsten _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
