Standardisierte Key- und Infoboxen der österreichischen
Bürgerkarte | Konvention | |
| 1.2.0 | ||
| Empfehlung | ||
| Kurzbeschreibung | Beim Abarbeiten von Befehlen des Security-Layer durch die Bürgerkarten-Umgebung können eine Reihe von Fehlern mit unterschiedlichen Ursachen auftreten. Das vorliegende Dokument klassifiziert diese Fehler und legt Codes für die einzelnen Fehler fest. Diese Codes werden in der Fehlerantwort verwendet, welche die Bürgerkarten-Umgebung an die Applikation übermittelt. | |
| Autoren: | et al. | Projektteam/Arbeitsgruppe |
| AG Bürgerkarte | ||
| Datum: | 14.5.2004 | |
Beim Abarbeiten von Befehlen der Schnittstelle Security-Layer durch die
Bürgerkarten-Umgebung
können eine Reihe von Fehlern mit unterschiedlichen Ursachen auftreten.
Für diesen Fall liefert die Bürgerkarten-Umgebung
eine sl: ErrorResponse (vgl. Abschnitt 13, „Fehlerbehandlung“ in sl:ErrorResponse enthält einerseits einen Fehlercode und
andererseits einen beschreibenden Text zur Fehlerursache.
Das vorliegende Dokument klassifiziert diese Fehler und legt Codes für die einzelnen Fehler fest.
Zur besseren Lesbarkeit wurde in diesem Dokument auf geschlechtsneutrale Formulierungen verzichtet. Die verwendeten Formulierungen richten sich jedoch ausdrücklich an beide Geschlechter.
Folgende Namenraum-Präfixe werden in dieser Spezifikation zur Kennzeichnung der Namenräume von XML-Elementen verwendet:
| Präfix | Namenraum | Erläuterung |
|---|---|---|
sl
|
http://www.buergerkarte.at/namespaces/securitylayer/1.2#
| Elemente der Applikationsschnittstelle Security-Layer |
Dieses Dokument verwendet die Schlüsselwörter MUSS, DARF NICHT, ERFORDERLICH, SOLLTE, SOLLTE NICHT, EMPFOHLEN, DARF, und OPTIONAL zur Kategorisierung der Anforderungen. Diese Schlüsselwörter sind analog zu ihren englischsprachigen Entsprechungen MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, und OPTIONAL zu handhaben, deren Interpretation in [Keywords] festgelegt ist.
Der in der Fehlernachricht der Bürgerkarten-Umgebung
angegebene Fehler (sl:ErrorResponse/sl:Errorcode) muss dem
folgenden zweiteiligen Aufbau genügen: Der erste Teil, bestehend aus bis
zu zwei Dezimalstellen, kennzeichnet die Herkunft des Fehlers, der zweite
Teil, bestehend aus exakt drei Dezimalstellen, ist ein innerhalb des
Herkunftsbereichs eindeutiger Identifikator des Fehlers selbst. Die beiden
Teile ergeben hintereinandergereiht eine vier- bzw. fünfstellige
Dezimalzahl.
Hinsichtlich der Herkunft eines aufgetretenen Fehlers werden folgende Bereiche unterschieden:
| Code | Herkunft |
|---|---|
1
| unklassifiziert |
2
| Fehler in der Bindung an das Transportprotokoll |
3
| Fehler in der XML-Struktur der Befehlsanfrage |
4
| Fehler in der Befehlsabarbeitung |
5
| Fehler in der Anzeigekomponente |
6
| Abbruch durch den Bürger |
Der zweite Teil des Fehlercodes ist eine innerhalb des Herkunftsbereichs eindeutiger Identifikator des Fehlers. Neben den in Abschnitt 3, „Standardisierte Fehlercodes“ festgelegten Identifikatoren, die eine Bürgerkarten-Umgebung zur Kennzeichnung der entsprechenden Fehler verwenden MUSS, DARF eine Bürgerkarten-Umgebung weitere, selbst festgelegte Identifikatoren für Fehler verwenden, die in Abschnitt 3, „Standardisierte Fehlercodes“ nicht explizit aufgeführt sind.
Die nachfolgende Tabelle enthält standardisierte Fehlercodes, die von einer Bürgerkarten-Umgebung zur Kennzeichnung der entsprechenden Fehler verwenden MÜSSEN.
| Fehlercode | Bedeutung |
|---|---|
1000
| Unklassifizierter Fehler. |
2000
| Unklassifizierter Fehler in der Transportbindung. |
2001
| HTTP/HTTPS-Bindung: DataURL kann nicht
aufgelöst werden. |
2002
| HTTP/HTTPS-Bindung: StylesheetURL kann nicht
aufgelöst werden. |
2003
| HTTP/HTTPS-Bindung: RedirectURL kann nicht
aufgelöst werden. |
2004
| HTTP/HTTPS-Bindung: Parameter XMLRequest
fehlt. |
2005
| HTTP/HTTPS-Bindung: Unbekannte Kodierung der Parameter. |
2006
| HTTP/HTTPS-Bindung: Fehlerhafte Kodierung der Parameter. |
2007
| HTTP/HTTPS-Bindung: DataURL-Server sendet
Fehler oder unerwartete Antwort. |
2008
| HTTP/HTTPS-Bindung: Fehler im Stylesheet, der von der
StylesheetURL bezogen wurde. |
2009
| HTTP/HTTPS-Bindung: HTTP-Anfrage an lokale BKU wurde an unerlaubte URL gerichtet. |
2010
| HTTPS-Bindung: Fehler beim Aufbau der TLS-Verbindung. |
3000
| Unklassifizierter Fehler in der XML-Struktur der Befehlsanfrage. |
3001
| XML-Struktur der Befehlsanfrage ist nicht wohlgeformt. |
3002
| XML-Struktur der Befehlsanfrage entspricht nicht dem Schema des Security-Layers. |
3003
| XML-Struktur der Befehlsanfrage enthält eine unerlaubte Kombination aus optionalen Elementen oder Attributen. |
3004
| XML-Struktur enthält ein Element oder Attribut, dessen Syntax nicht der Spezifikation des Security-Layer entspricht. |
3005
| Protokollversion des Security-Layer wird nicht unterstützt. |
4000
| Unklassifizierter Fehler in der Befehlsabarbeitung. |
4001
| Unbekannter Keyboxbezeichner. |
4002
| Unbekannter Infoboxbezeichner. |
4003
| Zu signierendes Datum kann nicht aufgelöst werden. |
4004
| Ergänzungsobjekt kann nicht aufgelöst werden. |
4005
| Zu verschlüsselndes Datum kann nicht aufgelöst werden. |
4006
| Algorithmus (Signatur, Verschlüsselung, Digest, Kanonisierung, Transformation) wird nicht unterstützt. |
4007
| Fehler bei der Algorithmusausführung (Signatur, Verschlüsselung, Digest, Kanonisierung, Transformation). |
4008
| Fehler beim Parsen der CMS-Nachricht. |
4009
| Kein passender Entschlüsselungsschlüssel vorhanden. |
4010
| Parameter des Infobox-Befehls passen nicht zum Typ der Infobox. |
4011
| Befehl ist nicht implementiert. |
4100
| XML-Dokument, in das die Signatur integriert werden soll, kann nicht aufgelöst werden. |
4101
| XML-Dokument, in das die Signatur integriert werden soll, kann nicht geparst werden. |
4102
| Signatur kann nicht am spezifizierten Ort in das bestehende XML-Dokument integriert werden. |
4103
| Signatorzertifikat ist nicht in der CMS-Signatur enthalten. |
4104
| Signierte Daten sind weder in der CMS-Signatur noch im XML-Request enthalten. |
4105
| XML-Dokument, das die zu prüfende Signatur enthält, kann nicht aufgelöst werden. |
4106
| XML-Dokument, das die zu prüfende Signatur enthält, kann nicht geparst werden. |
4107
| Am spezifizierten Ort innerhalb des XML-Dokuments befindet sich keine XML-Signatur. |
4108
| Verschlüsseltes Datum kann nicht am spezifizierten Ort in das bestehende XML-Dokument eingefügt werden. |
4109
| Bestehendes XML-Dokument ist notwendig, aber nicht vorhanden. |
4110
| Bestehendes XML-Dokument kann nicht aufgelöst werden. |
4111
| Bestehendes XML-Dokument kann nicht geparst werden. |
4112
| Verschlüsselte Datenverschlüsselungsschlüssel können nicht am spezifizierten Ort in das bestehende XML-Dokument eingefügt werden. |
4113
| Zu entschlüsselnde Daten sind weder in der CMS-Nachricht noch im XML-Request enthalten. |
4114
| Zu entschlüsselndes XML-Dokument kann nicht aufgelöst werden. |
4115
| Zu entschlüsselndes XML-Dokument kann nicht geparst werden. |
4116
| Zumindest ein spezifiziertes Verschlüsselungselement kann nicht im zu entschlüsselnden XML-Dokument gefunden werden. |
4117
| Kein Verschlüsselungselement für Binärantwort vorhanden. |
4118
| Zu hashendes Datum kann nicht aufgelöst werden. |
4119
| Datum, für das der Hashwert zu prüfen ist, kann nicht aufgelöst werden. |
4120
| Gewählter Infoboxbezeichner bereits vergeben. |
4121
| Infobox mit spezifiziertem Bezeichner existiert nicht. |
4122
| Inhalt der ausgewählten Infobox kann nicht als XML dargestellt werden. |
4123
| Assoziatives Array: Zum spezifizierten Schlüssel existiert kein Eintrag. |
5000
| Unklassifizierter Fehler in der Anzeigekomponente. |
5001
| Anzeige von Daten des in der Befehlsanfrage angegebenen Mime-Types wird nicht unterstützt. |
5002
| Zeichenkodierung der anzuzeigenden Daten ist fehlerhaft oder wird nicht unterstützt. |
5003
| Anzuzeigende Daten enhalten nicht unterstützte Zeichen. |
5004
| Standardanzeigeformat: HTML ist nicht spezifikationskonform. |
5005
| Standardanzeigeformat: CSS ist nicht spezifikationskonform. |
5006
| Standardanzeigeformat: Format eines eingebundenen Bildes ist nicht spezifikationskonform. |
5007
| Standardanzeigeformat: Signatur über eingebundene Bilder fehlt oder ist nicht spezifikationskonform. |
6000
| Unklassifizierter Abbruch durch den Bürger. |
6001
| Abbruch durch den Bürger über die Benutzerschnittstelle. |
6002
| Abbruch auf Grund mangelnder Rechte zur Befehlsausführung. |
Glossar
- Applikation
Jenes Programm, das Anfragen an die Bürgerkarten-Umgebung über den Security-Layer richtet und die entsprechenden Antworten entgegennimmt und auswertet.
- Benutzer-Schnittstelle
Jene Schnittstelle, über die der Bürger mit der Bürgerkarten-Umgebung kommuniziert. Über diese Schnittstelle wird einerseits die Benutzerinteraktion abgewickelt, die gegebenenfalls zur Abwicklung eines Befehls des Security-Layers notwendig ist (z.B. die Anzeige eines zu signierenden Dokuments beim Befehl zur Erzeugung einer XML-Signatur); andererseits kann der Bürger über diese Schnittstelle seine Bürgerkarten-Umgebung nach seinen persönlichen Bedürfnissen konfigurieren (z.B. kann er Einstellungen zum Zugriffsschutz auf seine Infoboxen verändern). Die Vorgaben an die Benutzer-Schnittstelle sind in Minimale Umsetzung des Security-Layers geregelt.
- Bürger
Jene Person, die die Funktionen der Bürgerkarten-Umgebung für die sichere Abwicklung von E-Government oder E-Commerce verwenden möchte. Die Ansteuerung der Bürgerkarten-Umgebung erfolgt in der Regel nicht durch den Bürger selbst, sondern durch die Applikation, welche die E-Government oder E-Commerce Anwendung repräsentiert.
- Bürgerkarte
Laut [E-GovG], §10 ZI 10 ist die Bürgerkarte „die unabhängig von der Umsetzung auf unterschiedlichen technischen Komponenten gebildete logische Einheit, die eine elektronische Signatur mit einer Personenbindung (§ 4 Abs. 2) und den zugehörigen Sicherheitsdaten und -funktionen sowie mit allenfalls vorhandenen Vollmachtsdaten verbindet“. Im Sinne der in den Spezifikationen zur österreichischen Bürgerkarte gebrauchten Terminologie ist die Bürgerkarten-Umgebung die Implementierung der logischen Einheit Bürgerkarte.
- Bürgerkarten-Umgebung
Jenes Programm bzw. jener Dienst, der die Funktionalität der Bürgerkarte zur Verfügung stellt. Grundsätzlich vorstellbar ist die Ausführung als Programm, das lokal am Rechner des Bürgers läuft (lokale Bürgerkarten-Umgebung), oder als serverbasierter Dienst, der über das Internet angesprochen wird (serverbasierte Bürgerkarten-Umgebung). Die Interaktion mit diesem Programm bzw. Dienst wird über zwei Schnittstellen abgewickelt: Über die Benutzer-Schnittstelle sowie über den Security-Layer.
- Hash-Eingangsdaten
Jene Daten, die für die Berechnung des Hash-Wertes für eine
dsig:Referenceverwendet werden. Sind für diedsig:ReferenceTransformationen angegeben, entsprechen diese Daten dem Ergebnis der letzten Transformation. Sind keine Transformationen spezifiziert, gleichen die Hash-Eingangsdaten den Referenz-Eingangsdaten.- Impliziter Transformationsparameter
Siehe Abschnitt 2.2.2.2, „Implizite Transformationsparameter“ in
Die österreichische Bürgerkarte - Applikationsschnittstelle Security-Layer - Referenz-Eingangsdaten
Jene Daten, die sich aus der Auflösung der im Attribut
URIderdsig:Referenceangegebenen URI ergeben. Sind für diedsig:ReferenceTransformationen angegeben, werden diese Daten als Eingangsdaten zur Berechnung der ersten Transformation verwendet. Sind keine Transformationen spezifiziert, gleichen die Referenz-Eingangsdaten den Hash-Eingangsdaten.- Security-Layer
Jene Schnittstelle, über die die Applikation mit der Bürgerkarten-Umgebung kommuniziert. Das genaue Protokoll, das über diese Schnittstelle gesprochen werden kann, wird in Applikationsschnittstelle Security-Layer spezifiziert. Die möglichen Bindungen dieses Protokolls an Transportschichten wie HTTP oder TCP wird in Transportprotokolle Security-Layer geregelt.
- Signaturmanifest
Siehe Abschnitt 2.2.2.2, „Implizite Transformationsparameter“ in
Die österreichische Bürgerkarte - Applikationsschnittstelle Security-Layer .
[BSI TR-03111] Bundesamt für Sicherheit in der Informationstechnik: Technical Guideline TR-03111: Elliptic Curve Cryptography, Technical Guideline, Juni 2012
[CAdES] European Telecommunications Standards Institute: ETSI TS 101733: Electronic Signatures and Infrastructures (ESI); CMS Advanced Electronic Signatures (CAdES) v2.2.1 , Technical Specification, April 2013
[CAdES-Baseline] European Telecommunications Standards Institute: ETSI TS 103173: Electronic Signatures and Infrastructures (ESI); CAdES Baseline Profile v2.2.1 , Technical Specification, April 2013
[CMS] Housley, R.: RFC 5652: Cryptographic Message Syntax (CMS) , IETF Request For Comment, September 2009
[CMS-AES] chaad, J.: RFC 3565: Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS) . IETF Request For Comment, Juli 2003.
[CMS-Alg] Housley, R.: RFC 3370: Cryptographic Message Syntax (CMS) Algorithms . IETF Request For Comment, August 2002.
[CMS-RSAES-OAEP] Housley, R.: RFC 3560: Use of the RSAES-OAEP Key Transport Algorithm in the Cryptographic Message Syntax (CMS) . IETF Request For Comment, Juli 2003.
[CSS 2] Bert Bos, Håkon Wium Lie, Chris Lilley und Ian Jacobs: Cascading Style Sheets, level 2 . W3C Recommendation, Mai 1998.
[EC14N] Boyer, John, Eastlake, Donald und Reagle, Joseph: Exclusive XML Canonicalization. W3C Recommendation, Juli 2002 .
[ECDSA-CMS] Turner, S., Brown, D.: RFC 5753: Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) . IETF Request For Comment, Jänner 2010.
[ECDSA-XML] Blake-Wilson, S., Karlinger, G. und Wang, Y.: ECDSA with XML-Signature Syntax . Internet-Draft, Jänner 2004.
[ESS-S/MIME] Hoffman, P.: RFC 2634: Enhanced Security Services for S/MIME , IETF Request For Comment, Juni 1999
[ETSICMS] European Telecommunications Standards Institute: ETSI TS 101733: Electronic Signature Formats, v1.5.1 , Technical Specification, Dezember 2003
[ETSIQCert] European Telecommunications Standards Institute: ETSI TS 101 862: Qualified certificate profile, v1.2.1 , Technical Specification, Juni 2001
[ETSIXML] European Telecommunications Standards Institute: ETSI TS 101903: XML Advanced Electronic Signatures (XAdES), v1.2.2 , Technical Specification, April 2004
[GIF] Graphics Interchange Format, Version 89a . CompuServe Incorporated, Juli 1990.
[HTML4] Dave Ragget, Arnaud Le Hors und Ian Jacobs: HTML 4.01 Specification . W3C Recommendation, Dezember 1999.
[HTTP1.1] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leech und T. Berners-Lee: Hypertext Transfer Protocol -- HTTP/1.1. IETF Request For Comment, Juni 1999.
[HTTPS] E. Rescorla HTTP over TLS. IETF Request For Comment, Mai 2000
[ISO-8859-1] ISO/IEC 8859-1:1998: Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1.
[ISO-8859-10] ISO/IEC 8859-10:1998: Information technology -- 8-bit single-byte coded graphic character sets -- Part 10: Latin alphabet No. 6.
[ISO-8859-15] ISO/IEC 8859-15:1999: Information technology -- 8-bit single-byte coded graphic character sets -- Part 15: Latin alphabet No. 9.
[ISO-8859-2] ISO/IEC 8859-2:1999: Information technology -- 8-bit single-byte coded graphic character sets -- Part 2: Latin alphabet No. 2.
[ISO-8859-3] ISO/IEC 8859-3:1999: Information technology -- 8-bit single-byte coded graphic character sets -- Part 3: Latin alphabet No. 3.
[ISO-8859-9] ISO/IEC 8859-9:1999: Information technology -- 8-bit single-byte coded graphic character sets -- Part 9: Latin alphabet No. 5.
[JPEG] Eric Hamilton: JPEG File Interchange Format, Version 1.02 . C-Cube Microsystems, September 1992.
[KEYWORDS] Bradner, S.: RFC 2119: Key words for use in RFCs to Indicate Requirement Levels , IETF Request For Comment, März 1997
[MIME] Freed, N. und Borenstein, N.: RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types , IETF Request For Comment, November 1996
[PAdES] European Telecommunications Standards Institute: ETSI TS 102778: Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic Signature Profiles v1.2.1 , Technical Specification, Juli 2010
[PersBin] Hollosi, Arno und Karlinger, Gregor: XML-Definition der Personenbindung . Konvention zum E-Government Austria erarbeitet von der Stabsstelle IKT-Strategie des Bundes, Technik und Standards. Öffentlicher Entwurf, Version 1.2.2, 14. Februar 2005.
[PersonData] Naber, Larissa: PersonData Struktur - XML Spezifikation . Konvention zum E-Government Austria erarbeitet von der Arbeitsgruppe Kommunikationsarchitekturen. Öffentlicher Entwurf, Version 2.0.0, 14. Oktober 2004.
[PKCS#12] RSA Laboratories: PKCS#12 v1.0: Personal Information Exchange Syntax , Juni 1999.
[port-numbers] Internet Assigned Numbers Authority: Port Numbers
[QCert] Santesson, S. und Nystrom M.: RFC 3739: Internet X.509 Public Key Infrastructure: Qualified Certificates Profile , IETF Request For Comment, März 2004
[RFC 5035] Schaad, J.: RFC 5035: Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility , IETF Request For Comment, August 2007
[SHA2-CMS] Turner, S.: RFC 5754: Using SHA2 Algorithms with Cryptographic Message Syntax , IETF Request For Comment, Jänner 2010
[Stammzahl] Hollosi, Arno und Hörbe, Rainer: Bildung von Stammzahl und bereichsspezifischem Personenkennzeichen (bPK) . Konvention zum E-Government Austria erarbeitet von der Stabsstelle IKT-Strategie des Bundes, Technik und Standards sowie vom Bundesminsterium für Inneres. Öffentlicher Entwurf, Version 1.0, 2. Februar 2004.
[TLS] T. Dierks und C. Allen: The TLS Protocol Version 1.0 . IETF Request For Comment, Januar 1999.
[Unicode] The Unicode Consortium. The Unicode Standard, Version 4.0.0 , defined by: The Unicode Standard, Version 4.0 (Boston, MA, Addison-Wesley, 2003. ISBN 0-321-18578-1).
[URI] Berners-Lee, T. , Fielding, R. und Masinter, L.: RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax , IETF Request For Comment, August 1998
[VerwEig] Hollosi, Arno: X.509 Zertifikatserweiterungen für die Verwaltung . Konvention zum E-Government Austria erarbeitet von der Stabsstelle IKT-Strategie des Bundes, Technik und Standards. Öffentlicher Entwurf, Version 1.0.3, 21. Februar 2005.
[X509] Polk, W., Ford, W., Solo, D.: RFC 3280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile . IETF Request For Comment, April 2002.
[XAdES] European Telecommunications Standards Institute: ETSI TS 101903: XML Advanced Electronic Signatures (XAdES), v1.4.2 , Technical Specification, Dezember 2010
[XHTML 1.1] Murray Altheim, Frank Boumphrey, Sam Dooley, Shane McCarron, Sebastian Schnitzenbaumer und Ted Wugofski: Modularization of XHTML . W3C Recommendation, April 2001.
[XHTML MOD] Daniel Austin, Subramanian Peruvemba, Shane McCarron, Masayasu Ishikawa: Modularization of XHTML in XML Schema . W3C Working Draft, Oktober 2003.
[XML] Bray, Tim, Paoli, Jean, Sperberg-McQueen, C.M. und Maler, Eve: Extensible Markup Language (XML) 1.0 (Second Edition) , W3C Recommendation, Oktober 2000.
[XMLDecTF] Hughes, Merlin, Imamura, Takeshi und Maruyama, Hiroshi: Decryption Transform for XML Signature . W3C Recommendation, Dezember 2002.
[XMLDSIG] Eastlake, Donald, Reagle, Joseph und Solo, David: XML-Signature Syntax and Processing , W3C Recommendation, Februar 2002
[XMLDSIG-URI] Eastlake, Donald: RFC 4051: Additional XML Security Uniform Resource Identifiers (URIs) , IETF Request For Comments, April 2005
[XMLEnc] Eastlake, Donald und Reagle, Joseph: XML Encryption Syntax and Processing , W3C Recommendation, Dezember 2002
[XML-Schema] Thompson, Henry S., Beech, David, Maloney, Murray und Mendelson, Noah: XML Schema Part 1: Structures , W3C Recommendation, Mai 2001
[XMLTYPE] Murata, M., St.Laurent, S., und Kohn, D.: RFC 3023: XML Media Types , IETF Request For Comment, Jänner 2001.
[XPath] Clark, James und DeRose, Steven: XML Path Language , W3C Recommendation, November 1999
[XPF2] Boyer, John, Hughes, Merlin und Reagle, Joseph: XML-Signature XPath Filter 2.0 . W3C Candidate Recommendation, Juli 2002.
[XPointer] Grosso, Paul, Maler, Eve, Marsh, Jonathan und Walsh, Norman: XPointer Framework . W3C Recommendation, März 2003.
[XSS-FAQ] Cgisecurity.com: The Cross Site Scripting FAQ .