This is the mail archive of the libc-hacker@cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Integrating BIND 8.2


> X-Organisation: Faculty of Mathematics, Computer Science, Physics & Astronomy
>                 University of Amsterdam
>                 The Netherlands
> X-Address:      See http://www.wins.uva.nl/location
> Date: Thu, 1 Apr 1999 19:52:05 +0200 (CEST)
> From: Mark Kettenis <kettenis@wins.uva.nl>
> CC: baccala@FreeSoft.org, zack@rabi.columbia.edu, libc-hacker@cygnus.com,
>         rms@santafe.edu
> 
>    Date: Thu, 1 Apr 1999 08:55:50 +1000
>    From: Geoff Keating <geoffk@ozemail.com.au>
> 
>    Happily, RFC 2535 obsoletes RFC 2065.  Now, it is the DSA algorithm
>    that is mandatory.  So our problem has gone away; we can just avoid
>    implementing RSA until the patent expires (whenever that is):
> 
>    3.2 The KEY Algorithm Number Specification
>    ...
>       Algorithm specific formats and procedures are given in separate
>       documents.  The mandatory to implement for interoperability algorithm
>       is number 3, DSA.  It is recommended that the RSA/MD5 algorithm,
>       number 1, also be implemented.  Algorithm 2 is used to indicate
>       Diffie-Hellman keys and algorithm 4 is reserved for elliptic curve.
> 
> Unfortunately we cannot use the DSA code included in bind 8.2, since
> it is not freely distributable.

That's OK.  It's easy enough to rewrite stuff like this.  Probably
the BIND people would be happy to have a LGPLed version.

> The problem is that even DSA is still export restricted. 

I understand that software for computing a "Message Authentication
Code (MAC) or similar result" (eg. DSA signatures), is not
export-controlled, as long as it "does not allow for encryption of
data, text, or other media other than that needed for the
authentication" (the quotes are from the US Commerce Control List
available at <http://www.access.gpo.gov/bxa/ear/ear_data.html>).

However, the US regulations on this are very complicated (there are
exceptions to exceptions to exceptions to exceptions, and I'm still
looking to see if there's a fifth level...) so it's possible I've got
this wrong.  John Gilmore thinks that export of this is OK, see
<http://www.toad.com/~dnssec/>, and got the US government to agree.

The BIND readme says that

... it is free for use and redistribution and incorporation into
    vendor products and export and anything else you can think of
    ...

but this can't be considered completely reliable since it is
contradicted by the "DNSSAFE LICENSE TERMS":

                        DNSSAFE LICENSE TERMS

This BIND software includes the DNSsafe software from RSA Data
Security, Inc., which is copyrighted software that can only be
distributed under the terms of this license agreement.

The DNSsafe software cannot be used or distributed separately from the
BIND software.  You only have the right to use it or distribute it as
a bundled, integrated product.

The DNSsafe software can ONLY be used to provide authentication for
resource records in the Domain Name System, as specified in RFC 2065
and successors.  You cannot modify the BIND software to use the
DNSsafe software for other purposes, or to make its cryptographic
functions available to end-users for other uses.

If you modify the DNSsafe software itself, you cannot modify its
documented API, and you must grant RSA Data Security the right to use,
modify, and distribute your modifications, including the right to use
any patents or other intellectual property that your modifications
depend upon.
...

-- 
Geoffrey Keating <geoffk@ozemail.com.au>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]