Re: Problems with MSP
Paul E. Hoffman (phoffman@imc.org)
Fri, 16 Feb 1996 20:16:36 -0800
I'm forwarding this to the list because it got bounced for being too large.
The file that was sent is available on the IMC server as
<http://www.imc.org/workshop/SDN70413.DOC>. You can see RFC 1704 as
<http://www.imc.org/workshop/rfc1704>.
--Paul Hoffman
--Internet Mail Consortium
============================
From: "Nicolls, J. Weston" <jwnicol@missi.ncsc.mil>
To: IMC Resolving Security <resolving-security@imc.org>
Cc: Hapeman Dale <hapemand@bah.com>
Subject: Re: Problems with MSP
Date: Fri, 16 Feb 96 16:42:00 PST
Message-ID: <312524E7@smtpgw.missi.ncsc.mil>
Encoding: 127 TEXT, 6310 UUENCODE, 1292 UUENCODE
X-Mailer: Microsoft Mail V3.0
X-MS-Attachment: SDN70413.DOC 283648 01-22-1996 13:34
X-MS-Attachment: RFC704.DOC 57856 02-16-1996 16:09
Attached (in word) is a copy of the SDN.701, MIME with MSP rev 1.3. This is
the spec that defines how vendors are required/have implented MSP in their
products to be transported via the Internet (the first version of this spec
was 4/94 and it replaced any reference to SMTP in SDN.701(MSP)). At this
point we have 4 vendors who have implemented it, three of the vendors
products will be at E-Mail World next week in San Jose for those in the area
(see the NSA both, I'll be there when I'm not at the IMC workshop).
At the next IETF meeting, there is a BOF scheduled for a to be draft MIME
with MSP RFC on 6 March at 730pm. [attached is a word 6.0 draft of the rfc]
In the spec you will notice the the info protected in the ASN.1 is in MIME
format so there is no need for X.00 to MIME conversion. MSP does not
specify the the encapsulatedContent be in an specific format.
Weston Nicolls
SMTP Product Manager
NSA - Workstation Security Products Division
[[ SDN70413.DOC : 4096 in SDN70413.DOC ]][[ RFC704.DOC : 4097 in RFC704.DOC
]]
----------
>>From: Hapeman Dale
>>To: Nicolls Weston
>>Subject: FW: Problems with MSP
>>Date: Thursday, February 15, 1996 3:49PM
>>
>>Return-Path: <hapemand@bah.com>
>>From: Hapeman Dale <hapemand@bah.com>
>>To: Nicolls Weston <jwnicol@missi.ncsc.mil>
>>Subject: FW: Problems with MSP
>>Date: Thu, 15 Feb 96 15:49:00 PST
>>Message-ID: <3123C672@smtpj.bah.com>
>>Encoding: 82 TEXT
>>X-Mailer: Microsoft Mail V3.0
>>--------------------------------------------------------------------------
----
>>
>>Wes,
>>
>>Have you seen this (specifically the ****** below) and would it be
possible
>>to provide them with SDN.704? This guy has some good points - that's why
>>you wrote 704!!!
>>
>>Dale
>> ----------
>>From: owner-resolving-security
>>To: Dave Crocker
>>Cc: resolving-security
>>Subject: Re: Problems with MSP
>>Date: Thursday, February 15, 1996 9:45AM
>>
>>
>>
>>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
>>