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:]
Sent: 13 January 2003
17:01
To: 'Nick Pope'; Carlisle Adams;
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.
