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

["Roddy, Sue A." <s.roddy@radium.ncsc.mil>]

Regretfully, I need to leave my office for a meeting that precludes
participation in today's telecon.

I remain very interested in how the various groups interact with each other
as far as standardization of distributing key material.

I'm also in the final stages of converting the CMS for KEYPACK into (X)CMS
for KEYPACK and hope to have that ready within the next two weeks, for
discussion.

best regards,
Sandi

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 11:06 PM
To: ekmi@lists.oasis-open.org
Subject: Re: [ekmi] Reminder about postponement of next week's
meeting(IOG Feedback)


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