[dss] Use cases and requirements input

[Gregor Karlinger <gregor.karlinger@cio.gv.at>]

All,

in addition to the use cases already mentioned by other TC
members, please find below a single use case which
influences both signature creation and signature validation.

Furthermore, I have collected some basic requirements both
on signature creation and signature validation. The
requirements resulting from my use case are not included in
this collection.

1.  Use cases

1.1 Securing the transform chain

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.


Liebe Gruesse/Regards,
---------------------------------------------------------------
DI Gregor Karlinger

Chief Information Office
Bundesministerium f�r �ffentliche Leistung und Sport/
Federal Ministry for Public Services and Sports

Post/Mail: Wollzeile 1-3, 1010 Wien, Austria
Besuch/Visit: Wagramer Stra�e 4, 1220 Wien, Austria

mailto:gregor.karlinger@cio.gv.at          http://www.cio.gv.at
fon +43 1 50190 6163                    mobil +43 664 610 45 44
---------------------------------------------------------------