[Top] [All Lists]

Re: Comments on SecLabel draft

2000-04-17 20:40:30

Thanks for your comments and questions. My responses are below >>

Jim Schaad wrote:


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 
of any
   SignedData object.

2.  Please give more text explaining the difference between rank and role 
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 
that role may have access.  Another way of explaining the difference can be 
Rank based AC is based on who you are while Role based AC is based on what you

3.  The Amoco policy description is not clear.  From the text I assumed that
the confidentiality and integrity were orthogonal axis for make decisions 
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 
to remove the integrity policy values from the security classification section
( 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


5.  Section -- I don't think that one should provide a syntax for the
privacy marks.  However giving a couple of the privacy marks or guidelines 
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 
 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 
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 
categories that are bound to the classification policy. A category "HR 
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 
and what to display to the user.

As far as a syntax, would a new OID need to be defined for each category?  
the syntax just need to provide the application with the text to display to the

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.


<Prev in Thread] Current Thread [Next in Thread>
  • Re: Comments on SecLabel draft, Nicolls <=