Re: [ekmi] Reminder about postponement of next week's meeting(IOGFeedback)

[Arshad Noor <arshad.noor@strongauth.com>]

Thanks for the links, Anil.

Some of you who joined EKMI-TC after it was convened, missed
the discussion between myself and Phillip Hallam-Baker of
VeriSign on this topic.  His e-mail and my response are at
this link where we discussed the charter of EKMI-TC *before*
it was convenend:

http://lists.oasis-open.org/archives/oasis-charter-discuss/200611/msg00004.html

The final e-mail from Phillip on this topic is at:

http://lists.oasis-open.org/archives/oasis-charter-discuss/200611/msg00015.html

where he acknowledges that there is no overlap.  Unless
something has changed on the IETF-WG, there is no overlap
or confusion in my mind - but that may only be temporal,
as with all things in life.

Arshad Noor
StrongAuth, Inc.

Anil Saldhana wrote:
> We can discuss this on tomorrow's call, but looking at this post:
> http://www.safehaus.org/pipermail/ietf-keyprov/2007-February/000077.html
> 
> It seems that the Keyprov wg does do something similar.
> 
> The following post confirms further:
> http://www.safehaus.org/pipermail/ietf-keyprov/2007-January/000063.html
> 
> Arshad Noor wrote:
> 
>> I believe our protocol will specify WSS for compliance,
>> Sandi; but, if anyone chooses to implement something
>> outside the WSS-spec, that is entirely upto them; there
>> is/will be no restriction.
>>
>> However, in order to communicate with some client/server
>> that conforms to the spec, the private implementation
>> would have to support the WSS-specified protocols too.
>> So, the flexibility would exist.
>>
>> Yes, we are meeting tomorrow, as Anil mentioned; the call
>> in details are as follows (as a reminder):
>>
>> April 25th, 2007 at 09:00 PDT:
>>
>> Conference Dial-in Number: (319) 632-1100
>> Participant Access Code: 979986#
>>
>> Agenda:
>>
>> 1) Roll-call
>> 2) Minutes from last meeting
>> 3) Feedback from OASIS Symposium
>> 4) Potential overlap with IETF KeyProv-WG?
>>     http://www.safehaus.org/mailman/listinfo/ietf-keyprov
>> 5) Updates from Subcommittees
>> 6) Sponsorship of workshop at ISACA Regional Conference
>>     in SFO in Septmber 2007 for AGSC
>> 7) Other items, if any
>> 8) Adjourn
>>
>> Arshad Noor
>> StrongAuth, Inc.
>>
>> Roddy, Sue A. wrote:
>>
>>> Just as long as there's no restriction on implementation of 
>>> algorithms (be
>>> that inherited from the WSS or an extension to be defined locally) 
>>> I'm ok.
>>>
>>> Are we having the telecon tomorrow (Wed 4/25)?
>>>
>>> Sandi Roddy
>>> I5 Technical Leader for IA Infrastructure Transformation
>>> National Security Agency
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Arshad Noor [mailto:arshad.noor@strongauth.com]
>>> Sent: Tuesday, April 24, 2007 12:33 AM
>>> To: ekmi@lists.oasis-open.org
>>> Subject: Re: [ekmi] Reminder about postponement of next week's
>>> meeting(IOG Feedback)
>>>
>>>
>>> Personally, I'm seeing most people using either 3DES
>>> or AES.  Since both these algorithms are specified in
>>> the XMLEncryption standard (which is leveraged by WSS),
>>> it makes our job simple.  However, I do agree that a
>>> customer must be able to get the unilimited crypto
>>> policy files (for Java) to make it work.  I'm sure
>>> that C/C++ and other language implementations have
>>> similar restrictions.  I think it makes more sense to
>>> focus on the 80-90% that are satisfied with 3DES/AES
>>> and leave the spec referencing WSS.
>>>
>>> Arshad Noor
>>> StrongAuth, Inc.
>>>
>>> Anil Saldhana wrote:
>>>
>>>>> WRT the crypto protocols for the transfer of symmetric keys,
>>>>> since an assumption in the SKSML is that it would leverage
>>>>> other standards such as XML Encryption and XML Signature
>>>>> (which are implemented in OASIS' Web Services Security layer),
>>>>> I felt that the specification of the crypto protocols could
>>>>> be relegated to those standards.
>>>>>
>>>>> We could reference those standards and mention them in our
>>>>> document, but would defer to those standards for conformance;
>>>>> do you agree?  
>>>>
>>>>
>>>> From an implementation perspective in the java world, the key 
>>>> size(>=128k means you will need unlimited crypto policy support from 
>>>> the jvm due to US export requirements) and JDK support for 
>>>> algorithms is going to define choices for the various algorithms. My 
>>>> guess is that lower strength encryption will anyway not find any use 
>>>> cases for SKMS in the real world.  Do you see any usage of 
>>>> encryption algorithms like Blowfish, DES etc in your field 
>>>> experience?  I would suspect 3DES (or AES) may be used. I am not 
>>>> sure what this committee should do - whether to keep the choice of 
>>>> algorithms tied to ws-sec usage or define particular algorithms from 
>>>> practical experiences. :)
>>>>
>