Logo BMÖLS Open Interfaces
für das eGovernment
Logo A-SIT

Security-Layer für das Konzept Bürgerkarte

Minimalanforderungen an eine Implementation


Dokumenteninformation

Bezeichnung Minimalanforderungen aus dem Konzept Bürgerkarte an eine Implementation des Security-Layers
Kurzbezeichnung Minimalanforderungen Security-Layer
Version 1.1.0
Datum 31. 08. 2002
Dokumentklasse Konvention
Dokumentstadium Öffentlicher Entwurf
Kurzbeschreibung

Dieses Dokument beschreibt folgende 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;
  • Auflösung von URIs;
  • Bindung des Schnittstellenprotokolls an Transportprotokolle.
Autoren Arno Hollosi (arno.hollosi@cio.gv.at)
Gregor Karlinger (gregor.karlinger@cio.gv.at)
Arbeitsgruppe BMÖLS, CIO des Bundes, Operative Unit
© Diese Spezifikation wird von A-SIT und dem BMÖLS zur Verfügung gestellt. Die Verwendung ohne Modifikation ist unter Bezugnahme auf diese Copyright-Notiz zulässig. Eine Erweiterung der Spezifikation ist erlaubt, jedoch muss dies eindeutig gekennzeichnet sein, und es muss die erweiterte Spezifikation frei zur Verfügung gestellt werden.

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:

1.1 Namenskonventionen

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

Präfix
Namenraum
Erläuterung
dsig http://www.w3.org/2000/09/xmldsig# Elemente aus [XMLDSIG]
sl10 http://www.buergerkarte.at/namespaces/securitylayer/20020225# Unveränderte Elemente aus der Version 1.0.3 dieser Spezifikation
sl11 http://www.buergerkarte.at/namespaces/securitylayer/20020831# Elemente dieser Spezifikation

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.

Signaturbefehl Kommandonamen Anforderung
Signatur nach CMS erstellen sl10:CreateCMSSignatureRequest
sl10:CreateCMSSigantureResponse
empfohlen
Signatur nach XMLDSIG erstellen sl11:CreateXMLSignatureRequest
sl11:CreateXMLSignatureResponse
erforderlich
Signatur nach CMS prüfen sl11:VerifyCMSSignatureRequest
sl11:VerifyCMSSignatureResponse
empfohlen
Signatur nach XMLDSIG prüfen sl11:VerifyXMLSignatureRequest
sl11:VerifyXMLSignatureResponse
erforderlich
Abfrage verfügbarer Infoboxen sl10:InfoboxAvailableRequest
sl10:InfoboxAvailableResponse
erforderlich
Lesen von Infobox-Daten sl10:InfoboxReadRequest
sl10:InfoboxReadResponse
erforderlich
Verändern von Infoboxdaten sl10:InfoboxUpdateRequest
sl10:InfoboxUpdateResponse
erforderlich
Erzeugung eines Sitzungszertifikats sl10:CreateSessionKeyRequest
sl10:CreateSessionKeyResponse
optional
Aushandeln eines symmetrischen Geheimnisses sl10:CreateSymmetricSecretRequest
sl10:CreateSymmetricSecretResponse
optional
Abfrage der Umgebungseigenschaften sl10:GetPropertiesRequest
sl11:GetPropertiesResponse
erforderlich
Abfrage des Kartenstatus sl10:GetStatusRequest
sl10:GetStatusResponse
erforderlich

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:

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

Bezeichnung URI normative Referenz Anforderung
RSA http://www.w3.org/2000/09/xmldsig#rsa-sha1 [XMLDSIG], 6.4.2 erforderlich
DSA http://www.w3.org/2000/09/xmldsig#dsa-sha1 [XMLDSIG], 6.4.1 erforderlich
ECDSA http://www.buergerkarte.at/namespaces/ecdsa/200206030#ecdsa-sha1 [ECDSA] empfohlen

3.3.2 Digestalgorithmen

Bezeichnung URI normative Referenz Anforderung
SHA-1 http://www.w3.org/2000/09/xmldsig#sha1 [XMLDSIG], 6.2.1 erforderlich

3.3.3 Kanonisierungsalgorithmen

Bezeichnung URI normative Referenz Anforderung
C14N http://www.w3.org/TR/2001/REC-xml-c14n-20010315 [XMLDSIG], 6.5.1 erforderlich
C14N with comments http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments [XMLDSIG], 6.5.1 erforderlich
EC14N http://www.w3.org/2001/10/xml-exc-c14n# [EC14N], 4 erforderlich
EC14N with comments http://www.w3.org/2001/10/xml-exc-c14n#WithComments [EC14N], 4 erforderlich

3.3.4 Transformationen

Bezeichnung URI normative Referenz Anforderung
C14N http://www.w3.org/TR/2001/REC-xml-c14n-20010315 [XMLDSIG], 6.5.1 erforderlich
C14N with comments http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments [XMLDSIG], 6.5.1 erforderlich
EC14N http://www.w3.org/2001/10/xml-exc-c14n# [EC14N], 4 erforderlich
EC14N with comments http://www.w3.org/2001/10/xml-exc-c14n#WithComments [EC14N], 4 erforderlich
Base64 Decoder http://www.w3.org/2000/09/xmldsig#base64
[XMLDSIG], 6.6.2 erforderlich
XPath Filter 1 http://www.w3.org/TR/1999/REC-xpath-19991116 [XMLDSIG], 6.6.3 erforderlich
XPath Filter 2 http://www.w3.org/2002/06/xmldsig-filter2 [XPF2] erforderlich
Enveloped Signature http://www.w3.org/2000/09/xmldsig#enveloped-signature [XMLDSIG], 6.6.4 erforderlich
XSLT http://www.w3.org/TR/1999/REC-xslt-19991116
[XMLDSIG], 6.6.5 erforderlich

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:

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.

Kindelement
Anforderung im Kontext
Signaturprüfung (1)
Signaturerstellung (2)
Symm. Geheimnis (3)
dsig:X509Certificate erforderlich erforderlich erforderlich
dsig:X509CRL empfohlen optional n.a.
dsig:x509IssuerSerial optional/erforderlich (4) optional optional
dsig:x509SubjectName optional/erforderlich (4) optional optional

(1) Die Kindelemente müssen wie angegeben in einer zu prüfenden XML-Signatur ausgewertet werden können.

(2) Die Kindelemente müssen wie angegeben als Teil der zu erstellenden Signatur generiert werden können.

(3) Die Kindelemente müssen wie angegeben zur Identifikation des Schlüssels des Kommunikationsparters ausgewertet werden können.

(4) 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.

Protokoll
Anforderung im Kontext
Request-Befehl
Zu prüfende XML-Signatur
Daten-Verweis
Schlüsselinfo-Verweis
http erforderlich erforderlich erforderlich
https erforderlich erforderlich erforderlich
ldap optional optional empfohlen
relative URI (1) erforderlich (3) erforderlich (3) erforderlich (3)
Fragment-Bezeichner(2) darf nicht darf nicht (4) darf nicht (4)

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

(2) 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).

(3) Vergleiche den Mechanismus der Ergänzungsobjekte in der Schnittstellenspezifikation zur Unterstützung der Auflösung relativer URIs.

(4) 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.

Transportprotokoll Anforderung
TCP/IP erforderlich
HTTP erforderlich
SSL/TLS empfohlen
HTTPS empfohlen

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