[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
Agreed, Tomas. Anil, would you be kind enough to keep track of things we want to work on in 2.0? Here are some items I've that are of interest so far: 1) Inclusion of DSKPP key-container (Tomas G and Sandy R); 2) KM standard for mobile environments (Upendra M); 3) Replication between SKS servers (Arshad N); I will respond to Philip Hoyer that we want to engage with him/KEYPROV to understand the mechanics of DSKPP, their security model and how it will fit in with SKSML. Would someone from the TC volunteer to lead this discussion with Philip on the DSKPP item? Sandy/Tomas? I will be involved, but would prefer to take a back-seat on this discussion. Since we have heard no objections to the current DRAFT specification, I will setup a ballot for moving the current DRAFT to Committee Specification status. We can begin new TC work with our first meeting in Jan 2009 (Anil, would you please schedule them in the calendar? Thanks). Thanks all and a very happy new year to everyone. Arshad Tomas Gustavsson wrote: > 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]