<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.19">
<TITLE>RE: [rt-users] encrypting fields and email</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>No, that would of course not be a good design. I don't think all fields need to be encrypted either. Transporting the public key for every http request would be a bit of overhead but probably not that bad. Searching would of course be quite a nightmare, may just have to make encrypted fields non searchable otherwise like you said, would have to decrypt everything just to search it, time consuming, would have to be done server side.</FONT></P>
<P><FONT SIZE=2>Not sure what a good solution for an incident database would be that would store sensitive confidential data that other employees should not see. What if we are investigating the dba or someone in the support team that supports the machine, or someone very high up like a VP or CEO for that matter. We also have to ensure that emails are encrypted for any communications regarding the investigation.</FONT></P>
<P><FONT SIZE=2>I am drawing on my past experience with Lotus Notes where this type of encryption was possible. Fields could be protected by public/private pair keys and the public keys could be shipped to authorized users. When looking at the database the key would automatically be used to decrypt the contents. Even the developers would not be able to decrypt the data yet they could continue development support. I don't know if this functionality made it into Domino or not. Any RT developer or support person would pretty well have the keys to all the data in the database.</FONT></P>
<P><FONT SIZE=2>The <A HREF="http://www.fourmilab.ch/javascrypt/" TARGET="_blank">http://www.fourmilab.ch/javascrypt/</A> site has some interesting ideas, not sure how this could be implemented. I would prefer to use certificates, maybe imported into the browser.</FONT></P>
<P><FONT SIZE=2>If RT had protection down to the field level similar to RTFM then maybe that would be sufficient. Will that be available anytime soon?</FONT></P>
<P><FONT SIZE=2>Thanks</FONT>
<BR><FONT SIZE=2>Dave</FONT>
</P>
<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Jesse Vincent [<A HREF="mailto:jesse@bestpractical.com">mailto:jesse@bestpractical.com</A>]</FONT>
<BR><FONT SIZE=2>Sent: Thursday, September 30, 2004 12:41 PM</FONT>
<BR><FONT SIZE=2>To: david.falkenburger@rbc.com</FONT>
<BR><FONT SIZE=2>Cc: rt-users@lists.bestpractical.com; vivek@khera.org</FONT>
<BR><FONT SIZE=2>Subject: Re: [rt-users] encrypting fields and email</FONT>
</P>
<BR>
<BR>
<P><FONT SIZE=2>On Sep 30, 2004, at 11:02 AM, david.falkenburger@rbc.com wrote:</FONT>
</P>
<P><FONT SIZE=2>> I was thinking more along the lines of public and private key </FONT>
<BR><FONT SIZE=2>> technology. If I was to use the private key to encrypt all the data in </FONT>
<BR><FONT SIZE=2>> one or more fields, a key that I as developer generate, then having </FONT>
<BR><FONT SIZE=2>> access to the database or the server will not do you any good unless </FONT>
<BR><FONT SIZE=2>> you have the corresponding private key to decrypt. I could distribute </FONT>
<BR><FONT SIZE=2>> the private key to authorized individuals only. So now you would not </FONT>
<BR><FONT SIZE=2>> only have to be authorized to access RT, and the appropriate queue, </FONT>
<BR><FONT SIZE=2>> but would also need the public key available to your browser for </FONT>
<BR><FONT SIZE=2>> decryption.</FONT>
</P>
<P><FONT SIZE=2>So would all searching be done on the client side? If so, does that </FONT>
<BR><FONT SIZE=2>mean that I'd have to shovel several gigs of ticket content to the end </FONT>
<BR><FONT SIZE=2>user for searching?</FONT>
</P>
</BODY>
</HTML>
<P>------------------------------------------------------------<br>
<br>
This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. <br>
<br>
Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen.<br>
<br>
============================================================<br>
</P>