From fbb591eeda525fcadf796e9c2615981a32dd87f6 Mon Sep 17 00:00:00 2001 From: gregor Date: Thu, 24 Mar 2005 14:13:42 +0000 Subject: *** empty log message *** git-svn-id: https://joinup.ec.europa.eu/svn/moa-idspss/trunk@277 d688527b-c9ab-4aba-bd8d-4036d912da1d --- spss.handbook/handbook/usage/usage.html | 51 +++++++++++++++++++-------------- 1 file changed, 29 insertions(+), 22 deletions(-) (limited to 'spss.handbook/handbook/usage/usage.html') diff --git a/spss.handbook/handbook/usage/usage.html b/spss.handbook/handbook/usage/usage.html index f8f0e60d2..f6f40b872 100644 --- a/spss.handbook/handbook/usage/usage.html +++ b/spss.handbook/handbook/usage/usage.html @@ -8,11 +8,12 @@ - - + + + -

Open Source - für das E-Government

Open Source
+ für das E-Government

MOA: Serversignatur (SS) und Signaturprüfung (SP), V 1.2

Anwendung

@@ -48,12 +49,12 @@ -

Webservice-Clients -

Übersicht
Gemeinsamkeiten
Besonderheiten von HTTPSServerAuth
Besonderheiten von HTTPSClientAuth
Webservice-Clients +

@@ -430,7 +431,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph> </DataObjectInfo>

Für das erste zu signierende Datenobjekt werden die Referenz-Eingangsdaten mittels DataObject/@Reference referenziert, d. h. MOA SS löst die darin enthaltene URL auf, um zu den Daten zu gelangen. Es handelt sich dabei um einen base64 kodierten Text.

Unterschrieben werden soll nun aber nicht dieser base64 kodierte Text, sondern der entsprechend dekodierte Text. Dies lässt sich elegant durch die Angabe einer Base64 Decoding Transformation bewerkstelligen. Dazu wird als erstes Kindelement von CreateTransformsInfo ein dsig:Transforms Element im Request angegeben. Dieses dsig:Transforms Element nimmt ein oderer mehrere dsig:Transform Elemente auf, wobei jedes dsig:Transform Element für eine Transformation steht. In unserem Fall wird nur eine einzige Transformation benötigt; die Angabe, um welche Transformation es sich handelt, wird durch das Attribut dsig:Transform/@Algorithm angegeben. Für die Base64 Decoding Transformation muss der Wert auf http://www.w3.org/2000/09/xmldsig#base64 gesetzt werden. Sie ist eine parameterlose Transformation, d. h. dsig:Transform hat keine Kindelemente.

Der Mime-Type der zu signierenden Daten wird als text/plain angegeben, da ja tatsächlich nach der durchgeführten Transformation dekodierter Text vorliegt, über den dann der Hashwert berechnet wird.

     <DataObjectInfo Structure="detached">
@@ -473,7 +474,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
     </DataObjectInfo>

Für das zweite zu signierende Datenobjekt werden die Referenz-Eingangsdaten wiederum mittels DataObject/@Reference referenziert, d. h. MOA SS löst die darin enthaltene URL auf, um zu den Daten zu gelangen. Es handelt sich dabei um ein XML-Dokument.

Zunächst soll von diesem XML-Dokument jedoch ein Teil weggeschnitten werden, da er nicht mitsigniert werden soll. Für diesen Zweck bietet sich die XPath Filter 2 Transformation an. Das Attribut dsig:Transform/@Algorithm ist dazu auf den Wert http://www.w3.org/2002/06/xmldsig-filter2 zu setzen. Diese Transformation benötigt weiters Transformationsparameter. Diese werden als Kindelement xp2:XPath in dsig:Transform angegeben. Das Attribut Filter selektiert den Filtermodus; für das Bespiel wird den Modus subtract benötigt, da ein Teil weggefiltert werden soll. Der Textinhalt von xp2:XPath ist ein XPath-Ausdruck, der den Wurzelknoten jenes Teilbaums selektiert, der weggefiltert werden soll. Für das Beispiel soll das zweite Paragraph Element des XML-Dokuments weggefiltert werden. Beachten Sie, dass das im XPath-Ausdruck verwendete Namespace-Prefix doc im Kontext des xp2:XPath Elements deklariert sein muss.

Zunächst soll von diesem XML-Dokument jedoch ein Teil weggeschnitten werden, da er nicht mitsigniert werden soll. Für diesen Zweck bietet sich die XPath Filter 2 Transformation an. Das Attribut dsig:Transform/@Algorithm ist dazu auf den Wert http://www.w3.org/2002/06/xmldsig-filter2 zu setzen. Diese Transformation benötigt weiters Transformationsparameter. Diese werden als Kindelement xp2:XPath in dsig:Transform angegeben. Das Attribut Filter selektiert den Filtermodus; für das Bespiel wird den Modus subtract benötigt, da ein Teil weggefiltert werden soll. Der Textinhalt von xp2:XPath ist ein XPath-Ausdruck, der den Wurzelknoten jenes Teilbaums selektiert, der weggefiltert werden soll. Für das Beispiel soll das zweite doc:Paragraph Element des XML-Dokuments weggefiltert werden. Beachten Sie, dass das im XPath-Ausdruck verwendete Namespace-Prefix doc im Kontext des xp2:XPath Elements deklariert sein muss.

Als nächstes soll nun das XML-Dokument mit Hilfe eines Stylesheets in ein XHTML-Dokument übergeführt werden. Dazu kann die XSLT Transformation verwendet werden. Das Attribut dsig:Transform/@Algorithm ist dazu auf den Wert http://www.w3.org/TR/1999/REC-xslt-19991116 zu setzen. Auch diese Transformation benötigt Transformationsparameter: Als Kindelement von dsig:Transform wird jener Stylesheet angegeben, mit dem die Stylesheet-Transformation ausgeführt werden soll.

Abschließend soll, wie in der Spezifikation der XSLT-Transformation empfohlen, eine Kanonisierungstransformation angewendet werden. Damit können Unterschiede im Output unterschiedlicher XSLT-Engines, wie sie in der Praxis vorkommen, abgefangen werden. Beachten Sie, dass als Voraussetzung dazu die Output-Methode im Stylesheet auf xml festgelegt werden muss (<xsl:output method="xml">), denn nur XML-Output kann anschließend kanonisiert werden. Das Attribut dsig:Transform/@Algorithm ist für die Canonical XML Transformation auf den Wert http://www.w3.org/TR/2001/REC-xml-c14n-20010315 zu setzen. Die Transformation benötigt keine Transformationsparameter.

Das Ergebnis der drei hintereinandergeschalteten Transformationen, welches der Hashwert-Berechnung zufließt, finden Sie hier.

@@ -525,7 +526,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>

Die zweite dsig:Reference wurde auf Grund des zweiten DataObjectInfo im Request erstellt. Man erkennt auch hier gut, dass die URL auf die Referenz-Eingangsdaten (Wert des Attributs dsig:Reference/@URI) aus DataObject/@Reference übernommen und die drei Transformationen wie im Request angegeben eingefügt wurden.

2.1.1.4 Ergänzungsobjekte

Request

Dieses Beispiel (CreateXMLSignatureRequest.Supplements.xml) stellt die Verwendung von Ergänzungsobjekten vor. Ein Ergänzungsobjekt betrifft entweder ein zu signierendes Datum (Zusammenhang mit einem DataObject) oder jenes Dokument, in das eine zu erzeugende Signatur eingefügt werden soll (Zusammenhang mit CreateSignatureEnvironment). Es muss dann angegeben werden, wenn in einem zu signierenden Datum bzw. im Einfügedokument auf Daten per Referenz verwiesen wird, diese referenzierten Daten aber von MOA SS nicht aufgelöst werden können. Das Ergänzungsobjekt enthält dann genau diese Daten die nicht von MOA SS aufgelöst werden können.

 <CreateXMLSignatureRequest 
   xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" 
@@ -623,7 +624,7 @@ O=A-Trust Ges. f
   </SignerInfo>

Die Response enthält zunächst in SignerInfo/dsig:X509Data Informationen über den Signator, die aus dem in der CMS-Signatur enthaltenen Signatorzertifikat entnommen sind.

dsig:X509SubjectName ist immer vorhanden und enthält den Namen des Signators. dsig:X509IssuerSerial ist ebenfalls immer vorhanden und enthält den Namen des Austellers des Signatorzertifikats (dsig:X509IssuerName) sowie die Seriennummer des Zertifikats (dsig:X509SerialNumber). Auch dsig:X509Certificate ist ist immer vorhanden und enthält das Signatorzertifikat in base64 kodierter Form.

dsig:X509SubjectName ist immer vorhanden und enthält den Namen des Signators. dsig:X509IssuerSerial ist ebenfalls immer vorhanden und enthält den Namen des Austellers des Signatorzertifikats (dsig:X509IssuerName) sowie die Seriennummer des Zertifikats (dsig:X509SerialNumber). Auch dsig:X509Certificate ist immer vorhanden und enthält das Signatorzertifikat in base64 kodierter Form.

Optional vorhanden ist das inhaltslose Element QualifiedCertificate, und zwar dann, wenn es sich beim Signatorzertifikat um ein qualifiziertes Zertifikat handelt. Ebenfalls optional vorhanden ist schließlich - in diesem Beispiel nicht ersichtlich - das Element PublicAuthority, und zwar dann, wenn das Signatorzertifikat die österreichspezifische Zertifikatserweiterung Verwaltungseigenschaft aufweist. Ist in dieser Zertifikatserweiterung das Verwaltungskennzeichen mitkodiert, wird dieses Kennzeichen als Textinhalt des optionalen Elements PublicAuthority/Code geliefert.

   <SignatureCheck>
@@ -639,7 +640,7 @@ O=A-Trust Ges. f
 Abschließend enthält die Response mit CertificateCheck/Code das Resultat der Prüfung des Signatorzertifikats. Zunächst prüft MOA SP, ob ausgehend vom Signatorzertifikat eine Zertifikatskette zu einem im zugehörigen Vertrauensprofil konfigurierten sog. Trust Anchor gebildet werden kann. Gelingt dies, wird die Gültigkeit jedes Zertifikats dieser Kette überprüft. In unserem Beispiel enthält Code den Wert 1, d. h. MOA SP konnte die oben erläuterte Zertifikatskette nicht bilden. Für eine Übersicht der möglichen Kodes siehe Security-Layer 1.2.
 2.1.2.2 Erweitertes Beispiel
 Request
-Dieses erweiterte Beispiel zur Prüfung einer CMS-Signatur (VerifyCMSSignatureRequest.Extended.xml) demonstriert die Prüfung mehrerer Signatoren einer CMS-Signatur, die Angabe des Prüfzeitpunkts sowie die Prüfung einer Detached Signature, d. h. einer Signatur in der die signierten Daten nicht enthalten sind und daher extra angegeben werden müssen. 
+Dieses erweiterte Beispiel zur Prüfung einer CMS-Signatur (VerifyCMSSignatureRequest.Extended.xml) demonstriert die Prüfung mehrerer Signatoren einer CMS-Signatur, die Angabe des Prüfzeitpunkts sowie die Prüfung einer Detached Signature, d. h. einer Signatur, in der die signierten Daten nicht enthalten sind und daher extra angegeben werden müssen. 
  <VerifyCMSSignatureRequest 
   xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" 
@@ -685,7 +686,7 @@ O=A-Trust Ges. f
       </XMLContent>
     </VerifySignatureEnvironment>
 
-Das Element VerifySignatureEnvironment enthält jenes XML-Dokument, das die zu prüfende XML-Signatur enthält. Auch hier stehen eine Reihe von Möglichkeiten zur Verfügung, dieses XML-Dokument anzugeben. Im Beispiel wurde das Element XMLContent verwendet; alternativ stehen die Elemente Base64Content und LocRefContent bzw. gleichwertig zu LocRefContent das Attribut Reference zur Verfügung.
+Das Element VerifySignatureEnvironment enthält jenes XML-Dokument, das die zu prüfende XML-Signatur enthält. Auch hier stehen eine Reihe von Möglichkeiten zur Verfügung, dieses XML-Dokument anzugeben. Im Beispiel wurde das Element XMLContent verwendet; alternativ stehen die Elemente Base64Content und LocRefContent bzw. gleichwertig zu LocRefContent das Attribut Reference zur Verfügung.
 Im konkreten Beispiel enthält das angegebene XML-Dokument direkt als Root-Element die zu prüfende Signatur (dsig:Signature). Es handelt sich dabei um eine Enveloping Signature, d. h. die signierten Daten sind in einem dsig:Object als Teil der XML-Struktur der Signatur kodiert. Tatsächlich signiert ist hier die Zeichenkette Diese Daten werden signiert.
      <VerifySignatureLocation
@@ -756,7 +757,7 @@ O=A-Trust Ges. f
   <TrustProfileID>Test-Signaturdienste</TrustProfileID>
 </VerifyXMLSignatureRequest>
 
-Durch Angabe des optionalen, leeren Elements Return HashInputData wird MOA SP angewiesen, im Response jene Daten zurückzuliefern, die von der Signatur abgedeckt sind, d. h. tatsächlich signiert wurden (siehe unten). Diese Information ist für die MOA SP verwendende Anwendung essentiell, da sie wissen muss, ob tatsächlich die von ihr geforderten Daten signiert wurden. Wird HashInputData im Request nicht angegeben, muss die Anwendung selbst die Signatur analysieren, um diese Information zu erhalten. 
+Durch Angabe des optionalen, leeren Elements ReturnHashInputData wird MOA SP angewiesen, im Response jene Daten zurückzuliefern, die von der Signatur abgedeckt sind, d. h. tatsächlich signiert wurden (siehe unten). Diese Information ist für die MOA SP verwendende Anwendung essentiell, da sie wissen muss, ob tatsächlich die von ihr geforderten Daten signiert wurden. Wird HashInputData im Request nicht angegeben, muss die Anwendung selbst die Signatur analysieren, um diese Information zu erhalten. 
 Response
 VerifyXMLSignatureRequest.Enveloped.resp.xml ist eine typische Response des SP Webservices auf den obigen Request. Sein Aufbau wird nachfolgend analysiert. Bitte beachten Sie, dass die dargestellte Response zur bessernen Lesbarkeit eingerückt und gekürzt wurde.
 @@ -786,7 +787,7 @@ O=A-Trust Ges. f
 Die Elemente SignatureCheck und CertificateCheck enthalten die Resultate der kryptographischen Prüfung der Signatur sowie der Zertifikatsprüfung (siehe Einfaches Beispiel).
 2.1.3.3 Prüfung eines XMLDSIG-Manifests 
 Request
-Dieses  Beispiel zur Prüfung einer XML-Signatur (VerifyXMLSignatureRequest.XMLDSigManifest.xml) demonstriert die Prüfung eines in der zu XML-Signatur vorhandenden Manifests nach XMLDSig. Bitte beachten Sie, dass  der  dargestellte Request zur bessernen Lesbarkeit eingerückt und gekürzt wurde.
+Dieses  Beispiel zur Prüfung einer XML-Signatur (VerifyXMLSignatureRequest.XMLDSigManifest.xml) demonstriert die Prüfung eines in der  XML-Signatur vorhandenden Manifests nach XMLDSig. Bitte beachten Sie, dass  der  dargestellte Request zur bessernen Lesbarkeit eingerückt und gekürzt wurde.
  <VerifyXMLSignatureRequest
   xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" 
@@ -861,7 +862,7 @@ O=A-Trust Ges. f
 
 Das Element CertificateCheck enthält das Resultat der Zertifikatsprüfung (siehe Einfaches Beispiel).
 2.3.1.4 Ergänzungsobjekte 
-Dieses Beispiel zur Prüfung einer XML-Signatur (VerifyXMLSignatureRequest.Supplements.xml) demonstriert die Verwendung von Ergänzungsobjekten. Ein Ergänzungsobjekt betrifft entweder ein signiertes Datum (Zusammenhang mit einem dsig:Reference der XML-Signatur) oder jenes Dokument, in dem sich die zu prüfende XML-Signatur befindet (Zusammenhang mit VerifySignatureEnvironment). Es muss dann angegeben werden, wenn auf ein signiertes Datum bzw. in einem signierten Datum bzw. in dem die XML-Signatur enthaltende XML-Dokument auf weitere Daten  per Referenz verwiesen wird, diese Referenz aber von MOA SP nicht aufgelöst werden kann. Das Ergänzungsobjekt enthält dann genau diese Daten die nicht von MOA SS aufgelöst werden können.
+Dieses Beispiel zur Prüfung einer XML-Signatur (VerifyXMLSignatureRequest.Supplements.xml) demonstriert die Verwendung von Ergänzungsobjekten. Ein Ergänzungsobjekt betrifft entweder ein signiertes Datum (Zusammenhang mit einem dsig:Reference der XML-Signatur) oder jenes Dokument, in dem sich die zu prüfende XML-Signatur befindet (Zusammenhang mit VerifySignatureEnvironment). Es muss dann angegeben werden, wenn auf ein signiertes Datum bzw. in einem signierten Datum bzw. in dem die XML-Signatur enthaltenden XML-Dokument auf weitere Daten  per Referenz verwiesen wird, diese Referenz aber von MOA SP nicht aufgelöst werden kann. Das Ergänzungsobjekt enthält dann genau diese Daten die nicht von MOA SS aufgelöst werden können.
 Bitte beachten Sie, dass der dargestellte Request zur bessernen Lesbarkeit eingerückt und gekürzt wurde.
  <VerifyXMLSignatureRequest xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#">
@@ -910,7 +911,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
     </Content>
   </SupplementProfile>
 
-Das erste Element SupplementProfile enthält nun das Ergänzungsobjekt für den oben beschriebenen inkludierten Stylesheet. Content/@Reference enthält die Referenz genau so, wie sie oben im Attribut xsl:stylesheet/@href angegeben wurde. Im Inhalt von Content werden entweder explizit jene Daten angegeben, die von MOA statt dem Auflösen der Referenz verwendet werden sollen (Base64Content oder - wie im konkreten Beispiel -  XMLContent), oder aber es wird mit LocRefContent eine auflösbare Referenz für diese Daten an MOA SP übergeben. 
+Das erste Element SupplementProfile enthält nun das Ergänzungsobjekt für den oben beschriebenen inkludierten Stylesheet. Content/@Reference enthält die Referenz genau so, wie sie oben im Attribut xsl:stylesheet/@href angegeben wurde. Im Inhalt von Content werden entweder explizit jene Daten angegeben, die von MOA statt des Auflösens der Referenz verwendet werden sollen (Base64Content oder XMLContent), oder aber es wird  - wie im konkreten Beispiel -  mit LocRefContent eine auflösbare Referenz für diese Daten an MOA SP übergeben. 
    <SupplementProfile>
     <Content Reference="urn:XMLDocument.xsd">
@@ -925,7 +926,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
   <TrustProfileID>Test-Signaturdienste</TrustProfileID>
 </VerifyXMLSignatureRequest>
 
-Das zweite Element SupplementProfile enthält analog das Ergänzungsobjekt für das oben beschriebene XML-Schema. Content/@Reference enthält die Referenz genau so, wie sie oben im Attribut xsi:schemaLocation angegeben wurde. 
+Das zweite Element SupplementProfile enthält analog das Ergänzungsobjekt für das oben beschriebene XML-Schema. Content/@Reference enthält die Referenz genau so, wie sie oben im Attribut xsi:schemaLocation angegeben wurde. 
 Response
 VerifyXMLSignatureRequest.Supplements.resp.xml ist eine typische Response des SP Webservices auf den obigen Request. Er wird an dieser Stelle nicht näher analysiert, da er keine für das Thema des Beispiels relevanten Besonderheiten aufweist.
 2.1.3.5 Signatur-Manifest des Security-Layers 
@@ -1082,6 +1083,12 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
 </VerifyXMLSignatureResponse>
 
 Das Element CertificateCheck enthält das Resultat der Zertifikatsprüfung (siehe Einfaches Beispiel).
- 
+2.2 Webservice-Clients
+2.2.1 Übersicht
+2.2.2 Gemeinsamkeiten
+2.2.3 Besonderheiten von HTTPSServerAuth
+debug property 
+2.2.4 Besonderheiten von HTTPSClientAuth 
+debug property
 
 
-- 
cgit v1.2.3