RE: [dss] DSS Use Cases...

[Nick Pope <pope@secstan.com>]

Title: DSS Use Cases...

Hal,

 

Coming back on a couple of points that you raise:

 

I agree that we should avoid getting into the application semantics and the intent behind a signature.

 

However, the main point that I was addressing is for applications where there is some important legal intent behind the signature there is a need to more than just simple authentication.  There is a need to protect the signature against being repudiated and ensure that the signature can be checked some time after it has been created.

 

From the work done in ETSI this requires a time-stamp / time-marking around the time that a signature and information on the status of the relevant certificates at that time.

 

I wasn't disagreeing with the the need for corporate signatures being applied.  And that a signature service produce for a corporation may include additional information about individuals.  I am just a bit confused over the description of what is an individual signature, a corporate signature, a signature by a corporate initiated by an indivual, ....

 

I agree that we may not resolve the very long term signatures but it is worth noting as an requirement even if we do not have an immediate answer.

 

Nick

-----Original Message-----
From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
Sent: 13 January 2003 17:01
To: 'Nick Pope'; Carlisle Adams; dss@lists.oasis-open.org
Subject: RE: [dss] DSS Use Cases...

Comments inline.

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. 

[Hal Lockhart]

I disagree. As I understand it the use of a SOAP gateway, rather than an Application Server or some other approach is simply an implementation choice. The organization could change its implimentation at any point and it would have no implications for application semantics. (Rereading you comment, perhaps that is not what you intended. If so disregard this comment.)

You do raise an important point, which as far as I can tell has pretty much been avoided by the groups dealing with related standards. (Which perhaps means we should dodge it also.) That is the semantics of signatures. Dsig, WSS nor any other standard addresses this. I assume that this means the sematics are application specific and up to some mutual agreement between the parties.

I see no reason to believe the the semantics are dictated by where the signature appears. What can't the SOAP message be a purchase order for $4M? Why can't the corporate seal be on the Annual Report?

 

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

[Hal Lockhart] 

I think many corporations would want to use this type of scenario as an operation convenience or to better protect the signing keys. They would consider that some other type of authentication to the DSS, such as password/SSL was sufficient.  Afterall, companies issue checks and documents signed by the image of a handwritten signature all the time. It is up to them to have adequate safeguards to prevent misuse. Hell, I have worked at service bureaus that printed checks for other companies. For that matter, all the currency inb my wallet was "signed" by the Secretary of the Treasury.

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. 

[Hal Lockhart] I am not familiar with the term "hire purchase" 

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. 

[Hal Lockhart] This is a difficult general problem. I suggest we not try to solve it.