[This is fairly off-topic for the ietf-TLS list, but the issue is of such
importance to implementors regardless of IETF policy regarding such matters
that I think a little more discussion is permissible.]
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 no lawyer, but I think 15 CFR 774 supplement 1 section 5D002 does this,
more or less. For those not familiar with this terminology, this the Code of
Federal Regulations, Title 15 (Commerce and Foreign Trade), Volume 2 Chapter
VII, part 774 (The Commerce Control List). This is one small piece of the EAR,
or Export Administration Regulations, specifically its a subpart of the part
that says what's covered and what isn't. A copy of this can be found at
http://jya.com/774-ccl05.htm (I tried to find an officia GPO version of it at
www.access.gpo.gov but I cannot figure out how to retrieve supplements from
their server.)
Specifically, item a in section 5D002 says that "Software specially designed or
modified for the development, production or use of equipment or software
controlled by ... section 5D002" comes under export control. (A
self-referential rule... how cute.) And item c.1 in this same section specifies
encyption software explicitly.
In other words, there appears to me that software which was specifically
designed or modified to allow it to be used with encryption software is itself
regulated. And so is, for that matter, software which in turn references such
software.
I'm also curious to know how Microsoft's CryptoAPI fits into this scheme
of things?
My understanding is that CryptoAPI plugins are themselves signed, and unless
that signature is valid the plugin cannot be used. As such, it is possible to
regulate what plugs will actually work and what plugins will not work.
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).
This, I think, is a very interesting point. The text I just cited seems like it
may only apply to interfaces specifically designed for cryptographic plugins. A
more generic plugin interface with lots of other uses might fly. (Indeed, it is
hard to see how it could not, given that such interfaces exist in abundance in
literally hundreds of existing products.)
Of course it doesn't serve the government's interest to clarify this in any
way, which I think explains the NCSA debacle. It may well be that my reading of
the regulations is totally incorrect -- as I said, I'm no lawyer. It may be
that it is what it intended but not what the text actually ends up saying in a
legal sense. It may be that my interpretation is what is intended and what is
said but the rule is nevertheless flawed and unenforcable. It may be that the
rule is valid and enforceable but doesn't cover interfaces with more general
utility. Or it could cover the very general case, and everyone with a more
general interface that could conceivably be used to hook in encryption is in
technical violation of the law. However, a general chilling effect is obtained,
especially among those of us with a fiduciary responsibility to our companies
and stockholders, by leaving it unclear -- an effect that could never be
obtained by a clearer rule.
In any case, if you want to pursue this further offline I'd be happy to do so
as well.
Ned