Signature Gateway Profile Transport Binding

[Glenn.Benson@chase.com]

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?