Jim
Thanks for your comments and questions. My responses are below >>
Jim Schaad wrote:
SecLabel
1. Section 1 P2 - Security labels cannot be bound to an encrypted body, only
to a signed message.
Yes. Will reword to state that they may be included in the signed
attributes
of any
SignedData object.
2. Please give more text explaining the difference between rank and role
based
security. From the current description they look like the same to me.
Yes, more explaination is needed. The main different is that rank based
AC is
hierarchical while role based is not necessarily (which isnt what I wrote).
Roles can be defined without regard to a hierarchy. Better examples of roles
such as DB Administrator or Network Admin and Shipper Purchaser, which do not
imply a hierarchy but can have their own set of information that only holders
of
that role may have access. Another way of explaining the difference can be
that
Rank based AC is based on who you are while Role based AC is based on what you
do.
3. The Amoco policy description is not clear. From the text I assumed that
the confidentiality and integrity were orthogonal axis for make decisions
(thus
leading to 9 items). Based on the conversation with you this is not true as
the policy is choose one of the axis and then the point on the axis. The text
should be clarified as to which is correct.
Yes, the confidentiality and integrity polices are independent so either or
both may be chosen. I'll add wording to 2.1.1. I think it is also
appropriate
to remove the integrity policy values from the security classification section
(2.2.1.2) and clearance section (2.2.2). Integrity does not effect access
control. It belongs in the privacy mark section, if anywhere.
4. Typo - Section 1.2 last para - "while he outer signature" should be "while
the".
Yes.
5. Section 2.2.1.3 -- I don't think that one should provide a syntax for the
privacy marks. However giving a couple of the privacy marks or guidelines
from
the policy on writting them might be useful. Given that a privacy mark is a
UTF8 string in the syntax, no addtional ASN syntax is really possible.
Agree. Will see about on examples or guidelines.
6. You say that categories are used informally, however without knowning how
they would be used or specified I cannot even hope to offer syntax
suggestions.
Given that they are informal why would they not be marked as privacy labels.
If they are categories then I would expect the policy module to do
enforcement
thus being informal would cause some difficulties.
I meant that categories are not formally defined in the information security
policies but are used in the organization. Project or organizations do define
their own category to limit access to data to members of an organization or a
project. Once defined, then they are formal and are to be enforced
So the owner of the classification policy allows departments to define
security
categories that are bound to the classification policy. A category "HR
Department"
could be defined under the Company ABC classification policy OID and
CompanyABC-SecurityCategory (1) could become "HR Department Only". Then
CompanyABC-Project NextGreatestWasher could become bound to category (2) and so
on. The hard part being how the application knows what categories are being
used
and what to display to the user.
As far as a syntax, would a new OID need to be defined for each category?
Does
the syntax just need to provide the application with the text to display to the
user?
7. I suggest that you name Clearance in the ASN sections to be XxxxSection.
a nd the same for the other top level items.
Will fix numbering for section 2.2.2.
Weston