[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] JPMorgan/RSA message
Trevor,
Thanks for your question. We are looking to standardize a Signature
Gateway Profile, and introduce a one-time passwords into the DSS spec. The
DSS TC is making good progress on the one-time password issue. However, we
encountered difficulties on the Signature Gateway Profile due to our desire
for in-line processing. Burt Kaliski and I met to discuss the
difficulties, and we would like to propose a potential solution which the
enclosed JPEG illustrates.
If we separate the inline proxy into two components, then we may
potentially isolate a DSS server which exhibits a conventional
request/response model. The diagram illustrates a client who sends a
message; a signature-aware proxy that transforms the message; and a
transaction server that processes the message. For illustrative purposes,
the diagram surrounds the signature-aware proxy with firewalls; however,
these firewalls are extraneous to the example. The diagram breaks the
signature-aware proxy into two pieces: a proxy and a DSS server. The
client sends a message which contains a signature of data. The
signature-aware proxy either countersigns the original signature, or
applies a second signature to the original data. The following
description presents the individual steps.
1. The client sends a request to the proxy. The request either contains
an XMLDSIG-compliant signature; or the request is a fully-formatted DSS
request.
2a. The proxy intercepts the message and extracts the signature-related
piece. If this piece is a DSS request formatted by the client, then the
proxy simply forwards the request to the DSS server. Otherwise, the proxy
envelopes the signature with a DSS request and submits to the DSS server.
2b. The DSS server operates in a conventional request/response manner by
validating the signature and re-signing. Presumably, the DSS server
operates as a gateway between signature technologies. For example, the
client may apply PSTP as its signature method; while the DSS server applies
an HMAC.
3. The application server validates the DSS server's signature.
Perhaps, the actual DSS profile is a conventional request/response
signature gateway. In this profile, the binding would consider
confidentiality as an option; and the binding would not require support for
either authentication or integrity. Perhaps, the Signature Gateway Profile
may allow for negotiation of the signature request formats that the DSS
server agrees to process.
In reference to Trevor's specific questions, please consider the following
responses:
1. I am not sure that PSTP fits as a <ClaimedIdentity> because PSTP is a
signature which binds authentication to integrity. Also, we require
further research to determine whether PSTP should be referenced as
"abstract" or "concrete".
2. I hope that I answered the inline question above, i.e., we only need to
consider the request/response model.
3. I agree that PSTP best fits as a signature representation. However, in
accordance to the charter of DSS, a Signature Gateway Profile is general
technique for processing digital signatures. The purpose of this profile
is to (i) bridge disparate signature technologies, and (ii) translate
between different private keying material logistic infrastructures.
In order to further motivate the Signature Gateway Profile, consider a
large Financial Services institution. The institution requires that its
clients sign transactions, but the institution does not process the
transactions until it validates the signatures. The financial institution
has hundreds of applications residing on different servers. Through
centralization, the financial institution may deploy specialized
cryptography hardware in order to both protect keys and optimize
performance. Also, the centralized service can hide the complex issues of
client credential management from the applications. That is, the
applications need to understand the logistics of the centralized service's
keys, but not the clients' keys.
Glenn
(See attached file: Signature Aware Proxy 28-oct-o4.jpg)
Overall network diagram
client-------------->proxy-------------------------->application
Trevor Perrin
<trevp@trevp.net> To: <dss@lists.oasis-open.org>
cc:
10/28/2004 03:40 Subject: RE: [dss] JPMorgan/RSA message
AM
Glenn,
I'm still trying to figure what parts of your technology overlap with DSS,
and how they'd fit into profiles. It seems there's 3 pieces:
1) An authentication technology (PSTP) for authenticating clients to
signature servers. This could be an "abstract profile" of DSS, profiling
the <ClaimedIdentity> optional input to carry a PSTP signature (abstract
profiles can be combined with other profiles; see Paul Madsen's profile
integration doc:
http://www.oasis-open.org/apps/org/workgroup/dss/download.php/6175/profile-integration-01.doc
).
2) The concept of an inline Signature Gateway. It's not clear how this
fits with DSS. Are DSS <SignRequest> messages sent inline as well? Or
does the inline server call a DSS server?
3) A way of augmenting a signature (adding a MAC
counter-signature). This is more a profile of the signature format than of
the DSS protocol, but could make sense in DSS, if it's a DSS server doing
the augmenting.
If this is a good breakdown, I'm curious which pieces you're interested in
standardizing through DSS, and how you'd want to factor things (i.e., would
pieces be reusable apart from the whole)?
Trevor
To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php
.
Signature Aware Proxy 28-oct-o4.jpg
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
