What I call the primary private key is a private key, that matches to the site address.
If the primary private key is leaked or lost, that is an emergency without solution, and the control over the site is lost forever.
For that reason, the primary key should be kept in a way as secure as possible and be used only in absolutely critical situations. In the everyday work, secondary keys should be used, so if they leaked or lost, new secondary keys can be created and signed with the primary key. Unfortunately, the commonly used ways of working with zites now are very careless about the primary key.
Here are some steps we can take for the better security at FZNC sites:
The moderation should be done using the moderators' own keys, not the primary key.
Status: totally possible.
We already do that.
Appointment and removal of moderators (and supermoderators) should not require the primary key.
Status: not implemented, but looks possible.
We need an intermediate
data/content.json, that lies between the root
The engine updates should not require the primary key.
Status: more investigation is required; the implementation may have some difficulties.
All the engine files should be placed in a separate subdirectory, so that a separate
content.json can be used for signing. What can be a trouble is
index.html, since his name and location is fixed on the level of the ZeroNet engine. That file should probably be a simple proxy to the real entry point and have no code that can require update.
Changing internal site settings should not require the primary key.
Status: not yet implemented.
Some engines, including ZeroTalk, make use of the root
content.json to save settings. Those settings should probably be moved to
data/data.json and controlled by the intermediate
Changing the site metadata should not require the primary key.
Status: currently impossible, modification of ZeroNet engine is required.
Metadata, such as the site title and description (and maybe some other in the future) are saved in the root
content.json. We do need the primary key to modify the title, displayed in the "Hello ZeroNet" UI.
In the case of an ideal separation of tasks of the primary and secondary keys, the following situations and their consequences are possible:
|Primary key||Secondary key||Result|
|okay||lost||The secondary key is dropped and a new one is created.|
|okay||leaked||The secondary key is dropped and a new one is created. The site is restored from a backup, if there was some damage.|
|lost||okay||The site keep working.|
|lost||lost||The site keep working, but any management and moderation is not possible.|
|lost||leaked||The site most likely be destroed; exclusive control over the address is lost.|
|leaked||(irrelevant)||The site most likely be destroed; exclusive control over the address is lost.|