diff options
author | Thomas Lenz <thomas.lenz@egiz.gv.at> | 2017-02-16 11:55:53 +0100 |
---|---|---|
committer | Thomas Lenz <thomas.lenz@egiz.gv.at> | 2017-02-16 11:55:53 +0100 |
commit | 28b140426304acf5342e9ab5a1a3a5656fa280b9 (patch) | |
tree | 1d0a55101f79d211aecc4431f40201ebfeffd416 /moaSig/handbook | |
parent | 2507c718c0b0dddcd19edda38699f1f3c4d1c7df (diff) | |
download | moa-sig-28b140426304acf5342e9ab5a1a3a5656fa280b9.tar.gz moa-sig-28b140426304acf5342e9ab5a1a3a5656fa280b9.tar.bz2 moa-sig-28b140426304acf5342e9ab5a1a3a5656fa280b9.zip |
update handbook
Diffstat (limited to 'moaSig/handbook')
-rw-r--r-- | moaSig/handbook/handbook/usage/usage.html | 243 |
1 files 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 @@ <li><a href="#webservice_xmlrequests_pruefungxml_ergaenzungsobjekte">Ergänzungsobjekte</a></li> <li><a href="#webservice_xmlrequests_pruefungxml_signaturmanifest">Signatur-Manifest des Security-Layers</a></li> <li><a href="#webservice_xmlrequests_pruefungxml_tsl">Prüfung gegen Trustprofil mit TSL Unterstützung</a></li> - </ol> + </ol> </li> + <li><a href="#webservice_xmlrequests_pruefungpdf">Prüfung von PAdES Signaturen</a></li> + <li><a href="#webservice_xmlrequests_pruefungasic">Prüfung von ASiC Signaturen</a></li> </ol> </li> <li><a href="#webservice_clients">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> </pre> <p> Liegt eine zu prüfende CMS-Signatur vor, die von mehreren Unterzeichnenden signiert worden ist, kann das Attribut <code>VerifyCMSSignatureRequest/@Signatories</code> 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 <code>1</code>. 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 <code>"1 3"</code> würde beispielsweise aussagen, dass MOA SP die Unterschrift des ersten sowie des dritten Unterzeichnenden prüfen soll.</p> -<p>Mit dem optionalen Element <code>DateTime</code> kann der Zeitpunkt der Signaturprüfung explizit vorgegeben werden. Inhalt dieses Elements ist die Angabe von Datum und Uhrzeit entsprechend dem XML-Schema Datentyp <a href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime" target="_blank"><span class="term">dateTime</span></a>. 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 <code>DateTime</code> nicht angegeben, versucht MOA SP, den Zeitpunkt der Signaturerstellung aus der Signatur zu ermitteln (anhand des Signaturattributs <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/core/Core.html#ref-etsicms" target="_blank" class="term">SigningTime</a>). Enthält die Signatur keinen Zeitpunkt der Signaturerstellung, verwendet MOA SP die aktuelle Systemzeit des Servers, auf dem es läuft. </p> +<p>Mit dem optionalen Element <code>DateTime</code> kann der Zeitpunkt der Signaturprüfung explizit vorgegeben werden. Inhalt dieses Elements ist die Angabe von Datum und Uhrzeit entsprechend dem XML-Schema Datentyp <a href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime" target="_blank"><span class="term">dateTime</span></a>. 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 <code>DateTime</code> nicht angegeben, versucht MOA SP, den Zeitpunkt der Signaturerstellung aus der Signatur zu ermitteln (anhand des Signaturattributs <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/core/Core.html#ref-etsicms" target="_blank" class="term">SigningTime</a>). Enthält die Signatur keinen Zeitpunkt der Signaturerstellung, verwendet MOA SP die aktuelle Systemzeit des Servers, auf dem es läuft. Das optionale Element <code>ExtendedValidation</code> 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 <a href="#webservice_xmlrequests_pruefungxml_erweitert">2.1.4.2</a>, da diese für alle unterstützen Signaturformate identisch sind.</p> <p>Das optionale Element <code>DataObject</code> muss dann angegeben werden, wenn eine <span class="term">Detached Signature</span> geprüft werden soll, d. h. wenn in der CMS-Signatur die signierten Daten nicht mitkodiert sind. In <code>DataObject/Content/Base64Content</code> sind in einem solchen Fall diese Daten in base64 kodierter Form bereit zu stellen.</p> <h5>Response</h5> <p><code><a href="../../clients/webservice/resources/requests/VerifyCMSSignatureRequest.Extended.resp.xml" target="_blank">VerifyCMSSignatureRequest.Extended.resp.xml</a></code> 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.</p> @@ -876,10 +879,202 @@ positive Ganzzahl repräsentiert, die auf das beinhaltende <code>dsig:Manife <CertificateCheck> <Code>0</Code> </CertificateCheck> - <FormCheckResult><br> <Code>1</Code><br> <Name>LTA</Name><br> </FormCheckResult><br> <FormCheckResult><br> <Code>1</Code><br> <Name>LT</Name><br> </FormCheckResult><br> <FormCheckResult><br> <Code>1</Code><br> <Name>T</Name><br> </FormCheckResult><br> <FormCheckResult><br> <Code>1</Code><br> <Name>B</Name><br> </FormCheckResult><br> <ExtendedCertificateCheck><br> <Major><br> <Code>2</Code><br> Name>INDETERMINATE</Name><br> </Major><br> <Minor><br> <Code>13</Code><br> <Name/><br> </Minor><br> </ExtendedCertificateCheck> + <FormCheckResult><br> <Code>1</Code><br> <Name>B-LTA</Name><br> </FormCheckResult><br> <FormCheckResult><br> <Code>1</Code><br> <Name>B-LT</Name><br> </FormCheckResult><br> <FormCheckResult><br> <Code>1</Code><br> <Name>B-T</Name><br> </FormCheckResult><br> <FormCheckResult><br> <Code>0</Code><br> <Name>B-B</Name><br> </FormCheckResult><br> <ExtendedCertificateCheck><br> <Major><br> <Code>0</Code><br> <Name>VALID</Name><br> </Major><br> <Minor><br> <Code>23</Code><br> <Name>SUCCESS</Name><br> </Minor><br> </ExtendedCertificateCheck> </VerifyXMLSignatureResponse> </pre> <p>Die Elemente <code>SignatureCheck</code> und <code>CertificateCheck</code> enthalten die Resultate der kryptographischen Prüfung der Signatur sowie der Zertifikatsprüfung (siehe <a href="#webservice_xmlrequests_pruefungxml_einfach">Einfaches Beispiel</a>). Die Elemente <code>FormCheckResult</code> enthalten die Ergebnisse zu den einzelnen Formvalidierungen und das Element <code>ExtendedCertificateCheck</code> enthalten die Ergebnisse zum erweiterten Zertifikatscheck.</p> +<p>Das Element <code>FormCheckResult</code> kann mehrfach vorkommen und beinhaltet die Validierungsergebnisse der folgenden erweiterten Signaturformate:</p> +<table width="993" border="1"> + <tr> + <td width="80" align="center"><strong>Name</strong></td> + <td width="897"><strong>Beschreibung</strong></td> + </tr> + <tr> + <td align="center">B-B</td> + <td>B- Level Conformance</td> + </tr> + <tr> + <td align="center">B-T</td> + <td>T- Level Conformance. </td> + </tr> + <tr> + <td align="center">B-LT</td> + <td>LT- Level Conformance</td> + </tr> + <tr> + <td align="center">B-LTV</td> + <td>LTA- Level Conformance</td> + </tr> +</table> +<p> </p> +<p>Das Prüfergebnis des jeweiligen Levels wird in Form eines <code>Code</code> Elements zurückgegeben. Hierbei sind folgende Statuscodes möglich:</p> +<table width="993" border="1"> +<tr> + <td><table width="993" border="1"> + <tr> + <td width="80" align="center"><strong>Code</strong></td> + <td width="897"><strong>Beschreibung</strong></td> + </tr> + <tr> + <td align="center">0</td> + <td>Die Signatur entspricht der im Element<code> Name</code> angegebenen Form. </td> + </tr> + <tr> + <td align="center">1</td> + <td>Die Signatur entspricht nicht der im Element<code> Name</code> angegebenen Form. </td> + </tr> + <tr> + <td align="center">2</td> + <td>Die Signatur beinhaltet nicht alle erforderlichen Eigenschaften der im Element<code> Name</code> angegebenen Form. </td> + </tr> + <tr> + <td align="center">3</td> + <td>Die Formvalidierung wurde wegen eines Fehlers abgebrochen</td> + </tr> + </table></td> +</tr> +</table> +<p> </p> +<p>Details zu den einzelen Levels finden Sie in den entsprechenden Spezifikation:</p> +<ul> + <li><a href="http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf">http://www.etsi.org/deliver/etsi_ts/103100_103199/103171/02.01.01_60/ts_103171v020101p.pdf </a></li> + <li><a href="http://www.etsi.org/deliver/etsi_ts/103100_103199/103172/02.01.01_60/ts_103172v020101p.pdf">http://www.etsi.org/deliver/etsi_ts/103100_103199/103172/02.01.01_60/ts_103172v020101p.pdf</a></li> + <li><a href="http://www.etsi.org/deliver/etsi_ts/102700_102799/10277804/01.01.02_60/ts_10277804v010102p.pdf">http://www.etsi.org/deliver/etsi_ts/102700_102799/10277804/01.01.02_60/ts_10277804v010102p.pdf</a></li> +</ul> +<p> </p> +<p>Das Element<code> ExtendedCertificateCheck </code>kommt einfach vor und beinhaltet die Validierungsergebnisse des erweiterten Zertifikatschecks. Hierbei sind die Validierungsergebnisse in ein <code>Major</code> und in ein <code>Minor</code> Ergebnis aufgetrennt wobei diese als gleichnamige XML Elemente abgebildet sind. Jedes dieser XML Elemnte beinhalet einen ResultCode als Element <code>Code</code> und ein eine optionale textuelle Beschreibung des Codes im Element <code>Name.</code> </p> +<p>Als Major Result sind folgende Codes möglich:</p> +<table width="993" border="1"> + <tr> + <td width="72" align="center"><strong>Code</strong></td> + <td width="180" align="center"><strong>Name</strong></td> + <td width="719"><strong>Beschreibung</strong></td> + </tr> + <tr> + <td align="center">0</td> + <td align="center">VALID</td> + <td>Zertifikatsprüfung erfolgreich</td> + </tr> + <tr> + <td align="center">1</td> + <td align="center">INVALID</td> + <td>Zertifikatsprüfung nicht erfolgreich</td> + </tr> + <tr> + <td align="center">2</td> + <td align="center">INDETERMINATE</td> + <td>Zertifikatsstatus nicht ermittelbar</td> + </tr> +</table> +<p> </p> +<p>Als Minor Result sind folgende Codes möglich:</p> +<table width="993" border="1"> + <tr> + <td width="80" align="center"><strong>Code</strong></td> + <td width="897"><strong>Beschreibung</strong></td> + </tr> + <tr> + <td align="center">0</td> + <td>Ein Zertifikat ist als revokiert gekennzeichnet</td> + </tr> + <tr> + <td align="center">1</td> + <td>Hash Fehler</td> + </tr> + <tr> + <td align="center">2</td> + <td>Signaturüberprüfung fehlgeschlagen</td> + </tr> + <tr> + <td align="center">3</td> + <td>Richtlinien zur Signaturerstellung </td> + </tr> + <tr> + <td align="center">4</td> + <td>Richtlinien zur Zertifikatskettenbildung</td> + </tr> + <tr> + <td align="center">5</td> + <td>Richtlinien zu kryptografischen Verfahren</td> + </tr> + <tr> + <td align="center">6</td> + <td>Ein Zertifikat ist abgelaufen</td> + </tr> + <tr> + <td align="center">7</td> + <td>Ein Zertifikat ist noch nicht gültig</td> + </tr> + <tr> + <td align="center">8</td> + <td>Formatfehler</td> + </tr> + <tr> + <td align="center">9</td> + <td>Policy konnte nicht verarbeitet werden</td> + </tr> + <tr> + <td align="center">10</td> + <td>Unbekannter Commitment Type</td> + </tr> + <tr> + <td align="center">11</td> + <td>Timestamp Fehler</td> + </tr> + <tr> + <td align="center">12</td> + <td>Allgemeiner Fehler bei der Validierung</td> + </tr> + <tr> + <td align="center">13</td> + <td>Kein Signaturzertifikat gefunden</td> + </tr> + <tr> + <td align="center">14</td> + <td>Keine Zertifikatskette gefunden</td> + </tr> + <tr> + <td align="center">15</td> + <td>Keine Policy gefunden</td> + </tr> + <tr> + <td align="center">16</td> + <td>Revokiert und kein Proof of Existence (POE)</td> + </tr> + <tr> + <td align="center">17</td> + <td>CA Revokiert und kein Proof of Existence (POE)</td> + </tr> + <tr> + <td align="center">18</td> + <td>Proof of Existence (POE) ungültig</td> + </tr> + <tr> + <td align="center">19</td> + <td>Krypografische Anforderungen an Proof of Existence (POE)</td> + </tr> + <tr> + <td align="center">20</td> + <td>Proof of Existence (POE) nicht vorhanden</td> + </tr> + <tr> + <td align="center">21</td> + <td>Die Prüfung war zum aktuellen Zeitpunkt nicht erfolgreich. Eine erneute Prüfung zu einen späteren Zeitpunkt könnte jedoch ein anderes Ergebnis liefern.</td> + </tr> + <tr> + <td align="center">22</td> + <td>SignedData Element nicht gefunden</td> + </tr> + <tr> + <td align="center">23</td> + <td>Erfolgreich</td> + </tr> + <tr> + <td align="center">24</td> + <td>Fehler</td> + </tr> +</table> +<p> </p> <h4><a name="webservice_xmlrequests_pruefungxml_xmldsigmanifest"></a>2.1.4.3 Prüfung eines XMLDSIG-Manifests </h4> <h5>Request</h5> <p>Dieses Beispiel zur Prüfung einer XML-Signatur (<a href="../../clients/webservice/resources/requests/VerifyXMLSignatureRequest.XMLDSigManifest.xml" target="_blank"><code>VerifyXMLSignatureRequest.XMLDSigManifest.xml</code></a>) demonstriert die Prüfung eines in der XML-Signatur vorhandenden <a href="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-Manifest" target="_blank">Manifests nach XMLDSig</a>. Bitte beachten Sie, dass der dargestellte Request zur bessernen Lesbarkeit eingerückt und gekürzt wurde.</p> @@ -1248,6 +1443,48 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph> </CertificateCheck> </pre> <p>Abschließend enthält die Response mit <code>CertificateCheck/Code</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. <span class="term">Trust Anchor</span> gebildet werden kann. Gelingt dies, wird die Gültigkeit jedes Zertifikats dieser Kette überprüft. In unserem Beispiel enthält <code>Code</code> den Wert <code>0</code>, 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 <a href="#sl"> Security-Layer Spezifikation</a>.</p> +<h3><a name="webservice_xmlrequests_pruefungpdf" id="webservice_xmlrequests_pruefungcms2"></a>2.1.5 Prüfung einer PAdES-Signatur</h3> +<h4>Request</h4> +<p>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.</p> +<pre> +<VerifyPDFSignatureRequest + xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#"> + <DateTime>2004-08-18T17:00:00+02:00</DateTime><br> <ExtendedValidation>true</ExtendedValidation> + <PDFSignature>MIIHsAYJKo...4sLL6kpOPJaLg==</PDFSignature> + <TrustProfileID>Test-Signaturdienste</TrustProfileID> +</VerifyPDFSignatureRequest> +</pre> +<p>Mit dem optionalen Element <code>DateTime</code> kann der Zeitpunkt der Signaturprüfung explizit vorgegeben werden. Inhalt dieses Elements ist die Angabe von Datum und Uhrzeit entsprechend dem XML-Schema Datentyp <a href="http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#dateTime" target="_blank"><span class="term">dateTime</span></a>. 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 <code>DateTime</code> nicht angegeben, versucht MOA SP, den Zeitpunkt der Signaturerstellung aus der Signatur zu ermitteln (anhand des Signaturattributs <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/core/Core.html#ref-etsicms" target="_blank" class="term">SigningTime</a>). Enthält die Signatur keinen Zeitpunkt der Signaturerstellung, verwendet MOA SP die aktuelle Systemzeit des Servers, auf dem es läuft. Das optionale Element <code>ExtendedValidation</code> 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 <a href="#webservice_xmlrequests_pruefungxml_erweitert">2.1.4.2</a>, da diese für alle unterstützen Signaturformate identisch sind.</p> +<p>Der Request enthält im Element <code>PDFSignature</code> die zu prüfende PAdES-Signatur, und zwar in base64 kodierter Form. </p> +<p>Abschließend enthält der Request in <code>TrustProfileID</code> 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. </p> +<h5>Response</h5> +<p>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.</p> +<pre> +<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><br> <SignatureCheck><br> <Code>0</Code><br> </SignatureCheck><br> <CertificateCheck><br> ... + </SignatureResult> + <SignatureResult> + ... +</pre> +<p>Die Response beinhaltet als erstes kein, ein oder mehrere <code>SignatureResult</code> 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 <a href="-webservice_xmlrequests_pruefungcms_erweitert">2.1.3.2</a> verwiesen.</p> +<p> </p> +<p> </p> <!-- TSL --> <h2><a name="webservice_clients" id="webservice_clients"></a>2.2 Webservice-Clients</h2> |