Aggk! Yes of course I meant S/MIME. Result of having just spent time explaining why Pretty Good Privacy is not a first choice for solving problems of document authenticity (think PGP code signing). Yes, the only problem we are dealling with here is confidentiality. On the 'replace other headers', the problem there is that we end up back in the rat-hole. People will propose all sorts of random headers ad infinitum. And others will counter that there are integrity problems and then we have the interop issue, etc. I don't think that the problem is big enough to require a whole new S/MIME spec to solve, just a minor tweak to implementations. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@xxxxxxxxxxxx 781 245 6996 x227 > -----Original Message----- > From: Paul Hoffman / IMC [mailto:phoffman@xxxxxxx] > Sent: Monday, December 17, 2001 4:08 PM > To: Hallam-Baker, Phillip > Cc: ietf-smime@xxxxxxx > Subject: Re: The subject line leakage problem > > > At 10:34 AM -0800 12/17/01, Hallam-Baker, Phillip wrote: > > One of the ongoing problems with people using PGP > > Or S/MIME, which is the topic of this mailing list :-) > > > is that people put > >confidential information in the mail subject lines, eg: > > > >Subject: Proposed purchase of Excite@Home > >Subject: Your STD test results > >Subject: Planned head count reduction > > > > etc. > > > >So over the years there have been plenty of fixes involving > CMS encrypted > >attributes etc. which gets into the rat hole of what other > headers to add > >in. > > Just to be clear: you are talking about leaking headers in > *encrypted* messages, not signed messages, I assume. > > >So instead of that how about the following fix: > > > >1) A Best Current Practice Draft that says > >2) Clients SHOULD offer users the option of replacing the > subject line on > >confidential messages and carrying the subject as the first > line in the body > >of the message. > > A few thoughts: > > 1) That only covers the subject; you might want to cover other > headers that have valuable information. > > 2) That prevents the headers from being automatically processed. > > Instead, how about encouraging the use of multipart/mixed which > starts with text/rfc822-headers. Any headers in that first part are > to replace the same headers on display only. > > --Paul Hoffman, Director > --Internet Mail Consortium >
Attachment:
Phillip Hallam-Baker (E-mail).vcf
Description: Binary data