Re: Alternative signature systems


need advises regarding the ed25519 secret/public keys usage in ostree.
Shortly speaking the secret key is 64 bytes (32 for seed + 32 for public) and a public key is the 32B public part of secret key.

From my findings there are 2 more or less widespread subsystems which provide some keys management like keypairs generation and file format to store keys:

- signify used in OpenBSD
It uses own formats ( for public/secret/signature which includes KEY-ID and encrypts the secret part with password.

- openssl allow to generate secret/public keys and partially use them.
Full ed25519 support is under development as far as I understood.
But anyway -- it store the secret and public parts as is without any additional attributes (if compare with signify format). It is simple to extract the secret and public parts externally and use them in ostree.

0. Keys generation
`libostree` should not care about keys generation (even if it is pretty simple), so need to use the public and secret keys in one of already existing format or define our own format to store and use keys and use external method to convert from foreign one.

1. Verification
To verify commit/summary we need to know only public key (32B) which is small enough to be used as reference in configuration file and CLI (instead of KEY-ID used with GPG)

Need to decide where to store ed25519 public keys for ostree (directories, file names, etc.) and the format of public key itself -- i.e. do we need to store any other info than key itself.

For example if we may to use just a list of valid public keys in base64 representation as a simplest solution. Also it is possible to add the public key directly to repo.config for appropriate remote. Or both variants. Public key example in this case: "taB90TjC+08KOlgRRQFepHjCQvJ9SzI/ZM3TpjGdOW4="

Or we may to use something similar to approach used in "signify" utility, i.e. one public key per file, file should have special format and contain not only the public key but some additional info.

2. Sign
As far as I remember we use signing only with couple of builtins like `ostree commit`, `ostree summary` or (new) `ostree sign`. Do not think we need to implement the support of any file format for secret keys -- should be enough to provide secret key via CLI (in base64 representation) and it should be extracted externally.
Applications will be able to provide the key via API if needed.

Out of scope: keys rotation, revocation, life span.

So the main decision for now -- places and format for ed25519 public keys. I think it have sense to start with simple files with the lists of valid keys.

16.05.2019 11:18, Denis Pynkin via ostree-list wrote:
In issue and the
implementation of GPG alternatives is under discussion since 2017.

We plan to add the alternative signature system one more time to avoid
GPLv3 dependencies for libostree.

Just to recap the current status:
- able to build ostree without GPG support with PR #1889
- work on proposed modular (ok, a kind of) signature subsystem is under development (PR #1878)

wbr, Denis

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]