I scanned quickly through draft-davin-eesst with a few basic puzzlements in mind. The mechanism makes sense. I have two questions on security/privacy considerations, one on the protocol involved, and one on scope. I am copying perpass, because I suspect that my considerations have bearing on the broader topic of pervasive monitoring of traffic.
If I understand correctly, the EESST specification is intended to facilitate the secure transmission of data private to one party but originated by a second party to a set of third parties with legitimate and authorized interest. The specific case is a secondary school transcript, being sent by a student, originated by an institution, and received by a set of other institutions; the data is, of course, private to the the student, who is presumably applying to the receiving institutions. My question on scope is: "why so narrow a description?" I can think of other cases in which data private to one party and originated by a second party is sent to a set of third parties with legitimate and authorized interest; medical records come quickly to mind. I could imagine the basic mechanism being described in generic terms and the transmission of transcripts described separately as a use case for the mechanism. My protocol question is "why spend so much time on the structure of the email message?" If the student has the files, they could be communicated via http upload, IM, USB key, twitter, or any other application. Even if email is used, the student is likely to simply attach them to an email message using his or her favorite email tool without regard to the specifics of the EESST specification. In any case, the transmission will need context: unless s/he is uploading them to an application web page at the receiving institution (which is its own context), the student will likely include either text or another file as a cover letter. Why not simply say that the files are exchanged without reference to the protocol in question? But now to what I consider the heart of the matter. The specification calls for a pair of files (XML and PDF) to be signed by the originating institution, for purposes of authenticity and integrity checking, and for the MIME object containing it to be optionally encrypted, so that it cannot be inspected in an MTA. I understand that encryption being optional, in that few mail tools make S/MIME or OpenPGP easy enough for a non-expert to use - even in the IETF, few have PGP keys, and since our lists don't have keys, even this email is being sent in the clear. So the call for encryption is largely vacuous, and the very real possibility remains for inspection of data while at rest in an MTA or captured in flight on a traffic analyzer. Due to our failure to provide simple key creation and management tools, this private and important data is accessible to a casual eye in flight. However, in the use case, the transcript is likely to survive as a record for years, and perhaps forever, but only be in transit for a period of seconds to minutes in the usual case. The specification leaves the data at rest unencrypted, available for casual inspection. One could argue that this is not an issue with a transcript; nobody is going to lose their job over having gotten a bad grade decades earlier. In the medical record use case, it can have dramatic effects. I think the primary threat is unauthorized or inappropriate access/use when the data is at rest. Why not have the originating institution encrypt the data using its private key and make that key available to other institutions? In this or another specification, you could give them a naming guideline that would identify the file as pertaining to an individual and an institution, and therefore a specified public key. This is not perfect security, of course; an unauthorized party that obtained the public key of the originating institution could read the file. But it at least forces them to do so, as opposed to leaving the data open to hack or casual access.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
