1995-11-14 - Re: NSA, ITAR, NCSA and plug-in hooks.

Header Data

From: Scott Brickner <sjb@universe.digex.net>
To: Simon Spero <ses@tipper.oit.unc.edu>
Message Hash: c5c8413f0fa7e823da34a91ac78cf608ca798a98afae7da85d68b5522bb4dca3
Message ID: <199511142054.PAA07674@universe.digex.net>
Reply To: <Pine.SOL.3.91.951114115921.17855A-100000@chivalry>
UTC Datetime: 1995-11-14 21:29:36 UTC
Raw Date: Wed, 15 Nov 1995 05:29:36 +0800

Raw message

From: Scott Brickner <sjb@universe.digex.net>
Date: Wed, 15 Nov 1995 05:29:36 +0800
To: Simon Spero <ses@tipper.oit.unc.edu>
Subject: Re: NSA, ITAR, NCSA and plug-in hooks.
In-Reply-To: <Pine.SOL.3.91.951114115921.17855A-100000@chivalry>
Message-ID: <199511142054.PAA07674@universe.digex.net>
MIME-Version: 1.0
Content-Type: text/plain


Simon Spero writes:
>The interesting question is how narrow the interface has to be before it 
>becomes in violation of the ITAR. Is the key question whether the "holes" 
>are specifically designed for the insertion of cryptographic materials, 
>or is it the fact that they could be used to support cryptographic 
>enhancements?

If the ban *is* due to Category XIII (b) (5), the wording would
indicate that the "hole" must be "specifically designed or modified" to
support crypto.  One that was specifically designed to support some
sort of block compression library should be exempt under that
paragraph, even if someone else were to write and distribute a crypto
library with an identical interface.

'Course, IANAL, and the interpreters of the ITAR don't really seem to
care what it *says*, anyway.





Thread