From: jim bell <jimbell@pacifier.com>
Date: Mon, 23 Dec 1996 18:27:08 -0800 (PST)
To: cypherpunks@toad.com
Subject: Re: [NOT NOISE] Microsoft Crypto Service Provider API
Message-ID: <199612240226.SAA25202@mail.pacifier.com>
MIME-Version: 1.0
Content-Type: text/plain


At 11:21 PM 12/22/96 -0800, geeman@best.com wrote:
>
>Software that is imported becomes subject to ITAR with respect to
>re-exportation, of course (but of course IANALetc.)  
>
>If you can't demonstrate to MSFT that you are
>playing by the rules --such that you have the proper export papers
>for your code if you plan to export it, for example-- they won't sign,
>even if developed outside US.

Except that it isn't clear that there are any enforceable "rules," 
particularly after the Patel decision.



>So: you develop a CSP outside US ... you have to IMPORT it to get it signed.
>It becomes subject at that point to ITAR export regs.  Unless you demonstrate
>that you fulfull those requirements, no signature.  So there's no relief by
>looking at just exporting the signature.

You've stated a position, but you haven't supported it.  It's the position 
you might expect the government to take, given its past behavior, but it 
isn't yet clear that this is the case.

Even if, arguably, once-imported software becomes subject to ITAR, it is by 
no means clear that a "signature" is in any way controlled by ITAR.  After 
all, looked at generously, the "signature" might simply be a plaque or paper 
certificate, saying "this is wonderful software!"

Remember, no matter how long that signature it, it might just happen to be 
the same string as a compressed bit of data from some other source, etc.    
The signature might be 16 bits long, for all we know.

In short, the "you can't export signatures" is simply more steps removed 
from the "you can't export crypto software."  We have yet to see anybody 
attempt to enforce this.




Jim Bell
jimbell@pacifier.com