OGSA Basic Profile Telecon Agenda 4/6
The following is a proposed agenda for OGSA-WG telecon on April 6th Wednesday from noon to 2pm (CDT) 1PM-3PM (EDT). The dial-in number for Wednesday; Free: +1-800-664-6895 Toll: +1-719-955-1126 passcode: 285178 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0406 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (10 min) Note taker assignment Roll call Agenda bashing 2) Approve minutes from 3/30 https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050330-OGSA-... See AI below for update of minutes 3) Review AIs Action 1321: Frank & Sam to come up with text and schema for 1321 Action 1320: DaveS update text (text not captured need update of minutes) Action: 1298 should be closed no action (see minutes) Action 1231-1233: TomM to pull back 1231-33 into the document with empty body resolve message. Action 1317: TomM to make this a SHOULD with follow-on MUSTs (if implemented) Action 1262: TomM to remove from profile doc. 4) Security discussion (60 min) 1322: Use of Proxy Certificates 1323: Communication of assertions 5) Basic Profile discussion (50 min) 1211: What must a service satisfy before it can be called an "OGSA service?" 1314: Relationship to WS-I Basic Security Profile 1.0 6) Wrap up (10 min) AOB See telecon schedule until May F2F: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule ---- Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint-Exupery T o m M a g u i r e STSM, On Demand Architecture Poughkeepsie, NY 12601
Dear All, The following is a material for a discussion for the action item 1321. Regards, Takuya Mori From: Tom Maguire <tmaguire@us.ibm.com> Subject: [ogsa-wg] OGSA Basic Profile Telecon Agenda 4/6 Date: Tue, 5 Apr 2005 14:49:17 -0500
The following is a proposed agenda for OGSA-WG telecon on April 6th Wednesday from noon to 2pm (CDT) 1PM-3PM (EDT).
The dial-in number for Wednesday; Free: +1-800-664-6895 Toll: +1-719-955-1126 passcode: 285178 :: 3) Review AIs Action 1321: Frank & Sam to come up with text and schema for 1321
---- Apr. 5, 2005 Note: Key infomation exchange for message level security Frank Siebenlist, Samuel Meder and Takuya Mori 0. Introduction This document is to define key information exchange for message level security by using the Matadata element in the EndpointReference which is defined in the latest WS-Agreement draft specification. This document is intended to serve as a base input for the basic profile discussion. 1. Use cases The followings are use cases that the profile specified in the document intends to cover. - When a client wants to send any encrypted message to a service, it will have to know the key associated with that service. - When a client wants to make a policy decision whether or not it wants a certain service to serve its request, it has to know the service's key-info. 2. Namespaces This note uses the following namespaces to define the profile. prefix Namespece URI (Specification) ds: http://www.w3.org/2000/09/xmldsig# (XML-Signature Syntax and Processing) wsse: http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-wssecurity-secext-1.0.xsd (Web Services Security v1.0) ogsa-bp: a Namespace URI for the Basic Profile 1.0 document (OGSA Basic Profile 1.0) And this note also uses the following entity references to ease the description of the URIs. &wsse; the Namespace URI for Web Services Security v1.0 &ogsabp; the Namespace URI for OGSA Basic Profile 1.0 3. Example The following shows an example which the profile is intended to define. (001) <wsa:EndpointReference> (002) <wsa:Address>http://www.globus.org/some/path</wsa:Address> (003) <wsa:Metadata> (004) <ogsabp:EndpointKeyInfo> (005) <wsse:SecurityTokenReference ogsabp:KeyUsage="&ogsabp;#signature"> (006) <wsse:Reference URI="#token1"/> (007) </wsse:SecurityTokenReference> (008) <wsse:SecurityTokenReference (009) ogsabp:KeyUsage="&ogsabp;#encryption"> (010) <wsse:Embedded> (011) <wsse:BinarySecurityToken ValueType="&wsse;X509PKIpathv1"> (012) MIIC..... (013) </wsse:BinarySecurityToken> (014) </wsse:Embedded> (015) </wsse:SecurityTokenReference> (016) </ogsabp:EndpointKeyInfo> (017) </wsa:Metadata> (018) </wsa:EndpointReference> (001)-(018) An example wsa:EndointReference (004)-(016) An example of ogsabp:EndpointKeyInfo elment is shown. The actual key information contained in the ogsabp:EndpointKeyInfo element is bound to the endpoint specified by the enclosing wsa:EndpointReference. (005)-(007) An example of actual key information is shown. The key is expressed by using wsse:SecurityTokenReference and the ogsabp:KeyUsage attribute shows that the key shoud be used for signature. The key data is referenced by the same document referece, "#token1". (008)-(015) Another example of key information is shown. The key is also expressed by using wsse:SecurityTokenReference, but the actual key data is embbeded in the element as a wsse:BinarySecurityToken in wsse:Embedded. And the usage of the key is specified as encryption by the ogsabp:KeyUsage attribute. 4. Infoset The following is the definitions of the infosets refered to in this note. - /wsa:EndpointReference/wsa:Metadata WS-Addressing defines optional wsa:Metadata element which is used to hold metadata that is relevant to the interaction with the endpoint. - /wsa:EndpointReference/wsa:Metadata/osgabp:EndpointKeyInfo/ The ogsabpEndpointKeyInfo is defined as a ds:KeyInfoType which is defined in the XML-Signture specification to contain generic key information. In this profile, the element is used to specify a key information which should be used to interact with the endpoint. - /wsa:EndpointReference/wsa:Metadata/ogsabp:EndpointKeyInfo/ wsse:SecurityTokenReference Although the XML-Signature specification defines various types of elements which are intended to be used as a child element of ds:KeyInfoType element and the specification also allows the ds:KeyInfoType element to have arbitary types of elements in its content, this profile mandates the use of wsse:SecurityTokenReference element under the ogsabp:EndpointKeyInfo element. - /wsa:EndpointReference/wsa:Metadata/ogsabp:EndpointKeyInfo/ wsse:SecurityTokenReference/@ogsabp:KeyUsage This profile defines an optional attribute, @ogsabp:KeyUsage, to specify the usage of the key referenced by the wsse:SecurityTokenReference. The value of the @ogsabp:KeyUsage should be one of the followings: Value Usage &ogsabp;#encryption Encryption key needed to interact with the endpoint. &ogsabp;#signature Signature key needed to interact with the endpoint. 5. Schema The following schema fragment defines ogsabp:EndpointReferenceType element and ogsabp:KeyUsage attribute defined in this profile. ---- <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ogsabp="&ogsabp;" targetNamespace="&ogsabp;"> <!-- definition f the EndpointKeyInfo element --> <xs:element name="EndpointKeyInfo" type="ds:KeyInfoType"/> <!-- definition of the KeyUsage Attribute --> <xs:attribute name="KeyUsage" type="xs:anyURI"/> </xs:schema> ---- 6. Interoperability To ensure the interoperability, a wsse:SecurityTokenReference element MUST comform to the requirements defined in the section 4.2 of the WS-I Basic Profile 1.0 document (SecurityTokenReferences). To ensure the interoperability, if the wsse:BinarySecurityToken refers to or embeds an X509 Certificate, the wsse:BinarySecurityToken MUST comform to the requirements defined in the chapter 6 of the WS-I Basic Profile 1.0 document (X509 Certificate Token Profile). 7. Reference XML-Signature XML-Signature Syntax and Processing, http://www.w3.org/TR/xmldsig-core/ Web Service Security http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-soap-message-security-1.0.pdf WS-I Basic Security Profile WS-I Basic Security Profile Working Groupd Draft http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html End of Note ----
Dear All, I am resending our discussion material because I corrected a mistake which I made in the introduction. And also I made some changes to the document and added a version number to the title. The changes are: 1. The correction of mistake in chapter 0. WS-Agreement -> WS-Addressing 2. Addition of XML-ns prefix definition for WS-Addressing in chapter 2. 3. Addition of a reference to the latest WS-Addressing specification in chapter 7. 4. Some editorial changes. Regards, Takuya Mori ---- Takuya Mori From: Takuya Mori <mori@mcs.anl.gov> Subject: Re: [ogsa-wg] OGSA Basic Profile Telecon Agenda 4/6 Date: Tue, 05 Apr 2005 21:04:22 -0500 (CDT)
Dear All,
The following is a material for a discussion for the action item 1321.
Regards, Takuya Mori
---- Apr. 5, 2005 Note: Key infomation exchange for message level security (V0.2) Frank Siebenlist, Samuel Meder and Takuya Mori 0. Introduction This document is to define key information exchange for message level security by using the Matadata element in the EndpointReference which is defined in the latest WS-Addressing draft specification. This document is intended to serve as a base input for the basic profile discussion. 1. Use cases The followings are use cases that the profiles specified in the document intend to cover. - When a client wants to send any encrypted message to a service, it will have to know the key associated with that service. - When a client wants to make a policy decision whether or not it wants a certain service to serve its request, it has to know the service's key-info. 2. Namespaces This note uses the following namespaces to define the profile. prefix Namespece URI (Specification) wsa: http://www.w3.org/2005/03/addressing ds: http://www.w3.org/2000/09/xmldsig# (XML-Signature Syntax and Processing) wsse: http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-wssecurity-secext-1.0.xsd (Web Services Security v1.0) ogsa-bp: a Namespace URI for the Basic Profile 1.0 document (OGSA Basic Profile 1.0) And this note also uses the following entity references to ease the description of the URIs. &wsse; the Namespace URI for Web Services Security v1.0 &ogsabp; the Namespace URI for OGSA Basic Profile 1.0 3. Example The following shows an example which the profile is intended to define. (001) <wsa:EndpointReference> (002) <wsa:Address>http://www.globus.org/some/path</wsa:Address> (003) <wsa:Metadata> (004) <ogsabp:EndpointKeyInfo> (005) <wsse:SecurityTokenReference ogsabp:KeyUsage="&ogsabp;#signature"> (006) <wsse:Reference URI="#token1"/> (007) </wsse:SecurityTokenReference> (008) <wsse:SecurityTokenReference (009) ogsabp:KeyUsage="&ogsabp;#encryption"> (010) <wsse:Embedded> (011) <wsse:BinarySecurityToken ValueType="&wsse;X509PKIpathv1"> (012) MIIC..... (013) </wsse:BinarySecurityToken> (014) </wsse:Embedded> (015) </wsse:SecurityTokenReference> (016) </ogsabp:EndpointKeyInfo> (017) </wsa:Metadata> (018) </wsa:EndpointReference> (001)-(018) An example wsa:EndointReference (004)-(016) An example of ogsabp:EndpointKeyInfo elment is shown. The actual key information contained in the ogsabp:EndpointKeyInfo element is bound to the endpoint specified by the enclosing wsa:EndpointReference. (005)-(007) An example of actual key information is shown. The key is expressed by using wsse:SecurityTokenReference and the ogsabp:KeyUsage attribute shows that the key shoud be used for signature. The key data is referenced by the same document referece, "#token1". (008)-(015) Another example of key information is shown. The key is also expressed by using wsse:SecurityTokenReference, but the actual key data is embbeded in the element as a wsse:BinarySecurityToken in wsse:Embedded. And the usage of the key is specified as encryption by the ogsabp:KeyUsage attribute. 4. Infoset The following is the definitions of the infosets refered to in this note. - /wsa:EndpointReference/wsa:Metadata WS-Addressing defines optional wsa:Metadata element which is used to hold metadata that is relevant to the interaction with the endpoint. - /wsa:EndpointReference/wsa:Metadata/osgabp:EndpointKeyInfo/ The ogsabp:EndpointKeyInfo is defined as a ds:KeyInfoType which is defined in the XML-Signture specification to contain generic key information. In this profile, the element is used to specify a key information which should be used to interact with the endpoint. - /wsa:EndpointReference/wsa:Metadata/ogsabp:EndpointKeyInfo/ wsse:SecurityTokenReference Although the XML-Signature specification defines various types of elements which are intended to be used as a child element of ds:KeyInfoType element and the specification also allows the ds:KeyInfoType element to have arbitary types of elements in its content, this profile mandates the use of wsse:SecurityTokenReference element under the ogsabp:EndpointKeyInfo element. - /wsa:EndpointReference/wsa:Metadata/ogsabp:EndpointKeyInfo/ wsse:SecurityTokenReference/@ogsabp:KeyUsage This profile defines an optional attribute, @ogsabp:KeyUsage, to specify the usage of the key referenced by the wsse:SecurityTokenReference. The value of the @ogsabp:KeyUsage should be one of the followings: Value Usage &ogsabp;#encryption Encryption key needed to interact with the endpoint. &ogsabp;#signature Signature key needed to interact with the endpoint. 5. Schema The following schema fragment defines ogsabp:EndpointReferenceType element and ogsabp:KeyUsage attribute defined in this profile. ---- <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ogsabp="&ogsabp;" targetNamespace="&ogsabp;"> <!-- definition f the EndpointKeyInfo element --> <xs:element name="EndpointKeyInfo" type="ds:KeyInfoType"/> <!-- definition of the KeyUsage Attribute --> <xs:attribute name="KeyUsage" type="xs:anyURI"/> </xs:schema> ---- 6. Interoperability To ensure the interoperability, a wsse:SecurityTokenReference element MUST comform to the requirements defined in the section 4.2 of the WS-I Basic Profile 1.0 document (SecurityTokenReferences). To ensure the interoperability, if the wsse:BinarySecurityToken refers to or embeds an X509 Certificate, the wsse:BinarySecurityToken MUST comform to the requirements defined in the chapter 6 of the WS-I Basic Profile 1.0 document (X509 Certificate Token Profile). 7. Reference WS-Addressing Web Services Addressing 1.0 - Core http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/ XML-Signature XML-Signature Syntax and Processing, http://www.w3.org/TR/xmldsig-core/ Web Service Security http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-soap-message-security-1.0.pdf WS-I Basic Security Profile WS-I Basic Security Profile Working Groupd Draft http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html End of Note ----
<snip>
2. Namespaces ogsa-bp: a Namespace URI for the Basic Profile 1.0 document (OGSA Basic Profile 1.0)
And this note also uses the following entity references to ease the description of the URIs.
&wsse; the Namespace URI for Web Services Security v1.0 &ogsabp; the Namespace URI for OGSA Basic Profile 1.0
3. Example The following shows an example which the profile is intended to define.
(001) <wsa:EndpointReference> (002) <wsa:Address>http://www.globus.org/some/path</wsa:Address> (003) <wsa:Metadata> (004) <ogsabp:EndpointKeyInfo> (005) <wsse:SecurityTokenReference ogsabp:KeyUsage="&ogsabp;#signature"> (006) <wsse:Reference URI="#token1"/> (007) </wsse:SecurityTokenReference> (008) <wsse:SecurityTokenReference (009) ogsabp:KeyUsage="&ogsabp;#encryption"> (010) <wsse:Embedded> (011) <wsse:BinarySecurityToken ValueType="&wsse;X509PKIpathv1"> (012) MIIC..... (013) </wsse:BinarySecurityToken> (014) </wsse:Embedded> (015) </wsse:SecurityTokenReference> (016) </ogsabp:EndpointKeyInfo> (017) </wsa:Metadata> (018) </wsa:EndpointReference>
(001)-(018) An example wsa:EndointReference (004)-(016) An example of ogsabp:EndpointKeyInfo elment is shown. The actual key information contained in the ogsabp:EndpointKeyInfo element is bound to the endpoint specified by the enclosing wsa:EndpointReference. (005)-(007) An example of actual key information is shown. The key is expressed by using wsse:SecurityTokenReference and the ogsabp:KeyUsage attribute shows that the key shoud be used for signature. The key data is referenced by the same document referece, "#token1". (008)-(015) Another example of key information is shown. The key is also expressed by using wsse:SecurityTokenReference, but the actual key data is embbeded in the element as a wsse:BinarySecurityToken in wsse:Embedded. And the usage of the key is specified as encryption by the ogsabp:KeyUsage attribute.
6. Interoperability To ensure the interoperability, a wsse:SecurityTokenReference element MUST comform to the requirements defined in the section 4.2 of the WS-I Basic Profile 1.0 document (SecurityTokenReferences).
To ensure the interoperability, if the wsse:BinarySecurityToken refers to or embeds an X509 Certificate, the wsse:BinarySecurityToken MUST comform to the requirements defined in the chapter 6 of the WS-I Basic Profile 1.0 document (X509 Certificate Token Profile).
If I have a client environment that just understands WS-I specifications... what else would it need to understand to support this proposed profile. Could it handle the parsing of ogsabp:KeyUsage and know what to do with it? Steven -- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Deputy Director, Open Middleware Infrastructure Institute (OMII) Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK
Steven, I wasn't on the call, so others might need to clarify, but I would answer your question as follows. A WS-I PB plus WS-I WSSE Profile client would also have to understand these sections of the OGSA BP, in order to understand the meaning of the ogsabp QNames, and WS-Addressing, which is also profiled in OGSA BP (as are the specific parts of WS-I WSSE Profile that need to be understood). If we have done our homework correctly, everything you need to know is either in OGSA BP or referenced by it. On 7 Apr 2005, at 11:48, Steven Newhouse wrote:
<snip>
2. Namespaces ogsa-bp: a Namespace URI for the Basic Profile 1.0 document (OGSA Basic Profile 1.0) And this note also uses the following entity references to ease the description of the URIs. &wsse; the Namespace URI for Web Services Security v1.0 &ogsabp; the Namespace URI for OGSA Basic Profile 1.0 3. Example The following shows an example which the profile is intended to define. (001) <wsa:EndpointReference> (002) <wsa:Address>http://www.globus.org/some/path</wsa:Address> (003) <wsa:Metadata> (004) <ogsabp:EndpointKeyInfo> (005) <wsse:SecurityTokenReference ogsabp:KeyUsage="&ogsabp;#signature"> (006) <wsse:Reference URI="#token1"/> (007) </wsse:SecurityTokenReference> (008) <wsse:SecurityTokenReference (009) ogsabp:KeyUsage="&ogsabp;#encryption"> (010) <wsse:Embedded> (011) <wsse:BinarySecurityToken ValueType="&wsse;X509PKIpathv1"> (012) MIIC..... (013) </wsse:BinarySecurityToken> (014) </wsse:Embedded> (015) </wsse:SecurityTokenReference> (016) </ogsabp:EndpointKeyInfo> (017) </wsa:Metadata> (018) </wsa:EndpointReference> (001)-(018) An example wsa:EndointReference (004)-(016) An example of ogsabp:EndpointKeyInfo elment is shown. The actual key information contained in the ogsabp:EndpointKeyInfo element is bound to the endpoint specified by the enclosing wsa:EndpointReference. (005)-(007) An example of actual key information is shown. The key is expressed by using wsse:SecurityTokenReference and the ogsabp:KeyUsage attribute shows that the key shoud be used for signature. The key data is referenced by the same document referece, "#token1". (008)-(015) Another example of key information is shown. The key is also expressed by using wsse:SecurityTokenReference, but the actual key data is embbeded in the element as a wsse:BinarySecurityToken in wsse:Embedded. And the usage of the key is specified as encryption by the ogsabp:KeyUsage attribute.
6. Interoperability To ensure the interoperability, a wsse:SecurityTokenReference element MUST comform to the requirements defined in the section 4.2 of the WS-I Basic Profile 1.0 document (SecurityTokenReferences). To ensure the interoperability, if the wsse:BinarySecurityToken refers to or embeds an X509 Certificate, the wsse:BinarySecurityToken MUST comform to the requirements defined in the chapter 6 of the WS-I Basic Profile 1.0 document (X509 Certificate Token Profile).
If I have a client environment that just understands WS-I specifications... what else would it need to understand to support this proposed profile. Could it handle the parsing of ogsabp:KeyUsage and know what to do with it?
Steven
-- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Deputy Director, Open Middleware Infrastructure Institute (OMII) Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK
-- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)
Hi Steven, In general, as David says, your client needs to know the OGSA BP specifications and other specifications which is referenced by the OGSA BP specs. With regard to the proposed ogsabp:EndpointKeyInfo and ogsabp:KeyUsage, the XML-Signature, WS-Security and WS-Addressing speficifations are refferenced and the OGSA Basic Profile will profile these specifications, so your client needs to know all of them. The proposed profile only states where to find a key-info for message level security and how it is encoded, so I think we need to state how to handle with the information more clearly. Thanks,
From
Takuya: David Snelling <David.Snelling@UK.Fujitsu.com> Subject: Re: [ogsa-wg] OGSA Basic Profile Telecon Agenda 4/6 Date: Thu, 7 Apr 2005 13:42:55 +0100
Steven,
I wasn't on the call, so others might need to clarify, but I would answer your question as follows.
A WS-I PB plus WS-I WSSE Profile client would also have to understand these sections of the OGSA BP, in order to understand the meaning of the ogsabp QNames, and WS-Addressing, which is also profiled in OGSA BP (as are the specific parts of WS-I WSSE Profile that need to be understood). If we have done our homework correctly, everything you need to know is either in OGSA BP or referenced by it.
On 7 Apr 2005, at 11:48, Steven Newhouse wrote:
<snip>
2. Namespaces ogsa-bp: a Namespace URI for the Basic Profile 1.0 document (OGSA Basic Profile 1.0) And this note also uses the following entity references to ease the description of the URIs. &wsse; the Namespace URI for Web Services Security v1.0 &ogsabp; the Namespace URI for OGSA Basic Profile 1.0 3. Example The following shows an example which the profile is intended to define. (001) <wsa:EndpointReference> (002) <wsa:Address>http://www.globus.org/some/path</wsa:Address> (003) <wsa:Metadata> (004) <ogsabp:EndpointKeyInfo> (005) <wsse:SecurityTokenReference ogsabp:KeyUsage="&ogsabp;#signature"> (006) <wsse:Reference URI="#token1"/> (007) </wsse:SecurityTokenReference> (008) <wsse:SecurityTokenReference (009) ogsabp:KeyUsage="&ogsabp;#encryption"> (010) <wsse:Embedded> (011) <wsse:BinarySecurityToken ValueType="&wsse;X509PKIpathv1"> (012) MIIC..... (013) </wsse:BinarySecurityToken> (014) </wsse:Embedded> (015) </wsse:SecurityTokenReference> (016) </ogsabp:EndpointKeyInfo> (017) </wsa:Metadata> (018) </wsa:EndpointReference> (001)-(018) An example wsa:EndointReference (004)-(016) An example of ogsabp:EndpointKeyInfo elment is shown. The actual key information contained in the ogsabp:EndpointKeyInfo element is bound to the endpoint specified by the enclosing wsa:EndpointReference. (005)-(007) An example of actual key information is shown. The key is expressed by using wsse:SecurityTokenReference and the ogsabp:KeyUsage attribute shows that the key shoud be used for signature. The key data is referenced by the same document referece, "#token1". (008)-(015) Another example of key information is shown. The key is also expressed by using wsse:SecurityTokenReference, but the actual key data is embbeded in the element as a wsse:BinarySecurityToken in wsse:Embedded. And the usage of the key is specified as encryption by the ogsabp:KeyUsage attribute.
6. Interoperability To ensure the interoperability, a wsse:SecurityTokenReference element MUST comform to the requirements defined in the section 4.2 of the WS-I Basic Profile 1.0 document (SecurityTokenReferences). To ensure the interoperability, if the wsse:BinarySecurityToken refers to or embeds an X509 Certificate, the wsse:BinarySecurityToken MUST comform to the requirements defined in the chapter 6 of the WS-I Basic Profile 1.0 document (X509 Certificate Token Profile).
If I have a client environment that just understands WS-I specifications... what else would it need to understand to support this proposed profile. Could it handle the parsing of ogsabp:KeyUsage and know what to do with it?
Steven
-- ---------------------------------------------------------------- Dr Steven Newhouse Tel:+44 (0)2380 598789 Deputy Director, Open Middleware Infrastructure Institute (OMII) Suite 6005, Faraday Building (B21), Highfield Campus, Southampton University, Highfield, Southampton, SO17 1BJ, UK
--
Take care:
Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE
+44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)
Dear All, Please find an updated note for the EPR/KeyInfo in the below. The changes are: 1. Changed to use wsse:Usage attribute instead defining our own ogsabp:KeyUsage for specifying the usage of the key-info. 2. Added some text to the wsse:Usage attribute. - absence of the usage attribute. - inconsistency on the usage defined in the key-info data itself 3. Some editorial changes. 4. Changed the version number to V0.3. Regards, Takuya Mori ---- Apr. 13, 2005 Note: Key infomation exchange for message level security (V0.3) Frank Siebenlist, Samuel Meder and Takuya Mori 0. Introduction This document is to define key information exchange for message level security by using the Matadata element in the EndpointReference which is defined in the latest WS-Addressing draft specification. This document is intended to serve as a base input for the basic profile discussion. 1. Use cases The followings are use cases that the profiles specified in the document intend to cover. - When a client wants to send any encrypted message to a service, it will have to know the key associated with that service. - When a client wants to make a policy decision whether or not it wants a certain service to serve its request, it has to know the service's key-info. 2. Namespaces This note uses the following namespaces to define the profile. prefix Namespece URI (Specification) wsa: http://www.w3.org/2005/03/addressing ds: http://www.w3.org/2000/09/xmldsig# (XML-Signature Syntax and Processing) wsse: http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-wssecurity-secext-1.0.xsd (Web Services Security v1.0) ogsa-bp: a Namespace URI for the Basic Profile 1.0 document (OGSA Basic Profile 1.0) And this note also uses the following entity references to ease the description of the URIs. &wsse; the Namespace URI for Web Services Security v1.0 &ogsabp; the Namespace URI for OGSA Basic Profile 1.0 3. Example The following shows an example which the profile is intended to define. (001) <wsa:EndpointReference> (002) <wsa:Address>http://www.globus.org/some/path</wsa:Address> (003) <wsa:Metadata> (004) <ogsabp:EndpointKeyInfo> (005) <wsse:SecurityTokenReference wsse:Usage="&ogsabp;#signature"> (006) <wsse:Reference URI="#token1"/> (007) </wsse:SecurityTokenReference> (008) <wsse:SecurityTokenReference (009) wsse:Usage="&ogsabp;#encryption"> (010) <wsse:Embedded> (011) <wsse:BinarySecurityToken ValueType="&wsse;X509PKIpathv1"> (012) MIIC..... (013) </wsse:BinarySecurityToken> (014) </wsse:Embedded> (015) </wsse:SecurityTokenReference> (016) </ogsabp:EndpointKeyInfo> (017) </wsa:Metadata> (018) </wsa:EndpointReference> (001)-(018) An example wsa:EndointReference (004)-(016) An example of ogsabp:EndpointKeyInfo elment is shown. The actual key information contained in the ogsabp:EndpointKeyInfo element is bound to the endpoint specified by the enclosing wsa:EndpointReference. (005)-(007) An example of actual key information is shown. The key is expressed by using wsse:SecurityTokenReference and the wsse:Usage attribute shows that the key shoud be used for signature. The key data is referenced by the same document referece, "#token1". (008)-(015) Another example of key information is shown. The key is also expressed by using wsse:SecurityTokenReference, but the actual key data is embbeded in the element as a wsse:BinarySecurityToken in wsse:Embedded. And the usage of the key is specified as encryption by the wsse:Usage attribute. 4. Infoset The following is the descriptions or definitions of the infosets refered or defined in this note. - /wsa:EndpointReference/wsa:Metadata WS-Addressing defines optional wsa:Metadata element which is used to hold metadata that is relevant to the interaction with the endpoint. - /wsa:EndpointReference/wsa:Metadata/osgabp:EndpointKeyInfo/ The ogsabp:EndpointKeyInfo is defined as a ds:KeyInfoType which is defined in the XML-Signture specification to contain generic key information. In this profile, the element is used to specify a key information which should be used to interact with the endpoint. - /wsa:EndpointReference/wsa:Metadata/ogsabp:EndpointKeyInfo/ wsse:SecurityTokenReference Although the XML-Signature specification defines various types of elements which are intended to be used as a child element of ds:KeyInfoType element and the specification also allows the ds:KeyInfoType element to have arbitary types of elements in its content, this profile mandates the use of wsse:SecurityTokenReference elements under the ogsabp:EndpointKeyInfo element. - /wsa:EndpointReference/wsa:Metadata/ogsabp:EndpointKeyInfo/ wsse:SecurityTokenReference/@wsse:Usage WS-Security defines this optional attribute which is used to type the usage of the wsse:SecurityTokenReference element. This profile defines the following values for the @wsse:Usage attribute to specify the usage of the key referenced by the wsse:SecurityTokenReference. Value Usage &ogsabp;#encryption Encryption key needed to interact with the endpoint. &ogsabp;#signature Signature verification key needed to interact with the endpoint. Absence of this attribute means that the key can be used for both encryption and signature verification. Implementations which create the key-info data MAY NOT set an inconsitent value with the usage in the referenced key to this @wsse:Usage attribute. For example, if the KeyUsage certificate extension of a X509 public key certificate is marked as CRITICAL and set to Signing, then an implementation MAY NOT set &ogsabp;#encryption to the @wsse:Usage attribute. (Thus, in this case, the certificate cannot be used as an encryption key.) Implementations which detect an inconsistency between the value of @wsse:Usage attribute and the usage specified in the referenced key itself MUST report an error and MAY NOT use the key for the usage specified by the @wsse:Usage attribute. 5. Schema The following schema fragment defines ogsabp:EndpointReferenceType element defined in this profile. ---- <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ogsabp="&ogsabp;" targetNamespace="&ogsabp;"> <!-- definition f the EndpointKeyInfo element --> <xs:element name="EndpointKeyInfo" type="ds:KeyInfoType"/> </xs:schema> ---- 6. Interoperability To ensure the interoperability, a wsse:SecurityTokenReference element MUST comform to the requirements defined in the section 4.2 of the WS-I Basic Profile 1.0 document (SecurityTokenReferences). To ensure the interoperability, if the wsse:BinarySecurityToken refers to or embeds an X509 Certificate, the wsse:BinarySecurityToken MUST comform to the requirements defined in the chapter 6 of the WS-I Basic Profile 1.0 document (X509 Certificate Token Profile). 7. Reference WS-Addressing Web Services Addressing 1.0 - Core http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/ XML-Signature XML-Signature Syntax and Processing, http://www.w3.org/TR/xmldsig-core/ Web Service Security http://docs.oasis-open.org/wss/2004/01/ oasis-200401-wss-soap-message-security-1.0.pdf WS-I Basic Security Profile WS-I Basic Security Profile Working Groupd Draft http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html End of Note ----
participants (4)
-
David Snelling -
Steven Newhouse -
Takuya Mori -
Tom Maguire