-----BEGIN PGP SIGNED MESSAGE-----
Gene Hoffman wrote:
...
... there is most likely a
majority of users with DSS/EG keys.
I'll address this separately.
Ignoring that and moving to a couple of more important points, I believe
that the charter had or has a goal of creating a standard to which
implementors anywhere can implement without concern for intellectual
property rights. DSA, SHA-1, ElGamal, 3DES, and CAST5 are all
un-encumbered alogorithims. DSS/ElGamal with either 3DES or CAST should be
the standard MUSTs. If you as an applications developer wish to support
the "legacy" mode of PGP and can get the licenses to do so, please feel
free to implement a SHOULD of RSA/MD5/IDEA as well as
DSS/EG/(???3DES/CAST5????).
I accept the RSA patent as a strong consideration. However, I find
myself taking the devil's advocate.
Outside the US (and perhaps Canada), nobody much cares about the RSA
thing. In fact, nobody much wants to implement ElGamal because it is
slower, messier, not as well proven, and harder to implement. RSA is a
nice algorithm, and we have happily communicated with US people up until
now - why do we need to change?
You might find this odd, but when I talk to European companies, they
actually prefer RSA. Getting them onto something else will be a
problem, especially for the big ones. Let's put it another way: in
Europe there is demand for RSA and no demand for ElGamal.
So which algorithm is a MUST might depend on which side of the Atlantic
the editor is sitting.
For half the market, RSA is good but ElGamal is bad. For the other
half, ElGamal is cool but RSA is out. This argues, in an
*international* standard, for two MUSTs, or two SHOULDs. In an
*international* standard, is there a case for one over the other?
An RSA MUST might be out if IETF can't deliver unencumbered algorithms
to part of the market. What remains is two SHOULDs. (To repeat an
earlier post, could somebody summarise the IETF experiences or feelings
specifically regarding RSA?)
Two SHOULDs would work, although it appears clumsy on the surface.
Let's work through it.
Half the market (US) goes with ElGamal, and the other half (non-US)
stays with RSA. Remember, this is how it is now (being loose on the
definition of "half"):
* In the short term, those in the US half of
the connection will simply buy the plugin
(say for the next year).
* In the medium term, the unincentivised Europeans
(and Australians and Japanese and ...) will get
around to doing ElGamal. Maybe faster if we can
find some US customers to pay for it.
* In the longer term (4 years time) the RSA patent
expires and we can all go back to using RSA,
which is what we wanted to do in the first place.
But to rush this process simply to get one international unencumbered
standard that not everyone wants will cause a rift that need not
happen. The Eastern half simply don't need to do this. (Odd that -
perhaps the Westerners should be paying for the development of
Euro-crypto :-)
It's not so simple. Regardless of my arguments above, I do not find
that there is a clear and obvious case here either way, and would hope
that we can develop these arguments without biases getting in the way.
Joe has got to get a license from Security Dynamics....
More crypto will get deployed if ANYONE can build it and sell it. Also, it
seems like "the interoperability problem" decreases linearly with time.
Once this proposal is done, I would hope that people like Ian will be
making available OpenPGP compliant software and toolkits that implement
both RSA/MD5/IDEA and DSS/EG/?3DES-CAST5?
To confirm, the Cryptix Development Team do have an ElGamal
implementation. It is close enough to delivery that it will beat this
standard out (I hope) but it's not as if we have any customers asking
for it so there's no hurry. Our US users aren't allowed to ask of
course ;-)
I don't know of any other pgp developers that have even started on the
ElGamal side, I have asked on pgp-dev.
On the symmetric front, I'd like to suggest that all software MUST Decrypt
CAST5 and 3DES, but only MUST encrypt 3DES. In this way, those application
developers/ end users who wish to use CAST5 as their default can be
assured that someone out there can read what they generate. If they find a
key from an application that does not "prefer" CAST5, then they will know
how to encrypt 3DES so as to conform to spec...
I know of no practical, technical or business scenario where it makes
sense to deploy decryption but not encryption (with symmetric ciphers).
If you have the algorithm to decrypt, you can use it to encrypt.
USG/NIST did spend an awful lot of money deploying a system that could
sign and not encrypt (DSS), but that's politics.
- --
iang systemics.com
FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com
-----BEGIN PGP SIGNATURE-----
Version: Cryptix 2.21
iQCVAgUANFlQqJUdDk1bRs+FAQEN7wP+P/HDGRVAQORhWRhnnEsEntNKlORqK2lw
9wfl7tFkQgFkFBgiyN6QVfaxc+M0Evt0++M6RO56g/L5YO3bb5LDCFMc0PdBCQd+
lazWJ75hqEiBjD3qJca1psFgGepjBVYKINWs7Y0Au3tI4x6k5CJd8WCZ4KrRs3Y3
wWGF1c9iW1g=
=ET6o
-----END PGP SIGNATURE-----