On Thu, 2 Jul 1998, William H. Geiger III wrote:
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.
AFAIK, Stronghold uses SSLeay code in original form including their
implementation of RSA. Of course licensing it proves to be prohibitive
except for large companies or those whose perserverance would qualify
them for sainthood. Fortunately this will expire in a few years.
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.
What should happen is that any current RSA keys become (depricated)
subkeys linked to the DSA primary key just like the DH key already is.
The problem is then we need something that is different than a revocation
- you could send the whole glob as sort of a key-integration message.
There is only a signature that allows for stating with certainty the user
ID, but not one that claims that key1 and key2 are the same person (or can
we slip a 0x14 sig type in)? The signature should always be in the
reverse direction of the superceeding, i.e. the RSA key signs the DSA key
to say to use the DSA keyset from now on. (not quite, superceeding is
different than wanting to use two different keys but to say they are both
"me" - 0x15? It is filling rapidly :).
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.
And whether they can use their own RSA code, or will we be stuck with
something limiting the number of bits in the key?
--- reply to tzeruch - at - ceddec - dot - com ---