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(_at_)verisign(_dot_)com
781 245 6996 x227
-----Original Message-----
From: Paul Hoffman / IMC [mailto:phoffman(_at_)imc(_dot_)org]
Sent: Monday, December 17, 2001 4:08 PM
To: Hallam-Baker, Phillip
Cc: ietf-smime(_at_)imc(_dot_)org
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(_at_)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
Phillip Hallam-Baker (E-mail).vcf
Description: Binary data