Re: Problems with MSP
Raph Levien (raph@c2.org)
Thu, 15 Feb 1996 15:05:59 -0800 (PST)
On Thu, 15 Feb 1996, Housley, Russ wrote:
>
> Raph:
>
> I want to reply to your comments.
>
> > At the urging of one of the list members, I took a look at the MSP
> > documents available from the IMC Web server.
> >
> > I did not like what I saw. Implementing MSP requires the
> > implementation of a lot of X.400 and ASN.1 garbage. The whole
> > thing would be very, very complex. I can see a single person
> > implementing MOSS, PGP, or S/MIME, but probably not MSP.
>
> You are wrong. I know of three MSP implementations. In each case a
> single programmer did the job.
Ok.
> Yes, MSP is more complex than some of the alternatives. The additional
> complexity is due to additional features. Signed receipts, in my
> opinion, are very valuable. The ability for a message originator to have
> proof that the message got through to the recipient without modification
> is very valuable. Non-repudiation with proof of delivery is worth the
> complexity. When I send a purchase order over the Internet, I would like
> to know that it reached the vendor without modification.
>
> > Complexity aside, I saw problems with features and compatibility as
> > well. From what I understand, all messages (including signed messages)
> > are encoded in a BER-encoded ASN.1 structure. Such a structure is
> > effectively binary and cannot be transported over RFC 822 without
> > additional encoding (presumably MIME base64). Thus, MSP signed
> > messages would be unreadable to recipients not in possession of an MSP
> > agent.
>
> MSP carries the encapsulated content as an ASN.1 OCTET STRING. This is
> the same technique used by PKCS#7. As with PKCS#7, the solution is to
> put a MIME wrapper around the binary message. At the next IETF meeting,
> there will be a BOF session to discuss the MIME wrapper for MSP. I have
> been coordinating the session time slot with CNRI.
Ah. If the OCTET STRING is actually a MIME message, then using MSP
makes more sense. I was under the mistaken impression that the internal
contents had to be an X.400 message.
> > 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
> > great lengths to ensure that the original message is clearly
> > recoverable from the signed message format.
>
> As I said, the same technique used in the S/MIME wrapper for PKCS#7 is
> used. The specification for the wrapper is presently in a Microsoft
> Word document, and I will be converting it to an Internet-Draft prior to
> the LA IETF meeting.
Right. This got discussed earlier today. The fact that there is a
specification for a MIME wrapper for MSP is a good sign.
> > The documents assert that MSP can be used over RFC 822 channels, but
> > this claim is not supported. Presumably, Internet multimedia types
> > would need to be MIME encoded, converted to X.400, encrypted by MSP,
> > then embedded in another MIME object. This process sounds complex,
> > inefficient, and error prone. I contend that the burden of proof falls
> > on MSP's proponents to demonstrate why such complexity is justified.
>
> MSP offers the ability to protect an arbitrary sequence of bytes (an
> ASN.1 OCTET STRING). There is no reason to involve X.400 in the
> protection of Internet multimedia types. First, the Internet multimedia
> types are would need to be MIME encoded. This is common to all
> approaches. Second, the resulting sequence of octets is MSP protected.
> Third, the resulting MSP content is MIME encoded. I think that these are
> the same three steps needed in S/MIME.
Ok.
> > 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.
>
> I'm glad that we agree about the benefits of signed receipts. You do not
> include sufficient detail in your MIME receipt description for me to really
> comment, but it is very important to include cryptographic binding between
> the original message and the receipt. Non-repudiation with proof of
> delivery cannot be provided without such a binding.
It was not intended as a proposal, merely a comment that it could be
done. Isn't there an IETF working group for these kinds of extensions?
> > I believe that the combination of these factors renders MSP unsuitable
> > for the goal of a widely deployed, transparent crypto protocol for
> > Internet email. We should spend time on MSP at the conference only if
> > this is not our goal, or if I can be shown wrong. The issue of
> > unreadability of signed message formats alone would seem to doom the
> > protocol.
>
> Obviously, I completely disagree.
I retract my blanket condemnation of MSP. I have now been convinced
that it is a plausible alternative. I still have concerns about its
complexity, and about the multipart/alternative signature format it shares
with S/MIME. I agree that's what we should be discussing now and at the
meeting.
Raph