OpenPGP certificate/key management thoughts about function re-organization and cleanup
n.mavrogiannopoulos at gmail.com
Mon Jun 16 15:53:59 CEST 2008
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:
>> 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
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
More information about the Gnutls-devel