On Mon, Apr 06, 2009 at 01:50:32PM -0400, Russ Housley wrote: > >On Mon, Apr 06, 2009 at 07:03:32AM -0400, Santosh Chokhani wrote: > >> I view SPIF as performing the following functions: converting machine to > >> human representation and vice versa; establishing equivalency between > >> two labeling policies, and defining which labels with the lattice are > >> valid and which are invalid. > > > >If I understand Russ' comment correctly the difficulty with SPIF lies in > >the label equivalency concept. I think there's a better solution for > >dealing with the idea that parts of a policy are classified differently > >than others. > > No. They are two separate concerns. > > Mapping labels between two different policies. Hopefully this can be > avoided altogether in the NFS context.
There should be no impact from this on NFS. If a server is able to map some labels between multiple distinct DOIs, so much the better for it, but that would be an implementation detail. Making it possible to express label equivalencies is not an implementation detail. But it's also not a detail we should care about in the context of NFSv4, whereas security policy agreement _is_ something that we should care about in the context of NFSv4. > Some label values are not releasable to clients that do not have > access to data associated with that label. This one is a real-world > problem, and it leads to different clients having different subsets > of the SPIF if this community that is being supported has this > requirement in their policy. Right, that's what I meant, but I had misunderstood "label equivalency" as being related (d'oh). This is a problem that we must deal with to the extent that it impacts how a client and server determine that they agree on a common security policy. Nico --
