[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]