Re: OpenPGP certificate/key management thoughts about function re-organization and cleanup

On Mon, Jun 16, 2008 at 12:07 PM, Simon Josefsson <simon <at> josefsson.org> wrote:

>> Primary Keys vs. Subkeys
>> ------------------------
>>
>> There are currently a lot of duplicated functions which deal with the
>> subkey and primary keys differently.  For example:
>>
>>  gnutls_openpgp_crt_get_pk_algorithm()
>>  gnutls_openpgp_crt_get_subkey_pk_algorithm()
>>
>> These behave exactly the same way, but the primary key is sort of
>> special-cased out.
>>
>> When writing key management code, one often abstracts away the
>> differences between primary keys and subkeys, and needs to just walk
>> through each key separately.  Having to call different functions for
>> the subkey than for the primary key is awkward and makes for a lot of
>> code duplication, which is room for error.
>>
>> We could significantly reduce the number of functions exposed by
>> GnuTLS if we were to collapse these pairs of functions into a single
>> function which takes a key index.  Key index 0 would be the primary
>> key, key index 1 would be the first subkey, etc.  This would allow
>> much simpler looping constructs over a keyset, and would make the
>> documentation easier to scan and understand.
>
> I think this suggestion makes sense, although I'm not an OpenPGP expert.
> I have also found the number of APIs related to keys+subkeys rather
> overwhelming.

Actually the idea was to replace them completely. But since we wanted
backwards compatibility, this is the reason of the
non subkey functions still existing. A change would still be possible
by deprecating the non subkey functions and adding functionality to
the subkey ones so they handle primary keys as well. However this is a
big change for last minute change. (although I like this change).

If this is to occur I'd suggest to delay the release for another 1-2
months and merge with the other development branch. Otherwise with
these changes merging would be impossible.

>> Certificates vs. Private Keys
>> -----------------------------
>>
>> Furthermore, there are many functions that have basically identical
>> functionality duplicated across the crt and the privkey.  I'm aware
>> that these functions may be created as duplicates of the functions in
>> the x509 space, but if the crt and the privkey shared a common base
>> struct, or were otherwise considered interchangable at some level, you
>> could reduce the function space still further.

This is quite unavoidable. I wanted to have a consistent API for X.509
and Openpgp keys. If this changes consistency is pretty much gone!

> I think the size of the installed base for the OpenPGP stuff is rather
> limited, so I'm quite open to improving the API in this area.  We should
> make an effort to maintain ABI compatibility though.

Well I think currently this is a dilema. It is not easy to have both
non duplicated functions a backwards compatibility. The previous
interface was quite limited.

> Hm.  Maybe we can add a libgnutls-openpgp which contains a simplified
> OpenPGP related API?  Eventually, the old OpenPGP API in libgnutls could
> be deprecated.

I don't think it is a good idea to offer alternative APIs. I'm in
favor for either a fix in the library, or a delay until the next ABI
break.

regards,
Nikos