Re: Proposed Extensions to TLS for OpenPGP

[Ned Freed <Ned.Freed@xxxxxxxxxxxx>]

[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