[rt-users] encrypting fields and email

david.falkenburger at rbc.com david.falkenburger at rbc.com
Thu Sep 30 13:06:03 EDT 2004


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.

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.

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.

The http://www.fourmilab.ch/javascrypt/ site has some interesting ideas, not
sure how this could be implemented. I would prefer to use certificates,
maybe imported into the browser.

If RT had protection down to the field level similar to RTFM then maybe that
would be sufficient. Will that be available anytime soon?

Thanks
Dave

-----Original Message-----
From: Jesse Vincent [mailto:jesse at bestpractical.com]
Sent: Thursday, September 30, 2004 12:41 PM
To: david.falkenburger at rbc.com
Cc: rt-users at lists.bestpractical.com; vivek at khera.org
Subject: Re: [rt-users] encrypting fields and email



On Sep 30, 2004, at 11:02 AM, david.falkenburger at rbc.com wrote:

> I was thinking more along the lines of public and private key 
> technology. If I was to use the private key to encrypt all the data in 
> one or more fields, a key that I as developer generate, then having 
> access to the database or the server will not do you any good unless 
> you have the corresponding private key to decrypt. I could distribute 
> the private key to authorized individuals only. So now you would not 
> only have to be authorized to access RT, and the appropriate queue, 
> but would also need the public key available to your browser for 
> decryption.

So would all searching be done on the client side? If so, does that 
mean that I'd have to shovel several gigs of ticket content to the end 
user for searching?


------------------------------------------------------------

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. 

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.

============================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20040930/bee11578/attachment.htm>


More information about the rt-users mailing list