From f85a709bf64b186f4006466f310d841b65d50ade Mon Sep 17 00:00:00 2001 From: gregor Date: Wed, 24 Aug 2005 13:40:46 +0000 Subject: =?UTF-8?q?Bug=20232:=20=C3=84nderungen=20an=20der=20Schnittstelle?= =?UTF-8?q?=20(VerifyXMLSignatureResponse)=20in=20den=20Beispielen=20und?= =?UTF-8?q?=20im=20Tutorial=20nachgezogen.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit git-svn-id: https://joinup.ec.europa.eu/svn/moa-idspss/trunk@462 d688527b-c9ab-4aba-bd8d-4036d912da1d --- spss.handbook/handbook/usage/usage.html | 48 ++++++++++++++++++++++++++------- 1 file changed, 38 insertions(+), 10 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 d18bf1e7c..01f9c09fd 100644 --- a/spss.handbook/handbook/usage/usage.html +++ b/spss.handbook/handbook/usage/usage.html @@ -103,7 +103,7 @@ </FinalDataMetaInfo> </CreateTransformsInfo> </CreateTransformsInfoProfile> - Zu jedem Daten-Objekt können optional Transformationen (z.B. XPath, XSLT, Base64-Decodierung, etc.) angegeben werden. Werden - wie hier im Beispiel - keine Transformationen angegeben, so muss zumindest der MIME-Type der zu signierenden Daten spezifiziert werden.

+ Zu jedem Daten-Objekt können optional Transformationen (z.B. XPath, XSLT, Base64-Decodierung, etc.) angegeben werden. Werden - wie hier im Beispiel - keine Transformationen angegeben, so muss zumindest der MIME-Type der zu signierenden Daten spezifiziert werden.

Response

CreateXMLSignatureRequest.Simple.resp.xml ist eine typische Response des SS 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.

@@ -118,7 +118,7 @@ ... <dsig:Object Id="signed-data-1-1-1">Diese Daten werden signiert.</dsig:Object> </dsig:Signature>
</SignatureEnvironment>
</CreateXMLSignatureResponse> -

+

CreateXMLSignatureResponse enthält je erzeugter Signatur ein Element SignatureEnvironment (in diesem Fall genau ein Element). SignatureEnvironment enthält die von SS erzeugte XML-Signatur, die im obigen Request spezifiziert wurde. Man erkennt, dass die XML-Signatur genau ein Daten-Objekt unterzeichnet (ein dsig:Reference Element ist enthalten). Das unterzeichnete Datenobjekt ist in der Signaturstruktur selbst enthalten (enveloping), und zwar in einem dsig:Object Element.

2.1.1.2 Angabe der zu signierenden Daten

Request
@@ -780,11 +780,30 @@ O=A-Trust Ges. f

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

-  <HashInputData>
+  <HashInputData PartOf="SignedInfo">
     <Base64Content>PGRvYzp...hNTERvY3VtZW50Pg==</Base64Content>
   </HashInputData>
-

Wurde im Request - so wie in diesem Beispiel - das Element ReturnHashInputData angegeben, enthält die Response nach SignerInfo für jede dsig:Reference in dsig:SignedInfo der XML-Signatur ein Element HashInputData, wobei die Reihenfolge der HashInputData-Elemente der Reihenfolge der dsig:Reference Element in dsig:SignedInfo der XML-Signatur entspricht. Der Inhalt wird dabei stets mittels Base64Content in base64-kodierter Form geliefert.

+

Wurde im Request - so wie in diesem Beispiel - das Element ReturnHashInputData angegeben, enthält + die Response nach SignerInfo für jede dsig:Reference in dsig:SignedInfo der + XML-Signatur (bzw. auch für jede dsig:Reference aus einem dsig:Manifest, auf + das mittels des Attributs Type="http://www.w3.org/2000/09/xmldsig#Manifest" in einer dsig:Reference aus dsig:SignedInfo verwiesen + wird; solche Manifeste kommen aber in diesem Beispiel nicht vor) ein Element HashInputData.

+

Die Reihenfolge der HashInputData-Elemente + entspricht der Reihenfolge der dsig:Reference-Elemente in dsig:SignedInfo der + XML-Signatur (enthält die XML-Signatur auch dsig:Manifest-Elemente, auf die jeweils in einer dsig:Reference aus dsig:SignedInfo verwiesen wird, werden zuerst HashInputData-Elemente für alle dsig:Reference-Elemente + aus dsig:SignedInfo und anschließend HashInputData-Elemente für alle dsig:Reference-Elemente + aus den einzelnen dsig:Manifest-Elementen geliefert).

+

Das Attribut PartOf weist mit dem Wert SignedInfo darauf hin, dass die dsig:Reference, +für welche die Hasheingangsdaten gelten, Teil von dsig:SignedInfo ist (für eine dsig:Reference aus +einem dsig:SignedInfo würde der gelieferte Wert XMLDSIGManifest lauten; weiters +würde HashInputData in einem solchen Fall ein weiteres Attribut + + +ReferringSigReference aufweisen, dessen Wert die Nummer jener dsig:Reference aus dsig:SignedInfo als +positive Ganzzahl repräsentiert, die auf das beinhaltende dsig:Manifest verweist.).

+

Der Inhalt wird dabei stets mittels Base64Content in + base64-kodierter Form geliefert.

   <SignatureCheck>
     <Code>0</Code>
@@ -1032,7 +1051,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
 
+
 
Damit MOA SP die erste Teilprüfung durchführen kann, muss in SignatureManifestCheckParams je dsig:Reference Element in dsig:SignedInfo der XML-Signatur ein Element ReferenceInfo angeben. Ausgenommen sind dsig:Reference-Elemente, die auf ein Signaturmanifest (Attribut Type ist gesetzt und hat den Wert http://www.buergerkarte.at/specifications/Security-Layer/20020225#SignatureManifest), auf ein XMLDSIG-Manifest (Attribut Type ist gesetzt und hat den Wert http://www.w3.org/2000/09/xmldsig#Manifest) oder auf Signatureigenschaften (Attribut Type ist gesetzt und hat den Wert http://uri.etsi.org/01903/v1.1.1#SignedProperties) verweisen. 

 
Das Element ReferenceInfo enthält eine oder mehrere erlaubte Transformationsketten, die jeweils durch ein Element VerifyTransformsInfoProfile/dsig:Transforms repräsentiert werden. Im konkreten Beispiel werden für die einzige zu prüfende dsig:Reference zwei erlaubte Transformationsketten angegeben. Die Transformationen in der dsig:Reference müssen einer dieser beiden Ketten entsprechen; im konkreten Beispiel entsprechen sie der ersten. 

 
Nachdem die erste erlaubte Transformationskette eine XSLT-Transformation mit einem inkludierten Stylesheet enthält, muss MOA SP auch überprüfen, ob dieser inkludierte Stylesheet korrekt durch ein Signaturmanifest mitunterschrieben wurde. Nachdem wichtig ist, dass nicht irgendein beliebiger Stylesheet verwendet und mitunterschrieben wurde, sondern genau jener, den die Anwendung bei der Signaturerstellung vorgegeben hat, muss die Anwendung MOA SP mitteilen, welcher Stylesheet das sein muss. Die Anwendung verwendet dazu das Element VerifyTransformsInfoProfile/TransformParameter. Das Attribut TransformParameter/@URI enthält die Referenz auf den Stylesheet genau so, wie er im Stylesheet-Parameter der zu prüfenden Signatur verwendet wird (dsig:Transform/xsl:stylesheet/xsl:inlcude/@href). Für den Inhalt dieses Elements hat die Anwendung drei Möglichkeiten: 

@@ -1040,7 +1059,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
   
  • Die Anwendung lässt den Inhalt leer. Dies wird sie dann machen, wenn sie darauf vertrauen kann, dass die Auflösung der in TransformParameter/@URI angegebenen Referenz bei der Signaturprüfung zum gleichen Resultat führt wie seinerzeit beim Erstellen der Signatur (z.B. weil die Referenz auf einen Webserver unter Kontrolle der Anwendung zeigt);
    • 
   
  • Die Anwendung gibt im Element TransformParameter/Base64Content explizit den inkludierten Stylesheet an. MOA SP verwendet dann diesen Stylesheet, um den Hashwert der dsig:Reference im Signaturmanifest zu kontrollieren;
    • 
   
  • Die Anwendung gibt im Element TransformParameter/Hash den Hashwert des inkludierten Stylesheets an. MOA SP löst dann die Referenz in dsig:Transform/xsl:stylesheet/xsl:inlcude/@href auf und stellt sicher, dass der über das Auflösungsergebnis gebildete Hashwert jenem in TransformParameter/Hash entspricht. Diese Möglichkeit wird die Anwendung dann verwenden, wenn es sich um einen sehr umfangreichen Stylesheet handelt, der nicht im Request mitübertragen werden soll.
    • 
-  
+
 
    Response
    
 
    VerifyXMLSignatureRequest.SigManifest.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. 
    
 
    @@ -1051,20 +1070,20 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
 
    
 
    Die Response enthält zunächst in SignerInfo/dsig:X509Data Informationen über den Signator, die aus dem in der XML-Signatur enthaltenen Signatorzertifikat entnommen sind (siehe Einfaches Beispiel). 
    
 
    -  <ReferenceInputData>
+  <ReferenceInputData PartOf="SignedInfo">
     <XMLContent xml:space="preserve">
       <doc:Paragraph ParaId="Para2" xmlns:doc="urn:document" 
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">...</doc:Paragraph>
     </XMLContent>
   </ReferenceInputData>
-  <ReferenceInputData>
+  <ReferenceInputData PartOf="SignedInfo">
     <XMLContent xml:space="preserve">
       <dsig:Manifest Id="manifest-1-1" xmlns:doc="urn:document" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
         ...
       </dsig:Manifest>
     </XMLContent>
   </ReferenceInputData>
-  <ReferenceInputData>
+  <ReferenceInputData PartOf="SignedInfo">
     <XMLContent xml:space="preserve">
       <etsi:SignedProperties xmlns:doc="urn:document" 
         xmlns:etsi="http://uri.etsi.org/01903/v1.1.1#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
@@ -1073,7 +1092,16 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
     </XMLContent>
   </ReferenceInputData>
 
    
-
    Nachdem im Request spezifiziert wurde, dass in der Response die Referenzeingangsdaten für alle dsig:Reference-Elemente von dsig:SignedInfo der geprüften XML-Signatur übermittelt werden sollen, enthält die Response nach SignerInfo drei ReferenceInputData-Elemente. Das erste ReferenceInputData-Element enthält das zuvor besprochene doc:Paragraph Element, das zweite das Signaturmanifest, das dritte die Signatureigenschaften.
    
+
    Nachdem im Request spezifiziert wurde, dass in der Response die Referenzeingangsdaten für alle dsig:Reference-Elemente
+  von dsig:SignedInfo (bzw. auch  für jede dsig:Reference aus einem dsig:Manifest,
+  auf das mittels des Attributs Type="http://www.w3.org/2000/09/xmldsig#Manifest" in einer dsig:Reference  aus dsig:SignedInfo verwiesen
+  wird; solche Manifeste kommen aber in diesem Beispiel nicht vor) der geprüften
+  XML-Signatur übermittelt
+  werden sollen, enthält
+  die Response nach SignerInfo drei ReferenceInputData-Elemente. Das erste ReferenceInputData-Element
+  enthält das zuvor besprochene doc:Paragraph Element, das zweite das Signaturmanifest, das
+  dritte die Signatureigenschaften. Das Attribut PartOf jedes Elements weist mit dem Wert SignedInfo darauf hin,
+  dass die dsig:Reference, für welche die Referenzeingangsdaten gelten, Teil von dsig:SignedInfo ist. 
    
 
       <SignatureCheck>
     <Code>0</Code>
-- 
cgit v1.2.3