Private classes and members

[daniele-athome]

I noticed that many classes and members are not available for use, including for example:

• PGPSignatureSubpacket members
• PGPUser certifications
• Many others...

Specifically I need to check some low level stuff in my keys.
I don't understand if I'm doing something wrong, but I can't access many classes unless I recompile your library to expose .h files (move them from the private section to the public section).

If I'm correct, why hide so many things? Why not expose everything, your API is so useful and nice.

Thanks and sorry for bothering you with such nuances.

[krzyzanowskim]

ObjectivePGP provides higher level API. The private API you mention is not intended to be used directly - it's too easy to misuse. If you're missing some functionality, it should be build on top of that.

[daniele-athome]

Thanks for your answer. I'm sure it's low-level stuff, but the problem is that at the actual state, the public API is equivalent to a prehistoric version of gpg.
I'll detail my requirements.

1. Key generator: add a subkey for authentication only, which must be RSA while the other ones for convenience purposes (i.e. short keys) can be ECDSA or any other kind of EC - actually, it would be great to have the ability to add any number of subkeys
2. Access to the RSA key data (modulus and exponent)
3. Be able to extract a subkey suitable for a specific given purpose (auth, encrypt, sign)
4. Change key passphrase

Point 4 should already be covered (isn't it?), I'm not totally sure though. Points 1 through 3 can be achieved by exposing some private stuff.

While I can agree that point 2 is very low-level (I'm afraid I need that too though), points 1 and 3 are operations available with the current GPG/gpgme library.

[krzyzanowskim]

I disagree with "prehistoric version" part. First of all, it's OpenPGP as standarized, second of, GPG has extensions that are not necessary yet standarized.

That said.

1. PGPKeyGenerator is not the most configurable. There are few options. If needed, other options can be added to the generator (either by me, or from PR). As of today, it serves the most popular use that is a key with a sign and encrypt subkeys.

2. Why do you need that?

3. Why do you need to access it directly? I guess it's a part of another flow, something more general.

4. There is no key edits now, it's something that would be very useful.

[daniele-athome]

I disagree with "prehistoric version" part. First of all, it's OpenPGP as standarized, second of, GPG has extensions that are not necessary yet standarized.

I'm sorry I didn't mean it in a offending way. I was just comparing your public API with gpgme. But of course there are also extensions as you say.

1. PGPKeyGenerator is not the most configurable. There are few options. If needed, other options can be added to the generator (either by me, or from PR). As of today, it serves the most popular use that is a key with a sign and encrypt subkeys.

IMHO PGPKeyGenerator should include something to let the user decide about subkeys. I'll see what I can do in terms of a PR - no promises though.

2. Why do you need that?

I need to use the raw private key data to convert the authentication private key to an OpenSSL private key (for use in a X.509 certificate).

3. Why do you need to access it directly? I guess it's a part of another flow, something more general.

The above private key extraction should happen on-the-fly, therefore, when loading the PGP keyring from storage, I need to extract the subkey with the authentication flag set.

4. There is no key edits now, it's something that would be very useful.

Indeed :-)

[krzyzanowskim]

@daniele-athome did you start any work on this?

[daniele-athome]

Hey, sorry for the late reply. We started to test something out with @acappelli, but I stopped following it directly a few days later. And I believe he actually got busy elsewhere. Sorry...