Re: Making gpgme dependency optional

[Jussi Laako <jussi laako linux intel com>]

On 01.06.2017 17:13, Colin Walters wrote:
> Introducing ed25519 signatures has the advantage of
> simplicity - and I love the small key sizes that one gets with ECC.  ed25519
> is already used by Alpine and OpenBSD at least.

Yes, ed25519 is already used in many places like OpenBSD's signify, but 
it alone doesn't address the key management things so it is kind of 
partial solution needing a bit more implementation for the surrounding 
infra.

> Hm, well I'd been thinking of using ed25519; see:
> https://github.com/ostreedev/ostree/commit/df5cbc9be9bb25c6eaeff12db9727d1ba28118a1

I am trying to avoid OpenSSL in combination with (L)GPL projects due to 
license incompatibility. It requires additional clause on (L)GPL 
software side allow combining the two. For example ecryptfs-utils has 
such clause. Sometimes it may be hard to add such clause, sometimes not...

> I am personally not as familiar with using X.509 outside of a TLS context
> and what that would involve.

Key management in all contexts similar/same. For example Microsoft 
Authenticode code signing uses X.509 certificates. For simpler case one 
can use for example self-signed certificates. Only major difference to 
OpenPGP key signing is use of separate CA keys for key signing. Just 
more authoritarian structure.

PKCS#7 and related S/MIME use these certificates too. X.509 is pretty 
generic for any public key crypto with a model for key trust and management.

> Definitely - but let's have some design discussions here first.  Is your
> primary goal dropping the GPLv3 dependency, or is it using X.509 because
> your organization has tooling/keys in that form instead of GPG?

We have just two concerns. Primary concern is GPLv3 dependency and 
secondary concern is performance slow down caused by gpgme.

In itself we don't have any explicit need for X.509 or PKCS#7, I just 
picked existing standards already supported by multiple crypto library 
implementations. So that the abstraction level is equivalent to that of 
gpgme.

But overall, I think we would be happy with ed25519 too. If it means 
more crypto specific code inside ostree it would just need more security 
review on our side though. Not necessarily any problem.


        - Jussi