I have some replies to your replies to my original comments.
I am still concerned about the notion of security domain and
what it means. I don't understand what retrictions a security
domain imposes on the availability of files. In some examples below,
files seem not to be able to pass from one security domain to another
and in other examples they can.
I don't see the connection between security domains and real security
on existing systems, namely user/group/public file permissions.
Bob Herriot
More comments below.
> From rdebry at us.ibm.com Fri Mar 21 06:52:08 1997
>> line ?: "security domain" is mentioned but not defined. Please add
> a definition of it.
> RKD> Anyone have a definition they'd like to offer?
> RKD> Loosley speaking I'd say that it was the domain
> RKD> within which a given set of security policies
> RKD> and mechanisms operated. A domain in which a
> RKD> person has access privileges to resources.
So if two people are a member of the same security domain, they
both have access to exactly the same files? This doesn't seem
realistic. In most systems, I can make some file visible to
just me and others visible to others and I can decide who those
others are for each file.
And if a file is in a different domain from client or printer, how
does anyone get access to it? I confused.
>> section 2.1: if security domain is at the level of a DNS domain, then
> it may not be possible to print a document by reference. That is,
> it may be inaccessible for security reasons because client and
> server are on differet hosts.
> RKD> See previous response. By definition,
> RKD> client has access to documents. If not,
> RKD> they are not in the same security domain.
You describe 2.1 as the traditional office, so I assume this is where
there is some security on files. I may want to print a file that only
I can read on a printer. I can push it because I have access to it.
A printer cannot pull it unless I send it appropriate credentials and
that problem is not yet solved as far as I know.
>> section 2.2: Why can printing only be done by reference?
> RKD> Because you can't push a document that's not
> RKD> physically on the client, which is the case here.
>> What is
> the meaning of the security barrier in this example. Is the
> document in a secure area or are the client and host in a secure
> area?
>> RKD> They may be secure or not, depending upon
> RKD> the policies of the security domain they
> RKD> reside in.
>> In either case, I assume that either client or server can
> fetch the document.
>> RKD> If the client fetches it, then from an IPP point
> RKD> of view the the document is now in the client's
> RKD> security domain. Doesn't matter how (or when) it
> RKD> got there. The point is, that at the instant I
> RKD> invoke the print request, the document is not on
> RKD> the client in the case described in this section.
a client can send a file or the printer can fetch it. What is
left unanswered is how a client get authority to fetch the file
or how the printer knows that the client is allowed to print the file.
> section 2.5: This case also raises some difficult issues in the print
> by reference because the printer somehow has to be able to pull
> the data from another security domain -- exactly what section 2.4
> was disallowing. This seems like a contradiction to me.
>> RKD> I'm confused by your comment. Yes, the Printer has to pull
> RKD> the content from another security domain. But, I'm not
> RKD> sure what your point is with respect to section 2.4. In
> RKD> section 2.4 what do you think is disallowed?
The point I was making is that in section 2.4 the client cannot gain
direct access to the data because it is in a different security domain
and yet in section 2.5 the print can gain access to the data even though
it is in a different security domain.