Re: Problems with MSP
Housley, Russ (housley@spyrus.com)
Thu, 15 Feb 96 14:19:56
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.
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.
> 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.
> 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.
> 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.
> 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.
Russ