Re: [dss] Signature Gateway Profile Transport Binding

[Glenn.Benson@chase.com]

Trevor,

Yes, I agree that there are some higher-level protocol issues.  Perhaps,
the best approach is to build a mandatory binding for HTTP per the
conventional DSS request/response choreography.  However, we should not
prohibit other optional bindings.

Our colleague John Linn of RSA asked the following question:
Is the requirement for support of at least one
specified transport binding a must-implement for interoperability, not a
must-actively-enable-for-all-deployments: would it be possible to have a
valid and conformant DSS implementation deployed in a mode where the
HTTP binding support code was latent and inactive?  Rather than
considering a local interface as a proprietary binding, would it be
possible to construe it instead as a null binding, appropriate for use
where communications paths lie outside the scope of network protocols?

Glenn



                                                                                                                                   
                      Trevor Perrin                                                                                                
                      <trevp@trevp.net>        To:       <Glenn.Benson@chase.com>                                                  
                                               cc:                                                                                 
                      01/24/2005 04:45         Subject:  Re: [dss] Signature Gateway Profile Transport Binding                     
                      AM                                                                                                           
                                                                                                                                   
                                                                                                                                   





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