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

From: Duane Merrill III

To: Frank Siebenlist ; Blair Dillaway

Cc: ogsa-wg@ggf.org

Sent: Friday, March 09, 2007 12:28 PM

Subject: Re: [ogsa-wg] Draft, Informational, Security Profile

----- 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