search

OneKey-Network / addressability-framework

Apache License 2.0
4 stars 2 forks source link

Key management for contracting parties #4

Open broggeri opened 2 years ago

broggeri commented 2 years ago

  1. How would you rule the management of the expiration dates ? I am adding something like that for now: "All signatures shared across the network must be verifiable. Therefore, each signature must have an associable key in the Identity Endpoint".

  2. Do we provide recommendations regarding the delay of the key rotation?

  3. Can we agree on a general Date format across the proposals ? The SWAN Demo uses a timestamp since 2020 if I remember well. I would go for an ISO-8601 format (e.g "2021-12-08T09:48:43.511Z") for readability purposes. However, for storing concerns, it can be preferable to use a timestamp since 1970 (which is also pretty common). Ping @OlivierChirouze,

_Originally posted by @RomainLofaso in https://github.com/criteo/addressable-network-proposals/pull/2#discussion_r764660282_

jwrosewell commented 2 years ago

SWAN demo did not include a concrete implementation of rotating. We considered that each party is responsible for rotating their secrets / keys and the solution should allow for multiple keys to be used at any one time. We did not set a limit on the number of concurrent keys. We probably treat this as a recommendation with a maximum limit that is quite flexible.

Re: OWID time format.

The time format in SWAN OWID was designed to keep the number of bytes to a minimum. These values will be transmitted and stored hundreds of trillions of times and places during a day. Saving bytes saves trees.

Therefore we have to the minute resolution and an epoch of 2020.

OlivierChirouze commented 2 years ago

  1. and 2. Yes, I think the requirements are relatively simple:

    • a node exposes a list of public keys with a start and end date
    • because of synchronisation issues (or just because things are not instantaneous), there must be some reasonable overlap between the "old" and the "new" key. We have discussed this topic with @RomainLofaso and we believe the best way to handle it is to have the end date of the "new" key be explicitly after the start date of the "new" key. In other words, the overlap is explicit and not based on some heuristic. Intuitively, I would say we also need to define the "current" key (the one to use by default) to be the key where start date <= now <= end date AND (if there are more than one) that has the maximum end date. WDYT?

  2. I believe timestamps are better than "date strings" because they are:

    • smaller
    • "safer" (date strings always lead to issues some time or another) (this goes beyond key management, BTW)

Now, using 1970 or 2020 is an interesting debate but exclusively about optimizing the size of data and messages. I suggest to create a dedicate issue for this discussion.