[ogsa-wg] Draft, Informational, Security Profile

[Duane Merrill III]

----- Original Message ----- 
From: "Frank Siebenlist" <franks at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-wg/attachments/20070309/a370b92e/attachment.html