1 / 14

Creating Signatures at User Agents

Creating Signatures at User Agents. Comparing Transport Bindings. Use Case. Assumptions A User-Agent is used as a Signature Creation Device, possibly by means of an SSCD, but cannot perform all verification functions nor all kinds of complex signature creation functions.

cale
Download Presentation

Creating Signatures at User Agents

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Creating Signaturesat User Agents Comparing Transport Bindings

  2. Use Case Assumptions • A User-Agent is used as a Signature Creation Device, possibly by means of an SSCD, but cannot perform all verification functions nor all kinds of complex signature creation functions. • A User-Agent has limited software & performance capabilities; it cannot manipulate the document itself. • A User-Agent always initiates the transaction. • A document remains at it’s current location at the Remote-End. • A remote Digital Signature Service is used to handle the complexities of the signature creation. • As an example, a User-Agent can be a Mobile Device or an Applet in the browser. • The OASIS DSS Core is used.

  3. Use Case Actor • The End-User of the User-Agent. System • The User-Agent, communicating with a remote system for document handling and signature creation.

  4. Use Case • Basic Flow • Actor selects document. • User Agent remembers the selected document at the remote end. • Actor requests a signing operation for the document. • User Agent asks the user for a PIN or Password. • Actor enters the PIN or Password • User Agent calculates the signature using the (Secure) Signature Creation Device and presents the signed document, at the remote end, to the user. • Actor views the signed document.

  5. System Aspects • The User Agent is capable of creating a raw digital signature; it needs the hash of the document to create the raw signature. • The document is at the Remote End. • Scenario’s • 1: Remote End requests DSS to do the signature creation; DSS delegates the raw signature creation to the User Agent. • 2: Remote End calculates the hash, requests the User Agent to create a raw signature and requests DSS to ‘complete’ the signature creation (the request contains the raw signature). • Case 2 requires the User Agent to have a ‘thin’ implemention of the DSS interface. • Both cases require 2 interactions between the User Agent and the Remote End for the signature creation. 1 2

  6. Sequence Diagram 1 – Delegated DSS User Agent Remote System Digital Signature Service (S)SCD @ User Agent Select document 1 Sign document Prepare request for document DSS-Request(Complex) Calculate Hash 2 DSS-Request(PKCS#1) Sign Hash DSS-Response Verification, Timestamping, Revocation Info, etc. ... DSS-Response Document signed

  7. Sequence Diagram 2 – Composite DSS User Agent Remote System Digital Signature Service (S)SCD @ User Agent Select document 1 Sign document Prepare request for document Calculate Hash 2 DSS-Request(PKCS#1) Sign Hash DSS-Response DSS-Request(Complex) Verification, Timestamping, Revocation Info, etc. ... DSS-Response Document signed

  8. Interaction User Agent • Initiate Request • Hash is calculated at the ‘Remote End’ • Create signature • Hash is signed at the User Agent In all cases the client (User Agent) initiates the requests to the Remote End. Possible Transport Bindings: • PAOS, reverse SOAP. • ebMS v3, using the ‘polling’ mode. • Two separate SOAP calls.

  9. POAS – Sequence 1 Remote System Digital Signature Service (1) Sign document Prepare DSS request DSS-Request(Complex) Calculate Hash (2) DSS-Request(PKCS#1) Sign Hash Different session! (2) DSS-Response DSS (1) Document signed DSS-Response

  10. POAS – Sequence 2 Remote System Digital Signature Service (1) Sign document Calculate Hash (2) DSS-Request(PKCS#1) Sign Hash (2) DSS-Response DSS-Request(Complex) DSS (1) Document signed DSS-Response

  11. POAS Usage • Sequence 1 seems more complex than Sequence 2 • The request/response “(2) DSS-Request(PKCS#1)” is a new session, initiated by the DSS server ... • ... That request has to be correlated, by the Remote End, to the first POAS R/R, to put the “(2) DSS-Request(PKCS#1)” into the POAS response.

  12. ebMSv3 – Sequence 1 User Agent Remote System Digital Signature Service (S)SCD @ User Agent MSH A MSH B MSH C MSH A PUSH(Request(Sign document)) (1) Sign document Calculate Hash DSS-Request(Complex) PULL(Request) (2) DSS-Request(PKCS#1) Sign Hash PUSH(Response) (2) DSS-Response Verification, Timestamping, Revocation Info, etc. ... DSS-Response PULL(Response) (1) Document signed

  13. ebMSv3 – Sequence 2 User Agent Remote System Digital Signature Service (S)SCD @ User Agent MSH A MSH B MSH A PUSH(Request(Sign document)) (1) Sign document Calculate Hash PULL(Request) (2) DSS-Request(PKCS#1) Sign Hash PUSH(Response) (2) DSS-Response DSS-Request(Complex) Verification, Timestamping, Revocation Info, etc. DSS-Response PULL(Response) (1) Document signed

  14. ebMS Usage • Sequence 1 • Requires DSS server to use ebMSv3 • Pull Request from User Agent has to be routed via the Remote System. • Sequence 2 • Does not require DSS server to use ebMSv3 • No routing issue • How does the ebMSv3 ‘client’ compare to the POAS ‘client’ at the User Agent regarding implementation complexity?

More Related