[Top] [All Lists]

RE: The subject line leakage problem

2001-12-17 14:36:49

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.


Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
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


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

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