Open Interfaces für das eGovernment

Security-Layer für das Konzept Bürgerkarte

Minimalanforderungen an eine Implementation

Dokumenteninformation

Inhalt

1. Einführung
   1. Schlüsselwörter
2. Schnittstellenbefehle des Security-Layer
3. Profil für XML-Signaturen
4. Auflösung von URIs
5. Transportprotokolle für den Security-Layer
6. Referenzen
7. Historie

1 Einführung

Dieses Dokument beschreibt die Minimalanforderungen aus dem Konzept Bürgerkarte an eine Implementation des Security-Layers:

• Schnittstellenbefehle, die zur Verfügung gestellt werden müssen;
• Profil für XML-Signaturen (Prüfung einer XML-Signatur, Erstellung einer XML-Signatur, Aushandeln eines symmetrischen Geheimnisses);
• Auflösung von URIs;
• Bindung des Schnittstellenprotokolls an Transportprotokolle.

1.1 Namenskonventionen

Folgende Namenraum-Präfixe werden in dieser Spezifikation zur Kennzeichnung der Namenräume von XML-Elementen verwendet:

1.2 Schlüsselwörter

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.

2 Schnittstellenbefehle des Security-Layer

Die nachfolgende Tabelle listet alle Befehle, die im Dokument Schnittstellenspezifikation Security-Layer spezifiziert sind. Für jeden dieser Schnittstellenbefehle gibt sie an, ob der Befehl verpflichtend zu implementieren ist oder optional implementiert werden kann.

Für optionale Komponenten innerhalb eines Befehls gelten die Angaben aus der Schnittstellenspezifikation Security-Layer.

3 Profil für XML-Signaturen

Dieser Abschnitt spezifiziert ein Profil für XML-Signaturen nach [XMLDSIG], das von einer Bürgerkarten-Umgebung im Kontext der folgenden Befehle des Security-Layer zu berücksichtigen ist:

• Prüfung einer XML-Signatur
• Erstellung einer XML-Signatur
• Aushandeln eines symmetrischen Geheimnissess

3.1 Signaturtypen

Alle drei Signaturtypen, die in [XMLDSIG] beschrieben sind (Detached Signature, Enveloping Signature, Enveloped Signature), müssen von einer Bürgerkarten-Umgebung überprüft werden können.

Die Anforderungen hinsichtlich der Erstellung von XML-Signaturen ergeben sich bereits aus den Erläuterungen der Schnittstellenspezifikation. Der Vollständigkeit halber sei an dieser Stelle angeführt, dass alle drei erwähnten Signaturtypen von einer Bürgerkarten-Umgebung auch erstellt werden können müssen.

3.2 Manifeste

Aus den Erläuterungen der Schnittstellenspezifikation ergibt sich, dass eine Bürgerkarten-Umgebung sowohl die Überprüfung von Signaturmanifesten (auf die in einer Signaturreferenz mittels des Wertes http://www.buergerkarte.at/specifications/Security-Layer/20020831#SignatureManifest im Attribut Type des Elements dsig:Reference Bezug genommen wird) durchführen können muss ist, als auch die Überprüfung von gewöhnlichen Manifesten nach [XMLDSIG] (auf die in einer Signaturreferenz mittels des Wertes http://www.w3.org/2000/09/xmldsig#Manifest im Attribut Type des Elements dsig:Reference Bezug genommen wird).

3.3 Algorithmen

Dieser Abschnitt gibt an, welche Algorithmen für Signaturberechnung, Digestberechnung, Kanoniserung und Transformationen eine Bürgerkarten-Umgebung beherrschen muss, und zwar sowohl im Kontext der Signaturprüfung als auch im Kontext der Signaturerstellung.

3.3.1 Signaturalgorithmen

3.3.2 Digestalgorithmen

3.3.3 Kanonisierungsalgorithmen

3.3.4 Transformationen

3.4 Schlüsselinformationen

Dieser Abschnitt regelt die Arten von Schlüsselinformationen (Kindelemente von dsig:KeyInfo), mit denen eine Bürgerkarten-Umgebung im Kontext der folgenden Befehle des Security-Layer umgehen können muss:

• Prüfung einer XML-Signatur
• Erstellung einer XML-Signatur
• Aushandlung eines symmetrischen Geheimnisses

3.4.1 X.509-basierte Schlüsselinformationen

X509-basierte Schlüsselinformationen (Kindelement dsig:X509Data von dsig:KeyInfo bzw. sl10:SignerInfo) müssen von einer Bürgerkarten-Umgebung beherrscht werden. Die nachfolgende Tabelle gibt einen Überblick über die einzelnen Kindelemente von dsig:X509Data, mit welchen die Bürgerkarten-Umgebung im Kontext der oben angeführten Befehle des Security-Layer umgehen können mus.

⁽¹⁾ Die Kindelemente müssen wie angegeben in einer zu prüfenden XML-Signatur ausgewertet werden können.

⁽²⁾ Die Kindelemente müssen wie angegeben als Teil der zu erstellenden Signatur generiert werden können.

⁽³⁾ Die Kindelemente müssen wie angegeben zur Identifikation des Schlüssels des Kommunikationsparters ausgewertet werden können.

⁽⁴⁾ Die Erforderlichkeit bezieht sich lediglich auf das Element sl10:SignerInfo in der Antwort auf den Befehl zur Signaturprüfung.

3.4.2 Verweis auf Schlüsselinformationen

Neben den 509-basierten Schlüsselinformationen muss von einer Bürgerkarten-Umgebung auch das Kindelement dsig:RetrievalMethod (siehe [XMLDSIG], 4.4.3) zur Angabe von Verweisen auf Schlüsselinformationen unterstützt werden.

Bezüglich der in diesem Element vorkommenden Transformationen gelten die Anforderungen aus Abschnitt 3.3.4.

Erforderlich ist einerseits die Unterstützung von direkten Verweisen auf X509-Zertifikate (Verwendung des Wertes http://www.w3.org/2000/09/xmldsig#rawX509Certificate im Attribut Type des Elements dsig:Retrievalmethod), andererseits von Verweisen auf X509-basierte Schlüsselinformationen (Verwendung des Wertes http://www.w3.org/2000/09/xmldsig#X509Data im Attribut Type des Elements dsig:Retrievalmethod). Im letzten Fall gelten hinsichtlich der zu unterstützenden Subkategorien die Anforderungen aus Abschnitt 3.4.1.

4 Auflösung von URIs

Dieser Abschnitt regelt die von einer Bürgerkarten-Umgebung bei der Auflösung von URIs zu unterstützenden Protokolle. Die gemachten Angaben beziehen sich einerseits auf Verweise, die in einzelnen Request-Befehlen des Security-Layer vorkommen, andererseits auf Verweise in zu überprüfenden XML-Signaturen.

⁽¹⁾ Unter relativer URI ist hier eine URI zu verstehen, die keinen Protokoll-Teil enthält (vgl. [RFC2396], 3.1).

⁽²⁾ Unter Fragment-Bezeichner ist hier jener an eine URI angehängte Bezeichner zu verstehen, der zusammen mit der URI eine URI-Referenz bildet (vgl [RFC2396], 4).

⁽³⁾ Vergleiche den Mechanismus der Ergänzungsobjekte in der Schnittstellenspezifikation zur Unterstützung der Auflösung relativer URIs.

⁽⁴⁾ Zur Auswahl von Teilen eines XML-Dokuments steht alternativ das Mittel der Transformationen zur Verfügung.

5 Transportprotokolle für den Security-Layer

Das Dokument Transportprotokolle Security-Layer beschreibt die Bindung des Schnittstellenprotokolls Security-Layer an eine Reihe von möglichen Transportprotokollen. Die nachfolgende Tabelle gibt für jedes dieser Transportprotokolle an, ob die entsprechende Bindung verpflichtend zu implementieren ist oder optional zur Verfügung gestellt werden kann.

Für optionale Komponenten innerhalb einer Bindung gelten die Angaben aus dem Dokument Transportprotokolle Security-Layer.

6 Referenzen

EC14N

Boyer, John, Eastlake, Donald und Reagle, Joseph: Exclusive XML Canonicalization. W3C Recommendation, Juli 2002. Abgerufen aus dem World Wide Web am 31. August 2002 unter http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/.

ECDSA

Blake-Wilson, S., Karlinger, G. und Wang, Y.: ECDSA with XML-Signature Syntax. Internet-Draft, Juni 2002. Abgerufen aus dem World Wide Web am 31. August 2002 unter http://www.ietf.org/internet-drafts/draft-blake-wilson-xmldsig-ecdsa-03.txt.

Keywords

Bradner, S.: RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. IETF Request For Comment, März 1997. Abgerufen aus dem World Wide Web am 31.August 2002 unter http://www.ietf.org/rfc/rfc2119.txt.

RFC2396

Berners-Lee, T., Fielding, R., Irvine, U.C. und Masinter, L.: RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax. IETF Request For Comments, August 1998. Abgerufen aus dem World Wide Web am 31. August 2002 unter http://www.ietf.org/rfc/rfc2396.txt.

XMLDSIG

Eastlake, Donald, Reagle, Joseph und Solo, David: XML-Signature Syntax and Processing. W3C Recommendation, Februar 2002. Abgerufen aus dem World Wide Web am 31. August 2002 unter http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/.

XPF2

Boyer, John, Hughes, Merlin und Reagle, Joseph: XML-Signature XPath Filter 2.0. W3C Candidate Recommendation, Juli 2002. Abgerufen aus dem World Wide Web am 31. August 2002 unter http://www.w3.org/TR/2002/CR-xmldsig-filter2-20020718/.

7 Historie

Version 1.1.0 vom 31.08.2002: Veränderungen zu Version 1.0.3

• Anpassung der Namespaces in Abschnitt 1.1 und 2
• Anpassungen an Schnittstellenspezifikation in Abschnitt 3.1 und 3.