RE: [ekmi] Reminder about postponement of next week's meeting(IOG Feedback)

["Yu, Jiafu" <Jiafu_Yu@stercomm.com>]

I believe the default policy file in jdk1.4 and 1.5 allows key size up
to 128 bits for any algorithms and 3DES to its maximum. If you need to
use anything "greater than" 128 bits key, unlimited crypto policy file
is required. 


-----Original Message-----
From: Anil Saldhana [mailto:Anil.Saldhana@redhat.com] 
Sent: Tuesday, April 24, 2007 11:52 AM
To: ekmi@lists.oasis-open.org
Subject: Re: [ekmi] Reminder about postponement of next week's
meeting(IOG Feedback)

You cannot get anything secure until the key size is at least 128bits 
and also you will need unlimited crypto policy support based on US 
export regulations. This is more of a deployment guide issue. :)

 From an Operations guide perspective, as you said we can focus on 
3DES/AES with the liberty provided to implementers to choose any 
encryption algorithm they want (which is based on various factors like 
processing strength on devices, bandwidth limitations etc).

Arshad Noor wrote:
> 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/