Re: pgp library

[mccoy@io.com (Jim McCoy)]

nobody@jpunix.com (Anonymous) writes:
> Jim McCoy responds:
> >  [...]  I do know of some people who are interested in working on
> >  a PGP compatible library of crypto code, but I am not quite sure
> >  what the status of that project is at this time...
> 
> This is really a shame, because at the current time one of the most
> lacking aspects of most crypto software is the key management
> interface.

A key-management module is planned for this library.  Something that takes
the key management stuff out of the various places in the code it is
scattered and into it's own is one of the goals of the project.

> [...]  But you are doubly screwed because the PGP development
> team has made it clear that the keyring file format will change in
> 3.0.
[...]
> Who wants to spend time writing a key management API (which, I admit,
> is NOT trivial...) which is guaranteed not to work in the next version
> of PGP?

It is not necessarily guaranteed to not work.  We have been in contact with
members of the PGP development team, and may be able to emulate much of
thier API as things develop.  Either way, this is not just a project to
develop an updated PGPTools; we hope to have a general purpose crypto
library including better math routines, generalized key management, support
for multiple public-key and symmetrical ciphers, and hooks for various APIs
at different levels.  

> PGP front-ends aren't the only application type whose progress is
> being slowed by this situation.  IMHO, any app that uses PK-crypto
> should support PGPformat keys, even if it's output isn't designed to
> be fed into PGP.

Either that, or PGP should learn to use a key standard that might not
necessarly be it's own.  Key management issues are one of the primary goals
for Eclipse and hopefully some of the IETF work in this arena in recent
months will help us in determining a direction to work in.  Either way,
while we want to support as much PGP functionality as possible I doubt we
will shackle ourselves with the liabilities of blindly following only the
PGP developers when deciding what to do.

jim