Re: Alternative signature systems

[Denis Pynkin <denis pynkin collabora com>]

Hi,

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
https://www.openbsd.org/papers/bsdcan-signify.html
It uses own formats 
(https://github.com/aperezdc/signify/blob/master/signify.c#L54) 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 https://github.com/ostreedev/ostree/issues/1233 and
> https://mail.gnome.org/archives/ostree-list/2017-June/msg00002.html 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