Initial Cryptographic Support to have (some parts of) models en/de/crypted

[vorburger]

It could be fun to make it add initial basic crypto support to this project.

The way I imagine it working is that you would "tag" (with Proto extensions, perhaps?) some parts of models marked secret. It would be nice to keep this nicely "modular" and avoid having to "bake this into the core" of Enola.

The secret parts of any model would then be encrypted on the client (CLI, for now, Web, later) and stored "encrypted at rest" on the server (e.g. in the File System Repository), and could later be decrypted again on the client.

There are a bunch of pre-requisites for this, at least including:

• enola put is missing, and it seems less fun without that
• enola --server is missing, as the "flip side" of the (existing) enola server [This was done in feat (cli): Introduce --server (still un-tested & un-documented) #300 and fix (cli): Download Descriptor Protos from Server (and --server etc. docz) #312.]
• Authentication for the remoting might have to come before encryption?

[vorburger]

No, the basics of this should of course work completely without any client/server; just locally.

At its core, this is just an URI scheme, with a ResourceProvider?

Like the (TBD) data: one.

crypt:{PUBKEY}/{SECRET}, using some agreed upon encoding.

Are there existing standards for this?

• Ask at G.
• https://w3c-ccg.github.io/
• https://w3c-ccg.github.io/multibase/

Decrypt is via a key in TPM; may shell out to exec age.

Model https://enola.dev/secret is:

• datatype https://enola.dev/PubKey & PrivateKey are multibase String encoded https://enola.dev/secret/PublicKey and PrivateKey Things
• class https://enola.dev/secret/PublicKey/{ALGO}/{DATA} and PrivateKey are Things with IRI of said datatypes with properties such as Algorithm and binary data
• datatype Secret
• datatype SecretText extends Secret!

CLI is via (TBD) Enola Actions, on Things; e.g. generate key, list keys, encrypt URL, decrypt secret.

Password 🔑 Manager is then trivial and an obvious 1st application: just e.g. a class Website Thing, with a password property.

The #607 format should directly support this.

models/people/ can then contain e.g. phone numbers... 🔒

[vorburger]

Actually, decrypt: scheme specific part start should somehow include if what follows is an encrypted secret itself, or a delegated URL where to fetch one from.. e.g. decrypt:http://server/secret.pgp.

The "decrypted Form" of such secrets should use secret-token: (bearer) scheme, as per RFC 8959.