Re: [ekmi] Some updates

[Allen <netsecurity@sound-by-design.com>]

Arshad Noor wrote:

[snip]

>    a) The protocol has a <Permissions> element that tells
>       conformant symmetric-key client libraries (SKCL) what
>       the library is permitted to do with the key.  Since
>       the permissions are a form of restrictions, does it
>       make sense to change the name of this element from
>       <Permissions> to <Restrictions> and each of the
>       <Permitted.....> element to <Restricted.....>?  This
>       would change, for example, <PermittedDates> to
>       <RestrictedDates>, <PermittedTimes> to <RestrictedTimes>,
>       etc.  Does this make the protocol any clearer?  Remember
>       that NO end-user will ever see this.  No application
>       developer will ever see the protocol; but developers
>       who're implementing SKSML and building a library and/or
>       product to use it, will definitely see it.  This is a
>       very, very small number of developers.  While they will
>       definitely get the meaning regardless of whether we call
>       it <Permitted...> or <Restricted...>, I thought I'd ask
>       the TC for its opinion on this.

As you have stated it, I find it more confusing. For example, 
does <RestrictedTimes> mean restricted *to* these times or does 
it mean restricted *from* these times? In an attempt to bring 
more clarity to this I would have it be as narrow as possible and 
therefore use <RestrictedTo...> as the replacement.

>       The impact of this change is minimal; a find-and-replace
>       will fix the document within 15 minutes.
> 
>    b) Any application making a call to an SKS server may get
>       error messages that must be processed by SKCLs.  Should
>       we specify standard error-codes and messages that MUST
>       be implemented and still leave room for vendor-specific
>       codes/numbers?  Or should we leave all error-codes and
>       messages open to vendors, completely?
> 
>       The impact of this is that we, as a group, must identify
>       and determine all potential error-codes and messages and
>       specify them.  This could take a few weeks or a month, at
>       a minimum.

Best practices is to have a base of error-codes that allow for 
vendor extensions. In this way no vendor can fail to have at 
least the minimal set working if they should get in a hurry to 
get their product out the door. Besides, we have seen thousands 
of inexplicable error codes in applications and no real resource 
to find out what they mean. Let's give end users and application 
developers something they can use as a starting point.


> Thanks and have a great weekend everyone.

You too, Arshad.

Allen Schaaf - CISSP, CEH, CHFI, CEI
Information Security Analyst - Business Process Analyst
Training & Instructional Designer - Sr. Writer & Documentation
Developer - Certified Network Security Analyst & Intrusion
Forensics Investigator - Certified EC-Council Instructor
http://www.linkedin.com/in/allenschaaf

Security is lot like democracy - everyone's for it but
few understand that you have to work at it constantly.