RE: Microsoft Feature Support List (V 0.1, ALPHA, 8/26/96)

Jim Whitehead (ejw@ics.uci.edu)
Thu, 29 Aug 1996 12:09:28 -0400


>Section 3 of my document addresses security issues.

My apologies, I didn't intend to ignore this section of Yaron's document,
all of which I think is very relevant.

>More advanced ones like VSS provide a security resolution down to the
>directory level. If we do not provide support for security in the standard
>so that different clients can speak a generic security language we will end
>up with a versioning protocol that may be implemented but will be hidden
>behind a proprietary security wall. Security is ugly but we can not avoid
>it. We can not punt it.

I agree that security is very important for versioning, and also for
distributed authoring.  There are many situations where you would not want
to send unencrypted files over the wire.

What I would like is a better understanding of whether existing HTTP
security protocols can be used (e.g., SHTTP, MD5, certificates), or whether
we need to call for something new.  If we go to the HTTP working group and
say "we need a security protocol to support distributed authoring," their
first questions will be a) exactly what distributed functionality depends
on security capability, and b) in what way do the existing security
mechanisms not support the functionality decribed in the answer to a).

Also, I think we need to be very careful in our terminology to separate
"access control" from "security."  These two areas, while somewhat related,
are not synonymous.

Access control is definitely needed to support versioning.  The question in
my mind is whether we only need locking, or whether more fine-grain control
over access control is needed.  I know we can do versioning with only
locking -- what more can be done with full-featured access control
functionality?

- Jim Whitehead <ejw@ics.uci.edu>