At 6:14 PM 9/28/95, Eric Young wrote:
On Fri, 29 Sep 1995, Jonathan Zamick wrote:
Consensus Development and RSA Data Security, have finalized the
contract for Consensus to license and support RSAREF(tm) for
...
Lastly, we would like to hear suggestions and ideas on how to
improve RSAREF. We intend to remain responsive to requests, and
welcome ideas for the evolution of the RSAREF toolkit.
Are you going to change the licencing restrictions on the lower level RSA
function interface? To implement protocols such as SSL, one requires
access to RSAPrivateDecrypt(), RSAPrivateEncrypt(), RSAPublicDecrypt()
and RSAPublicEncrypt().
To be precise, we have a "waiver" that we can grant a licensee to "go
underneath" the published API. This waiver allows limited access to
DES_CBCInit() and DES_CBCUpdate() for securing the channel, and
RSAPublicEncrypt() and RSAPrivateDecrypt() for server endpoint
authentication only.
Right now we can only grant that waiver for the SSLREF implementation by
Netscape, or in an SSL implementation by Consensus. We are in the process
of deciding whether to aquire an SSL implementation or write our own that
would be freely available to any RSAREF licensee.
To get the waiver for any other SSL implementation right now requires
written permission from RSA. However, we are working on the spec for a new
API to RSAREF that will be part of the published interface that hopefully
will make these routines available at protected level so that no waivers
are required at all for an SSL-like implementations. We are seeking advice
on the best way to do so.
RSA's objectives in restricting the API may not be obvious to some -- they
are concerned that by granting you direct access to some of the lower level
routines that it is possible to violate patents that RSA does not own (some
of the secret sharing or digital cash patents, for instance.) The published
API is designed to make violating other patents difficult. I hope that we
can accomplish the same result for future SSL oriented enhancements to the
RSAREF API that will meet the same goals.
We also are working closely with VeriSign to create keypair generation and
x.509 server heirarchy certificate request software independent of SSL
(i.e. could be used by any server protocol,) so it is no longer necessary
for an SSL application to do keygen or issue certificates. Because of
random seed issues, the encryption and storage of of private keys, and
other security issues, VeriSign is very reluctant to issue server
certificates based on unknown or modified source code. The intent is that
this utility will be free, and source code will be easily licensable under
non-disclosure so that it can be inspected for security issues. In the
future this utility may also be 'callable' by server applications so that
they can put their own interface on it if they wish.
I have now implemented my own version of RSAref (the same functionality)
as part of an SSL library. To stop people in the USA from violating the
RSA patent I replace my functions to perform the above mentioned
operations with calls the those functions in RSAref; I'm doing a similar
thing to PGP. Currently I belive this is illegal unless I get a
licence. Is this going to change?
I am aware of the your situation here, and hope that as we improve the
RSAREF published API that it may solve a number of these types of issues.
The current priority in RSAREF 2.1 is to abstract out some calls that will
allow PGP to not have to make calls "underneath" the published interface so
that PGP waivers to use RSAREF no longer have to be issued.
Meanwhile, any waivers to go under the API except for SSLREF (which has
been pre-approved) must be approved by RSA (which they have granted to
companies in the past.)
I am in the interesting situation of being some-one who will probably
never see or use RSAref (being outside the USA) but for people to use my
code in the USA I have to know the RSAref API. I think things
would be rather wierd if I had to licence the use of the 'non-standard'
RSAref interface but never actually see the code.
Of course, for you, this makes things even more difficult. I am
knowledgable enough of the cryptography export issues that I am very wary
of making broad statements, but I hope that it will be possible for people
outside of the US to create their own libraries compatible with a published
RSAREF API. The reality is that it may not be possible under the current
political climate.
A different export issue that I've not resoved completeley is access to
RC2/RC4. RSA has agreed in principle to allow Consensus' RSAREF licensees
access to an object-code implementation of RC2 or RC4 that will be limited
to exportable sized keys, and contractually limited for use in published
internet standards such as PEM, SSL, S/MIME, etc. It will take a little
more time to finalize that agreement with RSA.
------------------------------------------------------------------------
..Christopher Allen Consensus Development Corporation..
..<ChristopherA(_at_)consensus(_dot_)com> 1563 Solano Avenue
#355..
.. Berkeley, CA 94707-2116..
..<http://www.consensus.com/> o510/559-1500 f510/559-1505..