Re: [ekmi] Some updates

[Davi Ottenheimer <davi@poetry.org>]

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