Creating Signaturesat

User Agents

Comparing Transport Bindings

Use CaseAssumptions• A User-Agent is connected to 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.

• This User-Agent may be equipped with a gradual set of signature-related functionality ranging from the simple forwarding of APDUs e.g. according to ISO/IEC 7816 to the (S)SCD to full blown signature functionality according to the different OASIS DSS(-X) profiles.

• A User-Agent may have has limited software & performance capabilities and hence may be supported by a remote Digital Signature Service to handle the complexities of the signature creation if it cannot manipulate the document itself.

• A User-Agent always initiates the transaction and serves as HTTP-client.• A document may remain on the client or server side s or move from one

side to the other. at it’s current location at the Remote-End.• A remote Digital Signature Service may be is used to handle the

complexities of the signature creation (see above).• As an example, a User-Agent can be a Mobile Device or an Applet in the

browser.• The OASIS DSS Core is used.

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.

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.

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

UserAgent

RemoteSystem

DigitalSignatureService

(S)SCD@ User Agent

Select document

Sign document

Calculate Hash

DSS-Request(Complex)

DSS-Request(PKCS#1)

DSS-Response

DSS-Response

Prepare requestfor document

Verification,Timestamping,Revocation Info,etc....

SignHash

Sequence Diagram 1 – Delegated DSS

Document signed

1

2

UserAgent

RemoteSystem

DigitalSignatureService

(S)SCD@ User Agent

Select document

Sign document

Calculate Hash

DSS-Request(Complex)

DSS-Request(PKCS#1)

DSS-Response

DSS-Response

Prepare requestfor document

Verification,Timestamping,Revocation Info,etc....

SignHash

Sequence Diagram 2 – Composite DSS

Document signed

1

2

UserAgent

RemoteSystem

Select document

SignRequestCalculate Hash (optional)

SignResponse

Prepare requestfor document

Verification,Timestamping,Revocation Info,etc. (optional)

Sequence Diagram 3 – “Rich DSS Client”

signed Document

1

(S)SCD@ User Agent

SignHash

2Sign-APDU

PKCS#1-Signature

UserAgent

RemoteSystem

Select document

Sign(DID,hash)

Calculate Hash

SignResponse(Signature)

Prepare requestfor document

Verification,Timestamping,Revocation Info,etc. (optional)

Sequence Diagram 4 – “SAL-Client (ISO/IEC 24727 / CEN 15480)”

signed Document

1

(S)SCD@ User Agent

SignHash

2Sign-APDU

PKCS#1-Signature

HashResponse(hash)

Hash(Message) or0

UserAgent

RemoteSystem

Select document

Transmit(Sign-APDU)

Calculate Hash (optional)

TransmitResponse(Signature)

Prepare requestfor document

Verification,Timestamping,Revocation Info,etc. (optional)

Sequence Diagram 5 – “IFD-Client (ISO/IEC 24727 / CEN 15480)”

signed Document

1

(S)SCD@ User Agent

SignHash

2Sign-APDU

PKCS#1-Signature

eCard-API-Framework

Service-Access-Layer

Identity-Layer

Terminal-Layer

Application-Layer

eCard-Interface

GRTool, Border

Control ...

eHealth-Application

ePA-Application

JobCard ELSTER ...

ISO24727-3-Interface

ePassport CardInfo

ePA CardInfo

eGK/HBA CardInfo

ePassportConvenience

Support Services

Support-Interface

Generic Card Services

...

Management Services

Mgmt-Interface

Encryption Services

Signature ServicesIdentity Services

IFD-Interface

SCARD-Interface

PC/SC 2.0 IFD-Handler

IFD-Handler

IFDSICCT

CT-API-Interface

MKT, B1 etc.

SICCT-Interface

ePAConvenience

eHealthConvenience

JobCardConvenience

eID

Manage-ment

ManagementConvenience

ELSTERConvenience ...

Rich DSS Client

SAL Client

IFD-Client

Major standards

Service-Access-Layer

Identity-Layer

Terminal-Layer

Application-Layer

eCard-Interface

GRTool, Border

Control ...

eHealth-Application

ePA-Application

JobCard ELSTER ...

ISO24727-3-Interface

ePassport CardInfo

ePA CardInfo

eGK/HBA CardInfo

ePassportConvenience

Support Services

Support-Interface

Generic Card Services

...

Management Services

Mgmt-Interface

Encryption Services

Signature ServicesIdentity Services

IFD-Interface

SCARD-Interface

PC/SC 2.0 IFD-Handler

IFD-Handler

IFDSICCT

CT-API-Interface

MKT, B1 etc.

SICCT-Interface

ePAConvenience

eHealthConvenience

JobCardConvenience

eID

Manage-ment

ManagementConvenience

ELSTERConvenience ...

ISO/IEC 24727(CEN 15480)

ISO/IEC 24727(CEN 15480)

OASIS DSS (-X)OASIS DSS (-X)

Signature-related functions

Service-Access-Layer

Identity-Layer

Terminal-Layer

eCard-Interface

ISO24727-3-Interface

Support Services

Support-Interface

Generic Card Services

Mgmt. Services

Mgmt-Interface

IFD-Interface

eID Signature Services

SignRequest / SignResponse

Sign /S.Resp.

VerifyRequest / VerifyResponse

Connection to Interface-Device and Card

Hash / H. Resp.

DIDAuthenticate /DIDAuthenticateResp.

EstablishContext / Est.Con.Resp.

Transmit /Transm.Resp.

Connect /Con.Resp.

VerifyUser /VerifyUserResp.

Connection Management User Authentication Signature VerificationLegend: Signature Creation

ISO/IEC 24727 is based on DSS

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.

PAOAS – Sequence 1

(1) Sign document

(2) DSS-Request(PKCS#1)

(2) DSS-Response

(1) Document signed

Calculate Hash

SignHash

DSS

DSS-Response

DigitalSignatureService

DSS-Request(Complex)

Prepare DSS request

Diffe

ren

t se

ssion

!

RemoteSystem

PAOAS – Sequence 2

(1) Sign document

(2) DSS-Request(PKCS#1)

(2) DSS-Response

(1) Document signed

Calculate Hash

SignHash

DSS

DSS-Request(Complex)

DSS-Response

DigitalSignatureService

RemoteSystem

PAOS – Sequence 3

(1) Sign document

(2) SignRequest

(2) SignResponse

(1) Document signed

Calculate Hash (optional)

SignHash

DSS (optional)

RemoteSystem

PAOS – Sequence 4

(1) Sign document

(2) Sign (ISO/IEC 24727)

(2) SignResponse (ISO/IEC 24727)

(1) Document signed

Calculate Hash (optional)

SignHash

DSS (optional)

RemoteSystem

PAOS – Sequence 5

(1) Sign document

(2) Transmit(APDU)

(2) TransmitResponse(Signature)

(1) Document signed

Calculate Hash (optional)

SignHash

DSS (optional)

RemoteSystem

PAOAS 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 PAOAS R/R, to put the “(2) DSS-Request(PKCS#1)” into the POAS response.

• Sequence 3-5 show integration of OASIS DSS(-X) and ISO/IEC 24727 / CEN 15480

It seems that the „additional complexity“

stems from the separation of the

Remote System and the DSS

(1) Document signed

(1) Sign document

ebMSv3 – Sequence 1UserAgent

RemoteSystem

DigitalSignatureService

(S)SCD@ User Agent

PUSH(Request(Sign document))

MSH A MSH B MSH A

PULL(Request)

(2) DSS-Request(PKCS#1)

PUSH(Response)

(2) DSS-Response

PULL(Response)

CalculateHash

DSS-Request(Complex)

DSS-Response

Verification,Timestamping,Revocation Info,etc....

SignHash

MSH C

(2) DSS-Response

(2) DSS-Request(PKCS#1)

(1) Document signed

(1) Sign document

ebMSv3 – Sequence 2UserAgent

RemoteSystem

DigitalSignatureService

(S)SCD@ User Agent

PUSH(Request(Sign document))

MSH A MSH B MSH A

CalculateHash

PULL(Request)

PUSH(Response)

PULL(Response)

DSS-Request(Complex)

DSS-ResponseVerification,Timestamping,Revocation Info,etc.

SignHash

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 PAOAS ‘client’ at the User Agent regarding implementation complexity?

• A simple PAOS-applet may be as small as 100 kB.