----- Original Message ----- From: "Frank Siebenlist" <franks@mcs.anl.gov>
* Blair mentioned it already, but just to clarify that the embedding of key-info in the EPR allows one to use normal user-certs for ssl/tls servers and to enforce an equivalent authorization on the to-be-expected server's subject(-alt)-name. Section 2.1.i seems to hint at the same in the BSP-core discussion.
----- Original Message ----- From: "Blair Dillaway" <blaird@microsoft.com> 1. I have discussed the motivating use cases for OGSA-BSP Core with Frank Siebenlist. This was developed to support validation of the desired TLS/SSL server where the server cert doesn't contain info corresponding to the service location. I happen to think standardizing on such a mechanism may be more important when using message-level security, but that may require some additional work as you mention.
Very interesting. I had no idea that the OGSA BSP-Core was specifically motivated for SSL/TLS transport level security. I had just assumed that the profile was primarily addressing an intuitive approach for communicating key/certificate information to clients for use in SOAP message-level secure commmunication. (The words "SSL" or "TLS" never appear in the document, and "transport" appears once in line 107 in a manner that would appear to be descriptive of the OGSA BSP-SC profile, rather than the Core profile.) In fact, it seems that the OGSA HPC Basic Profile document made the same initial assumption that I did, as it reads: Note: The OGSA Basic Security Profile 1.0 - Core specification is not used as that addresses the binding of key information to an endpoint reference [in WS-Addressing], which is not relevant when using transport layer security. This further evidences the need for more specificity in the BSP-Core profile for the intent-of-use of the embedded key (cert) information. (For example, a client may want to see two certificates within the endpoint references that it consumes: one to verify the SSL/TLS endpoint, and the other to authenticate the individual, possibly-mobile, remote resource.) We would suggest that the OGSA BSP-SC be updated to explicitly reflect this interaction with the (proposed updates to the) BSP-Core; specifically that there must be agreement between any such server subject-(alt-)names in embedded EPR key/cert information that is specified for transport endpoint verification. By doing this, the application of these two profiles would explicitly address your original tranport security motivations. -Duane