• It was always our intent to support SSL 3.0.  What we call "SSL" and "TLS" are essentially different versions of the same IETF protocol (with "SSL 3.0" being version 3.0 and "TLS 1.0" being version 3.1).  I've included extra requirements and descriptive text within the transport-layer section of the document to indicate that the TLS/SSL handshake should negotiate, at a minimum, SSL 3.0. 
• You are right about the 128-bit symmetric encryption: it's "good enough for government work" and it's also what is recommended in Section 3.2.2 of the WS-I BSP 1.0.  I've updated the referenceable policy documents to indicate support for both 256 and 128-bit symmetric encryption.
• As you mentioned, we had envisioned the Username-token policy being applied in conjunction with either a transport-level or message-level policy mandating encryption of all communication (or, at a minimum, the <wsse:UsernameToken> elements).  I updated section 7.2 to include this requirement: that it "makes sense" for a policy-dependency in this case. 
• As for recommending that the UsernameDigest policy NOT be applied in conjunction with a TLS/SSL transport policy, we discussed this on telecon.  There are many permutations of policy documents that "don't make sense", and we felt that addressing the suitableness of nonsensical combinations was out of scope of the document.

----- Original Message -----

From: Blair Dillaway

To: Duane Merrill III

Cc: ogsa-wg

Sent: Monday, December 03, 2007 5:18 PM

Subject: Secure Communications

Duane,

 

I reviewed the latest draft of the Secure Communications spec. I have a few substantive comments which have been entered in the tracker for this spec which I assigned to you.  Artifact artf6092.

 

Regards,

Blair Dillaway