On Fri, 26 Jun 1998, Uri Blumenthal wrote:
The users are protected by symmetric pref rules. If my self-sig doesn't
have algorithm X in it, then an implementation is not to use X. This
permits us to be relatively free with assigning algorithm IDs. In any
event, once IDs are assigned by IANA, they're more likely to be more free
than the stingy folks would like.
This protection is perfectly good enough in my opinion.
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.
To sum up, MAY means MAY, it doesn't mean SHOULD NOT. I think that any new
algorithm that is born SHOULD NOT simply shouldn't be there. If there's
rousing, quick, consensus here to delete some set of algorithms, that
change is easy for me to do. If anyone wants to comment, the comments
better come quickly.
SHOULD NOT implement is not the same as SHOULD NOT be used for
publication. You MAY drive your moped, but you SHOULD NOT drive it on the
freeway. Just as there is a distinction between a residential street and
a freeway, 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.
This isn't clearly stated in the spec as it stands. 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.
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. Do you mean the raw
algorithms, or the cfb-reset-after-10 that PGP uses? What decides,
whoever is first-to-implement? 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 can interchange X509 and PGP formats
easily, but no one has mentioned that capability of my implementation,
while they want algorithms added specifically to do this function (which
won't really work - e.g. MD2 digests different material in X509 and PGP,
so why have the algorithm in PGP since you can't place the correct
information to be hashed into any PGP signature packet).
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.
If you are going to let every implementation use whatever combination it
wants, the only way of limiting it is to remove algorithms.
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.