From alec.muffett at gmail.com  Sun Jun  1 20:03:00 2014
From: alec.muffett at gmail.com (Alec Muffett)
Date: Sun, 1 Jun 2014 20:03:00 +0100
Subject: TrueCrypt takedown
In-Reply-To: <o82nipa2vpn6rfv9o7ft9l3j.1401464967769@email.android.com>
References: <o82nipa2vpn6rfv9o7ft9l3j.1401464967769@email.android.com>
Message-ID: <CAFWeb9Kq8aftW+P6kHTDq_pRBRUT0sikOxF+o26z1_S_0C=Bjw@mail.gmail.com>

On 30 May 2014 16:49, Wendy M. Grossman <wendyg at pelicancrossing.net> wrote:

> Me too.  It really does make you wonder what hidden factors might have
> been at work.
>

http://knowyourmeme.com/photos/158329-ancient-aliens

-- 
http://dropsafe.crypticide.com/aboutalecm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.chiark.greenend.org.uk/pipermail/ukcrypto/attachments/20140601/2745a67c/attachment.html>

From igb at batten.eu.org  Wed Jun 11 12:40:34 2014
From: igb at batten.eu.org (Ian Batten)
Date: Wed, 11 Jun 2014 12:40:34 +0100
Subject: RIPA S.12(7) and other pressure points
Message-ID: <EC846839-8C56-4430-8F9D-B08FE977A6A3@batten.eu.org>

Hey ho, we're on the RIPA train again.   

RIPA section 12 lays down provision for the home secretary to direct CSPs to maintain an interception capability.

Section 12(7) provides that if a CSP refuses, the Home Secretary can go to a (civil) court and seek remedies.

To be concrete, imagine an email provider (Gmail, say) or ISP who proposes to run a service that 
 encourages or enables their customers to run end-to-end encryption, such that the ISP (etc) did
_not_ have any keys to respond to a a RIPA S.49 notice.  And let's assume for the purposes at hand that they
can prove they don't have keys in a relatively accessible and comprehensible way.

Some questions that have arisen from a debate with a colleague.

1.  Imagine your clients are using end-to-end encryption, and you have somehow encouraged them.  Do your S.12
responsibilities include any obligation to make it easier for an interception to obtain plaintext (or, alternatively,
to not make it any harder)? 

2.  This thanks to Julian Huppert when we asked him about this on Monday.  Could S.94 of the Telecommunications
Act be engaged to try to convince the operator to modify their network?  As amended, S.94(8) limits this to
"providers of public electronic communications networks".  As Julian pointed out, "telecommunications networks" aren't 
defined in the 1984 Act; further reading of the history of S.94(8) implies that the meaning from S.32 of the
Communications Act 2003 applies, which would cover pretty well any imaginable service offered at scale. 

3.  Has any CSP who has been approached with S.12 powers refused to comply (other than by shutting down
the service?)  As the Technical Advisory Board has never met, one would tend to suspect that no such dispute
has ever taken place.

4.  If someone did refuse, forced a meeting of the TAB, still refused, and ended up in court, how likely is it that
the government would (a) fight and (b) win an action under S.12(7)?

My core question is: if you decided to deploy a service which offered strong end-to-end encryption, it's likely it
would attract interest from agencies.  If you were of a mind to follow in the footsteps of Richard Ingram in
Arkell v Pressdram and force the matter to a court, what would be the likely outcome?

[[ This is a hypothetical question, by the way: I have no such product, nor any such intention. ]]

My guesses are (1) No (2) on the face of it yes (3) I suspect not (4) who knows?  My answer to the core
question is that the government would do almost anything to avoid the dispute getting into open court.

ian



From D.M.Pick at qmul.ac.uk  Wed Jun 11 13:58:32 2014
From: D.M.Pick at qmul.ac.uk (David Pick)
Date: Wed, 11 Jun 2014 13:58:32 +0100
Subject: RIPA S.12(7) and other pressure points
In-Reply-To: <EC846839-8C56-4430-8F9D-B08FE977A6A3@batten.eu.org>
References: <EC846839-8C56-4430-8F9D-B08FE977A6A3@batten.eu.org>
Message-ID: <53985278.7040002@qmul.ac.uk>

On 11/06/14 12:40, Ian Batten wrote:

> <snip>
> 
> 1.  Imagine your clients are using end-to-end encryption, and you have somehow encouraged them.  Do your S.12
> responsibilities include any obligation to make it easier for an interception to obtain plaintext (or, alternatively,
> to not make it any harder)? 

And are CSP's not encouraged *by govnernmant bodies* to encourage their
clients to communicate securely, using end-to-end encryption, with
their banks to secure their transactions? Clients using end-to-end
encryptiion is *not* something we have to work very hard to imagine.

> <snip>

-- 
David Pick
Network Security Manager, IT Services
Queen Mary University of London
Tel: +44 (0) 20 7882 7079
Mob: +44 (0) 7973 379 161
E-Mail: D.M.Pick at qmul.ac.uk



From nbohm at ernest.net  Wed Jun 11 15:11:57 2014
From: nbohm at ernest.net (Nicholas Bohm)
Date: Wed, 11 Jun 2014 15:11:57 +0100
Subject: RIPA S.12(7) and other pressure points
In-Reply-To: <EC846839-8C56-4430-8F9D-B08FE977A6A3@batten.eu.org>
References: <EC846839-8C56-4430-8F9D-B08FE977A6A3@batten.eu.org>
Message-ID: <539863AD.3060608@ernest.net>

An HTML attachment was scrubbed...
URL: <http://www.chiark.greenend.org.uk/pipermail/ukcrypto/attachments/20140611/b330c626/attachment.html>

From peter at pmsommer.com  Thu Jun 12 07:43:29 2014
From: peter at pmsommer.com (Peter Sommer)
Date: Thu, 12 Jun 2014 07:43:29 +0100
Subject: RIPA s 12(7)
Message-ID: <53994C11.4030705@pmsommer.com>

Surely an important element is the form that the encouragement to use 
encrypted email took.

If all that the CSP is doing is reminding their users that email is 
insecure,  that they should use encryption and pointing them to some 
sources of advice,  it is difficult to  see that the CSP has any 
responsibility for what is happening nor would it be feasible for them 
to introduce a capability to do deal with "protected information" - 
after all,  UK law enforcement resources in this area are all 
centralised and shared - at NTAC.

You may find it helpful to the the appropriate RIPA Code of Practice:

https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/97959/code-practice-electronic-info.pdf

GMail or any of the non-UK webmail service providers could however embed 
encryption into their offerings but the UK government would not be able 
to force them to introduce an interception capability;  it would have to 
be done by agreement.

I agree with Nick (no, not that one)



Peter Sommer

On 11/06/2014 15:11, Nicholas Bohm wrote:
On 11/06/2014 12:40, Ian Batten wrote:
> Hey ho, we're on the RIPA train again.
>
> RIPA section 12 lays down provision for the home secretary to direct CSPs to maintain an interception capability.
>
> Section 12(7) provides that if a CSP refuses, the Home Secretary can go to a (civil) court and seek remedies.
>
> To be concrete, imagine an email provider (Gmail, say) or ISP who proposes to run a service that
>   encourages or enables their customers to run end-to-end encryption, such that the ISP (etc) did
> _not_ have any keys to respond to a a RIPA S.49 notice.  And let's assume for the purposes at hand that they
> can prove they don't have keys in a relatively accessible and comprehensible way.
>
> Some questions that have arisen from a debate with a colleague.
>
> 1.  Imagine your clients are using end-to-end encryption, and you have somehow encouraged them.  Do your S.12
> responsibilities include any obligation to make it easier for an interception to obtain plaintext (or, alternatively,
> to not make it any harder)?

I suggest not.  Section 12 is about intercepting communications, not 
about making them intelligible, to which latter purpose a whole lot of 
quite different provisions are made.

>   
> 2.  This thanks to Julian Huppert when we asked him about this on Monday.  Could S.94 of the Telecommunications
> Act be engaged to try to convince the operator to modify their network?  As amended, S.94(8) limits this to
> "providers of public electronic communications networks".  As Julian pointed out, "telecommunications networks" aren't
> defined in the 1984 Act; further reading of the history of S.94(8) implies that the meaning from S.32 of the
> Communications Act 2003 applies, which would cover pretty well any imaginable service offered at scale.

Anything at all can be ordered, provided it is proportionate, and that 
must include modifying the service.  It is hard to see that secretly 
frustrating the security features for all users could be proportionate, 
but doing so for some might be.  It would be a judicial review that HMG 
would hate to fight, though.

> 3.  Has any CSP who has been approached with S.12 powers refused to comply (other than by shutting down
> the service?)  As the Technical Advisory Board has never met, one would tend to suspect that no such dispute
> has ever taken place.
>
> 4.  If someone did refuse, forced a meeting of the TAB, still refused, and ended up in court, how likely is it that
> the government would (a) fight and (b) win an action under S.12(7)?

The Government would fight if they felt it mattered enough, which seems 
inherently pretty unpredictable.  Equally unpredictable is whether they 
would win, since it depends what points were at issue. If the argument 
was about making communications intelligible I think they'd lose; but 
since that would be apparent in advance, they wouldn't fight that one.
Nicholas

-- 
THE INFORMATION CONTAINED IN THIS E-MAIL IS CONFIDENTIAL AND LEGALLY PRIVILEGED.  IT IS INTENDED ONLY FOR THE ADDRESSEE NAMED ABOVE. IF YOU ARE NOT THE ADDRESSEE ANY DISTRIBUTION, COPYING OR DISCLOSURE OF THIS E-MAIL IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED IT IN ERROR PLEASE NOTIFY THE SENDER BY E-MAIL IMMEDIATELY AND DESTROY THE ORIGINAL



From lists at casparbowden.net  Thu Jun 12 12:20:09 2014
From: lists at casparbowden.net (Caspar Bowden (lists))
Date: Thu, 12 Jun 2014 13:20:09 +0200
Subject: RIPA s 12(7)
In-Reply-To: <53994C11.4030705@pmsommer.com>
References: <53994C11.4030705@pmsommer.com>
Message-ID: <53998CE9.1000507@casparbowden.net>

On 06/12/14 08:43, Peter Sommer wrote:
> ..
> GMail or any of the non-UK webmail service providers could however 
> embed encryption into their offerings but the UK government would not 
> be able to force them to introduce an interception capability;  it 
> would have to be done by agreement.

..but a s.49 RIP order can require CSP to produce plaintext (or key) to 
any past (or future) data. If the key isn't available (e.g there is 
client-side code) a recipient of a s.49 can be required to give all 
co-operation necessary to have a defence.

Wonder opinions if this sufficient for UK to (coercively) "do a 
Hushmail" ? Or under Intel Services Act, or RIPA Pt.2 ?

CB


From peter at pmsommer.com  Thu Jun 12 17:49:25 2014
From: peter at pmsommer.com (Peter Sommer)
Date: Thu, 12 Jun 2014 17:49:25 +0100
Subject: RIPA s 12(7)
In-Reply-To: <53998CE9.1000507@casparbowden.net>
References: <53994C11.4030705@pmsommer.com> <53998CE9.1000507@casparbowden.net>
Message-ID: <5399DA15.2010101@pmsommer.com>

One of the reasons I provided a link to the RIPA Pt 3 Code of Practice 
is that it shows the steps involved and tests that must be applied 
during any attempt to enforce a s49 Order.  If the CSP has merely 
advised their customers to use encryption,  pointed them in a few 
specific directions but has no further role in setting up the encryption 
system then they can say that in this instance they are a mere conduit.  
It would be different if they were offering an encrypted webmail 
service, though if the keys are generated by the client or by a third 
party then plainly the CSP has nothing that would help the authorities. 
For conviction under s 49 the authorities have to prove, among other 
things, a reasonable belief that the key or the power to decrypt, is in 
the possession of the person or entity being accused.


Peter Sommer


On 12/06/2014 12:20, Caspar Bowden (lists) wrote:
> On 06/12/14 08:43, Peter Sommer wrote:
>> ..
>> GMail or any of the non-UK webmail service providers could however 
>> embed encryption into their offerings but the UK government would not 
>> be able to force them to introduce an interception capability;  it 
>> would have to be done by agreement.
>
> ..but a s.49 RIP order can require CSP to produce plaintext (or key) 
> to any past (or future) data. If the key isn't available (e.g there is 
> client-side code) a recipient of a s.49 can be required to give all 
> co-operation necessary to have a defence.
>
> Wonder opinions if this sufficient for UK to (coercively) "do a 
> Hushmail" ? Or under Intel Services Act, or RIPA Pt.2 ?
>
> CB
>
>


-- 
THE INFORMATION CONTAINED IN THIS E-MAIL IS CONFIDENTIAL AND LEGALLY PRIVILEGED.  IT IS INTENDED ONLY FOR THE ADDRESSEE NAMED ABOVE. IF YOU ARE NOT THE ADDRESSEE ANY DISTRIBUTION, COPYING OR DISCLOSURE OF THIS E-MAIL IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED IT IN ERROR PLEASE NOTIFY THE SENDER BY E-MAIL IMMEDIATELY AND DESTROY THE ORIGINAL



From igb at batten.eu.org  Thu Jun 12 18:26:56 2014
From: igb at batten.eu.org (Ian Batten)
Date: Thu, 12 Jun 2014 18:26:56 +0100
Subject: RIPA s 12(7)
In-Reply-To: <5399DA15.2010101@pmsommer.com>
References: <53994C11.4030705@pmsommer.com> <53998CE9.1000507@casparbowden.net>
	<5399DA15.2010101@pmsommer.com>
Message-ID: <076CD416-9EAE-4EA6-B885-7F6D42320657@batten.eu.org>


On 12 Jun 2014, at 17:49, Peter Sommer <peter at pmsommer.com> wrote:

> For conviction under s 49 the authorities have to prove, among other things, a reasonable belief that the key or the power to decrypt, is in the possession of the person or entity being accused.

The authorities need that "reasonable belief" to issue the decryption notice in the first place (S.49(2)(a)).    For a conviction, they need "beyond a reasonable doubt", not "reasonable belief".

ian



From lists at casparbowden.net  Thu Jun 12 18:39:17 2014
From: lists at casparbowden.net (Caspar Bowden (lists))
Date: Thu, 12 Jun 2014 19:39:17 +0200
Subject: RIPA s 12(7)
In-Reply-To: <5399DA15.2010101@pmsommer.com>
References: <53994C11.4030705@pmsommer.com> <53998CE9.1000507@casparbowden.net>
	<5399DA15.2010101@pmsommer.com>
Message-ID: <5399E5C5.20306@casparbowden.net>

On 06/12/14 18:49, Peter Sommer wrote:
> One of the reasons I provided a link to the RIPA Pt 3 Code of Practice 
> is that it shows the steps involved and tests that must be applied 
> during any attempt to enforce a s49 Order.  If the CSP has merely 
> advised their customers to use encryption,  pointed them in a few 
> specific directions but has no further role in setting up the 
> encryption system then they can say that in this instance they are a 
> mere conduit.

Indeed

> It would be different if they were offering an encrypted webmail 
> service, though if the keys are generated by the client or by a third 
> party then plainly the CSP has nothing that would help the 
> authorities. For conviction under s 49 the authorities have to prove, 
> among other things, a reasonable belief that the key or the power to 
> decrypt, is in the possession of the person or entity being accused.

A "key" is broader than a key:

    "key", in relation to any electronic data, means any key, code,
    password, algorithm or other data the use of which (with or without
    other keys)---
    (a) allows access to the electronic data, or
    (b) *facilitates* the putting of the data into an intelligible form;

Moreover in the CoP

    6.16 Where a person is required by a section 49 notice to make a
    disclosure in respect of any protected information and that person:

        . has had possession of the key to the protected information but
        no longer has possession of it;
        . would have been required by the notice to disclose the key if
        it had continued to be in his possession, and
        . when given the notice, or within the time by which the notice
        must be complied with, is in possession of any information that
        would facilitate the obtaining or discovery of the key or the
        putting of the protected information into an intelligible form;

    the effect of the disclosure requirement is that he shall be
    required to disclose all such information to the person to whom he
    would have been required to disclose the protected information in an
    intelligible form or the key. In other words, to disclose anything
    they have that assists putting the protected information into an
    intelligible form.

that looks broad enough to ask for the source code to any client-side 
Webmail encrypting widget. Quite useful.

can't see how the service provider's arm can be twisted to supply 
doctored code (themselves), but MITM and possibly Quantum attacks (?)

CB


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.chiark.greenend.org.uk/pipermail/ukcrypto/attachments/20140612/6e55ab7f/attachment.html>

From igb at batten.eu.org  Thu Jun 12 15:44:43 2014
From: igb at batten.eu.org (Ian Batten)
Date: Thu, 12 Jun 2014 15:44:43 +0100
Subject: RIPA s 12(7)
In-Reply-To: <53998CE9.1000507@casparbowden.net>
References: <53994C11.4030705@pmsommer.com> <53998CE9.1000507@casparbowden.net>
Message-ID: <7831B5DF-31B9-4872-A110-26385914B715@batten.eu.org>


On 12 Jun 2014, at 12:20, Caspar Bowden (lists) <lists at CasparBowden.net> wrote:

> On 06/12/14 08:43, Peter Sommer wrote:
>> ..
>> GMail or any of the non-UK webmail service providers could however embed encryption into their offerings but the UK government would not be able to force them to introduce an interception capability;  it would have to be done by agreement.
> 
> ..but a s.49 RIP order can require CSP to produce plaintext (or key) to any past (or future) data. If the key isn't available (e.g there is client-side code) a recipient of a s.49 can be required to give all co-operation necessary to have a defence.
> 
> Wonder opinions if this sufficient for UK to (coercively) "do a Hushmail" ? Or under Intel Services Act, or RIPA Pt.2 ?

That's the basic debate, I think.

That anyone who wants to offer an end-to-end crypto solution that doesn't involve customers compiling PGP themselves is
gambling that when the S.49 music stops, they can absolutely convince a judge that although they offered the service
and provided significant assistance in running it (keyservers, perhaps) they genuinely don't have the keys.  One position
is that S.12 could be used to frustrate the service in the first place: I think we've concluded that's not realistic.  But I think
the protection racket angle, "well, you could run that service, but you'd have to convince a judge that your fancy zero-knowledge
proof was genuine when you claim you can't decrypt stuff on your network, encrypted with your software, using keys that
you store" would be a fairly powerful deterrent to anyone but the most committed.

On the other hand, suppose the CSP in this case were Google, and they lost such an action: they claimed (accurately) that
they couldn't help with a S.49 notice, but the court didn't believe them.  What would happen next?  

ian



From marcus at connectotel.com  Thu Jun 12 17:44:22 2014
From: marcus at connectotel.com (Marcus Williamson)
Date: Thu, 12 Jun 2014 17:44:22 +0100
Subject: Off topic: DPA question
Message-ID: <aj3jp9p51vpsei2hc77didaab6l3a85qj9@4ax.com>


Hello

An off-topic question if I may:

Is a business email address considered "personal data" under the terms of the Data
Protection Act (DPA)?

Thanks
Marcus Williamson


From fjmd1a at gmail.com  Thu Jun 12 20:59:56 2014
From: fjmd1a at gmail.com (Francis Davey)
Date: Thu, 12 Jun 2014 20:59:56 +0100
Subject: Off topic: DPA question
In-Reply-To: <aj3jp9p51vpsei2hc77didaab6l3a85qj9@4ax.com>
References: <aj3jp9p51vpsei2hc77didaab6l3a85qj9@4ax.com>
Message-ID: <CAEWR3kvncOPO-1x37H2LaA6hbaQXWzWznp+UOGWGyYHBBXywkg@mail.gmail.com>

2014-06-12 17:44 GMT+01:00 Marcus Williamson <marcus at connectotel.com>:

>
> Hello
>
> An off-topic question if I may:
>
> Is a business email address considered "personal data" under the terms of
> the Data
> Protection Act (DPA)?
>
>
That depends on whether the email address relates to a living individual
(and also whether that individual is identified or identifiable).

-- 
Francis Davey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.chiark.greenend.org.uk/pipermail/ukcrypto/attachments/20140612/5d98f182/attachment-0001.html>

From amidgley at gmail.com  Thu Jun 12 19:57:32 2014
From: amidgley at gmail.com (Adrian Midgley)
Date: Thu, 12 Jun 2014 19:57:32 +0100
Subject: RIPA s 12(7)
In-Reply-To: <5399E5C5.20306@casparbowden.net>
References: <53994C11.4030705@pmsommer.com> <53998CE9.1000507@casparbowden.net>
	<5399DA15.2010101@pmsommer.com> <5399E5C5.20306@casparbowden.net>
Message-ID: <CAN2jWyiMzQ145J7DnWzhhgfzUC8+4VS4GFaL+F4V0ti+wCrO6w@mail.gmail.com>

On Thursday, June 12, 2014, Caspar Bowden (lists) <lists at casparbowden.net>
wrote:

>
> ?key?, in relation to any electronic data, means any key, code, password,
> algorithm or other data the use of which (with or without other keys)?
> (a) allows access to the electronic data, or
> (b) *facilitates* the putting of the data into an intelligible form;
>
> .
>
> that looks broad enough to ask for the source code to any client-side
> Webmail encrypting widget. Quite useful.
>
> ... So simplest to disclose the source code to the world in advance...
>


-- 
Adrian Midgley   http://www.defoam.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.chiark.greenend.org.uk/pipermail/ukcrypto/attachments/20140612/965cf71f/attachment.html>

From igb at batten.eu.org  Thu Jun 12 21:04:09 2014
From: igb at batten.eu.org (Ian Batten)
Date: Thu, 12 Jun 2014 21:04:09 +0100
Subject: RIPA s 12(7)
In-Reply-To: <5399E5C5.20306@casparbowden.net>
References: <53994C11.4030705@pmsommer.com> <53998CE9.1000507@casparbowden.net>
	<5399DA15.2010101@pmsommer.com> <5399E5C5.20306@casparbowden.net>
Message-ID: <D734523A-695B-4977-9FBA-3AF482AA8D42@batten.eu.org>


On 12 Jun 2014, at 18:39, Caspar Bowden (lists) <lists at casparbowden.net> wrote:
> that looks broad enough to ask for the source code to any client-side Webmail encrypting widget. Quite useful.

It's also broad enough to get a server's private key if RSA was in use: if you've intercepted encrypted sessions, then
having the RSA private key allows you to extract the session keys.  There's a proportionality and collateral issue, but
of course the S.49 notice could be used to demand the CSP decrypt encrypted session keys and provided
by the agency, and therefore satisfy the needs of the investigator without releasing a long-term key.

However, I'm not sure whether the police would be overly interested in any of this, because even if the CSP coughs
all the keys, it's intercept and therefore not admissible.  They'll need other, non-intercept evidence to get the intercept
warrant, and they'll need other, non-intercept evidence to get a conviction.  Cases where the intercept evidence is
therefore hugely significant, to the point of it being worth messing around with production orders, are going to be 
thin on the ground.  And stuff which is admissible when decrypted, for example memory sticks seized under search
warrants or computers with "data at rest" ditto, is much less likely to have keys held by anyone other than the
putative owner.

ian




From marcus at connectotel.com  Fri Jun 13 00:01:25 2014
From: marcus at connectotel.com (Marcus Williamson)
Date: Fri, 13 Jun 2014 00:01:25 +0100
Subject: Off topic: DPA question
In-Reply-To: <CAEWR3kvncOPO-1x37H2LaA6hbaQXWzWznp+UOGWGyYHBBXywkg@mail.gmail.com>
References: <aj3jp9p51vpsei2hc77didaab6l3a85qj9@4ax.com>
	<CAEWR3kvncOPO-1x37H2LaA6hbaQXWzWznp+UOGWGyYHBBXywkg@mail.gmail.com>
Message-ID: <v4ckp9dt6mqbt1qi4gsoh34q9db0sjkq58@4ax.com>


On Thu, 12 Jun 2014 20:59:56 +0100, you wrote:

>That depends on whether the email address relates to a living individual
>(and also whether that individual is identified or identifiable).

Hello Francis

Thank you - in this case the email address relates to a living individual.

In my view, their personal (non-business) email address would be personal
information but their business email address would not be.

Any thoughts please? Thank you!

best wishes
Marcus


From pwt at iosis.co.uk  Fri Jun 13 08:48:26 2014
From: pwt at iosis.co.uk (Peter Tomlinson)
Date: Fri, 13 Jun 2014 08:48:26 +0100
Subject: OxCEPT
Message-ID: <539AACCA.8030809@iosis.co.uk>

Do any of you have views about OxCEPT that you can share? Their news 
email today states:

    LONDON, UNITED KINGDOM and SAN FRANCISCO, CALIFORNIA--June 13, 2014)
    OxCEPT, the technology company behind the development of the world's
    most secure protocols for transmitting data, today announced that
    venture capitalist Allen Morgan has joined its team as Strategic
    Advisor.


And the web site oxcept.com states:

    Developed by Oxford University | Tested by the UK Ministry of Defence
    World's Most Secured Way to Transmit Data


Yet I don't hear anything about the company and its products through any 
other channel. (I was originally alerted to its existence through an 
Oxford Uni channel.)

(Their web site doesn't appear to be legal, as it doesn't give company 
registration particulars - Companies House shows the registered office 
address of Oxcept Ltd as Summertown, Oxford.)

Peter (the Bristol one)




From ben at liddicott.com  Fri Jun 13 08:00:35 2014
From: ben at liddicott.com (Ben Liddicott)
Date: Fri, 13 Jun 2014 08:00:35 +0100
Subject: Off topic: DPA question
In-Reply-To: <v4ckp9dt6mqbt1qi4gsoh34q9db0sjkq58@4ax.com>
References: <aj3jp9p51vpsei2hc77didaab6l3a85qj9@4ax.com>	<CAEWR3kvncOPO-1x37H2LaA6hbaQXWzWznp+UOGWGyYHBBXywkg@mail.gmail.com>
	<v4ckp9dt6mqbt1qi4gsoh34q9db0sjkq58@4ax.com>
Message-ID: <539AA193.1090208@liddicott.com>


On 13/06/2014 00:01, Marcus Williamson wrote:
>
> Thank you - in this case the email address relates to a living individual.
>
> In my view, their personal (non-business) email address would be personal
> information but their business email address would not be.
>
I used to think that the mere fact that a person existed, i.e. name and 
date of birth, were not personal data. However the courts have now taken 
the opposite view.

An email address directed to an individual rather than a role certainly 
uniquely identifies them in the world. That is now enough to make it 
personal information on its own - if it also identifies their name and 
place of work, then all the more so.

That's X. What's Y? In all likelihood processing information relating 
primarily to email transmission and to the person's work will be fair 
for most purposes because you have invited it by having a work email 
address. (What is it for if not sending and receiving email about work?)

I am not a lawyer though.

Cheers, Ben


From Andrew.Cormack at ja.net  Fri Jun 13 11:28:22 2014
From: Andrew.Cormack at ja.net (Andrew Cormack)
Date: Fri, 13 Jun 2014 10:28:22 +0000
Subject: Off topic: DPA question
In-Reply-To: <v4ckp9dt6mqbt1qi4gsoh34q9db0sjkq58@4ax.com>
References: <aj3jp9p51vpsei2hc77didaab6l3a85qj9@4ax.com>
	<CAEWR3kvncOPO-1x37H2LaA6hbaQXWzWznp+UOGWGyYHBBXywkg@mail.gmail.com>
	<v4ckp9dt6mqbt1qi4gsoh34q9db0sjkq58@4ax.com>
Message-ID: <61E52F3A5532BE43B0211254F13883AE9829D8E8@EXC001>

> -----Original Message-----
> From: ukcrypto-bounces at chiark.greenend.org.uk [mailto:ukcrypto-
> bounces at chiark.greenend.org.uk] On Behalf Of Marcus Williamson
> Sent: 13 June 2014 00:01
> To: ukcrypto at chiark.greenend.org.uk
> Subject: Re: Off topic: DPA question
> 
> 
> On Thu, 12 Jun 2014 20:59:56 +0100, you wrote:
> 
> >That depends on whether the email address relates to a living
> individual
> >(and also whether that individual is identified or identifiable).
> 
> Hello Francis
> 
> Thank you - in this case the email address relates to a living
> individual.
> 
> In my view, their personal (non-business) email address would be
> personal
> information but their business email address would not be.
> 
> Any thoughts please? Thank you!
> 
> best wishes
> Marcus

Just to add a wrinkle the Privacy and Electronic Communications Regs *do* distinguish between e-mail addresses of "individual subscribers" and others :(

But even then it's pretty tricky, if you're external to the system, to try to distinguish them - how do you know whether andrew.cormack at ja.net is an 'individual subscriber' or not? Or indeed how do I know which marcus at connectotel.com is?

Andrew



From james.davis at ja.net  Fri Jun 13 10:12:57 2014
From: james.davis at ja.net (James Davis)
Date: Fri, 13 Jun 2014 10:12:57 +0100
Subject: OxCEPT
In-Reply-To: <539AACCA.8030809@iosis.co.uk>
References: <539AACCA.8030809@iosis.co.uk>
Message-ID: <539AC099.5050101@ja.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 13/06/2014 08:48, Peter Tomlinson wrote:

> (Their web site doesn't appear to be legal, as it doesn't give
> company registration particulars - Companies House shows the
> registered office address of Oxcept Ltd as Summertown, Oxford.)

Well to be fair they haven't even get the name of the University right
- - despite it being correctly rendered in the seal :)

James

- -- 
James Davis                0300 999 2340 (+44 1235 822340)
Senior CSIRT Member	
Lumen House, Library Avenue, Didcot, Oxfordshire, OX11 0SG
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTmsCZAAoJEHRLPxE0xhCCVHwH/jOYvHp4SYNHYdR9qv1IrSE9
ISyoZew97tQeaUptfHbVRc3qi46N05NRFeAEysFFcqOSjTgxfQj4K6O6/Jd5V5I3
gsVcsReiV9mfcVzZZOPSBtN/ypsDqrc+ABy7s0A/NuSbR0YPLeWIsQ/JxUaKlaqd
YOG9x8lK094qSdo23FwNhNP8KiWxLd39pccD1SN/xgUrstwFD7rwQ2Ru+nhhDo+H
2PxoR/hXoiv5A/ojy8RU2XU+RCzua/t2Dqh943zIer9Bo9297jH7piZM270K9mWj
+5RE70CkKUtld67j5GEj70c/BN+D7AsH50Y+owxZ/uyjh3tnJlI9wYlyGlUYbms=
=tf1n
-----END PGP SIGNATURE-----

Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
not-for-profit company which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238



From lists at internetpolicyagency.com  Fri Jun 13 13:46:38 2014
From: lists at internetpolicyagency.com (Roland Perry)
Date: Fri, 13 Jun 2014 13:46:38 +0100
Subject: OxCEPT
In-Reply-To: <539AC099.5050101@ja.net>
References: <539AACCA.8030809@iosis.co.uk> <539AC099.5050101@ja.net>
Message-ID: <yCGViYQuKvmTFAAl@perry.co.uk>

In article <539AC099.5050101 at ja.net>, James Davis <james.davis at ja.net> 
writes
>Well to be fair they haven't even get the name of the University right
>- despite it being correctly rendered in the seal :)

To be fair, to take just one example, the rowers are called Oxford 
University Boat Club (OUBC) and not the University of Oxford Boat Club 
(UOBC) so it's not surprising both forms of name are in widespread use.
-- 
Roland Perry


From lists at internetpolicyagency.com  Fri Jun 13 12:10:11 2014
From: lists at internetpolicyagency.com (Roland Perry)
Date: Fri, 13 Jun 2014 12:10:11 +0100
Subject: Off topic: DPA question
In-Reply-To: <61E52F3A5532BE43B0211254F13883AE9829D8E8@EXC001>
References: <aj3jp9p51vpsei2hc77didaab6l3a85qj9@4ax.com>
	<CAEWR3kvncOPO-1x37H2LaA6hbaQXWzWznp+UOGWGyYHBBXywkg@mail.gmail.com>
	<v4ckp9dt6mqbt1qi4gsoh34q9db0sjkq58@4ax.com>
	<61E52F3A5532BE43B0211254F13883AE9829D8E8@EXC001>
Message-ID: <EWpYXrITwtmTFAmh@perry.co.uk>

In article <61E52F3A5532BE43B0211254F13883AE9829D8E8 at EXC001>, Andrew 
Cormack <Andrew.Cormack at ja.net> writes

>Just to add a wrinkle the Privacy and Electronic Communications Regs *do* distinguish between e-mail addresses of "individual subscribers" and
>others :(
>
>But even then it's pretty tricky, if you're external to the system, to try to distinguish them - how do you know whether andrew.cormack at ja.net
>is an 'individual subscriber' or not?

While you are very likely to be an individual, the word "subscriber" can 
have issues. I doubt you pay JANET's entire Internet or phone bill, for 
example.

Of course, unsolicited email is only one of several reasons why the 
status of individual email addresses could be important.
-- 
Roland Perry


From lists at internetpolicyagency.com  Fri Jun 13 11:42:04 2014
From: lists at internetpolicyagency.com (Roland Perry)
Date: Fri, 13 Jun 2014 11:42:04 +0100
Subject: Off topic: DPA question
In-Reply-To: <aj3jp9p51vpsei2hc77didaab6l3a85qj9@4ax.com>
References: <aj3jp9p51vpsei2hc77didaab6l3a85qj9@4ax.com>
Message-ID: <BlyprpG8VtmTFAFY@perry.co.uk>

In article <aj3jp9p51vpsei2hc77didaab6l3a85qj9 at 4ax.com>, Marcus 
Williamson <marcus at connectotel.com> writes
>Is a business email address considered "personal data" under the terms of the Data
>Protection Act (DPA)?

I discussed this at some length with the Commissioner (Elizabeth France 
at the time) who was somewhat out on a limb with her view [which I 
strongly agreed with] that what I'd call "obvious" email addresses like 
roland at perry.co.uk were personal data!

Later reports from the Article 29 Working Party confirmed this, but some 
(and especially USA-ian folks) still seem to be in denial about it 
because they are extremely reluctant to adopt a position that some/many 
email addresses are personal data and only appear to be prepared to 
accept that all/none are, with a strong presumption that if they can 
find just one that clearly isn't, then the answer is "none".

As for business email addresses, well if roland at perry.co.uk is a sole 
trader, then of course it still is.

roland at internetpolicyagency.com is also personal data because I'm 
immediately identifiable from that.

Where it starts getting tricky is whether a role address like
postmaster at internetpolicyagency.com is personal data, and I'd say it 
still was if you can easily find other information confirming who the 
postmaster (or ceo/sales/etc...) is.
-- 
Roland Perry


From fjmd1a at gmail.com  Fri Jun 13 15:16:00 2014
From: fjmd1a at gmail.com (Francis Davey)
Date: Fri, 13 Jun 2014 15:16:00 +0100
Subject: Off topic: DPA question
In-Reply-To: <61E52F3A5532BE43B0211254F13883AE9829D8E8@EXC001>
References: <aj3jp9p51vpsei2hc77didaab6l3a85qj9@4ax.com>
	<CAEWR3kvncOPO-1x37H2LaA6hbaQXWzWznp+UOGWGyYHBBXywkg@mail.gmail.com>
	<v4ckp9dt6mqbt1qi4gsoh34q9db0sjkq58@4ax.com>
	<61E52F3A5532BE43B0211254F13883AE9829D8E8@EXC001>
Message-ID: <CAEWR3ksp+_aKWcdpNeP2kp-WoABO+8UcQf3jN=ivSCwbZ+rxyg@mail.gmail.com>

2014-06-13 11:28 GMT+01:00 Andrew Cormack <Andrew.Cormack at ja.net>:
>
>
> Just to add a wrinkle the Privacy and Electronic Communications Regs *do*
> distinguish between e-mail addresses of "individual subscribers" and others
> :(
>
> But even then it's pretty tricky, if you're external to the system, to try
> to distinguish them - how do you know whether andrew.cormack at ja.net is an
> 'individual subscriber' or not? Or indeed how do I know which
> marcus at connectotel.com is?
>
>
The definition of personal data, for the purposes of the directive, is (in
article 2(a)):

"(a) 'personal data' shall mean any information relating to an identified
or identifiable natural person ('data subject'); an identifiable person is
one who can be identified, directly or indirectly, in particular by
reference to an identification number or to one or more factors specific to
his physical, physiological, mental, economic, cultural or social identity;"

This is actually quite simple. It asks essentially two questions: (i) does
the data relate to a natural person and (ii) are they identifiable (or
identified, but of course an identified person is ex hypothesi
identifiable).

A work email for an individual clearly relates to them. Some "role" email
addresses may not (though as Roland points out, it will depend).

Can _someone_ identify that person? In most cases, yes.

So, in most cases, individuals' work emails will be personal data. It
really is meant to be that all-encompassing.

You ask "how do I know which ....?" but that is the wrong question. Nothing
in A2(a) requires that the person asking the question "is it personal data"
can themselves identify the individual, what it requires is that someone
can.

This is logical and sensible. It means that if you have data that is (say)
sensitive health data with secret patient ID's attached so that you can't
reidentify the patients, but there is a list identifying them somewhere
else, then that is personal data and you have to take care of it, eg by
ensuring proper security of it, even though you may not personally be able
to misuse it. It might fall into the hands of someone who can misuse it.

Now the Data Protection Act 1998 isn't drafted like that. It uses a
slightly more restrictive definition of "personal data". I don't believe
we've had convincing UK authority that relied on that difference, and I
advise clients not to assume that they can get away in the UK with
something that Europe clearly forbids.

-- 
Francis Davey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.chiark.greenend.org.uk/pipermail/ukcrypto/attachments/20140613/4f0e303b/attachment-0001.html>

From bdm at fenrir.org.uk  Fri Jun 13 10:47:23 2014
From: bdm at fenrir.org.uk (Brian Morrison)
Date: Fri, 13 Jun 2014 10:47:23 +0100
Subject: RIPA s 12(7)
In-Reply-To: <7831B5DF-31B9-4872-A110-26385914B715@batten.eu.org>
References: <53994C11.4030705@pmsommer.com> <53998CE9.1000507@casparbowden.net>
	<7831B5DF-31B9-4872-A110-26385914B715@batten.eu.org>
Message-ID: <20140613104723.00005d70@surtees.fenrir.org.uk>

On Thu, 12 Jun 2014 15:44:43 +0100
Ian Batten wrote:

> "well, you could run that service, but you'd have to convince a judge
> that your fancy zero-knowledge proof was genuine when you claim you
> can't decrypt stuff on your network, encrypted with your software,
> using keys that you store"

But isn't that the wrong thing to do? Surely the keys stored will only
be the public keys, not the secret keys?

-- 

Brian Morrison


From lists at casparbowden.net  Fri Jun 13 16:05:29 2014
From: lists at casparbowden.net (Caspar Bowden (lists))
Date: Fri, 13 Jun 2014 17:05:29 +0200
Subject: RIPA s 12(7)
In-Reply-To: <D734523A-695B-4977-9FBA-3AF482AA8D42@batten.eu.org>
References: <53994C11.4030705@pmsommer.com>
	<53998CE9.1000507@casparbowden.net>	<5399DA15.2010101@pmsommer.com>
	<5399E5C5.20306@casparbowden.net>
	<D734523A-695B-4977-9FBA-3AF482AA8D42@batten.eu.org>
Message-ID: <539B1339.3060605@casparbowden.net>

On 06/12/14 22:04, Ian Batten wrote:
> On 12 Jun 2014, at 18:39, Caspar Bowden (lists) <lists at casparbowden.net> wrote:
>> that looks broad enough to ask for the source code to any client-side Webmail encrypting widget. Quite useful.
> It's also broad enough to get a server's private key if RSA was in use: if you've intercepted encrypted sessions, then
> having the RSA private key allows you to extract the session keys.  There's a proportionality and collateral issue, but
> of course the S.49 notice could be used to demand the CSP decrypt encrypted session keys and provided
> by the agency, and therefore satisfy the needs of the investigator without releasing a long-term key.
>
> However, I'm not sure whether the police would be overly interested in any of this, because even if the CSP coughs
> all the keys, it's intercept and therefore not admissible.  They'll need other, non-intercept evidence to get the intercept
> warrant, and they'll need other, non-intercept evidence to get a conviction.  Cases where the intercept evidence is
> therefore hugely significant, to the point of it being worth messing around with production orders, are going to be
> thin on the ground.  And stuff which is admissible when decrypted, for example memory sticks seized under search
> warrants or computers with "data at rest" ditto, is much less likely to have keys held by anyone other than the
> putative owner.

Knowing RSA (or D-H?) key from Pt.3, can do lawful cert-spoofing (Pt.2 
?) attack via Quantum, inject bad client-side code (if SSL only code 
authentication), and can lawfully target that in UK in "external" comms 
under s.16

Sounds very useful for JTRIG, "domestic extremists"

For police work, once docs known to exists, can be garnered/gardened by 
other means...

CB


From igb at batten.eu.org  Fri Jun 13 18:06:42 2014
From: igb at batten.eu.org (Ian Batten)
Date: Fri, 13 Jun 2014 18:06:42 +0100
Subject: RIPA s 12(7)
In-Reply-To: <20140613104723.00005d70@surtees.fenrir.org.uk>
References: <53994C11.4030705@pmsommer.com> <53998CE9.1000507@casparbowden.net>
	<7831B5DF-31B9-4872-A110-26385914B715@batten.eu.org>
	<20140613104723.00005d70@surtees.fenrir.org.uk>
Message-ID: <56BCA3AD-40CE-469F-B9FD-8A7EA3567C8D@batten.eu.org>


On 13 Jun 2014, at 10:47, Brian Morrison <bdm at fenrir.org.uk> wrote:

> On Thu, 12 Jun 2014 15:44:43 +0100
> Ian Batten wrote:
> 
>> "well, you could run that service, but you'd have to convince a judge
>> that your fancy zero-knowledge proof was genuine when you claim you
>> can't decrypt stuff on your network, encrypted with your software,
>> using keys that you store"
> 
> But isn't that the wrong thing to do? Surely the keys stored will only
> be the public keys, not the secret keys?

Yes, but it may not be quite as simple to show that you don?t have the private key if you?re
offering something more exotic than simply a directory of public keys.   For example, 
some of the certificate vendors have a ?for the less sophisticated? path where instead of
submitting a CSR, you instead ask for a signed certificate and are given a certificate and
a private key.   They presumably then discard the private key.  Proving they did that might
be quite entertaining.  

ian

From chl at clerew.man.ac.uk  Sat Jun 14 12:44:19 2014
From: chl at clerew.man.ac.uk (Charles Lindsey)
Date: Sat, 14 Jun 2014 12:44:19 +0100
Subject: Off topic: DPA question
In-Reply-To: <v4ckp9dt6mqbt1qi4gsoh34q9db0sjkq58@4ax.com>
References: <aj3jp9p51vpsei2hc77didaab6l3a85qj9@4ax.com>
	<CAEWR3kvncOPO-1x37H2LaA6hbaQXWzWznp+UOGWGyYHBBXywkg@mail.gmail.com>
	<v4ckp9dt6mqbt1qi4gsoh34q9db0sjkq58@4ax.com>
Message-ID: <op.xhfz75d16hl8nm@clerew.man.ac.uk>

On Fri, 13 Jun 2014 00:01:25 +0100, Marcus Williamson  
<marcus at connectotel.com> wrote:

> On Thu, 12 Jun 2014 20:59:56 +0100, you wrote:
>
>> That depends on whether the email address relates to a living individual
>> (and also whether that individual is identified or identifiable).
>
> Hello Francis
>
> Thank you - in this case the email address relates to a living  
> individual.
>
> In my view, their personal (non-business) email address would be personal
> information but their business email address would not be.
>
> Any thoughts please? Thank you!

Nominet seem to have a system for deciding whose name shall be published  
as owner of the domain in response to Whois, and whose should not.

If I registered a domain lindsey.me.uk, then whois would not indicate that  
I owned it. But try doing a whois on usenet.org.uk :-).

-- 
Charles H. Lindsey ---------At Home, doing my own  
thing------------------------
Tel: +44 161 436 6131                         Web:  
http://www.cs.man.ac.uk/~chl
Email: chl at clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU,  
U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4  
AB A5


From lists at internetpolicyagency.com  Sat Jun 14 15:07:36 2014
From: lists at internetpolicyagency.com (Roland Perry)
Date: Sat, 14 Jun 2014 15:07:36 +0100
Subject: Off topic: DPA question
In-Reply-To: <op.xhfz75d16hl8nm@clerew.man.ac.uk>
References: <aj3jp9p51vpsei2hc77didaab6l3a85qj9@4ax.com>
	<CAEWR3kvncOPO-1x37H2LaA6hbaQXWzWznp+UOGWGyYHBBXywkg@mail.gmail.com>
	<v4ckp9dt6mqbt1qi4gsoh34q9db0sjkq58@4ax.com>
	<op.xhfz75d16hl8nm@clerew.man.ac.uk>
Message-ID: <SOGdhALocFnTFAss@perry.co.uk>

In article <op.xhfz75d16hl8nm at clerew.man.ac.uk>, Charles Lindsey 
<chl at clerew.man.ac.uk> writes
>Nominet seem to have a system for deciding whose name shall be 
>published  as owner of the domain in response to Whois, and whose 
>should not.
>
>If I registered a domain lindsey.me.uk, then whois would not indicate 
>that  I owned it. But try doing a whois on usenet.org.uk :-).

I think it's more a case of having a rule about who can opt-out, and 
when that rule was introduced.
-- 
Roland Perry


From zenadsl6186 at zen.co.uk  Sat Jun 14 21:37:05 2014
From: zenadsl6186 at zen.co.uk (Peter Fairbrother)
Date: Sat, 14 Jun 2014 21:37:05 +0100
Subject: RIPA S.12(7) and other pressure points
In-Reply-To: <EC846839-8C56-4430-8F9D-B08FE977A6A3@batten.eu.org>
References: <EC846839-8C56-4430-8F9D-B08FE977A6A3@batten.eu.org>
Message-ID: <539CB271.3070606@zen.co.uk>

On 11/06/14 12:40, Ian Batten wrote:
> Hey ho, we're on the RIPA train again.
>
> RIPA section 12 lays down provision for the home secretary to direct CSPs to maintain an interception capability.
>
> Section 12(7) provides that if a CSP refuses, the Home Secretary can go to a (civil) court and seek remedies.
>
> To be concrete, imagine an email provider (Gmail, say) or ISP who proposes to run a service that
>   encourages or enables their customers to run end-to-end encryption, such that the ISP (etc) did
> _not_ have any keys to respond to a a RIPA S.49 notice.  And let's assume for the purposes at hand that they
> can prove they don't have keys in a relatively accessible and comprehensible way.
>
> Some questions that have arisen from a debate with a colleague.
>
> 1.  Imagine your clients are using end-to-end encryption, and you have somehow encouraged them.  Do your S.12
> responsibilities include any obligation to make it easier for an interception to obtain plaintext (or, alternatively,
> to not make it any harder)?

The Regulation of Investigatory Powers (Maintenance of Interception 
Capability) Order 2002

Schedule: OBLIGATIONS ON SERVICE PROVIDERS

"10. To ensure that the person on whose application the interception 
warrant was issued is able to remove any electronic protection applied 
by the service provider to the intercepted communication and the related 
communications data."


As I read that, it only applies to encryption applied by the service 
provider, not to any encryption applied by the users.

I don't think the fact that the service provider has encouraged the 
users to use encryption makes any difference, the service provider has 
not applied the encryption himself.

As you point out, if you can prove you don't have any keys then you 
can't be served a RIPA s.49 notice (which can require you to assist in 
making comms intelligible in other ways than using a key - but if you 
don't have keys, they can't serve you a s.49 notice in the first place).




Under s. 12 the Secretary of State can only give notices requiring 
behaviour from service providers which is in accord with an existing 
order - and making it easier for an interception to obtain plaintext 
(or, alternatively, to not make it any harder) does not fall under the 
only order in existence, as above.

The Secretary of State could of course make a new order under RIPA s.12, 
which would have to go through Parliament. An order requiring assistance 
with encryption as you describe would probably just about technically 
pass muster, see eg s.12(11); but as yet such an order hasn't been made.

I doubt it would be politically acceptable however, for the moment at least.


> 2.  This thanks to Julian Huppert when we asked him about this on Monday.  Could S.94 of the Telecommunications
> Act be engaged to try to convince the operator to modify their network?

Modification of the network (assuming it was such "as to make some or 
all of the contents of the communication available, while being 
transmitted, to a person other than the sender or intended recipient of 
the communication") would be interception under RIPA.


It might well be lawful interception under:

RIPA ss.1(5) "(c) it is in exercise, in relation to any stored 
communication, of any statutory power that is exercised (apart from this 
section) for the purpose of obtaining information or of taking 
possession of any document or other property;"

see eg  (NTL Group Ltd) v Crown Court at Ipswich for a judicial 
redefinition of "stored communication".


However if it wasn't lawful under ss.1(5) as above, then afaict the 
Telecommunications Act 1984 does not make the modification, and thus the 
interception, lawful.

Section 94 of the Telecommunications Act 1984 does not authorise 
otherwise unlawful acts (except as in 94(3) as amended, not relevant here).

> As amended, S.94(8) limits this to
> "providers of public electronic communications networks".  As Julian pointed out, "telecommunications networks" aren't
> defined in the 1984 Act; further reading of the history of S.94(8) implies that the meaning from S.32 of the
> Communications Act 2003 applies, which would cover pretty well any imaginable service offered at scale.

Yes - though s.94 would not apply to eg people who (only) supply 
encryption software.


> 3.  Has any CSP who has been approached with S.12 powers refused to comply (other than by shutting down
> the service?)  As the Technical Advisory Board has never met, one would tend to suspect that no such dispute
> has ever taken place.
>
> 4.  If someone did refuse, forced a meeting of the TAB, still refused, and ended up in court, how likely is it that
> the government would (a) fight and (b) win an action under S.12(7)?
>
> My core question is: if you decided to deploy a service which offered strong end-to-end encryption, it's likely it
> would attract interest from agencies.  If you were of a mind to follow in the footsteps of Richard Ingram in
> Arkell v Pressdram and force the matter to a court, what would be the likely outcome?

You would probably be required to assist. somehow - even if the 
judgement wasn't exactly in line with the law, see eg  (NTL Group Ltd) v 
Crown Court at Ipswich. Judges often just make it up as they go along.

I repeat,

End-to-end encryption should really be end-to-end - it should be 
impossible for the service provider to able to provide any assistance in 
in obtaining plaintext.

>
> [[ This is a hypothetical question, by the way: I have no such product, nor any such intention. ]]
>
> My guesses are (1) No (2) on the face of it yes (3) I suspect not (4) who knows?

Yes.

> My answer to the core
> question is that the government would do almost anything to avoid the dispute getting into open court.

Yes. But we also have closed Courts these days ...


-- Peter F



From zenadsl6186 at zen.co.uk  Sat Jun 14 21:49:26 2014
From: zenadsl6186 at zen.co.uk (Peter Fairbrother)
Date: Sat, 14 Jun 2014 21:49:26 +0100
Subject: RIPA s 12(7)
In-Reply-To: <53998CE9.1000507@casparbowden.net>
References: <53994C11.4030705@pmsommer.com> <53998CE9.1000507@casparbowden.net>
Message-ID: <539CB556.2010500@zen.co.uk>

On 12/06/14 12:20, Caspar Bowden (lists) wrote:
> On 06/12/14 08:43, Peter Sommer wrote:
>> ..
>> GMail or any of the non-UK webmail service providers could however
>> embed encryption into their offerings but the UK government would not
>> be able to force them to introduce an interception capability;  it
>> would have to be done by agreement.
>
> ..but a s.49 RIP order can require CSP to produce plaintext (or key) to
> any past (or future) data. If the key isn't available (e.g there is
> client-side code) a recipient of a s.49 can be required to give all
> co-operation necessary to have a defence.

Not entirely.

RIPA subsection 49(2) "If any person with the appropriate permission 
under Schedule 2 believes, on reasonable grounds?

(a)that a key to the protected information is in the possession of any 
person, [and ...]"

he can issue a notice which can require more cooperation than the use of 
the key. However if it is unreasonable for him to so believe then no 
such notice can be issued.

The first time, maybe the cops would get away with it - but afterwards, 
when it is known that no relevant key is in the possession of the ISP, 
then no notice can be issued - even if it is known that the ISP could 
otherwise provide plaintext.

-- Peter F


>
> Wonder opinions if this sufficient for UK to (coercively) "do a
> Hushmail" ? Or under Intel Services Act, or RIPA Pt.2 ?
>
> CB
>
>



From zenadsl6186 at zen.co.uk  Sat Jun 14 21:53:33 2014
From: zenadsl6186 at zen.co.uk (Peter Fairbrother)
Date: Sat, 14 Jun 2014 21:53:33 +0100
Subject: RIPA S.12(7) and other pressure points
In-Reply-To: <539863AD.3060608@ernest.net>
References: <EC846839-8C56-4430-8F9D-B08FE977A6A3@batten.eu.org>
	<539863AD.3060608@ernest.net>
Message-ID: <539CB64D.2090606@zen.co.uk>

On 11/06/14 15:11, Nicholas Bohm wrote:
> On 11/06/2014 12:40, Ian Batten wrote:

>> 2.  This thanks to Julian Huppert when we asked him about this on Monday.  Could S.94 of the Telecommunications
>> Act be engaged to try to convince the operator to modify their network?  As amended, S.94(8) limits this to
>> "providers of public electronic communications networks".  As Julian pointed out, "telecommunications networks" aren't
>> defined in the 1984 Act; further reading of the history of S.94(8) implies that the meaning from S.32 of the
>> Communications Act 2003 applies, which would cover pretty well any imaginable service offered at scale.
>
> Anything at all can be ordered, provided it is proportionate, and that
> must include modifying the service.


I don't agree - the SoS can't order you to murder your wife under s.94, 
for example. Directions under s.94 can only be to make or not make 
lawful actions (except as in 94(3), not relevant here).


-- Peter F


From nbohm at ernest.net  Sun Jun 15 09:54:14 2014
From: nbohm at ernest.net (Nicholas Bohm)
Date: Sun, 15 Jun 2014 09:54:14 +0100
Subject: RIPA S.12(7) and other pressure points
In-Reply-To: <539CB64D.2090606@zen.co.uk>
References: <EC846839-8C56-4430-8F9D-B08FE977A6A3@batten.eu.org>	<539863AD.3060608@ernest.net>
	<539CB64D.2090606@zen.co.uk>
Message-ID: <539D5F36.2070506@ernest.net>

An HTML attachment was scrubbed...
URL: <http://www.chiark.greenend.org.uk/pipermail/ukcrypto/attachments/20140615/e3fcbff8/attachment.html>

From ukcrypto at absent-minded.com  Sun Jun 15 09:27:16 2014
From: ukcrypto at absent-minded.com (Mark Lomas)
Date: Sun, 15 Jun 2014 09:27:16 +0100
Subject: OxCEPT
In-Reply-To: <yCGViYQuKvmTFAAl@perry.co.uk>
References: <539AACCA.8030809@iosis.co.uk> <539AC099.5050101@ja.net>
	<yCGViYQuKvmTFAAl@perry.co.uk>
Message-ID: <CACAki+vc=jeXq-W_6xvhLb-vFUG1UCeBqS-P4Kh6GTe5g8s+6g@mail.gmail.com>

I think that the company is genuine, although I would like to see a
detailed description of their protocols.

This Wired article gives slightly more detail than the company's own
website.
http://www.wired.co.uk/news/archive/2013-12/19/spontaneous-security

Also, Bill Roscoe's (Head of Computer Science at Oxford) website suggests
that they are commercialising work he did with Gavin Lowe.
http://www.cs.ox.ac.uk/bill.roscoe/

A classic mistake for new companies is to talk to the press before filing
for a trademark (filing date 11 April 2014), but it appears that nobody
took advantage of that lapse. Presumably their trademark lawyer told them
that OxCEPT (same capitalisation) is already the name of the Oxford Centre
for Ecclesiology and Practical Theology, a Church of England training and
research programme.

For any of you planning to start a computer security company please publish
sufficient information on your website for peer review.


On 13 June 2014 13:46, Roland Perry <lists at internetpolicyagency.com> wrote:

> In article <539AC099.5050101 at ja.net>, James Davis <james.davis at ja.net>
> writes
>
>  Well to be fair they haven't even get the name of the University right
>> - despite it being correctly rendered in the seal :)
>>
>
> To be fair, to take just one example, the rowers are called Oxford
> University Boat Club (OUBC) and not the University of Oxford Boat Club
> (UOBC) so it's not surprising both forms of name are in widespread use.
> --
> Roland Perry
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.chiark.greenend.org.uk/pipermail/ukcrypto/attachments/20140615/034741b7/attachment.html>

From zenadsl6186 at zen.co.uk  Sun Jun 15 20:33:11 2014
From: zenadsl6186 at zen.co.uk (Peter Fairbrother)
Date: Sun, 15 Jun 2014 20:33:11 +0100
Subject: RIPA s 12(7)
In-Reply-To: <539CB556.2010500@zen.co.uk>
References: <53994C11.4030705@pmsommer.com> <53998CE9.1000507@casparbowden.net>
	<539CB556.2010500@zen.co.uk>
Message-ID: <539DF4F7.9070909@zen.co.uk>

On 14/06/14 21:49, Peter Fairbrother wrote:
> On 12/06/14 12:20, Caspar Bowden (lists) wrote:
>> On 06/12/14 08:43, Peter Sommer wrote:
>>> ..
>>> GMail or any of the non-UK webmail service providers could however
>>> embed encryption into their offerings but the UK government would not
>>> be able to force them to introduce an interception capability;  it
>>> would have to be done by agreement.
>>
>> ..but a s.49 RIP order can require CSP to produce plaintext (or key) to
>> any past (or future) data. If the key isn't available (e.g there is
>> client-side code) a recipient of a s.49 can be required to give all
>> co-operation necessary to have a defence.


Actually there is another and perhaps rather amusing issue here:

RIPA ss.50(2)

"A person subject to a requirement under subsection (1)(b) to make a 
disclosure of any information in an intelligible form [ie the recipient 
of a s.49 notice] shall be taken to have complied with that requirement if?

(a) he makes, instead, a disclosure of any key to the protected 
information that is in his possession; and [...]"


However, RIPA s.26

" (1) [...] ?key?, in relation to any electronic data, means any key, 
code, password, algorithm or other data the use of which (with or 
without other keys)?
(a) allows access to the electronic data, or
(b) facilitates the putting of the data into an intelligible form; "

and

"(2) References in this Part to a person?s having information (including 
a key to protected information) in his possession include references?

(a) to its being in the possession of a person who is under his control 
so far as that information is concerned;

(b) to his having an immediate right of access to it, or an immediate 
right to have it transmitted or otherwise supplied to him; [...]"

so make sure the Swiss lawyer only gives out keys at his discretion ...



[ as I understand this, Plod can then issue a s.49 notice. You reply 
"the only key I have in my possession is the datum that the Swiss lawyer 
may be able to supply a key."

You have then given them the only key in your possession, and complied 
with the notice as defined in ss.50(2) - and they cannot then use the 
notice to require you to do anything more, such as ask the Swiss lawyer 
for the key, as you have already complied with the notice ]


I am not a lawyer ...



-- Peter Fairbrother


>
> Not entirely.
>
> RIPA subsection 49(2) "If any person with the appropriate permission
> under Schedule 2 believes, on reasonable grounds?
>
> (a)that a key to the protected information is in the possession of any
> person, [and ...]"
>
> he can issue a notice which can require more cooperation than the use of
> the key. However if it is unreasonable for him to so believe then no
> such notice can be issued.
>
> The first time, maybe the cops would get away with it - but afterwards,
> when it is known that no relevant key is in the possession of the ISP,
> then no notice can be issued - even if it is known that the ISP could
> otherwise provide plaintext.

>
> -- Peter F
>
>
>>
>> Wonder opinions if this sufficient for UK to (coercively) "do a
>> Hushmail" ? Or under Intel Services Act, or RIPA Pt.2 ?
>>
>> CB
>>
>>
>
>
>



From zenadsl6186 at zen.co.uk  Sun Jun 15 21:26:25 2014
From: zenadsl6186 at zen.co.uk (Peter Fairbrother)
Date: Sun, 15 Jun 2014 21:26:25 +0100
Subject: RIPA s 12(7)
In-Reply-To: <539DF4F7.9070909@zen.co.uk>
References: <53994C11.4030705@pmsommer.com>
	<53998CE9.1000507@casparbowden.net>	<539CB556.2010500@zen.co.uk>
	<539DF4F7.9070909@zen.co.uk>
Message-ID: <539E0171.8020508@zen.co.uk>

On 15/06/14 20:33, Peter Fairbrother wrote:
>
> Actually there is another and perhaps rather amusing issue here:
>
> RIPA ss.50(2)
>
> "A person subject to a requirement under subsection (1)(b) to make a
> disclosure of any information in an intelligible form [ie the recipient
> of a s.49 notice] shall be taken to have complied with that requirement if?
>
> (a) he makes, instead, a disclosure of *any* key to the protected
> information that is in his possession; and [...]"

O Lawyers, does that mean that if eg it needs two keys to decrypt, and 
he supplies only one, he has complied with the requirement?


Or does the *any* mean *every*?


Enquiring minds, etc,


-- Peter F




From zenadsl6186 at zen.co.uk  Sun Jun 15 23:26:30 2014
From: zenadsl6186 at zen.co.uk (Peter Fairbrother)
Date: Sun, 15 Jun 2014 23:26:30 +0100
Subject: RIPA s 12(7)
In-Reply-To: <53998CE9.1000507@casparbowden.net>
References: <53994C11.4030705@pmsommer.com> <53998CE9.1000507@casparbowden.net>
Message-ID: <539E1D96.9060706@zen.co.uk>

On 12/06/14 12:20, Caspar Bowden (lists) wrote:
> On 06/12/14 08:43, Peter Sommer wrote:
>> ..
>> GMail or any of the non-UK webmail service providers could however
>> embed encryption into their offerings but the UK government would not
>> be able to force them to introduce an interception capability;  it
>> would have to be done by agreement.
>
> ..but a s.49 RIP order can require CSP to produce plaintext (or key) to
> any past (or future) data. If the key isn't available (e.g there is
> client-side code) a recipient of a s.49 can be required to give all
> co-operation necessary to have a defence.

I'm beginning to wonder whether that last is actually true.



If you read RIPA s.50, there are many ways the subject of a s.49 notice 
can comply with that notice. most obviously by supplying any/all the 
keys you have - but as far as I can see, you cannot be required to make 
any other actions beyond supplying keys.

OK, with the s.50 definitions of "keys" and "in possession", which do 
not have anything at all to do with the English Language, they are just 
used as terms for some legal stuff here, that's not a big space in 
between - but if an action does not involve revealing a "key" in your 
"possession", afaict you cannot be forced to do it under a s.49 order.


Most specifically, you can't be forced to ask someone else for keys to 
which you only have conditional access to.


I too used to think otherwise :(

>
> Wonder opinions if this sufficient for UK to (coercively) "do a
> Hushmail" ? Or under Intel Services Act, or RIPA Pt.2 ?

I'm not sure what you mean here.


-- Peter F



From zenadsl6186 at zen.co.uk  Sun Jun 15 23:49:40 2014
From: zenadsl6186 at zen.co.uk (Peter Fairbrother)
Date: Sun, 15 Jun 2014 23:49:40 +0100
Subject: RIPA s 12(7)
In-Reply-To: <539E0171.8020508@zen.co.uk>
References: <53994C11.4030705@pmsommer.com>	<53998CE9.1000507@casparbowden.net>	<539CB556.2010500@zen.co.uk>	<539DF4F7.9070909@zen.co.uk>
	<539E0171.8020508@zen.co.uk>
Message-ID: <539E2304.2070505@zen.co.uk>

Francis seems to have some email problems, reposted

> On 15/06/14 20:33, Peter Fairbrother wrote:
>>
>> Actually there is another and perhaps rather amusing issue here:
>>
>> RIPA ss.50(2)
>>
>> "A person subject to a requirement under subsection (1)(b) to make a
>> disclosure of any information in an intelligible form [ie the recipient
>> of a s.49 notice] shall be taken to have complied with that
>> requirement if?
>>
>> (a) he makes, instead, a disclosure of *any* key to the protected
>> information that is in his possession; and [...]"
>
> O Lawyers, does that mean that if eg it needs two keys to decrypt, and
> he supplies only one, he has complied with the requirement?
>
>
> Or does the *any* mean *every*?


Read on to (4) - (7). The drafters have thought about that. The effect 
of those subsections together with (2) suggest that (2) means "all 
subject to ...".

Translated into English: in a case where there are multiple keys, you 
may choose to disclose a subset of keys that, taken together, will allow 
access to the protected information. You need not disclose any other keys.

--
Francis Davey




From lists at casparbowden.net  Mon Jun 16 08:04:15 2014
From: lists at casparbowden.net (Caspar Bowden (lists))
Date: Mon, 16 Jun 2014 09:04:15 +0200
Subject: RIPA s 12(7)
In-Reply-To: <539E1D96.9060706@zen.co.uk>
References: <53994C11.4030705@pmsommer.com> <53998CE9.1000507@casparbowden.net>
	<539E1D96.9060706@zen.co.uk>
Message-ID: <539E96EF.9010103@casparbowden.net>

On 06/16/14 00:26, Peter Fairbrother wrote:
> On 12/06/14 12:20, Caspar Bowden (lists) wrote:
>> ....but a s.49 RIP order can require CSP to produce plaintext (or 
>> key) to
>> any past (or future) data. If the key isn't available (e.g there is
>> client-side code) a recipient of a s.49 can be required to give all
>> co-operation necessary to have a defence.
>
> I'm beginning to wonder whether that last is actually true.
> ..
>
> Most specifically, you can't be forced to ask someone else for keys to 
> which you only have conditional access to.

don't understand what you mean by "conditional"

>
>>
>> Wonder opinions if this sufficient for UK to (coercively) "do a
>> Hushmail" ? Or under Intel Services Act, or RIPA Pt.2 ?
>
> I'm not sure what you mean here.

http://www.wired.com/2007/11/encrypted-e-mai/

Actually I had forgotten that this case involved server-side extraction 
of key (read above). This is obviously within RIP Pt.3 - I remain 
worried about trying to find combo of UK powers which could coerce a 
client-side attack (e.g. he provider has to inject back-doored 
javascript code)

CB


From Andrew.Cormack at ja.net  Mon Jun 16 08:53:04 2014
From: Andrew.Cormack at ja.net (Andrew Cormack)
Date: Mon, 16 Jun 2014 07:53:04 +0000
Subject: Off topic: DPA question
In-Reply-To: <CAEWR3ksp+_aKWcdpNeP2kp-WoABO+8UcQf3jN=ivSCwbZ+rxyg@mail.gmail.com>
References: <aj3jp9p51vpsei2hc77didaab6l3a85qj9@4ax.com>
	<CAEWR3kvncOPO-1x37H2LaA6hbaQXWzWznp+UOGWGyYHBBXywkg@mail.gmail.com>
	<v4ckp9dt6mqbt1qi4gsoh34q9db0sjkq58@4ax.com>
	<61E52F3A5532BE43B0211254F13883AE9829D8E8@EXC001>
	<CAEWR3ksp+_aKWcdpNeP2kp-WoABO+8UcQf3jN=ivSCwbZ+rxyg@mail.gmail.com>
Message-ID: <61E52F3A5532BE43B0211254F13883AE9829FBF5@EXC001>

Francis
On the DPA point, ICO advice (including the recent Anonymisation Code) suggests that once separated from the lookup key, pseudonymised data may be very close to non-personal, because the DPA specifically says that the lookup key must be "in the possession of the data controller" (or likely to come into their possession). As you say, that may run into problems of insufficient protection of privacy, unregulated secondary use, etc. But the alternative approach, following the literal wording of the Directive ("if anyone can..."), also gets into problems, because if you treat keyed-data-without-key as personal data then several duties (including subject access requests and proactive notification of breaches) are impossible to satisfy. IP addresses highlight the problem: if you treat them as personal data then the law requires websites to respond people saying "I am aaa.bbb.ccc.ddd, show me the logs you hold for me" (and all the other previous holders of that DHCP-pool address), and if those logs get compromised then they may be required to let all the owners of those addresses know, somehow! Maintaining a record that that aaa.bbb.ccc.ddd gave consent to processing (e.g. to exporting their packets from the EEA) could also be interesting...

The draft Regulation tries to get out of this by the hideous hack of saying that if compliance with a duty would require you to collect additional data then you're excused that duty. That feels like a loophole that I expect corporate lawyers to drive a coach and horses through if it ever becomes law :(

We badly need a law that will recognise that there is a new category of "potential personal data", which did exist in 1995 but hadn't been noticed, and impose appropriate duties on it (probably based on the risk of identification and resulting harm). The ICO has been suggesting that for a while, but getting push-back from those who consider this "going soft on privacy". But under the present law, where it's presumed that unlinked data is fully personal, those who wish to comply can't and those who don't wish to comply have the perfect excuse not to :(

But the question was also about e-mails and there the PECR has a separate distinction between the addresses of "individual subscribers" and "others". The PECR, still transposing the original, unamended, Directive, only restricts sending of unsolicited advertising e-mail to individual subscribers. If you aren't an IS - for example because your company pays the bill (or, as far as I can see, your parent or significant other does) then PECR doesn't protect you from spamming, only DPA does :( 

Andrew 

--
Andrew Cormack
Chief Regulatory Adviser, Janet
t: +44 1235 822302
b: https://community.ja.net/blogs/regulatory-developments
Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is
registered in England under No.2881024 and whose Registered Office is at Lumen House, Library
Avenue, Harwell Oxford, Didcot, Oxfordshire, OX11 0SG. VAT No. 614944238


> -----Original Message-----
> From: ukcrypto-bounces at chiark.greenend.org.uk [mailto:ukcrypto-
> bounces at chiark.greenend.org.uk] On Behalf Of Francis Davey
> Sent: 13 June 2014 15:16
> To: UK Cryptography Policy Discussion Group
> Subject: Re: Off topic: DPA question
> 
> 2014-06-13 11:28 GMT+01:00 Andrew Cormack <Andrew.Cormack at ja.net>:
> 
> 
> 	Just to add a wrinkle the Privacy and Electronic Communications
> Regs *do* distinguish between e-mail addresses of "individual
> subscribers" and others :(
> 
> 	But even then it's pretty tricky, if you're external to the
> system, to try to distinguish them - how do you know whether
> andrew.cormack at ja.net is an 'individual subscriber' or not? Or indeed
> how do I know which marcus at connectotel.com is?
> 
> 
> 
> 
> The definition of personal data, for the purposes of the directive, is
> (in article 2(a)):
> 
> "(a) 'personal data' shall mean any information relating to an
> identified or identifiable natural person ('data subject'); an
> identifiable person is one who can be identified, directly or
> indirectly, in particular by reference to an identification number or
> to one or more factors specific to his physical, physiological, mental,
> economic, cultural or social identity;"
> 
> This is actually quite simple. It asks essentially two questions: (i)
> does the data relate to a natural person and (ii) are they identifiable
> (or identified, but of course an identified person is ex hypothesi
> identifiable).
> 
> A work email for an individual clearly relates to them. Some "role"
> email addresses may not (though as Roland points out, it will depend).
> 
> Can _someone_ identify that person? In most cases, yes.
> 
> So, in most cases, individuals' work emails will be personal data. It
> really is meant to be that all-encompassing.
> 
> You ask "how do I know which ....?" but that is the wrong question.
> Nothing in A2(a) requires that the person asking the question "is it
> personal data" can themselves identify the individual, what it requires
> is that someone can.
> 
> This is logical and sensible. It means that if you have data that is
> (say) sensitive health data with secret patient ID's attached so that
> you can't reidentify the patients, but there is a list identifying them
> somewhere else, then that is personal data and you have to take care of
> it, eg by ensuring proper security of it, even though you may not
> personally be able to misuse it. It might fall into the hands of
> someone who can misuse it.
> 
> Now the Data Protection Act 1998 isn't drafted like that. It uses a
> slightly more restrictive definition of "personal data". I don't
> believe we've had convincing UK authority that relied on that
> difference, and I advise clients not to assume that they can get away
> in the UK with something that Europe clearly forbids.
> 
> 
> --
> Francis Davey
> 



From lists at internetpolicyagency.com  Mon Jun 16 13:44:20 2014
From: lists at internetpolicyagency.com (Roland Perry)
Date: Mon, 16 Jun 2014 13:44:20 +0100
Subject: Off topic: DPA question
In-Reply-To: <61E52F3A5532BE43B0211254F13883AE9829FBF5@EXC001>
References: <aj3jp9p51vpsei2hc77didaab6l3a85qj9@4ax.com>
	<CAEWR3kvncOPO-1x37H2LaA6hbaQXWzWznp+UOGWGyYHBBXywkg@mail.gmail.com>
	<v4ckp9dt6mqbt1qi4gsoh34q9db0sjkq58@4ax.com>
	<61E52F3A5532BE43B0211254F13883AE9829D8E8@EXC001>
	<CAEWR3ksp+_aKWcdpNeP2kp-WoABO+8UcQf3jN=ivSCwbZ+rxyg@mail.gmail.com>
	<61E52F3A5532BE43B0211254F13883AE9829FBF5@EXC001>
Message-ID: <hn1BbUAkaunTFAZf@perry.co.uk>

In article <61E52F3A5532BE43B0211254F13883AE9829FBF5 at EXC001>, Andrew 
Cormack <Andrew.Cormack at ja.net> writes
>The PECR, still transposing the original, unamended, Directive, only restricts sending of unsolicited advertising e-mail to individual
>subscribers. If you aren't an IS - for example because your company pays the bill (or, as far as I can see, your parent or significant other
>does) then PECR doesn't protect you from spamming, only DPA does :(

But it still does, quite adequately, should anyone be bothered to 
enforce it.
-- 
Roland Perry


From fjmd1a at gmail.com  Mon Jun 16 14:56:27 2014
From: fjmd1a at gmail.com (Francis Davey)
Date: Mon, 16 Jun 2014 14:56:27 +0100
Subject: Off topic: DPA question
In-Reply-To: <61E52F3A5532BE43B0211254F13883AE9829FBF5@EXC001>
References: <aj3jp9p51vpsei2hc77didaab6l3a85qj9@4ax.com>
	<CAEWR3kvncOPO-1x37H2LaA6hbaQXWzWznp+UOGWGyYHBBXywkg@mail.gmail.com>
	<v4ckp9dt6mqbt1qi4gsoh34q9db0sjkq58@4ax.com>
	<61E52F3A5532BE43B0211254F13883AE9829D8E8@EXC001>
	<CAEWR3ksp+_aKWcdpNeP2kp-WoABO+8UcQf3jN=ivSCwbZ+rxyg@mail.gmail.com>
	<61E52F3A5532BE43B0211254F13883AE9829FBF5@EXC001>
Message-ID: <CAEWR3kuJCUVNxd858fso=3+b7mdHjnxkuZNJe5oitd+1NJA0MA@mail.gmail.com>

2014-06-16 8:53 GMT+01:00 Andrew Cormack <Andrew.Cormack at ja.net>:

> Francis
> On the DPA point, ICO advice (including the recent Anonymisation Code)
> suggests that once separated from the lookup key, pseudonymised data may be
> very close to non-personal, because the DPA specifically says that the
> lookup key must be "in the possession of the data controller" (or likely to
> come into their possession). As you say, that may run into problems of
> insufficient protection of privacy, unregulated secondary use, etc.


Yes, I agree that the UK and UK ICO's have been very keen not to adopt the
wider European definition. I think it is the logically more sensible of the
two and that the sorts of problems you outline (eg to do with SAR's) could
be fixed without great difficulty. As you say, we will soon have a
regulation to argue about.

Note for those on list who aren't familiar with the distinction (though I
expect that everyone on this list is really well informed and better than
many lawyers): the key difference between a directive and a regulation (in
EU law) is that a directive needs to be implemented ("transposed") into
member states' laws; regulations don't.

What this will mean is that the new regulation's wording will be what UK
courts have to rely on, rather than whatever garbled version the UK's
drafters may have ended up with. In other words: there will be more
cross-European standardisation (perhaps even harmony :-).

-- 
Francis Davey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.chiark.greenend.org.uk/pipermail/ukcrypto/attachments/20140616/9b22d23b/attachment.html>

From dfawcus+lists-ukcrypto at employees.org  Mon Jun 16 14:59:58 2014
From: dfawcus+lists-ukcrypto at employees.org (Derek Fawcus)
Date: Mon, 16 Jun 2014 06:59:58 -0700
Subject: Off topic: DPA question
In-Reply-To: <61E52F3A5532BE43B0211254F13883AE9829FBF5@EXC001>
References: <aj3jp9p51vpsei2hc77didaab6l3a85qj9@4ax.com>
	<CAEWR3kvncOPO-1x37H2LaA6hbaQXWzWznp+UOGWGyYHBBXywkg@mail.gmail.com>
	<v4ckp9dt6mqbt1qi4gsoh34q9db0sjkq58@4ax.com>
	<61E52F3A5532BE43B0211254F13883AE9829D8E8@EXC001>
	<CAEWR3ksp+_aKWcdpNeP2kp-WoABO+8UcQf3jN=ivSCwbZ+rxyg@mail.gmail.com>
	<61E52F3A5532BE43B0211254F13883AE9829FBF5@EXC001>
Message-ID: <20140616135958.GA12552@banjo.employees.org>

On Mon, Jun 16, 2014 at 07:53:04am +0000, Andrew Cormack wrote:
> But the question was also about e-mails and there the PECR has a separate distinction between
> the addresses of "individual subscribers" and "others". The PECR, still transposing the original,
> unamended, Directive, only restricts sending of unsolicited advertising e-mail to individual subscribers.
> If you aren't an IS - for example because your company pays the bill (or, as far as I can see,
> your parent or significant other does) then PECR doesn't protect you from spamming, only DPA does :( 

You might wish to read about Adrian Kennard's battle on the 'individual subscriber' front,
he seems to have taken the position that unless the sender knows the addresss is _not_
an individual subscriber,  they must not send such;  and that usually the sender can not
know that.

   http://revk.www.me.uk/search/label/SPAM
(some of the above are telephone,  some email)

.pdf


From igb at batten.eu.org  Tue Jun 17 09:08:53 2014
From: igb at batten.eu.org (Ian Batten)
Date: Tue, 17 Jun 2014 09:08:53 +0100
Subject: Retrospective Warrants: Legal Theory?
Message-ID: <9B56CEA2-C50E-43DC-B8AB-AD104CE5C41E@batten.eu.org>

The GCHQ/NSA narrative on bulk interception appears to be that it's OK provided the data isn't
looked at by humans without a warrant.   There seems to be an assumption that it's OK to data-mine
bulk data, but that before the data belonging to an individual is looked at by humans there has to be a warrant.

I think the first part of that argument has a fairly straightforward legal basis (whatever my personal view
might be on the morality of it). RIPA S.2(2) defines intercept to occur when content is made available
"to a PERSON other than the sender or intended recipient of the communication" (my emphasis). 
I doubt a court would agree with the contention that software under the control of a person is equivalent to a person.

My interest is the legal theory which allows them to look at the output from that chain.  

S.9(6)(c) is quite clear about the period for which a new warrant is valid: "the period of three months beginning
with the day of the warrant?s issue".  So if you have a bulk data store, and are relying on S.2(2) to permit you
to data-mine it, why would a S.6 warrant give a person any authority to look at the data?  S.2(8) could be read
to outlaw the storage of bulk data full stop ("shall include any case in which any of the contents of the communication, 
while being transmitted, are diverted or recorded so as to be available to a person subsequently.")  but even taking
the most favourable to the authorities reading of "so as to be available", which only covers when the data is
actually made available, it seems to outlaw "store it, then get a warrant later".  S.2(7) is about data at rest which the
subscriber has access to, voicemail and inboxes and suchlike ("storing it in a manner that enables the intended
recipient to collect it or otherwise to have access to it") but S.2(8) doesn't appear to refer to subscriber storage,
rather to storage as part of the interception.

So I think that a narrow reading of S.2(8) outlaws storage without a warrant and later extraction under warrant.
But I can't think of any reading of S.2(8) which permits you to store data, search it automatically (under a reading
of S.2(2) which permits non-human access), get a warrant on the basis of the selectors that throws up, and
then read the content under a S.6 warrant.  

So if GCHQ are storing bulk data, analysing it, then applying for warrants to access the content (as they
seem to be admitting), I think it breaches RIPA S.1(1) because S.2(8) explicitly forbids access to recorded
content.

Thoughts?

ian





 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.chiark.greenend.org.uk/pipermail/ukcrypto/attachments/20140617/2bb720d7/attachment.html>

From nbohm at ernest.net  Tue Jun 17 10:16:05 2014
From: nbohm at ernest.net (Nicholas Bohm)
Date: Tue, 17 Jun 2014 10:16:05 +0100
Subject: Retrospective Warrants: Legal Theory?
In-Reply-To: <9B56CEA2-C50E-43DC-B8AB-AD104CE5C41E@batten.eu.org>
References: <9B56CEA2-C50E-43DC-B8AB-AD104CE5C41E@batten.eu.org>
Message-ID: <53A00755.2050905@ernest.net>

An HTML attachment was scrubbed...
URL: <http://www.chiark.greenend.org.uk/pipermail/ukcrypto/attachments/20140617/a091984b/attachment.html>

From igb at batten.eu.org  Tue Jun 17 11:35:58 2014
From: igb at batten.eu.org (Ian Batten)
Date: Tue, 17 Jun 2014 11:35:58 +0100
Subject: Retrospective Warrants: Legal Theory?
In-Reply-To: <53A00755.2050905@ernest.net>
References: <9B56CEA2-C50E-43DC-B8AB-AD104CE5C41E@batten.eu.org>
	<53A00755.2050905@ernest.net>
Message-ID: <7B7AC43C-E751-42EA-9BB0-7B1EA86669D7@batten.eu.org>


On 17 Jun 2014, at 10:16, Nicholas Bohm <nbohm at ernest.net> wrote:

> On 17/06/2014 09:08, Ian Batten wrote:
>> The GCHQ/NSA narrative on bulk interception appears to be that it's OK provided the data isn't
>> looked at by humans without a warrant.   There seems to be an assumption that it's OK to data-mine
>> bulk data, but that before the data belonging to an individual is looked at by humans there has to be a warrant.
>> 
>> I think the first part of that argument has a fairly straightforward legal basis (whatever my personal view
>> might be on the morality of it). RIPA S.2(2) defines intercept to occur when content is made available
>> "to a PERSON other than the sender or intended recipient of the communication" (my emphasis). 
>> I doubt a court would agree with the contention that software under the control of a person is equivalent to a person.
> 
> This is inconsistent with section 16(2), 

That's an interesting point.

My reading is that section 16 is only engaged by "certificated warrants", S.8(4), and that appears
to exclude material relating to people located in the UK  S.16(2)(a).  But I confess to struggling
with the language ("falls within this subsection so far only as it is selected to be read, looked at or listened 
to otherwise than according to a factor which" --- does the otherwise mean "other than as in the follow
sections" or is it attached to the "listened to"?)

ian



From lists at casparbowden.net  Tue Jun 17 12:19:01 2014
From: lists at casparbowden.net (Caspar Bowden (lists))
Date: Tue, 17 Jun 2014 13:19:01 +0200
Subject: Retrospective Warrants: Legal Theory?
In-Reply-To: <7B7AC43C-E751-42EA-9BB0-7B1EA86669D7@batten.eu.org>
References: <9B56CEA2-C50E-43DC-B8AB-AD104CE5C41E@batten.eu.org>	<53A00755.2050905@ernest.net>
	<7B7AC43C-E751-42EA-9BB0-7B1EA86669D7@batten.eu.org>
Message-ID: <53A02425.5080702@casparbowden.net>

On 06/17/14 12:35, Ian Batten wrote:
> On 17 Jun 2014, at 10:16, Nicholas Bohm <nbohm at ernest.net> wrote:
>
>> On 17/06/2014 09:08, Ian Batten wrote:
>>> The GCHQ/NSA narrative on bulk interception appears to be that it's OK provided the data isn't
>>> looked at by humans without a warrant.   There seems to be an assumption that it's OK to data-mine
>>> bulk data, but that before the data belonging to an individual is looked at by humans there has to be a warrant.
>>>
>>> I think the first part of that argument has a fairly straightforward legal basis (whatever my personal view
>>> might be on the morality of it). RIPA S.2(2) defines intercept to occur when content is made available
>>> "to a PERSON other than the sender or intended recipient of the communication" (my emphasis).
>>> I doubt a court would agree with the contention that software under the control of a person is equivalent to a person.
>> This is inconsistent with section 16(2),
> That's an interesting point.
>
> My reading is that section 16 is only engaged by "certificated warrants", S.8(4), and that appears
> to exclude material relating to people located in the UK  S.16(2)(a).  But I confess to struggling
> with the language ("falls within this subsection so far only as it is selected to be read, looked at or listened
> to otherwise than according to a factor which" --- does the otherwise mean "other than as in the follow
> sections" or is it attached to the "listened to"?)

This is what we know from 2000
http://www.fipr.org/rip/Bassam%20reply%20to%20Phillips%20on%20S.15.3.htm

Caspar


From nbohm at ernest.net  Tue Jun 17 12:20:49 2014
From: nbohm at ernest.net (Nicholas Bohm)
Date: Tue, 17 Jun 2014 12:20:49 +0100
Subject: Retrospective Warrants: Legal Theory?
In-Reply-To: <7B7AC43C-E751-42EA-9BB0-7B1EA86669D7@batten.eu.org>
References: <9B56CEA2-C50E-43DC-B8AB-AD104CE5C41E@batten.eu.org>
	<53A00755.2050905@ernest.net>
	<7B7AC43C-E751-42EA-9BB0-7B1EA86669D7@batten.eu.org>
Message-ID: <53A02491.7070502@ernest.net>

An HTML attachment was scrubbed...
URL: <http://www.chiark.greenend.org.uk/pipermail/ukcrypto/attachments/20140617/e75da321/attachment.html>

From Andrew.Cormack at ja.net  Tue Jun 17 10:47:09 2014
From: Andrew.Cormack at ja.net (Andrew Cormack)
Date: Tue, 17 Jun 2014 09:47:09 +0000
Subject: Off topic: DPA question
In-Reply-To: <20140616135958.GA12552@banjo.employees.org>
References: <aj3jp9p51vpsei2hc77didaab6l3a85qj9@4ax.com>
	<CAEWR3kvncOPO-1x37H2LaA6hbaQXWzWznp+UOGWGyYHBBXywkg@mail.gmail.com>
	<v4ckp9dt6mqbt1qi4gsoh34q9db0sjkq58@4ax.com>
	<61E52F3A5532BE43B0211254F13883AE9829D8E8@EXC001>
	<CAEWR3ksp+_aKWcdpNeP2kp-WoABO+8UcQf3jN=ivSCwbZ+rxyg@mail.gmail.com>
	<61E52F3A5532BE43B0211254F13883AE9829FBF5@EXC001>
	<20140616135958.GA12552@banjo.employees.org>
Message-ID: <61E52F3A5532BE43B0211254F13883AE982A31B1@EXC001>

> -----Original Message-----
> From: ukcrypto-bounces at chiark.greenend.org.uk [mailto:ukcrypto-
> bounces at chiark.greenend.org.uk] On Behalf Of Derek Fawcus
> Sent: 16 June 2014 15:00
> To: UK Cryptography Policy Discussion Group
> Subject: Re: Off topic: DPA question
> 
> On Mon, Jun 16, 2014 at 07:53:04am +0000, Andrew Cormack wrote:
> > But the question was also about e-mails and there the PECR has a
> separate distinction between
> > the addresses of "individual subscribers" and "others". The PECR,
> still transposing the original,
> > unamended, Directive, only restricts sending of unsolicited
> advertising e-mail to individual subscribers.
> > If you aren't an IS - for example because your company pays the bill
> (or, as far as I can see,
> > your parent or significant other does) then PECR doesn't protect you
> from spamming, only DPA does :(
> 
> You might wish to read about Adrian Kennard's battle on the 'individual
> subscriber' front,
> he seems to have taken the position that unless the sender knows the
> addresss is _not_
> an individual subscriber,  they must not send such;  and that usually
> the sender can not
> know that.
> 
>    http://revk.www.me.uk/search/label/SPAM
> (some of the above are telephone,  some email)
> 
> .pdf

<grin/> I've both read it and heard about it from Adrian over dinner!

Since the law for individual subscribers is that they can only be sent unsolicited advertising material after they have taken some positive action ("soft opt-in"), it seems logical to me that the sender must know either that someone isn't an IS, or that they are and have taken the required action. Otherwise you simply re-create an opt-out (as for phone or text marketing) where it's OK to spam someone until they tell you that they are an IS.

>From a quick look at the ICO's 'what we are doing' pages, it doesn't seem as if they've done any enforcement specifically on e-mails yet (either under the PECR or DPA). The actions I see mentioned either related to sending phone or SMS to people who have actively opted out by joining TPS, or to processing personal data without being registered with the ICO.

And as far as I recall the successful private actions have been for not ceasing processing when ordered to, so again avoiding this unclear area of law.

Andrew


From zenadsl6186 at zen.co.uk  Tue Jun 17 14:53:34 2014
From: zenadsl6186 at zen.co.uk (Peter Fairbrother)
Date: Tue, 17 Jun 2014 14:53:34 +0100
Subject: Retrospective Warrants: Legal Theory?
In-Reply-To: <9B56CEA2-C50E-43DC-B8AB-AD104CE5C41E@batten.eu.org>
References: <9B56CEA2-C50E-43DC-B8AB-AD104CE5C41E@batten.eu.org>
Message-ID: <53A0485E.1040300@zen.co.uk>

On 17/06/14 09:08, Ian Batten wrote:
[..]
> I think the first part of that argument has a fairly straightforward
> legal basis (whatever my personal view
> might be on the morality of it). RIPA S.2(2) defines intercept to occur
> when content is made available
> "to a PERSON other than the sender or intended recipient of the
> communication" (my emphasis).
> I doubt a court would agree with the contention that software under the
> control of a person is equivalent to a person.

I'm pretty sure they would - in law a "person" is not the same as a 
human being, for example a company is a "person". I don't think it makes 
any difference whether you use software or eyes.

Note, the looking-at isn't the interception - it is the making available 
to look at which is.



My 2p: GCHQ scoop up all the traffic on external cables etc., and store 
it, under a certificated warrant. They can obviously also look at it 
under the warrant, and the warrant is renewed as often as required.

They can also scoop up and store any domestic traffic which has gone on 
a hop abroad on the cable - this is lawful under ss.5(6)(a), "conduct 
(including the interception of communications not identified by the 
warrant) as it is necessary.."

Now here is the controversial bit (which some may disagree with - I 
append ss.2(8) for the perusal of those folks):

Once the traffic is scooped up and stored, they can then look at it 
*without that looking being an interception*, as it is no longer in 
transmission. (ss.2(2))

ss.2(7) only covers cases where the traffic is stored by the telecom or 
in the system which is/was used to transmit it. It doesn't cover GCHQ's 
stash.

ss.2(8) does not cover the looking-at, as the "diversion or recording", 
which is the interception, has already happened (and was lawful).

The traffic is now outside the system, has passed Lord Bassam's doormat, 
and is no longer in transmission - so looking at it is no longer an 
interception, as it is not being made available whist in transmission.




GCHQ can't lawfully scoop up all the traffic from domestic cables, and 
probably don't. If they did, subsequently looking at it would not be an 
interception either.


There may be DPA considerations which have to be applied when GCHQ looks 
at stored data - but not RIPA ones.


-- Peter Fairbrother


"2(8) For the purposes of this section the cases in which any contents 
of a communication are to be taken to be made available to a person 
while being transmitted shall include any case in which any of the 
contents of the communication, while being transmitted, are diverted or 
recorded so as to be available to a person subsequently."






From zenadsl6186 at zen.co.uk  Tue Jun 17 14:59:27 2014
From: zenadsl6186 at zen.co.uk (Peter Fairbrother)
Date: Tue, 17 Jun 2014 14:59:27 +0100
Subject: RIPA s 12(7)
In-Reply-To: <539E96EF.9010103@casparbowden.net>
References: <53994C11.4030705@pmsommer.com>
	<53998CE9.1000507@casparbowden.net>	<539E1D96.9060706@zen.co.uk>
	<539E96EF.9010103@casparbowden.net>
Message-ID: <53A049BF.90104@zen.co.uk>

On 16/06/14 08:04, Caspar Bowden (lists) wrote:
> On 06/16/14 00:26, Peter Fairbrother wrote:
>> On 12/06/14 12:20, Caspar Bowden (lists) wrote:
>>> ....but a s.49 RIP order can require CSP to produce plaintext (or
>>> key) to
>>> any past (or future) data. If the key isn't available (e.g there is
>>> client-side code) a recipient of a s.49 can be required to give all
>>> co-operation necessary to have a defence.
>>
>> I'm beginning to wonder whether that last is actually true.
>> ..
>>
>> Most specifically, you can't be forced to ask someone else for keys to
>> which you only have conditional access to.
>
> don't understand what you mean by "conditional"

Nor do I really, but if you have unconditional access to a key then you 
have it in your possession, and thus you have to give it up under a s.49 
warrant - so presumably if you only have conditional access, you don't 
have it in your possession (and you don't have to give it up).


That's from RIPA ss.58(2):

"References in this Part to a person?s having information (including a 
key to protected information) in his possession include references?

(a) to its being in the possession of a person who is under his control 
so far as that information is concerned;

(b) to his having an immediate right of access to it, or an immediate 
right to have it transmitted or otherwise supplied to him; [...]"


>
>>
>>>
>>> Wonder opinions if this sufficient for UK to (coercively) "do a
>>> Hushmail" ? Or under Intel Services Act, or RIPA Pt.2 ?
>>
>> I'm not sure what you mean here.
>
> http://www.wired.com/2007/11/encrypted-e-mai/
>
> Actually I had forgotten that this case involved server-side extraction
> of key (read above). This is obviously within RIP Pt.3 - I remain
> worried about trying to find combo of UK powers which could coerce a
> client-side attack (e.g. he provider has to inject back-doored
> javascript code)

Will get back to you on that one


-- Peter



From zenadsl6186 at zen.co.uk  Tue Jun 17 18:14:02 2014
From: zenadsl6186 at zen.co.uk (Peter Fairbrother)
Date: Tue, 17 Jun 2014 18:14:02 +0100
Subject: Retrospective Warrants: Legal Theory?
In-Reply-To: <7B7AC43C-E751-42EA-9BB0-7B1EA86669D7@batten.eu.org>
References: <9B56CEA2-C50E-43DC-B8AB-AD104CE5C41E@batten.eu.org>	<53A00755.2050905@ernest.net>
	<7B7AC43C-E751-42EA-9BB0-7B1EA86669D7@batten.eu.org>
Message-ID: <53A0775A.3090201@zen.co.uk>

On 17/06/14 11:35, Ian Batten wrote:
>

> My reading is that section 16 is only engaged by "certificated warrants", S.8(4), and that appears
> to exclude material relating to people located in the UK  S.16(2)(a).  But I confess to struggling
> with the language ("falls within this subsection so far only as it is selected to be read, looked at or listened
> to otherwise than according to a factor which" --- does the otherwise mean "other than as in the follow
> sections" or is it attached to the "listened to"?)


I'd agree that section 16 is only engaged by "certificated warrants", 
and that ss.16(2) sometimes excludes looking at material obtained under 
such a warrant which is chosen in relation to a person located in the 
UK, ss.8(5).

That material which cannot be looked at might be material selected as 
containing someone in the UK's name, or comms to/from someone in the UK 
- but they can still select which material to look at by looking for 
"bomb" or "Snowden" (but not Assange) or even "Daily Telegraph" in all 
material, and then look further at any hits they get from that search.



However ss.16(3) does introduce a new kind of _certificate_ - under 
which GCHQ can ignore ss.16(2), and look at material which *does* relate 
to people located in the UK.

A single s.16(3) certificate can only permit looking at material which 
was obtained during a limited period of time under a ss.8(4) warrant -- 
but, of course, the SoS can issue as many certificates as he likes, for 
different periods.


Perhaps more importantly, there is nothing I can see which prevents a 
single s.16(3) certificate including material (obtained under a s.8 
warrant) relating to groups of people, people of some description, or 
even just any and all people, rather than only individuals or addresses 
as under a normal domestic warrant.



-- Peter F




From zenadsl6186 at zen.co.uk  Sat Jun 21 01:26:40 2014
From: zenadsl6186 at zen.co.uk (Peter Fairbrother)
Date: Sat, 21 Jun 2014 01:26:40 +0100
Subject: RIPA s 12(7)
In-Reply-To: <539E96EF.9010103@casparbowden.net>
References: <53994C11.4030705@pmsommer.com>
	<53998CE9.1000507@casparbowden.net>	<539E1D96.9060706@zen.co.uk>
	<539E96EF.9010103@casparbowden.net>
Message-ID: <53A4D140.6030607@zen.co.uk>

On 16/06/14 08:04, Caspar Bowden (lists) wrote:
> On 06/16/14 00:26, Peter Fairbrother wrote:
>> On 12/06/14 12:20, Caspar Bowden (lists) wrote:
[...]
>>> Wonder opinions if this sufficient for UK to (coercively) "do a
>>> Hushmail" ? Or under Intel Services Act, or RIPA Pt.2 ?
>>
>> I'm not sure what you mean here.
>
> http://www.wired.com/2007/11/encrypted-e-mai/
>
> Actually I had forgotten that this case involved server-side extraction
> of key (read above). This is obviously within RIP Pt.3 - I remain
> worried about trying to find combo of UK powers which could coerce a
> client-side attack (e.g. he provider has to inject back-doored
> javascript code)

It seems Hushmail had/have two different products, one a Java-based 
applet, one JavaScript-based. The Java-based applet may or may not be 
secure against warrants, but the JavaScript-based one most definitely isn't.

Afaict, in the JavaScript-based app user's passwords and emails are sent 
behind a TSL connection, but otherwise in plain language, nothing is 
hidden from the server - in the case of a sent email, the server then 
does the public key encryption for the recipient. In the case of a 
received email, the server does the private key decryption, then just 
re-encrypts for link TLS.

This of course breaks the end-to-end model, and it is no wonder that 
Hushmail could provide plaintext under a warrant - server-side 
extraction of key, or just supplying users passwords (if that is what 
they did, I'm not clear on that) is just one of many ways in which they 
could have made plaintext available.

I don't see any reason why you couldn't operate a real end-to-end 
encryption scheme via a browser and JavaScript - it would be a bit 
clunky, but I can't see why it wouldn't technically be possible.



So, to get to the question - supposing you did have such a JavaScript on 
your server, could UK Plod force you to backdoor it so you/they could 
read traffic?

I think it depends a bit on the situation, eg what you are protecting, 
email-type messaging or voip traffic might be different - and it might 
also matter whether you are supplying a total service, or just the 
JavaScript software.

On the one hand, if you are just supplying software (and not a telecomms 
service) then I don't think they could force you to backdoor the 
software - on the other hand, if you are supplying a complete voip 
service like Skype (in the UK) then I think they probably could require 
you to have the capability to read traffic on 1 in 10,000 conversations 
- after all, you can't buy telephone equipment which doesn't have 
interception capability these days - even if that requirement meant 
installing a backdoor.

Though the lack of non-interception-capable telephone equipment is 
actually because there is no market for it, rather than any prohibition 
of sales.

In between these, I'm not so sure. May post more later.



-- Peter Fairbrother


From igb at batten.eu.org  Sat Jun 21 20:46:59 2014
From: igb at batten.eu.org (Ian Batten)
Date: Sat, 21 Jun 2014 20:46:59 +0100
Subject: RIPA s 12(7)
In-Reply-To: <53A4D140.6030607@zen.co.uk>
References: <53994C11.4030705@pmsommer.com>
	<53998CE9.1000507@casparbowden.net>	<539E1D96.9060706@zen.co.uk>
	<539E96EF.9010103@casparbowden.net> <53A4D140.6030607@zen.co.uk>
Message-ID: <437A4D2B-69FA-4252-99CA-437FCB61139D@batten.eu.org>


On 21 Jun 2014, at 01:26, Peter Fairbrother <zenadsl6186 at zen.co.uk> wrote:

>  after all, you can't buy telephone equipment which doesn't have interception capability these days 

You can't buy telephone _service_ which doesn't have interception capability, surely?
There's nothing stopping me gluing my own service together with Asterix (or whatever),
some over-the-counter ATAs and some IPSec tunnels, after all.

ian



From zenadsl6186 at zen.co.uk  Sun Jun 22 14:23:25 2014
From: zenadsl6186 at zen.co.uk (Peter Fairbrother)
Date: Sun, 22 Jun 2014 14:23:25 +0100
Subject: RIPA s 12(7)
In-Reply-To: <437A4D2B-69FA-4252-99CA-437FCB61139D@batten.eu.org>
References: <53994C11.4030705@pmsommer.com>	<53998CE9.1000507@casparbowden.net>	<539E1D96.9060706@zen.co.uk>	<539E96EF.9010103@casparbowden.net>
	<53A4D140.6030607@zen.co.uk>
	<437A4D2B-69FA-4252-99CA-437FCB61139D@batten.eu.org>
Message-ID: <53A6D8CD.1010702@zen.co.uk>

On 21/06/14 20:46, Ian Batten wrote:
>
> On 21 Jun 2014, at 01:26, Peter Fairbrother <zenadsl6186 at zen.co.uk> wrote:
>
>>   after all, you can't buy telephone equipment which doesn't have interception capability these days
>
> You can't buy telephone _service_ which doesn't have interception capability, surely?
> There's nothing stopping me gluing my own service together with Asterix (or whatever),
> some over-the-counter ATAs and some IPSec tunnels, after all.

Yes of course, there is no law preventing that (unless you operate a 
public telecomms service).

Though I'd just point out that Asterisk has "lawful interception" 
capability built-in ...


I'm sorry if I wasn't clear - what I meant was that nobody makes 
large-scale traditional pstn hardware equipment like class 4/5 switches 
(or cellphone core equipment) without built-in interception capability.

Thus you can't buy them - not because it would be illegal, but because 
no-one actually sells them.

The (international) market is such that there is no demand for them - 
almost every public telephone service provider throughout the world has 
to implement law-enforcement interception capability, and has had to do 
so for decades.




For IP-based stuff, as opposed to traditional switched circuit 
telephony, there is usually a mirror port facility on large-scale 
multiplexers, switches, routers etc which is provided and/or dedicated 
for interception purposes  - though hardware taps are also used.



[ the output from the mirror or tap is then fed to an analyser, and in 
the EU at least the service provider operates the analyser, selecting 
traffic which is to be intercepted from the total stream, then passing 
only that selected traffic on to the LEA.

Who operates the analyser is a big deal, present EU policy says that 
LEAs must get the service providers to do it for them. This doesn't 
apply to non-EU traffic however.

As far as I am aware the present inclusion of UK-EU traffic in the RIPA 
ss.8(4) catch-all category breaches EU policy on this matter, but is a 
matter of competencies so little can be done about it. ]

-- Peter F








From alan.braggins at gmail.com  Mon Jun 23 11:37:29 2014
From: alan.braggins at gmail.com (Alan Braggins)
Date: Mon, 23 Jun 2014 11:37:29 +0100
Subject: RIPA s 12(7)
In-Reply-To: <53A4D140.6030607@zen.co.uk>
References: <53994C11.4030705@pmsommer.com>	<53998CE9.1000507@casparbowden.net>	<539E1D96.9060706@zen.co.uk>	<539E96EF.9010103@casparbowden.net>
	<53A4D140.6030607@zen.co.uk>
Message-ID: <53A80369.8090307@gmail.com>

On 21/06/14 01:26, Peter Fairbrother wrote:
> I don't see any reason why you couldn't operate a real end-to-end
> encryption scheme via a browser and JavaScript - it would be a bit
> clunky, but I can't see why it wouldn't technically be possible.

http://matasano.com/articles/javascript-cryptography/
http://secushare.org/end2end
describe some of the difficulties.

But 
http://googleonlinesecurity.blogspot.co.uk/2014/06/making-end-to-end-encryption-easier-to.html