[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ekmi-comment] SKSML public review - comment - proposal to allowfor different key payload containers and alignment with IETF PSKC
Wednesday 11/2, Thursday 12/2 or friday 13/2, between 2pm and 5pm CET. Next week monday or wednesday or good. Regards, Tomas Philip Hoyer wrote: > Tomas, > Could you provide us with a couple of dates that work for you so we can > try to proceed with this. > > Thanks, > Philip > > -----Original Message----- > From: Tomas Gustavsson [mailto:tomas@primekey.se] > Sent: Monday, January 26, 2009 1:53 PM > To: Philip Hoyer > Cc: Arshad Noor; Pei, Mingliang; Hannes Tschofenig; > andrea.doherty@rsa.com; ekmi-comment@lists.oasis-open.org; ekmi; > keyprov@ietf.org; Hallam-Baker, Phillip > Subject: Re: [ekmi-comment] SKSML public review - comment - proposal to > allow for different key payload containers and alignment with IETF PSKC > > > Hi, > > The week commencing 2/2 is impossible for my unfortunately as I'm in > Oslo for a conference. Any week after that will be fine. > > Regards, > Tomas > > > Philip Hoyer skrev: >> Arshad and Tomas, Andrea, Ming and Hannes, >> Could we agree on a date for presenting you DSKPP and PSKC. Which > dates >> for week commencing 2/2 will work for all? >> >> Philip >> >> -----Original Message----- >> From: Arshad Noor [mailto:arshad.noor@strongauth.com] >> Sent: Tuesday, January 13, 2009 5:32 PM >> To: Philip Hoyer >> Cc: ekmi-comment@lists.oasis-open.org; ekmi; keyprov@ietf.org; Hannes >> Tschofenig; Hallam-Baker, Phillip; Pei, Mingliang; >> andrea.doherty@rsa.com; Tomas Gustavsson >> Subject: Re: [ekmi-comment] SKSML public review - comment - proposal > to >> allow for different key payload containers and alignment with IETF > PSKC >> Hi Philip, >> >> Tomas Gustaavson of Primekey in Sweden, has agreed to lead the effort >> from the EKMI TC to understand the KEYPROV work, and the ways in >> which KEYPROV and EKMI might overlap and work together. He (and any >> other TC members who volunteer to work with him on this) will make a >> recommendation to the TC on what we should do. >> >> I will participate in the KEYPROV presentation & discussions (schedule >> permitting), but I will let Tomas drive the schedule and respond with >> dates convenient to him. Except for the morning of the 23rd, I am >> open both weeks. >> >> Thanks. >> >> Arshad >> >> Philip Hoyer wrote: >>> Arshad, >>> We would be available to discuss and webex present Tuesday-Friday > week >>> commencing 19/1 and then the Monday 26th or Friday 30th. >>> >>> Would any such dates suite you and if not could you come back with >> some >>> candidate dates in February for us to consider. >>> >>> Thanks, >>> Philip >>> >>> -----Original Message----- >>> From: Arshad Noor [mailto:arshad.noor@strongauth.com] >>> Sent: Saturday, January 03, 2009 12:25 AM >>> To: Philip Hoyer >>> Cc: ekmi-comment@lists.oasis-open.org; ekmi >>> Subject: Re: [ekmi-comment] SKSML public review - comment - proposal >> to >>> allow for different key payload containers and alignment with IETF >> PSKC >>> Philip, >>> >>> Thank you very much for your comments on the DRAFT specification >>> of SKSML, and the potential to include the DSKPP key-container >>> within SKSML. >>> >>> The Technical Committee has agreed to begin discussions with you >>> (and/or other members of KEYPROV) to understand the implications >>> of this change. >>> >>> A small group of TC members would like to start understanding the >>> details of DSKPP, how it fits in with SKSML and its impact on >>> SKSML. Please let us know how you would like to begin - I imagine >>> a web-presentation from you on the current DSKPP architecture and >>> mechanics would be the appropriate first step. >>> >>> The TC has also decided that since there were no objections from >>> anyone in the Public Review to the current SKSML DRAFT specification, >>> it will move forward with a ballot to designate the DRAFT as a >>> Committee Specification. This is not an OASIS standard. That may >>> be many months away - which gives us the time to understand the >>> DSKPP technology, and the opportunity to include the key-container >>> (if the TC votes for it) before SKSML becomes an OASIS standard. >>> >>> Let me know some convenient dates and times when you might be able >>> to provide that web-presentation. We should have a sub-group named >>> by the 20th of January (our monthly TC meeting), so any time after >>> that would be appropriate. >>> >>> Regards and a happy new year. >>> >>> Arshad Noor >>> StrongAuth, Inc. >>> >>> Philip Hoyer wrote: >>>> Ladies and Gentlemen, >>>> >>>> >>>> >>>> Having been made aware of the SKSML work by Arshad Noor I wanted to >>>> comment on the current specification and make a proposal. >>>> >>>> >>>> >>>> I am the author of the PSKC spec >>>> > (http://www.ietf.org/internet-drafts/draft-ietf-keyprov-portable-symmetr >>> ic-key-container-06.txt) >>>> which is part of the IETF 'keyprov' working group >>>> (http://www.ietf.org/html.charters/keyprov-charter.html) that has >> some >>>> overlap with the work done for SKSML >>>> >>>> >>>> >>>> My main comment around SKSML is that it would be nice to be able to >>>> define the type of payload container (where the key resides) that is > >>>> transported. >>>> >>>> >>>> >>>> This has several advantages: >>>> >>>> 1. It decouples the protocol to obtain the keys from the payload >>> to >>>> transfer the keys >>>> 2. it allows for several different containers to be transported >>> with >>>> the same protocol >>>> 3. It allows extensions to the payload to have a separate >> lifecycle >>>> to the protocol >>>> 4. It will allow profiling of payloads for key related meta-data >>> not >>>> yet considered by the spec >>>> >>>> >>>> >>>> One of the main reasons is that there could be alignment of the >>> payload >>>> between SKSML and the work that has been done in IETF keyprov group. >>>> >>>> >>>> >>>> Especially I would suggest you to consider the work that has been >> done >>>> on the PSKC spec which seems to satisfy most of the requirements in >>>> SKSML and already has many implementers. >>>> >>>> >>>> >>>> The proposal could be to add one layer of abstraction in the >>>> SymKeyResponse element which indicates the type of key container >> being >>> used: >>>> >>>> >>>> Example 1 - using SKSML container >>>> >>>> >>>> >>>> <ekmi:SymkeyResponse >>>> xmlns:ekmi='http://docs.oasis-open.org/ekmi/2008/01' >>>> xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'> >>>> >>>> <ekmi:SymkeyContainer type=" >> http://docs.oasis-open.org/ekmi/2008/01";> >>>> <ekmi:SymkeyList> >>>> >>>> <ekmi:Symkey> >>>> >>>> <ekmi:GlobalKeyID>*10514-1-235*</ekmi:GlobalKeyID> >>>> >>>> <ekmi:KeyUsePolicy> >>>> >>>> <ekmi:KeyUsePolicyID>10514-4</ekmi:KeyUsePolicyID> >>>> >>>> ...... >>>> >>>> >>>> >>>> Example 2 - using PSKC container >>>> >>>> >>>> >>>> <ekmi:SymkeyResponse >>>> xmlns:ekmi='http://docs.oasis-open.org/ekmi/2008/01' >>>> xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'> >>>> >>>> <ekmi:SymkeyContainer > type="urn:ietf:params:xml:ns:keyprov:pskc:1.0"> >>>> <KeyContainer Version="1.0" >>>> xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0"> >>>> >>>> <Device> >>>> >>>> <DeviceInfo> >>>> >>>> <Manufacturer>aManufacturer</Manufacturer> >>>> >>>> <SerialNo>*10514-1-235*</SerialNo> >>>> >>>> </DeviceInfo> >>>> >>>> <Key >>> KeyAlgorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"; >>>> KeyId="*10514-1-235*"> >>>> >>>> <Issuer>anIssuer</Issuer> >>>> >>>> ....... >>>> >>>> >>>> >>>> >>>> >>>> Looking forward to your feedback and please do not hesitate to >> contact >>>> me for further clarificatons, >>>> >>>> >>>> >>>> Philip >>>> >>>> >>>> >>>> ________________________________ >>>> >>>> >>>> >>>> Philip Hoyer >>>> >>>> >>>> >>>> Senior Architect - Office of CTO >>>> >>>> >>>> >>>> ActivIdentity (UK) >>>> >>>> 117 Waterloo Road >>>> >>>> London SE1 8UL >>>> >>>> >>>> >>>> Telephone: +44 (0) 20 7960 0220 >>>> >>>> Fax: +44 (0) 20 7902 1985 >>>> >>>> >>>> >>>> Private and confidential: This message and any attachments may >> contain >>>> privileged / confidential information. If you are not an intended >>> recipient, >>>> you must not copy, distribute, discuss or take any action in > reliance >>> on it. >>>> If you have received this communication in error, please notify the >>> sender >>>> and delete this message immediately. >>>> >>>> >>>>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]