Re: Problems with MSP

Raph Levien (raph@c2.org)
Thu, 15 Feb 1996 09:45:47 -0800 (PST) 

On Wed, 14 Feb 1996, Dave Crocker wrote:

> 	I'd be interested in your elaborating on your ASN.1 concerns.
> S/MIME also uses ASN.1.  SNMP uses a restricted subset.  Opinions on ASN.1
> vary but it is certainly true that it's used in running systems.

   My own concerns are for complexity, not with pro- or anti-ASN.1
ideology. Even MOSS in the non-X.509 mode uses ASN.1 coding for the public
key, but that has no implications for overall complexity - it's still
quite easy to get the bits you need. 
   Without any X.400 experience, this is just speculation, but my guess is
that translating all email back and forth between RFC 822 + MIME and X.400
would be a nightmare, both in complexity and in user problems. I'm sure
this mailing list has someone who has implemented an X.400/Internet
gateway and can tell us about it (for example, how many lines of code are
in the product?). 

> >additional encoding (presumably MIME base64). Thus, MSP signed messages
> >would be unreadable to recipients not in possession of an MSP agent.
> >   In my personal opinion, this is the single most important feature of
> >any signed message format. PGP, PGP/MIME, MOSS, and S/MIME all go to
> 
> 	I thought that S/MIME signed messages were NOT directly readable.
> The spec advises that any desire to have a clear-text version of the data
> requires a second copy of that data, carried in a multipart/alternative.

   Good point. For some reason, I did not think of the possibility of 
using a multipart/alternative in conjunction with MSP.
   One thing, though. The S/MIME spec explicitly states that a 
multipart/alternative can be used for signed data. There is nothing in 
the MSP spec that suggests that a multipart/alternative can, or should, 
be used. It seems to me that details like this are left open by the MSP 
spec. One other thing that bothers me about the MSP spec is that it 
_does_ specify an RFC 822 transport, but only for forwarded messages, and 
using a non-MIME encoding.
   If MSP is to be used, then I believe we would require an "MSP/MIME" spec 
that nailed down the issues in integrating the X.400 world in general, 
and MSP in particular, to MIME.
   Incidentally, this brings up a point against S/MIME. Apparently, it 
would be a user-configurable choice whether to use the 
multipart/alternative construction or not. For example, if you knew that 
the recipient had S/MIME capability, then by eliminating it, you'd 
improve your bandwidth utilization by a factor of two. Yet, any such 
user-configurable option is subject to Murphy's Law. MOSS, PGP, and 
draft PGP/MIME all have the property that the signed data is _always_ 
recoverable from the message.

> >   I agree that MSP's signed receipt type is valuable, but see no reason
> >why it can't be implemented as, say, a MIME receipt type which is then
> >signed with the standard MIME-based signature protocol. In other words, I
> >see nothing inherent in MSP that enables this feature.
> 
> 	Anyone else care to comment on this?

   I'd really like the answer too!

   By the way, I did a Web search, and came across a summary of a
discussion about three years ago on pem-dev on the suitability of MSP (or
pre-MSP) for Internet mail. Check
http://www.eff.org/pub/Privacy/Crypto_misc/dod_pmsp_sdns.standards if
you're interested. 

Raph