Oh boy, do you annoy me...
dontspam-tzeruch(_at_)ceddec(_dot_)com says:
But my self-sig can have X in it, and might be a self-sig using X. So if
I create an El-Gamal signature using MD2, and send it to the public
keyservers, what happens? I don't know if every keyserver will take 5.0
keys yet, nor if every impelmentation will fail gracefully.
So...? If you want your sig to be universally accepted, you'll not
use MD2, and probably not PGP-5 yet. On the other hand, if you
need or want the features of PGP-5 (or MD2), you'll knowingly
sacrifice some accessibility...
Why are you wasting time proving that water is wet?
SHOULD NOT implement is not the same as SHOULD NOT be used for
publication.
Look: this "should not" idea of yours is crap. Accept it and get
back to doing something useful.
You MAY drive your moped, but you SHOULD NOT drive it on the
freeway.
Your analogy sucks because you don't understand (a) the terminology
of IETF standards and (b) how they work. You ignore the fact that
some use cars exclusively for highway driving, some others use
them for the backroads only, and yet others for both. Using
the very same vehicle. What you are trying to say is "forbid
that Corvette fro showing on back-roads, and expel Ford Escort
from the freeway".
[I don't know why I'm wasting my time on this. Need to vent the spleen
that you stirred, I guess - no other sane reason in sight.]
Just as there is a distinction between a residential street and
a freeway,
The car I drive does not know that distinction. Neither should PGP.
.....there should be a distinction between algorithms used to
interoperate with nonPGP things (like Fortrezza or X509) or an
experimental or specific local purpose and those used to publish things
like keys, or for interoperability without foreknowledge.
MUST defines the minimum necessary for interoperability. SHOULD defines
"you might not have it if you really have a bloody good reason..." MAY
defines things that you may have if you choose, but you're blameless if
you don't.
What is there not to understand?! This tree seems particularly unworthy
to be barked at. Don't know about you time, but I'm getting positively
annoyed by this sh**, er, stuff.
But there is an implicit set of algorithms:
PGP 5.X unencumbered (DSA/DH/3DES/SHA1) PGP 5.X general (above + CAST)
PGP 2.6 interoperable (RSA/RSA/IDEA/MD5)
--------
PGP 5.X general (above + ElGamal, RIPEMD160, DSA w/ !SHA1)
GNUPG (adds TIGER, BlowFish, and gzip compression)
My point is that for publication, one should stay above the line.
Your point doesn't make sense and isn't worth the electrons used to
carry it, if you forgive my bluntness. But I have little time and
even less patience left to deal with this nonsense.
I'm against it. As a matter of fact, I'd like to propose to ADD some
more, that AES competition will "unearth". Surely we'll want to AT
THE VERY LEAST support the AES winner itself? And for the sake
of interoperability with Fortezza might we not include SKIPJACK?
Just two examples...
Except you haven't really given any examples.
Does "AES" mean anything to you? Some candidates (quite good, BTW)
were already published, the rest will be published shortly. There
will be a winner, as I hope you understand. So, RC6 is not an
example worth your attention? TwoFish? LOKI97? Or do I have
to waste my time spelling out every candidate, one of who
will become "the" AES? And of course you don't think any of
the above should be in the MAY category, let alone SHOULD?
Is SKIPJACK not qualified to be an "example" of a new encryption algorithm
that one MAY implement?
Do you mean the raw algorithms, or the cfb-reset-after-10 that PGP uses?
Do you interoperate with raw algorithms, or with cfb-reset-after-10?
Isn't it bloody obvious that an algorithm definition must be specific
enough to be unambiguously implementable (and make sense at the same
time, so ECB mode isn't likely to cut it, for example)?
Do you really have this much free time on your hands to ask such questions?
What decides, whoever is first-to-implement?
^^^^ I hope it will be "who" that decides, but in your case...
The implementor, s****d. In your implementation - you do. So you
must implement the MUST ones, you should implement the SHOULD
ones, and the rest is entirely up to you. What is there NOT
to undertand?!
Now DO YOU get it??
What if there are multiple variants (e.g.
a 3-aes, or there are advantages to an ofb mode, or different key or
block sizes?)... And what of the other layers?..............
I'm tired. You go and figure it out yourself.
The point of my language is that if the PGP email and public key
infrastructure is more limited as to what will be seen by all the diverse
implementations (as my language would suggest) then I am for adding
algorithm IDs as MAYs even if they aren't fully defined or will rarely be
used.
No it is not. The natural selection will "wither" some of the defined
algorithms and make others "blossom". But it is absolutely not up to
you to guesstimate which ones will "live" and which ones will "die".
If you are going to let every implementation use whatever combination it
wants, the only way of limiting it is to remove algorithms.
Pure unadulerated bulshit. Since when did we enter a "single-Party"
system... Interoperability is ensured by (a) defining the common
set of algorithms that is always present and (b) describing all
the algorithms correctly and unambiguously.
If you absolutely have to limit something, please limit your arguments.
Remember that there is going to be a 1.1 version of the spec and I assume
a corresponding RFC. Not having an OID for HAVAL isn't critical if the
algorithm ID isn't coming soon to a PKserver near you. If the intent is
to allow publication to the PKI of every possible algorithm, I would be
for removing most of those that aren't completely defined or don't add to
any existing implementation.
It sounds like you're being force to pay for each OID from your own
pocket, and in hard currency. Please relax - we got plenty of OIDs
and they are still pretty cheap.
Now may we all return to solving the real problems at hand? Please?
--
Regards,
Uri uri(_at_)watson(_dot_)ibm(_dot_)com
-=-=-=-=-=-=-
<Disclaimer>