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