I'd like to start a discussion on what to include in the initial 
cryptosrc-intl tree. This serves as background. It has been discussed
by netbsd-developers for some time.

$Id: netbsd-intl-plan,v 1.4 1999/06/22 23:38:44 mcr Exp mcr $

General Problem:
	NetBSD's source tree currently includes a subtree called "domestic"
	which contains code that can not leave the United States due to
	Cryptographic export restrictions.

	People not resident in the United States currently have no standard
	cryptographic facilities as part of their tree. While there is plenty
	of available code available outside of the US, it is not well
	integrated into the system, and so is hard to use, and hard to
	count upon. As the NetBSD source tree is currently hosted in
	the United States, it is not currently possible for non-US citizens
	to usefully contribute cryptographic code to the NetBSD tree
	as once it enters the US, it may not leave again.

Opportunity

	The NetBSD Foundation has secured a machine with disk space
	and sufficient internet bandwidth to function as a non-US CVS
	server. This is cvs.fi.netbsd.org. The machine was provided by
	SSH Communications Security Oy, and the bandwidth by HUT
	(Helsinki University of Technology). Finland has rather
	liberal export rules on cryptography, so while US citizens
	(and people resident in the US) are still forbidden to
	contribute cryptographic to this repository, then can at least
	import it, and the rest of us can freely contribute code.


Background Proposal
	All of the non-crypgraphic parts of the NetBSD CVS repository
	code will be mirrored and/or moved to cvs.fi.netbsd.org. The
	details of this are not covered in this document.

Cryptographic Proposal
	A new subtree of /usr/src will be created. It will be named
|	"crypto-intl". In the new source tree organization, it will
|	live in /cvsroot/cryptosrc-intl/crypto-intl.

	A new subtree is needed as citizens/residents of countries with
	export restrictions will not be able to contribute code 
	to this part of the tree. The distinction will help them avoid
	breaking their own (misguided) laws.

	Some comments about the name: while the opposite of "domestic"
	is "export", typically the "export" version of a US program is
	the version without cryptography. We are not trying to do
	that. Rather we are making a non-US version that has
	cryptography. Intl is short for "international"		

| 	It has been suggested that "intl" along may get confused with i18n
|	efforts to make NetBSD happy with multilingual character sets. Thus
|	the name change to "crypto-intl"

|	Subdirectories of "crypt-intl" will resemble those of domestic (I'm
	told. I've never officially seen it ;-} ), or "gnu", i.e. there will be:
		
|	/usr/src/crypto-intl/lib	- support libraries
|	/usr/src/crypto-intl/bin	- programs for /bin
|	/usr/src/crypto-intl/usr.bin	- programs for /usr/bin
|	/usr/src/crypto-intl/sbin	- programs for /sbin
|	/usr/src/crypto-intl/usr.sbin	- programs for /usr/sbin
|	/usr/src/crypto-intl/sys	- kernel code
|	/usr/src/crypto-intl/dist	- original archives
|	/usr/src/crypto-intl/libexec - daemons
|	/usr/src/crypto-intl/etc
|	/usr/src/crypto-intl/share/examples

	Where reasonable, the Makefile files will use the "reach-over"
	technique into the dist area where original packages source
	trees will be kept. E.g:
	/usr/src/crypto-intl/lib/libdes/Makefile might grab code from
		{../..,/usr/src/crypto-intl}/dist/openssl/libdes
	
	Kernel Code
|	The kernel "crypto-intl/sys" area will be a shadow of /usr/src/sys.
|	There will a /usr/src/crypto-intl/sys/conf/files that will include
	/usr/src/sys/conf/files etc. This will allow kernels to be
	build/configured/etc. that contain cryptography, but without
	duplicating or polluting any of /usr/src/sys which must remain
	exportable from the US. Modifications to config(9) may be required to
	deal with additional paths, or possible additional makefile
	sections. At this time, it is believed that no additional features
	will be needed. 

What to include, where to put it

	Quite a large number of cryptographic programs may be better
	suited for pkgsrc inclusion. Apache-SSL comes to mind here.
	There are however, several categories of programs that will
	need to go into crypto-intl: 

	1. anything intended to go into the kernel:
		-IPsec
		-cryptographic signing of user binaries/lkms
		-public key based capability based extensions (a la KeyOS)
		-cryptographic file systems (including network file systems
			i.e. AFS-like stuff) 
		-secure network booting code
		
	2. support programs for above
	3. base libraries/headers that we wish to distribute to make crypto
		ubiquitous: i.e. RSA, DSS, DH, CAST, 3DES
	4. code that enhanced from code we maintain (i.e. Kerberized
		/bin/login, telnet)
	5. original code from the NetBSD project

	#4 implies that we would like to have Kerberos version 4 and
		Kerberos version 5 included. It is hoped that the Heimdal
		project will eventually provide this base. We can
		argue about whether or not we should just leave this
		in pkgsrc. 

Timeline
	We will start using cvs.fi.netbsd.org as soon as this proposal 
	is approved.

	The 1.5-current snapshots will start to include a "crypto-intl"
	package.

	The "secr" package would be renamed "domestic" or "domt". 

	1.5 might ship with just the crypto-intl package for distributions
 	that are created outside of the US. This is open to debate. We may
	prefer to continue leaving crypto an optional part. 

Additional minor items
	1. create a new list "tech-crypto"

	2. while it isn't that cool, you can check out "src" from
	cvs.netbsd.org and then checkout "src/crypto-intl" from
	cvs.fi.netbsd.org. You need to be a bit careful about not running
	"cvs update" from the toplevel with CVS versions lower than
	1.10. 1.10 can cope with parts of the tree being on different servers.

	3. we need to make sure that all ports have a non-US builder to build
	the crypto-intl area. It isn't enough to have a non-US machine, but 
	the person typing "make" must not be a US citizen or a US resident.
	Herb's lab is in Calgary, so machines should be in the right place.