Re: [core] [Anima] date-and-time and "created-on" field in constrained-voucher

[Carsten Bormann <[e-mail]>]

> On 29. Jun 2022, at 03:54, Jürgen Schönwälder <[e-mail]> wrote:
> 
> On Tue, Jun 28, 2022 at 11:40:55PM +0200, Carsten Bormann wrote:
>> On 2022-06-28, at 22:50, Carsten Bormann <[e-mail]> 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