Re: [No subject]

Brad Knowles (brad@azathoth.ops.aol.com)
Mon, 26 Feb 1996 19:39:24 -0500 

On Feb 26, 10:05am, Housley, Russ wrote:

> MSP signed receipts are more than just signed delivery notices.  The
> content from the original message is cryptographically bound to the
> receipt.  Thus, if the receipt validation works correctly, then the
> original message was recieved by the recipient without error.  The
> originator can prove to a third party that the recipient got the
> message and that the message was not alered in transit.
> 
> I think that this service acnnot be downplayed.  It is needed for
> electronic commerce.

    I did not intend in any way to downplay this service.  What I
meant to say is that, in so far as the receipts themselves are
concerned, I think we should be handling them in the "correct" MIME
fashion, whatever that may be.  It would then be up to us to further
attach to that the correct cryptographic features to make this work
for non-repudiation and other security and privacy-related purposes.

    And if the current "correct" MIME fashion of handling receipts
cannot be so adapted, then I vote that we modify that method of
handling receipts so that it can do what it does today as well as be
flexible enough to work the way we need, and then apply the necessary
security features.


    In other words, work within the current MIME framework to the
greatest extent possible, and only add the minimally necessary
security features to make it do what is needed -- as opposed to
inventing a whole new type of receipt that only does this one limited
feature.  And if the current framework doesn't meet our needs, then we
make the minimum necessary modifications to make it meet our needs.

    I want to avoid reinventing as many wheels as possible, and it
strikes me that perhaps the original MSP and MSP-derived standards do
not do this in a MIME-sense, as a result of their origin.

> MSP already supports any security policy that uses labels.  The label
> field begins with an object identifier.  This object identifier tells
> which security policy to apply, and it tells the format and
> interpretation for the rest of the label.

    My other point was that I think labels are a relatively easy thing
to add in a proper MIME fashion, and in a way that can potentially be
useful outside of a secure and perhaps encrypted fashion.



    In other words, let's be the best possible MIME citizens first,
and adapt our security protocols to fit it as closely as posisble and
make minimal changes, as opposed to making the minimum changes
necessary to kinda-semi-sorta make our blessed pre-existing security
standard work in a pseudo-MIME fashion.  This requires more work at
the beginning, but I submit that it will be more lasting and more
satisfying in the end.

-- 
Brad Knowles                           MIME/PGP: BKnowles@aol.net
    Mail Systems Administrator          <http:www.his.com/~brad/>
    for America Online, Inc.                   Ph: (703) 453-4148