Re: [dss] Signature Gateway Profile Transport Binding

[Trevor Perrin <trevp@trevp.net>]

Hi Glenn,

My understanding is you want a client to send a DSS Sign Request, embedded 
in some message, to an intermediary, which then produces a signature and 
forwards the DSS Sign Response to a final destination (not the client).

It seems to me this isn't a profile of DSS, but rather a higher-level 
protocol built on DSS.  I.e., you're embedding the DSS request/response 
flow in a more complicated flow.  If you'd like to add this to your profile 
you're welcome too, of course, but this is different enough that I'm not 
sure what advice to give.

Trevor



At 05:51 PM 1/10/2005 -0500, Glenn.Benson@chase.com wrote:
>This note responds to an action item of the 10-Jan-05 DSS meeting.
>
>DSS Profile: Signature Gateway Profile
>Issue: Open Issue in Specification of Transport Binding
>Description:
>The Signature Gateway Profile operates under multiple different use cases.
>The standard request/response use case has no open issue related to the
>transport binding because there is no significant difference between the
>Signature Gateway Profile and any other DSS profile.
>
>However, the Signature Gateway Profile identifies the "inline deployment"
>use case:
>"Devices located at the security perimeter may combine Signature Gateway
>with other security services.  Consider for example, deep packet inspection
>firewalls, content-inspecting load balancers, intelligent reverse proxies,
>or XML firewalls.  These devices contain the technology to inspect incoming
>communication while searching for signatures.  When the device identifies a
>signature within the context of a message, the device applies the Signature
>Gateway transformation, and then forwards the modified communication to the
>destination."
>
>In the inline deployment model, a gateway device intermediates between the
>client and the DSS services.  Therefore, neither the client requesting a
>transformation; nor the recipient which receives the transformed
>communication communicate directly with the DSS server, i.e., the transport
>mechanism communicating with the DSS server is not visible.   We would like
>the vendor of the inline server to be able to make a claim concerning
>conformance to the DSS interface, independently with respect to the
>transport binding.
>
>Consider the following example.  The signing client communicates with an
>intelligent reverse proxy through SSL.  The client embeds Signature Gateway
>Server-conformant DSS requests within the larger body of an HTTP request.
>Through proprietary methods, the intelligent reverse proxy parses the
>request, isolates the DSS request, and forwards the DSS request to a
>co-located DSS Signature Gateway Server.  The intelligent reverse proxy
>grabs the response and through proprietary methods injects the response
>into the original HTTP request.  The downstream target of the HTTP request
>receives a modified HTTP packet, where the modification contains a DSS
>Signature Gateway server-conformant response.  Note that this example,
>gives vendors the ability to differentiate themselves through clever and
>flexible HTTP parsing and injection methods.  However, DSS standardization
>will provide interoperability because both the signing client, and the
>target server both understand DSS formats.  From the perspective of the
>signing client and the target server, the reverse proxy provides a
>semantically-aware transport mechanism.
>
>How should we handle the bindings of the Signature Gateway profile?
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dss-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: dss-help@lists.oasis-open.org