Extracting librepgp

[ronaldtse]

From @dewyatt :

[we can] split the libs via some callback interface and data marshalling, etc.

We could maybe start with trying to extract librepgp, since it would be nice to have a general PGP parsing library.

This issue is to plan for the extraction of librepgp, also in preparation for Confium.

Ping @ni4

[ni4]

To extract it we should delegate some functionality to the upper logical layer. It could be key request/storage, password requesting (already done via password provider), logical signature validation (i.e. checks whether key is expired, revoked, trusted at all), probably something else.

[dewyatt]

Between this and https://github.com/rnpgp/rnp/issues/308 and TC I'm having trouble figuring out the best way to proceed.

One question I have is: if librekey becomes Confium (perhaps rewritten in Rust), what kind of key format(s) will Confium deal with?

For example: 1) Should it have plugins to deal directly with KBX, G10, OpenPGP packets, etc? 2) Or, should it have a unified key format (like some flexible JSON) which is the only format it deals with and clients are responsible for converting to/from? 3) Some kind of mixture? Like the core only deals with some unified format, but plugins convert to/from.

Based on the answer to that, I then wonder:

1) Do we want librepgp to parse into a unified key format and feed it into Confium? 2) Or, do we want a Confium plugin that leverages librepgp? 3) Something else entirely?

Am I overthinking everything?

[dewyatt]

I think I'm looking too far ahead so I'll try to focus on the minimal task at hand here for now. :)

[ronaldtse]

Sorry I missed replying here! All great points.

Should it have plugins to deal directly with KBX, G10, OpenPGP packets, etc?

Yes. I don't know if this is one plugin or multiple (you tell me! 😉 )

Or, should it have a unified key format (like some flexible JSON) which is the only format it deals with and clients are responsible for converting to/from?

As much as it is possible, a unified / an interoperable key format will be useful.

Some kind of mixture? Like the core only deals with some unified format, but plugins convert to/from.

Probably necessary for extensibility.

Do we want librepgp to parse into a unified key format and feed it into Confium? Or, do we want a Confium plugin that leverages librepgp?

I think the latter, but it does not precluding using a unified key format.

[ni4]

1. Should it have plugins to deal directly with KBX, G10, OpenPGP packets, etc?
2. Or, should it have a unified key format (like some flexible JSON) which is the only format it deals with and clients are responsible for converting to/from?
3. Some kind of mixture? Like the core only deals with some unified format, but plugins convert to/from.

I think it would not be possible to have unified key format - probably only blob storage, because of large number OpenPGP-only specific fields (signatures, signature subpackets, key preferences, whatever else). So these should be handled on library layer, Confium could only provide blob with data (having some metadata around it as well).

[ronaldtse]

because of large number OpenPGP-only specific fields (signatures, signature subpackets, key preferences, whatever else).

But it seems that G10 already separates all of these such that they are separate from the OpenPGP encoding / format?

When we think of a unified key format, we should consider that each cryptographic scheme will use a different schema (i.e. secrets with metadata). For example, we can look at KMIP's key exchange format to see how they organize these fields.

[dewyatt]

because of large number OpenPGP-only specific fields (signatures, signature subpackets, key preferences, whatever else).

But it seems that G10 already separates all of these such that they are separate from the OpenPGP encoding / format?

When we think of a unified key format, we should consider that each cryptographic scheme will use a different schema (i.e. secrets with metadata). For example, we can look at KMIP's key exchange format to see how they organize these fields.

Well G10 kind of relies on OpenPGP packets in the pubring to store extra data. Regardless, I don't see any reason JSON (as an example) couldn't store all of the extra fields required. It wouldn't be unified in the sense that every scheme has the same fields, it would be unified in the sense that there are lots of shared fields (key material, etc) and they all use the same "encoding" (JSON or whatever).

(Also remember GPG 2.3 has some new extended format in the works too, similar to G10 I guess.)

[dewyatt]

(Anyways, I'm focusing on the task at hand for now - getting librepgp split out into an entirely separate lib)

[ni4]

But it seems that G10 already separates all of these such that they are separate from the OpenPGP encoding / format?

G10/KBX stores additional data around the raw OpenPGP packets (like secret key data in special format, signature verification status, calculated trust status, whatever else) for easier later parsing. We can do the same, using the JSON instead of weird binary format.

[ronaldtse]

Agree with using JSON for easier parsing. We will need to encrypt that anyway, perhaps into another JSON...? We don’t need to settle into the “ultimate format”, we can improvise as we go.

[dewyatt]

I've been working on extracting this. I've basically started over a couple of times when I find that doing A, then B, then C means I'll probably want to go back and change A later. I do have a decent plan at this point I believe, and I'm trying to keep the changes minimal and keep librepgp in the source tree for now to make merging easier.