Fixing the secret keys, and a small apology

[Jon Callas <[e-mail]>]

I screwed up the footers on the last draft, saying 2000 where it should
have said 2001 or 2002. Sorry.

Now then, one of the remaining things really on our agenda is to discuss
fixing the secret key format.

There are a few options for a solution we've discussed:

* Change the secret key version number and add in a check. The plus here is
that it causes the fewest visible changes. The downside is that it causes
skew between the public and private versions, and is going to create
problems and confusion down the road. Enough people expressed disgust at
this that I don't think it needs to be discussed further.

* Change the entire public key version number to 5, and add in a check.
This is the "right" way to the above. From a standards point of view, this
is the most correct way to solve it. However, the downside is that it will
force a lot of client software to have to be revised (nigh unto all of it).
Secret key packets typically do not wander further from the disk than main
memory, and it would be a pity to force everyone to upgrade software
everywhere for this. Lots of people just won't. (See my previous note ECC.)
I'm probably one of them, too. I am reminded of the aphorism that in
theory, theory is the same as practice, but in practice, this turns out not
to be the case. While this may be the best solution from a standards point
of view, it is arguably the worst one from a practical point of view.

* Change the String-to-Key specifier. The solution here is adding in the
tag 254 to 3.7.2.1 and have 254 denote an improved S2K. The benefit here is
that it causes the least change to user software, and is as secure as
anything else. The downside is that if someone uses a cipher algorithm
there, then they can't use algorithm 254. However, not only is using a
cipher algorithm deprecated, but our present max cipher number is 10. I
can't get too upset about this, myself, and it appears this is the best
solution.

Comments?

	Jon