OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ekmi-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ekmi-comment] SKSML public review - comment - proposal to allow for different key payload containers and alignment with IETF PSKC


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]