On Mon, 18 Jul 2005, Manuel Freire wrote:

> the main one with the OpenPGP functions (encrypt, sign, ...), another
> for key management and the third one for algorithms.

Can you explain just what you mean by "key management"? I don't mind
a certain amount of arm-waving, but "key management" with no further
description seems rather too much to me.

I am all in favour of not going overboard in terms of planning, but I
certainly do not feel comfortable judging what you are doing right now
because I don't understand your plans. I personally think you should
abandon committing of .c files for the moment and sit down and write
up a description of the system in enough detail that someone who is
familiar with PGP, but has not used your previous implementation of it,
can understand what's going on.

In particular, I would like to see:

     1. A summary of the command-line programs, and all or most of the
     functions each one will perform.

     2. A summary of the libraries, and all or most of the functions that
     each one will publically export.

For both of these, for the sake of fast turnaround, I would start
not with the exact command line parameters, options, function names,
argument types, and so on, but just a quick list along the lines of
"encrypt a given file, import a key to the key ring, set a trust level
for the key," kind of thing, and get that committed. That way we can all
start thinking about it while you continue on and refine it.

I'd also like to see:

     3. Use cases for command line and library usage. We already have a
     start on this committed to CVS; expand upon it!

     4. Tests, or outlines of tests, written from these use cases. For
     example, if we have a use case for, "given a public key in OpenSSH
     format, encrypt a file that can be decrypted only by the owner of
     the private key counterpart to the public key." From there, we can
     make a shell script that would actually execute the test and compare
     the actual encrypted output with the expected output. (You'll want
     to make sure you commmit the private key, too, so that we can change
     the test later if necessary.)

Other questions:

     5. How will we be storing the keys? We already have some constraints
     on this; we have to be able to deal with keys stored in formats,
     such as OpenPGP format, that will allow us to exchange them with
     other software, such as key servers and other PGP implementations.
     List these formats, and then figure out what we want to add to this.
     Analyze the security implications of all storage formats. Describe
     how we specify the keys to the various programs.

     4. How will we be storing and calculating trust information? See my
     use cases document for some ideas and concerns about how we analyze
     this.

In the NetBSD developers group we have certain people, such as Steven,
Perry and Thor, among others, who are very, very good at analyzing
security issues. If you want to be able to take advantage of that, you
have to have good descriptions of what your aim is and how you intend to
implement that. You can do that with code, but I can almost guarantee
you that you're end up throwing away a lot of what you've written, so
you may want to do this in a format that's easier to understand as
well as faster to write: fairly precise English descriptions of your
proposals.

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.NetBSD.org
      Make up enjoying your city life...produced by BIC CAMERA