-----BEGIN PGP SIGNED MESSAGE-----
In <199807021205(_dot_)FAA18302(_at_)mail(_dot_)proper(_dot_)com>, on 07/02/98
at 11:04 PM, Lindsay Mathieson <lindsay(_at_)powerup(_dot_)com(_dot_)au>
said:
Well, considering that the US *is* the computer market anything other
than freeware is affected by the RSADSI patents. Add to this that the
majority of software is written in the US
Are you serious ?
Yes
While the majority of software may be written in the US, given the
restrictive us encrytpion regulations the majority of *security* software
is being written & maintained outside the US.
I would be willing to debate that but in either case the issue is software
markets. Regardless of where it is written as soon as you try to *sell* it
in the US you are up against the RSADSI patents issue or are you content
to only sell your software to non US markets? Will RSADSI even license
it's software to non-US companies? Considering that they mandate that you
only use their software I highly doubt it.
So even if you are overseas you only have two options if you want to sell
to the US market:
1. Don't use RSA or other proprietary algorithms.
2. Establish a *physical* presence in the US and hire the staff to
maintain 2 different code bases for your products.
Of course you can be content to leave the entire US market to NAI. I for
one do not find that an acceptable alternative.
I though we covered this whole US/rest of the world thing ages ago ... --
Not really and I wouldn't be too smug and cozy about US policies as AU
seems to be going the same route. If you have any doubts I suggest you
take a look at http://jya.com/oz-crypto.htm and the trouble Eric Young and
Tim Hudson are having over Cryptozilla.
Look people my intent here was not to get into a national dick waving
contest. We have an opportunity here to get the proprietary algorithm
monkey off our back. Hell, PGP Inc. has done all the hard work for us by
moving the majority of the user base away from RSA/IDEA to ELGamal/DSS.
All we have to do is not implement the code. Really simple and it doesn't
cost a thing :)
There is an important issue to understand when it comes to a
multi-algorithm standard. If algorithm set A is a MUST and algorithm set B
is a MAY but everyone is *using* algorithm set B, algorithm set B becomes
a defacto MUST. This is due to the unique nature of communication crypto
rather than some form of local crypto (ie file encryption).
As an example: If 90% of the user base is signing their messages with RSA
sigs and you want to sell a product to communicate with those users you
had best be able to process RSA sigs to (IMHO this is something the S/MIME
group has failed to understand though I am sure RSADSI has).
Encryption is not as big of an issue as multiple keys can resolve this
issue. Unfortunately outside of the code I have written and one other
freeware product *none* of the e-mail integrations (especially none of the
commercial products) take into account multiple keys with the same userid.
A compromise to this problem would be to have the systems that support RSA
require the user to generate not only a RSA key but an ElGamal/DSS key at
the same time. All 3 keys would be combined into one key with 2 subpackets
(or 3 if you want separate RSA keys for signing & encrypting). Then one
would have their application make use of parallel signatures where the
data is signed with both the RSA and DSS signatures. I believe that this
can be accomplished using the one-pass signature format but I would have
to go back to the specs to check on that.
There are still problems in dealing with the old RSA keys that are not of
this format. The application would need to require that the user generate
an ElGamal/DSS keypair to correspond to the imported RSA key. It would
have to support multiple keys for the same userid and it would still need
the ability to generate parallel signatures.
It might not be a bad idea for an implementor to require that when a
signature key that is generated/imported is *not* a DSA signature key that
either one of two thing happen:
1. The user already has a DSA key and it is "linked" to the non-DSA key
for use in parallel signatures with the non-DSA key.
2. The user generates a new DSA key to be used in parallel signatures with
the non-DSA key.
There is nothing in the specs for doing this type of linking (or any key
management for that matter) so this will need to be done on the
application level.
FWIW I don't have a problem with those who wish to have RSA support for
processing incoming messages for backward compatibility it is the
generating of new messages using RSA that I see as a problem.
I would be interested to hear what NAI's plans are for PGP now that they
have settled with RSADSI. The route they go with thier new releases will
pretty much shape what everyone else will need to do.
- --
- ---------------------------------------------------------------
William H. Geiger III http://users.invweb.net/~whgiii
Geiger Consulting Cooking With Warp 4.0
Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 5.0 at: http://users.invweb.net/~whgiii/pgp.html
- ---------------------------------------------------------------
Tag-O-Matic: I use OS/2 2.0 and I don't care who knows!
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a-sha1
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000
iQCVAwUBNZuz9I9Co1n+aLhhAQG0FwP8DIYD2xD/4OOmUgL57WgNzhRenNUm5Bvq
u4ARMgFo++LleuTtvUoG0m8znUE84trgofXNPXtmGqFgOJKE0JAeBmgjwj5R69bZ
8We32V+wbojUcEziC3XRRmEkNatvnznZ9gte/knhI9DMfShjTLPZfBt7P4dGuIhD
uFHqyiG1yIE=
=SNyO
-----END PGP SIGNATURE-----