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:]
Sent: 07 January 2003
21:22
To: ''
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.
