RE: [dss] DSS Use Cases...

[Nick Pope <pope@secstan.com>]

Title: DSS Use Cases...

Taking up Carlisle's ball to keep it rolling, I add below some comments on his scenarios plus a couple more:

 

Nick

-----Original Message-----
From: Carlisle Adams [mailto:carlisle.adams@entrust.com]
Sent: 07 January 2003 21:22
To: 'dss@lists.oasis-open.org'
Subject: [dss] DSS Use Cases...

Hi all,

In order to get the ball rolling on use cases, I would like to submit to the DSS Use Case subcommittee three use-case scenarios for the digital signature service: corporate seal, SOAP signing, and identified requester.

It is not expected that a single private key would be used to support all three scenarios (e.g., that the same key would be used to sign both corporate documents and SOAP XML messages).

Comments on these use cases are welcome!

Carlisle.

8<--------------------------------------------------

Corporate Seal

This scenario has a corporation using the Digital Signature Service interface to sign documents before the publication of these documents to external entities (either as hosted HTML or as distributed Word or PDF docs). The assumption is that the published document contains some statement that the corporation is making to its business partners, customers, investors, analysts, etc. - the nature of which is important and sensitive. The primary motivation for the signature is to ensure the integrity of the published document so that relying parties can be confident that the material within has not been modified. (The signature will also serve to reinforce the identity of the corporation that published the document - this information presumably also asserted through the internal content such as logo, titles, copyright notices, and so on.)

The benefit of this use case derives from the assumption that in practice it will be easier to securely distribute a corporate public key for verification of such signatures than the private keys of a dynamic list of individuals within the corporation who might create the documents that require these signatures.
 
[Nick Pope] A further feature of this type of statement is that it can be assumed to be evidence of the legal intent of the corporation and hence may need to be non-repudiable.  Also, it may be necessary to verify this signature some time after the statement was issued.

 

<<...OLE_Obj...>>

SOAP Signing

This scenario has a 3rd party Web service requester or service provider calling out to the Digital Signature Service interface for the application of a signature to some SOAP payload (and potentially envelope elements) before sending the signed SOAP message to the other participant.  This scenario is identical to the Corporate Seal scenario except for the entities involved.  In particular, it is not expected that the Digital Signature Server will need to understand, parse, or formulate SOAP-compliant messages:  as with the Corporate Seal scenario, the data it receives will be an opaque binary "blob" and the data it returns will be an XML Signature on that "blob".

A variant of this scenario has the request coming not directly from the application itself but from a so-called SOAP gateway sitting in front of the application. The Digital Signature Server (and any future Relying Parties) will be unaffected by such a modification to the architecture.
[Nick Pope] 

I see this scenario as being significantly diffierent from the corporate scenario in that the the SOAP signature is only for authentication of the request at the time of the transaction.  Hence it does not have the need to have the same strength of evidential value as corporate signatures indicating intent.

<<...OLE_Obj...>>

Identified Requester

In this scenario, the Digital Signature Server is signing on behalf of an individual requester and makes an assertion to that effect in the returned response. This scenario differs from those of Corporate Seal and SOAP Signing in that the identity of the requester is not returned in the response in those scenarios.

Where the actual Service Requester is itself acting on behalf of some other entity (e.g., a browser-based application requesting a digital signature for the individual), it may be relevant for the Digital Signature Server to assert the complete request chain in the response it returns.

The Digital Signature Server may sign all data with its own private key and simply include the name or identifier of the requester(s) within the scope of the data that is signed.  Alternatively, the Digital Signature Server may sign on behalf of a requester using the requester's private key, which is stored at the Server.  In either design, this use case may be motivated by assumptions regarding efficiency (e.g., hardware-assisted cryptography), centralized policy management and enforcement, and assurances with respect to safeguarding of private keys.

Identified Requester can be regarded as a variant of the other two use-case scenarios.
[Nick Pope] 

I am not sure I follow when the case of one identity acting on behalf of another applies.  I would have though in the case of the individual reuqets the signature relates to an individual.  In the case of a corporate signature there made be elements of the identified signatory which includes both the corporation, on whose behalf the signature is created, and the individual or computer system creating the acting for the corporation which may be needed for accountability purposes.

I presume that this case of individual signatures only applies to authentication required for real time access.  Not for long term evidence of intent.

ADDITIONAL SCENARIOS

Individual Signatures

In the case of an individal signing an electronic agreement, for example hire purchase, it is necessary to ensure the intent of the signatory and protect again later repudiation of the signature.

Long Term Corporate Signatures

In the case of say a government minister issuing a statement on behalf of his department in may be necessary for that statement to be verifiable some time later.  In the UK public electronic some records need to be kept for 30 years.

This brings in the need to ensure that signatures are checked and re-protected on a regular basis as certificates are likely to have expired.  The revocation information applicable at the time of signature creation also needs to be maintained.