[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, sure I can take this discussion with Philip. Cheers, Tomas Arshad Noor skrev: > 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 > > --------------------------------------------------------------------- > 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]