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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ekmi message

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


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


The meeting is scheduled for tomorrow at 12noon EST/9am PST. 

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. :)
>>
>>     

-- 
Anil Saldhana
JBoss Security & Identity Management
http://labs.jboss.com/portal/jbosssecurity/



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