dontspam-tzeruch(_at_)ceddec(_dot_)com wrote:
In any case walking into a meeting at the last minute is rude. Walking in
like you own the place is ruder still. And then trying to overturn an
issue that was discussed and decided much earlier without even reviewing
the minutes is downright barbaric.
I'm sorry for any apparant rudeness of bringing these matters up so late
in the game. I didn't mean to act like I own the place. I tried to
raise these points phrased in a way that would not make anyone feel that
way, and if I failed in that regard, I'm sorry.
If size was a concern, you would have split out a separate parameter
packet since it is likely that all PGP 5.0 1024 bit DSS and DSA keys have
the parameters in common, and then used a parameter ID and just the public
key.
This is a good idea, and I proposed it to our team two years ago, but our
implementation bandwidth was not up to it.
If I got it wrong, I would like to know where so I can fix it. If I
didn't I would like to know that too. Or is PGP now going to play a game
of "guess which competitor has the problem - we know but aren't telling"?
If it is by request of the implementor that would be a different thing,
but you now have called into question every one of your competitors. Is
this how PGP is going to act now? Even if you haven't checked the other
impelmentations, you need to say that too.
No, "PGP" is not playing a game. These were my own remarks, not PGP's.
I didn't know which implementation got it wrong. I knew that we had it
wrong in our experimental code (that's why it was experimental, and
ifdef'ed out), and I knew that Jon had told me that someone else did too,
but I didn't remember who it was. I guess "they" got it wrong because we
got it wrong first, and they used our ifdef'ed code as a base. Maybe
"they" is you. I'm sorry if that sounded insulting in my posting; I
didn't mean it that way, and I didn't know who it was. I typed those
remarks at home in the wee hours of the A.M., without the benefit of
having Jon Callas around to ask him for details.
The original PGP published source contained disabled support for ElGamal
signatures and was broken. This code should have been removed, though I
may have been the only one to enable it.
We should not have let it out. It was experimental. Hal thought that
the #ifdef around it would be enough. It keeps the compiler away from
it, and he thought that was enough to keep people away from it, too.
They will be subjected to Haval, Tiger, DES/SK (when it is available),
Blowfish, Safer/SK-128, MD2, EC (in whatever form), on the same basis as
ElGamal. Why include all these, but not ElGamal?
I don't think we should include these either, but I didn't want to make a
fuss over them, in the interest of making people happy.
This late in the game, I would agree to changing the MAY to a SHOULD NOT
for ElGamal. I would even be willing to disable it by default in my code
in the same way that PGP 5.0 disabled support (after fixing it if mine is
the errant implementation). And I think the other implementors may agree
to do the same thing and do a moratorium on "enabled ElGamal" until the
next spec is released and we can then either delete it or place caveats
or come up with a way of extending DSA.
Maybe that would work, if we can keep ElGamal from entering the PGP PKI.
I would rather extend DSA as soon as we can find a suitable hash. But
let's not hold up the spec to do it. It will take a while to find a good
hash.
Maybe we could use the algorithm byte value that is used for experimental
algorithms. It would be nice to find a way to buy some more time without
holding up the spec, while limiting the uptake of ElGamal signatures.