Re: [ekmi] Some updates

[Arshad Noor <arshad.noor@strongauth.com>]

I like that view of Permissions.  I never thought of it from that
perspective, and it makes sense.  Any other thoughts from others?

WRT the error-codes, it is to define some with standard OASIS-
specified error messages and leave a block of numbers open for
vendor-specific error messages, such as something like the
following (it doesn't have to look like this, but its one option):

SKSML-ERR-0001 to SKSML-ERR-0099: Authentication errors
SKSML-ERR-0100 to SKSML-ERR-0199: Authorization errors
SKSML-ERR-0200 to SKSML-ERR-0299: Policy errors
SKSML-ERR-0300 to SKSML-ERR-0399: Cache errors
SKSML-ERR-0400 to SKSML-ERR-0499: Miscellaneous errors
SKSML-ERR-1000 to SKSML-ERR-1999: Vendor-block

SKSML-MSG-0001 to SKSML-MSG-0099: Authentication messages (not errors)
....
...
SKSML-MSG-1000 to SKSML-MSG-1999: Vendor-block

If we wanted to get fancy, we could even have vendor implementations
"register" with the TC and get a unique block so it looks like the
following:

SKSML-ERR-1000 and SKSML-MSG-1000 ....: Vendor A block
SKSML-ERR-2000 and SKSML-MSG-2000 ....: Vendor B block
SKSML-ERR-3000 and SKSML-MSG-3000 ....: Vendor C block

and so on, so that there are no collisions of messages if a company
is using server implementations from two (or more) different vendors
(as is likely to happen as with DBMS and LDAP implementations).  I'm
sure SysAdmins and SecurityAdmins will love that in the standard.

Arshad

Davi Ottenheimer wrote:
> permitted means whitelist, whereas restricted means blacklist to me. permitted makes more sense if it is a whitelist of what can be done with the key.
> 
> 15 minutes seems like a slow search and replace function. :)
> 
> not sure about the second question. the option is to do some error codes and leave it open to development or leave all open? i would choose the former over latter.
> 
> davi
> 
> 
> 
> ----- Original Message ----
> From: Arshad Noor <arshad.noor@strongauth.com>
> To: ekmi@lists.oasis-open.org
> Sent: Friday, September 26, 2008 2:23:36 PM
> Subject: [ekmi] Some updates
> 
> Hello everyone,
> 
> Some quick updates on events in the last week:
> 
> 1) The IEEE held the first Key Management Summit in Baltimore
>     this week.  It was a good event, considering it was being
>     held for the first time.  About 75-80 people attended.
> 
>     While most attendees were storage vendors (members of the
>     IEEE 1619.3 Working Group), there were some end-users from
>     the financial industry and government.
> 
>     A concern was voiced that the industry must coalesce around
>     a single standard - and soon.  The trouble is that OASIS is
>     focused more at the application layer and only does XML-based
>     protocols, while the IEEE WG is divided over whether it needs
>     XML at all or XML + a compact, binary protocol.
> 
>     If they only choose to do a binary protocol, then it makes it
>     possible to have one standard that supports SKSML + IEEE-binary,
>     set a flag to indicate which one the payload is carrying.
>     Vendors may be required to implement both, but users will be
>     the winners.
> 
>     If they decide they want to work on an XML version too, and
>     they vote to NOT use SKSML, then it has potential for lots of
>     confusion in the market.  However, I think there was sufficient
>     emphasis in KMS that there should be one standard.
> 
>     I have promised to have a follow-up conversation with the Chair
>     of the 1619.3 WG to see how we might come closer to an solution.
>     I'll keep the TC updated on this after the conversation.
> 
> 2) A ballot is currently out, seeking to decide which design
>     firm to use for creating the EKMI flash demo.  While 100%
>     of voting members have cast their ballot, until the vote
>     closes on 9/27, the vote is not final.  But, we hope to
>     have a decision by next week so that OASIS Administration
>     can start the contract paper-work.
> 
> 3) We have completed our Public Review of SKSML, as required
>     by OASIS rules and as one can see, we did not receive any
>     comments:  http://lists.oasis-open.org/archives/ekmi-comment/.
> 
>     While this might sound discouraging, I do not view it as
>     such.  Based on my experience in presenting EKMI/SKSML to
>     various groups around the world over the last 2 years, I
>     have not heard one person say that we have designed an
>     insecure protocol, or one that does not meet business needs.
>     I believe we have hit this ball out of the park this time.
> 
>     Given this, we can technically move towards voting on a
>     Committee Specification (CS) and also move towards asking
>     for an OASIS Standards vote.
> 
>     However, there are two items I wanted to bring up to the
>     TC on the specification, and I would like to get feedback
>     from the TC before I setup the ballot for the CS:
> 
>     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.
> 
>        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.
> 
> Let me know what you all think.  If I don't hear back by Frdiay
> (Oct 3rd), I'll setup the ballot for the CS vote next week.
> 
> Thanks and have a great weekend everyone.
> 
> Arshad Noor
> StrongAuth, Inc.
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php