Draft Minutes of MSP MIME BOF

Housley, Russ (housley@spyrus.com)
Mon, 18 Mar 96 10:08:38 

Since the conclusion of the MSP MIME BOF was that a working group was not 
needed, no mail list was created.  So, I am sending the draft minutes to 
the resolving-security mail list for comments.  It was clear that most of 
the people who cam to the meeting are members of this list.

Please send comments directly to me, not the resolving-security list.

Thanks,
  Russ

- - - - - - - - - - 

MSP MIME BOF (MSP)

Reported by Russ Housley/SPYRUS.

The MSP BOF was chaired by Russ Housley.


Agenda

   o Opening remarks
   o Discussion of Internet-Draft
   o Is a working group needed?


Opening remarks

   Jeff Schiller, the Security Area Director, opened the meeting with a 
   few comments.  Jeff could not stay for the meeting, but his comments 
   sent the tone for the discussion.  Jeff said that many different 
   groups are using different approaches to secure e-mail today, and 
   that he did not think that the IETF should try to pick one.   Rather, 
   the IETF should ensure that each of the approaches is accommodated.  
   In the long run, the market place will determine which approaches 
   survive.


Discussion of Internet-Draft

   Prior to the meeting, <draft-housley-msp-mime-00.txt> was posted.  
   Weston Nicolls lead a discussion of the Inetrnet-Draft.

   The preamble described in the Internet-Draft may help in situations 
   where gateways that discard envelope information are used (like 
   Microsoft Mail 3.2), but the preamble is harmful in environments 
   where messages are automatically processed.  For example, Majordomo 
   will generate an error message for each line in the preamble.  One 
   person asserted that the information in the envelope that is 
   discarded can be reconstructed from the remaining MIME structure.  No 
   algorithm for doing so was offered.

   IMAP4 has an issue with encryption.  The problem is not specific to 
   the MSP MIME approach.  In the IMAP4 architecture, the server handles 
   decoding.  Thus, the encryption of an encoded object causes an 
   problem.  Two were discussed: placing the security mechanisms at the 
   server and sending the object back to the server to processing after 
   the client decrypts it.  No one really liked either alternative.

   There was consensus that multipart/signed was better that 
   multipart/mixed for handling huge blobs.  However, several people 
   thought that multipart/signed should support "armored" and 
   "unarmored" transfers.  PEM (see RFC 1421) supported these 
   alternatives with MIC and MIC-CLEAR.  There was a strong desire for 
   low-end mail user agents (MUAs) to be able to process signed 
   messages, even if they cannot validate the signature.  The 
   "unarmored" techniques support this desire.


Is a working group needed?

   No.  The issues raised in the discussion are not specific to MSP.  In 
   fact, all e-mail security protocols have issues in one area or 
   another.  The group agreed that a working group should be formed to 
   tackle these issues, but that working group should not focus on any 
   single security protocol.

   MSP MIME will be documented in an Informational RFC.  A working group 
   is not necessary to accomplish the assignment of the associated MIME 
   types.