[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ekmi] Some updates
I would suggest the spec include two things: status code and a status message. Error code standardization is a bigger effort (may be suitable for future versions of the spec). Tomas Gustavsson wrote: > > 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. >>>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]