Re: Draft IP-Bill enters wrap-up phase
Mark Lomas <ukcrypto-Qv/Mekd6ICy057r0afFFoQC/[email protected]> Sat, 23 Jan 2016 14:25:52 +0000
| Newsgroups | gmane.law.cryptography.uk |
|---|---|
| Message-ID | <CACAki+vUkGOp-LOdL7G1_ZCN2DL6J4ZW-3LS2M17n8jqCgKjzA@mail.gmail.com> |
--001a11401e42f2a17f052a011ca5 Content-Type: text/plain; charset=UTF-8 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: > >> >> --001a11401e42f2a17f052a011ca5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">NHS Net mail has two different encryption mechanisms, one = of which is end-to-end.<div><br></div><div>If the users take no special mea= sures then NHS Net mail encrypts between client and server, but messages ar= e stored in clear on the server. That is not end-to-end.</div><div><br></di= v><div>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 patie= nt records must use this. They felt unable to mandate this for individual r= ecords because many NHS staff are incapable of using S/MIME. So, for exampl= e, hospital admissions should support S/MIME but an individual healthcare w= orker isn't required to.</div><div><br></div><div>To complicate matters= there is an authorisation list for S/MIME that needs to traverse the netwo= rk boundary. That is to stop staff smuggling out sensitive data having firs= t encrypted it. Staff who need to exchange encrypted messages with external= parties have first to be added to the authorisation list.</div><div><br></= div><div>Mark</div><div><br></div><div>p.s. I realise that not all NHS bodi= es follow the policy, but the mechanism is available to support end-to-end = encryption.</div><div><br></div><div><br></div></div><div class=3D"gmail_ex= tra"><br><div class=3D"gmail_quote">On 22 January 2016 at 00:38, Adrian Mid= gley <span dir=3D"ltr"><<a href=3D"mailto:[email protected]" target=3D"= _blank">[email protected]</a>></span> wrote:<br><blockquote class=3D"gm= ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le= ft:1ex"><div dir=3D"ltr"><div><div><span class=3D""><div>> thinking base= d on a mistaken impression that an iMessage has four ends:<br> sender/Apple/Apple/recipient,<br><br></div></span>The NHS Net mail is persi= stently described as "end to end encrypted" 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'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'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= <<a href=3D"mailto:[email protected]" target=3D"_blank">li= [email protected]</a>> 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> --001a11401e42f2a17f052a011ca5--