[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [dss] Use cases and requirements input
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 ---------------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC