- Flatten the vendor heimdal tree.

27 files changed, 0 insertions, 8284 deletions

diff --git a/crypto/heimdal/doc/Makefile.am b/crypto/heimdal/doc/Makefile.am
deleted file mode 100644
index 87473fe..0000000
--- a/crypto/heimdal/doc/Makefile.am
+++ /dev/null
@@ -1,85 +0,0 @@
-# $Id: Makefile.am 22284 2007-12-13 20:39:37Z lha $
-
-include $(top_srcdir)/Makefile.am.common
-
-AUTOMAKE_OPTIONS = no-texinfo.tex
-
-MAKEINFOFLAGS = --no-split --css-include=$(srcdir)/heimdal.css
-
-TEXI2DVI = true # ARGH, make distcheck can't be disabled to not build dvifiles
-
-info_TEXINFOS = heimdal.texi hx509.texi
-
-dxy_subst = sed -e 's,[@]srcdir[@],$(srcdir),g' \
-	-e 's,[@]objdir[@],.,g' \
-	-e 's,[@]PACKAGE_VERSION[@],$(PACKAGE_VERSION),g'
-
-krb5.dxy: krb5.din Makefile
-	$(dxy_subst) < $(srcdir)/krb5.din > krb5.dxy.tmp
-	chmod +x krb5.dxy.tmp
-	mv krb5.dxy.tmp krb5.dxy
-
-ntlm.dxy: ntlm.din Makefile
-	$(dxy_subst) < $(srcdir)/ntlm.din > ntlm.dxy.tmp
-	chmod +x ntlm.dxy.tmp
-	mv ntlm.dxy.tmp ntlm.dxy
-
-hx509.dxy: hx509.din Makefile
-	$(dxy_subst) < $(srcdir)/hx509.din > hx509.dxy.tmp
-	chmod +x hx509.dxy.tmp
-	mv hx509.dxy.tmp hx509.dxy
-
-hcrypto.dxy: hcrypto.din Makefile
-	$(dxy_subst) < $(srcdir)/hcrypto.din > hcrypto.dxy.tmp
-	chmod +x hcrypto.dxy.tmp
-	mv hcrypto.dxy.tmp hcrypto.dxy
-
-
-texi_subst = sed -e 's,[@]dbdir[@],$(localstatedir),g' \
-	-e 's,[@]PACKAGE_VERSION[@],$(PACKAGE_VERSION),g'
-
-vars.texi: vars.tin Makefile
-	$(texi_subst) < $(srcdir)/vars.tin > vars.texi.tmp
-	chmod +x vars.texi.tmp
-	mv vars.texi.tmp vars.texi
-
-doxygen: krb5.dxy ntlm.dxy hx509.dxy hcrypto.dxy
-	doxygen krb5.dxy
-	doxygen ntlm.dxy
-	doxygen hx509.dxy
-	doxygen hcrypto.dxy
-
-heimdal_TEXINFOS = \
-	ack.texi \
-	apps.texi \
-	heimdal.texi \
-	install.texi \
-	intro.texi \
-	kerberos4.texi \
-	migration.texi \
-	misc.texi \
-	programming.texi \
-	setup.texi \
-	vars.texi \
-	whatis.texi \
-	win2k.texi
-
-EXTRA_DIST = \
-	krb5.din \
-	ntlm.din \
-	hx509.din \
-	hcrypto.din \
-	heimdal.css \
-	init-creds \
-	latin1.tex \
-	layman.asc \
-	doxytmpl.dxy \
-	vars.tin
-
-CLEANFILES = \
-	krb5.dxy* \
-	ntlm.dxy* \
-	hx509.dxy* \
-	hcrypto.dxy* \
-	vars.texi*
-
diff --git a/crypto/heimdal/doc/Makefile.in b/crypto/heimdal/doc/Makefile.in
deleted file mode 100644
index b79a7e3..0000000
--- a/crypto/heimdal/doc/Makefile.in
+++ /dev/null
@@ -1,982 +0,0 @@
-# Makefile.in generated by automake 1.10 from Makefile.am.
-# @configure_input@
-
-# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
-# 2003, 2004, 2005, 2006  Free Software Foundation, Inc.
-# This Makefile.in is free software; the Free Software Foundation
-# gives unlimited permission to copy and/or distribute it,
-# with or without modifications, as long as this notice is preserved.
-
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
-# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
-# PARTICULAR PURPOSE.
-
-@SET_MAKE@
-
-# $Id: Makefile.am 22284 2007-12-13 20:39:37Z lha $
-
-# $Id: Makefile.am.common 10998 2002-05-19 18:35:37Z joda $
-
-# $Id: Makefile.am.common 22488 2008-01-21 11:47:22Z lha $
-VPATH = @srcdir@
-pkgdatadir = $(datadir)/@PACKAGE@
-pkglibdir = $(libdir)/@PACKAGE@
-pkgincludedir = $(includedir)/@PACKAGE@
-am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
-install_sh_DATA = $(install_sh) -c -m 644
-install_sh_PROGRAM = $(install_sh) -c
-install_sh_SCRIPT = $(install_sh) -c
-INSTALL_HEADER = $(INSTALL_DATA)
-transform = $(program_transform_name)
-NORMAL_INSTALL = :
-PRE_INSTALL = :
-POST_INSTALL = :
-NORMAL_UNINSTALL = :
-PRE_UNINSTALL = :
-POST_UNINSTALL = :
-build_triplet = @build@
-host_triplet = @host@
-DIST_COMMON = $(heimdal_TEXINFOS) $(srcdir)/Makefile.am \
-	$(srcdir)/Makefile.in $(top_srcdir)/Makefile.am.common \
-	$(top_srcdir)/cf/Makefile.am.common mdate-sh
-subdir = doc
-ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
-am__aclocal_m4_deps = $(top_srcdir)/cf/aix.m4 \
-	$(top_srcdir)/cf/auth-modules.m4 $(top_srcdir)/cf/autobuild.m4 \
-	$(top_srcdir)/cf/broken-getaddrinfo.m4 \
-	$(top_srcdir)/cf/broken-glob.m4 \
-	$(top_srcdir)/cf/broken-realloc.m4 \
-	$(top_srcdir)/cf/broken-snprintf.m4 $(top_srcdir)/cf/broken.m4 \
-	$(top_srcdir)/cf/broken2.m4 $(top_srcdir)/cf/c-attribute.m4 \
-	$(top_srcdir)/cf/capabilities.m4 \
-	$(top_srcdir)/cf/check-compile-et.m4 \
-	$(top_srcdir)/cf/check-getpwnam_r-posix.m4 \
-	$(top_srcdir)/cf/check-man.m4 \
-	$(top_srcdir)/cf/check-netinet-ip-and-tcp.m4 \
-	$(top_srcdir)/cf/check-type-extra.m4 \
-	$(top_srcdir)/cf/check-var.m4 $(top_srcdir)/cf/check-x.m4 \
-	$(top_srcdir)/cf/check-xau.m4 $(top_srcdir)/cf/crypto.m4 \
-	$(top_srcdir)/cf/db.m4 $(top_srcdir)/cf/destdirs.m4 \
-	$(top_srcdir)/cf/dlopen.m4 \
-	$(top_srcdir)/cf/find-func-no-libs.m4 \
-	$(top_srcdir)/cf/find-func-no-libs2.m4 \
-	$(top_srcdir)/cf/find-func.m4 \
-	$(top_srcdir)/cf/find-if-not-broken.m4 \
-	$(top_srcdir)/cf/framework-security.m4 \
-	$(top_srcdir)/cf/have-struct-field.m4 \
-	$(top_srcdir)/cf/have-type.m4 $(top_srcdir)/cf/irix.m4 \
-	$(top_srcdir)/cf/krb-bigendian.m4 \
-	$(top_srcdir)/cf/krb-func-getlogin.m4 \
-	$(top_srcdir)/cf/krb-ipv6.m4 $(top_srcdir)/cf/krb-prog-ln-s.m4 \
-	$(top_srcdir)/cf/krb-readline.m4 \
-	$(top_srcdir)/cf/krb-struct-spwd.m4 \
-	$(top_srcdir)/cf/krb-struct-winsize.m4 \
-	$(top_srcdir)/cf/largefile.m4 $(top_srcdir)/cf/mips-abi.m4 \
-	$(top_srcdir)/cf/misc.m4 $(top_srcdir)/cf/need-proto.m4 \
-	$(top_srcdir)/cf/osfc2.m4 $(top_srcdir)/cf/otp.m4 \
-	$(top_srcdir)/cf/proto-compat.m4 $(top_srcdir)/cf/pthreads.m4 \
-	$(top_srcdir)/cf/resolv.m4 $(top_srcdir)/cf/retsigtype.m4 \
-	$(top_srcdir)/cf/roken-frag.m4 \
-	$(top_srcdir)/cf/socket-wrapper.m4 $(top_srcdir)/cf/sunos.m4 \
-	$(top_srcdir)/cf/telnet.m4 $(top_srcdir)/cf/test-package.m4 \
-	$(top_srcdir)/cf/version-script.m4 $(top_srcdir)/cf/wflags.m4 \
-	$(top_srcdir)/cf/win32.m4 $(top_srcdir)/cf/with-all.m4 \
-	$(top_srcdir)/acinclude.m4 $(top_srcdir)/configure.in
-am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
-	$(ACLOCAL_M4)
-mkinstalldirs = $(install_sh) -d
-CONFIG_HEADER = $(top_builddir)/include/config.h
-CONFIG_CLEAN_FILES =
-depcomp =
-am__depfiles_maybe =
-SOURCES =
-DIST_SOURCES =
-INFO_DEPS = $(srcdir)/heimdal.info $(srcdir)/hx509.info
-am__TEXINFO_TEX_DIR = $(srcdir)
-DVIS = heimdal.dvi hx509.dvi
-PDFS = heimdal.pdf hx509.pdf
-PSS = heimdal.ps hx509.ps
-HTMLS = heimdal.html hx509.html
-TEXINFOS = heimdal.texi hx509.texi
-TEXI2PDF = $(TEXI2DVI) --pdf --batch
-MAKEINFOHTML = $(MAKEINFO) --html
-AM_MAKEINFOHTMLFLAGS = $(AM_MAKEINFOFLAGS)
-DVIPS = dvips
-am__installdirs = "$(DESTDIR)$(infodir)"
-am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
-am__vpath_adj = case $$p in \
-    $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
-    *) f=$$p;; \
-  esac;
-am__strip_dir = `echo $$p | sed -e 's|^.*/||'`;
-DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
-ACLOCAL = @ACLOCAL@
-AIX_EXTRA_KAFS = @AIX_EXTRA_KAFS@
-AMTAR = @AMTAR@
-AR = @AR@
-AUTOCONF = @AUTOCONF@
-AUTOHEADER = @AUTOHEADER@
-AUTOMAKE = @AUTOMAKE@
-AWK = @AWK@
-CANONICAL_HOST = @CANONICAL_HOST@
-CATMAN = @CATMAN@
-CATMANEXT = @CATMANEXT@
-CC = @CC@
-CFLAGS = @CFLAGS@
-COMPILE_ET = @COMPILE_ET@
-CPP = @CPP@
-CPPFLAGS = @CPPFLAGS@
-CXX = @CXX@
-CXXCPP = @CXXCPP@
-CXXFLAGS = @CXXFLAGS@
-CYGPATH_W = @CYGPATH_W@
-DBLIB = @DBLIB@
-DEFS = @DEFS@
-DIR_com_err = @DIR_com_err@
-DIR_hcrypto = @DIR_hcrypto@
-DIR_hdbdir = @DIR_hdbdir@
-DIR_roken = @DIR_roken@
-ECHO = @ECHO@
-ECHO_C = @ECHO_C@
-ECHO_N = @ECHO_N@
-ECHO_T = @ECHO_T@
-EGREP = @EGREP@
-EXEEXT = @EXEEXT@
-F77 = @F77@
-FFLAGS = @FFLAGS@
-GREP = @GREP@
-GROFF = @GROFF@
-INCLUDES_roken = @INCLUDES_roken@
-INCLUDE_hcrypto = @INCLUDE_hcrypto@
-INCLUDE_hesiod = @INCLUDE_hesiod@
-INCLUDE_krb4 = @INCLUDE_krb4@
-INCLUDE_openldap = @INCLUDE_openldap@
-INCLUDE_readline = @INCLUDE_readline@
-INSTALL = @INSTALL@
-INSTALL_DATA = @INSTALL_DATA@
-INSTALL_PROGRAM = @INSTALL_PROGRAM@
-INSTALL_SCRIPT = @INSTALL_SCRIPT@
-INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
-LDFLAGS = @LDFLAGS@
-LDFLAGS_VERSION_SCRIPT = @LDFLAGS_VERSION_SCRIPT@
-LEX = @LEX@
-LEXLIB = @LEXLIB@
-LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
-LIBADD_roken = @LIBADD_roken@
-LIBOBJS = @LIBOBJS@
-LIBS = @LIBS@
-LIBTOOL = @LIBTOOL@
-LIB_AUTH_SUBDIRS = @LIB_AUTH_SUBDIRS@
-LIB_NDBM = @LIB_NDBM@
-LIB_XauFileName = @LIB_XauFileName@
-LIB_XauReadAuth = @LIB_XauReadAuth@
-LIB_XauWriteAuth = @LIB_XauWriteAuth@
-LIB_bswap16 = @LIB_bswap16@
-LIB_bswap32 = @LIB_bswap32@
-LIB_com_err = @LIB_com_err@
-LIB_com_err_a = @LIB_com_err_a@
-LIB_com_err_so = @LIB_com_err_so@
-LIB_crypt = @LIB_crypt@
-LIB_db_create = @LIB_db_create@
-LIB_dbm_firstkey = @LIB_dbm_firstkey@
-LIB_dbopen = @LIB_dbopen@
-LIB_dlopen = @LIB_dlopen@
-LIB_dn_expand = @LIB_dn_expand@
-LIB_door_create = @LIB_door_create@
-LIB_el_init = @LIB_el_init@
-LIB_freeaddrinfo = @LIB_freeaddrinfo@
-LIB_gai_strerror = @LIB_gai_strerror@
-LIB_getaddrinfo = @LIB_getaddrinfo@
-LIB_gethostbyname = @LIB_gethostbyname@
-LIB_gethostbyname2 = @LIB_gethostbyname2@
-LIB_getnameinfo = @LIB_getnameinfo@
-LIB_getpwnam_r = @LIB_getpwnam_r@
-LIB_getsockopt = @LIB_getsockopt@
-LIB_hcrypto = @LIB_hcrypto@
-LIB_hcrypto_a = @LIB_hcrypto_a@
-LIB_hcrypto_appl = @LIB_hcrypto_appl@
-LIB_hcrypto_so = @LIB_hcrypto_so@
-LIB_hesiod = @LIB_hesiod@
-LIB_hstrerror = @LIB_hstrerror@
-LIB_kdb = @LIB_kdb@
-LIB_krb4 = @LIB_krb4@
-LIB_loadquery = @LIB_loadquery@
-LIB_logout = @LIB_logout@
-LIB_logwtmp = @LIB_logwtmp@
-LIB_openldap = @LIB_openldap@
-LIB_openpty = @LIB_openpty@
-LIB_otp = @LIB_otp@
-LIB_pidfile = @LIB_pidfile@
-LIB_readline = @LIB_readline@
-LIB_res_ndestroy = @LIB_res_ndestroy@
-LIB_res_nsearch = @LIB_res_nsearch@
-LIB_res_search = @LIB_res_search@
-LIB_roken = @LIB_roken@
-LIB_security = @LIB_security@
-LIB_setsockopt = @LIB_setsockopt@
-LIB_socket = @LIB_socket@
-LIB_syslog = @LIB_syslog@
-LIB_tgetent = @LIB_tgetent@
-LN_S = @LN_S@
-LTLIBOBJS = @LTLIBOBJS@
-MAINT = @MAINT@
-MAKEINFO = @MAKEINFO@
-MKDIR_P = @MKDIR_P@
-NROFF = @NROFF@
-OBJEXT = @OBJEXT@
-PACKAGE = @PACKAGE@
-PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
-PACKAGE_NAME = @PACKAGE_NAME@
-PACKAGE_STRING = @PACKAGE_STRING@
-PACKAGE_TARNAME = @PACKAGE_TARNAME@
-PACKAGE_VERSION = @PACKAGE_VERSION@
-PATH_SEPARATOR = @PATH_SEPARATOR@
-PTHREADS_CFLAGS = @PTHREADS_CFLAGS@
-PTHREADS_LIBS = @PTHREADS_LIBS@
-RANLIB = @RANLIB@
-SET_MAKE = @SET_MAKE@
-SHELL = @SHELL@
-STRIP = @STRIP@
-VERSION = @VERSION@
-VERSIONING = @VERSIONING@
-VOID_RETSIGTYPE = @VOID_RETSIGTYPE@
-WFLAGS = @WFLAGS@
-WFLAGS_NOIMPLICITINT = @WFLAGS_NOIMPLICITINT@
-WFLAGS_NOUNUSED = @WFLAGS_NOUNUSED@
-XMKMF = @XMKMF@
-X_CFLAGS = @X_CFLAGS@
-X_EXTRA_LIBS = @X_EXTRA_LIBS@
-X_LIBS = @X_LIBS@
-X_PRE_LIBS = @X_PRE_LIBS@
-YACC = @YACC@
-YFLAGS = @YFLAGS@
-abs_builddir = @abs_builddir@
-abs_srcdir = @abs_srcdir@
-abs_top_builddir = @abs_top_builddir@
-abs_top_srcdir = @abs_top_srcdir@
-ac_ct_CC = @ac_ct_CC@
-ac_ct_CXX = @ac_ct_CXX@
-ac_ct_F77 = @ac_ct_F77@
-am__leading_dot = @am__leading_dot@
-am__tar = @am__tar@
-am__untar = @am__untar@
-bindir = @bindir@
-build = @build@
-build_alias = @build_alias@
-build_cpu = @build_cpu@
-build_os = @build_os@
-build_vendor = @build_vendor@
-builddir = @builddir@
-datadir = @datadir@
-datarootdir = @datarootdir@
-docdir = @docdir@
-dpagaix_cflags = @dpagaix_cflags@
-dpagaix_ldadd = @dpagaix_ldadd@
-dpagaix_ldflags = @dpagaix_ldflags@
-dvidir = @dvidir@
-exec_prefix = @exec_prefix@
-host = @host@
-host_alias = @host_alias@
-host_cpu = @host_cpu@
-host_os = @host_os@
-host_vendor = @host_vendor@
-htmldir = @htmldir@
-includedir = @includedir@
-infodir = @infodir@
-install_sh = @install_sh@
-libdir = @libdir@
-libexecdir = @libexecdir@
-localedir = @localedir@
-localstatedir = @localstatedir@
-mandir = @mandir@
-mkdir_p = @mkdir_p@
-oldincludedir = @oldincludedir@
-pdfdir = @pdfdir@
-prefix = @prefix@
-program_transform_name = @program_transform_name@
-psdir = @psdir@
-sbindir = @sbindir@
-sharedstatedir = @sharedstatedir@
-srcdir = @srcdir@
-sysconfdir = @sysconfdir@
-target_alias = @target_alias@
-top_builddir = @top_builddir@
-top_srcdir = @top_srcdir@
-SUFFIXES = .et .h .x .z .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8
-AM_CPPFLAGS = -I$(top_builddir)/include $(INCLUDES_roken)
-@do_roken_rename_TRUE@ROKEN_RENAME = -DROKEN_RENAME
-AM_CFLAGS = $(WFLAGS)
-CP = cp
-buildinclude = $(top_builddir)/include
-LIB_getattr = @LIB_getattr@
-LIB_getpwent_r = @LIB_getpwent_r@
-LIB_odm_initialize = @LIB_odm_initialize@
-LIB_setpcred = @LIB_setpcred@
-HESIODLIB = @HESIODLIB@
-HESIODINCLUDE = @HESIODINCLUDE@
-NROFF_MAN = groff -mandoc -Tascii
-LIB_kafs = $(top_builddir)/lib/kafs/libkafs.la $(AIX_EXTRA_KAFS)
-@KRB5_TRUE@LIB_krb5 = $(top_builddir)/lib/krb5/libkrb5.la \
-@KRB5_TRUE@	$(top_builddir)/lib/asn1/libasn1.la
-
-@KRB5_TRUE@LIB_gssapi = $(top_builddir)/lib/gssapi/libgssapi.la
-@KRB5_TRUE@LIB_tsasl = $(top_builddir)/lib/tsasl/libtsasl.la
-@DCE_TRUE@LIB_kdfs = $(top_builddir)/lib/kdfs/libkdfs.la
-AUTOMAKE_OPTIONS = no-texinfo.tex
-MAKEINFOFLAGS = --no-split --css-include=$(srcdir)/heimdal.css
-TEXI2DVI = true # ARGH, make distcheck can't be disabled to not build dvifiles
-info_TEXINFOS = heimdal.texi hx509.texi
-dxy_subst = sed -e 's,[@]srcdir[@],$(srcdir),g' \
-	-e 's,[@]objdir[@],.,g' \
-	-e 's,[@]PACKAGE_VERSION[@],$(PACKAGE_VERSION),g'
-
-texi_subst = sed -e 's,[@]dbdir[@],$(localstatedir),g' \
-	-e 's,[@]PACKAGE_VERSION[@],$(PACKAGE_VERSION),g'
-
-heimdal_TEXINFOS = \
-	ack.texi \
-	apps.texi \
-	heimdal.texi \
-	install.texi \
-	intro.texi \
-	kerberos4.texi \
-	migration.texi \
-	misc.texi \
-	programming.texi \
-	setup.texi \
-	vars.texi \
-	whatis.texi \
-	win2k.texi
-
-EXTRA_DIST = \
-	krb5.din \
-	ntlm.din \
-	hx509.din \
-	hcrypto.din \
-	heimdal.css \
-	init-creds \
-	latin1.tex \
-	layman.asc \
-	doxytmpl.dxy \
-	vars.tin
-
-CLEANFILES = \
-	krb5.dxy* \
-	ntlm.dxy* \
-	hx509.dxy* \
-	hcrypto.dxy* \
-	vars.texi*
-
-all: all-am
-
-.SUFFIXES:
-.SUFFIXES: .et .h .x .z .1 .3 .5 .8 .cat1 .cat3 .cat5 .cat8 .c .dvi .html .info .pdf .ps .texi
-$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ $(srcdir)/Makefile.am $(top_srcdir)/Makefile.am.common $(top_srcdir)/cf/Makefile.am.common $(am__configure_deps)
-	@for dep in $?; do \
-	  case '$(am__configure_deps)' in \
-	    *$$dep*) \
-	      cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh \
-		&& exit 0; \
-	      exit 1;; \
-	  esac; \
-	done; \
-	echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign  --ignore-deps doc/Makefile'; \
-	cd $(top_srcdir) && \
-	  $(AUTOMAKE) --foreign  --ignore-deps doc/Makefile
-.PRECIOUS: Makefile
-Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
-	@case '$?' in \
-	  *config.status*) \
-	    cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
-	  *) \
-	    echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
-	    cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
-	esac;
-
-$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
-	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
-
-$(top_srcdir)/configure: @MAINTAINER_MODE_TRUE@ $(am__configure_deps)
-	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
-$(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
-	cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
-
-mostlyclean-libtool:
-	-rm -f *.lo
-
-clean-libtool:
-	-rm -rf .libs _libs
-
-.texi.info:
-	restore=: && backupdir="$(am__leading_dot)am$$$$" && \
-	am__cwd=`pwd` && cd $(srcdir) && \
-	rm -rf $$backupdir && mkdir $$backupdir && \
-	if ($(MAKEINFO) --version) >/dev/null 2>&1; then \
-	  for f in $@ $@-[0-9] $@-[0-9][0-9] $(@:.info=).i[0-9] $(@:.info=).i[0-9][0-9]; do \
-	    if test -f $$f; then mv $$f $$backupdir; restore=mv; else :; fi; \
-	  done; \
-	else :; fi && \
-	cd "$$am__cwd"; \
-	if $(MAKEINFO) $(AM_MAKEINFOFLAGS) $(MAKEINFOFLAGS) -I $(srcdir) \
-	 -o $@ $<; \
-	then \
-	  rc=0; \
-	  cd $(srcdir); \
-	else \
-	  rc=$$?; \
-	  cd $(srcdir) && \
-	  $$restore $$backupdir/* `echo "./$@" | sed 's|[^/]*$$||'`; \
-	fi; \
-	rm -rf $$backupdir; exit $$rc
-
-.texi.dvi:
-	TEXINPUTS="$(am__TEXINFO_TEX_DIR)$(PATH_SEPARATOR)$$TEXINPUTS" \
-	MAKEINFO='$(MAKEINFO) $(AM_MAKEINFOFLAGS) $(MAKEINFOFLAGS) -I $(srcdir)' \
-	$(TEXI2DVI) $<
-
-.texi.pdf:
-	TEXINPUTS="$(am__TEXINFO_TEX_DIR)$(PATH_SEPARATOR)$$TEXINPUTS" \
-	MAKEINFO='$(MAKEINFO) $(AM_MAKEINFOFLAGS) $(MAKEINFOFLAGS) -I $(srcdir)' \
-	$(TEXI2PDF) $<
-
-.texi.html:
-	rm -rf $(@:.html=.htp)
-	if $(MAKEINFOHTML) $(AM_MAKEINFOHTMLFLAGS) $(MAKEINFOFLAGS) -I $(srcdir) \
-	 -o $(@:.html=.htp) $<; \
-	then \
-	  rm -rf $@; \
-	  if test ! -d $(@:.html=.htp) && test -d $(@:.html=); then \
-	    mv $(@:.html=) $@; else mv $(@:.html=.htp) $@; fi; \
-	else \
-	  if test ! -d $(@:.html=.htp) && test -d $(@:.html=); then \
-	    rm -rf $(@:.html=); else rm -Rf $(@:.html=.htp) $@; fi; \
-	  exit 1; \
-	fi
-$(srcdir)/heimdal.info: heimdal.texi $(heimdal_TEXINFOS)
-heimdal.dvi: heimdal.texi $(heimdal_TEXINFOS)
-heimdal.pdf: heimdal.texi $(heimdal_TEXINFOS)
-heimdal.html: heimdal.texi $(heimdal_TEXINFOS)
-$(srcdir)/hx509.info: hx509.texi 
-hx509.dvi: hx509.texi 
-hx509.pdf: hx509.texi 
-hx509.html: hx509.texi 
-.dvi.ps:
-	TEXINPUTS="$(am__TEXINFO_TEX_DIR)$(PATH_SEPARATOR)$$TEXINPUTS" \
-	$(DVIPS) -o $@ $<
-
-uninstall-dvi-am:
-	@$(NORMAL_UNINSTALL)
-	@list='$(DVIS)'; for p in $$list; do \
-	  f=$(am__strip_dir) \
-	  echo " rm -f '$(DESTDIR)$(dvidir)/$$f'"; \
-	  rm -f "$(DESTDIR)$(dvidir)/$$f"; \
-	done
-
-uninstall-html-am:
-	@$(NORMAL_UNINSTALL)
-	@list='$(HTMLS)'; for p in $$list; do \
-	  f=$(am__strip_dir) \
-	  echo " rm -rf '$(DESTDIR)$(htmldir)/$$f'"; \
-	  rm -rf "$(DESTDIR)$(htmldir)/$$f"; \
-	done
-
-uninstall-info-am:
-	@$(PRE_UNINSTALL)
-	@if test -d '$(DESTDIR)$(infodir)' && \
-	    (install-info --version && \
-	     install-info --version 2>&1 | sed 1q | grep -i -v debian) >/dev/null 2>&1; then \
-	  list='$(INFO_DEPS)'; \
-	  for file in $$list; do \
-	    relfile=`echo "$$file" | sed 's|^.*/||'`; \
-	    echo " install-info --info-dir='$(DESTDIR)$(infodir)' --remove '$(DESTDIR)$(infodir)/$$relfile'"; \
-	    install-info --info-dir="$(DESTDIR)$(infodir)" --remove "$(DESTDIR)$(infodir)/$$relfile"; \
-	  done; \
-	else :; fi
-	@$(NORMAL_UNINSTALL)
-	@list='$(INFO_DEPS)'; \
-	for file in $$list; do \
-	  relfile=`echo "$$file" | sed 's|^.*/||'`; \
-	  relfile_i=`echo "$$relfile" | sed 's|\.info$$||;s|$$|.i|'`; \
-	  (if test -d "$(DESTDIR)$(infodir)" && cd "$(DESTDIR)$(infodir)"; then \
-	     echo " cd '$(DESTDIR)$(infodir)' && rm -f $$relfile $$relfile-[0-9] $$relfile-[0-9][0-9] $$relfile_i[0-9] $$relfile_i[0-9][0-9]"; \
-	     rm -f $$relfile $$relfile-[0-9] $$relfile-[0-9][0-9] $$relfile_i[0-9] $$relfile_i[0-9][0-9]; \
-	   else :; fi); \
-	done
-
-uninstall-pdf-am:
-	@$(NORMAL_UNINSTALL)
-	@list='$(PDFS)'; for p in $$list; do \
-	  f=$(am__strip_dir) \
-	  echo " rm -f '$(DESTDIR)$(pdfdir)/$$f'"; \
-	  rm -f "$(DESTDIR)$(pdfdir)/$$f"; \
-	done
-
-uninstall-ps-am:
-	@$(NORMAL_UNINSTALL)
-	@list='$(PSS)'; for p in $$list; do \
-	  f=$(am__strip_dir) \
-	  echo " rm -f '$(DESTDIR)$(psdir)/$$f'"; \
-	  rm -f "$(DESTDIR)$(psdir)/$$f"; \
-	done
-
-dist-info: $(INFO_DEPS)
-	@srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`; \
-	list='$(INFO_DEPS)'; \
-	for base in $$list; do \
-	  case $$base in \
-	    $(srcdir)/*) base=`echo "$$base" | sed "s|^$$srcdirstrip/||"`;; \
-	  esac; \
-	  if test -f $$base; then d=.; else d=$(srcdir); fi; \
-	  base_i=`echo "$$base" | sed 's|\.info$$||;s|$$|.i|'`; \
-	  for file in $$d/$$base $$d/$$base-[0-9] $$d/$$base-[0-9][0-9] $$d/$$base_i[0-9] $$d/$$base_i[0-9][0-9]; do \
-	    if test -f $$file; then \
-	      relfile=`expr "$$file" : "$$d/\(.*\)"`; \
-	      test -f $(distdir)/$$relfile || \
-		cp -p $$file $(distdir)/$$relfile; \
-	    else :; fi; \
-	  done; \
-	done
-
-mostlyclean-aminfo:
-	-rm -rf heimdal.aux heimdal.cp heimdal.cps heimdal.fn heimdal.fns heimdal.ky \
-	  heimdal.kys heimdal.log heimdal.pg heimdal.tmp heimdal.toc \
-	  heimdal.tp heimdal.tps heimdal.vr heimdal.vrs heimdal.dvi \
-	  heimdal.pdf heimdal.ps heimdal.html hx509.aux hx509.cp \
-	  hx509.cps hx509.fn hx509.fns hx509.ky hx509.kys hx509.log \
-	  hx509.pg hx509.tmp hx509.toc hx509.tp hx509.tps hx509.vr \
-	  hx509.vrs hx509.dvi hx509.pdf hx509.ps hx509.html
-
-maintainer-clean-aminfo:
-	@list='$(INFO_DEPS)'; for i in $$list; do \
-	  i_i=`echo "$$i" | sed 's|\.info$$||;s|$$|.i|'`; \
-	  echo " rm -f $$i $$i-[0-9] $$i-[0-9][0-9] $$i_i[0-9] $$i_i[0-9][0-9]"; \
-	  rm -f $$i $$i-[0-9] $$i-[0-9][0-9] $$i_i[0-9] $$i_i[0-9][0-9]; \
-	done
-tags: TAGS
-TAGS:
-
-ctags: CTAGS
-CTAGS:
-
-
-distdir: $(DISTFILES)
-	@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
-	topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
-	list='$(DISTFILES)'; \
-	  dist_files=`for file in $$list; do echo $$file; done | \
-	  sed -e "s|^$$srcdirstrip/||;t" \
-	      -e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
-	case $$dist_files in \
-	  */*) $(MKDIR_P) `echo "$$dist_files" | \
-			   sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
-			   sort -u` ;; \
-	esac; \
-	for file in $$dist_files; do \
-	  if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
-	  if test -d $$d/$$file; then \
-	    dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
-	    if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
-	      cp -pR $(srcdir)/$$file $(distdir)$$dir || exit 1; \
-	    fi; \
-	    cp -pR $$d/$$file $(distdir)$$dir || exit 1; \
-	  else \
-	    test -f $(distdir)/$$file \
-	    || cp -p $$d/$$file $(distdir)/$$file \
-	    || exit 1; \
-	  fi; \
-	done
-	$(MAKE) $(AM_MAKEFLAGS) \
-	  top_distdir="$(top_distdir)" distdir="$(distdir)" \
-	  dist-info dist-hook
-check-am: all-am
-	$(MAKE) $(AM_MAKEFLAGS) check-local
-check: check-am
-all-am: Makefile $(INFO_DEPS) all-local
-installdirs:
-	for dir in "$(DESTDIR)$(infodir)"; do \
-	  test -z "$$dir" || $(MKDIR_P) "$$dir"; \
-	done
-install: install-am
-install-exec: install-exec-am
-install-data: install-data-am
-uninstall: uninstall-am
-
-install-am: all-am
-	@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
-
-installcheck: installcheck-am
-install-strip:
-	$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
-	  install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
-	  `test -z '$(STRIP)' || \
-	    echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
-mostlyclean-generic:
-
-clean-generic:
-	-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
-
-distclean-generic:
-	-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
-
-maintainer-clean-generic:
-	@echo "This command is intended for maintainers to use"
-	@echo "it deletes files that may require special tools to rebuild."
-clean: clean-am
-
-clean-am: clean-generic clean-libtool mostlyclean-am
-
-distclean: distclean-am
-	-rm -f Makefile
-distclean-am: clean-am distclean-generic
-
-dvi: dvi-am
-
-dvi-am: $(DVIS)
-
-html: html-am
-
-html-am: $(HTMLS)
-
-info: info-am
-
-info-am: $(INFO_DEPS)
-
-install-data-am: install-info-am
-	@$(NORMAL_INSTALL)
-	$(MAKE) $(AM_MAKEFLAGS) install-data-hook
-
-install-dvi: install-dvi-am
-
-install-dvi-am: $(DVIS)
-	@$(NORMAL_INSTALL)
-	test -z "$(dvidir)" || $(MKDIR_P) "$(DESTDIR)$(dvidir)"
-	@list='$(DVIS)'; for p in $$list; do \
-	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
-	  f=$(am__strip_dir) \
-	  echo " $(INSTALL_DATA) '$$d$$p' '$(DESTDIR)$(dvidir)/$$f'"; \
-	  $(INSTALL_DATA) "$$d$$p" "$(DESTDIR)$(dvidir)/$$f"; \
-	done
-install-exec-am:
-	@$(NORMAL_INSTALL)
-	$(MAKE) $(AM_MAKEFLAGS) install-exec-hook
-
-install-html: install-html-am
-
-install-html-am: $(HTMLS)
-	@$(NORMAL_INSTALL)
-	test -z "$(htmldir)" || $(MKDIR_P) "$(DESTDIR)$(htmldir)"
-	@list='$(HTMLS)'; for p in $$list; do \
-	  if test -f "$$p" || test -d "$$p"; then d=; else d="$(srcdir)/"; fi; \
-	  f=$(am__strip_dir) \
-	  if test -d "$$d$$p"; then \
-	    echo " $(MKDIR_P) '$(DESTDIR)$(htmldir)/$$f'"; \
-	    $(MKDIR_P) "$(DESTDIR)$(htmldir)/$$f" || exit 1; \
-	    echo " $(INSTALL_DATA) '$$d$$p'/* '$(DESTDIR)$(htmldir)/$$f'"; \
-	    $(INSTALL_DATA) "$$d$$p"/* "$(DESTDIR)$(htmldir)/$$f"; \
-	  else \
-	    echo " $(INSTALL_DATA) '$$d$$p' '$(DESTDIR)$(htmldir)/$$f'"; \
-	    $(INSTALL_DATA) "$$d$$p" "$(DESTDIR)$(htmldir)/$$f"; \
-	  fi; \
-	done
-install-info: install-info-am
-
-install-info-am: $(INFO_DEPS)
-	@$(NORMAL_INSTALL)
-	test -z "$(infodir)" || $(MKDIR_P) "$(DESTDIR)$(infodir)"
-	@srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`; \
-	list='$(INFO_DEPS)'; \
-	for file in $$list; do \
-	  case $$file in \
-	    $(srcdir)/*) file=`echo "$$file" | sed "s|^$$srcdirstrip/||"`;; \
-	  esac; \
-	  if test -f $$file; then d=.; else d=$(srcdir); fi; \
-	  file_i=`echo "$$file" | sed 's|\.info$$||;s|$$|.i|'`; \
-	  for ifile in $$d/$$file $$d/$$file-[0-9] $$d/$$file-[0-9][0-9] \
-                       $$d/$$file_i[0-9] $$d/$$file_i[0-9][0-9] ; do \
-	    if test -f $$ifile; then \
-	      relfile=`echo "$$ifile" | sed 's|^.*/||'`; \
-	      echo " $(INSTALL_DATA) '$$ifile' '$(DESTDIR)$(infodir)/$$relfile'"; \
-	      $(INSTALL_DATA) "$$ifile" "$(DESTDIR)$(infodir)/$$relfile"; \
-	    else : ; fi; \
-	  done; \
-	done
-	@$(POST_INSTALL)
-	@if (install-info --version && \
-	     install-info --version 2>&1 | sed 1q | grep -i -v debian) >/dev/null 2>&1; then \
-	  list='$(INFO_DEPS)'; \
-	  for file in $$list; do \
-	    relfile=`echo "$$file" | sed 's|^.*/||'`; \
-	    echo " install-info --info-dir='$(DESTDIR)$(infodir)' '$(DESTDIR)$(infodir)/$$relfile'";\
-	    install-info --info-dir="$(DESTDIR)$(infodir)" "$(DESTDIR)$(infodir)/$$relfile" || :;\
-	  done; \
-	else : ; fi
-install-man:
-
-install-pdf: install-pdf-am
-
-install-pdf-am: $(PDFS)
-	@$(NORMAL_INSTALL)
-	test -z "$(pdfdir)" || $(MKDIR_P) "$(DESTDIR)$(pdfdir)"
-	@list='$(PDFS)'; for p in $$list; do \
-	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
-	  f=$(am__strip_dir) \
-	  echo " $(INSTALL_DATA) '$$d$$p' '$(DESTDIR)$(pdfdir)/$$f'"; \
-	  $(INSTALL_DATA) "$$d$$p" "$(DESTDIR)$(pdfdir)/$$f"; \
-	done
-install-ps: install-ps-am
-
-install-ps-am: $(PSS)
-	@$(NORMAL_INSTALL)
-	test -z "$(psdir)" || $(MKDIR_P) "$(DESTDIR)$(psdir)"
-	@list='$(PSS)'; for p in $$list; do \
-	  if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
-	  f=$(am__strip_dir) \
-	  echo " $(INSTALL_DATA) '$$d$$p' '$(DESTDIR)$(psdir)/$$f'"; \
-	  $(INSTALL_DATA) "$$d$$p" "$(DESTDIR)$(psdir)/$$f"; \
-	done
-installcheck-am:
-
-maintainer-clean: maintainer-clean-am
-	-rm -f Makefile
-maintainer-clean-am: distclean-am maintainer-clean-aminfo \
-	maintainer-clean-generic
-
-mostlyclean: mostlyclean-am
-
-mostlyclean-am: mostlyclean-aminfo mostlyclean-generic \
-	mostlyclean-libtool
-
-pdf: pdf-am
-
-pdf-am: $(PDFS)
-
-ps: ps-am
-
-ps-am: $(PSS)
-
-uninstall-am: uninstall-dvi-am uninstall-html-am uninstall-info-am \
-	uninstall-pdf-am uninstall-ps-am
-	@$(NORMAL_INSTALL)
-	$(MAKE) $(AM_MAKEFLAGS) uninstall-hook
-
-.MAKE: install-am install-data-am install-exec-am install-strip \
-	uninstall-am
-
-.PHONY: all all-am all-local check check-am check-local clean \
-	clean-generic clean-libtool dist-hook dist-info distclean \
-	distclean-generic distclean-libtool distdir dvi dvi-am html \
-	html-am info info-am install install-am install-data \
-	install-data-am install-data-hook install-dvi install-dvi-am \
-	install-exec install-exec-am install-exec-hook install-html \
-	install-html-am install-info install-info-am install-man \
-	install-pdf install-pdf-am install-ps install-ps-am \
-	install-strip installcheck installcheck-am installdirs \
-	maintainer-clean maintainer-clean-aminfo \
-	maintainer-clean-generic mostlyclean mostlyclean-aminfo \
-	mostlyclean-generic mostlyclean-libtool pdf pdf-am ps ps-am \
-	uninstall uninstall-am uninstall-dvi-am uninstall-hook \
-	uninstall-html-am uninstall-info-am uninstall-pdf-am \
-	uninstall-ps-am
-
-
-install-suid-programs:
-	@foo='$(bin_SUIDS)'; \
-	for file in $$foo; do \
-	x=$(DESTDIR)$(bindir)/$$file; \
-	if chown 0:0 $$x && chmod u+s $$x; then :; else \
-	echo "*"; \
-	echo "* Failed to install $$x setuid root"; \
-	echo "*"; \
-	fi; done
-
-install-exec-hook: install-suid-programs
-
-install-build-headers:: $(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ) $(nobase_include_HEADERS)
-	@foo='$(include_HEADERS) $(dist_include_HEADERS) $(nodist_include_HEADERS) $(build_HEADERZ)'; \
-	for f in $$foo; do \
-		f=`basename $$f`; \
-		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
-		else file="$$f"; fi; \
-		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
-		: ; else \
-			echo " $(CP) $$file $(buildinclude)/$$f"; \
-			$(CP) $$file $(buildinclude)/$$f; \
-		fi ; \
-	done ; \
-	foo='$(nobase_include_HEADERS)'; \
-	for f in $$foo; do \
-		if test -f "$(srcdir)/$$f"; then file="$(srcdir)/$$f"; \
-		else file="$$f"; fi; \
-		$(mkdir_p) $(buildinclude)/`dirname $$f` ; \
-		if cmp -s  $$file $(buildinclude)/$$f 2> /dev/null ; then \
-		: ; else \
-			echo " $(CP) $$file $(buildinclude)/$$f"; \
-			$(CP) $$file $(buildinclude)/$$f; \
-		fi ; \
-	done
-
-all-local: install-build-headers
-
-check-local::
-	@if test '$(CHECK_LOCAL)' = "no-check-local"; then \
-	  foo=''; elif test '$(CHECK_LOCAL)'; then \
-	  foo='$(CHECK_LOCAL)'; else \
-	  foo='$(PROGRAMS)'; fi; \
-	  if test "$$foo"; then \
-	  failed=0; all=0; \
-	  for i in $$foo; do \
-	    all=`expr $$all + 1`; \
-	    if (./$$i --version && ./$$i --help) > /dev/null 2>&1; then \
-	      echo "PASS: $$i"; \
-	    else \
-	      echo "FAIL: $$i"; \
-	      failed=`expr $$failed + 1`; \
-	    fi; \
-	  done; \
-	  if test "$$failed" -eq 0; then \
-	    banner="All $$all tests passed"; \
-	  else \
-	    banner="$$failed of $$all tests failed"; \
-	  fi; \
-	  dashes=`echo "$$banner" | sed s/./=/g`; \
-	  echo "$$dashes"; \
-	  echo "$$banner"; \
-	  echo "$$dashes"; \
-	  test "$$failed" -eq 0 || exit 1; \
-	fi
-
-.x.c:
-	@cmp -s $< $@ 2> /dev/null || cp $< $@
-#NROFF_MAN = nroff -man
-.1.cat1:
-	$(NROFF_MAN) $< > $@
-.3.cat3:
-	$(NROFF_MAN) $< > $@
-.5.cat5:
-	$(NROFF_MAN) $< > $@
-.8.cat8:
-	$(NROFF_MAN) $< > $@
-
-dist-cat1-mans:
-	@foo='$(man1_MANS)'; \
-	bar='$(man_MANS)'; \
-	for i in $$bar; do \
-	case $$i in \
-	*.1) foo="$$foo $$i";; \
-	esac; done ;\
-	for i in $$foo; do \
-		x=`echo $$i | sed 's/\.[^.]*$$/.cat1/'`; \
-		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
-		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
-	done
-
-dist-cat3-mans:
-	@foo='$(man3_MANS)'; \
-	bar='$(man_MANS)'; \
-	for i in $$bar; do \
-	case $$i in \
-	*.3) foo="$$foo $$i";; \
-	esac; done ;\
-	for i in $$foo; do \
-		x=`echo $$i | sed 's/\.[^.]*$$/.cat3/'`; \
-		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
-		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
-	done
-
-dist-cat5-mans:
-	@foo='$(man5_MANS)'; \
-	bar='$(man_MANS)'; \
-	for i in $$bar; do \
-	case $$i in \
-	*.5) foo="$$foo $$i";; \
-	esac; done ;\
-	for i in $$foo; do \
-		x=`echo $$i | sed 's/\.[^.]*$$/.cat5/'`; \
-		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
-		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
-	done
-
-dist-cat8-mans:
-	@foo='$(man8_MANS)'; \
-	bar='$(man_MANS)'; \
-	for i in $$bar; do \
-	case $$i in \
-	*.8) foo="$$foo $$i";; \
-	esac; done ;\
-	for i in $$foo; do \
-		x=`echo $$i | sed 's/\.[^.]*$$/.cat8/'`; \
-		echo "$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x"; \
-		$(NROFF_MAN) $(srcdir)/$$i > $(distdir)/$$x; \
-	done
-
-dist-hook: dist-cat1-mans dist-cat3-mans dist-cat5-mans dist-cat8-mans
-
-install-cat-mans:
-	$(SHELL) $(top_srcdir)/cf/install-catman.sh install "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
-
-uninstall-cat-mans:
-	$(SHELL) $(top_srcdir)/cf/install-catman.sh uninstall "$(INSTALL_DATA)" "$(mkinstalldirs)" "$(srcdir)" "$(DESTDIR)$(mandir)" '$(CATMANEXT)' $(man_MANS) $(man1_MANS) $(man3_MANS) $(man5_MANS) $(man8_MANS)
-
-install-data-hook: install-cat-mans
-uninstall-hook: uninstall-cat-mans
-
-.et.h:
-	$(COMPILE_ET) $<
-.et.c:
-	$(COMPILE_ET) $<
-
-#
-# Useful target for debugging
-#
-
-check-valgrind:
-	tobjdir=`cd $(top_builddir) && pwd` ; \
-	tsrcdir=`cd $(top_srcdir) && pwd` ; \
-	env TESTS_ENVIRONMENT="$${tobjdir}/libtool --mode execute valgrind --leak-check=full --trace-children=yes --quiet -q --num-callers=30 --suppressions=$${tsrcdir}/cf/valgrind-suppressions" make check
-
-#
-# Target to please samba build farm, builds distfiles in-tree.
-# Will break when automake changes...
-#
-
-distdir-in-tree: $(DISTFILES) $(INFO_DEPS)
-	list='$(DIST_SUBDIRS)'; for subdir in $$list; do \
-	  if test "$$subdir" != .; then \
-	  (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) distdir-in-tree) ; \
-	  fi ; \
-	done
-
-krb5.dxy: krb5.din Makefile
-	$(dxy_subst) < $(srcdir)/krb5.din > krb5.dxy.tmp
-	chmod +x krb5.dxy.tmp
-	mv krb5.dxy.tmp krb5.dxy
-
-ntlm.dxy: ntlm.din Makefile
-	$(dxy_subst) < $(srcdir)/ntlm.din > ntlm.dxy.tmp
-	chmod +x ntlm.dxy.tmp
-	mv ntlm.dxy.tmp ntlm.dxy
-
-hx509.dxy: hx509.din Makefile
-	$(dxy_subst) < $(srcdir)/hx509.din > hx509.dxy.tmp
-	chmod +x hx509.dxy.tmp
-	mv hx509.dxy.tmp hx509.dxy
-
-hcrypto.dxy: hcrypto.din Makefile
-	$(dxy_subst) < $(srcdir)/hcrypto.din > hcrypto.dxy.tmp
-	chmod +x hcrypto.dxy.tmp
-	mv hcrypto.dxy.tmp hcrypto.dxy
-
-vars.texi: vars.tin Makefile
-	$(texi_subst) < $(srcdir)/vars.tin > vars.texi.tmp
-	chmod +x vars.texi.tmp
-	mv vars.texi.tmp vars.texi
-
-doxygen: krb5.dxy ntlm.dxy hx509.dxy hcrypto.dxy
-	doxygen krb5.dxy
-	doxygen ntlm.dxy
-	doxygen hx509.dxy
-	doxygen hcrypto.dxy
-# Tell versions [3.59,3.63) of GNU make to not export all variables.
-# Otherwise a system limit (for SysV at least) may be exceeded.
-.NOEXPORT:
diff --git a/crypto/heimdal/doc/ack.texi b/crypto/heimdal/doc/ack.texi
deleted file mode 100644
index 3c41f50..0000000
--- a/crypto/heimdal/doc/ack.texi
+++ /dev/null
@@ -1,72 +0,0 @@
-@c $Id: ack.texi 21228 2007-06-20 10:18:03Z lha $
-
-@node  Acknowledgments, , Migration, Top
-@comment  node-name,  next,  previous,  up
-@appendix Acknowledgments
-
-Eric Young wrote ``libdes''. Heimdal used to use libdes, without it
-kth-krb would never have existed. Since there are no longer any Eric
-Young code left in the library, we renamed it to libhcrypto.
-
-All functions in libhcrypto have been re-implemented or used available
-public domain code. The core AES function where written by Vincent
-Rijmen, Antoon Bosselaers and Paulo Barreto.  The core DES SBOX
-transformation was written by Richard Outerbridge. @code{imath} that
-is used for public key crypto support is written by Michael
-J. Fromberger.
-
-The University of California at Berkeley initially wrote @code{telnet},
-and @code{telnetd}.  The authentication and encryption code of
-@code{telnet} and @code{telnetd} was added by David Borman (then of Cray
-Research, Inc).  The encryption code was removed when this was exported
-and then added back by Juha Eskelinen.
-
-The @code{popper} was also a Berkeley program initially.
-
-Some of the functions in @file{libroken} also come from Berkeley by way
-of NetBSD/FreeBSD.
-
-@code{editline} was written by Simmule Turner and Rich Salz. Heimdal
-contains a modifed copy.
-
-The @code{getifaddrs} implementation for Linux was written by Hideaki
-YOSHIFUJI for the Usagi project.
-
-The @code{pkcs11.h} headerfile was written by the Scute project.
-
-Bugfixes, documentation, encouragement, and code has been contributed by:
-@table @asis
-@item Alexander Boström
-@item Andreaw Bartlett
-@item Björn Sandell
-@item Brandon S. Allbery KF8NH
-@item Brian A May
-@item Chaskiel M Grundman
-@item Cizzi Storm
-@item Daniel Kouril
-@item David Love
-@item Derrick J Brashear
-@item Douglas E Engert
-@item Frank van der Linden
-@item Jason McIntyre
-@item Johan Ihrén
-@item Jun-ichiro itojun Hagino
-@item Ken Hornstein
-@item Magnus Ahltorp
-@item Marc Horowitz
-@item Mario Strasser
-@item Mark Eichin
-@item Mattias Amnefelt
-@item Michael B Allen
-@item Michael Fromberger
-@item Michal Vocu
-@item Miroslav Ruda
-@item Petr Holub
-@item Phil Fisher
-@item Rafal Malinowski
-@item Richard Nyberg
-@item Åke Sandgren 
-@item and we hope that those not mentioned here will forgive us.
-@end table
-
-All bugs were introduced by ourselves.
diff --git a/crypto/heimdal/doc/apps.texi b/crypto/heimdal/doc/apps.texi
deleted file mode 100644
index 9d451b6..0000000
--- a/crypto/heimdal/doc/apps.texi
+++ /dev/null
@@ -1,244 +0,0 @@
-@c $Id: apps.texi 22071 2007-11-14 20:04:50Z lha $
-
-@node Applications, Things in search for a better place, Setting up a realm, Top
-
-@chapter Applications
-
-@menu
-* Authentication modules::
-* AFS::
-@end menu
-
-@node  Authentication modules, AFS, Applications, Applications
-@section Authentication modules
-
-The problem of having different authentication mechanisms has been
-recognised by several vendors, and several solutions have appeared. In
-most cases these solutions involve some kind of shared modules that are
-loaded at run-time.  Modules for some of these systems can be found in
-@file{lib/auth}.  Presently there are modules for Digital's SIA,
-and IRIX' @code{login} and @code{xdm} (in
-@file{lib/auth/afskauthlib}).
-
-@menu
-* Digital SIA::                 
-* IRIX::                        
-@end menu
-
-@node Digital SIA, IRIX, Authentication modules, Authentication modules
-@subsection Digital SIA
-
-How to install the SIA module depends on which OS version you're
-running. Tru64 5.0 has a new command, @file{siacfg}, which makes this
-process quite simple. If you have this program, you should just be able
-to run:
-@example
-siacfg -a KRB5 /usr/athena/lib/libsia_krb5.so
-@end example
-
-On older versions, or if you want to do it by hand, you have to do the
-following (not tested by us on Tru64 5.0):
-
-@itemize @bullet
-
-@item
-Make sure @file{libsia_krb5.so} is available in
-@file{/usr/athena/lib}. If @file{/usr/athena} is not on local disk, you
-might want to put it in @file{/usr/shlib} or someplace else. If you do,
-you'll have to edit @file{krb5_matrix.conf} to reflect the new location
-(you will also have to do this if you installed in some other directory
-than @file{/usr/athena}). If you built with shared libraries, you will
-have to copy the shared @file{libkrb.so}, @file{libdes.so},
-@file{libkadm.so}, and @file{libkafs.so} to a place where the loader can
-find them (such as @file{/usr/shlib}).
-@item
-Copy (your possibly edited) @file{krb5_matrix.conf} to @file{/etc/sia}.
-@item
-Apply @file{security.patch} to @file{/sbin/init.d/security}.
-@item
-Turn on KRB5 security by issuing @kbd{rcmgr set SECURITY KRB5} and
-@kbd{rcmgr set KRB5_MATRIX_CONF krb5_matrix.conf}.
-@item
-Digital thinks you should reboot your machine, but that really shouldn't
-be necessary.  It's usually sufficient just to run
-@kbd{/sbin/init.d/security start} (and restart any applications that use
-SIA, like @code{xdm}.)
-@end itemize
-
-Users with local passwords (like @samp{root}) should be able to login
-safely.
-
-When using Digital's xdm the @samp{KRB5CCNAME} environment variable isn't
-passed along as it should (since xdm zaps the environment). Instead you
-have to set @samp{KRB5CCNAME} to the correct value in
-@file{/usr/lib/X11/xdm/Xsession}. Add a line similar to
-@example
-KRB5CCNAME=FILE:/tmp/krb5cc`id -u`_`ps -o ppid= -p $$`; export KRB5CCNAME
-@end example
-If you use CDE, @code{dtlogin} allows you to specify which additional
-environment variables it should export. To add @samp{KRB5CCNAME} to this
-list, edit @file{/usr/dt/config/Xconfig}, and look for the definition of
-@samp{exportList}. You want to add something like:
-@example
-Dtlogin.exportList:     KRB5CCNAME
-@end example
-
-@subsubheading Notes to users with Enhanced security
-
-Digital's @samp{ENHANCED} (C2) security, and Kerberos solve two
-different problems. C2 deals with local security, adds better control of
-who can do what, auditing, and similar things. Kerberos deals with
-network security.
-
-To make C2 security work with Kerberos you will have to do the
-following.
-
-@itemize @bullet
-@item
-Replace all occurrences of @file{krb5_matrix.conf} with
-@file{krb5+c2_matrix.conf} in the directions above.
-@item
-You must enable ``vouching'' in the @samp{default} database.  This will
-make the OSFC2 module trust other SIA modules, so you can login without
-giving your C2 password. To do this use @samp{edauth} to edit the
-default entry @kbd{/usr/tcb/bin/edauth -dd default}, and add a
-@samp{d_accept_alternate_vouching} capability, if not already present.
-@item
-For each user who does @emph{not} have a local C2 password, you should
-set the password expiration field to zero. You can do this for each
-user, or in the @samp{default} table. To do this use @samp{edauth} to
-set (or change) the @samp{u_exp} capability to @samp{u_exp#0}.
-@item
-You also need to be aware that the shipped @file{login}, @file{rcp}, and
-@file{rshd}, don't do any particular C2 magic (such as checking for
-various forms of disabled accounts), so if you rely on those features,
-you shouldn't use those programs. If you configure with
-@samp{--enable-osfc2}, these programs will, however, set the login
-UID. Still: use at your own risk.
-@end itemize
-
-At present @samp{su} does not accept the vouching flag, so it will not
-work as expected.
-
-Also, kerberised ftp will not work with C2 passwords. You can solve this
-by using both Digital's ftpd and our on different ports.
-
-@strong{Remember}, if you do these changes you will get a system that
-most certainly does @emph{not} fulfil the requirements of a C2
-system. If C2 is what you want, for instance if someone else is forcing
-you to use it, you're out of luck.  If you use enhanced security because
-you want a system that is more secure than it would otherwise be, you
-probably got an even more secure system. Passwords will not be sent in
-the clear, for instance.
-
-@node IRIX, , Digital SIA, Authentication modules
-@subsection IRIX
-
-The IRIX support is a module that is compatible with Transarc's
-@file{afskauthlib.so}.  It should work with all programs that use this
-library. This should include @command{login} and @command{xdm}.
-
-The interface is not very documented but it seems that you have to copy
-@file{libkafs.so}, @file{libkrb.so}, and @file{libdes.so} to
-@file{/usr/lib}, or build your @file{afskauthlib.so} statically.
-
-The @file{afskauthlib.so} itself is able to reside in
-@file{/usr/vice/etc}, @file{/usr/afsws/lib}, or the current directory
-(wherever that is).
-
-IRIX 6.4 and newer seem to have all programs (including @command{xdm} and
-@command{login}) in the N32 object format, whereas in older versions they
-were O32. For it to work, the @file{afskauthlib.so} library has to be in
-the same object format as the program that tries to load it. This might
-require that you have to configure and build for O32 in addition to the
-default N32.
-
-Apart from this it should ``just work''; there are no configuration
-files.
-
-Note that recent Irix 6.5 versions (at least 6.5.22) have PAM,
-including a @file{pam_krb5.so} module.  Not all relevant programs use
-PAM, though, e.g.@: @command{ssh}. In particular, for console
-graphical login you need to turn off @samp{visuallogin} and turn on
-@samp{xdm} with @command{chkconfig}.
-
-@node AFS, , Authentication modules, Applications
-@section AFS
-
-@cindex AFS
-AFS is a distributed filesystem that uses Kerberos for authentication.
-
-@cindex OpenAFS
-@cindex Arla
-For more information about AFS see OpenAFS
-@url{http://www.openafs.org/} and Arla
-@url{http://www.stacken.kth.se/projekt/arla/}.
-
-@subsection How to get a KeyFile
-
-@file{ktutil -k AFSKEYFILE:KeyFile get afs@@MY.REALM}
-
-or you can extract it with kadmin
-
-@example
-kadmin> ext -k AFSKEYFILE:/usr/afs/etc/KeyFile afs@@My.CELL.NAME
-@end example
-
-You have to make sure you have a @code{des-cbc-md5} encryption type since that
-is the enctype that will be converted.
-
-@subsection How to convert a srvtab to a KeyFile
-
-You need a @file{/usr/vice/etc/ThisCell} containing the cellname of your
-AFS-cell.
-
-@file{ktutil copy krb4:/root/afs-srvtab AFSKEYFILE:/usr/afs/etc/KeyFile}.
-
-If keyfile already exists, this will add the new key in afs-srvtab to
-KeyFile.
-
-@section Using 2b tokens with AFS
-
-@subsection What is 2b ?
-
-2b is the name of the proposal that was implemented to give basic
-Kerberos 5 support to AFS in rxkad. It's not real Kerberos 5 support
-since it still uses fcrypt for data encryption and not Kerberos
-encryption types.
-
-Its only possible (in all cases) to do this for DES encryption types
-because only then the token (the AFS equivalent of a ticket) will be
-smaller than the maximum size that can fit in the token cache in the
-OpenAFS/Transarc client. It is a so tight fit that some extra wrapping
-on the ASN1/DER encoding is removed from the Kerberos ticket.
-
-2b uses a Kerberos 5 EncTicketPart instead of a Kerberos 4 ditto for
-the part of the ticket that is encrypted with the service's key. The
-client doesn't know what's inside the encrypted data so to the client
-it doesn't matter.
-
-To  differentiate between Kerberos 4 tickets and Kerberos 5 tickets, 2b
-uses a special kvno, 213 for 2b tokens and 255 for Kerberos 5 tokens.
-
-Its a requirement that all AFS servers that support 2b also support
-native Kerberos 5 in rxkad.
-
-@subsection Configuring a Heimdal kdc to use 2b tokens
-
-Support for 2b tokens in the kdc are turned on for specific principals
-by adding them to the string list option @code{[kdc]use_2b} in the
-kdc's @file{krb5.conf} file.
-
-@example
-[kdc]
-	use_2b = @{
-		afs@@SU.SE = yes
-		afs/it.su.se@@SU.SE = yes
-	@}
-@end example
-
-@subsection Configuring AFS clients for 2b support
-
-There is no need to configure AFS clients for 2b support. The only
-software that needs to be installed/upgrade is a Kerberos 5 enabled
-@file{afslog}.
diff --git a/crypto/heimdal/doc/doxytmpl.dxy b/crypto/heimdal/doc/doxytmpl.dxy
deleted file mode 100644
index bb7f25c..0000000
--- a/crypto/heimdal/doc/doxytmpl.dxy
+++ /dev/null
@@ -1,257 +0,0 @@
-#---------------------------------------------------------------------------
-# Project related configuration options
-#---------------------------------------------------------------------------
-DOXYFILE_ENCODING      = UTF-8
-CREATE_SUBDIRS         = NO
-OUTPUT_LANGUAGE        = English
-BRIEF_MEMBER_DESC      = YES
-REPEAT_BRIEF           = YES
-ABBREVIATE_BRIEF       = "The $name class " \
-                         "The $name widget " \
-                         "The $name file " \
-                         is \
-                         provides \
-                         specifies \
-                         contains \
-                         represents \
-                         a \
-                         an \
-                         the
-ALWAYS_DETAILED_SEC    = NO
-INLINE_INHERITED_MEMB  = NO
-FULL_PATH_NAMES        = YES
-STRIP_FROM_PATH        = /Applications/
-STRIP_FROM_INC_PATH    = 
-SHORT_NAMES            = NO
-JAVADOC_AUTOBRIEF      = NO
-QT_AUTOBRIEF           = NO
-MULTILINE_CPP_IS_BRIEF = NO
-DETAILS_AT_TOP         = NO
-INHERIT_DOCS           = YES
-SEPARATE_MEMBER_PAGES  = NO
-TAB_SIZE               = 8
-ALIASES                = 
-OPTIMIZE_OUTPUT_FOR_C  = YES
-OPTIMIZE_OUTPUT_JAVA   = NO
-BUILTIN_STL_SUPPORT    = NO
-CPP_CLI_SUPPORT        = NO
-DISTRIBUTE_GROUP_DOC   = NO
-SUBGROUPING            = YES
-#---------------------------------------------------------------------------
-# Build related configuration options
-#---------------------------------------------------------------------------
-EXTRACT_ALL            = NO
-EXTRACT_PRIVATE        = NO
-EXTRACT_STATIC         = NO
-EXTRACT_LOCAL_CLASSES  = YES
-EXTRACT_LOCAL_METHODS  = NO
-EXTRACT_ANON_NSPACES   = NO
-HIDE_UNDOC_MEMBERS     = YES
-HIDE_UNDOC_CLASSES     = YES
-HIDE_FRIEND_COMPOUNDS  = NO
-HIDE_IN_BODY_DOCS      = NO
-INTERNAL_DOCS          = NO
-CASE_SENSE_NAMES       = NO
-HIDE_SCOPE_NAMES       = NO
-SHOW_INCLUDE_FILES     = YES
-INLINE_INFO            = YES
-SORT_MEMBER_DOCS       = YES
-SORT_BRIEF_DOCS        = NO
-SORT_BY_SCOPE_NAME     = NO
-GENERATE_TODOLIST      = YES
-GENERATE_TESTLIST      = YES
-GENERATE_BUGLIST       = YES
-GENERATE_DEPRECATEDLIST= YES
-ENABLED_SECTIONS       = 
-MAX_INITIALIZER_LINES  = 30
-SHOW_USED_FILES        = YES
-SHOW_DIRECTORIES       = NO
-FILE_VERSION_FILTER    = 
-#---------------------------------------------------------------------------
-# configuration options related to warning and progress messages
-#---------------------------------------------------------------------------
-QUIET                  = YES
-WARNINGS               = YES
-WARN_IF_DOC_ERROR      = YES
-WARN_NO_PARAMDOC       = YES
-WARN_FORMAT            = "$file:$line: $text "
-WARN_LOGFILE           = 
-#---------------------------------------------------------------------------
-# configuration options related to the input files
-#---------------------------------------------------------------------------
-INPUT_ENCODING         = UTF-8
-FILE_PATTERNS          = *.c \
-                         *.cc \
-                         *.cxx \
-                         *.cpp \
-                         *.c++ \
-                         *.d \
-                         *.java \
-                         *.ii \
-                         *.ixx \
-                         *.ipp \
-                         *.i++ \
-                         *.inl \
-                         *.h \
-                         *.hh \
-                         *.hxx \
-                         *.hpp \
-                         *.h++ \
-                         *.idl \
-                         *.odl \
-                         *.cs \
-                         *.php \
-                         *.php3 \
-                         *.inc \
-                         *.m \
-                         *.mm \
-                         *.dox \
-                         *.py
-RECURSIVE              = YES
-EXCLUDE                = 
-EXCLUDE_SYMLINKS       = NO
-EXCLUDE_PATTERNS       = */.svn
-EXCLUDE_SYMBOLS        = 
-EXAMPLE_PATH           = 
-EXAMPLE_PATTERNS       = *
-EXAMPLE_RECURSIVE      = NO
-IMAGE_PATH             = 
-INPUT_FILTER           = 
-FILTER_PATTERNS        = 
-FILTER_SOURCE_FILES    = NO
-#---------------------------------------------------------------------------
-# configuration options related to source browsing
-#---------------------------------------------------------------------------
-SOURCE_BROWSER         = NO
-INLINE_SOURCES         = NO
-STRIP_CODE_COMMENTS    = YES
-REFERENCED_BY_RELATION = NO
-REFERENCES_RELATION    = NO
-REFERENCES_LINK_SOURCE = YES
-USE_HTAGS              = NO
-VERBATIM_HEADERS       = NO
-#---------------------------------------------------------------------------
-# configuration options related to the alphabetical class index
-#---------------------------------------------------------------------------
-ALPHABETICAL_INDEX     = NO
-COLS_IN_ALPHA_INDEX    = 5
-IGNORE_PREFIX          = 
-#---------------------------------------------------------------------------
-# configuration options related to the HTML output
-#---------------------------------------------------------------------------
-GENERATE_HTML          = YES
-HTML_OUTPUT            = html
-HTML_FILE_EXTENSION    = .html
-HTML_STYLESHEET        = 
-HTML_ALIGN_MEMBERS     = YES
-GENERATE_HTMLHELP      = NO
-HTML_DYNAMIC_SECTIONS  = NO
-CHM_FILE               = 
-HHC_LOCATION           = 
-GENERATE_CHI           = NO
-BINARY_TOC             = NO
-TOC_EXPAND             = NO
-DISABLE_INDEX          = NO
-ENUM_VALUES_PER_LINE   = 4
-GENERATE_TREEVIEW      = NO
-TREEVIEW_WIDTH         = 250
-#---------------------------------------------------------------------------
-# configuration options related to the LaTeX output
-#---------------------------------------------------------------------------
-GENERATE_LATEX         = NO
-LATEX_OUTPUT           = latex
-LATEX_CMD_NAME         = latex
-MAKEINDEX_CMD_NAME     = makeindex
-COMPACT_LATEX          = NO
-PAPER_TYPE             = a4wide
-EXTRA_PACKAGES         = 
-LATEX_HEADER           = 
-PDF_HYPERLINKS         = NO
-USE_PDFLATEX           = NO
-LATEX_BATCHMODE        = NO
-LATEX_HIDE_INDICES     = NO
-#---------------------------------------------------------------------------
-# configuration options related to the RTF output
-#---------------------------------------------------------------------------
-GENERATE_RTF           = NO
-RTF_OUTPUT             = rtf
-COMPACT_RTF            = NO
-RTF_HYPERLINKS         = NO
-RTF_STYLESHEET_FILE    = 
-RTF_EXTENSIONS_FILE    = 
-#---------------------------------------------------------------------------
-# configuration options related to the man page output
-#---------------------------------------------------------------------------
-GENERATE_MAN           = YES
-MAN_OUTPUT             = man
-MAN_EXTENSION          = .3
-MAN_LINKS              = YES
-#---------------------------------------------------------------------------
-# configuration options related to the XML output
-#---------------------------------------------------------------------------
-GENERATE_XML           = NO
-XML_OUTPUT             = xml
-XML_SCHEMA             = 
-XML_DTD                = 
-XML_PROGRAMLISTING     = YES
-#---------------------------------------------------------------------------
-# configuration options for the AutoGen Definitions output
-#---------------------------------------------------------------------------
-GENERATE_AUTOGEN_DEF   = NO
-#---------------------------------------------------------------------------
-# configuration options related to the Perl module output
-#---------------------------------------------------------------------------
-GENERATE_PERLMOD       = NO
-PERLMOD_LATEX          = NO
-PERLMOD_PRETTY         = YES
-PERLMOD_MAKEVAR_PREFIX = 
-#---------------------------------------------------------------------------
-# Configuration options related to the preprocessor   
-#---------------------------------------------------------------------------
-ENABLE_PREPROCESSING   = YES
-MACRO_EXPANSION        = NO
-EXPAND_ONLY_PREDEF     = NO
-SEARCH_INCLUDES        = YES
-INCLUDE_PATH           = 
-INCLUDE_FILE_PATTERNS  = 
-PREDEFINED             = 
-EXPAND_AS_DEFINED      = 
-SKIP_FUNCTION_MACROS   = YES
-#---------------------------------------------------------------------------
-# Configuration::additions related to external references   
-#---------------------------------------------------------------------------
-TAGFILES               = 
-GENERATE_TAGFILE       = 
-ALLEXTERNALS           = NO
-EXTERNAL_GROUPS        = YES
-#---------------------------------------------------------------------------
-# Configuration options related to the dot tool   
-#---------------------------------------------------------------------------
-CLASS_DIAGRAMS         = NO
-MSCGEN_PATH            = /Applications/Doxygen.app/Contents/Resources/
-HIDE_UNDOC_RELATIONS   = YES
-HAVE_DOT               = YES
-CLASS_GRAPH            = YES
-COLLABORATION_GRAPH    = YES
-GROUP_GRAPHS           = YES
-UML_LOOK               = NO
-TEMPLATE_RELATIONS     = NO
-INCLUDE_GRAPH          = YES
-INCLUDED_BY_GRAPH      = YES
-CALL_GRAPH             = NO
-CALLER_GRAPH           = NO
-GRAPHICAL_HIERARCHY    = YES
-DIRECTORY_GRAPH        = YES
-DOT_IMAGE_FORMAT       = png
-DOT_PATH               = /Applications/Doxygen.app/Contents/Resources/
-DOTFILE_DIRS           = 
-DOT_GRAPH_MAX_NODES    = 50
-MAX_DOT_GRAPH_DEPTH    = 1000
-DOT_TRANSPARENT        = NO
-DOT_MULTI_TARGETS      = NO
-GENERATE_LEGEND        = YES
-DOT_CLEANUP            = YES
-#---------------------------------------------------------------------------
-# Configuration::additions related to the search engine   
-#---------------------------------------------------------------------------
-SEARCHENGINE           = NO
diff --git a/crypto/heimdal/doc/hcrypto.din b/crypto/heimdal/doc/hcrypto.din
deleted file mode 100644
index 55f1ed7..0000000
--- a/crypto/heimdal/doc/hcrypto.din
+++ /dev/null
@@ -1,15 +0,0 @@
-# Doxyfile 1.5.3
-
-PROJECT_NAME           = "Heimdal crypto library"
-PROJECT_NUMBER         = @PACKAGE_VERSION@
-OUTPUT_DIRECTORY       = @objdir@/hcrypto
-INPUT                  = @srcdir@/../lib/hcrypto
-
-WARN_IF_UNDOCUMENTED   = YES
-
-PERL_PATH              = /usr/bin/perl
-
-HTML_HEADER = "@srcdir@/header.html"
-HTML_FOOTER = "@srcdir@/footer.html"
-
-@INCLUDE = "@srcdir@/doxytmpl.dxy"
diff --git a/crypto/heimdal/doc/heimdal.css b/crypto/heimdal/doc/heimdal.css
deleted file mode 100644
index 2e5b374..0000000
--- a/crypto/heimdal/doc/heimdal.css
+++ /dev/null
@@ -1,53 +0,0 @@
-body {
-	color: black;
-	background-color: #fdfdfd;
-	font-family: serif;
-	max-width: 40em;
-}
-h1, h2, h3 {
-	font-family: sans-serif;
-	font-weight: bold;
-}
-h1 {
-    padding: 0.5em 0 0.5em 5%;
-    color: white;
-    background: #3366cc;
-    border-bottom: solid 1px black;
-}
-h1 {
-	font-size: 200%;
-}
-h2 {
-	font-size: 150%;
-}
-h3 {
-	font-size: 120%;
-}
-h4 {
-	font-weight: bold;
-}
-pre.example {
-	margin-left: 2em;
-	padding: 1em 0em;
-	border: 2px dashed #c0c0c0;
-	background: #f0f0f0;
-}
-a:link {
-  color: blue;
-  text-decoration: none;
-}
-a:visited {
-  color: red;
-  text-decoration: none
-}
-a:hover {
-  text-decoration: underline
-}
-span.literal {
-	font-family: monospace;
-}
-hr {
-	border-style: none;
-	background-color: black;
-	height: 1px;
-}
diff --git a/crypto/heimdal/doc/heimdal.texi b/crypto/heimdal/doc/heimdal.texi
deleted file mode 100644
index 1b999d3..0000000
--- a/crypto/heimdal/doc/heimdal.texi
+++ /dev/null
@@ -1,370 +0,0 @@
-\input texinfo @c -*- texinfo -*-
-@c %**start of header
-@c $Id: heimdal.texi 22191 2007-12-06 17:26:30Z lha $
-@setfilename heimdal.info
-@settitle HEIMDAL
-@iftex
-@afourpaper
-@end iftex
-@c some sensible characters, please?
-@tex
-\input latin1.tex
-@end tex
-@setchapternewpage on
-@syncodeindex pg cp
-@c %**end of header
-
-@include vars.texi
-
-@set UPDATED $Date: 2007-12-06 09:26:30 -0800 (Tor, 06 Dec 2007) $
-@set VERSION @value{PACKAGE_VERSION}
-@set EDITION 1.0
-
-@ifinfo
-@dircategory Security
-@direntry
-* Heimdal: (heimdal).           The Kerberos 5 distribution from KTH
-@end direntry
-@end ifinfo
-
-@c title page
-@titlepage
-@title Heimdal
-@subtitle Kerberos 5 from KTH
-@subtitle Edition @value{EDITION}, for version @value{VERSION}
-@subtitle 2007
-@author Johan Danielsson
-@author Love Hörnquist Åstrand
-@author Assar Westerlund
-@author last updated @value{UPDATED}
-
-@def@copynext{@vskip 20pt plus 1fil@penalty-1000}
-@def@copyrightstart{}
-@def@copyrightend{}
-@page
-@copyrightstart
-Copyright (c) 1997-2007 Kungliga Tekniska Högskolan 
-(Royal Institute of Technology, Stockholm, Sweden).
-All rights reserved.
-
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions
-are met:
-
-1. Redistributions of source code must retain the above copyright
-   notice, this list of conditions and the following disclaimer.
-
-2. Redistributions in binary form must reproduce the above copyright
-   notice, this list of conditions and the following disclaimer in the
-   documentation and/or other materials provided with the distribution.
-
-3. Neither the name of the Institute nor the names of its contributors
-   may be used to endorse or promote products derived from this software
-   without specific prior written permission.
-
-THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND
-ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-ARE DISCLAIMED.  IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE
-FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-SUCH DAMAGE.
-
-@copynext
-
-Copyright (C) 1990 by the Massachusetts Institute of Technology
-
-Export of this software from the United States of America may
-require a specific license from the United States Government.
-It is the responsibility of any person or organization contemplating
-export to obtain such a license before exporting.
-
-WITHIN THAT CONSTRAINT, permission to use, copy, modify, and
-distribute this software and its documentation for any purpose and
-without fee is hereby granted, provided that the above copyright
-notice appear in all copies and that both that copyright notice and
-this permission notice appear in supporting documentation, and that
-the name of M.I.T. not be used in advertising or publicity pertaining
-to distribution of the software without specific, written prior
-permission.  M.I.T. makes no representations about the suitability of
-this software for any purpose.  It is provided "as is" without express
-or implied warranty.
-
-@copynext
-
-Copyright (c) 1988, 1990, 1993
-     The Regents of the University of California.  All rights reserved.
-
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions
-are met:
-
-1. Redistributions of source code must retain the above copyright
-   notice, this list of conditions and the following disclaimer.
-
-2. Redistributions in binary form must reproduce the above copyright
-   notice, this list of conditions and the following disclaimer in the
-   documentation and/or other materials provided with the distribution.
-
-3. Neither the name of the University nor the names of its contributors
-   may be used to endorse or promote products derived from this software
-   without specific prior written permission.
-
-THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
-ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
-FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-SUCH DAMAGE.
-
-@copynext
-
-Copyright 1992 Simmule Turner and Rich Salz.  All rights reserved. 
-
-This software is not subject to any license of the American Telephone 
-and Telegraph Company or of the Regents of the University of California. 
-
-Permission is granted to anyone to use this software for any purpose on
-any computer system, and to alter it and redistribute it freely, subject
-to the following restrictions:
-
-1. The authors are not responsible for the consequences of use of this
-   software, no matter how awful, even if they arise from flaws in it.
-
-2. The origin of this software must not be misrepresented, either by
-   explicit claim or by omission.  Since few users ever read sources,
-   credits must appear in the documentation.
-
-3. Altered versions must be plainly marked as such, and must not be
-   misrepresented as being the original software.  Since few users
-   ever read sources, credits must appear in the documentation.
-
-4. This notice may not be removed or altered.
-
-@copynext
-
-IMath is Copyright 2002-2005 Michael J. Fromberger
-You may use it subject to the following Licensing Terms:
-
-Permission is hereby granted, free of charge, to any person obtaining
-a copy of this software and associated documentation files (the
-"Software"), to deal in the Software without restriction, including
-without limitation the rights to use, copy, modify, merge, publish,
-distribute, sublicense, and/or sell copies of the Software, and to
-permit persons to whom the Software is furnished to do so, subject to
-the following conditions:
-
-The above copyright notice and this permission notice shall be
-included in all copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
-EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
-MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
-IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
-CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
-TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
-SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
-
-@copynext
-
-Copyright (c) 2005 Doug Rabson
-All rights reserved.
-
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions
-are met:
-1. Redistributions of source code must retain the above copyright
-   notice, this list of conditions and the following disclaimer.
-2. Redistributions in binary form must reproduce the above copyright
-   notice, this list of conditions and the following disclaimer in the
-   documentation and/or other materials provided with the distribution.
-
-THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
-ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
-FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-SUCH DAMAGE.
-
-@copynext
-
-Copyright (c) 2005 Marko Kreen
-All rights reserved.
-
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions
-are met:
-1. Redistributions of source code must retain the above copyright
-       notice, this list of conditions and the following disclaimer.
-2. Redistributions in binary form must reproduce the above copyright
-       notice, this list of conditions and the following disclaimer in the
-       documentation and/or other materials provided with the distribution.
-
-THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
-ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-ARE DISCLAIMED.	IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
-FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-SUCH DAMAGE.
-
-@copynext
-
-Copyright (c) 2006,2007
-NTT (Nippon Telegraph and Telephone Corporation) . All rights reserved.
-
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions
-are met:
-1. Redistributions of source code must retain the above copyright
-  notice, this list of conditions and the following disclaimer as
-  the first lines of this file unmodified.
-2. Redistributions in binary form must reproduce the above copyright
-  notice, this list of conditions and the following disclaimer in the
-  documentation and/or other materials provided with the distribution.
-
-THIS SOFTWARE IS PROVIDED BY NTT ``AS IS'' AND ANY EXPRESS OR
-IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
-OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
-IN NO EVENT SHALL NTT BE LIABLE FOR ANY DIRECT, INDIRECT,
-INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
-NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
-THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
-@copyrightend
-@end titlepage
-
-@macro manpage{man, section}
-@cite{\man\(\section\)}
-@end macro
-
-@c Less filling! Tastes great!
-@iftex
-@parindent=0pt
-@global@parskip 6pt plus 1pt
-@global@chapheadingskip = 15pt plus 4pt minus 2pt 
-@global@secheadingskip = 12pt plus 3pt minus 2pt
-@global@subsecheadingskip = 9pt plus 2pt minus 2pt
-@end iftex
-@ifinfo
-@paragraphindent 0
-@end ifinfo
-
-@ifnottex
-@node Top, Introduction, (dir), (dir)
-@top Heimdal
-@end ifnottex
-
-This manual is last updated @value{UPDATED} for version
-@value{VERSION} of Heimdal.
-
-@menu
-* Introduction::                
-* What is Kerberos?::           
-* Building and Installing::     
-* Setting up a realm::          
-* Applications::                
-* Things in search for a better place::  
-* Kerberos 4 issues::           
-* Windows 2000 compatability::  
-* Programming with Kerberos::   
-* Migration::                   
-* Acknowledgments::             
-
-@detailmenu
- --- The Detailed Node Listing ---
-
-Setting up a realm
-
-* Configuration file::          
-* Creating the database::       
-* Modifying the database::      
-* keytabs::                     
-* Serving Kerberos 4/524/kaserver::  
-* Remote administration::       
-* Password changing::           
-* Testing clients and servers::  
-* Slave Servers::               
-* Incremental propagation::     
-* Encryption types and salting::                     
-* Cross realm::                 
-* Transit policy::              
-* Setting up DNS::              
-* Using LDAP to store the database::  
-* Providing Kerberos credentials to servers and programs::  
-* Setting up PK-INIT::
-
-Applications
-
-* Authentication modules::      
-* AFS::                         
-
-Authentication modules
-
-* Digital SIA::                 
-* IRIX::                        
-
-Kerberos 4 issues
-
-* Principal conversion issues::  
-* Converting a version 4 database::  
-* kaserver::                    
-
-Windows 2000 compatability
-
-* Configuring Windows 2000 to use a Heimdal KDC::  
-* Inter-Realm keys (trust) between Windows 2000 and a Heimdal KDC::  
-* Create account mappings::     
-* Encryption types::            
-* Authorisation data::          
-* Quirks of Windows 2000 KDC::  
-* Useful links when reading about the Windows 2000::  
-
-Programming with Kerberos
-
-* Kerberos 5 API Overview::     
-* Walkthrough of a sample Kerberos 5 client::  
-* Validating a password in a server application::  
-* API differences to MIT Kerberos::  
-* File formats::
-
-@end detailmenu
-@end menu
-
-@include intro.texi
-@include whatis.texi
-@include install.texi
-@include setup.texi
-@include apps.texi
-@include misc.texi
-@include kerberos4.texi
-@include win2k.texi
-@include programming.texi
-@include migration.texi
-@include ack.texi
-
-@c @shortcontents
-@contents
-
-@bye
diff --git a/crypto/heimdal/doc/hx509.din b/crypto/heimdal/doc/hx509.din
deleted file mode 100644
index e28429f..0000000
--- a/crypto/heimdal/doc/hx509.din
+++ /dev/null
@@ -1,15 +0,0 @@
-# Doxyfile 1.5.3
-
-PROJECT_NAME           = Heimdal x509 library
-PROJECT_NUMBER         = @PACKAGE_VERSION@
-OUTPUT_DIRECTORY       = @objdir@/hx509
-INPUT                  = @srcdir@/../lib/hx509
-
-WARN_IF_UNDOCUMENTED   = YES
-
-PERL_PATH              = /usr/bin/perl
-
-HTML_HEADER = "@srcdir@/header.html"
-HTML_FOOTER = "@srcdir@/footer.html"
-
-@INCLUDE = "@srcdir@/doxytmpl.dxy"
diff --git a/crypto/heimdal/doc/hx509.texi b/crypto/heimdal/doc/hx509.texi
deleted file mode 100644
index dbb5261..0000000
--- a/crypto/heimdal/doc/hx509.texi
+++ /dev/null
@@ -1,633 +0,0 @@
-\input texinfo @c -*- texinfo -*-
-@c %**start of header
-@c $Id: hx509.texi 22071 2007-11-14 20:04:50Z lha $
-@setfilename hx509.info
-@settitle HX509
-@iftex
-@afourpaper
-@end iftex
-@c some sensible characters, please?
-@tex
-\input latin1.tex
-@end tex
-@setchapternewpage on
-@syncodeindex pg cp
-@c %**end of header
-
-@set UPDATED $Date: 2007-11-14 12:04:50 -0800 (Ons, 14 Nov 2007) $
-@set VERSION 1.0
-@set EDITION 1.0
-
-@ifinfo
-@dircategory Security
-@direntry
-* hx509: (hx509).           The X.509 distribution from KTH
-@end direntry
-@end ifinfo
-
-@c title page
-@titlepage
-@title HX509
-@subtitle X.509 distribution from KTH
-@subtitle Edition @value{EDITION}, for version @value{VERSION}
-@subtitle 2007
-@author Love Hörnquist Åstrand
-@author last updated @value{UPDATED}
-
-@def@copynext{@vskip 20pt plus 1fil@penalty-1000}
-@def@copyrightstart{}
-@def@copyrightend{}
-@page
-@copyrightstart
-Copyright (c) 1994-2007 Kungliga Tekniska Högskolan
-(Royal Institute of Technology, Stockholm, Sweden).
-All rights reserved.
-
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions
-are met:
-
-1. Redistributions of source code must retain the above copyright
-   notice, this list of conditions and the following disclaimer.
-
-2. Redistributions in binary form must reproduce the above copyright
-   notice, this list of conditions and the following disclaimer in the
-   documentation and/or other materials provided with the distribution.
-
-3. Neither the name of the Institute nor the names of its contributors
-   may be used to endorse or promote products derived from this software
-   without specific prior written permission.
-
-THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND
-ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-ARE DISCLAIMED.  IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE
-FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-SUCH DAMAGE.
-
-@copynext
-
-Copyright (C) 1990 by the Massachusetts Institute of Technology
-
-Export of this software from the United States of America may
-require a specific license from the United States Government.
-It is the responsibility of any person or organization contemplating
-export to obtain such a license before exporting.
-
-WITHIN THAT CONSTRAINT, permission to use, copy, modify, and
-distribute this software and its documentation for any purpose and
-without fee is hereby granted, provided that the above copyright
-notice appear in all copies and that both that copyright notice and
-this permission notice appear in supporting documentation, and that
-the name of M.I.T. not be used in advertising or publicity pertaining
-to distribution of the software without specific, written prior
-permission.  M.I.T. makes no representations about the suitability of
-this software for any purpose.  It is provided "as is" without express
-or implied warranty.
-
-@copynext
-
-Copyright (c) 1988, 1990, 1993
-     The Regents of the University of California.  All rights reserved.
-
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions
-are met:
-
-1. Redistributions of source code must retain the above copyright
-   notice, this list of conditions and the following disclaimer.
-
-2. Redistributions in binary form must reproduce the above copyright
-   notice, this list of conditions and the following disclaimer in the
-   documentation and/or other materials provided with the distribution.
-
-3. Neither the name of the University nor the names of its contributors
-   may be used to endorse or promote products derived from this software
-   without specific prior written permission.
-
-THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
-ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
-FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-SUCH DAMAGE.
-
-@copynext
-
-Copyright 1992 Simmule Turner and Rich Salz.  All rights reserved.
-
-This software is not subject to any license of the American Telephone
-and Telegraph Company or of the Regents of the University of California.
-
-Permission is granted to anyone to use this software for any purpose on
-any computer system, and to alter it and redistribute it freely, subject
-to the following restrictions:
-
-1. The authors are not responsible for the consequences of use of this
-   software, no matter how awful, even if they arise from flaws in it.
-
-2. The origin of this software must not be misrepresented, either by
-   explicit claim or by omission.  Since few users ever read sources,
-   credits must appear in the documentation.
-
-3. Altered versions must be plainly marked as such, and must not be
-   misrepresented as being the original software.  Since few users
-   ever read sources, credits must appear in the documentation.
-
-4. This notice may not be removed or altered.
-
-@copynext
-
-IMath is Copyright 2002-2005 Michael J. Fromberger
-You may use it subject to the following Licensing Terms:
-
-Permission is hereby granted, free of charge, to any person obtaining
-a copy of this software and associated documentation files (the
-"Software"), to deal in the Software without restriction, including
-without limitation the rights to use, copy, modify, merge, publish,
-distribute, sublicense, and/or sell copies of the Software, and to
-permit persons to whom the Software is furnished to do so, subject to
-the following conditions:
-
-The above copyright notice and this permission notice shall be
-included in all copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
-EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
-MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
-IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
-CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
-TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
-SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
-
-@copyrightend
-@end titlepage
-
-@macro manpage{man, section}
-@cite{\man\(\section\)}
-@end macro
-
-@c Less filling! Tastes great!
-@iftex
-@parindent=0pt
-@global@parskip 6pt plus 1pt
-@global@chapheadingskip = 15pt plus 4pt minus 2pt
-@global@secheadingskip = 12pt plus 3pt minus 2pt
-@global@subsecheadingskip = 9pt plus 2pt minus 2pt
-@end iftex
-@ifinfo
-@paragraphindent 0
-@end ifinfo
-
-@ifnottex
-@node Top, Introduction, (dir), (dir)
-@top Heimdal
-@end ifnottex
-
-This manual is last updated @value{UPDATED} for version
-@value{VERSION} of hx509.
-
-@menu
-* Introduction::
-* What is X.509 ?::
-* Setting up a CA::
-* CMS signing and encryption::
-
-@detailmenu
- --- The Detailed Node Listing ---
-
-Setting up a CA
-
-@c * Issuing certificates::
-* Creating a CA certificate::
-* Issuing certificates::
-* Issuing CRLs::
-@c * Issuing a proxy certificate::
-@c * Creating a user certificate::
-@c * Validating a certificate::
-@c * Validating a certificate path::
-* Application requirements::
-
-CMS signing and encryption
-
-* CMS background::
-
-@end detailmenu
-@end menu
-
-@node Introduction, What is X.509 ?, Top, Top
-@chapter Introduction
-
-hx509 is a somewhat complete X.509 stack that can handle CMS messages
-(crypto system used in S/MIME and Kerberos PK-INIT) and basic
-certificate processing tasks, path construction, path validation, OCSP
-and CRL validation, PKCS10 message construction, CMS Encrypted (shared
-secret encrypted), CMS SignedData (certificate signed), and CMS
-EnvelopedData (certificate encrypted).
-
-hx509 can use PKCS11 tokens, PKCS12 files, PEM files, DER encoded files.
-
-@node What is X.509 ?, Setting up a CA, Introduction, Top
-@chapter What is X.509, PKIX, PKCS7 and CMS ? 
-
-X.509 is from the beginning created by CCITT (later ITU) for the X.500
-directory service. But today when people are talking about X.509 they
-are commonly referring to IETF's PKIX Certificate and CRL Profile of the
-X.509 v3 certificate standard, as specified in RFC 3280.
-
-ITU continues to develop the X.509 standard together in a complicated
-dance with IETF.
-
-X.509 is public key based security system that have associated data
-stored within a so called certificate. From the beginning X.509 was a
-strict hierarchical system with one root. This didn't not work so over
-time X.509 got support for multiple policy roots, bridges, and mesh
-solutions. You can even use it as a peer to peer system, but this is not
-very common.
-
-@section Type of certificates
-
-There are several flavors of certificate in X.509.
-
-@itemize @bullet
-
-@item Trust anchors
-
-Trust anchors are strictly not certificate, but commonly stored in
-certificate since they are easier to handle then. Trust anchor are the
-keys that you trust to validate other certificate. This is done by
-building a path from the certificate you wan to validate to to any of
-the trust anchors you have.
-
-@item End Entity (EE) certificates
-
-End entity certificates is the most common type of certificate. End
-entity certificates can't issue certificate them-self and is used to
-authenticate and authorize user and services.
-
-@item Certification Authority (CA) certificates
-
-Certificate authority are certificates that have the right to issue
-other certificate, they may be End entity certificates or Certificate
-Authority certificates. There is no limit to how many certificates a CA
-may issue, but there might other restrictions, like the maximum path
-depth.
-
-@item Proxy certificates
-
-Remember that End Entity can't issue certificates by them own, it's not
-really true. There there is an extension called proxy certificates,
-defined in RFC3820, that allows certificates to be issued by end entity
-certificates. The service that receives the proxy certificates must have
-explicitly turned on support for proxy certificates, so their use is
-somewhat limited.
-
-Proxy certificates can be limited by policy stored in the certificate to
-what they can be used for. This allows users to delegate the proxy
-certificate to services (by sending over the certificate and private
-key) so the service can access services on behalf of the user.
-
-One example of this would be a print service. The user wants to print a
-large job in the middle of the night when the printer isn't used that
-much, so the user creates a proxy certificate with the policy that it
-can only be used to access files related to this print job, creates the
-print job description and send both the description and proxy
-certificate with key over to print service. Later at night will the
-print service, without the help of the user, access the files for the
-the print job using the proxy certificate and print the job. Because of
-the policy (limitation) in the proxy certificate, it can't be used for
-any other purposes.
-
-@end itemize
-
-@section Building a path
-
-Before validating a path the path must be constructed. Given a
-certificate (EE, CA, Proxy, or any other type), the path construction
-algorithm will try to find a path to one of the trust anchors.
-
-It start with looking at whom issued the certificate, by name or Key
-Identifier, and tries to find that certificate while at the same time
-evaluates the policy.
-
-@node Setting up a CA, Creating a CA certificate, What is X.509 ?, Top
-@chapter Setting up a CA
-
-Do not let this chapter scare you off, it's just to give you an idea how
-to complicated setting up a CA can be. If you are just playing around,
-skip all this and go to the next chapter, @pxref{Creating a CA
-certificate}.
-
-Creating a CA certificate should be more the just creating a
-certificate, there is the policy of the CA. If it's just you and your
-friend that is playing around then it probably doesn't matter what the
-policy is. But then it comes to trust in an organisation, it will
-probably matter more whom your users and sysadmins will find it
-acceptable to trust.
-
-At the same time, try to keep thing simple, it's not very hard to run a
-Certificate authority and the process to get new certificates should
-simple.
-
-Fill all this in later.
-
-How do you trust your CA.
-
-What is the CA responsibility.
-
-Review of CA activity.
-
-How much process should it be to issue certificate.
-
-Who is allowed to issue certificates.
-
-Who is allowed to requests certificates.
-
-How to handle certificate revocation, issuing CRLs and maintain OCSP
-services.
-
-@node Creating a CA certificate, Issuing certificates, Setting up a CA, Top
-@section Creating a CA certificate
-
-This section describes how to create a CA certificate and what to think
-about.
-
-@subsection Lifetime CA certificate
-
-You probably want to create a CA certificate with a long lifetime, 10
-years at the shortest. This because you don't want to push out the
-certificate (as a trust anchor) to all you users once again when the old
-one just expired. A trust anchor can't really expire, but not all
-software works that way.
-
-Keep in mind the security requirements might be different 10-20 years
-into the future. For example, SHA1 is going to be withdrawn in 2010, so
-make sure you have enough buffering in your choice of digest/hash
-algorithms, signature algorithms and key lengths.
-
-@subsection Create a CA certificate
-
-This command below will create a CA certificate in the file ca.pem.
-
-@example
-hxtool issue-certificate \
-    --self-signed \
-    --issue-ca \
-    --generate-key=rsa \
-    --subject="CN=CertificateAuthority,DC=test,DC=h5l,DC=se" \
-    --lifetime=10years \
-    --certificate="FILE:ca.pem"
-@end example
-
-@subsection Extending lifetime of a CA certificate
-
-You just realised that your CA certificate is going to expire soon and
-that you need replace it with something else, the easiest way to do that
-is to extend the lifetime of your CA certificate.
-
-The example below will extend the CA certificate 10 years into the
-future. You should compare this new certificate if it contains all the
-special tweaks as the old certificate had.
-
-@example
-hxtool issue-certificate \
-    --self-signed \
-    --issue-ca \
-    --lifetime="10years" \
-    --template-certificate="FILE:ca.pem" \
-    --template-fields="serialNumber,notBefore,subject,SPKI" \
-    --ca-private-key=FILE:ca.pem \
-    --certificate="FILE:new-ca.pem"
-@end example
-
-@subsection Subordinate CA
-
-This example create a new subordinate certificate authority.
-
-@example
-hxtool issue-certificate \
-    --ca-certificate=FILE:ca.pem \
-    --issue-ca \
-    --generate-key=rsa \
-    --subject="CN=CertificateAuthority,DC=dev,DC=test,DC=h5l,DC=se" \
-    --certificate="FILE:dev-ca.pem"
-@end example
-
-
-@node Issuing certificates, Issuing CRLs, Creating a CA certificate, Top
-@section Issuing certificates
-
-First you'll create a CA certificate, after that you have to deal with
-your users and servers and issue certificate to them.
-
-CA can generate the key for the user.
-
-Can receive PKCS10 certificate requests from the users. PKCS10 is a
-request for a certificate. The user can specified what DN the user wants
-and what public key. To prove the user have the key, the whole request
-is signed by the private key of the user.
-
-@subsection Name space management
-
-What people might want to see.
-
-Re-issue certificates just because people moved within the organization.
-
-Expose privacy information.
-
-Using Sub-component name (+ notation).
-
-@subsection Certificate Revocation, CRL and OCSP
-
-Sonetimes people loose smartcard or computers and certificates have to
-be make not valid any more, this is called revoking certificates. There
-are two main protocols for doing this Certificate Revocations Lists
-(CRL) and Online Certificate Status Protocol (OCSP).
-
-If you know that the certificate is destroyed then there is no need to
-revoke the certificate because it can not be used by someone else.
-
-The main reason you as a CA administrator have to deal with CRLs however
-will be that some software require there to be CRLs. Example of this is
-Windows, so you have to deal with this somehow.
-
-@node Issuing CRLs, Application requirements, Issuing certificates, Top
-@section Issuing CRLs
-
-Create an empty CRL with not certificates revoked. Default expiration
-value is one year from now.
-
-@example
-hxtool crl-sign \
-	--crl-file=crl.der \
-	--signer=FILE:ca.pem
-@end example
-
-Create a CRL with all certificates in the directory
-@file{/path/to/revoked/dir} included in the CRL as revoked.  Also make
-it expire one month from now.
-
-@example
-hxtool crl-sign \
-	--crl-file=crl.der \
-        --signer=FILE:ca.pem \
-	--lifetime='1 month' \
-        DIR:/path/to/revoked/dir
-@end example
-
-@node Application requirements, CMS signing and encryption, Issuing CRLs, Top
-@section Application requirements
-
-Application have different requirements on certificates. This section
-tries to expand what they are and how to use hxtool to generate
-certificates for those services.
-
-@subsection HTTPS - server
-
-@example
-hxtool issue-certificate \
-	  --subject="CN=www.test.h5l.se,DC=test,DC=h5l,DC=se" \
-	  --type="https-server" \
-          --hostname="www.test.h5l.se" \
-          --hostname="www2.test.h5l.se" \
-          ...
-@end example
-
-@subsection HTTPS - client
-
-@example
-hxtool issue-certificate \
-	  --subject="UID=testus,DC=test,DC=h5l,DC=se" \
-	  --type="https-client" \
-          ...
-@end example
-
-@subsection S/MIME - email
-
-There are two things that should be set in S/MIME certificates, one or
-more email addresses and an extended eku usage (EKU), emailProtection.
-
-The email address format used in S/MIME certificates is defined in
-RFC2822, section 3.4.1 and it should be an ``addr-spec''.
-
-There are two ways to specifify email address in certificates. The old
-ways is in the subject distinguished name, this should not be used. The
-new way is using a Subject Alternative Name (SAN).
-
-But even though email address is stored in certificates, they don't need
-to, email reader programs are required to accept certificates that
-doesn't have either of the two methods of storing email in certificates.
-In that case, they try to protect the user by printing the name of the
-certificate instead.
-
-S/MIME certificate can be used in another special way. They can be
-issued with a NULL subject distinguished name plus the email in SAN,
-this is a valid certificate. This is used when you wont want to share
-more information then you need to.
-
-hx509 issue-certificate supports adding the email SAN to certificate by
-using the --email option, --email also gives an implicit emailProtection
-eku. If you want to create an certificate without an email address, the
-option --type=email will add the emailProtection EKU.
-
-@example
-hxtool issue-certificate \
-	  --subject="UID=testus-email,DC=test,DC=h5l,DC=se" \
-	  --type=email \
-	  --email="testus@@test.h5l.se" \
-          ...
-@end example
-
-An example of an certificate without and subject distinguished name with
-an email address in a SAN.
-
-@example
-hxtool issue-certificate \
-	  --subject="" \
-	  --type=email \
-	  --email="testus@@test.h5l.se" \
-          ...
-@end example
-
-@subsection PK-INIT
-
-How to create a certificate for a KDC.
-
-@example
-hxtool issue-certificate \
-    --type="pkinit-kdc" \
-    --pk-init-principal="krbtgt/TEST.H5L.SE@@TEST.H5L.SE" \
-    --hostname kerberos.test.h5l.se \
-    --hostname pal.test.h5l.se \
-    ...
-@end example
-
-How to create a certificate for a user.
-
-@example
-hxtool issue-certificate \
-    --type="pkinit-client" \
-    --pk-init-principal="user@@TEST.H5L.SE" \
-    ...
-@end example
-
-@subsection XMPP/Jabber
-
-The jabber server certificate should have a dNSname that is the same as
-the user entered into the application, not the same as the host name of
-the machine.
-
-@example
-hxtool issue-certificate \
-	  --subject="CN=xmpp1.test.h5l.se,DC=test,DC=h5l,DC=se" \
-          --hostname="xmpp1.test.h5l.se" \
-          --hostname="test.h5l.se" \
-          ...
-@end example
-
-The certificate may also contain a jabber identifier (JID) that, if the
-receiver allows it, authorises the server or client to use that JID.
-
-When storing a JID inside the certificate, both for server and client,
-it's stored inside a UTF8String within an otherName entity inside the
-subjectAltName, using the OID id-on-xmppAddr (1.3.6.1.5.5.7.8.5).
-
-To read more about the requirements, see RFC3920, Extensible Messaging
-and Presence Protocol (XMPP): Core.
-
-hxtool issue-certificate have support to add jid to the certificate
-using the option @kbd{--jid}.
-
-@example
-hxtool issue-certificate \
-	  --subject="CN=Love,DC=test,DC=h5l,DC=se" \
-          --jid="lha@@test.h5l.se" \
-          ...
-@end example
-
-
-@node CMS signing and encryption, CMS background, Application requirements, Top
-@chapter CMS signing and encryption
-
-CMS is the Cryptographic Message System that among other, is used by
-S/MIME (secure email) and Kerberos PK-INIT. It's an extended version of
-the RSA, Inc standard PKCS7.
-
-@node CMS background, , CMS signing and encryption, Top
-@section CMS background
-
-
-@c @shortcontents
-@contents
-
-@bye
diff --git a/crypto/heimdal/doc/init-creds b/crypto/heimdal/doc/init-creds
deleted file mode 100644
index 8892d29..0000000
--- a/crypto/heimdal/doc/init-creds
+++ /dev/null
@@ -1,374 +0,0 @@
-Currently, getting an initial ticket for a user involves many function
-calls, especially when a full set of features including password
-expiration and challenge preauthentication is desired.  In order to
-solve this problem, a new api is proposed.
-
-typedef struct _krb5_prompt {
-    char *prompt;
-    int hidden;
-    krb5_data *reply;
-} krb5_prompt;
-
-typedef int (*krb5_prompter_fct)(krb5_context context,
-				 void *data,
-				 const char *banner,
-				 int num_prompts,
-				 krb5_prompt prompts[]);
-
-typedef struct _krb5_get_init_creds_opt {
-    krb5_flags flags;
-    krb5_deltat tkt_life;
-    krb5_deltat renew_life;
-    int forwardable;
-    int proxiable;
-    krb5_enctype *etype_list;
-    int etype_list_length;
-    krb5_address **address_list;
-	/* XXX the next three should not be used, as they may be
-	removed later */
-    krb5_preauthtype *preauth_list;
-    int preauth_list_length;
-    krb5_data *salt;
-} krb5_get_init_creds_opt;
-
-#define KRB5_GET_INIT_CREDS_OPT_TKT_LIFE	0x0001
-#define KRB5_GET_INIT_CREDS_OPT_RENEW_LIFE	0x0002
-#define KRB5_GET_INIT_CREDS_OPT_FORWARDABLE	0x0004
-#define KRB5_GET_INIT_CREDS_OPT_PROXIABLE	0x0008
-#define KRB5_GET_INIT_CREDS_OPT_ETYPE_LIST	0x0010
-#define KRB5_GET_INIT_CREDS_OPT_ADDRESS_LIST	0x0020
-#define KRB5_GET_INIT_CREDS_OPT_PREAUTH_LIST	0x0040
-#define KRB5_GET_INIT_CREDS_OPT_SALT		0x0080
-
-void krb5_get_init_creds_opt_init(krb5_get_init_creds_opt *opt);
-
-void krb5_get_init_creds_opt_set_tkt_life(krb5_get_init_creds_opt *opt,
-					  krb5_deltat tkt_life);
-void krb5_get_init_creds_opt_set_renew_life(krb5_get_init_creds_opt *opt,
-					    krb5_deltat renew_life);
-void krb5_get_init_creds_opt_set_forwardable(krb5_get_init_creds_opt *opt,
-					     int forwardable);
-void krb5_get_init_creds_opt_set_proxiable(krb5_get_init_creds_opt *opt,
-					   int proxiable);
-void krb5_get_init_creds_opt_set_etype_list(krb5_get_init_creds_opt *opt,
-					    krb5_enctype *etype_list,
-					    int etype_list_length);
-void krb5_get_init_creds_opt_set_address_list(krb5_get_init_creds_opt *opt,
-					      krb5_address **addresses);
-void krb5_get_init_creds_opt_set_preauth_list(krb5_get_init_creds_opt *opt,
-					      krb5_preauthtype *preauth_list,
-					      int preauth_list_length);
-void krb5_get_init_creds_opt_set_salt(krb5_get_init_creds_opt *opt,
-				      krb5_data *salt);
-
-krb5_error_code
-krb5_get_init_creds_password(krb5_context context,
-			     krb5_creds *creds,
-			     krb5_principal client,
-			     char *password,
-			     krb5_prompter_fct prompter,
-			     void *data,
-			     krb5_deltat start_time,
-			     char *in_tkt_service,
-			     krb5_get_init_creds_opt *options);
-
-This function will attempt to acquire an initial ticket.  The function
-will perform whatever tasks are necessary to do so.  This may include
-changing an expired password, preauthentication.
-
-The arguments divide into two types.  Some arguments are basically
-invariant and arbitrary across all initial tickets, and if not
-specified are determined by configuration or library defaults.  Some
-arguments are different for each execution or application, and if not
-specified can be determined correctly from system configuration or
-environment.  The former arguments are contained in a structure whose
-pointer is passed to the function.  A bitmask specifies which elements
-of the structure should be used.  In most cases, a NULL pointer can be
-used.  The latter arguments are specified as individual arguments to
-the function.
-
-If a pointer to a credential is specified, the initial credential is
-filled in.  If the caller only wishes to do a simple password check
-and will not be doing any other kerberos functions, then a NULL
-pointer may be specified, and the credential will be destroyed.
-
-If the client name is non-NULL, the initial ticket requested will be
-for that principal.  Otherwise, the principal will be the username
-specified by the USER environment variable, or if the USER environment
-variable is not set, the username corresponding to the real user id of
-the caller.
-
-If the password is non-NULL, then this string is used as the password.
-Otherwise, the prompter function will be used to prompt the user for
-the password.
-
-If a prompter function is non-NULL, it will be used if additional user
-input is required, such as if the user's password has expired and
-needs to be changed, or if input preauthentication is necessary.  If
-no function is specified and input is required, then the login will
-fail.
-
-	The context argument is the same as that passed to krb5_login.
-	The data argument is passed unmodified to the prompter
-	function and is intended to be used to pass application data
-	(such as a display handle) to the prompter function.
-
-	The banner argument, if non-NULL, will indicate what sort of
-	input is expected from the user (for example, "Password has
-	expired and must be changed" or "Enter Activcard response for
-	challenge 012345678"), and should be displayed accordingly.
-	
-	The num_prompts argument indicates the number of values which
-	should be prompted for.  If num_prompts == 0, then the banner
-	contains an informational message which should be displayed to
-	the user.
-
-	The prompts argument contains an array describing the values
-	for which the user should be prompted.  The prompt member
-	indicates the prompt for each value ("Enter new
-	password"/"Enter it again", or "Challenge response").  The
-	hidden member is nonzero if the response should not be
-	displayed back to the user.  The reply member is a pointer to
-	krb5_data structure which has already been allocated.  The
-	prompter should fill in the structure with the NUL-terminated
-	response from the user.
-
-	If the response data does not fit, or if any other error
-	occurs, then the prompter function should return a non-zero
-	value which will be returned by the krb5_get_init_creds
-	function. Otherwise, zero should be returned.
-
-	The library function krb5_prompter_posix() implements
-	a prompter using a posix terminal for user in.  This function
-	does not use the data argument.
-
-If the start_time is zero, then the requested ticket will be valid
-beginning immediately.  Otherwise, the start_time indicates how far in
-the future the ticket should be postdated.
-
-If the in_tkt_service name is non-NULL, that principal name will be
-used as the server name for the initial ticket request.  The realm of
-the name specified will be ignored and will be set to the realm of the
-client name.  If no in_tkt_service name is specified,
-krbtgt/CLIENT-REALM@CLIENT-REALM will be used.
-
-For the rest of arguments, a configuration or library default will be
-used if no value is specified in the options structure.
-
-If a tkt_life is specified, that will be the lifetime of the ticket.
-The library default is 10 hours; there is no configuration variable
-(there should be, but it's not there now).
-
-If a renew_life is specified and non-zero, then the RENEWABLE option
-on the ticket will be set, and the value of the argument will be the
-the renewable lifetime.  The configuration variable [libdefaults]
-"renew_lifetime" is the renewable lifetime if none is passed in.  The
-library default is not to set the RENEWABLE option.
-
-If forwardable is specified, the FORWARDABLE option on the ticket will
-be set if and only if forwardable is non-zero.  The configuration
-variable [libdefaults] "forwardable" is used if no value is passed in.
-The option will be set if and only if the variable is "y", "yes",
-"true", "t", "1", or "on", case insensitive.  The library default is
-not to set the FORWARDABLE option.
-
-If proxiable is specified, the PROXIABLE option on the ticket will be
-set if and only if proxiable is non-zero.  The configuration variable
-[libdefaults] "proxiable" is used if no value is passed in.  The
-option will be set if and only if the variable is "y", "yes", "true",
-"t", "1", or "on", case insensitive.  The library default is not to
-set the PROXIABLE option.
-
-If etype_list is specified, it will be used as the list of desired
-encryption algorithms in the request.  The configuration variable
-[libdefaults] "default_tkt_enctypes" is used if no value is passed in.
-The library default is "des-cbc-md5 des-cbc-crc".
-
-If address_list is specified, it will be used as the list of addresses
-for which the ticket will be valid.  The library default is to use all
-local non-loopback addresses.  There is no configuration variable.
-
-If preauth_list is specified, it names preauth data types which will
-be included in the request.  The library default is to interact with
-the kdc to determine the required preauth types.  There is no
-configuration variable.
-
-If salt is specified, it specifies the salt which will be used when
-converting the password to a key.  The library default is to interact
-with the kdc to determine the correct salt.  There is no configuration
-variable.
-
-================================================================
-
-typedef struct _krb5_verify_init_creds_opt {
-    krb5_flags flags;
-    int ap_req_nofail;
-} krb5_verify_init_creds_opt;
-
-#define KRB5_VERIFY_INIT_CREDS_OPT_AP_REQ_NOFAIL	0x0001
-
-void krb5_verify_init_creds_opt_init(krb5_init_creds_opt *options);
-void krb5_verify_init_creds_opt_set_ap_req_nofail(krb5_init_creds_opt *options,
-						  int ap_req_nofail);
-
-krb5_error_code
-krb5_verify_init_creds(krb5_context context,
-		       krb5_creds *creds,
-		       krb5_principal ap_req_server,
-		       krb5_keytab ap_req_keytab,
-		       krb5_ccache *ccache,
-		       krb5_verify_init_creds_opt *options);
-
-This function will use the initial ticket in creds to make an AP_REQ
-and verify it to insure that the AS_REP has not been spoofed.
-
-If the ap_req_server name is non-NULL, then this service name will be
-used for the AP_REQ; otherwise, the default host key
-(host/hostname.domain@LOCAL-REALM) will be used.
-
-If ap_req_keytab is non-NULL, the service key for the verification
-will be read from that keytab; otherwise, the service key will be read
-from the default keytab. 
-
-If the service of the ticket in creds is the same as the service name
-for the AP_REQ, then this ticket will be used directly.  If the ticket
-is a tgt, then it will be used to obtain credentials for the service.
-Otherwise, the verification will fail, and return an error.
-
-Other failures of the AP_REQ verification may or may not be considered
-errors, as described below.
-
-If a pointer to a credential cache handle is specified, and the handle
-is NULL, a credential cache handle referring to all credentials
-obtained in the course of verifying the user will be returned.  In
-order to avoid potential setuid race conditions and other problems
-related to file system access, this handle will refer to a memory
-credential cache.  If the handle is non-NULL, then the credentials
-will be added to the existing ccache.  If the caller only wishes to
-verify the password and will not be doing any other kerberos
-functions, then a NULL pointer may be specified, and the credentials
-will be deleted before the function returns.
-
-If ap_req_nofail is specified, then failures of the AP_REQ
-verification are considered errors if and only if ap_req_nofail is
-non-zero.
-
-Whether or not AP_REQ validation is performed and what failures mean
-depends on these inputs:
-
- A) The appropriate keytab exists and contains the named key.
-
- B) An AP_REQ request to the kdc succeeds, and the resulting AP_REQ
-can be decrypted and verified.
-
- C) The administrator has specified in a configuration file that
-AP_REQ validation must succeed.  This is basically a paranoid bit, and
-can be overridden by the application based on a command line flag or
-other application-specific info.  This flag is especially useful if
-the admin is concerned that DNS might be spoofed while determining the
-host/FQDN name.  The configuration variable [libdefaults]
-"verify_ap_req_nofail" is used if no value is passed in.  The library
-default is not to set this option.
-
-Initial ticket verification will succeed if and only if:
-
- - A && B    or
- - !A && !C
-
-================================================================
-
-For illustrative purposes, here's the invocations I expect some
-programs will use.  Of course, error checking needs to be added.
-
-kinit:
-
-    /* Fill in client from the command line || existing ccache, and,
-       start_time, and options.{tkt_life,renew_life,forwardable,proxiable}
-       from the command line.  Some or all may remain unset. */
-
-    krb5_get_init_creds(context, &creds, client,
-			krb5_initial_prompter_posix, NULL,
-			start_time, NULL, &options);
-    krb5_cc_store_cred(context, ccache, &creds);
-    krb5_free_cred_contents(context, &creds);
-
-login:
-
-    krb5_get_init_creds(context, &creds, client,
-			krb5_initial_prompter_posix, NULL,
-			0, NULL, NULL);
-    krb5_verify_init_creds(context, &creds, NULL, NULL, &vcc, NULL);
-    /* setuid */
-    krb5_cc_store_cred(context, ccache, &creds);
-    krb5_cc_copy(context, vcc, ccache);
-    krb5_free_cred_contents(context, &creds);
-    krb5_cc_destroy(context, vcc);
-
-xdm:
-
-    krb5_get_initial_creds(context, &creds, client,
-			   krb5_initial_prompter_xt, (void *) &xtstuff,
-			   0, NULL, NULL);
-    krb5_verify_init_creds(context, &creds, NULL, NULL, &vcc, NULL);
-    /* setuid */
-    krb5_cc_store_cred(context, ccache, &creds);
-    krb5_free_cred_contents(context, &creds);
-    krb5_cc_copy(context, vcc, ccache);
-    krb5_cc_destroy(context, vcc);
-
-passwd:
-
-    krb5_init_creds_opt_init(&options);
-    krb5_init_creds_opt_set_tkt_life = 300;
-    krb5_get_initial_creds(context, &creds, client,
-			   krb5_initial_prompter_posix, NULL,
-			   0, "kadmin/changepw", &options);
-    /* change password */
-    krb5_free_cred_contents(context, &creds);
-
-pop3d (simple password validator when no user interation possible):
-
-    krb5_get_initial_creds(context, &creds, client,
-			   NULL, NULL, 0, NULL, NULL);
-    krb5_verify_init_creds(context, &creds, NULL, NULL, &vcc, NULL);
-    krb5_cc_destroy(context, vcc);
-
-================================================================
-
-password expiration has a subtlety.  When a password expires and is
-changed, there is a delay between when the master gets the new key
-(immediately), and the slaves (propogation interval).  So, when
-getting an in_tkt, if the password is expired, the request should be
-reissued to the master (this kind of sucks if you have SAM, oh well).
-If this says expired, too, then the password should be changed, and
-then the initial ticket request should be issued to the master again.
-If the master times out, then a message that the password has expired
-and cannot be changed due to the master being unreachable should be
-displayed.
-
-================================================================
-
-get_init_creds reads config stuff from:
-
-[libdefaults]
-	varname1 = defvalue
-	REALM = {
-		varname1 = value
-		varname2 = value
-	}
-
-typedef struct _krb5_get_init_creds_opt {
-    krb5_flags flags;
-    krb5_deltat tkt_life;	/* varname = "ticket_lifetime" */
-    krb5_deltat renew_life;	/* varname = "renew_lifetime" */
-    int forwardable;		/* varname = "forwardable" */
-    int proxiable;		/* varname = "proxiable" */
-    krb5_enctype *etype_list;	/* varname = "default_tkt_enctypes" */
-    int etype_list_length;
-    krb5_address **address_list; /* no varname */
-    krb5_preauthtype *preauth_list; /* no varname */
-    int preauth_list_length;
-    krb5_data *salt;
-} krb5_get_init_creds_opt;
-
-
diff --git a/crypto/heimdal/doc/install.texi b/crypto/heimdal/doc/install.texi
deleted file mode 100644
index 3d4b78d..0000000
--- a/crypto/heimdal/doc/install.texi
+++ /dev/null
@@ -1,107 +0,0 @@
-@c $Id: install.texi 16768 2006-02-27 12:26:49Z joda $
-
-@node Building and Installing, Setting up a realm, What is Kerberos?, Top
-@comment  node-name,  next,  previous,  up
-@chapter Building and Installing
-
-Heimdal uses GNU Autoconf to configure for specific hosts, and GNU
-Automake to manage makefiles. If this is new to you, the short
-instruction is to run the @code{configure} script in the top level
-directory, and when that finishes @code{make}.
-
-If you want to build the distribution in a different directory from the
-source directory, you will need a make that implements VPATH correctly,
-such as GNU make.
-
-You will need to build the distribution:
-
-@itemize @bullet
-@item
-A compiler that supports a ``loose'' ANSI C mode, such as @code{gcc}.
-@item
-lex or flex
-@item
-awk
-@item
-yacc or bison
-@item
-a socket library
-@item
-NDBM or Berkeley DB for building the server side.
-@end itemize
-
-When everything is built, you can install by doing @kbd{make
-install}. The default location for installation is @file{/usr/heimdal},
-but this can be changed by running @code{configure} with
-@samp{--prefix=/some/other/place}.
-
-If you need to change the default behaviour, configure understands the
-following options:
-
-@table @asis
-@item @kbd{--without-berkeley-db}
-DB is preferred before NDBM, but if you for some reason want to use NDBM
-instead, you can use this option.
-
-@item @kbd{--with-krb4=@file{dir}}
-Gives the location of Kerberos 4 libraries and headers. This enables
-Kerberos 4 support in the applications (telnet, rsh, popper, etc) and
-the KDC. It is automatically found if present under
-@file{/usr/athena}.  If you keep libraries and headers in different
-places, you can instead give the path to each with the
-@kbd{--with-krb4-lib=@file{dir}}, and
-@kbd{--with-krb4-include=@file{dir}} options.
-
-You will need a fairly recent version of our Kerberos 4 distribution for
-@code{rshd} and @code{popper} to support version 4 clients.
-
-@item @kbd{--enable-dce}
-Enables support for getting DCE credentials and tokens.  See the README
-files in @file{appl/dceutils} for more information.
-
-@item @kbd{--disable-otp}
-By default some of the application programs will build with support for
-one-time passwords (OTP).  Use this option to disable that support.
-
-@item @kbd{--enable-osfc2}
-Enable some C2 support for OSF/Digital Unix/Tru64.  Use this option if
-you are running your OSF operating system in C2 mode.
-
-@item @kbd{--with-readline=@file{dir}}
-Gives the path for the GNU Readline library, which will be used in some
-programs. If no readline library is found, the (simpler) editline
-library will be used instead.
-
-@item @kbd{--with-hesiod=@file{dir}}
-Enables hesiod support in push.
-
-@item @kbd{--enable-netinfo}
-Add support for using netinfo to lookup configuration information.
-Probably only useful (and working) on NextStep/Mac OS X.
-
-@item @kbd{--without-ipv6}
-Disable the IPv6 support.
-
-@item @kbd{--with-openldap}
-Compile Heimdal with support for storing the database in LDAP.  Requires
-OpenLDAP @url{http://www.openldap.org}.  See
-@url{http://www.padl.com/Research/Heimdal.html} for more information.
-
-@item @kbd{--enable-bigendian}
-@item @kbd{--enable-littleendian}
-Normally, the build process will figure out by itself if the machine is
-big or little endian.  It might fail in some cases when
-cross-compiling.  If it does fail to figure it out, use the relevant of
-these two options.
-
-@item @kbd{--with-mips-abi=@var{abi}}
-On Irix there are three different ABIs that can be used (@samp{32},
-@samp{n32}, or @samp{64}).  This option allows you to override the
-automatic selection.
-
-@item @kbd{--disable-mmap}
-Do not use the mmap system call.  Normally, configure detects if there
-is a working mmap and it is only used if there is one.  Only try this
-option if it fails to work anyhow.
-
-@end table
diff --git a/crypto/heimdal/doc/intro.texi b/crypto/heimdal/doc/intro.texi
deleted file mode 100644
index e1a96e1..0000000
--- a/crypto/heimdal/doc/intro.texi
+++ /dev/null
@@ -1,99 +0,0 @@
-@c $Id: intro.texi 22509 2008-01-23 18:28:01Z lha $
-
-@node Introduction, What is Kerberos?, Top, Top
-@c @node Introduction, What is Kerberos?, Top, Top
-@comment  node-name,  next,  previous,  up
-@chapter Introduction
-
-@heading What is Heimdal?
-
-Heimdal is a free implementation of Kerberos 5. The goals are to:
-
-@itemize @bullet
-@item
-have an implementation that can be freely used by anyone
-@item
-be protocol compatible with existing implementations and, if not in
-conflict, with RFC 4120 (and any future updated RFC). RFC 4120
-replaced RFC 1510.
-@item
-be reasonably compatible with the M.I.T Kerberos V5 API
-@item
-have support for Kerberos V5 over GSS-API (RFC1964)
-@item
-include the most important and useful application programs (rsh, telnet,
-popper, etc.)
-@item
-include enough backwards compatibility with Kerberos V4
-@end itemize
-
-@heading Status
-
-Heimdal has the following features (this does not mean any of this
-works):
-
-@itemize @bullet
-@item
-a stub generator and a library to encode/decode/whatever ASN.1/DER
-stuff
-@item
-a @code{libkrb5} library that should be possible to get to work with
-simple applications
-@item
-a GSS-API library
-@item
-@file{kinit}, @file{klist}, @file{kdestroy}
-@item
-@file{telnet}, @file{telnetd}
-@item
-@file{rsh}, @file{rshd}
-@item
-@file{popper}, @file{push} (a movemail equivalent)
-@item
-@file{ftp}, and @file{ftpd}
-@item
-a library @file{libkafs} for authenticating to AFS and a program
-@file{afslog} that uses it
-@item
-some simple test programs
-@item
-a KDC that supports most things; optionally, it may also support
-Kerberos V4 and kaserver,
-@item
-simple programs for distributing databases between a KDC master and
-slaves
-@item
-a password changing daemon @file{kpasswdd}, library functions for
-changing passwords and a simple client
-@item
-some kind of administration system
-@item
-Kerberos V4 support in many of the applications.
-@end itemize
-
-@heading Bug reports
-
-If you find bugs in this software, make sure it is a genuine bug and not
-just a part of the code that isn't implemented.
-
-Bug reports should be sent to @email{heimdal-bugs@@h5l.org}. Please
-include information on what machine and operating system (including
-version) you are running, what you are trying to do, what happens, what
-you think should have happened, an example for us to repeat, the output
-you get when trying the example, and a patch for the problem if you have
-one. Please make any patches with @code{diff -u} or @code{diff -c}.
-
-Suggestions, comments and other non bug reports are also welcome.
-
-@heading Mailing list
-
-There are two mailing lists with talk about
-Heimdal. @email{heimdal-announce@@sics.se} is a low-volume announcement
-list, while @email{heimdal-discuss@@sics.se} is for general discussion.
-Send a message to @email{majordomo@@sics.se} to subscribe.
-
-@heading Heimdal source code, binaries and the manual
-
-The source code for heimdal, links to binaries and the manual (this
-document) can be found on our web-page at
-@url{http://www.pdc.kth.se/heimdal/}.
diff --git a/crypto/heimdal/doc/kerberos4.texi b/crypto/heimdal/doc/kerberos4.texi
deleted file mode 100644
index fb490f3..0000000
--- a/crypto/heimdal/doc/kerberos4.texi
+++ /dev/null
@@ -1,226 +0,0 @@
-@c $Id: kerberos4.texi 16370 2005-12-12 12:11:51Z lha $
-
-@node Kerberos 4 issues, Windows 2000 compatability, Things in search for a better place, Top
-@comment  node-name,  next,  previous,  up
-@chapter Kerberos 4 issues
-
-The KDC has built-in version 4 support. It is not enabled by default,
-see setup how to set it up.
-
-The KDC will also have kaserver emulation and be able to handle
-AFS-clients that use @code{klog}.
-
-@menu
-* Principal conversion issues::  
-* Converting a version 4 database::  
-* kaserver::
-@end menu
-
-@node Principal conversion issues, Converting a version 4 database, Kerberos 4 issues, Kerberos 4 issues
-@section Principal conversion issues
-
-First, Kerberos 4 and Kerberos 5 principals are different. A version 4
-principal consists of a name, an instance, and a realm. A version 5
-principal has one or more components, and a realm (the terms ``name''
-and ``instance'' are still used, for the first and second component,
-respectively).    Also, in some cases the name of a version 4 principal
-differs from the first component of the corresponding version 5
-principal. One notable example is the ``host'' type principals, where
-the version 4 name is @samp{rcmd} (for ``remote command''), and the
-version 5 name is @samp{host}. For the class of principals that has a
-hostname as instance, there is an other major difference, Kerberos 4
-uses only the first component of the hostname, whereas Kerberos 5 uses
-the fully qualified hostname.
-
-Because of this it can be hard or impossible to correctly convert a
-version 4 principal to a version 5 principal @footnote{the other way is
-not always trivial either, but usually easier}. The biggest problem is
-to know if the conversion resulted in a valid principal. To give an
-example, suppose you want to convert the principal @samp{rcmd.foo}.
-
-The @samp{rcmd} name suggests that the instance is a hostname (even if
-there are exceptions to this rule). To correctly convert the instance
-@samp{foo} to a hostname, you have to know which host it is referring
-to. You can to this by either guessing (from the realm) which domain
-name to append, or you have to have a list of possible hostnames. In the
-simplest cases you can cover most principals with the first rule. If you
-have several domains sharing a single realm this will not usually
-work. If the exceptions are few you can probably come by with a lookup
-table for the exceptions.
-
-In a complex scenario you will need some kind of host lookup mechanism.
-Using DNS for this is tempting, but DNS is error prone, slow and unsafe
-@footnote{at least until secure DNS is commonly available}.
-
-Fortunately, the KDC has a trump on hand: it can easily tell if a
-principal exists in the database. The KDC will use
-@code{krb5_425_conv_principal_ext} to convert principals when handling
-to version 4 requests.
-
-@node Converting a version 4 database, kaserver , Principal conversion issues, Kerberos 4 issues
-@section Converting a version 4 database
-
-If you want to convert an existing version 4 database, the principal
-conversion issue arises too.
-
-If you decide to convert your database once and for all, you will only
-have to do this conversion once. It is also possible to run a version 5
-KDC as a slave to a version 4 KDC. In this case this conversion will
-happen every time the database is propagated.  When doing this
-conversion, there are a few things to look out for. If you have stale
-entries in the database, these entries will not be converted. This might
-be because these principals are not used anymore, or it might be just
-because the principal couldn't be converted.
-
-You might also see problems with a many-to-one mapping of
-principals. For instance, if you are using DNS lookups and you have two
-principals @samp{rcmd.foo} and @samp{rcmd.bar}, where `foo' is a CNAME
-for `bar', the resulting principals will be the same. Since the
-conversion function can't tell which is correct, these conflicts will
-have to be resolved manually.
-
-@subsection Conversion example
-
-Given the following set of hosts and services:
-
-@example
-foo.se          rcmd
-mail.foo.se     rcmd, pop
-ftp.bar.se      rcmd, ftp
-@end example
-
-you have a database that consists of the following principals:
-
-@samp{rcmd.foo}, @samp{rcmd.mail}, @samp{pop.mail}, @samp{rcmd.ftp}, and
-@samp{ftp.ftp}.
-
-lets say you also got these extra principals: @samp{rcmd.gone},
-@samp{rcmd.old-mail}, where @samp{gone.foo.se} was a machine that has
-now passed away, and @samp{old-mail.foo.se} was an old mail machine that
-is now a CNAME for @samp{mail.foo.se}.
-
-When you convert this database you want the following conversions to be
-done:
-@example
-rcmd.foo         host/foo.se
-rcmd.mail        host/mail.foo.se
-pop.mail         pop/mail.foo.se
-rcmd.ftp         host/ftp.bar.se
-ftp.ftp          ftp/ftp.bar.se
-rcmd.gone        @i{removed}
-rcmd.old-mail    @i{removed}
-@end example
-
-A @file{krb5.conf} that does this looks like:
-
-@example
-[realms]
-        FOO.SE = @{
-                v4_name_convert = @{
-                        host = @{
-                                ftp = ftp
-                                pop = pop
-                                rcmd = host
-                        @}
-                @}
-                v4_instance_convert = @{
-                        foo = foo.se
-                        ftp = ftp.bar.se
-                @}
-                default_domain = foo.se
-        @}
-@end example
-
-The @samp{v4_name_convert} section says which names should be considered
-having an instance consisting of a hostname, and it also says how the
-names should be converted (for instance @samp{rcmd} should be converted
-to @samp{host}). The @samp{v4_instance_convert} section says how a
-hostname should be qualified (this is just a hosts-file in
-disguise). Host-instances that aren't covered by
-@samp{v4_instance_convert} are qualified by appending the contents of
-the @samp{default_domain}.
-
-Actually, this example doesn't work. Or rather, it works to well. Since
-it has no way of knowing which hostnames are valid and which are not, it
-will happily convert @samp{rcmd.gone} to @samp{host/gone.foo.se}. This
-isn't a big problem, but if you have run your kerberos realm for a few
-years, chances are big that you have quite a few `junk' principals.
-
-If you don't want this you can remove the @samp{default_domain}
-statement, but then you will have to add entries for @emph{all} your hosts
-in the @samp{v4_instance_convert} section.
-
-Instead of doing this you can use DNS to convert instances. This is not
-a solution without problems, but it is probably easier than adding lots
-of static host entries. 
-
-To enable DNS lookup you should turn on @samp{v4_instance_resolve} in
-the @samp{[libdefaults]} section.
-
-@subsection Converting a database
-
-The database conversion is done with @samp{hprop}. You can run this
-command to propagate the database to the machine called
-@samp{slave-server} (which should be running a @samp{hpropd}).
-
-@example
-hprop --source=krb4-db --master-key=/.m slave-server
-@end example
-
-This command can also be to use for converting the v4 database on the
-server:
-
-@example
-hprop -n --source=krb4-db -d /var/kerberos/principal --master-key=/.m | hpropd -n
-@end example
-
-@section Version 4 Kadmin
-
-@samp{kadmind} can act as a version 4 kadmind, and you can do most
-operations, but with some restrictions (since the version 4 kadmin
-protocol is, lets say, very ad hoc.) One example is that it only passes
-des keys when creating principals and changing passwords (modern kpasswd
-clients do send the password, so it's possible to to password quality
-checks). Because of this you can only create principals with des keys,
-and you can't set any flags or do any other fancy stuff.
-
-To get this to work, you have to add another entry to inetd (since
-version 4 uses port 751, not 749).
-
-@emph{And then there are a many more things you can do; more on this in
-a later version of this manual. Until then, UTSL.}
-
-@node kaserver, , Converting a version 4 database, Kerberos 4 issues
-@section kaserver
-
-@subsection kaserver emulation
-
-The Heimdal kdc can emulate a kaserver. The kaserver is a Kerberos 4
-server with pre-authentication using Rx as the on-wire protocol. The kdc
-contains a minimalistic Rx implementation.
-
-There are three parts of the kaserver; KAA (Authentication), KAT (Ticket
-Granting), and KAM (Maintenance). The KAA interface and KAT interface
-both passes over DES encrypted data-blobs (just like the
-Kerberos-protocol) and thus do not need any other protection.  The KAM
-interface uses @code{rxkad} (Kerberos authentication layer for Rx) for
-security and data protection, and is used for example for changing
-passwords.  This part is not implemented in the kdc.
-
-Another difference between the ka-protocol and the Kerberos 4 protocol
-is that the pass-phrase is salted with the cellname in the @code{string to
-key} function in the ka-protocol, while in the Kerberos 4 protocol there
-is no salting of the password at all. To make sure AFS-compatible keys
-are added to each principals when they are created or their password are
-changed, @samp{afs3-salt} should be added to
-@samp{[kadmin]default_keys}.
-
-@subsection Transarc AFS Windows client
-
-The Transarc Windows client uses Kerberos 4 to obtain tokens, and thus
-does not need a kaserver. The Windows client assumes that the Kerberos
-server is on the same machine as the AFS-database server. If you do not
-like to do that you can add a small program that runs on the database
-servers that forward all kerberos requests to the real kerberos
-server. A program that does this is @code{krb-forward}
-(@url{ftp://ftp.stacken.kth.se/pub/projekts/krb-forward}).
diff --git a/crypto/heimdal/doc/krb5.din b/crypto/heimdal/doc/krb5.din
deleted file mode 100644
index 2af9947..0000000
--- a/crypto/heimdal/doc/krb5.din
+++ /dev/null
@@ -1,16 +0,0 @@
-# Doxyfile 1.5.3
-
-PROJECT_NAME           = Heimdal Kerberos 5 library
-PROJECT_NUMBER         = @PACKAGE_VERSION@
-OUTPUT_DIRECTORY       = @objdir@/krb5
-INPUT                  = @srcdir@/../lib/krb5
-
-WARN_IF_UNDOCUMENTED   = NO
-
-PERL_PATH              = /usr/bin/perl
-
-HTML_HEADER = "@srcdir@/header.html"
-HTML_FOOTER = "@srcdir@/footer.html"
-
-@INCLUDE = "@srcdir@/doxytmpl.dxy"
-
diff --git a/crypto/heimdal/doc/latin1.tex b/crypto/heimdal/doc/latin1.tex
deleted file mode 100644
index e683dd2..0000000
--- a/crypto/heimdal/doc/latin1.tex
+++ /dev/null
@@ -1,95 +0,0 @@
-% ISO Latin 1 (ISO 8859/1) encoding for Computer Modern fonts.
-% Jan Michael Rynning <jmr@nada.kth.se> 1990-10-12
-\def\inmathmode#1{\relax\ifmmode#1\else$#1$\fi}
-\global\catcode`\^^a0=\active \global\let^^a0=~		% no-break space
-\global\catcode`\^^a1=\active \global\def^^a1{!`}		% inverted exclamation mark
-\global\catcode`\^^a2=\active \global\def^^a2{{\rm\rlap/c}}	% cent sign
-\global\catcode`\^^a3=\active \global\def^^a3{{\it\$}}	% pound sign
-% currency sign, yen sign, broken bar
-\global\catcode`\^^a7=\active \global\let^^a7=\S		% section sign
-\global\catcode`\^^a8=\active \global\def^^a8{\"{}}		% diaeresis
-\global\catcode`\^^a9=\active \global\let^^a9=\copyright	% copyright sign
-% feminine ordinal indicator, left angle quotation mark
-\global\catcode`\^^ac=\active \global\def^^ac{\inmathmode\neg}% not sign
-\global\catcode`\^^ad=\active \global\let^^ad=\-		% soft hyphen
-% registered trade mark sign
-\global\catcode`\^^af=\active \global\def^^af{\={}}		% macron
-% ...
-\global\catcode`\^^b1=\active \global\def^^b1{\inmathmode\pm}	% plus minus
-\global\catcode`\^^b2=\active \global\def^^b2{\inmathmode{{^2}}}
-\global\catcode`\^^b3=\active \global\def^^b3{\inmathmode{{^3}}}
-\global\catcode`\^^b4=\active \global\def^^b4{\'{}}		% acute accent
-\global\catcode`\^^b5=\active \global\def^^b5{\inmathmode\mu}	% mu
-\global\catcode`\^^b6=\active \global\let^^b6=\P		% pilcroy
-\global\catcode`\^^b7=\active \global\def^^b7{\inmathmode{{\cdot}}}
-\global\catcode`\^^b8=\active \global\def^^b8{\c{}}		% cedilla
-\global\catcode`\^^b9=\active \global\def^^b9{\inmathmode{{^1}}}
-% ...
-\global\catcode`\^^bc=\active \global\def^^bc{\inmathmode{{1\over4}}}
-\global\catcode`\^^bd=\active \global\def^^bd{\inmathmode{{1\over2}}}
-\global\catcode`\^^be=\active \global\def^^be{\inmathmode{{3\over4}}}
-\global\catcode`\^^bf=\active \global\def^^bf{?`}		% inverted question mark
-\global\catcode`\^^c0=\active \global\def^^c0{\`A}
-\global\catcode`\^^c1=\active \global\def^^c1{\'A}
-\global\catcode`\^^c2=\active \global\def^^c2{\^A}
-\global\catcode`\^^c3=\active \global\def^^c3{\~A}
-\global\catcode`\^^c4=\active \global\def^^c4{\"A}		% capital a with diaeresis
-\global\catcode`\^^c5=\active \global\let^^c5=\AA		% capital a with ring above
-\global\catcode`\^^c6=\active \global\let^^c6=\AE
-\global\catcode`\^^c7=\active \global\def^^c7{\c C}
-\global\catcode`\^^c8=\active \global\def^^c8{\`E}
-\global\catcode`\^^c9=\active \global\def^^c9{\'E}
-\global\catcode`\^^ca=\active \global\def^^ca{\^E}
-\global\catcode`\^^cb=\active \global\def^^cb{\"E}
-\global\catcode`\^^cc=\active \global\def^^cc{\`I}
-\global\catcode`\^^cd=\active \global\def^^cd{\'I}
-\global\catcode`\^^ce=\active \global\def^^ce{\^I}
-\global\catcode`\^^cf=\active \global\def^^cf{\"I}
-% capital eth
-\global\catcode`\^^d1=\active \global\def^^d1{\~N}
-\global\catcode`\^^d2=\active \global\def^^d2{\`O}
-\global\catcode`\^^d3=\active \global\def^^d3{\'O}
-\global\catcode`\^^d4=\active \global\def^^d4{\^O}
-\global\catcode`\^^d5=\active \global\def^^d5{\~O}
-\global\catcode`\^^d6=\active \global\def^^d6{\"O}		% capital o with diaeresis
-\global\catcode`\^^d7=\active \global\def^^d7{\inmathmode\times}% multiplication sign
-\global\catcode`\^^d8=\active \global\let^^d8=\O
-\global\catcode`\^^d9=\active \global\def^^d9{\`U}
-\global\catcode`\^^da=\active \global\def^^da{\'U}
-\global\catcode`\^^db=\active \global\def^^db{\^U}
-\global\catcode`\^^dc=\active \global\def^^dc{\"U}
-\global\catcode`\^^dd=\active \global\def^^dd{\'Y}
-% capital thorn
-\global\catcode`\^^df=\active \global\def^^df{\ss}
-\global\catcode`\^^e0=\active \global\def^^e0{\`a}
-\global\catcode`\^^e1=\active \global\def^^e1{\'a}
-\global\catcode`\^^e2=\active \global\def^^e2{\^a}
-\global\catcode`\^^e3=\active \global\def^^e3{\~a}
-\global\catcode`\^^e4=\active \global\def^^e4{\"a}		% small a with diaeresis
-\global\catcode`\^^e5=\active \global\let^^e5=\aa		% small a with ring above
-\global\catcode`\^^e6=\active \global\let^^e6=\ae
-\global\catcode`\^^e7=\active \global\def^^e7{\c c}
-\global\catcode`\^^e8=\active \global\def^^e8{\`e}
-\global\catcode`\^^e9=\active \global\def^^e9{\'e}
-\global\catcode`\^^ea=\active \global\def^^ea{\^e}
-\global\catcode`\^^eb=\active \global\def^^eb{\"e}
-\global\catcode`\^^ec=\active \global\def^^ec{\`\i}
-\global\catcode`\^^ed=\active \global\def^^ed{\'\i}
-\global\catcode`\^^ee=\active \global\def^^ee{\^\i}
-\global\catcode`\^^ef=\active \global\def^^ef{\"\i}
-% small eth
-\global\catcode`\^^f1=\active \global\def^^f1{\~n}
-\global\catcode`\^^f2=\active \global\def^^f2{\`o}
-\global\catcode`\^^f3=\active \global\def^^f3{\'o}
-\global\catcode`\^^f4=\active \global\def^^f4{\^o}
-\global\catcode`\^^f5=\active \global\def^^f5{\~o}
-\global\catcode`\^^f6=\active \global\def^^f6{\"o}		% small o with diaeresis
-\global\catcode`\^^f7=\active \global\def^^f7{\inmathmode\div}% division sign
-\global\catcode`\^^f8=\active \global\let^^f8=\o
-\global\catcode`\^^f9=\active \global\def^^f9{\`u}
-\global\catcode`\^^fa=\active \global\def^^fa{\'u}
-\global\catcode`\^^fb=\active \global\def^^fb{\^u}
-\global\catcode`\^^fc=\active \global\def^^fc{\"u}
-\global\catcode`\^^fd=\active \global\def^^fd{\'y}
-% capital thorn
-\global\catcode`\^^ff=\active \global\def^^ff{\"y}
diff --git a/crypto/heimdal/doc/layman.asc b/crypto/heimdal/doc/layman.asc
deleted file mode 100644
index d4fbe64..0000000
--- a/crypto/heimdal/doc/layman.asc
+++ /dev/null
@@ -1,1855 +0,0 @@
-A Layman's Guide to a Subset of ASN.1, BER, and DER
-
-An RSA Laboratories Technical Note
-Burton S. Kaliski Jr.
-Revised November 1, 1993
-
-
-Supersedes June 3, 1991 version, which was also published as
-NIST/OSI Implementors' Workshop document SEC-SIG-91-17.
-PKCS documents are available by electronic mail to
-<pkcs@rsa.com>.
-
-Copyright (C) 1991-1993 RSA Laboratories, a division of RSA
-Data Security, Inc. License to copy this document is granted
-provided that it is identified as "RSA Data Security, Inc.
-Public-Key Cryptography Standards (PKCS)" in all material
-mentioning or referencing this document.
-003-903015-110-000-000
-
-
-Abstract. This note gives a layman's introduction to a
-subset of OSI's Abstract Syntax Notation One (ASN.1), Basic
-Encoding Rules (BER), and Distinguished Encoding Rules
-(DER). The particular purpose of this note is to provide
-background material sufficient for understanding and
-implementing the PKCS family of standards.
-
-
-1. Introduction
-
-It is a generally accepted design principle that abstraction
-is a key to managing software development. With abstraction,
-a designer can specify a part of a system without concern
-for how the part is actually implemented or represented.
-Such a practice leaves the implementation open; it
-simplifies the specification; and it makes it possible to
-state "axioms" about the part that can be proved when the
-part is implemented, and assumed when the part is employed
-in another, higher-level part. Abstraction is the hallmark
-of most modern software specifications.
-
-One of the most complex systems today, and one that also
-involves a great deal of abstraction, is Open Systems
-Interconnection (OSI, described in X.200). OSI is an
-internationally standardized architecture that governs the
-interconnection of computers from the physical layer up to
-the user application layer. Objects at higher layers are
-defined abstractly and intended to be implemented with
-objects at lower layers. For instance, a service at one
-layer may require transfer of certain abstract objects
-between computers; a lower layer may provide transfer
-services for strings of ones and zeroes, using encoding
-rules to transform the abstract objects into such strings.
-OSI is called an open system because it supports many
-different implementations of the services at each layer.
-
-OSI's method of specifying abstract objects is called ASN.1
-(Abstract Syntax Notation One, defined in X.208), and one
-set of rules for representing such objects as strings of
-ones and zeros is called the BER (Basic Encoding Rules,
-defined in X.209). ASN.1 is a flexible notation that allows
-one to define a variety data types, from simple types such
-as integers and bit strings to structured types such as sets
-and sequences, as well as complex types defined in terms of
-others. BER describes how to represent or encode values of
-each ASN.1 type as a string of eight-bit octets. There is
-generally more than one way to BER-encode a given value.
-Another set of rules, called the Distinguished Encoding
-Rules (DER), which is a subset of BER, gives a unique
-encoding to each ASN.1 value.
-
-The purpose of this note is to describe a subset of ASN.1,
-BER and DER sufficient to understand and implement one OSI-
-based application, RSA Data Security, Inc.'s Public-Key
-Cryptography Standards. The features described include an
-overview of ASN.1, BER, and DER and an abridged list of
-ASN.1 types and their BER and DER encodings. Sections 2-4
-give an overview of ASN.1, BER, and DER, in that order.
-Section 5 lists some ASN.1 types, giving their notation,
-specific encoding rules, examples, and comments about their
-application to PKCS. Section 6 concludes with an example,
-X.500 distinguished names.
-
-Advanced features of ASN.1, such as macros, are not
-described in this note, as they are not needed to implement
-PKCS. For information on the other features, and for more
-detail generally, the reader is referred to CCITT
-Recommendations X.208 and X.209, which define ASN.1 and BER.
-
-Terminology and notation. In this note, an octet is an eight-
-bit unsigned integer. Bit 8 of the octet is the most
-significant and bit 1 is the least significant.
-
-The following meta-syntax is used for in describing ASN.1
-notation:
-
-     BIT  monospace denotes literal characters in the type
-          and value notation; in examples, it generally
-          denotes an octet value in hexadecimal
-
-     n1   bold italics denotes a variable
-
-     []   bold square brackets indicate that a term is
-          optional
-
-     {}   bold braces group related terms
-
-     |    bold vertical bar delimits alternatives with a
-          group
-
-     ...  bold ellipsis indicates repeated occurrences
-
-     =    bold equals sign expresses terms as subterms
-
-
-2. Abstract Syntax Notation One
-
-Abstract Syntax Notation One, abbreviated ASN.1, is a
-notation for describing abstract types and values.
-
-In ASN.1, a type is a set of values. For some types, there
-are a finite number of values, and for other types there are
-an infinite number. A value of a given ASN.1 type is an
-element of the type's set. ASN.1 has four kinds of type:
-simple types, which are "atomic" and have no components;
-structured types, which have components; tagged types, which
-are derived from other types; and other types, which include
-the CHOICE type and the ANY type. Types and values can be
-given names with the ASN.1 assignment operator (::=) , and
-those names can be used in defining other types and values.
-
-Every ASN.1 type other than CHOICE and ANY has a tag, which
-consists of a class and a nonnegative tag number. ASN.1
-types are abstractly the same if and only if their tag
-numbers are the same. In other words, the name of an ASN.1
-type does not affect its abstract meaning, only the tag
-does. There are four classes of tag:
-
-     Universal, for types whose meaning is the same in all
-          applications; these types are only defined in
-          X.208.
-
-     Application, for types whose meaning is specific to an
-          application, such as X.500 directory services;
-          types in two different applications may have the
-          same application-specific tag and different
-          meanings.
-
-     Private, for types whose meaning is specific to a given
-          enterprise.
-
-     Context-specific, for types whose meaning is specific
-          to a given structured type; context-specific tags
-          are used to distinguish between component types
-          with the same underlying tag within the context of
-          a given structured type, and component types in
-          two different structured types may have the same
-          tag and different meanings.
-
-The types with universal tags are defined in X.208, which
-also gives the types' universal tag numbers. Types with
-other tags are defined in many places, and are always
-obtained by implicit or explicit tagging (see Section 2.3).
-Table 1 lists some ASN.1 types and their universal-class
-tags.
-
-    Type                     Tag number     Tag number
-                             (decimal)      (hexadecimal)
-    INTEGER                  2              02
-    BIT STRING               3              03
-    OCTET STRING             4              04
-    NULL                     5              05
-    OBJECT IDENTIFIER        6              06
-    SEQUENCE and SEQUENCE OF 16             10
-    SET and SET OF           17             11
-    PrintableString          19             13
-    T61String                20             14
-    IA5String                22             16
-    UTCTime                  23             17
-
-     Table 1. Some types and their universal-class tags.
-
-ASN.1 types and values are expressed in a flexible,
-programming-language-like notation, with the following
-special rules:
-
-     o    Layout is not significant; multiple spaces and
-          line breaks can be considered as a single space.
-
-     o    Comments are delimited by pairs of hyphens (--),
-          or a pair of hyphens and a line break.
-
-     o    Identifiers (names of values and fields) and type
-          references (names of types) consist of upper- and
-          lower-case letters, digits, hyphens, and spaces;
-          identifiers begin with lower-case letters; type
-          references begin with upper-case letters.
-
-The following four subsections give an overview of simple
-types, structured types, implicitly and explicitly tagged
-types, and other types. Section 5 describes specific types
-in more detail.
-
-
-2.1 Simple types
-
-Simple types are those not consisting of components; they
-are the "atomic" types. ASN.1 defines several; the types
-that are relevant to the PKCS standards are the following:
-
-     BIT STRING, an arbitrary string of bits (ones and
-          zeroes).
-
-     IA5String, an arbitrary string of IA5 (ASCII)
-          characters.
-
-     INTEGER, an arbitrary integer.
-
-     NULL, a null value.
-
-     OBJECT IDENTIFIER, an object identifier, which is a
-          sequence of integer components that identify an
-          object such as an algorithm or attribute type.
-
-     OCTET STRING, an arbitrary string of octets (eight-bit
-          values).
-
-     PrintableString, an arbitrary string of printable
-          characters.
-
-     T61String, an arbitrary string of T.61 (eight-bit)
-          characters.
-
-     UTCTime, a "coordinated universal time" or Greenwich
-          Mean Time (GMT) value.
-
-Simple types fall into two categories: string types and non-
-string types. BIT STRING, IA5String, OCTET STRING,
-PrintableString, T61String, and UTCTime are string types.
-
-String types can be viewed, for the purposes of encoding, as
-consisting of components, where the components are
-substrings. This view allows one to encode a value whose
-length is not known in advance (e.g., an octet string value
-input from a file stream) with a constructed, indefinite-
-length encoding (see Section 3).
-
-The string types can be given size constraints limiting the
-length of values.
-
-
-2.2 Structured types
-
-Structured types are those consisting of components. ASN.1
-defines four, all of which are relevant to the PKCS
-standards:
-
-     SEQUENCE, an ordered collection of one or more types.
-
-     SEQUENCE OF, an ordered collection of zero or more
-          occurrences of a given type.
-
-     SET, an unordered collection of one or more types.
-
-     SET OF, an unordered collection of zero or more
-          occurrences of a given type.
-
-The structured types can have optional components, possibly
-with default values.
-
-
-2.3 Implicitly and explicitly tagged types
-
-Tagging is useful to distinguish types within an
-application; it is also commonly used to distinguish
-component types within a structured type. For instance,
-optional components of a SET or SEQUENCE type are typically
-given distinct context-specific tags to avoid ambiguity.
-
-There are two ways to tag a type: implicitly and explicitly.
-
-Implicitly tagged types are derived from other types by
-changing the tag of the underlying type. Implicit tagging is
-denoted by the ASN.1 keywords [class number] IMPLICIT (see
-Section 5.1).
-
-Explicitly tagged types are derived from other types by
-adding an outer tag to the underlying type. In effect,
-explicitly tagged types are structured types consisting of
-one component, the underlying type. Explicit tagging is
-denoted by the ASN.1 keywords [class number] EXPLICIT (see
-Section 5.2).
-
-The keyword [class number] alone is the same as explicit
-tagging, except when the "module" in which the ASN.1 type is
-defined has implicit tagging by default. ("Modules" are
-among the advanced features not described in this note.)
-
-For purposes of encoding, an implicitly tagged type is
-considered the same as the underlying type, except that the
-tag is different. An explicitly tagged type is considered
-like a structured type with one component, the underlying
-type. Implicit tags result in shorter encodings, but
-explicit tags may be necessary to avoid ambiguity if the tag
-of the underlying type is indeterminate (e.g., the
-underlying type is CHOICE or ANY).
-
-
-2.4 Other types
-
-Other types in ASN.1 include the CHOICE and ANY types. The
-CHOICE type denotes a union of one or more alternatives; the
-ANY type denotes an arbitrary value of an arbitrary type,
-where the arbitrary type is possibly defined in the
-registration of an object identifier or integer value.
-
-
-3. Basic Encoding Rules
-
-The Basic Encoding Rules for ASN.1, abbreviated BER, give
-one or more ways to represent any ASN.1 value as an octet
-string. (There are certainly other ways to represent ASN.1
-values, but BER is the standard for interchanging such
-values in OSI.)
-
-There are three methods to encode an ASN.1 value under BER,
-the choice of which depends on the type of value and whether
-the length of the value is known. The three methods are
-primitive, definite-length encoding; constructed, definite-
-length encoding; and constructed, indefinite-length
-encoding. Simple non-string types employ the primitive,
-definite-length method; structured types employ either of
-the constructed methods; and simple string types employ any
-of the methods, depending on whether the length of the value
-is known. Types derived by implicit tagging employ the
-method of the underlying type and types derived by explicit
-tagging employ the constructed methods.
-
-In each method, the BER encoding has three or four parts:
-
-     Identifier octets. These identify the class and tag
-          number of the ASN.1 value, and indicate whether
-          the method is primitive or constructed.
-
-     Length octets. For the definite-length methods, these
-          give the number of contents octets. For the
-          constructed, indefinite-length method, these
-          indicate that the length is indefinite.
-
-     Contents octets. For the primitive, definite-length
-          method, these give a concrete representation of
-          the  value. For the constructed methods, these
-          give the concatenation of the BER encodings of the
-          components of the value.
-
-     End-of-contents octets. For the constructed, indefinite-
-          length method, these denote the end of the
-          contents. For the other methods, these are absent.
-
-The three methods of encoding are described in the following
-sections.
-
-
-3.1 Primitive, definite-length method
-
-This method applies to simple types and types derived from
-simple types by implicit tagging. It requires that the
-length of the value be known in advance. The parts of the
-BER encoding are as follows:
-
-Identifier octets. There are two forms: low tag number (for
-tag numbers between 0 and 30) and high tag number (for tag
-numbers 31 and greater).
-
-     Low-tag-number form. One octet. Bits 8 and 7 specify
-          the class (see Table 2), bit 6 has value "0,"
-          indicating that the encoding is primitive, and
-          bits 5-1 give the tag number.
-
-                  Class            Bit  Bit
-                                   8    7
-                  universal        0    0
-                  application      0    1
-                  context-specific 1    0
-                  private          1    1
-
-        Table 2. Class encoding in identifier octets.
-
-     High-tag-number form. Two or more octets. First octet
-          is as in low-tag-number form, except that bits 5-1
-          all have value "1." Second and following octets
-          give the tag number, base 128, most significant
-          digit first, with as few digits as possible, and
-          with the bit 8 of each octet except the last set
-          to "1."
-
-Length octets. There are two forms: short (for lengths
-between 0 and 127), and long definite (for lengths between 0
-and 21008-1).
-
-     Short form. One octet. Bit 8 has value "0" and bits 7-1
-          give the length.
-
-     Long form. Two to 127 octets. Bit 8 of first octet has
-          value "1" and bits 7-1 give the number of
-          additional length octets. Second and following
-          octets give the length, base 256, most significant
-          digit first.
-
-Contents octets. These give a concrete representation of the
-value (or the value of the underlying type, if the type is
-derived by implicit tagging). Details for particular types
-are given in Section 5.
-
-
-3.2 Constructed, definite-length method
-
-This method applies to simple string types, structured
-types, types derived simple string types and structured
-types by implicit tagging, and types derived from anything
-by explicit tagging. It requires that the length of the
-value be known in advance. The parts of the BER encoding are
-as follows:
-
-Identifier octets. As described in Section 3.1, except that
-bit 6 has value "1," indicating that the encoding is
-constructed.
-
-Length octets. As described in Section 3.1.
-
-Contents octets. The concatenation of the BER encodings of
-the components of the value:
-
-     o    For simple string types and types derived from
-          them by implicit tagging, the concatenation of the
-          BER encodings of consecutive substrings of the
-          value (underlying value for implicit tagging).
-
-     o    For structured types and types derived from them
-          by implicit tagging, the concatenation of the BER
-          encodings of components of the value (underlying
-          value for implicit tagging).
-
-     o    For types derived from anything by explicit
-          tagging, the BER encoding of the underlying value.
-
-Details for particular types are given in Section 5.
-
-
-3.3 Constructed, indefinite-length method
-
-This method applies to simple string types, structured
-types, types derived simple string types and structured
-types by implicit tagging, and types derived from anything
-by explicit tagging. It does not require that the length of
-the value be known in advance. The parts of the BER encoding
-are as follows:
-
-Identifier octets. As described in Section 3.2.
-
-Length octets. One octet, 80.
-
-Contents octets. As described in Section 3.2.
-
-End-of-contents octets. Two octets, 00 00.
-
-Since the end-of-contents octets appear where an ordinary
-BER encoding might be expected (e.g., in the contents octets
-of a sequence value), the 00 and 00 appear as identifier and
-length octets, respectively. Thus the end-of-contents octets
-is really the primitive, definite-length encoding of a value
-with universal class, tag number 0, and length 0.
-
-
-4. Distinguished Encoding Rules
-
-The Distinguished Encoding Rules for ASN.1, abbreviated DER,
-are a subset of BER, and give exactly one way to represent
-any ASN.1 value as an octet string. DER is intended for
-applications in which a unique octet string encoding is
-needed, as is the case when a digital signature is computed
-on an ASN.1 value. DER is defined in Section 8.7 of X.509.
-
-DER adds the following restrictions to the rules given in
-Section 3:
-
-     1.   When the length is between 0 and 127, the short
-          form of length must be used
-
-     2.   When the length is 128 or greater, the long form
-          of length must be used, and the length must be
-          encoded in the minimum number of octets.
-
-     3.   For simple string types and implicitly tagged
-          types derived from simple string types, the
-          primitive, definite-length method must be
-          employed.
-
-     4.   For structured types, implicitly tagged types
-          derived from structured types, and explicitly
-          tagged types derived from anything, the
-          constructed, definite-length method must be
-          employed.
-
-Other restrictions are defined for particular types (such as
-BIT STRING, SEQUENCE, SET, and SET OF), and can be found in
-Section 5.
-
-
-5. Notation and encodings for some types
-
-This section gives the notation for some ASN.1 types and
-describes how to encode values of those types under both BER
-and DER.
-
-The types described are those presented in Section 2. They
-are listed alphabetically here.
-
-Each description includes ASN.1 notation, BER encoding, and
-DER encoding. The focus of the encodings is primarily on the
-contents octets; the tag and length octets follow Sections 3
-and 4. The descriptions also explain where each type is used
-in PKCS and related standards. ASN.1 notation is generally
-only for types, although for the type OBJECT IDENTIFIER,
-value notation is given as well.
-
-
-5.1 Implicitly tagged types
-
-An implicitly tagged type is a type derived from another
-type by changing the tag of the underlying type.
-
-Implicit tagging is used for optional SEQUENCE components
-with underlying type other than ANY throughout PKCS, and for
-the extendedCertificate alternative of PKCS #7's
-ExtendedCertificateOrCertificate type.
-
-ASN.1 notation:
-
-[[class] number] IMPLICIT Type
-
-class = UNIVERSAL  |  APPLICATION  |  PRIVATE
-
-where Type is a type, class is an optional class name, and
-number is the tag number within the class, a nonnegative
-integer.
-
-In ASN.1 "modules" whose default tagging method is implicit
-tagging, the notation [[class] number] Type is also
-acceptable, and the keyword IMPLICIT is implied. (See
-Section 2.3.) For definitions stated outside a module, the
-explicit inclusion of the keyword IMPLICIT is preferable to
-prevent ambiguity.
-
-If the class name is absent, then the tag is context-
-specific. Context-specific tags can only appear in a
-component of a structured or CHOICE type.
-
-Example: PKCS #8's PrivateKeyInfo type has an optional
-attributes component with an implicit, context-specific tag:
-
-PrivateKeyInfo ::= SEQUENCE {
-  version Version,
-  privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
-  privateKey PrivateKey,
-  attributes [0] IMPLICIT Attributes OPTIONAL }
-
-Here the underlying type is Attributes, the class is absent
-(i.e., context-specific), and the tag number within the
-class is 0.
-
-BER encoding. Primitive or constructed, depending on the
-underlying type. Contents octets are as for the BER encoding
-of the underlying value.
-
-Example: The BER encoding of the attributes component of a
-PrivateKeyInfo value is as follows:
-
-     o    the identifier octets are 80 if the underlying
-          Attributes value has a primitive BER encoding and
-          a0 if the underlying Attributes value has a
-          constructed BER encoding
-
-     o    the length and contents octets are the same as the
-          length and contents octets of the BER encoding of
-          the underlying Attributes value
-
-DER encoding. Primitive or constructed, depending on the
-underlying type. Contents octets are as for the DER encoding
-of the underlying value.
-
-
-5.2 Explicitly tagged types
-
-Explicit tagging denotes a type derived from another type by
-adding an outer tag to the underlying type.
-
-Explicit tagging is used for optional SEQUENCE components
-with underlying type ANY throughout PKCS, and for the
-version component of X.509's Certificate type.
-
-ASN.1 notation:
-
-[[class] number] EXPLICIT Type
-
-class = UNIVERSAL  |  APPLICATION  |  PRIVATE
-
-where Type is a type, class is an optional class name, and
-number is the tag number within the class, a nonnegative
-integer.
-
-If the class name is absent, then the tag is context-
-specific. Context-specific tags can only appear in a
-component of a SEQUENCE, SET or CHOICE type.
-
-In ASN.1 "modules" whose default tagging method is explicit
-tagging, the notation [[class] number] Type is also
-acceptable, and the keyword EXPLICIT is implied. (See
-Section 2.3.) For definitions stated outside a module, the
-explicit inclusion of the keyword EXPLICIT is preferable to
-prevent ambiguity.
-
-Example 1: PKCS #7's ContentInfo type has an optional
-content component with an explicit, context-specific tag:
-
-ContentInfo ::= SEQUENCE {
-  contentType ContentType,
-  content
-    [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }
-
-Here the underlying type is ANY DEFINED BY contentType, the
-class is absent (i.e., context-specific), and the tag number
-within the class is 0.
-
-Example 2: X.509's Certificate type has a version component
-with an explicit, context-specific tag, where the EXPLICIT
-keyword is omitted:
-
-Certificate ::= ...
-  version [0] Version DEFAULT v1988,
-...
-
-The tag is explicit because the default tagging method for
-the ASN.1 "module" in X.509 that defines the Certificate
-type is explicit tagging.
-
-BER encoding. Constructed. Contents octets are the BER
-encoding of the underlying value.
-
-Example: the BER encoding of the content component of a
-ContentInfo value is as follows:
-
-     o    identifier octets are a0
-
-     o    length octets represent the length of the BER
-          encoding of the underlying ANY DEFINED BY
-          contentType value
-
-     o    contents octets are the BER encoding of the
-          underlying ANY DEFINED BY contentType value
-
-DER encoding. Constructed. Contents octets are the DER
-encoding of the underlying value.
-
-
-5.3 ANY
-
-The ANY type denotes an arbitrary value of an arbitrary
-type, where the arbitrary type is possibly defined in the
-registration of an object identifier or associated with an
-integer index.
-
-The ANY type is used for content of a particular content
-type in PKCS #7's ContentInfo type, for parameters of a
-particular algorithm in X.509's AlgorithmIdentifier type,
-and for attribute values in X.501's Attribute and
-AttributeValueAssertion types. The Attribute type is used by
-PKCS #6, #7, #8, #9 and #10, and the AttributeValueAssertion
-type is used in X.501 distinguished names.
-
-ASN.1 notation:
-
-ANY [DEFINED BY identifier]
-
-where identifier is an optional identifier.
-
-In the ANY form, the actual type is indeterminate.
-
-The ANY DEFINED BY identifier form can only appear in a
-component of a SEQUENCE or SET type for which identifier
-identifies some other component, and that other component
-has type INTEGER or OBJECT IDENTIFIER (or a type derived
-from either of those by tagging). In that form, the actual
-type is determined by the value of the other component,
-either in the registration of the object identifier value,
-or in a table of integer values.
-
-Example: X.509's AlgorithmIdentifier type has a component of
-type ANY:
-
-AlgorithmIdentifier ::= SEQUENCE {
-  algorithm OBJECT IDENTIFIER,
-  parameters ANY DEFINED BY algorithm OPTIONAL }
-
-Here the actual type of the parameter component depends on
-the value of the algorithm component. The actual type would
-be defined in the registration of object identifier values
-for the algorithm component.
-
-BER encoding. Same as the BER encoding of the actual value.
-
-Example: The BER encoding of the value of the parameter
-component is the BER encoding of the value of the actual
-type as defined in the registration of object identifier
-values for the algorithm component.
-
-DER encoding. Same as the DER encoding of the actual value.
-
-
-5.4 BIT STRING
-
-The BIT STRING type denotes an arbitrary string of bits
-(ones and zeroes). A BIT STRING value can have any length,
-including zero. This type is a string type.
-
-The BIT STRING type is used for digital signatures on
-extended certificates in PKCS #6's ExtendedCertificate type,
-for digital signatures on certificates in X.509's
-Certificate type, and for public keys in certificates in
-X.509's SubjectPublicKeyInfo type.
-
-ASN.1 notation:
-
-BIT STRING
-
-Example: X.509's SubjectPublicKeyInfo type has a component
-of type BIT STRING:
-
-SubjectPublicKeyInfo ::= SEQUENCE {
-  algorithm AlgorithmIdentifier,
-  publicKey BIT STRING }
-
-BER encoding. Primitive or constructed. In a primitive
-encoding, the first contents octet gives the number of bits
-by which the length of the bit string is less than the next
-multiple of eight (this is called the "number of unused
-bits"). The second and following contents octets give the
-value of the bit string, converted to an octet string. The
-conversion process is as follows:
-
-     1.   The bit string is padded after the last bit with
-          zero to seven bits of any value to make the length
-          of the bit string a multiple of eight. If the
-          length of the bit string is a multiple of eight
-          already, no padding is done.
-
-     2.   The padded bit string is divided into octets. The
-          first eight bits of the padded bit string become
-          the first octet, bit 8 to bit 1, and so on through
-          the last eight bits of the padded bit string.
-
-In a constructed encoding, the contents octets give the
-concatenation of the BER encodings of consecutive substrings
-of the bit string, where each substring except the last has
-a length that is a multiple of eight bits.
-
-Example: The BER encoding of the BIT STRING value
-"011011100101110111" can be any of the following, among
-others, depending on the choice of padding bits, the form of
-length octets, and whether the encoding is primitive or
-constructed:
-
-03 04 06 6e 5d c0                               DER encoding
-
-03 04 06 6e 5d e0                       padded with "100000"
-
-03 81 04 06 6e 5d c0              long form of length octets
-
-23 09        constructed encoding: "0110111001011101" + "11"
-   03 03 00 6e 5d
-   03 02 06 c0
-
-DER encoding. Primitive. The contents octects are as for a
-primitive BER encoding, except that the bit string is padded
-with zero-valued bits.
-
-Example: The DER encoding of the BIT STRING value
-"011011100101110111" is
-
-03 04 06 6e 5d c0
-
-
-5.5 CHOICE
-
-The CHOICE type denotes a union of one or more alternatives.
-
-The CHOICE type is used to represent the union of an
-extended certificate and an X.509 certificate in PKCS #7's
-ExtendedCertificateOrCertificate type.
-
-ASN.1 notation:
-
-CHOICE {
-  [identifier1] Type1,
-  ...,
-  [identifiern] Typen }
-
-where identifier1 , ..., identifiern are optional, distinct
-identifiers for the alternatives, and Type1, ..., Typen are
-the types of the alternatives. The identifiers are primarily
-for documentation; they do not affect values of the type or
-their encodings in any way.
-
-The types must have distinct tags. This requirement is
-typically satisfied with explicit or implicit tagging on
-some of the alternatives.
-
-Example: PKCS #7's ExtendedCertificateOrCertificate type is
-a CHOICE type:
-
-ExtendedCertificateOrCertificate ::= CHOICE {
-  certificate Certificate, -- X.509
-  extendedCertificate [0] IMPLICIT ExtendedCertificate
-}
-
-Here the identifiers for the alternatives are certificate
-and extendedCertificate, and the types of the alternatives
-are Certificate and [0] IMPLICIT ExtendedCertificate.
-
-BER encoding. Same as the BER encoding of the chosen
-alternative. The fact that the alternatives have distinct
-tags makes it possible to distinguish between their BER
-encodings.
-
-Example: The identifier octets for the BER encoding are 30
-if the chosen alternative is certificate, and a0 if the
-chosen alternative is extendedCertificate.
-
-DER encoding. Same as the DER encoding of the chosen
-alternative.
-
-
-5.6 IA5String
-
-The IA5String type denotes an arbtrary string of IA5
-characters. IA5 stands for International Alphabet 5, which
-is the same as ASCII. The character set includes non-
-printing control characters. An IA5String value can have any
-length, including zero. This type is a string type.
-
-The IA5String type is used in PKCS #9's electronic-mail
-address, unstructured-name, and unstructured-address
-attributes.
-
-ASN.1 notation:
-
-IA5String
-
-BER encoding. Primitive or constructed. In a primitive
-encoding, the contents octets give the characters in the IA5
-string, encoded in ASCII. In a constructed encoding, the
-contents octets give the concatenation of the BER encodings
-of consecutive substrings of the IA5 string.
-
-Example: The BER encoding of the IA5String value
-"test1@rsa.com" can be any of the following, among others,
-depending on the form of length octets and whether the
-encoding is primitive or constructed:
-
-16 0d 74 65 73 74 31 40 72 73 61 2e 63 6f 6d DER encoding
-
-16 81 0d                       long form of length octets
-   74 65 73 74 31 40 72 73 61 2e 63 6f 6d
-
-36 13     constructed encoding: "test1" + "@" + "rsa.com"
-   16 05 74 65 73 74 31
-   16 01 40
-   16 07 72 73 61 2e 63 6f 6d
-
-DER encoding. Primitive. Contents octets are as for a
-primitive BER encoding.
-
-Example: The DER encoding of the IA5String value
-"test1@rsa.com" is
-
-16 0d 74 65 73 74 31 40 72 73 61 2e 63 6f 6d
-
-
-5.7 INTEGER
-
-The INTEGER type denotes an arbitrary integer. INTEGER
-values can be positive, negative, or zero, and can have any
-magnitude.
-
-The INTEGER type is used for version numbers throughout
-PKCS, cryptographic values such as modulus, exponent, and
-primes in PKCS #1's RSAPublicKey and RSAPrivateKey types and
-PKCS #3's DHParameter type, a message-digest iteration count
-in PKCS #5's PBEParameter type, and version numbers and
-serial numbers in X.509's Certificate type.
-
-ASN.1 notation:
-
-INTEGER [{ identifier1(value1) ... identifiern(valuen) }]
-
-where identifier1, ..., identifiern are optional distinct
-identifiers and value1, ..., valuen are optional integer
-values. The identifiers, when present, are associated with
-values of the type.
-
-Example: X.509's Version type is an INTEGER type with
-identified values:
-
-Version ::= INTEGER { v1988(0) }
-
-The identifier v1988 is associated with the value 0. X.509's
-Certificate type uses the identifier v1988 to give a default
-value of 0 for the version component:
-
-Certificate ::= ...
-  version Version DEFAULT v1988,
-...
-
-BER encoding. Primitive. Contents octets give the value of
-the integer, base 256, in two's complement form, most
-significant digit first, with the minimum number of octets.
-The value 0 is encoded as a single 00 octet.
-
-Some example BER encodings (which also happen to be DER
-encodings) are given in Table 3.
-
-                    Integer   BER encoding
-                    value
-                    0         02 01 00
-                    127       02 01 7F
-                    128       02 02 00 80
-                    256       02 02 01 00
-                    -128      02 01 80
-                    -129      02 02 FF 7F
-
-      Table 3. Example BER encodings of INTEGER values.
-
-DER encoding. Primitive. Contents octets are as for a
-primitive BER encoding.
-
-
-5.8 NULL
-
-The NULL type denotes a null value.
-
-The NULL type is used for algorithm parameters in several
-places in PKCS.
-
-ASN.1 notation:
-
-NULL
-
-BER encoding. Primitive. Contents octets are empty.
-
-Example: The BER encoding of a NULL value can be either of
-the following, as well as others, depending on the form of
-the length octets:
-
-05 00
-
-05 81 00
-
-DER encoding. Primitive. Contents octets are empty; the DER
-encoding of a NULL value is always 05 00.
-
-
-5.9 OBJECT IDENTIFIER
-
-The OBJECT IDENTIFIER type denotes an object identifier, a
-sequence of integer components that identifies an object
-such as an algorithm, an attribute type, or perhaps a
-registration authority that defines other object
-identifiers. An OBJECT IDENTIFIER value can have any number
-of components, and components can generally have any
-nonnegative value. This type is a non-string type.
-
-OBJECT IDENTIFIER values are given meanings by registration
-authorities. Each registration authority is responsible for
-all sequences of components beginning with a given sequence.
-A registration authority typically delegates responsibility
-for subsets of the sequences in its domain to other
-registration authorities, or for particular types of object.
-There are always at least two components.
-
-The OBJECT IDENTIFIER type is used to identify content in
-PKCS #7's ContentInfo type, to identify algorithms in
-X.509's AlgorithmIdentifier type, and to identify attributes
-in X.501's Attribute and AttributeValueAssertion types. The
-Attribute type is used by PKCS #6, #7, #8, #9, and #10, and
-the AttributeValueAssertion type is used in X.501
-distinguished names. OBJECT IDENTIFIER values are defined
-throughout PKCS.
-
-ASN.1 notation:
-
-OBJECT IDENTIFIER
-
-The ASN.1 notation for values of the OBJECT IDENTIFIER type
-is
-
-{ [identifier] component1 ... componentn }
-
-componenti = identifieri | identifieri (valuei) | valuei
-
-where identifier, identifier1, ..., identifiern are
-identifiers, and value1, ..., valuen are optional integer
-values.
-
-The form without identifier is the "complete" value with all
-its components; the form with identifier abbreviates the
-beginning components with another object identifier value.
-The identifiers identifier1, ..., identifiern are intended
-primarily for documentation, but they must correspond to the
-integer value when both are present. These identifiers can
-appear without integer values only if they are among a small
-set of identifiers defined in X.208.
-
-Example: The following values both refer to the object
-identifier assigned to RSA Data Security, Inc.:
-
-{ iso(1) member-body(2) 840 113549 }
-{ 1 2 840 113549 }
-
-(In this example, which gives ASN.1 value notation, the
-object identifier values are decimal, not hexadecimal.)
-Table 4 gives some other object identifier values and their
-meanings.
-
- Object identifier value       Meaning
- { 1 2 }                       ISO member bodies
- { 1 2 840 }                   US (ANSI)
- { 1 2 840 113549 }            RSA Data Security, Inc.
- { 1 2 840 113549 1 }          RSA Data Security, Inc. PKCS
- { 2 5 }                       directory services (X.500)
- { 2 5 8 }                     directory services-algorithms
-
- Table 4. Some object identifier values and their meanings.
-
-BER encoding. Primitive. Contents octets are as follows,
-where value1, ..., valuen denote the integer values of the
-components in the complete object identifier:
-
-     1.   The first octet has value 40 * value1 + value2.
-          (This is unambiguous, since value1 is limited to
-          values 0, 1, and 2; value2 is limited to the range
-          0 to 39 when value1 is 0 or 1; and, according to
-          X.208, n is always at least 2.)
-
-     2.   The following octets, if any, encode value3, ...,
-          valuen. Each value is encoded base 128, most
-          significant digit first, with as few digits as
-          possible, and the most significant bit of each
-          octet except the last in the value's encoding set
-          to "1."
-
-Example: The first octet of the BER encoding of RSA Data
-Security, Inc.'s object identifier is 40 * 1 + 2 = 42 =
-2a16. The encoding of 840 = 6 * 128 + 4816 is 86 48 and the
-encoding of 113549 = 6 * 1282 + 7716 * 128 + d16 is 86 f7
-0d. This leads to the following BER encoding:
-
-06 06 2a 86 48 86 f7 0d
-
-DER encoding. Primitive. Contents octets are as for a
-primitive BER encoding.
-
-
-5.10 OCTET STRING
-
-The OCTET STRING type denotes an arbitrary string of octets
-(eight-bit values). An OCTET STRING value can have any
-length, including zero. This type is a string type.
-
-The OCTET STRING type is used for salt values in PKCS #5's
-PBEParameter type, for message digests, encrypted message
-digests, and encrypted content in PKCS #7, and for private
-keys and encrypted private keys in PKCS #8.
-
-ASN.1 notation:
-
-OCTET STRING [SIZE ({size | size1..size2})]
-
-where size, size1, and size2 are optional size constraints.
-In the OCTET STRING SIZE (size) form, the octet string must
-have size octets. In the OCTET STRING SIZE (size1..size2)
-form, the octet string must have between size1 and size2
-octets. In the OCTET STRING form, the octet string can have
-any size.
-
-Example: PKCS #5's PBEParameter type has a component of type
-OCTET STRING:
-
-PBEParameter ::= SEQUENCE {
-  salt OCTET STRING SIZE(8),
-  iterationCount INTEGER }
-
-Here the size of the salt component is always eight octets.
-
-BER encoding. Primitive or constructed. In a primitive
-encoding, the contents octets give the value of the octet
-string, first octet to last octet. In a constructed
-encoding, the contents octets give the concatenation of the
-BER encodings of substrings of the OCTET STRING value.
-
-Example: The BER encoding of the OCTET STRING value 01 23 45
-67 89 ab cd ef can be any of the following, among others,
-depending on the form of length octets and whether the
-encoding is primitive or constructed:
-
-04 08 01 23 45 67 89 ab cd ef                   DER encoding
-
-04 81 08 01 23 45 67 89 ab cd ef  long form of length octets
-
-24 0c            constructed encoding: 01 ... 67 + 89 ... ef
-   04 04 01 23 45 67
-   04 04 89 ab cd ef
-
-DER encoding. Primitive. Contents octets are as for a
-primitive BER encoding.
-
-Example: The BER encoding of the OCTET STRING value 01 23 45
-67 89 ab cd ef is
-
-04 08 01 23 45 67 89 ab cd ef
-
-
-5.11 PrintableString
-
-The PrintableString type denotes an arbitrary string of
-printable characters from the following character set:
-
-                         A, B, ..., Z
-                         a, b, ..., z
-                         0, 1, ..., 9
-               (space) ' ( ) + , - . / : = ?
-
-This type is a string type.
-
-The PrintableString type is used in PKCS #9's challenge-
-password and unstructuerd-address attributes, and in several
-X.521 distinguished names attributes.
-
-ASN.1 notation:
-
-PrintableString
-
-BER encoding. Primitive or constructed. In a primitive
-encoding, the contents octets give the characters in the
-printable string, encoded in ASCII. In a constructed
-encoding, the contents octets give the concatenation of the
-BER encodings of consecutive substrings of the string.
-
-Example: The BER encoding of the PrintableString value "Test
-User 1" can be any of the following, among others, depending
-on the form of length octets and whether the encoding is
-primitive or constructed:
-
-13 0b 54 65 73 74 20 55 73 65 72 20 31          DER encoding
-
-13 81 0b                          long form of length octets
-   54 65 73 74 20 55 73 65 72 20 31
-
-33 0f               constructed encoding: "Test " + "User 1"
-   13 05 54 65 73 74 20
-   13 06 55 73 65 72 20 31
-
-DER encoding. Primitive. Contents octets are as for a
-primitive BER encoding.
-
-Example: The DER encoding of the PrintableString value "Test
-User 1" is
-
-13 0b 54 65 73 74 20 55 73 65 72 20 31
-
-
-5.12 SEQUENCE
-
-The SEQUENCE type denotes an ordered collection of one or
-more types.
-
-The SEQUENCE type is used throughout PKCS and related
-standards.
-
-ASN.1 notation:
-
-SEQUENCE {
-  [identifier1] Type1 [{OPTIONAL | DEFAULT value1}],
-  ...,
-  [identifiern] Typen [{OPTIONAL | DEFAULT valuen}]}
-
-where identifier1 , ..., identifiern are optional, distinct
-identifiers for the components, Type1, ..., Typen are the
-types of the components, and value1, ..., valuen are optional
-default values for the components. The identifiers are
-primarily for documentation; they do not affect values of
-the type or their encodings in any way.
-
-The OPTIONAL qualifier indicates that the value of a
-component is optional and need not be present in the
-sequence. The DEFAULT qualifier also indicates that the
-value of a component is optional, and assigns a default
-value to the component when the component is absent.
-
-The types of any consecutive series of components with the
-OPTIONAL or DEFAULT qualifier, as well as of any component
-immediately following that series, must have distinct tags.
-This requirement is typically satisfied with explicit or
-implicit tagging on some of the components.
-
-Example: X.509's Validity type is a SEQUENCE type with two
-components:
-
-Validity ::= SEQUENCE {
-  start UTCTime,
-  end UTCTime }
-
-Here the identifiers for the components are start and end,
-and the types of the components are both UTCTime.
-
-BER encoding. Constructed. Contents octets are the
-concatenation of the BER encodings of the values of the
-components of the sequence, in order of definition, with the
-following rules for components with the OPTIONAL and DEFAULT
-qualifiers:
-
-     o    if the value of a component with the OPTIONAL or
-          DEFAULT qualifier is absent from the sequence,
-          then the encoding of that component is not
-          included in the contents octets
-
-     o    if the value of a component with the DEFAULT
-          qualifier is the default value, then the encoding
-          of that component may or may not be included in
-          the contents octets
-
-DER encoding. Constructed. Contents octets are the same as
-the BER encoding, except that if the value of a component
-with the DEFAULT qualifier is the default value, the
-encoding of that component is not included in the contents
-octets.
-
-
-5.13 SEQUENCE OF
-
-The SEQUENCE OF type denotes an ordered collection of zero
-or more occurrences of a given type.
-
-The SEQUENCE OF type is used in X.501 distinguished names.
-
-ASN.1 notation:
-
-SEQUENCE OF Type
-
-where Type is a type.
-
-Example: X.501's RDNSequence type consists of zero or more
-occurences of the RelativeDistinguishedName type, most
-significant occurrence first:
-
-RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
-
-BER encoding. Constructed. Contents octets are the
-concatenation of the BER encodings of the values of the
-occurrences in the collection, in order of occurence.
-
-DER encoding. Constructed. Contents octets are the
-concatenation of the DER encodings of the values of the
-occurrences in the collection, in order of occurence.
-
-
-5.14 SET
-
-The SET type denotes an unordered collection of one or more
-types.
-
-The SET type is not used in PKCS.
-
-ASN.1 notation:
-
-SET {
-  [identifier1] Type1 [{OPTIONAL | DEFAULT value1}],
-  ...,
-  [identifiern] Typen [{OPTIONAL | DEFAULT valuen}]}
-
-where identifier1, ..., identifiern are optional, distinct
-identifiers for the components, Type1, ..., Typen are the
-types of the components, and value1, ..., valuen are
-optional default values for the components. The identifiers
-are primarily for documentation; they do not affect values
-of the type or their encodings in any way.
-
-The OPTIONAL qualifier indicates that the value of a
-component is optional and need not be present in the set.
-The DEFAULT qualifier also indicates that the value of a
-component is optional, and assigns a default value to the
-component when the component is absent.
-
-The types must have distinct tags. This requirement is
-typically satisfied with explicit or implicit tagging on
-some of the components.
-
-BER encoding. Constructed. Contents octets are the
-concatenation of the BER encodings of the values of the
-components of the set, in any order, with the following
-rules for components with the OPTIONAL and DEFAULT
-qualifiers:
-
-     o    if the value of a component with the OPTIONAL or
-          DEFAULT qualifier is absent from the set, then the
-          encoding of that component is not included in the
-          contents octets
-
-     o    if the value of a component with the DEFAULT
-          qualifier is the default value, then the encoding
-          of that component may or may not be included in
-          the contents octets
-
-DER encoding. Constructed. Contents octets are the same as
-for the BER encoding, except that:
-
-     1.   If the value of a component with the DEFAULT
-          qualifier is the default value, the encoding of
-          that component is not included.
-
-     2.   There is an order to the components, namely
-          ascending order by tag.
-
-
-5.15 SET OF
-
-The SET OF type denotes an unordered collection of zero or
-more occurrences of a given type.
-
-The SET OF type is used for sets of attributes in PKCS #6,
-#7, #8, #9 and #10, for sets of message-digest algorithm
-identifiers, signer information, and recipient information
-in PKCS #7, and in X.501 distinguished names.
-
-ASN.1 notation:
-
-SET OF Type
-
-where Type is a type.
-
-Example: X.501's RelativeDistinguishedName type consists of
-zero or more occurrences of the AttributeValueAssertion
-type, where the order is unimportant:
-
-RelativeDistinguishedName ::=
-  SET OF AttributeValueAssertion
-
-BER encoding. Constructed. Contents octets are the
-concatenation of the BER encodings of the values of the
-occurrences in the collection, in any order.
-
-DER encoding. Constructed. Contents octets are the same as
-for the BER encoding, except that there is an order, namely
-ascending lexicographic order of BER encoding. Lexicographic
-comparison of two different BER encodings is done as
-follows: Logically pad the shorter BER encoding after the
-last octet with dummy octets that are smaller in value than
-any normal octet. Scan the BER encodings from left to right
-until a difference is found. The smaller-valued BER encoding
-is the one with the smaller-valued octet at the point of
-difference.
-
-
-5.16 T61String
-
-The T61String type denotes an arbtrary string of T.61
-characters. T.61 is an eight-bit extension to the ASCII
-character set. Special "escape" sequences specify the
-interpretation of subsequent character values as, for
-example, Japanese; the initial interpretation is Latin. The
-character set includes non-printing control characters. The
-T61String type allows only the Latin and Japanese character
-interepretations, and implementors' agreements for directory
-names exclude control characters [NIST92]. A T61String value
-can have any length, including zero. This type is a string
-type.
-
-The T61String type is used in PKCS #9's unstructured-address
-and challenge-password attributes, and in several X.521
-attributes.
-
-ASN.1 notation:
-
-T61String
-
-BER encoding. Primitive or constructed. In a primitive
-encoding, the contents octets give the characters in the
-T.61 string, encoded in ASCII. In a constructed encoding,
-the contents octets give the concatenation of the BER
-encodings of consecutive substrings of the T.61 string.
-
-Example: The BER encoding of the T61String value "cl'es
-publiques" (French for "public keys") can be any of the
-following, among others, depending on the form of length
-octets and whether the encoding is primitive or constructed:
-
-14 0f                                           DER encoding
-   63 6c c2 65 73 20 70 75 62 6c 69 71 75 65 73
-
-14 81 0f                          long form of length octets
-   63 6c c2 65 73 20 70 75 62 6c 69 71 75 65 73
-
-34 15      constructed encoding: "cl'es" + " " + "publiques"
-   14 05 63 6c c2 65 73
-   14 01 20
-   14 09 70 75 62 6c 69 71 75 65 73
-
-The eight-bit character c2 is a T.61 prefix that adds an
-acute accent (') to the next character.
-
-DER encoding. Primitive. Contents octets are as for a
-primitive BER encoding.
-
-Example: The DER encoding of the T61String value "cl'es
-publiques" is
-
-14 0f 63 6c c2 65 73 20 70 75 62 6c 69 71 75 65 73
-
-
-5.17 UTCTime
-
-The UTCTime type denotes a "coordinated universal time" or
-Greenwich Mean Time (GMT) value. A UTCTime value includes
-the local time precise to either minutes or seconds, and an
-offset from GMT in hours and minutes. It takes any of the
-following forms:
-
-YYMMDDhhmmZ
-YYMMDDhhmm+hh'mm'
-YYMMDDhhmm-hh'mm'
-YYMMDDhhmmssZ
-YYMMDDhhmmss+hh'mm'
-YYMMDDhhmmss-hh'mm'
-
-where:
-
-     YY is the least significant two digits of the year
-
-     MM is the month (01 to 12)
-
-     DD is the day (01 to 31)
-
-     hh is the hour (00 to 23)
-
-     mm are the minutes (00 to 59)
-
-     ss are the seconds (00 to 59)
-
-     Z indicates that local time is GMT, + indicates that
-          local time is later than GMT, and - indicates that
-          local time is earlier than GMT
-
-     hh' is the absolute value of the offset from GMT in
-          hours
-
-     mm' is the absolute value of the offset from GMT in
-          minutes
-
-This type is a string type.
-
-The UTCTime type is used for signing times in PKCS #9's
-signing-time attribute and for certificate validity periods
-in X.509's Validity type.
-
-ASN.1 notation:
-
-UTCTime
-
-BER encoding. Primitive or constructed. In a primitive
-encoding, the contents octets give the characters in the
-string, encoded in ASCII. In a constructed encoding, the
-contents octets give the concatenation of the BER encodings
-of consecutive substrings of the string. (The constructed
-encoding is not particularly interesting, since UTCTime
-values are so short, but the constructed encoding is
-permitted.)
-
-Example: The time this sentence was originally written was
-4:45:40 p.m. Pacific Daylight Time on May 6, 1991, which can
-be represented with either of the following UTCTime values,
-among others:
-
-"910506164540-0700"
-
-"910506234540Z"
-
-These values have the following BER encodings, among others:
-
-17 0d 39 31 30 35 30 36 32 33 34 35 34 30 5a
-
-17 11 39 31 30 35 30 36 31 36 34 35 34 30 2D 30 37 30
-      30
-
-DER encoding. Primitive. Contents octets are as for a
-primitive BER encoding.
-
-
-6. An example
-
-This section gives an example of ASN.1 notation and DER
-encoding: the X.501 type Name.
-
-
-6.1 Abstract notation
-
-This section gives the ASN.1 notation for the X.501 type
-Name.
-
-Name ::= CHOICE {
-  RDNSequence }
-
-RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
-
-RelativeDistinguishedName ::=
-  SET OF AttributeValueAssertion
-
-AttributeValueAssertion ::= SEQUENCE {
-   AttributeType,
-   AttributeValue }
-
-AttributeType ::= OBJECT IDENTIFIER
-
-AttributeValue ::= ANY
-
-The Name type identifies an object in an X.500 directory.
-Name is a CHOICE type consisting of one alternative:
-RDNSequence. (Future revisions of X.500 may have other
-alternatives.)
-
-The RDNSequence type gives a path through an X.500 directory
-tree starting at the root. RDNSequence is a SEQUENCE OF type
-consisting of zero or more occurences of
-RelativeDistinguishedName.
-
-The RelativeDistinguishedName type gives a unique name to an
-object relative to the object superior to it in the
-directory tree. RelativeDistinguishedName is a SET OF type
-consisting of zero or more occurrences of
-AttributeValueAssertion.
-
-The AttributeValueAssertion type assigns a value to some
-attribute of a relative distinguished name, such as country
-name or common name. AttributeValueAssertion is a SEQUENCE
-type consisting of two components, an AttributeType type and
-an AttributeValue type.
-
-The AttributeType type identifies an attribute by object
-identifier. The AttributeValue type gives an arbitrary
-attribute value. The actual type of the attribute value is
-determined by the attribute type.
-
-
-6.2 DER encoding
-
-This section gives an example of a DER encoding of a value
-of type Name, working from the bottom up.
-
-The name is that of the Test User 1 from the PKCS examples
-[Kal93]. The name is represented by the following path:
-
-                           (root)
-                              |
-                     countryName = "US"
-                              |
-          organizationName = "Example Organization"
-                              |
-                 commonName = "Test User 1"
-
-Each level corresponds to one RelativeDistinguishedName
-value, each of which happens for this name to consist of one
-AttributeValueAssertion value. The AttributeType value is
-before the equals sign, and the AttributeValue value (a
-printable string for the given attribute types) is after the
-equals sign.
-
-The countryName, organizationName, and commonUnitName are
-attribute types defined in X.520 as:
-
-attributeType OBJECT IDENTIFIER ::=
-  { joint-iso-ccitt(2) ds(5) 4 }
-
-countryName OBJECT IDENTIFIER ::= { attributeType 6 }
-organizationName OBJECT IDENTIFIER ::=
-  { attributeType 10 }
-commonUnitName OBJECT IDENTIFIER ::=
-  { attributeType 3 }
-
-
-6.2.1 AttributeType
-
-The three AttributeType values are OCTET STRING values, so
-their DER encoding follows the primitive, definite-length
-method:
-
-06 03 55 04 06                                   countryName
-
-06 03 55 04 0a                              organizationName
-
-06 03 55 04 03                                    commonName
-
-The identifier octets follow the low-tag form, since the tag
-is 6 for OBJECT IDENTIFIER. Bits 8 and 7 have value "0,"
-indicating universal class, and bit 6 has value "0,"
-indicating that the encoding is primitive. The length octets
-follow the short form. The contents octets are the
-concatenation of three octet strings derived from
-subidentifiers (in decimal): 40 * 2 + 5 = 85 = 5516; 4; and
-6, 10, or 3.
-
-
-6.2.2 AttributeValue
-
-The three AttributeValue values are PrintableString values,
-so their encodings follow the primitive, definite-length
-method:
-
-13 02 55 53                                             "US"
-
-13 14                                 "Example Organization"
-   45 78 61 6d 70 6c 65 20 4f 72 67 61 6e 69 7a 61
-   74 69 6f 6e
-
-13 0b                                          "Test User 1"
-   54 65 73 74 20 55 73 65 72 20 31
-
-The identifier octets follow the low-tag-number form, since
-the tag for PrintableString, 19 (decimal), is between 0 and
-30. Bits 8 and 7 have value "0" since PrintableString is in
-the universal class. Bit 6 has value "0" since the encoding
-is primitive. The length octets follow the short form, and
-the contents octets are the ASCII representation of the
-attribute value.
-
-
-6.2.3 AttributeValueAssertion
-
-The three AttributeValueAssertion values are SEQUENCE
-values, so their DER encodings follow the constructed,
-definite-length method:
-
-30 09                                     countryName = "US"
-   06 03 55 04 06
-   13 02 55 53
-
-30 1b              organizationName = "Example Organizaiton"
-   06 03 55 04 0a
-   13 14 ... 6f 6e
-
-30 12                             commonName = "Test User 1"
-   06 03 55 04 0b
-   13 0b ... 20 31
-
-The identifier octets follow the low-tag-number form, since
-the tag for SEQUENCE, 16 (decimal), is between 0 and 30.
-Bits 8 and 7 have value "0" since SEQUENCE is in the
-universal class. Bit 6 has value "1" since the encoding is
-constructed. The length octets follow the short form, and
-the contents octets are the concatenation of the DER
-encodings of the attributeType and attributeValue
-components.
-
-
-6.2.4 RelativeDistinguishedName
-
-The three RelativeDistinguishedName values are SET OF
-values, so their DER encodings follow the constructed,
-definite-length method:
-
-31 0b
-   30 09 ... 55 53
-
-31 1d
-   30 1b ... 6f 6e
-
-31 14
-   30 12 ... 20 31
-
-The identifier octets follow the low-tag-number form, since
-the tag for SET OF, 17 (decimal), is between 0 and 30. Bits
-8 and 7 have value "0" since SET OF is in the universal
-class Bit 6 has value "1" since the encoding is constructed.
-The lengths octets follow the short form, and the contents
-octets are the DER encodings of the respective
-AttributeValueAssertion values, since there is only one
-value in each set.
-
-
-6.2.5 RDNSequence
-
-The RDNSequence value is a SEQUENCE OF value, so its DER
-encoding follows the constructed, definite-length method:
-
-30 42
-   31 0b ... 55 53
-   31 1d ... 6f 6e
-   31 14 ... 20 31
-
-The identifier octets follow the low-tag-number form, since
-the tag for SEQUENCE OF, 16 (decimal), is between 0 and 30.
-Bits 8 and 7 have value "0" since SEQUENCE OF is in the
-universal class. Bit 6 has value "1" since the encoding is
-constructed. The lengths octets follow the short form, and
-the contents octets are the concatenation of the DER
-encodings of the three RelativeDistinguishedName values, in
-order of occurrence.
-
-
-6.2.6 Name
-
-The Name value is a CHOICE value, so its DER encoding is the
-same as that of the RDNSequence value:
-
-30 42
-   31 0b
-      30 09
-         06 03 55 04 06          attributeType = countryName
-         13 02 55 53                   attributeValue = "US"
-   31 1d
-      30 1b
-         06 03 55 04 0a     attributeType = organizationName
-         13 14       attributeValue = "Example Organization"
-            45 78 61 6d 70 6c 65 20 4f 72 67 61 6e 69 7a 61
-            74 69 6f 6e
-
-   31 14
-      30 12
-         06 03 55 04 03           attributeType = commonName
-         13 0b                attributeValue = "Test User 1"
-            54 65 73 74 20 55 73 65 72 20 31
-
-
-References
-
-PKCS #1   RSA Laboratories. PKCS #1: RSA Encryption
-          Standard. Version 1.5, November 1993.
-
-PKCS #3   RSA Laboratories. PKCS #3: Diffie-Hellman Key-
-          Agreement Standard. Version 1.4, November 1993.
-
-PKCS #5   RSA Laboratories. PKCS #5: Password-Based
-          Encryption Standard. Version 1.5, November 1993.
-
-PKCS #6   RSA Laboratories. PKCS #6: Extended-Certificate
-          Syntax Standard. Version 1.5, November 1993.
-
-PKCS #7   RSA Laboratories. PKCS #7: Cryptographic Message
-          Syntax Standard. Version 1.5, November 1993.
-
-PKCS #8   RSA Laboratories. PKCS #8: Private-Key Information
-          Syntax Standard. Version 1.2, November 1993.
-
-PKCS #9   RSA Laboratories. PKCS #9: Selected Attribute
-          Types. Version 1.1, November 1993.
-
-PKCS #10  RSA Laboratories. PKCS #10: Certification Request
-          Syntax Standard. Version 1.0, November 1993.
-
-X.200     CCITT. Recommendation X.200: Reference Model of
-          Open Systems Interconnection for CCITT
-          Applications. 1984.
-
-X.208     CCITT. Recommendation X.208: Specification of
-          Abstract Syntax Notation One (ASN.1). 1988.
-
-X.209     CCITT. Recommendation X.209: Specification of
-          Basic Encoding Rules for Abstract Syntax Notation
-          One (ASN.1). 1988.
-
-X.500     CCITT. Recommendation X.500: The
-          Directory--Overview of Concepts, Models and
-          Services. 1988.
-
-X.501     CCITT. Recommendation X.501: The Directory--
-          Models. 1988.
-
-X.509     CCITT. Recommendation X.509: The Directory--
-          Authentication Framework. 1988.
-
-X.520     CCITT. Recommendation X.520: The Directory--
-          Selected Attribute Types. 1988.
-
-[Kal93]   Burton S. Kaliski Jr. Some Examples of the PKCS
-          Standards. RSA Laboratories, November 1993.
-
-[NIST92]  NIST. Special Publication 500-202: Stable
-          Implementation Agreements for Open Systems
-          Interconnection Protocols. Part 11 (Directory
-          Services Protocols). December 1992.
-
-
-Revision history
-
-
-June 3, 1991 version
-
-The June 3, 1991 version is part of the initial public
-release of PKCS. It was published as NIST/OSI Implementors'
-Workshop document SEC-SIG-91-17.
-
-
-November 1, 1993 version
-
-The November 1, 1993 version incorporates several editorial
-changes, including the addition of a revision history. It is
-updated to be consistent with the following versions of the
-PKCS documents:
-
-     PKCS #1: RSA Encryption Standard. Version 1.5, November
-          1993.
-
-     PKCS #3: Diffie-Hellman Key-Agreement Standard. Version
-          1.4, November 1993.
-
-     PKCS #5: Password-Based Encryption Standard. Version
-          1.5, November 1993.
-
-     PKCS #6: Extended-Certificate Syntax Standard. Version
-          1.5, November 1993.
-
-     PKCS #7: Cryptographic Message Syntax Standard. Version
-          1.5, November 1993.
-
-     PKCS #8: Private-Key Information Syntax Standard.
-          Version 1.2, November 1993.
-
-     PKCS #9: Selected Attribute Types. Version 1.1,
-          November 1993.
-
-     PKCS #10: Certification Request Syntax Standard.
-          Version 1.0, November 1993.
-
-The following substantive changes were made:
-
-     Section 5: Description of T61String type is added.
-
-     Section 6: Names are changed, consistent with other
-          PKCS examples.
-
-
-Author's address
-
-Burton S. Kaliski Jr., Ph.D.
-Chief Scientist
-RSA Laboratories              (415) 595-7703
-100 Marine Parkway            (415) 595-4126 (fax)
-Redwood City, CA  94065  USA  burt@rsa.com
diff --git a/crypto/heimdal/doc/mdate-sh b/crypto/heimdal/doc/mdate-sh
deleted file mode 100755
index 37171f2..0000000
--- a/crypto/heimdal/doc/mdate-sh
+++ /dev/null
@@ -1,92 +0,0 @@
-#!/bin/sh
-# Get modification time of a file or directory and pretty-print it.
-# Copyright (C) 1995, 1996, 1997 Free Software Foundation, Inc.
-# written by Ulrich Drepper <drepper@gnu.ai.mit.edu>, June 1995
-#
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 2, or (at your option)
-# any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software Foundation,
-# Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
-
-# Prevent date giving response in another language.
-LANG=C
-export LANG
-LC_ALL=C
-export LC_ALL
-LC_TIME=C
-export LC_TIME
-
-# Get the extended ls output of the file or directory.
-# On HPUX /bin/sh, "set" interprets "-rw-r--r--" as options, so the "x" below.
-if ls -L /dev/null 1>/dev/null 2>&1; then
-  set - x`ls -L -l -d $1`
-else
-  set - x`ls -l -d $1`
-fi
-# The month is at least the fourth argument
-# (3 shifts here, the next inside the loop).
-shift
-shift
-shift
-
-# Find the month.  Next argument is day, followed by the year or time.
-month=
-until test $month
-do
-  shift
-  case $1 in
-    Jan) month=January; nummonth=1;;
-    Feb) month=February; nummonth=2;;
-    Mar) month=March; nummonth=3;;
-    Apr) month=April; nummonth=4;;
-    May) month=May; nummonth=5;;
-    Jun) month=June; nummonth=6;;
-    Jul) month=July; nummonth=7;;
-    Aug) month=August; nummonth=8;;
-    Sep) month=September; nummonth=9;;
-    Oct) month=October; nummonth=10;;
-    Nov) month=November; nummonth=11;;
-    Dec) month=December; nummonth=12;;
-  esac
-done
-
-day=$2
-
-# Here we have to deal with the problem that the ls output gives either
-# the time of day or the year.
-case $3 in
-  *:*) set `date`; eval year=\$$#
-       case $2 in
-	 Jan) nummonthtod=1;;
-	 Feb) nummonthtod=2;;
-	 Mar) nummonthtod=3;;
-	 Apr) nummonthtod=4;;
-	 May) nummonthtod=5;;
-	 Jun) nummonthtod=6;;
-	 Jul) nummonthtod=7;;
-	 Aug) nummonthtod=8;;
-	 Sep) nummonthtod=9;;
-	 Oct) nummonthtod=10;;
-	 Nov) nummonthtod=11;;
-	 Dec) nummonthtod=12;;
-       esac
-       # For the first six month of the year the time notation can also
-       # be used for files modified in the last year.
-       if (expr $nummonth \> $nummonthtod) > /dev/null;
-       then
-	 year=`expr $year - 1`
-       fi;;
-  *) year=$3;;
-esac
-
-# The result.
-echo $day $month $year
diff --git a/crypto/heimdal/doc/migration.texi b/crypto/heimdal/doc/migration.texi
deleted file mode 100644
index 586d488..0000000
--- a/crypto/heimdal/doc/migration.texi
+++ /dev/null
@@ -1,43 +0,0 @@
-@c $Id: migration.texi 9718 2001-02-24 05:09:24Z assar $
-
-@node Migration, Acknowledgments, Programming with Kerberos, Top
-@chapter Migration
-
-@section General issues
-
-When migrating from a Kerberos 4 KDC.
-
-@section Order in what to do things:
-
-@itemize @bullet
-
-@item Convert the database, check all principals that hprop complains
-about.
-
-@samp{hprop -n --source=<NNN>| hpropd -n}
-
-Replace <NNN> with whatever source you have, like krb4-db or krb4-dump.
-
-@item Run a Kerberos 5 slave for a while.
-
-@c XXX Add you slave first to your kdc list in you kdc.
-
-@item Figure out if it does everything you want it to.
-
-Make sure that all things that you use works for you.
-
-@item Let a small number of controlled users use Kerberos 5 tools.
-
-Find a sample population of your users and check what programs they use,
-you can also check the kdc-log to check what ticket are checked out.
-
-@item Burn the bridge and change the master.
-@item Let all users use the Kerberos 5 tools by default.
-@item Turn off services that do not need Kerberos 4 authentication.
-
-Things that might be hard to get away is old programs with support for
-Kerberos 4. Example applications are old Eudora installations using
-KPOP, and Zephyr. Eudora can use the Kerberos 4 kerberos in the Heimdal
-kdc.
-
-@end itemize
diff --git a/crypto/heimdal/doc/misc.texi b/crypto/heimdal/doc/misc.texi
deleted file mode 100644
index ea22609..0000000
--- a/crypto/heimdal/doc/misc.texi
+++ /dev/null
@@ -1,58 +0,0 @@
-@c $Id: misc.texi 12197 2003-05-04 13:32:37Z lha $
-
-@node Things in search for a better place, Kerberos 4 issues, Applications, Top
-@chapter Things in search for a better place
-
-@section Making things work on Ciscos
-
-Modern versions of Cisco IOS has some support for authenticating via
-Kerberos 5. This can be used both by having the router get a ticket when
-you login (boring), and by using Kerberos authenticated telnet to access
-your router (less boring). The following has been tested on IOS
-11.2(12), things might be different with other versions. Old versions
-are known to have bugs.
-
-To make this work, you will first have to configure your router to use
-Kerberos (this is explained in the documentation). A sample
-configuration looks like the following:
-
-@example
-aaa new-model
-aaa authentication login default krb5-telnet krb5 enable
-aaa authorization exec krb5-instance
-kerberos local-realm FOO.SE
-kerberos srvtab entry host/router.foo.se 0 891725446 4 1 8 012345678901234567
-kerberos server FOO.SE 10.0.0.1
-kerberos instance map admin 15
-@end example
-
-This tells you (among other things) that when logging in, the router
-should try to authenticate with kerberised telnet, and if that fails try
-to verify a plain text password via a Kerberos ticket exchange (as
-opposed to a local database, RADIUS or something similar), and if that
-fails try the local enable password. If you're not careful when you
-specify the `login default' authentication mechanism, you might not be
-able to login at all. The `instance map' and `authorization exec' lines
-says that people with `admin' instances should be given `enabled' shells
-when logging in.
-
-The numbers after the principal on the `srvtab' line are principal type,
-time stamp (in seconds since 1970), key version number (4), keytype (1 ==
-des), key length (always 8 with des), and then the key.
-
-To make the Heimdal KDC produce tickets that the Cisco can decode you
-might have to turn on the @samp{encode_as_rep_as_tgs_rep} flag in the
-KDC. You will also have to specify that the router can't handle anything
-but @samp{des-cbc-crc}. This can be done with the @samp{del_enctype}
-command of @samp{kadmin}.
-
-This all fine and so, but unless you have an IOS version with encryption
-(available only in the U.S) it doesn't really solve any problems. Sure
-you don't have to send your password over the wire, but since the telnet
-connection isn't protected it's still possible for someone to steal your
-session. This won't be fixed until someone adds integrity to the telnet
-protocol.
-
-A working solution would be to hook up a machine with a real operating
-system to the console of the Cisco and then use it as a backwards
-terminal server.
diff --git a/crypto/heimdal/doc/ntlm.din b/crypto/heimdal/doc/ntlm.din
deleted file mode 100644
index bbf1087..0000000
--- a/crypto/heimdal/doc/ntlm.din
+++ /dev/null
@@ -1,15 +0,0 @@
-# Doxyfile 1.5.3
-
-PROJECT_NAME           = Heimdal ntlm library
-PROJECT_NUMBER         = @PACKAGE_VERSION@
-OUTPUT_DIRECTORY       = @objdir@/ntlm
-INPUT                  = @srcdir@/../lib/ntlm
-
-WARN_IF_UNDOCUMENTED   = YES
-
-PERL_PATH              = /usr/bin/perl
-
-HTML_HEADER = "@srcdir@/header.html"
-HTML_FOOTER = "@srcdir@/footer.html"
-
-@INCLUDE = "@srcdir@/doxytmpl.dxy"
diff --git a/crypto/heimdal/doc/programming.texi b/crypto/heimdal/doc/programming.texi
deleted file mode 100644
index 528348b..0000000
--- a/crypto/heimdal/doc/programming.texi
+++ /dev/null
@@ -1,642 +0,0 @@
-@c $Id: programming.texi 22071 2007-11-14 20:04:50Z lha $
-
-@node Programming with Kerberos, Migration, Windows 2000 compatability, Top
-@chapter Programming with Kerberos
-
-First you need to know how the Kerberos model works, go read the
-introduction text (@pxref{What is Kerberos?}).
-
-@menu
-* Kerberos 5 API Overview::     
-* Walkthrough of a sample Kerberos 5 client::  
-* Validating a password in a server application::  
-* API differences to MIT Kerberos::  
-* File formats::
-@end menu
-
-@node Kerberos 5 API Overview, Walkthrough of a sample Kerberos 5 client, Programming with Kerberos, Programming with Kerberos
-@section Kerberos 5 API Overview
-
-All functions are documented in manual pages.  This section tries to
-give an overview of the major components used in Kerberos library, and
-point to where to look for a specific function.
-
-@subsection Kerberos context
-
-A kerberos context (@code{krb5_context}) holds all per thread state. All global variables that
-are context specific are stored in this structure, including default
-encryption types, credential cache (for example, a ticket file), and default realms.
-
-See the manual pages for @manpage{krb5_context,3} and
-@manpage{krb5_init_context,3}.
-
-@subsection Kerberos authentication context
-
-Kerberos authentication context (@code{krb5_auth_context}) holds all
-context related to an authenticated connection, in a similar way to the
-kerberos context that holds the context for the thread or process.
-
-The @code{krb5_auth_context} is used by various functions that are
-directly related to authentication between the server/client. Example of
-data that this structure contains are various flags, addresses of client
-and server, port numbers, keyblocks (and subkeys), sequence numbers,
-replay cache, and checksum types.
-
-See the manual page for @manpage{krb5_auth_context,3}.
-
-@subsection Kerberos principal
-
-The Kerberos principal is the structure that identifies a user or
-service in Kerberos. The structure that holds the principal is the
-@code{krb5_principal}. There are function to extract the realm and
-elements of the principal, but most applications have no reason to
-inspect the content of the structure.
-
-The are several ways to create a principal (with different degree of
-portability), and one way to free it.
-
-See manual page for @manpage{krb5_principal,3} for more information
-about the functions.
-
-@subsection Credential cache
-
-A credential cache holds the tickets for a user. A given user can have
-several credential caches, one for each realm where the user have the
-initial tickets (the first krbtgt).
-
-The credential cache data can be stored internally in different way, each of them for
-different proposes.  File credential (FILE) caches and processes based
-(KCM) caches are for permanent storage. While memory caches (MEMORY)
-are local caches to the local process.
-
-Caches are opened with @manpage{krb5_cc_resolve,3} or created with
-@manpage{krb5_cc_gen_unique,3}.
-
-If the cache needs to be opened again (using
-@manpage{krb5_cc_resolve,3}) @manpage{krb5_cc_close,3} will close the
-handle, but not the remove the cache. @manpage{krb5_cc_destroy,3} will
-zero out the cache, remove the cache so it can no longer be
-referenced.
-
-See also manual page for @manpage{krb5_ccache,3}
-
-@subsection Kerberos errors
-
-Kerberos errors are based on the com_err library.  All error codes are
-32-bit signed numbers, the first 24 bits define what subsystem the
-error originates from, and last 8 bits are 255 error codes within the
-library.  Each error code have fixed string associated with it.  For
-example, the error-code -1765328383 have the symbolic name
-KRB5KDC_ERR_NAME_EXP, and associated error string ``Client's entry in
-database has expired''.
-
-This is a great improvement compared to just getting one of the unix
-error-codes back.  However, Heimdal have an extention to pass back
-customised errors messages.  Instead of getting ``Key table entry not
-found'', the user might back ``failed to find
-host/host.example.com@@EXAMLE.COM(kvno 3) in keytab /etc/krb5.keytab
-(des-cbc-crc)''.  This improves the chance that the user find the
-cause of the error so you should use the customised error message
-whenever it's available.
-
-See also manual page for @manpage{krb5_get_error_string,3} and
-@manpage{krb5_get_err_text,3}.
-
-@subsection Keytab management
-
-A keytab is a storage for locally stored keys. Heimdal includes keytab
-support for Kerberos 5 keytabs, Kerberos 4 srvtab, AFS-KeyFile's,
-and for storing keys in memory.
-
-Keytabs are used for servers and long-running services.
-
-See also manual page for @manpage{krb5_keytab,3}
-
-@subsection Kerberos crypto
-
-Heimdal includes a implementation of the Kerberos crypto framework,
-all crypto operations.
-
-See also manual page for @manpage{krb5_crypto_init,3},
-@manpage{krb5_keyblock,3}, @manpage{krb5_create_checksum,3}, 
-and @manpage{krb5_encrypt,3}.
-
-@node Walkthrough of a sample Kerberos 5 client, Validating a password in a server application, Kerberos 5 API Overview, Programming with Kerberos
-@section Walkthrough of a sample Kerberos 5 client
-
-This example contains parts of a sample TCP Kerberos 5 clients, if you
-want a real working client, please look in @file{appl/test} directory in
-the Heimdal distribution.
-
-All Kerberos error-codes that are returned from kerberos functions in
-this program are passed to @code{krb5_err}, that will print a
-descriptive text of the error code and exit. Graphical programs can
-convert error-code to a human readable error-string with the
-@manpage{krb5_get_err_text,3} function.
-
-Note that you should not use any Kerberos function before
-@code{krb5_init_context()} have completed successfully. That is the
-reason @code{err()} is used when @code{krb5_init_context()} fails.
-
-First the client needs to call @code{krb5_init_context} to initialise
-the Kerberos 5 library. This is only needed once per thread
-in the program. If the function returns a non-zero value it indicates
-that either the Kerberos implementation is failing or it's disabled on
-this host.
-
-@example
-#include <krb5.h>
-
-int
-main(int argc, char **argv)
-@{
-        krb5_context context;
-
-        if (krb5_context(&context))
-                errx (1, "krb5_context");
-@end example
-
-Now the client wants to connect to the host at the other end. The
-preferred way of doing this is using @manpage{getaddrinfo,3} (for
-operating system that have this function implemented), since getaddrinfo
-is neutral to the address type and can use any protocol that is available.
-
-@example
-        struct addrinfo *ai, *a;
-        struct addrinfo hints;
-        int error;
-
-        memset (&hints, 0, sizeof(hints));
-        hints.ai_socktype = SOCK_STREAM;
-        hints.ai_protocol = IPPROTO_TCP;
-
-        error = getaddrinfo (hostname, "pop3", &hints, &ai);
-        if (error)
-                errx (1, "%s: %s", hostname, gai_strerror(error));
-
-        for (a = ai; a != NULL; a = a->ai_next) @{
-                int s;
-
-                s = socket (a->ai_family, a->ai_socktype, a->ai_protocol);
-                if (s < 0)
-                        continue;
-                if (connect (s, a->ai_addr, a->ai_addrlen) < 0) @{
-                        warn ("connect(%s)", hostname);
-                            close (s);
-                            continue;
-                @}
-                freeaddrinfo (ai);
-                ai = NULL;
-        @}
-        if (ai) @{
-                    freeaddrinfo (ai);
-                    errx ("failed to contact %s", hostname);
-        @}
-@end example
-
-Before authenticating, an authentication context needs to be
-created. This context keeps all information for one (to be) authenticated
-connection (see @manpage{krb5_auth_context,3}).
-
-@example
-        status = krb5_auth_con_init (context, &auth_context);
-        if (status)
-                krb5_err (context, 1, status, "krb5_auth_con_init");
-@end example
-
-For setting the address in the authentication there is a help function
-@code{krb5_auth_con_setaddrs_from_fd} that does everything that is needed
-when given a connected file descriptor to the socket.
-
-@example
-        status = krb5_auth_con_setaddrs_from_fd (context,
-                                                 auth_context,
-                                                 &sock);
-        if (status)
-                krb5_err (context, 1, status, 
-                          "krb5_auth_con_setaddrs_from_fd");
-@end example
-
-The next step is to build a server principal for the service we want
-to connect to. (See also @manpage{krb5_sname_to_principal,3}.)
-
-@example
-        status = krb5_sname_to_principal (context,
-                                          hostname,
-                                          service,
-                                          KRB5_NT_SRV_HST,
-                                          &server);
-        if (status)
-                krb5_err (context, 1, status, "krb5_sname_to_principal");
-@end example
-
-The client principal is not passed to @manpage{krb5_sendauth,3}
-function, this causes the @code{krb5_sendauth} function to try to figure it
-out itself.
-
-The server program is using the function @manpage{krb5_recvauth,3} to
-receive the Kerberos 5 authenticator.
-
-In this case, mutual authentication will be tried. That means that the server
-will authenticate to the client. Using mutual authentication
-is good since it enables the user to verify that they are talking to the
-right server (a server that knows the key).
-
-If you are using a non-blocking socket you will need to do all work of
-@code{krb5_sendauth} yourself. Basically you need to send over the
-authenticator from @manpage{krb5_mk_req,3} and, in case of mutual
-authentication, verifying the result from the server with
-@manpage{krb5_rd_rep,3}.
-
-@example
-        status = krb5_sendauth (context,
-                                &auth_context,
-                                &sock,
-                                VERSION,
-                                NULL,
-                                server,
-                                AP_OPTS_MUTUAL_REQUIRED,
-                                NULL,
-                                NULL,
-                                NULL,
-                                NULL,
-                                NULL,
-                                NULL);
-        if (status)
-                krb5_err (context, 1, status, "krb5_sendauth");
-@end example
-
-Once authentication has been performed, it is time to send some
-data. First we create a krb5_data structure, then we sign it with
-@manpage{krb5_mk_safe,3} using the @code{auth_context} that contains the
-session-key that was exchanged in the
-@manpage{krb5_sendauth,3}/@manpage{krb5_recvauth,3} authentication
-sequence.
-
-@example
-        data.data   = "hej";
-        data.length = 3;
-
-        krb5_data_zero (&packet);
-
-        status = krb5_mk_safe (context,
-                               auth_context,
-                               &data,
-                               &packet,
-                               NULL);
-        if (status)
-                krb5_err (context, 1, status, "krb5_mk_safe");
-@end example
-
-And send it over the network.
-
-@example
-        len = packet.length;
-        net_len = htonl(len);
-
-        if (krb5_net_write (context, &sock, &net_len, 4) != 4)
-                err (1, "krb5_net_write");
-        if (krb5_net_write (context, &sock, packet.data, len) != len)
-                err (1, "krb5_net_write");
-@end example
-
-To send encrypted (and signed) data @manpage{krb5_mk_priv,3} should be
-used instead. @manpage{krb5_mk_priv,3} works the same way as
-@manpage{krb5_mk_safe,3}, with the exception that it encrypts the data
-in addition to signing it.
-
-@example
-        data.data   = "hemligt";
-        data.length = 7;
-
-        krb5_data_free (&packet);
-
-        status = krb5_mk_priv (context,
-                               auth_context,
-                               &data,
-                               &packet,
-                               NULL);
-        if (status)
-                krb5_err (context, 1, status, "krb5_mk_priv");
-@end example
-
-And send it over the network.
-
-@example
-        len = packet.length;
-        net_len = htonl(len);
-
-        if (krb5_net_write (context, &sock, &net_len, 4) != 4)
-                err (1, "krb5_net_write");
-        if (krb5_net_write (context, &sock, packet.data, len) != len)
-                err (1, "krb5_net_write");
-
-@end example
-
-The server is using @manpage{krb5_rd_safe,3} and
-@manpage{krb5_rd_priv,3} to verify the signature and decrypt the packet.
-
-@node Validating a password in a server application, API differences to MIT Kerberos, Walkthrough of a sample Kerberos 5 client, Programming with Kerberos
-@section Validating a password in an application
-
-See the manual page for @manpage{krb5_verify_user,3}.
-
-@node API differences to MIT Kerberos, File formats, Validating a password in a server application, Programming with Kerberos
-@section API differences to MIT Kerberos
-
-This section is somewhat disorganised, but so far there is no overall
-structure to the differences, though some of the have their root in
-that Heimdal uses an ASN.1 compiler and MIT doesn't.
-
-@subsection Principal and realms
-
-Heimdal stores the realm as a @code{krb5_realm}, that is a @code{char *}.
-MIT Kerberos uses a @code{krb5_data} to store a realm.
-
-In Heimdal @code{krb5_principal} doesn't contain the component
-@code{name_type}; it's instead stored in component
-@code{name.name_type}. To get and set the nametype in Heimdal, use
-@manpage{krb5_principal_get_type,3} and
-@manpage{krb5_principal_set_type,3}.
-
-For more information about principal and realms, see
-@manpage{krb5_principal,3}.
-
-@subsection Error messages
-
-To get the error string, Heimdal uses
-@manpage{krb5_get_error_string,3} or, if @code{NULL} is returned,
-@manpage{krb5_get_err_text,3}. This is to return custom error messages
-(like ``Can't find host/datan.example.com@@EXAMPLE.COM in
-/etc/krb5.conf.'' instead of a ``Key table entry not found'' that
-@manpage{error_message,3} returns.
-
-Heimdal uses a threadsafe(r) version of the com_err interface; the
-global @code{com_err} table isn't initialised.  Then
-@manpage{error_message,3} returns quite a boring error string (just
-the error code itself).
-
-
-@c @node Why you should use GSS-API for new applications, Walkthrough of a sample GSS-API client, Validating a password in a server application, Programming with Kerberos
-@c @section Why you should use GSS-API for new applications
-@c 
-@c SSPI, bah, bah, microsoft, bah, bah, almost GSS-API.
-@c 
-@c It would also be possible for other mechanisms then Kerberos, but that
-@c doesn't exist any other GSS-API implementations today.
-@c 
-@c @node Walkthrough of a sample GSS-API client, , Why you should use GSS-API for new applications, Programming with Kerberos
-@c @section Walkthrough of a sample GSS-API client
-@c 
-@c Write about how gssapi_clent.c works.
-
-@node File formats,  , API differences to MIT Kerberos, Programming with Kerberos
-@section File formats
-
-This section documents the diffrent file formats that are used in
-Heimdal and other Kerberos implementations.
-
-@subsection keytab
-
-The keytab binary format is not a standard format. The format has
-evolved and may continue to. It is however understood by several
-Kerberos implementations including Heimdal, MIT, Sun's Java ktab and
-are created by the ktpass.exe utility from Windows. So it has
-established itself as the defacto format for storing Kerberos keys.
-
-The following C-like structure definitions illustrate the MIT keytab
-file format. All values are in network byte order. All text is ASCII.
-
-@example
-  keytab @{
-      uint16_t file_format_version;                    /* 0x502 */
-      keytab_entry entries[*];
-  @};
-
-  keytab_entry @{
-      int32_t size;
-      uint16_t num_components;   /* subtract 1 if version 0x501 */
-      counted_octet_string realm;
-      counted_octet_string components[num_components];
-      uint32_t name_type;       /* not present if version 0x501 */
-      uint32_t timestamp;
-      uint8_t vno8;
-      keyblock key;
-      uint32_t vno; /* only present if >= 4 bytes left in entry */
-  @};
-
-  counted_octet_string @{
-      uint16_t length;
-      uint8_t data[length];
-  @};
-
-  keyblock @{
-      uint16_t type;
-      counted_octet_string;
-  @};
-@end example
-
-All numbers are stored in network byteorder (big endian) format.
-
-The keytab file format begins with the 16 bit file_format_version which
-at the time this document was authored is 0x502. The format of older
-keytabs is described at the end of this document.
-
-The file_format_version is immediately followed by an array of
-keytab_entry structures which are prefixed with a 32 bit size indicating
-the number of bytes that follow in the entry. Note that the size should be
-evaluated as signed. This is because a negative value indicates that the
-entry is in fact empty (e.g. it has been deleted) and that the negative
-value of that negative value (which is of course a positive value) is
-the offset to the next keytab_entry. Based on these size values alone
-the entire keytab file can be traversed.
-
-The size is followed by a 16 bit num_components field indicating the
-number of counted_octet_string components in the components array.
-
-The num_components field is followed by a counted_octet_string
-representing the realm of the principal.
-
-A counted_octet_string is simply an array of bytes prefixed with a 16
-bit length. For the realm and name components, the counted_octet_string
-bytes are ASCII encoded text with no zero terminator.
-
-Following the realm is the components array that represents the name of
-the principal. The text of these components may be joined with slashs
-to construct the typical SPN representation. For example, the service
-principal HTTP/www.foo.net@@FOO.NET would consist of name components
-"HTTP" followed by "www.foo.net".
-
-Following the components array is the 32 bit name_type (e.g. 1 is
-KRB5_NT_PRINCIPAL, 2 is KRB5_NT_SRV_INST, 5 is KRB5_NT_UID, etc). In
-practice the name_type is almost certainly 1 meaning KRB5_NT_PRINCIPAL.
-
-The 32 bit timestamp indicates the time the key was established for that
-principal. The value represents the number of seconds since Jan 1, 1970.
-
-The 8 bit vno8 field is the version number of the key. This value is
-overridden by the 32 bit vno field if it is present. The vno8 field is
-filled with the lower 8 bits of the 32 bit protocol kvno field.
-
-The keyblock structure consists of a 16 bit value indicating the
-encryption type and is a counted_octet_string containing the key.  The
-encryption type is the same as the Kerberos standard (e.g. 3 is
-des-cbc-md5, 23 is arcfour-hmac-md5, etc).
-
-The last field of the keytab_entry structure is optional. If the size of
-the keytab_entry indicates that there are at least 4 bytes remaining,
-a 32 bit value representing the key version number is present. This
-value supersedes the 8 bit vno8 value preceeding the keyblock.
-
-Older keytabs with a file_format_version of 0x501 are different in
-three ways:
-
-@table @asis
-@item All integers are in host byte order [1].
-@item The num_components field is 1 too large (i.e. after decoding, decrement by 1).
-@item The 32 bit name_type field is not present.
-@end table
-
-[1] The file_format_version field should really be treated as two
-separate 8 bit quantities representing the major and minor version
-number respectively.
-
-@subsection Heimdal database dump file
-
-Format of the Heimdal text dump file as of Heimdal 0.6.3:
-
-Each line in the dump file is one entry in the database.
-
-Each field of a line is separated by one or more spaces, with the
-exception of fields consisting of principals containing spaces, where
-space can be quoted with \ and \ is quoted by \.
-
-Fields and their types are:
-
-@example
-	Quoted princial (quote character is \) [string]
-	Keys [keys]
-	Created by [event]
-	Modified by [event optional]
-	Valid start time [time optional]
-	Valid end time [time optional]
-	Password end valid time [time optional]
-	Max lifetime of ticket [time optional]
-	Max renew time of ticket [integer optional]
-	Flags [hdb flags]
-	Generation number [generation optional]
-	Extensions [extentions optional]
-@end example
-
-Fields following these silently are ignored.
-
-All optional fields will be skipped if they fail to parse (or comprise
-the optional field marker of "-", w/o quotes).
-
-Example:
-
-@example
-fred@@EXAMPLE.COM 27:1:16:e8b4c8fc7e60b9e641dcf4cff3f08a701d982a2f89ba373733d26ca59ba6c789666f6b8bfcf169412bb1e5dceb9b33cda29f3412:-:1:3:4498a933881178c744f4232172dcd774c64e81fa6d05ecdf643a7e390624a0ebf3c7407a:-:1:2:b01934b13eb795d76f3a80717d469639b4da0cfb644161340ef44fdeb375e54d684dbb85:-:1:1:ea8e16d8078bf60c781da90f508d4deccba70595258b9d31888d33987cd31af0c9cced2e:- 20020415130120:admin@@EXAMPLE.COM 20041221112428:fred@@EXAMPLE.COM - - - 86400 604800 126 20020415130120:793707:28 -
-@end example
-
-Encoding of types are as follows:
-
-@table @asis
-@item keys
-
-@example
-kvno:[masterkvno:keytype:keydata:salt]@{zero or more separated by :@}
-@end example
-
-kvno is the key version number.
-
-keydata is hex-encoded
-
-masterkvno is the kvno of the database master key.  If this field is
-empty, the kadmin load and merge operations will encrypt the key data
-with the master key if there is one.  Otherwise the key data will be
-imported asis.
-
-salt is encoded as "-" (no/default salt) or
-
-@example
-salt-type /
-salt-type / "string"
-salt-type / hex-encoded-data
-@end example
-
-keytype is the protocol enctype number; see enum ENCTYPE in
-include/krb5_asn1.h for values.
-
-Example:
-@example
-27:1:16:e8b4c8fc7e60b9e641dcf4cff3f08a701d982a2f89ba373733d26ca59ba6c789666f6b8bfcf169412bb1e5dceb9b33cda29f3412:-:1:3:4498a933881178c744f4232172dcd774c64e81fa6d05ecdf643a7e390624a0ebf3c7407a:-:1:2:b01934b13eb795d76f3a80717d469639b4da0cfb644161340ef44fdeb375e54d684dbb85:-:1:1:ea8e16d8078bf60c781da90f508d4deccba70595258b9d31888d33987cd31af0c9cced2e:-
-@end example
-
-
-@example
-kvno=27,@{key: masterkvno=1,keytype=des3-cbc-sha1,keydata=..., default salt@}...
-@end example
-
-@item time
-	
-Format of the time is: YYYYmmddHHMMSS, corresponding to strftime
-format "%Y%m%d%k%M%S".
-
-Time is expressed in UTC.
-
-Time can be optional (using -), when the time 0 is used.
-
-Example:
-
-@example
-20041221112428
-@end example
-
-@item event
-
-@example
-	time:principal
-@end example
-
-time is as given in format time
-
-principal is a string.  Not quoting it may not work in earlier
-versions of Heimdal.
-
-Example:
-@example
-20041221112428:bloggs@@EXAMPLE.COM
-@end example
-
-@item hdb flags
-
-Integer encoding of HDB flags, see HDBFlags in lib/hdb/hdb.asn1. Each
-bit in the integer is the same as the bit in the specification.
-
-@item generation:
-
-@example
-time:usec:gen
-@end example
-
-
-usec is a the microsecond, integer.
-gen is generation number, integer.
-
-The generation can be defaulted (using '-') or the empty string
-
-@item extensions:
-
-@example
-first-hex-encoded-HDB-Extension[:second-...]
-@end example
-
-HDB-extension is encoded the DER encoded HDB-Extension from
-lib/hdb/hdb.asn1. Consumers HDB extensions should be aware that
-unknown entires needs to be preserved even thought the ASN.1 data
-content might be unknown. There is a critical flag in the data to show
-to the KDC that the entry MUST be understod if the entry is to be
-used.
-
-@end table
diff --git a/crypto/heimdal/doc/setup.texi b/crypto/heimdal/doc/setup.texi
deleted file mode 100644
index 02e7972..0000000
--- a/crypto/heimdal/doc/setup.texi
+++ /dev/null
@@ -1,1455 +0,0 @@
-@c $Id: setup.texi 22191 2007-12-06 17:26:30Z lha $
-
-@node Setting up a realm, Applications, Building and Installing, Top
-
-@chapter Setting up a realm
-
-A
-@cindex realm
-realm is an administrative domain.  The name of a Kerberos realm is
-usually the Internet domain name in uppercase.  Call your realm the same
-as your Internet domain name if you do not have strong reasons for not
-doing so.  It will make life easier for you and everyone else.
-
-@menu
-* Configuration file::
-* Creating the database::
-* Modifying the database::
-* Checking the setup::
-* keytabs::
-* Serving Kerberos 4/524/kaserver::
-* Remote administration::
-* Password changing::
-* Testing clients and servers::
-* Slave Servers::
-* Incremental propagation::
-* Encryption types and salting::
-* Cross realm::
-* Transit policy::
-* Setting up DNS::
-* Using LDAP to store the database::
-* Providing Kerberos credentials to servers and programs::
-* Setting up PK-INIT::
-@end menu
-
-@node  Configuration file, Creating the database, Setting up a realm, Setting up a realm
-@section Configuration file
-
-To setup a realm you will first have to create a configuration file:
-@file{/etc/krb5.conf}. The @file{krb5.conf} file can contain many
-configuration options, some of which are described here.
-
-There is a sample @file{krb5.conf} supplied with the distribution.
-
-The configuration file is a hierarchical structure consisting of
-sections, each containing a list of bindings (either variable
-assignments or subsections). A section starts with
-@samp{[@samp{section-name}]}.  A binding consists of a left hand side, an equal sign
-(@samp{=}) and a right hand side (the left hand side tag must be
-separated from the equal sign with some whitespace). Subsections have a
-@samp{@{} as the first non-whitespace character after the equal sign. All
-other bindings are treated as variable assignments. The value of a
-variable extends to the end of the line.
-
-@example
-[section1]
-        a-subsection = @{
-                var = value1
-                other-var = value with @{@}
-                sub-sub-section = @{
-                        var = 123
-                @}
-        @}
-        var = some other value
-[section2]
-        var = yet another value
-@end example
-
-In this manual, names of sections and bindings will be given as strings
-separated by slashes (@samp{/}). The @samp{other-var} variable will thus
-be @samp{section1/a-subsection/other-var}.
-
-For in-depth information about the contents of the configuration file, refer to
-the @file{krb5.conf} manual page. Some of the more important sections
-are briefly described here.
-
-The @samp{libdefaults} section contains a list of library configuration
-parameters, such as the default realm and the timeout for KDC
-responses. The @samp{realms} section contains information about specific
-realms, such as where they hide their KDC@. This section serves the same
-purpose as the Kerberos 4 @file{krb.conf} file, but can contain more
-information. Finally the @samp{domain_realm} section contains a list of
-mappings from domains to realms, equivalent to the Kerberos 4
-@file{krb.realms} file.
-
-To continue with the realm setup, you will have to create a configuration file,
-with contents similar to the following.
-
-@example
-[libdefaults]
-        default_realm = MY.REALM
-[realms]
-        MY.REALM = @{
-                kdc = my.kdc my.slave.kdc
-                kdc = my.third.kdc
-        @}
-[domain_realm]
-        .my.domain = MY.REALM
-
-@end example
-
-If you use a realm name equal to your domain name, you can omit the
-@samp{libdefaults}, and @samp{domain_realm}, sections. If you have a DNS
-SRV-record for your realm, or your Kerberos server has DNS CNAME
-@samp{kerberos.my.realm}, you can omit the @samp{realms} section too.
-
-@node Creating the database, Modifying the database, Configuration file, Setting up a realm
-@section Creating the database
-
-The database library will look for the database in the directory
-@file{@value{dbdir}}, so you should probably create that directory.
-Make sure the directory has restrictive permissions.
-
-@example
-# mkdir /var/heimdal
-@end example
-
-The keys of all the principals are stored in the database.  If you
-choose to, these can be encrypted with a master key.  You do not have to
-remember this key (or password), but just to enter it once and it will
-be stored in a file (@file{/var/heimdal/m-key}).  If you want to have a
-master key, run @samp{kstash} to create this master key:
-
-@example
-# kstash
-Master key:
-Verifying password - Master key:
-@end example
-
-If you want to generate a random master key you can use the
-@kbd{--random-key} flag to kstash. This will make sure you have a good key
-on which attackers can't do a dictionary attack.
-
-If you have a master key, make sure you make a backup of your master
-key file; without it backups of the database are of no use.
-
-To initialise the database use the @command{kadmin} program, with the
-@kbd{-l} option (to enable local database mode). First issue a
-@kbd{init MY.REALM} command. This will create the database and insert
-default principals for that realm. You can have more than one realm in
-one database, so @samp{init} does not destroy any old database.
-
-Before creating the database, @samp{init} will ask you some questions
-about maximum ticket lifetimes.
-
-After creating the database you should probably add yourself to it. You
-do this with the @samp{add} command. It takes as argument the name of a
-principal. The principal should contain a realm, so if you haven't set up
-a default realm, you will need to explicitly include the realm.
-
-@example
-# kadmin -l
-kadmin> init MY.REALM
-Realm max ticket life [unlimited]:
-Realm max renewable ticket life [unlimited]:
-kadmin> add me
-Max ticket life [unlimited]:
-Max renewable life [unlimited]:
-Attributes []:
-Password:
-Verifying password - Password:
-@end example
-
-Now start the KDC and try getting a ticket.
-
-@example
-# kdc &
-# kinit me
-me@@MY.REALMS's Password:
-# klist
-Credentials cache: /tmp/krb5cc_0
-        Principal: me@@MY.REALM
-
-  Issued           Expires          Principal
-Aug 25 07:25:55  Aug 25 17:25:55  krbtgt/MY.REALM@@MY.REALM
-@end example
-
-If you are curious you can use the @samp{dump} command to list all the
-entries in the database.  It should look something similar to the
-following example (note that the entries here are truncated for
-typographical reasons):
-
-@smallexample
-kadmin> dump
-me@@MY.REALM 1:0:1:0b01d3cb7c293b57:-:0:7:8aec316b9d1629e3baf8 ...
-kadmin/admin@@MY.REALM 1:0:1:e5c8a2675b37a443:-:0:7:cb913ebf85 ...
-krbtgt/MY.REALM@@MY.REALM 1:0:1:52b53b61c875ce16:-:0:7:c8943be ...
-kadmin/changepw@@MY.REALM 1:0:1:f48c8af2b340e9fb:-:0:7:e3e6088 ...
-@end smallexample
-
-@node Modifying the database, Checking the setup, Creating the database, Setting up a realm
-@section Modifying the database
-
-All modifications of principals are done with with kadmin.
-
-A principal has several attributes and lifetimes associated with it.
-
-Principals are added, renamed, modified, and deleted with the kadmin
-commands @samp{add}, @samp{rename}, @samp{modify}, @samp{delete}.
-Both interactive editing and command line flags can be used (use --help
-to list the available options).
-
-There are different kinds of types for the fields in the database;
-attributes, absolute time times and relative times.
-
-@subsection Attributes
-
-When doing interactive editing, attributes are listed with @samp{?}.
-
-The attributes are given in a comma (@samp{,}) separated list.
-Attributes are removed from the list by prefixing them with @samp{-}.
-
-@smallexample
-kadmin> modify me
-Max ticket life [1 day]:
-Max renewable life [1 week]:
-Principal expiration time [never]:
-Password expiration time [never]:
-Attributes [disallow-renewable]: requires-pre-auth,-disallow-renewable
-kadmin> get me
-            Principal: me@@MY.REALM
-[...]
-           Attributes: requires-pre-auth
-@end smallexample
-
-@subsection Absolute times
-
-The format for absolute times are any of the following:
-
-@smallexample
-never
-now
-YYYY-mm-dd
-YYYY-mm-dd HH:MM:SS
-@end smallexample
-
-
-@subsection Relative times
-
-The format for relative times are any of the following combined:
-
-@smallexample
-N year
-M month
-O day
-P hour
-Q minute
-R second
-@end smallexample
-
-@c Describe more of kadmin commands here...
-
-@node Checking the setup, keytabs, Modifying the database, Setting up a realm
-@section Checking the setup
-
-There are two tools that can check the consistency of the Kerberos
-configuration file and the Kerberos database.
-
-The Kerberos configuration file is checked using
-@command{verify_krb5_conf}. The tool checks for common errors, but
-commonly there are several uncommon configuration entries that are
-never added to the tool and thus generates ``unknown entry'' warnings.
-This is usually nothing to worry about.
-
-The database check is built into the kadmin tool. It will check for
-common configuration error that will cause problems later. Common
-check are for existence and flags on important principals. The
-database check by run by the following command :
-
-@example
-kadmin check REALM.EXAMPLE.ORG
-@end example
-
-@node keytabs, Serving Kerberos 4/524/kaserver, Checking the setup, Setting up a realm
-@section keytabs
-
-To extract a service ticket from the database and put it in a keytab, you
-need to first create the principal in the database with @samp{ank}
-(using the @kbd{--random-key} flag to get a random key) and then
-extract it with @samp{ext_keytab}.
-
-@example
-kadmin> add --random-key host/my.host.name
-Max ticket life [unlimited]:
-Max renewable life [unlimited]:
-Attributes []:
-kadmin> ext host/my.host.name
-kadmin> exit
-# ktutil list
-Version  Type             Principal
-     1   des-cbc-md5      host/my.host.name@@MY.REALM
-     1   des-cbc-md4      host/my.host.name@@MY.REALM
-     1   des-cbc-crc      host/my.host.name@@MY.REALM
-     1   des3-cbc-sha1    host/my.host.name@@MY.REALM
-@end example
-
-@node Serving Kerberos 4/524/kaserver, Remote administration, keytabs, Setting up a realm
-@section Serving Kerberos 4/524/kaserver
-
-Heimdal can be configured to support 524, Kerberos 4 or kaserver. All
-these services are turned off by default. Kerberos 4 is always
-supported by the KDC, but the Kerberos 4 client support also depends
-on Kerberos 4 support having been included at compile-time, using
-@kbd{--with-krb4=dir}.
-
-@subsection 524
-
-524 is a service that allows the KDC to convert Kerberos 5 tickets to
-Kerberos 4 tickets for backward compatibility. See also Using 2b
-tokens with AFS in @xref{Things in search for a better place}.
-
-524 can be turned on by adding this to the configuration file
-
-@example
-[kdc]
-	enable-524 = yes
-@end example
-
-@subsection Kerberos 4
-
-Kerberos 4 is the predecessor to to Kerberos 5. It only supports
-single DES@. You should only enable Kerberos 4 support if you have
-needs for compatibility with an installed base of Kerberos 4
-clients/servers.
-
-Kerberos 4 can be turned on by adding this to the configuration file
-
-@example
-[kdc]
-	enable-kerberos4 = yes
-@end example
-
-@subsection kaserver
-
-Kaserver is a Kerberos 4 that is used in AFS@.  The protocol has some
-extra features over plain Kerberos 4, but like Kerberos 4, only uses
-single DES@.
-
-You should only enable Kaserver support if you have needs for
-compatibility with an installed base of AFS machines.
-
-Kaserver can be turned on by adding this to the configuration file
-
-@example
-[kdc]
-	enable-kaserver = yes
-@end example
-
-@node Remote administration, Password changing, Serving Kerberos 4/524/kaserver, Setting up a realm
-@section Remote administration
-
-The administration server, @command{kadmind}, can be started by
-@command{inetd} (which isn't recommended) or run as a normal daemon. If you
-want to start it from @command{inetd} you should add a line similar to the
-one below to your @file{/etc/inetd.conf}.
-
-@example
-kerberos-adm stream     tcp     nowait  root /usr/heimdal/libexec/kadmind kadmind
-@end example
-
-You might need to add @samp{kerberos-adm} to your @file{/etc/services}
-as @samp{749/tcp}.
-
-Access to the administration server is controlled by an ACL file,
-(default @file{/var/heimdal/kadmind.acl}.) The file has the following
-syntax:
-@smallexample
-principal       [priv1,priv2,...]       [glob-pattern]
-@end smallexample
-
-The matching is from top to bottom for matching principals (and if given,
-glob-pattern).  When there is a match, the access rights of that line are
-applied.
-
-The privileges you can assign to a principal are: @samp{add},
-@samp{change-password} (or @samp{cpw} for short), @samp{delete},
-@samp{get}, @samp{list}, and @samp{modify}, or the special privilege
-@samp{all}. All of these roughly correspond to the different commands
-in @command{kadmin}.
-
-If a @var{glob-pattern} is given on a line, it restricts the access
-rights for the principal to only apply for subjects that match the
-pattern.  The patterns are of the same type as those used in shell
-globbing, see @url{none,,fnmatch(3)}.
-
-In the example below @samp{lha/admin} can change every principal in the
-database. @samp{jimmy/admin} can only modify principals that belong to
-the realm @samp{E.KTH.SE}. @samp{mille/admin} is working at the
-help desk, so he should only be able to change the passwords for single
-component principals (ordinary users). He will not be able to change any
-@samp{/admin} principal.
-
-@example
-lha/admin@@E.KTH.SE	all
-jimmy/admin@@E.KTH.SE	all		*@@E.KTH.SE
-jimmy/admin@@E.KTH.SE	all		*/*@@E.KTH.SE
-mille/admin@@E.KTH.SE	change-password	*@@E.KTH.SE
-@end example
-
-@node Password changing, Testing clients and servers, Remote administration, Setting up a realm
-@section Password changing
-
-To allow users to change their passwords, you should run @command{kpasswdd}.
-It is not run from @command{inetd}.
-
-You might need to add @samp{kpasswd} to your @file{/etc/services} as
-@samp{464/udp}.
-
-@subsection Password quality assurance
-
-It is important that users have good passwords, both to make it harder
-to guess them and to avoid off-line attacks (although
-pre-authentication provides some defence against off-line attacks).
-To ensure that the users choose good passwords, you can enable
-password quality controls in @command{kpasswdd} and @command{kadmind}.
-The controls themselves are done in a shared library or an external
-program that is used by @command{kpasswdd}.  To configure in these
-controls, add lines similar to the following to your
-@file{/etc/krb5.conf}:
-
-@example
-[password_quality]
-	policies = external-check builtin:minimum-length module:policyname
-	external_program = /bin/false
-	policy_libraries = @var{library1.so} @var{library2.so}
-@end example
-
-In @samp{[password_quality]policies} the module name is optional if
-the policy name is unique in all modules (members of
-@samp{policy_libraries}).
-
-The built-in polices are
-
-@itemize @bullet
-
-@item external-check
-
-Executes the program specified by @samp{[password_quality]external_program}.
-
-A number of key/value pairs are passed as input to the program, one per
-line, ending with the string @samp{end}.  The key/value lines are of
-the form
-@example
-principal: @var{principal}
-new-password: @var{password}
-@end example
-where @var{password} is the password to check for the previous
-@var{principal}.
-
-If the external application approves the password, it should return
-@samp{APPROVED} on standard out and exit with exit code 0.  If it
-doesn't approve the password, an one line error message explaining the
-problem should be returned on standard error and the application
-should exit with exit code 0.  In case of a fatal error, the
-application should, if possible, print an error message on standard
-error and exit with a non-zero error code.
-
-@item minimum-length
-
-The minimum length password quality check reads the configuration file
-stanza @samp{[password_quality]min_length} and requires the password
-to be at least this length.
-
-@item character-class
-
-The character-class password quality check reads the configuration
-file stanza @samp{[password_quality]min_classes}. The policy requires
-the password to have characters from at least that many character
-classes. Default value if not given is 3.
-
-The four different characters classes are, uppercase, lowercase,
-number, special characters.
-
-@end itemize
-
-If you want to write your own shared object to check password
-policies, see the manual page @manpage{kadm5_pwcheck,3}.
-
-Code for a password quality checking function that uses the cracklib
-library can be found in @file{lib/kadm5/sample_password_check.c} in
-the source code distribution.  It requires that the cracklib library
-be built with the patch available at
-@url{ftp://ftp.pdc.kth.se/pub/krb/src/cracklib.patch}.
-
-A sample policy external program is included in
-@file{lib/kadm5/check-cracklib.pl}.
-
-If no password quality checking function is configured, the only check
-performed is that the password is at least six characters long.
-
-To check the password policy settings, use the command
-@command{password-quality} in @command{kadmin} program. The password
-verification is only performed locally, on the client.  It may be
-convenient to set the environment variable @samp{KRB5_CONFIG} to point
-to a test version of @file{krb5.conf} while you're testing the
-@samp{[password_quality]} stanza that way.
-
-@node Testing clients and servers, Slave Servers, Password changing, Setting up a realm
-@section Testing clients and servers
-
-Now you should be able to run all the clients and servers.  Refer to the
-appropriate man pages for information on how to use them.
-
-@node Slave Servers, Incremental propagation, Testing clients and servers, Setting up a realm
-@section Slave servers, Incremental propagation, Testing clients and servers, Setting up a realm
-
-It is desirable to have at least one backup (slave) server in case the
-master server fails. It is possible to have any number of such slave
-servers but more than three usually doesn't buy much more redundancy.
-
-All Kerberos servers for a realm must have the same database so that
-they present the same service to the users.  The
-@pindex hprop
-@command{hprop} program, running on the master, will propagate the database
-to the slaves, running
-@pindex hpropd
-@command{hpropd} processes.
-
-Every slave needs a database directory, the master key (if it was used
-for the database) and a keytab with the principal
-@samp{hprop/@var{hostname}}.  Add the principal with the
-@pindex ktutil
-@command{ktutil} command and start
-@pindex hpropd
-@command{hpropd}, as follows:
-
-@example
-slave# ktutil get -p foo/admin hprop/`hostname`
-slave# mkdir /var/heimdal
-slave# hpropd
-@end example
-
-The master will use the principal @samp{kadmin/hprop} to authenticate to
-the slaves.  This principal should be added when running @kbd{kadmin -l
-init} but if you do not have it in your database for whatever reason,
-please add it with @kbd{kadmin -l add}.
-
-Then run
-@pindex hprop
-@code{hprop} on the master:
-
-@example
-master# hprop slave
-@end example
-
-This was just an hands-on example to make sure that everything was
-working properly.  Doing it manually is of course the wrong way, and to
-automate this you will want to start
-@pindex hpropd
-@command{hpropd} from @command{inetd} on the slave(s) and regularly run
-@pindex hprop
-@command{hprop} on the master to regularly propagate the database.
-Starting the propagation once an hour from @command{cron} is probably a
-good idea.
-
-@node Incremental propagation, Encryption types and salting, Slave Servers, Setting up a realm
-@section Incremental propagation
-
-There is also a newer, and still somewhat experimental, mechanism for
-doing incremental propagation in Heimdal.  Instead of sending the whole
-database regularly, it sends the changes as they happen on the master to
-the slaves.  The master keeps track of all the changes by assigning a
-version number to every change to the database.  The slaves know which
-was the latest version they saw and in this way it can be determined if
-they are in sync or not.  A log of all the changes is kept on the master,
-and when a slave is at an older version than the oldest one in the
-log, the whole database has to be sent.
-
-Protocol-wise, all the slaves connect to the master and as a greeting
-tell it the latest version that they have (@samp{IHAVE} message).  The
-master then responds by sending all the changes between that version and
-the current version at the master (a series of @samp{FORYOU} messages)
-or the whole database in a @samp{TELLYOUEVERYTHING} message.  There is
-also a keep-alive protocol that makes sure all slaves are up and running.
-
-@subsection Configuring incremental propagation
-
-The program that runs on the master is @command{ipropd-master} and all
-clients run @command{ipropd-slave}.
-
-Create the file @file{/var/heimdal/slaves} on the master containing all
-the slaves that the database should be propagated to.  Each line contains
-the full name of the principal (for example
-@samp{iprop/hemligare.foo.se@@FOO.SE}).
-
-You should already have @samp{iprop/tcp} defined as 2121, in your
-@file{/etc/services}.  Otherwise, or if you need to use a different port
-for some peculiar reason, you can use the @kbd{--port} option.  This is
-useful when you have multiple realms to distribute from one server.
-
-Then you need to create those principals that you added in the
-configuration file.  Create one @samp{iprop/hostname} for the master and
-for every slave.
-
-
-@example
-master# /usr/heimdal/sbin/ktutil get iprop/`hostname`
-@end example
-
-The next step is to start the @command{ipropd-master} process on the master
-server.  The @command{ipropd-master} listens on the UNIX domain socket
-@file{/var/heimdal/signal} to know when changes have been made to the
-database so they can be propagated to the slaves.  There is also a
-safety feature of testing the version number regularly (every 30
-seconds) to see if it has been modified by some means that do not raise
-this signal.  Then, start @command{ipropd-slave} on all the slaves:
-
-@example
-master# /usr/heimdal/libexec/ipropd-master &
-slave#  /usr/heimdal/libexec/ipropd-slave master &
-@end example
-
-To manage the iprop log file you should use the @command{iprop-log}
-command. With it you can dump, truncate and replay the logfile.
-
-@node Encryption types and salting, Cross realm, Incremental propagation, Setting up a realm
-@section Encryption types and salting
-@cindex Salting
-@cindex Encryption types
-
-The encryption types that the KDC is going to assign by default is
-possible to change. Since the keys used for user authentication is
-salted the encryption types are described together with the salt
-strings.
-
-Salting is used to make it harder to pre-calculate all possible
-keys. Using a salt increases the search space to make it almost
-impossible to pre-calculate all keys. Salting is the process of mixing a
-public string (the salt) with the password, then sending it through an
-encryption type specific string-to-key function that will output the
-fixed size encryption key.
-
-In Kerberos 5 the salt is determined by the encryption type, except in
-some special cases.
-
-In @code{des} there is the Kerberos 4 salt
-(none at all) or the afs-salt (using the cell (realm in
-AFS lingo)).
-
-In @code{arcfour} (the encryption type that Microsoft Windows 2000 uses)
-there is no salt. This is to be compatible with NTLM keys in Windows
-NT 4.
-
-@code{[kadmin]default_keys} in @file{krb5.conf} controls
-what salting to use.
-
-The syntax of @code{[kadmin]default_keys} is
-@samp{[etype:]salt-type[:salt-string]}. @samp{etype} is the encryption
-type (des-cbc-crc, arcfour-hmac-md5, aes256-cts-hmac-sha1-96),
-@code{salt-type} is the type of salt (pw-salt or afs3-salt), and the
-salt-string is the string that will be used as salt (remember that if
-the salt is appended/prepended, the empty salt "" is the same thing as
-no salt at all).
-
-Common types of salting include
-
-@itemize @bullet
-@item @code{v4} (or @code{des:pw-salt:})
-
-The Kerberos 4 salting is using no salt at all. Reason there is colon
-at the end of the salt string is that it makes the salt the empty
-string (same as no salt).
-
-@item @code{v5} (or @code{pw-salt})
-
-@code{pw-salt} uses the default salt for each encryption type is
-specified for. If the encryption type @samp{etype} isn't given, all
-default encryption will be used.
-
-@item @code{afs3-salt}
-
-@code{afs3-salt} is the salt that is used with Transarc kaserver. It's
-the cell name appended to the password.
-
-@end itemize
-
-@node Cross realm, Transit policy, Encryption types and salting, Setting up a realm
-@section Cross realm
-@cindex Cross realm
-
-Suppose you reside in the realm @samp{MY.REALM}, how do you
-authenticate to a server in @samp{OTHER.REALM}? Having valid tickets in
-@samp{MY.REALM} allows you to communicate with Kerberised services in that
-realm. However, the computer in the other realm does not have a secret
-key shared with the Kerberos server in your realm.
-
-It is possible to share keys between two realms that trust each
-other. When a client program, such as @command{telnet} or @command{ssh},
-finds that the other computer is in a different realm, it will try to
-get a ticket granting ticket for that other realm, but from the local
-Kerberos server. With that ticket granting ticket, it will then obtain
-service tickets from the Kerberos server in the other realm.
-
-For a two way trust between @samp{MY.REALM} and @samp{OTHER.REALM}
-add the following principals to each realm. The principals should be
-@samp{krbtgt/OTHER.REALM@@MY.REALM} and
-@samp{krbtgt/MY.REALM@@OTHER.REALM} in @samp{MY.REALM}, and
-@samp{krbtgt/MY.REALM@@OTHER.REALM} and
-@samp{krbtgt/OTHER.REALM@@MY.REALM}in @samp{OTHER.REALM}.
-
-In Kerberos 5 the trust can be configured to be one way. So that
-users from @samp{MY.REALM} can authenticate to services in
-@samp{OTHER.REALM}, but not the opposite. In the example above, the
-@samp{krbtgt/MY.REALM@@OTHER.REALM} then should be removed.
-
-The two principals must have the same key, key version number, and the
-same set of encryption types. Remember to transfer the two keys in a
-safe manner.
-
-@example
-vr$ klist
-Credentials cache: FILE:/tmp/krb5cc_913.console
-        Principal: lha@@E.KTH.SE
-
-  Issued           Expires          Principal
-May  3 13:55:52  May  3 23:55:54  krbtgt/E.KTH.SE@@E.KTH.SE
-
-vr$ telnet -l lha hummel.it.su.se
-Trying 2001:6b0:5:1095:250:fcff:fe24:dbf...
-Connected to hummel.it.su.se.
-Escape character is '^]'.
-Waiting for encryption to be negotiated...
-[ Trying mutual KERBEROS5 (host/hummel.it.su.se@@SU.SE)... ]
-[ Kerberos V5 accepts you as ``lha@@E.KTH.SE'' ]
-Encryption negotiated.
-Last login: Sat May  3 14:11:47 from vr.l.nxs.se
-hummel$ exit
-
-vr$ klist
-Credentials cache: FILE:/tmp/krb5cc_913.console
-        Principal: lha@@E.KTH.SE
-
-  Issued           Expires          Principal
-May  3 13:55:52  May  3 23:55:54  krbtgt/E.KTH.SE@@E.KTH.SE
-May  3 13:55:56  May  3 23:55:54  krbtgt/SU.SE@@E.KTH.SE
-May  3 14:10:54  May  3 23:55:54  host/hummel.it.su.se@@SU.SE
-
-@end example
-
-@node Transit policy, Setting up DNS, Cross realm, Setting up a realm
-@section Transit policy
-@cindex Transit policy
-
-If you want to use cross realm authentication through an intermediate
-realm, it must be explicitly allowed by either the KDCs or the server
-receiving the request. This is done in @file{krb5.conf} in the
-@code{[capaths]} section.
-
-When the ticket transits through a realm to another realm, the
-destination realm adds its peer to the "transited-realms" field in the
-ticket. The field is unordered, since there is no way to know if
-know if one of the transited-realms changed the order of the list.
-
-The syntax for @code{[capaths]} section:
-
-@example
-[capaths]
-        CLIENT-REALM = @{
-                SERVER-REALM = PERMITTED-CROSS-REALMS ...
-        @}
-@end example
-
-The realm @code{STACKEN.KTH.SE} allows clients from @code{SU.SE} and
-@code{DSV.SU.SE} to cross it. Since @code{STACKEN.KTH.SE} only has
-direct cross realm setup with @code{KTH.SE}, and @code{DSV.SU.SE} only
-has direct cross realm setup with @code{SU.SE} they need to use both
-@code{SU.SE} and @code{KTH.SE} as transit realms.
-
-@example
-[capaths]
-	SU.SE = @{
-                    STACKEN.KTH.SE = KTH.SE
-	@}
-	DSV.SU.SE = @{
-                    STACKEN.KTH.SE = SU.SE KTH.SE
-	@}
-
-@end example
-
-The order of the @code{PERMITTED-CROSS-REALMS} is not important when
-doing transit cross realm verification.
-
-However, the order is important when the @code{[capaths]} section is used
-to figure out the intermediate realm to go to when doing multi-realm
-transit. When figuring out the next realm, the first realm of the list
-of @code{PERMITTED-CROSS-REALMS} is chosen. This is done in both the
-client kerberos library and the KDC.
-
-@c To test the cross realm configuration, use:
-@c    kmumble transit-check client server transit-realms ...
-
-@node Setting up DNS, Using LDAP to store the database, Transit policy, Setting up a realm
-@section Setting up DNS
-@cindex Setting up DNS
-
-@subsection Using DNS to find KDC
-
-If there is information about where to find the KDC or kadmind for a
-realm in the @file{krb5.conf} for a realm, that information will be
-preferred, and DNS will not be queried.
-
-Heimdal will try to use DNS to find the KDCs for a realm. First it
-will try to find a @code{SRV} resource record (RR) for the realm. If no
-SRV RRs are found, it will fall back to looking for an @code{A} RR for
-a machine named kerberos.REALM, and then kerberos-1.REALM, etc
-
-Adding this information to DNS minimises the client configuration (in
-the common case, resulting in no configuration needed) and allows the
-system administrator to change the number of KDCs and on what machines
-they are running without caring about clients.
-
-The downside of using DNS is that the client might be fooled to use the
-wrong server if someone fakes DNS replies/data, but storing the IP
-addresses of the KDC on all the clients makes it very hard to change
-the infrastructure.
-
-An example of the configuration for the realm @code{EXAMPLE.COM}:
-
-@example
-
-$ORIGIN example.com.
-_kerberos._tcp          SRV     10 1 88 kerberos.example.com.
-_kerberos._udp          SRV     10 1 88 kerberos.example.com.
-_kerberos._tcp          SRV     10 1 88 kerberos-1.example.com.
-_kerberos._udp          SRV     10 1 88 kerberos-1.example.com.
-_kpasswd._udp           SRV     10 1 464 kerberos.example.com.
-_kerberos-adm._tcp	SRV	10 1 749 kerberos.example.com.
-
-@end example
-
-More information about DNS SRV resource records can be found in
-RFC-2782 (A DNS RR for specifying the location of services (DNS SRV)).
-
-@subsection Using DNS to map hostname to Kerberos realm
-
-Heimdal also supports a way to lookup a realm from a hostname. This to
-minimise configuration needed on clients. Using this has the drawback
-that clients can be redirected by an attacker to realms within the
-same cross realm trust and made to believe they are talking to the
-right server (since Kerberos authentication will succeed).
-
-An example configuration that informs clients that for the realms
-it.example.com and srv.example.com, they should use the realm
-EXAMPLE.COM:
-
-@example
-
-$ORIGIN example.com.
-_kerberos.it		TXT     "EXAMPLE.COM"
-_kerberos.srv		TXT     "EXAMPLE.COM"
-
-@end example
-
-@node Using LDAP to store the database, Providing Kerberos credentials to servers and programs, Setting up DNS, Setting up a realm
-@section Using LDAP to store the database
-@cindex Using the LDAP backend
-
-This document describes how to install the LDAP backend for
-Heimdal. Note that before attempting to configure such an
-installation, you should be aware of the implications of storing
-private information (such as users' keys) in a directory service
-primarily designed for public information. Nonetheless, with a
-suitable authorisation policy, it is possible to set this up in a
-secure fashion. A knowledge of LDAP, Kerberos, and C is necessary to
-install this backend. The HDB schema was devised by Leif Johansson.
-
-Requirements:
-
-@itemize @bullet
-
-@item
-A current release of Heimdal, configured with
-@code{--with-openldap=/usr/local} (adjust according to where you have
-installed OpenLDAP).
-
-You can verify that you manage to configure LDAP support by running
-@file{kdc --builtin-hdb}, and checking that @samp{ldap:} is one entry
-in the list.
-
-Its also possible to configure the ldap backend as a shared module,
-see option --hdb-openldap-module to configure.
-
-@item
-OpenLDAP 2.0.x. Configure OpenLDAP with @kbd{--enable-local} to enable the
-local transport. (A patch to support SASL EXTERNAL authentication is
-necessary in order to use OpenLDAP 2.1.x.)
-
-@item
-Add the hdb schema to the LDAP server, it's included in the source-tree
-in @file{lib/hdb/hdb.schema}. Example from slapd.conf:
-
-@example
-include /usr/local/etc/openldap/schema/hdb.schema
-@end example
-
-@item
-Configure the LDAP server ACLs to accept writes from clients over the
-local transport. For example:
-
-@example
-access to *
-        by dn.exact="uid=heimdal,dc=services,dc=example,dc=com" write
-        ...
-
-sasl-regexp "uidNumber=0\\\+gidNumber=.*,cn=peercred,cn=external,cn=auth"
-	"uid=heimdal,dc=services,dc=example,dc=com"
-
-@end example
-
-The sasl-regexp is for mapping between the SASL/EXTERNAL and a user in
-a tree.  The user that the key is mapped to should be have a
-krb5Principal aux object with krb5PrincipalName set so that the
-``creator'' and ``modifier'' is right in @file{kadmin}.
-
-Another option is to create an admins group and add the dn to that
-group.
-
-Since Heimdal talks to the LDAP server over a UNIX domain socket, and
-uses external sasl authentication, it's not possible to require
-security layer quality (ssf in cyrus-sasl lingo). So that requirement
-has to be turned off in OpenLDAP @command{slapd} configuration file
-@file{slapd.conf}.
-
-@example
-sasl-secprops minssf=0
-@end example
-
-@item
-
-Start @command{slapd} with the local listener (as well as the default TCP/IP
-listener on port 389) as follows:
-
-@example
-    slapd -h "ldapi:/// ldap:///"
-@end example
-
-Note: These is a bug in @command{slapd} where it appears to corrupt the krb5Key
-binary attribute on shutdown. This may be related to our use of the V3
-schema definition syntax instead of the old UMich-style, V2 syntax.
-
-@item
-You should specify the distinguished name under which your
-principals will be stored in @file{krb5.conf}. Also you need to
-enter the path to the kadmin acl file:
-
-
-@example
-[kdc]
-        database = @{
-                dbname = ldap:ou=KerberosPrincipals,dc=example,dc=com
-                hdb-ldap-structural-object = inetOrgPerson
-                acl_file = /path/to/kadmind.acl
-                mkey_file = /path/to/mkey
-        @}
-@end example
-
-@samp{mkey_file} can be excluded if you feel that you trust your ldap
-directory to have the raw keys inside it.  The
-hdb-ldap-structural-object is not necessary if you do not need Samba
-comatibility.
-
-
-
-@item
-Once you have built Heimdal and started the LDAP server, run kadmin
-(as usual) to initialise the database. Note that the instructions for
-stashing a master key are as per any Heimdal installation.
-
-@example
-kdc# kadmin -l
-kadmin> init EXAMPLE.COM
-Realm max ticket life [unlimited]:
-Realm max renewable ticket life [unlimited]:
-kadmin> ank lukeh
-Max ticket life [1 day]:
-Max renewable life [1 week]:
-Principal expiration time [never]:
-Password expiration time [never]:
-Attributes []:
-lukeh@@EXAMPLE.COM's Password:
-Verifying password - lukeh@@EXAMPLE.COM's Password:
-kadmin> exit
-@end example
-
-Verify that the principal database has indeed been stored in the
-directory with the following command:
-
-@example
-kdc# ldapsearch -L -h localhost -D cn=manager \
- -w secret -b ou=KerberosPrincipals,dc=example,dc=com \
- 'objectclass=krb5KDCEntry'
-@end example
-
-@item
-Now consider adding indexes to the database to speed up the access, at
-least theses should be added to slapd.conf.
-
-@example
-index	objectClass		eq
-index	cn			eq,sub,pres
-index	uid			eq,sub,pres
-index	displayName		eq,sub,pres
-index	krb5PrincipalName	eq
-@end example
-
-@end itemize
-
-@subsection Troubleshooting guide
-
-@url{https://sec.miljovern.no/bin/view/Info/TroubleshootingGuide}
-
-
-@subsection Using Samba LDAP password database
-@cindex Samba
-
-@c @node Using Samba LDAP password database, Providing Kerberos credentials to servers and programs, Using LDAP to store the database, Setting up a realm
-@c @section Using Samba LDAP password database
-
-The Samba domain and the Kerberos realm can have different names since
-arcfour's string to key functions principal/realm independent.  So now
-will be your first and only chance name your Kerberos realm without
-needing to deal with old configuration files.
-
-First, you should set up Samba and get that working with LDAP backend.
-
-Now you can proceed as in @xref{Using LDAP to store the database}.
-Heimdal will pick up the Samba LDAP entries if they are in the same
-search space as the Kerberos entries.
-
-@node Providing Kerberos credentials to servers and programs, Setting up PK-INIT, Using LDAP to store the database, Setting up a realm
-@section Providing Kerberos credentials to servers and programs
-
-Some services require Kerberos credentials when they start to make
-connections to other services or need to use them when they have started.
-
-The easiest way to get tickets for a service is to store the key in a
-keytab. Both ktutil get and kadmin ext can be used to get a
-keytab. ktutil get is better in that way it changes the key/password
-for the user. This is also the problem with ktutil. If ktutil is used
-for the same service principal on several hosts, they keytab will only
-be useful on the last host. In that case, run the extract command on
-one host and then securely copy the keytab around to all other hosts
-that need it.
-
-@example
-host# ktutil -k /etc/krb5-service.keytab \
-      get -p lha/admin@@EXAMPLE.ORG service-principal@@EXAMPLE.ORG
-lha/admin@@EXAMPLE.ORG's Password:
-@end example
-
-To get a Kerberos credential file for the service, use kinit in the
-@kbd{--keytab} mode. This will not ask for a password but instead fetch the
-key from the keytab.
-
-@example
-service@@host$ kinit --cache=/var/run/service_krb5_cache \
-               --keytab=/etc/krb5-service.keytab \
-       service-principal@@EXAMPLE.ORG
-@end example
-
-Long running services might need credentials longer then the
-expiration time of the tickets. kinit can run in a mode that refreshes
-the tickets before they expire. This is useful for services that write
-into AFS and other distributed file systems using Kerberos. To run the
-long running script, just append the program and arguments (if any)
-after the principal. kinit will stop refreshing credentials and remove
-the credentials when the script-to-start-service exits.
-
-@example
-service@@host$ kinit --cache=/var/run/service_krb5_cache \
-       --keytab=/etc/krb5-service.keytab \
-       service-principal@@EXAMPLE.ORG \
-       script-to-start-service argument1 argument2
-@end example
-
-
-@node Setting up PK-INIT, , Providing Kerberos credentials to servers and programs, Setting up a realm
-@section Setting up PK-INIT
-
-PK-INIT is levering the existing PKI infrastructure to use
-certificates to get the initial ticket, that is usually the krbtgt.
-
-To use PK-INIT you must first have a PKI, so if you don't have one,
-it is time to create it. Note that you should read the whole chapter
-of the document to see the requirements on the CA software.
-
-There needs to exist a mapping between the certificate and what
-principals that certificate is allowed to use. There are several ways
-to do this. The administrator can use a configuration file, storing
-the principal in the SubjectAltName extension of the certificate, or store the
-mapping in the principals entry in the kerberos database.
-
-@section Certificates
-
-This section documents the requirements on the KDC and client
-certificates and the format used in the id-pkinit-san OtherName
-extention.
-
-@subsection KDC certificate
-
-The certificate for the KDC have serveral requirements.
-
-First the certificate should have an Extended Key Usage (EKU)
-id-pkkdcekuoid (1.3.6.1.5.2.3.5) set. Second there must be a
-subjectAltName otherName using oid id-pkinit-san (1.3.6.1.5.2.2) in
-the type field and a DER encoded KRB5PrincipalName that matches the
-name of the TGS of the target realm.
-
-Both of these two requirements are not required by the standard to be
-checked by the client if it have external information what the
-certificate the KDC is supposed to be used. So it's in the interest of
-minimum amount of configuration on the clients they should be included.
-
-Remember that if the client would accept any certificate as the KDC's
-certificate, the client could be fooled into trusting something that
-isn't a KDC and thus expose the user to giving away information (like
-password or other private information) that it is supposed to secret.
-
-Also, if the certificate has a nameConstraints extention with a
-Generalname with dNSName or iPAdress it must match the hostname or
-adress of the KDC.
-
-@subsection Client certificate
-
-The client certificate may need to have a EKU id-pkekuoid
-(1.3.6.1.5.2.3.4) set depending on the certifiate on the KDC.
-
-It possible to store the principal (if allowed by the KDC) in the
-certificate and thus delegate responsibility to do the mapping between
-certificates and principals to the CA.
-
-@subsubsection Using KRB5PrincipalName in id-pkinit-san
-
-OtherName extention in the GeneralName is used to do the
-mapping between certifiate and principal in the certifiate or storing
-the krbtgt principal in the KDC certificate.
-
-The principal is stored in a SubjectAltName in the certificate using
-OtherName. The oid in the type is id-pkinit-san.
-
-@example
-id-pkinit-san OBJECT IDENTIFIER ::= @{ iso (1) org (3) dod (6)
-internet (1) security (5) kerberosv5 (2) 2 @}
-@end example
-
-The data part of the OtherName is filled with the following DER
-encoded ASN.1 structure:
-
-@example
-KRB5PrincipalName ::= SEQUENCE @{
-	realm [0] Realm,
-	principalName [1] PrincipalName
-@}
-@end example
-
-where Realm and PrincipalName is defined by the Kerberos ASN.1 specification.
-
-@section Naming certificate using hx509
-
-hx509 is the X.509 software used in Heimdal to handle
-certificates. hx509 uses different syntaxes to specify the different
-formats the certificates are stored in and what formats they exist in.
-
-There are several formats that can be used, PEM, embedded into PKCS12
-files, embedded into PKCS11 devices and raw DER encoded certificates.
-Below is a list of types to use.
-
-
-@table @asis
-
-@item DIR:
-
-DIR is reading all certificates in a directory that is DER or PEM
-formatted.
-
-The main feature of DIR is that the directory is read on demand when
-iterating over certificates, that way applictions can for some cases
-avoid to store all certificates in memory. It's very useful for tests
-that iterate over larger amount of certificates.
-
-Syntax is:
-
-@example
-DIR:/path/to/der/files
-@end example
-
-@item FILE:
-
-FILE: is used to have the lib pick up a certificate chain and a
-private key. The file can be either a PEM (openssl) file or a raw DER
-encoded certificate. If it's a PEM file it can contain several keys and
-certificates and the code will try to match the private key and
-certificate together.
-
-Its useful to have one PEM file that contains all the trust anchors.
-
-Syntax is:
-
-@example
-FILE:certificate.pem,private-key.key,other-cert.pem,....
-@end example
-
-@item PKCS11:
-
-PKCS11: is used to handle smartcards via PKCS11 drivers, for example
-soft-token, opensc, or muscle. The default is to use all slots on the
-device/token.
-
-Syntax is:
-
-@example
-PKCS11:shared-object.so
-@end example
-
-@item PKCS12:
-
-PKCS12: is used to handle PKCS12 files. PKCS12 files commonly have the
-extension pfx or p12.
-
-Syntax is:
-
-@example
-PKCS12:/path/to/file.pfx
-@end example
-
-@end table
-
-@section Configure the Kerberos software
-
-First configure the client's trust anchors and what parameters to
-verify, see subsection below how to do that. Now you can use kinit to
-get yourself tickets. One example how that can look like is:
-
-@example
-$ kinit -C FILE:$HOME/.certs/lha.crt,$HOME/.certs/lha.key lha@@EXAMPLE.ORG
-Enter your private key passphrase:
-: lha@@nutcracker ; klist
-Credentials cache: FILE:/tmp/krb5cc_19100a
-        Principal: lha@@EXAMPLE.ORG
-
-  Issued           Expires          Principal
-Apr 20 02:08:08  Apr 20 12:08:08  krbtgt/EXAMPLE.ORG@@EXAMPLE.ORG
-@end example
-
-Using PKCS11 it can look like this instead:
-
-@example
-$ kinit -C PKCS11:/tmp/pkcs11/lib/soft-pkcs11.so lha@@EXAMPLE.ORG
-PIN code for SoftToken (slot):
-$ klist
-Credentials cache: API:4
-        Principal: lha@@EXAMPLE.ORG
-
-  Issued           Expires          Principal
-Mar 26 23:40:10  Mar 27 09:40:10  krbtgt/EXAMPLE.ORG@@EXAMPLE.ORG
-@end example
-
-
-Write about the kdc.
-
-@section Configure the client
-
-@example
-[appdefaults]
-	pkinit_anchors = FILE:/path/to/trust-anchors.pem
-
-[realms]
-        EXAMPLE.COM = @{
-		pkinit_require_eku = true
-		pkinit_require_krbtgt_otherName = true
-		pkinit_win2k = no
-		pkinit_win2k_require_binding = yes
-	@}
-
-@end example
-
-@section Configure the KDC
-
-@example
-[kdc]
-	enable-pkinit = yes
-	pkinit_identity = FILE:/secure/kdc.crt,/secure/kdc.key
-	pkinit_anchors = FILE:/path/to/trust-anchors.pem
-	pkinit_pool = PKCS12:/path/to/useful-intermediate-certs.pfx
-	pkinit_pool = FILE:/path/to/other-useful-intermediate-certs.pem
-	pkinit_allow_proxy_certificate = false
-	pkinit_win2k_require_binding = yes
-@end example
-
-@subsection Using pki-mapping file
-
-Note that the file name is space sensitive.
-
-@example
-# cat /var/heimdal/pki-mapping
-# comments starts with #
-lha@@EXAMPLE.ORG:C=SE,O=Stockholm universitet,CN=Love,UID=lha
-lha@@EXAMPLE.ORG:CN=Love,UID=lha
-@end example
-
-@subsection Using the Kerberos database
-
-@section Use hxtool to create certificates
-
-@subsection Generate certificates
-
-First you need to generate a CA certificate, change the --subject to
-something appropriate, the CA certificate will be valid for 10 years.
-
-You need to change --subject in the command below.
-
-@example
-hxtool issue-certificate \
-    --self-signed \
-    --issue-ca \
-    --generate-key=rsa \
-    --subject="CN=CA,DC=test,DC=h5l,DC=se" \
-    --lifetime=10years \
-    --certificate="FILE:ca.pem"
-@end example
-
-The KDC needs to have a certificate, so generate a certificate of the
-type ``pkinit-kdc'' and set the PK-INIT specifial SubjectAltName to the
-name of the krbtgt of the realm.
-
-You need to change --subject and --pk-init-principal in the command below.
-
-@example
-hxtool issue-certificate \
-    --ca-certificate=FILE:ca.pem \
-    --generate-key=rsa \
-    --type="pkinit-kdc" \
-    --pk-init-principal="krbtgt/TEST.H5L.SE@@TEST.H5L.SE" \
-    --subject="uid=kdc,DC=test,DC=h5l,DC=se" \
-    --certificate="FILE:kdc.pem"
-@end example
-
-The users also needs to have a certificate, so generate a certificate
-of the type ``pkinit-client''. The client doesn't need to have the PK-INIT
-SubjectAltName set, you can have the Subject DN in the ACL file
-(pki-mapping) instead.
-
-You need to change --subject and --pk-init-principal in the command below.
-
-@example
-hxtool issue-certificate \
-    --ca-certificate=FILE:ca.pem \
-    --generate-key=rsa \
-    --type="pkinit-client" \
-    --pk-init-principal="lha@@TEST.H5L.SE" \
-    --subject="uid=lha,DC=test,DC=h5l,DC=se" \
-    --certificate="FILE:user.pem"
-@end example
-
-@subsection Validate the certificate
-
-hxtool also contains a tool that will validate certificates according to
-rules from the PKIX document. These checks are not complete, but a good test
-to check if you got all of the basic bits right in your certificates.
-
-@example
-hxtool validate FILE:user.pem
-@end example
-
-@section Use OpenSSL to create certificates
-
-This section tries to give the CA owners hints how to create
-certificates using OpenSSL (or CA software based on OpenSSL).
-
-@subsection Using OpenSSL to create certificates with krb5PrincipalName
-
-To make OpenSSL create certificates with krb5PrincipalName use
-@file{openssl.cnf} as described below. To see a complete example of
-creating client and KDC certificates, see the test-data generation
-script @file{lib/hx509/data/gen-req.sh} in the source-tree. The
-certicates it creates are used to test the PK-INIT functionality in
-@file{tests/kdc/check-kdc.in}.
-
-To use this example you have to use OpenSSL 0.9.8a or later.
-
-@example
-
-[user_certificate]
-subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:princ_name
-
-[princ_name]
-realm = EXP:0, GeneralString:MY.REALM
-principal_name = EXP:1, SEQUENCE:principal_seq
-
-[principal_seq]
-name_type = EXP:0, INTEGER:1
-name_string = EXP:1, SEQUENCE:principals
-
-[principals]
-princ1 = GeneralString:userid
-
-@end example
-
-Command usage
-
-@example
-openssl x509 -extensions user_certificate
-openssl ca -extensions user_certificate
-@end example
-
-
-@c --- ms certificate
-@c
-@c [ new_oids ]
-@c msCertificateTemplateName       = 1.3.6.1.4.1.311.20.2
-@c
-@c
-@c [ req_smartcard ]
-@c keyUsage                = digitalSignature, keyEncipherment
-@c extendedKeyUsage        = msSmartcardLogin, clientAuth
-@c msCertificateTemplateName       = ASN1:BMP:SmartcardLogon
-@c subjectAltName          = otherName:msUPN;UTF8:lukeh@dsg.padl.com
-@c #subjectAltName         = email:copy
-
-
-@section Using PK-INIT with Windows
-
-@subsection Client configration
-
-Clients using a Windows KDC with PK-INIT need configuration since
-windows uses pre-standard format and this can't be autodetected.
-
-The pkinit_win2k_require_binding option requires the reply for the KDC
-to be of the new, secure, type that binds the request to reply. Before
-clients should fake the reply from the KDC. To use this option you
-have to apply a fix from Microsoft.
-
-@example
-[realms]
-        MY.MS.REALM = @{
-                pkinit_win2k = yes
-                pkinit_win2k_require_binding = no
-	@}
-@end example
-
-@subsection Certificates
-
-The client certificates need to have the extended keyusage ``Microsoft
-Smartcardlogin'' (openssl have the oid shortname msSmartcardLogin).
-
-See Microsoft Knowledge Base Article - 281245 ``Guidelines for Enabling
-Smart Card Logon with Third-Party Certification Authorities'' for a
-more extensive description of how set setup an external CA to it
-includes all information that will make a Windows KDC happy.
-
-@subsection Configure Windows 2000 CA
-
-To enable Microsoft Smartcardlogin> for certificates in your Windows
-2000 CA, you want to look at Microsoft Knowledge Base Article -
-313274 ``HOW TO: Configure a Certification Authority to Issue
-Smart Card Certificates in Windows''.
diff --git a/crypto/heimdal/doc/vars.texi b/crypto/heimdal/doc/vars.texi
deleted file mode 100755
index c2e6671..0000000
--- a/crypto/heimdal/doc/vars.texi
+++ /dev/null
@@ -1,7 +0,0 @@
-
-@c
-@c Variables depending on installation
-@c
-
-@set dbdir /var/heimdal
-@set PACKAGE_VERSION 1.1
diff --git a/crypto/heimdal/doc/vars.tin b/crypto/heimdal/doc/vars.tin
deleted file mode 100644
index d3e67b7..0000000
--- a/crypto/heimdal/doc/vars.tin
+++ /dev/null
@@ -1,7 +0,0 @@
-
-@c
-@c Variables depending on installation
-@c
-
-@set dbdir @dbdir@
-@set PACKAGE_VERSION @PACKAGE_VERSION@
diff --git a/crypto/heimdal/doc/whatis.texi b/crypto/heimdal/doc/whatis.texi
deleted file mode 100644
index 307c5a2..0000000
--- a/crypto/heimdal/doc/whatis.texi
+++ /dev/null
@@ -1,161 +0,0 @@
-@c $Id: whatis.texi 16769 2006-02-27 12:26:50Z joda $
-
-@node What is Kerberos?, Building and Installing, Introduction, Top
-@chapter What is Kerberos?
-
-@quotation
-@flushleft
-        Now this Cerberus had three heads of dogs,
-        the tail of a dragon, and on his back the
-        heads of all sorts of snakes.
-        --- Pseudo-Apollodorus Library 2.5.12
-@end flushleft
-@end quotation
-
-Kerberos is a system for authenticating users and services on a network.
-It is built upon the assumption that the network is ``unsafe''.  For
-example, data sent over the network can be eavesdropped and altered, and
-addresses can also be faked.  Therefore they cannot be used for
-authentication purposes.
-@cindex authentication
-
-Kerberos is a trusted third-party service.  That means that there is a
-third party (the kerberos server) that is trusted by all the entities on
-the network (users and services, usually called @dfn{principals}).  All
-principals share a secret password (or key) with the kerberos server and
-this enables principals to verify that the messages from the kerberos
-server are authentic.  Thus trusting the kerberos server, users and
-services can authenticate each other.
-
-@section Basic mechanism
-
-@ifinfo
-@macro sub{arg}
-<\arg\>
-@end macro
-@end ifinfo
-
-@tex
-@def@xsub#1{$_{#1}$}
-@global@let@sub=@xsub
-@end tex
-
-@ifhtml
-@macro sub{arg}
-@html
-<sub>\arg\</sub>
-@end html
-@end macro
-@end ifhtml
-
-@c ifdocbook
-@c macro sub{arg}
-@c docbook
-@c <subscript>\arg\</subscript>
-@c end docbook
-@c end macro
-@c end ifdocbook
-
-@quotation
-@strong{Note} This discussion is about Kerberos version 4, but version
-5 works similarly.
-@end quotation
-
-In Kerberos, principals use @dfn{tickets} to prove that they are who
-they claim to be. In the following example, @var{A} is the initiator of
-the authentication exchange, usually a user, and @var{B} is the service
-that @var{A} wishes to use.
-
-To obtain a ticket for a specific service, @var{A} sends a ticket
-request to the kerberos server. The request contains @var{A}'s and
-@var{B}'s names (along with some other fields). The kerberos server
-checks that both @var{A} and @var{B} are valid principals.
-
-Having verified the validity of the principals, it creates a packet
-containing @var{A}'s and @var{B}'s names, @var{A}'s network address
-(@var{A@sub{addr}}), the current time (@var{t@sub{issue}}), the lifetime
-of the ticket (@var{life}), and a secret @dfn{session key}
-@cindex session key
-(@var{K@sub{AB}}). This packet is encrypted with @var{B}'s secret key
-(@var{K@sub{B}}).  The actual ticket (@var{T@sub{AB}}) looks like this:
-(@{@var{A}, @var{B}, @var{A@sub{addr}}, @var{t@sub{issue}}, @var{life},
-@var{K@sub{AB}}@}@var{K@sub{B}}).
-
-The reply to @var{A} consists of the ticket (@var{T@sub{AB}}), @var{B}'s
-name, the current time, the lifetime of the ticket, and the session key, all
-encrypted in @var{A}'s secret key (@{@var{B}, @var{t@sub{issue}},
-@var{life}, @var{K@sub{AB}}, @var{T@sub{AB}}@}@var{K@sub{A}}). @var{A}
-decrypts the reply and retains it for later use.
-
-@sp 1
-
-Before sending a message to @var{B}, @var{A} creates an authenticator
-consisting of @var{A}'s name, @var{A}'s address, the current time, and a
-``checksum'' chosen by @var{A}, all encrypted with the secret session
-key (@{@var{A}, @var{A@sub{addr}}, @var{t@sub{current}},
-@var{checksum}@}@var{K@sub{AB}}). This is sent together with the ticket
-received from the kerberos server to @var{B}.  Upon reception, @var{B}
-decrypts the ticket using @var{B}'s secret key.  Since the ticket
-contains the session key that the authenticator was encrypted with,
-@var{B} can now also decrypt the authenticator. To verify that @var{A}
-really is @var{A}, @var{B} now has to compare the contents of the ticket
-with that of the authenticator. If everything matches, @var{B} now
-considers @var{A} as properly authenticated.
-
-@c (here we should have some more explanations)
-
-@section Different attacks
-
-@subheading Impersonating A
-
-An impostor, @var{C} could steal the authenticator and the ticket as it
-is transmitted across the network, and use them to impersonate
-@var{A}. The address in the ticket and the authenticator was added to
-make it more difficult to perform this attack.  To succeed @var{C} will
-have to either use the same machine as @var{A} or fake the source
-addresses of the packets. By including the time stamp in the
-authenticator, @var{C} does not have much time in which to mount the
-attack.
-
-@subheading Impersonating B
-
-@var{C} can hijack @var{B}'s network address, and when @var{A} sends
-her credentials, @var{C} just pretend to verify them. @var{C} can't
-be sure that she is talking to @var{A}.
-
-@section Defence strategies
-
-It would be possible to add a @dfn{replay cache}
-@cindex replay cache
-to the server side.  The idea is to save the authenticators sent during
-the last few minutes, so that @var{B} can detect when someone is trying
-to retransmit an already used message. This is somewhat impractical
-(mostly regarding efficiency), and is not part of Kerberos 4; MIT
-Kerberos 5 contains it.
-
-To authenticate @var{B}, @var{A} might request that @var{B} sends
-something back that proves that @var{B} has access to the session
-key. An example of this is the checksum that @var{A} sent as part of the
-authenticator. One typical procedure is to add one to the checksum,
-encrypt it with the session key and send it back to @var{A}.  This is
-called @dfn{mutual authentication}.
-
-The session key can also be used to add cryptographic checksums to the
-messages sent between @var{A} and @var{B} (known as @dfn{message
-integrity}).  Encryption can also be added (@dfn{message
-confidentiality}). This is probably the best approach in all cases.
-@cindex integrity
-@cindex confidentiality
-
-@section Further reading
-
-The original paper on Kerberos from 1988 is @cite{Kerberos: An
-Authentication Service for Open Network Systems}, by Jennifer Steiner,
-Clifford Neuman and Jeffrey I. Schiller.
-
-A less technical description can be found in @cite{Designing an
-Authentication System: a Dialogue in Four Scenes} by Bill Bryant, also
-from 1988.
-
-These documents can be found on our web-page at
-@url{http://www.pdc.kth.se/kth-krb/}.
diff --git a/crypto/heimdal/doc/win2k.texi b/crypto/heimdal/doc/win2k.texi
deleted file mode 100644
index 7bc9b2a..0000000
--- a/crypto/heimdal/doc/win2k.texi
+++ /dev/null
@@ -1,306 +0,0 @@
-@c $Id: win2k.texi 21991 2007-10-19 13:28:07Z lha $
-
-@node Windows 2000 compatability, Programming with Kerberos, Kerberos 4 issues, Top
-@comment  node-name,  next,  previous,  up
-@chapter Windows 2000 compatability
-
-Windows 2000 (formerly known as Windows NT 5) from Microsoft implements
-Kerberos 5.  Their implementation, however, has some quirks,
-peculiarities, and bugs.  This chapter is a short summary of the things
-that we have found out while trying to test Heimdal against Windows
-2000.  Another big problem with the Kerberos implementation in Windows
-2000 is that the available documentation is more focused on getting
-things to work rather than how they work, and not that useful in figuring
-out how things really work.
-
-This information should apply to Heimdal @value{VERSION} and Windows
-2000 Professional.  It's of course subject to change all the time and
-mostly consists of our not so inspired guesses.  Hopefully it's still
-somewhat useful.
-
-@menu
-* Configuring Windows 2000 to use a Heimdal KDC::  
-* Inter-Realm keys (trust) between Windows 2000 and a Heimdal KDC::  
-* Create account mappings::     
-* Encryption types::            
-* Authorisation data::          
-* Quirks of Windows 2000 KDC::  
-* Useful links when reading about the Windows 2000::  
-@end menu
-
-@node Configuring Windows 2000 to use a Heimdal KDC, Inter-Realm keys (trust) between Windows 2000 and a Heimdal KDC, Windows 2000 compatability, Windows 2000 compatability
-@comment node-name, next, precious, up
-@section Configuring Windows 2000 to use a Heimdal KDC
-
-You need the command line program called @command{ksetup.exe} which is available
-in the file @file{SUPPORT/TOOLS/SUPPORT.CAB} on the Windows 2000 Professional
-CD-ROM. This program is used to configure the Kerberos settings on a
-Workstation.
-
-@command{Ksetup} store the domain information under the registry key:
-@code{HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\Kerberos\Domains}.
-
-Use the @command{kadmin} program in Heimdal to create a host principal in the
-Kerberos realm.
-
-@example
-unix% kadmin
-kadmin> ank --password=password host/datan.example.com
-@end example
-
-The name @samp{datan.example.com} should be replaced with DNS name of
-the workstation.
-
-You must configure the workstation as a member of a workgroup, as opposed
-to a member in an NT domain, and specify the KDC server of the realm
-as follows:
-@example
-C:> ksetup /setdomain EXAMPLE.COM
-C:> ksetup /addkdc EXAMPLE.COM kdc.example.com
-@end example
-
-Set the machine password, i.e.@: create the local keytab:
-@example
-C:> ksetup /SetComputerPassword password
-@end example
-
-The password used in @kbd{ksetup /setmachpassword} must be the same
-as the password used in the @kbd{kadmin ank} command.
-
-The workstation must now be rebooted.
-
-A mapping between local NT users and Kerberos principals must be specified.
-You have two choices. First:
-
-@example
-C:> ksetup /mapuser user@@MY.REALM nt_user
-@end example
-
-This will map a user to a specific principal; this allows you to have
-other usernames in the realm than in your NT user database. (Don't ask
-me why on earth you would want that@enddots{})
-
-You can also say:
-@example
-C:> ksetup /mapuser * *
-@end example
-The Windows machine will now map any user to the corresponding principal,
-for example @samp{nisse} to the principal @samp{nisse@@MY.REALM}.
-(This is most likely what you want.)
-
-@node Inter-Realm keys (trust) between Windows 2000 and a Heimdal KDC, Create account mappings, Configuring Windows 2000 to use a Heimdal KDC, Windows 2000 compatability
-@comment node-name, next, precious, up
-@section Inter-Realm keys (trust) between Windows 2000 and a Heimdal KDC
-
-See also the Step-by-Step guide from Microsoft, referenced below.
-
-Install Windows 2000, and create a new controller (Active Directory
-Server) for the domain.
-
-By default the trust will be non-transitive. This means that only users
-directly from the trusted domain may authenticate. This can be changed
-to transitive by using the @command{netdom.exe} tool. @command{netdom.exe} 
-can also be used to add the trust between two realms.
-
-You need to tell Windows 2000 on what hosts to find the KDCs for the
-non-Windows realm with @command{ksetup}, see @xref{Configuring Windows 2000
-to use a Heimdal KDC}.
-
-This needs to be done on all computers that want enable cross-realm
-login with @code{Mapped Names}. @c XXX probably shouldn't be @code
-
-Then you need to add the inter-realm keys on the Windows KDC@. Start the
-Domain Tree Management tool (found in Programs, Administrative tools,
-Active Directory Domains and Trusts).
-
-Right click on Properties of your domain, select the Trust tab.  Press
-Add on the appropriate trust windows and enter domain name and
-password. When prompted if this is a non-Windows Kerberos realm, press
-OK.
-
-Do not forget to add trusts in both directions (if that's what you want).
-
-If you want to use @command{netdom.exe} instead of the Domain Tree
-Management tool, you do it like this:
-
-@example
-netdom trust NT.REALM.EXAMPLE.COM /Domain:EXAMPLE.COM /add /realm /passwordt:TrustPassword
-@end example
-
-You also need to add the inter-realm keys to the Heimdal KDC. Make sure
-you have matching encryption types (DES, Arcfour and AES in case of Longhorn)
-
-Another issue is salting.  Since Windows 2000 does not seem to
-understand Kerberos 4 salted hashes you might need to turn off anything
-similar to the following if you have it, at least while adding the
-principals that are going to share keys with Windows 2000.
-
-@example
-[kadmin]
-        default_keys = v5 v4
-@end example
-
-So remove v4 from default keys.
-
-What you probably want to use is this:
-
-@example
-[kadmin]
-        default_keys = des-cbc-crc:pw-salt arcfour-hmac-md5:pw-salt
-@end example
-
-@c XXX check this
-@c It is definitely not supported in base 2003.  I haven't been able to
-@c get SP1 installed here, but it is supposed to work in that.
-
-Once that is also done, you can add the required inter-realm keys:
-
-@example
-kadmin add krbtgt/NT.REALM.EXAMPLE.COM@@EXAMPLE.COM
-kadmin add krbtgt/REALM.EXAMPLE.COM@@NT.EXAMPLE.COM
-@end example
-
-Use the same passwords for both keys.
-
-Do not forget to reboot before trying the new realm-trust (after
-running @command{ksetup}). It looks like it might work, but packets are
-never sent to the non-Windows KDC.
-
-@node Create account mappings, Encryption types, Inter-Realm keys (trust) between Windows 2000 and a Heimdal KDC, Windows 2000 compatability
-@comment node-name, next, precious, up
-@section Create account mappings
-
-Start the @code{Active Directory Users and Computers} tool. Select the
-View menu, that is in the left corner just below the real menu (or press
-Alt-V), and select Advanced Features. Right click on the user that you
-are going to do a name mapping for and choose Name mapping.
-
-Click on the Kerberos Names tab and add a new principal from the
-non-Windows domain.
-
-@c XXX check entry name then I have network again
-This adds @samp{authorizationNames} entry to the users LDAP entry to
-the Active Directory LDAP catalog. When you create users by script you
-can add this entry instead.
-
-@node Encryption types, Authorisation data, Create account mappings, Windows 2000 compatability
-@comment  node-name,  next,  previous,  up
-@section Encryption types
-
-Windows 2000 supports both the standard DES encryptions (@samp{des-cbc-crc} and
-@samp{des-cbc-md5}) and its own proprietary encryption that is based on MD4 and
-RC4 that is documented in and is supposed to be described in
-@file{draft-brezak-win2k-krb-rc4-hmac-03.txt}.  New users will get both
-MD4 and DES keys.  Users that are converted from a NT4 database, will
-only have MD4 passwords and will need a password change to get a DES
-key.
-
-@node Authorisation data, Quirks of Windows 2000 KDC, Encryption types, Windows 2000 compatability
-@comment  node-name,  next,  previous,  up
-@section Authorisation data
-
-The Windows 2000 KDC also adds extra authorisation data in tickets.
-It is at this point unclear what triggers it to do this.  The format of
-this data is only available under a ``secret'' license from Microsoft,
-which prohibits you implementing it.
-
-A simple way of getting hold of the data to be able to understand it
-better is described here.
-
-@enumerate
-@item Find the client example on using the SSPI in the SDK documentation.
-@item Change ``AuthSamp'' in the source code to lowercase.
-@item Build the program.
-@item Add the ``authsamp'' principal with a known password to the
-database.  Make sure it has a DES key.
-@item Run @kbd{ktutil add} to add the key for that principal to a
-keytab.
-@item Run @kbd{appl/test/nt_gss_server -p 2000 -s authsamp
-@kbd{--dump-auth}=@var{file}} where @var{file} is an appropriate file.
-@item It should authenticate and dump for you the authorisation data in
-the file.
-@item The tool @kbd{lib/asn1/asn1_print} is somewhat useful for
-analysing the data.
-@end enumerate
-
-@node Quirks of Windows 2000 KDC, Useful links when reading about the Windows 2000, Authorisation data, Windows 2000 compatability
-@comment  node-name,  next,  previous,  up
-@section Quirks of Windows 2000 KDC
-
-There are some issues with salts and Windows 2000.  Using an empty salt---which is the only one that Kerberos 4 supported, and is therefore known
-as a Kerberos 4 compatible salt---does not work, as far as we can tell
-from out experiments and users' reports.  Therefore, you have to make
-sure you keep around keys with all the different types of salts that are
-required.  Microsoft have fixed this issue post Windows 2003.
-
-Microsoft seems also to have forgotten to implement the checksum
-algorithms @samp{rsa-md4-des} and @samp{rsa-md5-des}. This can make Name
-mapping (@pxref{Create account mappings}) fail if a @samp{des-cbc-md5} key
-is used. To make the KDC return only @samp{des-cbc-crc} you must delete
-the @samp{des-cbc-md5} key from the kdc using the @kbd{kadmin
-del_enctype} command.
-
-@example
-kadmin del_enctype lha des-cbc-md5
-@end example
-
-You should also add the following entries to the @file{krb5.conf} file:
-
-@example
-[libdefaults]
-	default_etypes = des-cbc-crc
-	default_etypes_des = des-cbc-crc
-@end example
-
-These configuration options will make sure that no checksums of the
-unsupported types are generated.
-
-@node Useful links when reading about the Windows 2000,  , Quirks of Windows 2000 KDC, Windows 2000 compatability
-@comment  node-name,  next,  previous,  up
-@section Useful links when reading about the Windows 2000
-
-See also our paper presented at the 2001 Usenix Annual Technical
-Conference, available in the proceedings or at
-@uref{http://www.usenix.org/publications/library/proceedings/usenix01/freenix01/westerlund.html}.
-
-There are lots of texts about Kerberos on Microsoft's web site, here is a
-short list of the interesting documents that we have managed to find.
-
-@itemize @bullet
-
-@item Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability:
-@uref{http://www.microsoft.com/technet/prodtechnol/windows2000serv/howto/kerbstep.mspx}.
-Kerberos GSS-API (in Windows-eze SSPI), Windows as a client in a
-non-Windows KDC realm, adding unix clients to a Windows 2000 KDC, and
-adding cross-realm trust (@pxref{Inter-Realm keys (trust) between Windows 2000
-and a Heimdal KDC}).
-
-@item Windows 2000 Kerberos Authentication:
-@uref{www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/confeat/kerberos.mspx}.
-White paper that describes how Kerberos is used in Windows 2000.
-
-@item Overview of Kerberos:
-@uref{http://support.microsoft.com/support/kb/articles/Q248/7/58.ASP}.
-Links to useful other links.
-
-@c @item Klist for Windows:
-@c @uref{http://msdn.microsoft.com/library/periodic/period00/security0500.htm}.
-@c Describes where to get a klist for Windows 2000.
-
-@item Event logging for Kerberos:
-@uref{http://support.microsoft.com/support/kb/articles/Q262/1/77.ASP}.
-Basically it say that you can add a registry key
-@code{HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\LogLevel}
-with value DWORD equal to 1, and then you'll get logging in the Event
-Logger.
-
-@c @item Access to the Active Directory through LDAP:
-@c @uref{http://msdn.microsoft.com/library/techart/kerberossamp.htm}
-
-@end itemize
-
-Other useful programs include these:
-
-@itemize @bullet
-@item pwdump2
-@uref{http://www.bindview.com/Support/RAZOR/Utilities/Windows/pwdump2_readme.cfm}@end itemize