[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ekmi] Some updates
I wholeheartedly agree that we need to give some starting errors for the vendors. Otherwise interoperability will be impossible, or very bad. Future revisions of the standard can standardize more error codes that are found out to be important. Regards, Tomas Allen wrote: > Arshad, > > I think the schema you propose for error codes, my only concern is that > there might not be enough space for future development. Perhaps an extra > 0 and expand the numbers to 3 digits might solve this potential problem. > The risks of running out of numbers is primarily with the vendor block. > > Also the vendor block, as you point out, might have a problem if two > different vendors use the same number for different purposes, creating > potential confusion. We might want to assign blocks within this space by > request from the vendors. With the extra digit I doubt we'd run out of > space all that soon. With only 4 digits we can only have 9 vendor > specific groups. With 5 digits this would allow 99, more than we'll > likely need. > > Best, > > Allen > > Arshad Noor wrote: >> 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 >> >> --------------------------------------------------------------------- >> 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 >> > > --------------------------------------------------------------------- > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]