ietf-openpgp
[Top] [All Lists]

Re: Proposed Extensions to TLS for OpenPGP

1997-12-30 05:43:26
Tom Weinstein wrote:
At the very least one would think that the US vendors would put thier
crypto code in one DLL and document the API so someone overseas could
replace it with somthing worth using. <sigh> I guess even that is too
much to ask.

If the US government would let us, you better believe we'd do it.  We have
no vested interest in helping the NSA eavesdrop on people.  We make money
by selling software that meet our customers' needs, and that includes being
secure.

The strategy you describe is called "crypto with a hole", and is explicitly
forbidden by the export regs.

Is this really true? I've heard it said a lot, but there's contradictory
evidence...

Way back when, NCSA were advised by the NSA that crypto hooks were
illegal, and should be removed. NCSA did so, and passed this advice on
to the Apache Group, who also did so. However, when later challenged, I
seem to remember that this was denied (i.e. the USG claimed that they
had never advised that hooks were illegal). This actually happened
before I was involved in Apache, but I investigated it in some depth
when I did Apache-SSL, in the hope that I could ease the load of
tracking new versions. The results were inconlusive, but the Apache
Group were unwilling to take the risk. So far, no-one has shown me
definitive proof that hooks are illegal. 

I'm also curious to know how Microsoft's CryptoAPI fits into this scheme
of things?

Another interesting factor is that the evolution of the Apache API is
gradually making it easier to add crypto without modification to the
base code (you can't actually do it yet, but less hacking is required
than at first). This has happened for reasons not directly connected
with crypto. If Apache's API enables the addition of crypto as a pure
module, does that make Apache's API unexportable, even if every aspect
of it can be justified without resort to crypto hooks?

Apache 2.0 (if it ever happens) is pretty likely to permit this, since
it will allow layered I/O (which is the last major hurdle preventing
it). Layered I/O is required to support all sorts of other advanced
features (such as compressed transfer encodings, SSI over CGI, blah,
blah).

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant  |Fax:   +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben(_at_)algroup(_dot_)co(_dot_)uk |Apache-SSL 
author
A.L. Digital Ltd,     |http://www.algroup.co.uk/Apache-SSL
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache