[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ekmi] Discussion on comment received on 15-day review of SKSML
Hi Arshad, I agree that we should move on with v1 of the protocol. We should maintain a list of items that will be studied for v2. Regards, Tomas Arshad Noor <arshad.noor@strongauth.com> wrote: >Hi Tomas (Sandy and Ben), > >Thanks for your thoughts. > >I don't have anything (yet) against considering the merger of the >DSKPP key-container into SKSML - I just think that we should study >it before deciding on it. > >EKMI TC, the KEYPROV WG and the IEEE 1619.3 WG all had unique >charters 2 years ago, so everybody was comfortable that there was >no overlap. > >Since then, it appears that the IEEE and the KEYPROV WGs have carved >some part of the EKMI TC focus into their charter, causing the overlap; >we've still stayed true to our focus and mission for the last 2 years. > >Now that we're at the threshold of voting it to Committee Spec status, >I would hate to have 2-years worth of work delayed for a few more >months just so we can determine if the DSKPP key-container fits in >within SKSML. (I also recall that there was consensus in the last TC >meeting that we would not add any new features to SKSML 1.0 after the >asynch-request/encryption-cert support, as it was leading to scope- >creep). > >Vendors need to start building implementations of SKSML so they can >learn about its own implementation issues. However, they need a stable >spec for that; if we keep changing the protocol every 2-3 months without >putting a stake in the ground, we'll never finish SKSML. > >I think we can study the DSKPP key-container and create some vendor >implementations of the Committee Spec concurrently without sacrificing >anything. The SKSML implementation experience may cause us to fine-tune >our own protocol and by then we will also know how well the DSKPP key- >container fits in with SKSML. Sometime in spring, we can then vote on >how to move forward with the standards vote and the DSKPP. > >Thoughts? > >Arshad > >Tomas Gustavsson wrote: >> >> Hi, >> I didn't study the pskc document in detail now, only went over it >> briefly. It seems quite, perhaps overly, complex. >> >> In general the idea of standardizing key container is good. If it were >> PKI we were talking about I would be suspicious of any new protocol that >> did not allow piggy-backing of existing standard messages such as >> pkcs#10 requests and pkcs#12 keystores. >> >> The pskc seems to be simply such a standardized keystore, similar to >> pkcs#12 but for symmetric keys. If it is as Philip says that there are >> already wide-spread implementation of this keystore type, I think it >> would be beneficial for ekmi to support this. >> >> Regarding your point 5 Arshad, I think this would be the benefit of >> supporting pskc, easing integration with existing implementations that >> already use pskc containers AFTER the delivery of the key by the SKS. >> Being able to "EKMI-ify" existing systems. >> >> This is one of the areas where I think for example XKMS failed. It did >> not acknowledge the vast installed base of implementations using pkcs#10 >> but required implementing something completely new, making it impossible >> to easy "XKMS-ify" existing systems. >> >> Happy new year to all, >> Tomas >> >> Arshad Noor wrote: >>> All, >>> >>> Many people are probably still on vacation and enjoying the holidays >>> with their families/loved ones, but I thought that it would be useful >>> to start the discussion on the comment received from Philip Hoyer on >>> the 15-day review of SKSML that concluded last week: >>> >>> http://lists.oasis-open.org/archives/ekmi-comment/200812/msg00000.html >>> >>> Here are my thoughts (in no particular order of importance): >>> >>> 1) We have not received any objections or concerns with the current >>> definition of the SKSML protocol itself; >>> >>> 2) Harmonizing key-management standards are good for the industry and >>> for customers; those amongst us at the Key Management Summit held >>> in Baltimore in September 2008 heard this very clearly from the >>> customers that attended the summit; >>> >>> 3) The IETF key-management effort has always been focused on symmetric >>> authentication keys, which is a very different objective than what >>> the EKMI TC is focused on. This was discussed even before the TC >>> came into existence: >>> >>> http://lists.oasis-open.org/archives/oasis-charter-discuss/200611/msg00003.html >>> >>> >>> Since it was agreed that there was no overlap between KEYPROV and >>> EKMI TC (other than that both groups used symmetric cryptographic >>> keys to achieve their different objectives), the OASIS TC was >>> allowed to be created. >>> >>> 4) The key-container is an integral part of the SKSML protocol, but >>> not the most critical part of the protocol. The truly critical >>> element is the KeyUsePolicy element, since this is what defines >>> policy and establishes control. Without the KUP, there is no >>> key-management system; >>> >>> 5) The key-container in SKSML is tied to the use of XML Encryption >>> and X509 digital certificates for transporting the key; this not >>> only provides us the transport security, but also ties it to the >>> authentication credential of the client (also an X509 digital >>> certificate). Without having studied the KEYPROV protocol, I am >>> not certain what additional benefits SKSML will gain by allowing >>> for different key-containers to carry the key. At a minimum, it >>> will require studying the impact on the security and assumptions >>> we need to make about the requesting client; >>> >>> 6) We are at the point of only voting on a Committee Specification, >>> not an OASIS standard. The next 3-6 months will be spent in >>> creating implementations to validate our choices and learn from >>> the experience before voting on the standard. >>> >>> I would recommend that, given the effort we have put in over the >>> last two years, we continue with making the current spec a Committee >>> Specification to validate our work through implementations. At the >>> same time, I also recommend that one or more TC members engage in >>> discussions with Philip to understand the details and implications >>> of his suggestion. The engaging-member(s) can then report back to >>> the TC with an analysis on what impact this suggestion has on SKSML >>> and his/her/their recommendation. The analysis can occur concurrently >>> with the implementation validation so we will have a fair amount of >>> information before deciding on what to do before going for an OASIS >>> standards vote. >>> >>> Let me know what others think about this. >>> >>> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]