ietf-smime
[Top] [All Lists]

Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages

1998-09-18 08:49:27

On Thu, 17 Sep 1998 15:47:36 -0700 (PDT) Ned Freed 
<Ned(_dot_)Freed(_at_)innosoft(_dot_)com>
wrote:

I personally favor a message/rfc822 parameter, but I can also see a case for
putting it elsewhere. What do other people think? If there seems to be
consensus that this needs to be on message/rfc822, I'd be happy to write
a short draft defining such a parameter.

So do I.   There are some reasonably complex interplays between cached and 
displayed structures in the presence of security - especially in an IMAP4 mail 
client.   Clients that cache MIME structures will often do things like cache
overlays for security multiparts so that their UI code doesn't have to know
anything about security -- that is all handled at the MIME abstraction level.
Also there has been discussion many times in the past of having "proxy 
security handling" for IMAP servers where the IMAP server handles decoding
encrypted messages on behalf of the client and sending the decoded content
over an encrypted data connection to the client.   Note that this is not a 
real situation now, but there are lots of reasons for people to want this 
behaviour in the future and it continues to be discussed.

The message/rfc822 solution would work transparently in the cases described 
above.   If the parameter is attached to the security multiparts then it is
possible that it will be occluded or lost by an MUA in the act of removing 
the security.   Putting it at the message/rfc822 level means that it will
always be exposed to UI code and the UI can decide how to "cook" the display
to show the right thing. 

Cheers. 

---  
Steve Hole                           
The Esys Corporation
Mailto:Steve(_dot_)Hole(_at_)esys(_dot_)ca  
Phone:403-424-4922

Attachment: pgpVnPMtTF2zt.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>