[260] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: UK Encryption Policy

daemon@ATHENA.MIT.EDU (Ben Laurie)
Thu Feb 20 22:24:05 1997

To: Adam Back <aba@dcs.ex.ac.uk>
Date: Thu, 20 Feb 1997 22:49:43 +0000 (GMT)
From: Ben Laurie <ben@gonzo.ben.algroup.co.uk>
Cc: ben@algroup.co.uk, mikec@cobweb.co.uk, cryptography@c2.net
In-Reply-To: <199702192159.VAA01907@server.test.net> from "Adam Back" at Feb 19, 97 09:59:18 pm
Reply-To: ben@algroup.co.uk

Adam Back wrote:
> 
> 
> Ben Laurie <ben@algroup.co.uk> writes:
> > I wonder if that was the same guy that fed me a pile of interesting documents
> > which seemed to say that export is no problem so long as the technology was
> > publicly available. 
> 
> Technology publically available?  As long as you're not using
> non-publically available algorithms, such as say Red Pike (for which
> you'd have to enter into non-disclosure and secrecy agreements
> anyway), are you suggesting that you can export any crypto software?
> No DTI license required?  Mike Cobb seemed to be suggesting that this
> was tied to making it available on the internet, and that public
> domain status of algorithms (different to publically available)
> helped.

Bear in mind that I don't claim to either understand this stuff, or to be aware
of all factors. The documentation I received was plastered with warnings that
this was purely the DTI's interpretation of the relevant legislation, and in no
way to be taken to have any value whatsoever.

That said, I got sent an interesting appendix to the draconian regulations
which seemed to say the above. With luck, I may be able to dig it out from the
enormous stacks of paper I seem to have accumulated and say what actual
document it was.

If my memory is correct, the criterion was not public-domainness, but simply
public availability (presumably doublespeak for "anything GCHQ didn't invent").

> 
> > Making the product available to all comers also seems to make export
> > OK (and it doesn't have to be free either).
> 
> As in available on the internet?  Or as in no restrictions on who you
> give/sell it to?

Yes. (from memory again).

> 
> > I did all this to try to get a license for Apache-SSL, but dropped
> > it, in the end, when Oxford University agreed to host it (so export
> > was no longer my problem).
> 
> > Of course, the joke is, you can only get a license if it shouldn't
> > be exported.  - in which case, natch, they are unlikely to grant it.
> 
> I don't understand.  (Am I being dim, or did you misphrase that bit?).

No - after the affair of the Iraqi supergun thang, they shifted the way it
worked so that it is your affair to make sure that the thing is exportable.
Only if it isn't can you apply for a license. Really. The DTI do a lovely
pamphlet explaining it - I can't remember exactly what it is called, but its
something to do with End User Controls, and they should send it to you if you
ask.

> 
> >From what you and Mike have said it seems that:
> 
> 1. There are a set of exemptions which allow you to legally export
> without a license, the exemptions as reported by Mike and yourself seem
> so far to involve:
> 
>  a) availability on the internet
>  b) public domain algorithms
>  c) public domain source code
>  d) public algorithms (as opposed non-public, so for example _not_ Red Pike)
>  e) it is the downloader who exports

I'm not sure about e) (except that it is an obvious stance to take. One could
also argue that it is the router that has the intercountry link that exports).

> 
> 2. You suggest that you are in any case subject to a set of
> restrictions even if you are able to make use of the exemptions given
> in 1.  The restrictions being (for benefit of others, from Ben
> Laurie's Apache-SSL server source code, file EXPORT.SSL):
> 
> : 1. The software will not be used, in whole or in part, in connection
> : with the development, production, handling, operation, maintenance,
> : storage, detection, identification or dissemination of chemical,
> : biological or nuclear weapons or the development, production,
> : maintenance or storage of missiles capable of delivering such
> : weapons.
> :
> : 2. The software may not be exported to the following countries:
> : 
> : Algeria, Angola, Argentina, Armenia, Azerbaijan, Belarus, Bosnia,
> : Bulgaria, Burma, China (Peoples' Republic of), Croatia, Cuba, Egypt,
> : Estonia, Georgia, India, Iran, Iraq, Israel, Kazakhstan, Latvia,
> : Liberia, Libya, Lithuania, Macedonia, Moldova, Montenegro, Nigeria,
> : North Korea, Pakistan, Russia, Rwanda, Serbia, Slovenia, Somalia,
> : South Korea, Sudan, Syria, Taiwan, Tajikistan, Turkmenistan,
> : Ukraine, Uzbekhistan, Vietnam, Zaire.

These are taken from the End User Controls thing mentioned above. I'm not sure
that they apply in the case of the exceptions also mentioned above. This file
is only still available through an oversight. Again, I don't export Apache-SSL
so none of this matters to me.

> 
> 
> 3. If you obtain an export license you can export according to the
> terms of the license you obtain.  This may include exporting to the
> countries listed (or one presumes for the uses listed).

Yes. As I understand it.

> 
> 4. If you try but fail to obtain a license you are back to the
> exemptions and normal restrictions as givein in 1 and 2.

You only need a license to export if you shouldn't export it without a license.
Beautifully circular, but it seems to be the way it is. That is, it is not
possible to get a license if there is no (current) barrier to export. This is
explicitly stated.

> 
> 
> Is that an accurate summary?
> 
> The criteria for exemption from needing a license are unclear to me.
> 
> 
> > I'd love to see their response, BTW.
> 
> I'd also be interested to have the export situation clarified.
> Perhaps seeing their response would clarify some of the above
> questions.  Any possibility of scanning it all in and putting it on
> the web?

It was my hope to do that with Apache-SSL (clarify the situation).
Unfortunately, after they'd "lost" my snailmails for the second time, and I had
a way to avoid the question, I gave up ;-)

Cheers,

Ben.

-- 
Ben Laurie                Phone: +44 (181) 994 6435  Email: ben@algroup.co.uk
Freelance Consultant and  Fax:   +44 (181) 994 6472
Technical Director        URL: http://www.algroup.co.uk/Apache-SSL
A.L. Digital Ltd,         Apache Group member (http://www.apache.org)
London, England.          Apache-SSL author

home help back first fref pref prev next nref lref last post