Re: Integrating BIND 8.2

[Zack Weinberg <zack@rabi.columbia.edu>]

On Wed, 31 Mar 1999 11:51:49 +1000, Geoff Keating wrote:
>> Date: Tue, 30 Mar 1999 16:54:03 -0500
>> From: Zack Weinberg <zack@rabi.columbia.edu>
[...]
>> There are legal problems with the security code.  It depends on RSA for
>> cryptographic signatures; the kit includes a subset of the RSAREF library,
>> issued under a license which is not even vaguely compatible with GPL.  Also,
>> it is probably illegal to export from the US.  We could just leave hooks in
>> libresolv and put a free clone into the crypt add on, except that RSA is
>> patented in the US, so the clone would not be a legal import.  (Are you
>> disgusted yet?)

>> I see three options:
>> 
>> - Ignore the obnoxious license, distribute the RSAREF subset with the main
>> body of libc.  Hope that ISC is right when it says it's legal to export.
>
>You'd need to read very carefully to see what it is exactly that is
>legal to export.  Binaries?  Source?
>
>You really do not want to ignore the RSAREF licence.  The FSF might
>lose GPL protection on libc.

This wasn't a serious suggestion.

>> - Ignore RSA's patent, which expires next year anyway, and put a free clone
>> into the crypt add-on.  Hope RSA doesn't sue the FSF.
>
>Well, the FSF could simply not distribute the add-on until the patent
>expires.  (IIRC, it's actually October 2002 it expires, 20 years after
>its priority date).  Yuk!!

My book says October 2000, but it might've been extended.  Bleah.

[...]
>> - Put RSAREF, or a subset, into the crypt add-on.  Hope this doesn't make
>> libcrypt *binaries* illegal to export from the US, screwing two of the three
>> major distributions.  Also, is RSAREF available outside the US?
>
>That's OK, libcrypt binaries (with the `crypt' plugin) are already
>illegal to export from the US; that's the point of the plugin.
>
>There is, somewhere, a RSAREF clone developed outside the US.  I don't
>remember what licence it's under.

Redhat and Debian (and probably everyone else) take no special
precautions with libcrypt.  I believe I have seen a ruling saying that
crypt(3) is legal, since it can't be used for secrecy.

I know there is a RSAREF clone which qualifies as free software,
developed outside the US.  It can't legally be used inside because of
the patent.  SSH's build docs claim that RSAREF itself is available
outside the USA.

>I would like to avoid having essential features like Secure DNS put
>into the crypt add-on; at present the crypt add-on is only needed for
>compatibility.
>
>This is especially true since Secure DNS does not need encryption,
>only authentication, and so has a completely different set of legal
>problems to the current crypt add-on.

I'm going to see if I can rig something such that libresolv looks for
a cryptographic module at runtime.  That could be distributed as yet
another add-on.  Werner Almesberger (GPG maintainer) was making noises
about a standard GNU crypto library, if it happens we could use it.

>I would be interested in RMS's opinion on this.

Me too.

>I might add that I'm unhappy about the IETF choosing a patented
>algorithm as the _only_ possible algorithm.  The fact that the RFC was
>written in January 1997, when all possible algorithms were patented,
>is only a partial excuse...

Mm... BIND mentions a number of algorithms (but only implements RSA):

const struct res_sym __p_key_syms[] = {
        {NS_ALG_MD5RSA,         "RSA",          "RSA KEY with MD5 hash"},
        {NS_ALG_DH,             "DH",           "Diffie Hellman"},
        {NS_ALG_DSA,            "DSA",          "Digital Signature Algorithm"},
        {NS_ALG_EXPIRE_ONLY,    "EXPIREONLY",   "No algorithm"},
        {NS_ALG_PRIVATE_OID,    "PRIVATE",      "Algorithm obtained from OID"},
        {0,                     NULL,           NULL}
};

const struct res_sym __p_cert_syms[] = {
        {cert_t_pkix,   "PKIX",         "PKIX (X.509v3) Certificate"},
        {cert_t_spki,   "SPKI",         "SPKI certificate"},
        {cert_t_pgp,    "PGP",          "PGP certificate"},
        {cert_t_url,    "URL",          "URL Private"},
        {cert_t_oid,    "OID",          "OID Private"},
        {0,             NULL,           NULL}
};

zw