dss message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: [dss] Use cases
- From: Nick Pope <pope@secstan.com>
- To: OASIS DSS TC <dss@lists.oasis-open.org>
- Date: Wed, 05 Mar 2003 09:45:45 +0000
All,
On behalf of the use case sub-committee I submit the attached initial draft
of the uses cases to the DSS TC.
Nick Pope
Title: DSS Uses Cases Under Consideration
OASIS DSS Use Cases
Initial Use Cases - 2 March 2003
Corporate
Seal
SOAP
Signing
Identified
Requester
Individual
Signatures
Long
Term Corporate Signatures
Delegated
Signature Verification
Securing
the transform chain
Non-XML
Data Signing
eNotarization
Court
Filings
Client
Side Hashing
Time-stamping / Time-marking
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.
Top
of page
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.
Top
of page
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.
Top
of page
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.
Top
of page
Long Term Corporate Signatures (submitted
by Nick Pope)
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.
Top
of page
A client may receive a digital signature that has to be verified.
It does not have a trust relationship with the signer, is unable
to establish such a trust relationship or does not have the required
processing logic available (i.e. does not support the signature
algorithm used). Instead it has a single trust relationship with
a DSS gateway/server (e.g. it has a certificate or public key for
the DSS server/gateway using an algorithm it is familiar with).
It submits the signature to the DSS server, and optionally specifies
the policy under which the signature must be validated. The DSS
server has more complex processing capabilities and trust relationships
which it uses for signature validation. Following the validation
of the signature the DSS server returns a valid/invalid response
to the client. The response may include additional information such
as reason codes for failure, information on the policy used for
validation (i.e. a URL pointing to the policy or the policy itself)
and other information that may be useful to the client. The response
is signed by the DSS gateway/server and returned to the client.
The client can validate the signature of the DSS gateway using its
existing trust relationship.
Top
of page
If XML data
should be signed by a human, the following
problem can appear:
For machines,
the data to be signed by the human should be
the pure XML data, since this is the format which will be further
processed. On the contrary, for the human, signing pure XML structures
is not feasable since he must be able to comprehend what he is signing.
With XML signatures,
this problem can be solved by using the transforms concept. The
pure XML data is fed into a stylesheet transform, whicht transforms
it into - lets say - an HTML document. This HTML result can be shown
to the human and will be signed.
But this solution
only solves the signature creation. The signature validation is
still a problem, since the machine wants to further process the
pure XML data, but the human has signed the transformed data.
To overcome
this problem, special means have to be taken
during the signature creation: Not simply the resulting transform
data has to be signed, but also the pure XML data as well as the
way to get the transform data from the pure XML. Those additional
data items should be put in a dsig:Manifest, since it is not really
data signed by the human, but rather "technical data"
signed by the client software used by the human to create the signature.
2. Requirements
2.1 Signature
Creation
2.1.1 Creation
of Signature Attributes
In lots of situations,
signature attributes, such as those defined in the ETSI XAdES specification
(XML Advanced Electronic Sigatures), help to solve special requirements.
The requester should be able to tell the creation service which
attributes should be incorporated into the signature.
2.1.2 Allow
for configuration profiles
- Transforms
Often, the requester
has to deal with certain classes of signatures to be created. In
such cases, it would be helpful not to specify a potentially long
chain of transforms to be applied to a data item prior to digesting
it, but rather to identify a named profile.
2.2 Signature
Validation
2.2.1 Provide
data actually signed
For the requester
it is also important to know WHAT has been signed by the signature
to be validated. If the validation service does not provide this
information, the requester has to process the transforms specified
in the signature; but this is lots of work.
2.2.2 Support
ID References
XML signatures
allow for referring to data to be signed by using the ID mechanism
of XML 1.0. The validation service should support signatures using
ID references; but this must be considered in the design of the
validation request: it must be possible for the requester to tell
the service about schema/DTD validation information; otherwise the
service cannot know about which XML elements have defined ID attributes.
2.2.3 Allow
date in the past
The requester
should not only ask the validation service for
a validation result at the time of receiving the request,
but also to specify a certain point of time in the past.
2.2.4 Allow
for configuration profiles
- Trust
The requester
should be able to specify the trust settings (accepted root certificates,
accuracy of CRL checking, ...) to be applied by the service when
validating a signature.
Since this trust-related
information can be quite bulky, the requester should alternatively
identify this information by a named profile.
2.2.5 Provide
detailed result info
- About signer
The service
should provide information about the signer in a form that does
not mandate the requester to parse certificates etc., i. e. as an
XML structure (containing items like signer name, signer role, ...)
- On signature
references
In case of an
invalid signature, the service should provide information which
references of the signature have been verified correctly, and which
have lead to an error.
- On manifest
references
The same as
above applies to signature manifests, which are part of a signature.
2.3 Both
2.3.1 Support
dsig:Manifest
Signature manifests
should be supported both at signature creation and signature validation.
They are an important vehicle to sign "secondary" stuff,
such as the additional information in the "Securing the transform
chain" use case.
2.3.2 Signed
Data: Reference or direct provision
Data items to
be signed/validated should be either provided
to the service as a reference (URI), or directly as part of
the request. The latter is important for situations where
the data to be signed cannot be located by resolving a URI.
2.3.3 Support
all 3 Types of Signatures
All three signature
types defined in XML Signature
(enveloping, enveloped, detached) should be supported both
by the creation and the validation service. For each type
there are important use cases.
Top
of page
Specific instances:
. Validating
/ generating S/MIME signatures
. Validating / generating signed code (e.g., JAR files)
. Validating / generating proprietary formats
For example,
a simple email client that receives an S/MIME email can display
the MIME content but cannot handle the signature, so it packages
the mail up and submits it to the DSS service for validation. Similarly,
to send a signed email, the client generates a MIME message, submits
it to the service, with authorization, and receives an S/MIME response
that it can send out.
For the signed
code instance, developers within an organization may not have access
to signing keys; either because of organizational policy, or because
of the general code signing policy. When code development is complete,
the packaged code can be submitted, with authorization, to a signing
service which returns a signed code package.
Supporting extensiblity
for further proprietary formats
might help organizations transition from legacy internal
signed documents.
I'm not proposing
that we actually define the processing of
any specific non-XML format, just that we consider supporting signature
typing, data packaging and extensibility so that a DSS service could
support these types of signature. I think that presentation of the
data to be signed and the receipt of any resulting transformed data
should probably be considered alongside the XML signature reference
processing issue.
Should this
use case be accepted, it might suggest that
XMLDSIG be a signature type defined in its own document, alongside
a more agnostic DSS spec.
Top
of page
As promised,
attached
are extract pages, including diagrams, relative to requirements
for a use case of an eNotarization service from the Arizona Secretary
of State's Office. I have made inquiry and am informed and believe
that no IPR is claimed in the extract (which is part of a much larger
document that may not be directly relevant in its full form to our
purposes). The document was co-authored by Michael Tetherow and
Russ Savage of that office. Russ Savage emphasized in an email to
me for the benefit of this group that:
"1. the
process established allows for technology change -
there is an 'electronic notary seal/signature/datestamp' but what
that is will evolve as necessary
2. this is within the framework of state regulated notary services."
Top
of page
The Arizona
Court of Appeals Division Two uses a web server signature service
as part of its in-house application called e-filer. The production
version is html-based. An XML version is planned based upon the
LegalXML CourtFiling 1.1 and CourtDocument 1.1 recommended standards
(of judicial-related bodies). In a paper, Mohyeddin Abulaziz, Director
of Information Technology at the University of Arizona James E.
Rogers Law School and the Arizona Court of Appeals explains the
operation of e-filer, including authentication methods of filers,
filing procedures with screen shots, and signature technology. See
https://www.apltwo.ct.state.az.us/e-filer/abatechshow2002.pdf.
After emails
and a telephonic conversation with Mr. Abdulaziz, I am informed
and believed there is no copyright or other IPR in this document
either for him or any other individual or any institution or entity.
Top
of page
A client may
compute the hash on some document himself, then request the service
to sign/verify this hash. This would be more efficient that submitting
the whole document.
It would also
keep the document's contents hidden from the service. This
might be a disadvantage in use cases like Carlisle's "Corporate
Seal",
where the corporation would like to keep a record of what it has
signed. It might be an advantage in Carlisle's "Identified
Requester"
case, where the service is simply a private-key-holder for the client,
and
the less the client has to trust it the better.
To sign, a client
could send a ds:SignedInfo and receive back a
ds:Signature. To verify, the client would perform reference validation
himself, then forward the ds:Signature to the service for signature
validation.
Top
of page
Time-stamping / Time-marking (submitted
by Nick Pope)
The following identifies cases where some
form of time is required against a data item. This may be a
time-mark that makes use of other security services to bind the
time to the data (e.g. other DSS service or trusted audit log) or
as a time-stamp provided by an independent time-stamping authority
which exclusively provides time-related services.
1) Indicating the Signing Time
Where the a digital signature is to be
verified some time after the creation of the signature, it is
necessary to know the signing time in order to check the validity
of the certificate at the signing time. Firstly, if the
certificate used to support the certificate has been revoked
subsequent to the signing, it is necessary to know the signing
time to ensure that any subsequent revocation notification is not
applicable to that signature. In particular, this can be used to
avoid the signatory “repudiating” a signature by claiming that its
signing key had been compromised. Secondly, if the signed data is
to be used beyond the validity period of the certificate, it is
necessary to know that the signature was created during the
validity period of the certificate.
The signing time should be included in the
data to be signed to ensure that it cannot be changed once the
data has been signed.
The inclusion of signing time is generally
necessary for any case where the signed data is to be stored for
later use in a form that can be authenticated.
2) Validation near Creation Time
If signed data is validated close to the time
that the signature was created then the time can be included as
part of the validation function to give an independent indication
of the time near which the signature was created. This can be
used as a confirmation of the signing time (assuming that the
signing time and validation time are within a short time window)
or, in the case of signing time not being present, as a means of
indicating the approximate signing time.
As with signing time, this can be used to
ensure that the certificate used to support the signature is valid
at the time the signature was created.
3) Long Term Archival
If the validity of a digital signature is to
be assured for a long period it is necessary to apply further
integrity and time protection. This can be achieved by
periodically applying a digital signature and time-marking, or a
time-stamp over all the data required used to validate the
signature (certificates, revocation status information).
The time is required to prove when the
archival signature is applied so that the validity of the
certificate supporting the archival signature can be checked to be
valid at the time of archive, in the same way that the signing
time needs to be known in other forms of signatures (as described
above).
For very long the application of archival
signatures need to be repeated periodically, say immediately
following change of the archival signing certificate, including
the certificate and revocation status information applicable to
the previous archive signature.
4) Correlation With External Events
The time of an event is generally helpful for
placing that event in context with others events. For example, in
the case of betting on a horse race, it is important to know that
a bet has been placed before the start of the race.
Such events need not necessarily be
themselves be signed in which case time-stamping services would be
appropriate.
5) Time-limited Business transactions
For some business transactions, which may be
signed, there is a limited placed between one part of the business
transaction and the next. For example, when buying shares on the
Internet, there is a limited period between a share price being
offered and the purchase of the shares at the offered price.
Similarly, when sending out an invitation to tender, the time for
responses is commonly limited to a given time and date.
Such timing may be provided by a time-mark or
time-stamp applied to data before it is protected by other DSS
services.
6) Document Registration
For some documents it is important to prove
the time that a document is created is registered. For example,
when patenting an invention it is important to record the time the
patent was registered to counter claims of prior invention.
Such timing may be applied, for example,
using a time-stamping service or as an part of the DSS service
supporting the registration of documents.
7) Registered Mail
The requirement for timing documents may be
applied through registered mail. In this case the mail transfer
agent / mail relay may apply a time-stamp or time-mark with DSS
based signature as the mail as it passes between the sender and
recipient.
|
|
|
All contents are Copyright of their respective contributors.
All contributors claim no IPR for their content in accordance with Oasis
IPR regulations.
|
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]