1996-12-24 - RE: [NOT NOISE] Microsoft Crypto Service Provider API

Header Data

From: Blake Coverett <blake@bcdev.com>
To: “cypherpunks@toad.com>
Message Hash: 8b8dfd542566ff7d78c6c784882c51a80ae192a31c9c0434fa9135d43ad801ed
Message ID: <01BBF127.ACD7C120@bcdev.com>
Reply To: N/A
UTC Datetime: 1996-12-24 04:19:13 UTC
Raw Date: Mon, 23 Dec 1996 20:19:13 -0800 (PST)

Raw message

From: Blake Coverett <blake@bcdev.com>
Date: Mon, 23 Dec 1996 20:19:13 -0800 (PST)
To: "cypherpunks@toad.com>
Subject: RE: [NOT NOISE] Microsoft Crypto Service Provider API
Message-ID: <01BBF127.ACD7C120@bcdev.com>
MIME-Version: 1.0
Content-Type: text/plain


jim bell wrote:
> 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!"

The signature in question (on a Win32 Crypto Service Provider) is embedded
in the executable.  Certainly I could rip it out and inject it into an unsigned
but otherwise identical copy outside the U.S., but that is obviously not
going to be legal under ITAR.

ITAR is wrong and should be abolished, but that sort of weasling isn't 
going to make something legal under the current laws.

---

More interesting would be the OS patch that allows an unsigned 
(or signed by someone other than MS) CSP to be loaded...

Hmm, logically the patch must be built in and only need to be 
switched on as it would be too annoying to debug a CSP if you
needed to get it signed every time you built a new version.

Microsoft's Authenticode system had such a patch at one time
for just that purpose, and all it required was a registry setting.

regards,
-Blake  (off to grep around inside some binaries)





Thread