From 28b140426304acf5342e9ab5a1a3a5656fa280b9 Mon Sep 17 00:00:00 2001 From: Thomas Lenz Date: Thu, 16 Feb 2017 11:55:53 +0100 Subject: update handbook --- moaSig/handbook/handbook/usage/usage.html | 243 +++++++++++++++++++++++++++++- 1 file changed, 240 insertions(+), 3 deletions(-) diff --git a/moaSig/handbook/handbook/usage/usage.html b/moaSig/handbook/handbook/usage/usage.html index ef370d4..c382e18 100644 --- a/moaSig/handbook/handbook/usage/usage.html +++ b/moaSig/handbook/handbook/usage/usage.html @@ -53,8 +53,10 @@
  • Ergänzungsobjekte
  • Signatur-Manifest des Security-Layers
  • Prüfung gegen Trustprofil mit TSL Unterstützung
    • - + +
  • Prüfung von PAdES Signaturen
    • +
  • Prüfung von ASiC Signaturen
  • Webservice-Clients @@ -722,6 +724,7 @@ O=A-Trust Ges. für Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT< xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#" Signatories="1"> <DateTime>2004-08-17T08:00:00+02:00</DateTime> + <ExtendedValidation>false</ExtendedValidation> <CMSSignature>MIIHiwYJKoZI...kfiwsvqSk48lou</CMSSignature> <DataObject> <Content> @@ -732,7 +735,7 @@ O=A-Trust Ges. für Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT< </VerifyCMSSignatureRequest>

    Liegt eine zu prüfende CMS-Signatur vor, die von mehreren Unterzeichnenden signiert worden ist, kann das Attribut VerifyCMSSignatureRequest/@Signatories verwendet werden, um jene Unterzeichnenden auszuwählen, deren Unterschriften von MOA SP geprüft werden sollen. Der Default-Wert für dieses optionale Attribut ist 1. Soll nicht die Unterschrift allein des ersten Unterzeichnenden geprüft werden, muss das Attribut explizit angegeben werden. Es enthält dann eine oder mehrere Ganzzahlwerte, getrennt durch Leerzeichen. Jede Ganzzahl bezeichnet einen Unterzeichnenden, wobei die Reihenfolge der Auflistung der Unterzeichner in der CMS-Signatur entspricht. Der Wert "1 3" würde beispielsweise aussagen, dass MOA SP die Unterschrift des ersten sowie des dritten Unterzeichnenden prüfen soll.

    -

    Mit dem optionalen Element DateTime kann der Zeitpunkt der Signaturprüfung explizit vorgegeben werden. Inhalt dieses Elements ist die Angabe von Datum und Uhrzeit entsprechend dem XML-Schema Datentyp dateTime. Enthält der angegebene Zeitpunkt keinen Zeitzonen-Offset zur UTC, wird der Zeitpunkt als lokale Zeit des Servers interpretiert, auf dem MOA SP läuft. Wird DateTime nicht angegeben, versucht MOA SP, den Zeitpunkt der Signaturerstellung aus der Signatur zu ermitteln (anhand des Signaturattributs SigningTime). Enthält die Signatur keinen Zeitpunkt der Signaturerstellung, verwendet MOA SP die aktuelle Systemzeit des Servers, auf dem es läuft.

    +

    Mit dem optionalen Element DateTime kann der Zeitpunkt der Signaturprüfung explizit vorgegeben werden. Inhalt dieses Elements ist die Angabe von Datum und Uhrzeit entsprechend dem XML-Schema Datentyp dateTime. Enthält der angegebene Zeitpunkt keinen Zeitzonen-Offset zur UTC, wird der Zeitpunkt als lokale Zeit des Servers interpretiert, auf dem MOA SP läuft. Wird DateTime nicht angegeben, versucht MOA SP, den Zeitpunkt der Signaturerstellung aus der Signatur zu ermitteln (anhand des Signaturattributs SigningTime). Enthält die Signatur keinen Zeitpunkt der Signaturerstellung, verwendet MOA SP die aktuelle Systemzeit des Servers, auf dem es läuft. Das optionale Element ExtendedValidation kann dafür genutzt werden den Formvalidierungsmodus für CAdES Signaturen zu aktivieren. Diesem Fall enthält die Response spezifische Informationen bezüglich des CAdES Profils der Signatur und erweiterte Zertifikatsprüfungsergebnisse. Detailinformationen zu den erweiterten Ergebnissen finden Sie im Abschnitt 2.1.4.2, da diese für alle unterstützen Signaturformate identisch sind.

    Das optionale Element DataObject muss dann angegeben werden, wenn eine Detached Signature geprüft werden soll, d. h. wenn in der CMS-Signatur die signierten Daten nicht mitkodiert sind. In DataObject/Content/Base64Content sind in einem solchen Fall diese Daten in base64 kodierter Form bereit zu stellen.

    Response

    VerifyCMSSignatureRequest.Extended.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.

    @@ -876,10 +879,202 @@ positive Ganzzahl repräsentiert, die auf das beinhaltende dsig:Manife <CertificateCheck> <Code>0</Code> </CertificateCheck> - <FormCheckResult>
    <Code>1</Code>
    <Name>LTA</Name>
    </FormCheckResult>
    <FormCheckResult>
    <Code>1</Code>
    <Name>LT</Name>
    </FormCheckResult>
    <FormCheckResult>
    <Code>1</Code>
    <Name>T</Name>
    </FormCheckResult>
    <FormCheckResult>
    <Code>1</Code>
    <Name>B</Name>
    </FormCheckResult>
    <ExtendedCertificateCheck>
    <Major>
    <Code>2</Code>
    Name>INDETERMINATE</Name>
    </Major>
    <Minor>
    <Code>13</Code>
    <Name/>
    </Minor>
    </ExtendedCertificateCheck> + <FormCheckResult>
    <Code>1</Code>
    <Name>B-LTA</Name>
    </FormCheckResult>
    <FormCheckResult>
    <Code>1</Code>
    <Name>B-LT</Name>
    </FormCheckResult>
    <FormCheckResult>
    <Code>1</Code>
    <Name>B-T</Name>
    </FormCheckResult>
    <FormCheckResult>
    <Code>0</Code>
    <Name>B-B</Name>
    </FormCheckResult>
    <ExtendedCertificateCheck>
    <Major>
    <Code>0</Code>
    <Name>VALID</Name>
    </Major>
    <Minor>
    <Code>23</Code>
    <Name>SUCCESS</Name>
    </Minor>
    </ExtendedCertificateCheck> </VerifyXMLSignatureResponse>

    Die Elemente SignatureCheck und CertificateCheck enthalten die Resultate der kryptographischen Prüfung der Signatur sowie der Zertifikatsprüfung (siehe Einfaches Beispiel). Die Elemente FormCheckResult enthalten die Ergebnisse zu den einzelnen Formvalidierungen und das Element ExtendedCertificateCheck enthalten die Ergebnisse zum erweiterten Zertifikatscheck.

    +

    Das Element FormCheckResult kann mehrfach vorkommen und beinhaltet die Validierungsergebnisse der folgenden erweiterten Signaturformate:

    + + + + + + + + + + + + + + + + + + + + + +
    NameBeschreibung
    B-BB- Level Conformance
    B-TT- Level Conformance.
    B-LTLT- Level Conformance
    B-LTVLTA- Level Conformance
    +

     

    +

    Das Prüfergebnis des jeweiligen Levels wird in Form eines Code Elements zurückgegeben. Hierbei sind folgende Statuscodes möglich:

    + + + + +
    + + + + + + + + + + + + + + + + + + + + +
    CodeBeschreibung
    0Die Signatur entspricht der im Element Name angegebenen Form.
    1Die Signatur entspricht nicht der im Element Name angegebenen Form.
    2Die Signatur beinhaltet nicht alle erforderlichen Eigenschaften der im Element Name angegebenen Form.
    3Die Formvalidierung wurde wegen eines Fehlers abgebrochen
    +

     

    +

    Details zu den einzelen Levels finden Sie in den entsprechenden Spezifikation:

    + +

     

    +

    Das Element ExtendedCertificateCheck kommt einfach vor und beinhaltet die Validierungsergebnisse des erweiterten Zertifikatschecks. Hierbei sind die Validierungsergebnisse in ein Major und in ein Minor Ergebnis aufgetrennt wobei diese als gleichnamige XML Elemente abgebildet sind. Jedes dieser XML Elemnte beinhalet einen ResultCode als Element Code und ein eine optionale textuelle Beschreibung des Codes im Element Name.

    +

    Als Major Result sind folgende Codes möglich:

    + + + + + + + + + + + + + + + + + + + + + +
    CodeNameBeschreibung
    0VALIDZertifikatsprüfung erfolgreich
    1INVALIDZertifikatsprüfung nicht erfolgreich
    2INDETERMINATEZertifikatsstatus nicht ermittelbar
    +

     

    +

    Als Minor Result sind folgende Codes möglich:

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    CodeBeschreibung
    0Ein Zertifikat ist als revokiert gekennzeichnet
    1Hash Fehler
    2Signaturüberprüfung fehlgeschlagen
    3Richtlinien zur Signaturerstellung
    4Richtlinien zur Zertifikatskettenbildung
    5Richtlinien zu kryptografischen Verfahren
    6Ein Zertifikat ist abgelaufen
    7Ein Zertifikat ist noch nicht gültig
    8Formatfehler
    9Policy konnte nicht verarbeitet werden
    10Unbekannter Commitment Type
    11Timestamp Fehler
    12Allgemeiner Fehler bei der Validierung
    13Kein Signaturzertifikat gefunden
    14Keine Zertifikatskette gefunden
    15Keine Policy gefunden
    16Revokiert und kein Proof of Existence (POE)
    17CA Revokiert und kein Proof of Existence (POE)
    18Proof of Existence (POE) ungültig
    19Krypografische Anforderungen an Proof of Existence (POE)
    20Proof of Existence (POE) nicht vorhanden
    21Die Prüfung war zum aktuellen Zeitpunkt nicht erfolgreich. Eine erneute Prüfung zu einen späteren Zeitpunkt könnte jedoch ein anderes Ergebnis liefern.
    22SignedData Element nicht gefunden
    23Erfolgreich
    24Fehler
    +

     

    2.1.4.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 XML-Signatur vorhandenden Manifests nach XMLDSig. Bitte beachten Sie, dass der dargestellte Request zur bessernen Lesbarkeit eingerückt und gekürzt wurde.

    @@ -1248,6 +1443,48 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph> </CertificateCheck>

    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 0, d. h. MOA SP konnte die Kette bilden, und alle Zertifikate der Kette sind gültig. Für eine Übersicht der möglichen Kodes siehe Security-Layer Spezifikation.

    +

    2.1.5 Prüfung einer PAdES-Signatur

    +

    Request

    +

    Dieses Beispiel ist ein einfacher Request zur Prüfung einer PAdES-Signatur. Sein Aufbau wird nachfolgend analysiert. Bitte beachten Sie, dass der nachfolgende Ausschnitt aus dem Request aus Gründen der Übersichtlichkeit gekürzt wurde.

    +
    +<VerifyPDFSignatureRequest
+  xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#">
+	<DateTime>2004-08-18T17:00:00+02:00</DateTime>
    	<ExtendedValidation>true</ExtendedValidation>
+  <PDFSignature>MIIHsAYJKo...4sLL6kpOPJaLg==</PDFSignature>
+  <TrustProfileID>Test-Signaturdienste</TrustProfileID>
+</VerifyPDFSignatureRequest>
+
    +

    Mit dem optionalen Element DateTime kann der Zeitpunkt der Signaturprüfung explizit vorgegeben werden. Inhalt dieses Elements ist die Angabe von Datum und Uhrzeit entsprechend dem XML-Schema Datentyp dateTime. Enthält der angegebene Zeitpunkt keinen Zeitzonen-Offset zur UTC, wird der Zeitpunkt als lokale Zeit des Servers interpretiert, auf dem MOA SP läuft. Wird DateTime nicht angegeben, versucht MOA SP, den Zeitpunkt der Signaturerstellung aus der Signatur zu ermitteln (anhand des Signaturattributs SigningTime). Enthält die Signatur keinen Zeitpunkt der Signaturerstellung, verwendet MOA SP die aktuelle Systemzeit des Servers, auf dem es läuft. Das optionale Element ExtendedValidation kann dafür genutzt werden den Formvalidierungsmodus für PAdES Signaturen zu aktivieren. Diesem Fall enthält die Response spezifische Informationen bezüglich des PAdES Profils der Signatur und erweiterte Zertifikatsprüfungsergebnisse. Detailinformationen zu den erweiterten Ergebnissen finden Sie im Abschnitt 2.1.4.2, da diese für alle unterstützen Signaturformate identisch sind.

    +

    Der Request enthält im Element PDFSignature die zu prüfende PAdES-Signatur, und zwar in base64 kodierter Form.

    +

    Abschließend enthält der Request in TrustProfileID die Angabe des Vertrauensprofils, gegen das die Vertrauensprüfung des Zertifikats durchgeführt werden soll. Ein Vertrauensprofil mit dem angegebenen Namen muss in der für die Signaturprüfung verwendeten Instanz von MOA SP eingerichtet sein.

    +
    Response
    +

    Nachstehend 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.

    +
    +<VerifyPDFSignatureResponse
+  xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#"
+  xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
+	<SignatureResult>
+	  <SignerInfo>
+  	  <dsig:X509Data>
+  	    <dsig:X509SubjectName>serialNumber=615536615920,givenName=Gregor,SN=Karlinger,
+CN=Gregor Karlinger,C=AT</dsig:X509SubjectName>
+	      <dsig:X509IssuerSerial>
+	        <dsig:X509IssuerName>CN=TrustSignTest-Sig-01,OU=TrustSignTest-Sig-01,
+O=A-Trust Ges. für Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT</dsig:X509IssuerName>
+	        <dsig:X509SerialNumber>2892</dsig:X509SerialNumber>
+	      </dsig:X509IssuerSerial>
+	      <dsig:X509Certificate>...</dsig:X509Certificate>
+	      <QualifiedCertificate/>
+	    </dsig:X509Data>
+	  </SignerInfo>
+	  <SigningTime>2017-01-27T13:56:26Z</SigningTime>
        <SignatureCheck>
        	<Code>0</Code>
        </SignatureCheck>
        <CertificateCheck>
    		...
+	</SignatureResult>
+	<SignatureResult>
+		...
+
    +

    Die Response beinhaltet als erstes kein, ein oder mehrere SignatureResult Elemente, welche als Kindelemende die Prüfergebnisse der einzelnen im PDF Dokument gefundenen Signaturen beinhalten. Die Kindelement sind weitgehend identisch zur Response bei CMS Signaturen aufgebau. Somit sei hier auf das Kapitel 2.1.3.2 verwiesen.

    +

     

    +

     

    2.2 Webservice-Clients

    -- cgit v1.2.3