RE: [dss] Signature Gateway Profile Transport Binding

["Nick Pope" <pope@secstan.com>]

Glen,

Whilst my the suggestion of the application of the concept of Abstract vs
Conrete profile to this issue was not followed up at the meeting I do
believe that this is the only way to cover the "inline deployment" case.

Unless specific protocols are defined for the signatory to gateway / gateway
to outside world, I cannot see how it is posible to have interopable
concrete implementations.  A similar situation has occured with the entity
seal profile where it it was required that this profile was changed from
concrete to abstract as it did not mandate a single tranport binding.

Thus I suggest that the resolution of this is to define signature gateway in
terms of an abstract profile, with one concrete sub-profile definging a
implementable protocol between the DSS client and Server.

Nick

> -----Original Message-----
> From: Glenn.Benson@chase.com [mailto:Glenn.Benson@chase.com]
> Sent: 10 January 2005 22:52
> To: dss@lists.oasis-open.org
> Subject: [dss] Signature Gateway Profile Transport Binding
>
>
> 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
>
>
>