Re: Draft IP-Bill enters wrap-up phase

--001a1140150a0f13f8052a0308a5
Content-Type: text/plain; charset=UTF-8

I suspect places where it is used may be a shorter list than those where it
is not.  I'm not convinced anyone in our local setup knows it exists.

On Sat, 23 Jan 2016, 17:19 Mark Lomas <ukcrypto-Qv/Mekd6ICy057r0afFFoQC/[email protected]> wrote:

> NHS Net mail has two different encryption mechanisms, one of which is
> end-to-end.
>
> If the users take no special measures then NHS Net mail encrypts between
> client and server, but messages are stored in clear on the server. That is
> not end-to-end.
>
> NHS Net mail also provides a PKI to support S/MIME, allowing end-to-end
> encryption. NHS policy is that any message containing two or more patient
> records must use this. They felt unable to mandate this for individual
> records because many NHS staff are incapable of using S/MIME. So, for
> example, hospital admissions should support S/MIME but an individual
> healthcare worker isn't required to.
>
> To complicate matters there is an authorisation list for S/MIME that needs
> to traverse the network boundary. That is to stop staff smuggling out
> sensitive data having first encrypted it. Staff who need to exchange
> encrypted messages with external parties have first to be added to the
> authorisation list.
>
> Mark
>
> p.s. I realise that not all NHS bodies follow the policy, but the
> mechanism is available to support end-to-end encryption.
>
>
>
> On 22 January 2016 at 00:38, Adrian Midgley <[email protected]> wrote:
>
>> > thinking based on a mistaken impression that an iMessage has four ends:
>> sender/Apple/Apple/recipient,
>>
>> The NHS Net mail is persistently described as "end to end encrypted" when
>> it quite clearly is decrypted to store (perhaps being re-encrypted against
>> a key held for that server) on the central server, and then re-encrypted to
>> go to the recipient's compute.
>>
>> So the idea that there could be a persistent mistake about how many ends
>> there are in a a line isn't quite as daft as it might be.
>>
>> But no, I think it is simply saying whatever seems convenient, alas.
>>
>>
>>
>>
>>
>> On Thu, 14 Jan 2016 at 11:52 Roland Perry <[email protected]>
>> wrote:
>>
>>>
>>>
>

--001a1140150a0f13f8052a0308a5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">I suspect places where it is used may be a shorter list than=
 those where it is not.=C2=A0 I&#39;m not convinced anyone in our local set=
up knows it exists.</p>
<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, 23 Jan 2016, 17:19=
=C2=A0Mark Lomas &lt;<a href=3D"mailto:ukcrypto-Qv/Mekd6ICy057r0afFFoQC/[email protected]">ukcrypto=
@absent-minded.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr">NHS Net mail has two different encryption mechanisms, one o=
f which is end-to-end.<div><br></div><div>If the users take no special meas=
ures then NHS Net mail encrypts between client and server, but messages are=
 stored in clear on the server. That is not end-to-end.</div><div><br></div=
><div>NHS Net mail also provides a PKI to support S/MIME, allowing end-to-e=
nd encryption. NHS policy is that any message containing two or more patien=
t records must use this. They felt unable to mandate this for individual re=
cords because many NHS staff are incapable of using S/MIME. So, for example=
, hospital admissions should support S/MIME but an individual healthcare wo=
rker isn&#39;t required to.</div><div><br></div><div>To complicate matters =
there is an authorisation list for S/MIME that needs to traverse the networ=
k boundary. That is to stop staff smuggling out sensitive data having first=
 encrypted it. Staff who need to exchange encrypted messages with external =
parties have first to be added to the authorisation list.</div></div><div d=
ir=3D"ltr"><div><br></div><div>Mark</div></div><div dir=3D"ltr"><div><br></=
div><div>p.s. I realise that not all NHS bodies follow the policy, but the =
mechanism is available to support end-to-end encryption.</div><div><br></di=
v><div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">On 22 January 2016 at 00:38, Adrian Midgley <span dir=3D"ltr">&lt;<a =
href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
<div><span><div>&gt; thinking based on a mistaken impression that an iMessa=
ge has four ends:<br>
sender/Apple/Apple/recipient,<br><br></div></span>The NHS Net mail is persi=
stently described as &quot;end to end encrypted&quot; when it quite clearly=
 is decrypted to store (perhaps being re-encrypted against a key held for t=
hat server) on the central server, and then re-encrypted to go to the recip=
ient&#39;s compute.<br><br></div>So the idea that there could be a persiste=
nt mistake about how many ends there are in a a line isn&#39;t quite as daf=
t as it might be. <br><br></div>But no, I think it is simply saying whateve=
r seems convenient, alas.<br><br><br><br><div><div><div><br><br><div class=
=3D"gmail_quote"><div dir=3D"ltr">On Thu, 14 Jan 2016 at 11:52 Roland Perry=
 &lt;<a href=3D"mailto:[email protected]" target=3D"_blank">li=
[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><br>
</blockquote></div></div></div></div></div>
</blockquote></div><br></div>
</blockquote></div>

--001a1140150a0f13f8052a0308a5--