RE: [dss] JPMorgan/RSA message

[Trevor Perrin <trevp@trevp.net>]

At 04:37 PM 10/28/2004 -0400, Glenn.Benson@chase.com wrote:
>[...]
>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".

Mm, right, if you use the Verify protocol with UpdateSignature, the PSTP is 
the signature, and the claimed identity and authentication token basically 
get passed inside the PSTP.


>2.  I hope that I answered the inline question above, i.e., we only need to
>consider the request/response model.

Cool, makes things easier.


>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.

Sure, all I'm pointing out is that your profile document will be both a 
"signature profile" and a "protocol profile".  I.e. it will profile 
XML-DSIG as well as DSS.


>  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.

Well said!  I hope you use that paragraph in your profile overview.

I also hope that that centralization justifies having a DSS Server separate 
from the proxy server(s).  So that this separation has real benefits, and 
isn't just an artifact of squeezing into our model.

Trevor


>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