// COMPLETE THREAD

RE:

2 expanded posts ยท every known parent and child

NODE c5c4c749RE:
> James M. Galvin said:
> It's my impression that MOSS suffered from lack of representation at this
> workshop.  I got that view from at least 6 different people, so I believe
> it to be true.  That said, I think it's unfair to declare its demise.

I agree with this impression -- I think that MOSS was not represented in any 
meaningful way.  The question that begs to be asked is:  why?

I also agree with the assessment that MOSS was a casualty due to a certain 
extent to the lack of representation.

To recap the purpose of this conference, it was for the interested parties 
involved with security specifications to review their differences, determine 
the requirements, and possibly even to come out with a preferred solution.  If 
the interested parties don't show up, it seems that they are not going to have 
their arguments heard.  In fact, I believe that MOSS is the *only* 
specification that didn't have a significant group of proponents present 
during the entire proceedings.

I knew darn well that we as a group would be gunning down one or more of these 
specifications to simplify the process, and if I wanted anything to say about 
it, then I'd better go.

Before the conference, while this list was forming, I asked Dave Crocker what 
the agenda was, and who specifically was speaking about each specification -- 
the reason I did this is to find out if the *absolute best* representative for 
each specification was speaking, so that we would not end up in a situation 
where the audience was uninformed about a specification, and I could feel that 
the meeting would be productive.  Ultimately, for PGP and S/MIME, it was the 
authors or editors themselves that provided insight into their respective 
specification, and for MSP it was at least one key implementor.

For MOSS, it seemed that the whole contingency (people who were either in 
charge of the specification, who had plans to implement the specification, or 
who were significant customers interested in the specification) was you (an 
author of the specification), and you had to split.  This is not a good sign.  
If the people who cared about MOSS participated in the public forums provided 
for discussing it (mailing lists such as pem-dev), then they would have been 
made aware of this meeting just like the other specification proponents, and 
would have shown up.  You showed up, showed a chart that didn't demonstrate 
MOSS as a clear winner, and didn't stick around to discuss the chart (which I 
thought was a good start to finding The Answer).

This also reminds me of a time when a call went out for the MOSS implementors 
to raise their hands (on the pem-dev list) -- and only Ned Freed answered.  
This could very well be because MOSS implementors don't hang out on the 
mailing list, which is somewhat strange since the timeframe in which this 
question was posed was very close to the release date of the specification 
(10/95).  In fact, Dave Crocker recently said that "Clear, corporate 
commitments from product vendors ought to confirm or dispel the rumor of the 
MOSS demise", and we have not had *any* vendors step up since that statement.

Don't get me wrong -- I don't consider myself to be prejudiced away from MOSS. 
 Near the end of the meeting, I specifically pointed out that:  First we had 
PEM, and it died.  Now we have MOSS, which is 47 pages long, and less than 
*four months* old, and we are calling it dead also.

The answer to that was that it made a great "over beer" question -- a question 
to be discussed over a beer.

Care for a beer?

Blake
NODE d8a07a0fRe: RE: [ Death of MOSS? ]
On Feb 28, 12:16am, Blake Ramsdell wrote:

> > James M. Galvin said:
> > It's my impression that MOSS suffered from lack of representation at this
> > workshop.  I got that view from at least 6 different people, so I believe
> > it to be true.  That said, I think it's unfair to declare its demise.
> 
> I agree with this impression -- I think that MOSS was not represented in any 
> meaningful way.  The question that begs to be asked is:  why?

    May I restate a point I've been saying for a while?

    From what I recall of Terry Gray's presentation, MOSS seemed to be
a highly thought of integration of MIME and security, although perhaps
none of us thought much of the particular TIS freely available
implementation.

    I know that, from my personal perspective, MOSS appears to be the
best example of integrating security into MIME, at least from a
framework perspective.  The only reason PGP/MIME also rates a "+" in
my book is because it is based on the current PGP standard (the de
facto standard for our primary user base) as well as being reasonably
well integrated into MIME.


    I would vehemently oppose any statement that MOSS *as a framework*
is dead.  I don't think the particular TIS freely available
implementation has much of a future, but I'm a very strong supporter
for taking the existing MOSS standard and removing any remaining
algorithm specifics and then using it as a framework for implementing
a secure email standard with the PGP, S/MIME, or MSP trust models,
certificates, encryption algorithms, etc....

    Obviously a few additional enhancements would be necessary, such
as cryptographic signatures on return receipts and classification
labels (as two examples, there may be more), but MOSS is my current
best yardstick for measuring just how well a secure email standard
really is integrated into MIME, with the absolute minimal amount of
disturbance to the existing MIME standard (and thus, making it the
most "native" MIME implementation of a secure email standard).


    And if you look at what I've said previously, it is my firm belief
that if we are to succeed in giving users a truly interoperable secure
email standard, then said standard must be fully and completely
integrated into MIME and do everything it does in the proper MIME way,
as opposed to just being security grafted on.

    This is why I advocate finding out what the current (proposed)
MIME way is of handling return receipts and then finding how we can
add the dimension of security to those receipts, instead of just
defining our own secure receipts that are distinct from regular
receipts.


    MOSS the implementation may well be dead, but MOSS the framework I
feel is very much alive, and will likely continue to live well beyond
the other standards that were championed by presenters who remained at
the workshop into the afternoon, if only because I think MOSS as a
framework will likely define the framework that the other standards
(and any future standards) will have to find a way to fit into.

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