Re: Question and note

[Uri Blumenthal <uri@xxxxxxxxxxxxxx>]

dontspam-tzeruch@xxxxxxxxxx says:
> Well we have common IDs, but no specs for what a lot of the IDs point to.
> No Detail.  So there are lots of different and non interoperable ways
> of implementing what already is there.  And that is my point.

Hmm... Why didn't you say so. With this point I can't argue.

> Except lots of these already exist in this state in the existing spec.So
> the current spec is stupid?  It isn't *reserving* numbers for algorithms,
> it is *defining* them.  And without specifying all the details.

Without answering the question, I'd say that a list of discrepancies
would make fixing those less-than-perfect specs easier.  I certainly
wouldn't like just throwing the "unclean" pieces out. Making them
"clean" would be the best.

> You want to add incomplete definitions of new algorithms to the
> existing incomplete definitions and submit the spec in this incomplete
> state?

Hmm... A good question (at last :-).

Had I any time before September (I'm working on two publications and
am behind the schedule as is)  I'd have said "Yes and I'll make 'em
complete." As it goes, I won't be able to invest any efforts worth 
mentioning until September. By then it probably will be solved
one way or another...

> The spec ..............does say (5.7):
>    The body of this packet consists of:
>      - Encrypted data, the output of the selected symmetric-key cipher
>        operating in PGP's variant of Cipher Feedback (CFB) mode.
> and so on, implying that ALL algorithms must use the CFB mode.

So what do we do with stream ciphers? Leave them alone until the
next version? [I could live with that decision.]

> ...PGP-CFB and advertised the fact and no one said anything about me getting
> it wrong, so I assume I got it right - and I asked about DES/SK at that
> time. ID 6 means DES/SK in PGP-CFB mode.  That is what the spec says. 

Damn. I dislike this PGP-CFB mode, but I can live with it.

> If you want it in "raw" CFB it would need another ID.  

Nein. I don't want it in "raw" CFB bad enough to justify a whole
new ID. My sanity check won't permit it. (:-)

> The spec should say a lot of things.  I can only go by what it actually
> does say.  And it says I "MAY" implement this algorithm - DES/SK-PGP/CFB.
> And I plan to if it remains in the spec as soon as I obtain source for the
> algorithm. This detail has been around for months.Did anyone else notice it?  
> How would anyone else have implemented DES/SK - raw, raw-cfb, or PGP-CFB?

So let's make the spec to state explicitly:
	UNless Otherwise Specified, all the block ciphers are to be
	implemented in PGP-CFB-<Blocksize> mode.

> .............You can blame the people who came up
> with the broken standard, but I don't see anyone who has stopped using the
> broken implementations, and worse, new implementations must copy the bad
> features.  History shows that correct implementation don't superceed
> broken ones - they adopt the flaws in order to interoperate.

A good point. However you're talking about major features of major
very popular products - where being incompatible with an earlier
released bug is instantly and unpleasantly noticeable...

> If those advocating the algorithms won't take the time to insure they are
> specified completely and correctly, who is going to take time to do the
> harder job of implementing them correctly?  Especially when the correct
> implementation may not be the one in the spec.

A fair point. But speaking for myself, I won't be able to contribute
until September.


> So there are three alternatives:
> 
> 1. Delete the unimplementable algorithms (reserving the numbers) and hope
>    that someone wants to define them in the next revision, but submitting
>    a clean spec.

Not nice...

> 2. Don't submit the spec until these things are defined (and I don't
>    see anyone rushing to do the necessary legwork so this might take a
>    very long time).

The most "right" but probably unacceptable because of time...

> 3. Submit a spec with ambiguities that will create lots of opportunites
>    for interoperability problems.
> My original post was a fourth suggestion:
> 4. Leave the ambiguities in but identify them and tell implementors not to
>    use them widely because they are ambiguous and won't interoperate
>    because the details are unclear.
> I am open to a number 5 if anyone has one.  I am against number 3. Many
> have expressed that we need to get something out now, so #2 is probably
> not acceptable.

To identify and list the ambiguities is good. I suspect that when you do 
that, it turns into a correction/solution list...
-- 
Regards,
Uri		uri@xxxxxxxxxxxxxx
-=-=-=-=-=-=-
<Disclaimer>