<div class="gmail_quote"><div>Some thoughts:</div><div><br></div><div>Encrypting and signing as part of the file generation process is totally appropriate and I would call it a best practice. Especially if the file contains sensitive data.</div><div><br></div><div>1) You have to trust that the sftp service, machine, filesystem, backups, and anywhere else that has access to the raw unencrypted files is secure. All the recent front end server exploits are reason enough to encrypt the file prior to transfer.</div><div><br></div><div>2) If you are sending me a data file you probably are generating the file and then transferring the responsibility of transfer to a separate job. If only one job in your network can sign the file I am less worried about the security of your filesystem and backups.</div><div><br></div><div>3) I don't want to trust my own network. I only want to be able to process this data in the specific jobs that have access to the private key. I don't want to trust all the various actors in my organization.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yes, so that's my complaint. Their policy is that files must be encrypted before sending via SFTP.<br>
But there's no rationale and if I pin them down I'd bet the answer is they don't know. Or they'll<br>
agree but stick to their policy because "more is better" or "it can't hurt".<br>
<br>
Dave<br>
______________________________<u></u>_________________<br>
clue mailing list: <a href="mailto:clue@cluedenver.org" target="_blank">clue@cluedenver.org</a><br>
For information, account preferences, or to unsubscribe see:<br>
<a href="http://cluedenver.org/mailman/listinfo/clue" target="_blank">http://cluedenver.org/mailman/<u></u>listinfo/clue</a><br>
</blockquote></div>