Logo BKA Open Interfaces
für das E-Government		 Logo A-SIT

Die österreichische Bürgerkarte

Minimale Umsetzung des Security-Layers

Dokumenteninformation

Bezeichnung

Minimale Umsetzung der Applikationsschnittstelle Security-Layer zur österreichischen Bürgerkarte

Kurzbezeichnung

Minimale Umsetzung des Security-Layers

Version

1.2.0

Datum

14. 05. 2004

Dokumentklasse

Konvention

Dokumentstadium

Empfehlung

Kurzbeschreibung

Dieses Dokument beschreibt folgende Anforderungen an eine minimale Umsetzung der Schnittstelle Security-Layer durch eine Bürgerkarten-Umgebung:

  • Schnittstellenbefehle;

  • Transportprotokolle;

  • Profil für die Erstellung und Prüfung von CMS-Signaturen;

  • Profil für die Erstellung und Prüfung von XML-Signaturen;

  • Profil für CMS-Verschlüsselung und CMS-Entschlüsselung;

  • Profil für XML-Verschlüsselung und XML-Entschlüsselung;

  • Profil für Hashwert-Berechnung und Hashwert-Verifikation;

  • Anzeigeformate und Zeichensätze.

Autoren

Arno Hollosi
Gregor Karlinger

Arbeitsgruppe

Bundeskanzleramt, Stabsstelle IKT-Strategie des Bundes, Technik und Standards

©

Diese Spezifikation wird von A-SIT und dem Bundeskanzleramt 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. Namenskonventionen
    2. Schlüsselwörter
  2. Schnittstellenbefehle des Security-Layer
  3. Transportprotokolle für den Security-Layer
  4. Profil für CMS-Signaturen
    1. Signaturerstellung
      1. Digest-Algorithmen
      2. Signaturalgorithmen
      3. Schlüsselinformationen
      4. Auflösung von Referenzen
    2. Signaturprüfung
      1. Digest-Algorithmen
      2. Signaturalgorithmen
      3. Schlüsselinformationen
      4. Auflösung von Referenzen
  5. Profil für XML-Signaturen
    1. Signaturerstellung
      1. Digest-Algorithmen
      2. Signaturalgorithmen
      3. Kanonisierungsalgorithmen
      4. Transformationsalgorithmen
      5. Schlüsselinformationen
      6. Auflösung von Referenzen
    2. Signaturprüfung
      1. Digest-Algorithmen
      2. Signaturalgorithmen
      3. Kanonisierungsalgorithmen
      4. Transformationsalgorithmen
      5. Schlüsselinformationen
      6. Auflösung von Referenzen
  6. Profil für CMS-Verschlüsselung
    1. Verschlüsselung
      1. Algorithmen
      2. Auflösung von Referenzen
    2. Entschlüsselung
      1. Algorithmen
        1. Schlüsseltransport
        2. Datenverschlüsselung
      2. Auflösung von Referenzen
  7. Profil für XML-Verschlüsselung
    1. Verschlüsselung
      1. Algorithmen
      2. Auflösung von Referenzen
    2. Entschlüsselung
      1. Algorithmen
        1. Algorithmen für xenc:EncryptedData
        2. Algorithmen für xenc:EncryptedKey
      2. Schlüsselhinweise
        1. Schlüsselhinweise in xenc:EncryptedData
        2. Schlüsselhinweise in xenc:EncryptedKey
      3. Auflösung von Referenzen
  8. Profil für Hashwerte
    1. Hashwert-Berechnung
      1. Digest-Algorithmen
      2. Auflösung von Referenzen
    2. Hashwert-Verifikation
      1. Digest-Algorithmen
      2. Auflösung von Referenzen
  9. Anzeigeformate und Zeichensätze
    1. Formate für die Anzeige der Bürgerkartenumgebung
      1. Text
      2. Standard-Anzeigeformat des Security-Layers
    2. Zeichensätze für das Schnittstellenprotokoll
  10. Referenzen
  11. Historie

1 Einführung

Dieses Dokument beschreibt die Anforderungen an eine minimale Umsetzung der Schnittstelle Security-Layer durch eine Bürgerkarten-Umgebung. Möchte eine Bürgerkarten-Umgebung konform zum Modell Bürgerkarte sein, muss sie alle in den nachfolgenden Kapiteln als erforderlich oder empfohlen gekennzeichneten Funktionalitäten umsetzen. Die Umsetzung von Funktionalitäten, die als empfohlen gekennzeichnet sind, darf in gut begründbaren Ausnahmefällen unterbleiben (vergleiche dazu die Bedeutung des Schlüsselworts empfohlen in [Keywords]).

1.1 Namenskonventionen

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
dsig http://www.w3.org/2000/09/xmldsig# Elemente aus [XMLDSIG]
dsm http://www.w3.org/2001/04/xmldsig-more# Elemente aus [ECDSA-XML]
xenc http://www.w3.org/2001/04/xmlenc# Elemente aus [XMLEnc]
sl http://www.buergerkarte.at/namespaces/securitylayer/1.2# 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 Schnittstellenbefehle, die in Applikationsschnittstelle Security-Layer spezifiziert sind. Für jeden dieser Schnittstellenbefehle gibt sie an, ob der Befehl in einer minimalen Umsetzung der Bürgerkarten-Umgebung enthalten sein muss (Anforderungs-Level erforderlich oder empfohlen) oder nicht (Anforderungs-Level optional).

Signaturbefehl Kommandonamen Anforderung
Signatur nach CMS erstellen sl:CreateCMSSignatureRequest
sl:CreateCMSSigantureResponse		 empfohlen
Signatur nach XMLDSIG erstellen sl:CreateXMLSignatureRequest
sl:CreateXMLSignatureResponse		 erforderlich
Signatur nach CMS prüfen sl:VerifyCMSSignatureRequest
sl:VerifyCMSSignatureResponse		 empfohlen
Signatur nach XMLDSIG prüfen sl:VerifyXMLSignatureRequest
sl:VerifyXMLSignatureResponse 		erforderlich
Verschlüsselung als CMS-Nachricht sl:EncryptCMSRequest
sl:EncryptCMSResponse		 empfohlen
Verschlüsselung als XML-Nachricht sl:EncryptXMLRequest
sl:EncryptXMLResponse		 empfohlen
Entschlüsselung einer CMS-Nachricht sl:DecryptCMSRequest
sl:DecryptCMSResponse		 empfohlen
Entschlüsselung einer XML-Nachricht sl:DecryptXMLRequest
sl:DecryptXMLResponse 		empfohlen
Hashwert-Berechnung sl:CreateHashRequest
sl:CreateHashResponse 		erforderlich
Hashwert-Verifikation sl:VerifyHashRequest
sl:VerifyHashResponse 		empfohlen
Abfrage verfügbarer Infoboxen sl:InfoboxAvailableRequest
sl:InfoboxAvailableResponse		 erforderlich
Anlegen einer Infobox sl:InfoboxCreateRequest
sl:InfoboxCreateResponse		 erforderlich
Löschen einer Infobox sl:InfoboxDeleteRequest
sl:InfoboxDeleteResponse		 erforderlich
Lesen von Infobox-Daten sl:InfoboxReadRequest
sl:InfoboxReadResponse		 erforderlich
Verändern von Infobox-Daten sl:InfoboxUpdateRequest
sl:InfoboxUpdateResponse		 erforderlich
Null-Operation sl:NullOperationRequest
sl:NullOperationResponse		 erforderlich
Abfrage der Umgebungseigenschaften sl:GetPropertiesRequest
sl:GetPropertiesResponse 		erforderlich
Abfrage des Tokenstatus sl:GetStatusRequest
sl:GetStatusResponse		 erforderlich

3 Transportprotokolle für den Security-Layer

Das Dokument Transportprotokolle Security-Layer beschreibt eine Reihe von möglichen Transportprotokollen für die Applikationsschnittstelle Security-Layer. Die nachfolgende Tabelle gibt für jedes dieser Transportprotokolle an, ob es in einer minimalen Umsetzung der Bürgerkarten-Umgebung enthalten sein muss (Anforderungs-Level erforderlich oder empfohlen) oder nicht (Anforderungs-Level optional).

Transportprotokoll Kontext
lokale BKU(1) serverbasierte BKU(1)
TCP/IP empfohlen optional
SSL/TLS optional optional
HTTP erforderlich optional
HTTPS erforderlich erforderlich

(1) Für die Unterscheidung zwischen lokaler und serverbasierter Bürgerkarten-Umgebung siehe Einführung in die österreichische Bürgerkarte, Abschnitt 1.

4 Profil für CMS-Signaturen

4.1 Signaturerstellung

Dieser Abschnitt spezifiziert ein Profil von [CMS], das von einer Bürgerkarten-Umgebung im Kontext des Befehls CreateCMSSignature verwendet werden muss.

4.1.11 Digest-Algorithmen

Zur Berechnung des Message Digest nach [CMS], Abschnitt 5.4 muss der Algoritmus SHA-1 nach [CMS-Alg], Abschnitt 2.1 verwendet werden.

4.1.2 Signaturalgorithmen

Der Algorithmus zur Berechnung des Signaturwerts nach [CMS], Abschnitt 5.5 ist abhängig vom Signaturschlüssel der Bürgerkarten-Umgebung, der im Befehl CreateCMSSignature spezifiziert wird. Für RSA-Schlüssel muss der Algorithmus nach [CMS-Alg], Abschnitt 3.2, für DSA-Schlüssel der Algorithmus nach [CMS-Alg], Abschnitt 3.1, und für ECDSA-Schlüssel der Algorithmus nach [ECDSA-CMS], Abschnitt 2.1.1 verwendet werden.

4.1.3 Schlüsselinformationen

In einer CMS-Signatur können Informationen zum Auffinden des Prüfschlüssels in Form einer Sammlung von X509-Zertifikaten im Feld certificates (vgl. [CMS], Abschnitt 5.1) angegeben werden. Die Bürgerkarten-Umgebung muss in diese Sammlung jedenfalls das Signatorzertifikat aufnehmen. Weiters wird empfohlen, die gesamte Kette an Zertifikaten, die zur Prüfung der Signatur benötigt wird (Signatorzertifikat bis zu einer vertrauenswürdigen Wurzelinstanz), ebenfalls in diese Sammlung aufzunehmen.

4.1.4 Auflösung von Referenzen

Die nachfolgende Tabelle spezifiziert die Anforderungslevels an die Bürgerkarten-Umgebung betreffend die Protokolle bei der Auflösung von Referenzen im Kontext des Befehls CreateCMSSignature.

Protokoll
Kontext
sl:DataObject/sl:Content/@Reference
http
erforderlich
https
erforderlich
formdata(1) erforderlich

(1) Vergleiche Transportprotokolle Security-Layer, Abschnitt 3.3.1.2.

4.2 Signaturprüfung

Dieser Abschnitt spezifiziert ein Profil von [CMS], das von einer Bürgerkarten-Umgebung im Kontext des Befehls VerifyCMSSignature mindestens beherrscht werden muss.

4.2.1 Digest-Algorithmen

Die Bürgerkarten-Umgebung muss alle in [CMS-Alg], Abschnitt 2 gelisteten Algorithmen zur Berechnung des Message Digest im Rahmen der Signaturprüfung nach [CMS], Abschnitt 5.6 unterstützen (SHA-1, MD5).

4.2.2 Signaturalgorithmen

Die nachfolgende Tabelle spezifiziert die Anforderungslevels an die Bürgerkarten-Umgebung betreffend die Unterstützung von Signaturalgorithmen im Rahmen der Signaturprüfung nach [CMS], Abschnitt 5.6.

Bezeichnung OID normative Referenz Anforderung
RSA { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } [CMS-Alg], 3.2 erforderlich
DSA { iso(1) member-body(2) us(840) x9-57 (10040) x9cm(4) 3 } [CMS-Alg], 3.1 erforderlich
ECDSA { iso(1) member-body(2) us(840) 10045 signatures(4) 1} [ECDSA-CMS], 2.2.1 erforderlich

4.2.3 Schlüsselinformationen

In einer CMS-Signatur können Informationen zum Auffinden des Prüfschlüssels in Form einer Sammlung von X509-Zertifikaten im Feld certificates (vgl. [CMS], Abschnitt 5.1) angegeben sein. Die Bürgerkarten-Umgebung darf diese Informationen zum Auffinden des Prüfschlüssels sowie zur Bildung der Zertifikatskette hin zu einer vertrauenswürdigen Wurzel verwenden.

Weiters können in einer CMS-Signatur Widerrufsinformationen in Form einer Sammlung von X509-Widerrufslisten im Feld crls (vgl. [CMS], Abschnitt 5.1) angegeben sein. Die Bürgerkarten-Umgebung darf diese Informationen zur Feststellung des Status eines Zertifikats im Rahmen der Validierung einer Zertifikatskette verwenden.

4.2.4 Auflösung von Referenzen

Die nachfolgende Tabelle spezifiziert die Anforderungslevels an die Bürgerkarten-Umgebung betreffend die Protokolle bei der Auflösung von Referenzen im Kontext des Befehls VerifyCMSSignature.

Protokoll
Kontext
sl:DataObject/sl:Content/@Reference
http
erforderlich
https
erforderlich
formdata(1) erforderlich

(1) Vergleiche Transportprotokolle Security-Layer, Abschnitt 3.3.1.2.

5 Profil für XML-Signaturen

5.1 Signaturerstellung

Dieser Abschnitt spezifiziert ein Profil von [XMLDSIG], das von einer Bürgerkarten-Umgebung im Kontext des Befehls CreateXMLSignature verwendet werden muss.

5.1.1 Digest-Algorithmen

Zur Berechnung von Message Digests in einer XML-Signatur muss der Algoritmus SHA-1 nach [XMLDSIG], Abschnitt 6.2.1 verwendet werden.

5.1.2 Signaturalgorithmen

Der Algorithmus zur Berechnung des Signaturwerts nach [XMLDSIG], Abschnitt 3.1.2 ist abhängig vom Signaturschlüssel der Bürgerkarten-Umgebung, der im Befehl CreateXMLSignature spezifiziert wird. Für RSA-Schlüssel muss der Algorithmus nach [XMLDSIG], Abschnitt 6.4.2, für DSA-Schlüssel der Algorithmus nach [XMLDSIG], Abschnitt 6.4.1, und für ECDSA-Schlüssel der Algorithmus nach [ECDSA-XML], Abschnitt 3 verwendet werden.

5.1.3 Kanonisierungsalgorithmen

Die nachfolgende Tabelle spezifiziert die Anforderungslevels an die Bürgerkarten-Umgebung betreffend die Unterstützung von Kanonisierungsalgorithmen im Kontext des Befehls CreateXMLSignature.

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

5.1.4 Transformationsalgorithmen

Die nachfolgende Tabelle spezifiziert die Anforderungslevels an die Bürgerkarten-Umgebung betreffend die Unterstützung von Transformationsalgorithmen im Kontext des Befehls CreateXMLSignature.

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 Filer 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
Binary Mode Decryption http://www.w3.org/2002/07/decrypt#Binary [XMLDecTF], 4 optional
XML Mode Decryption(1) http://www.w3.org/2002/07/decrypt#XML [XMLDecTF], 3 optional

(1) Bei der Verwendung einer XML Mode Decryption Transformation im Zuge der Erstellung einer XML-Signatur muss die Bürgerkarten-Umgebung den Mechanismus aus [XMLDecTF], Abschnitt 3.2 verwenden.

5.1.5 Schlüsselinformationen

In einer XML-Signatur können Informationen zum Auffinden des Prüfschlüssels im XML-Element dsig:KeyInfo (vgl. [XMLDSIG], Abschnitt 4.4) angegeben werden. Die Bürgerkarten-Umgebung muss in dieses XML-Element jedenfalls das Signatorzertifikat aufnehmen. Weiters wird empfohlen, die gesamte Kette an Zertifikaten, die zur Prüfung der Signatur benötigt wird (Signatorzertifikat bis zu einer vertrauenswürdigen Wurzelinstanz), ebenfalls in dieses XML-Element aufzunehmen.

5.1.6 Auflösung von Referenzen

Die nachfolgende Tabelle spezifiziert die Anforderungslevels an die Bürgerkarten-Umgebung betreffend die Protokolle bei der Auflösung von Referenzen im Kontext des Befehls CreateXMLSignature.

Protokoll http https formdata ID-Referenz XPointer-Referenz(2)
K
o
n
t
e
x
t		 sl:DataObjectInfo/
sl:DataObject/
@Reference
erforderlich
 erforderlich erforderlich erforderlich empfohlen
sl:DataObjectInfo/
sl:DataObject/
sl:LocRefContent
erforderlich
 erforderlich erforderlich n.a. n.a.
Importierte Stylesheets(1) erforderlich erforderlich erforderlich n.a. n.a.
sl:DataObjectInfo/
sl:Supplement/
sl:Content/
sl:LocRefContent		 erforderlich erforderlich erforderlich n.a. n.a.
sl:SignatureInfo/
sl:SignatureEnvironment/
@Reference 		erforderlich erforderlich erforderlich n.a. n.a.
sl:SignatureInfo/
sl:Supplement/
sl:Content/
sl:LocRefContent 		erforderlich erforderlich erforderlich n.a. n.a.

(1) Stylesheet-Imports, die in einer XSLT-Transformation zu einem Datenobjekt angegeben sind.

(2) XPointer nach [XPointerFW], die xmlns (vgl. [XPointerNS]) und element (vgl. [XPointerEL]) XPointer Parts enthalten.

5.2 Signaturprüfung

Dieser Abschnitt spezifiziert ein Profil von [XMLDSIG], das von einer Bürgerkarten-Umgebung im Kontext des Befehls VerifyXMLSignature mindestens beherrscht werden muss.

5.2.1 Digest-Algorithmen

Die Bürgerkarten-Umgebung muss alle in [XMLDSIG], Abschnitt 6.2 gelisteten Algorithmen zur Berechnung des Message Digest im Rahmen der Signaturprüfung nach [XMLDSIG], Abschnitt 3.2 unterstützen (SHA-1).

5.2.2 Signaturalgorithmen

Die nachfolgende Tabelle spezifiziert die Anforderungslevels an die Bürgerkarten-Umgebung betreffend die Unterstützung von Signaturalgorithmen im Rahmen der Signaturprüfung nach [XMLDSIG], Abschnitt 3.2.

Bezeichnung URI normative Referenz Anforderung
RSA-SHA1 http://www.w3.org/2000/09/xmldsig#dsa-sha1 [XMLDSIG], 6.4.2 erforderlich
DSA-SHA1 http://www.w3.org/2000/09/xmldsig#rsa-sha1 [CMS-Alg], 6.4.1 erforderlich
ECDSA-SHA1 http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1 [ECDSA-XML], 3 erforderlich

5.2.3 Kanonisierungsalgorithmen

Für die Tabelle der Anforderungslevels an die Bürgerkarten-Umgebung betreffend die Unterstützung von Kanonisierungsalgorithmen im Rahmen der Signaturprüfung nach [XMLDSIG], Abschnitt 3.2 siehe Abschnitt 5.1.3.

5.2.4 Transformationsalgorithmen

Für die Tabelle der Anforderungslevels an die Bürgerkarten-Umgebung betreffend die Unterstützung von Transformationsalgorithmen im Rahmen der Signaturprüfung nach [XMLDSIG], Abschnitt 3.2 siehe Abschnitt 5.1.4.

Für diese beiden Tranformationen Binary Mode Decryption und XML Mode Decryption gelten sinngemäß die Vorgaben aus Applikationsschnittstelle Security-Layer, Abschnitt 5.2 sowie jene aus diesem Dokument, Abschnitt 7.2.

5.2.5 Schlüsselinformationen

In einer XML-Signatur können Informationen zum Auffinden des Prüfschlüssels im XML-Element dsig:KeyInfo (vgl. [XMLDSIG], Abschnitt 4.4) angegeben sein. Die nachfolgende Tabelle spezifiziert die Anforderungslevels an die Bürgerkarten-Umgebung betreffend die Unterstützung von XML-Elementen, die darin vorkommen können. Alle nicht explizit in der Tabelle erwähnten XML-Elemente dürfen von der Bürgerkarten-Umgebung ausgewertet werden.

Kindelement Anforderung Anmerkung
dsig:RSAKeyValue empfohlen -
dsig:DSAKeyValue empfohlen -
dsm:ECDSAKeyValue empfohlen -
dsig:X509IssuerSerial empfohlen Dieses XML-Element bezeichnet auf eindeutige Weise ein Zertifikat. Damit kann die Bürgerkarten-Umgebung ggf. ein Zertifikat aus dem eigenen Cache zuordnen.
dsig:X509Certificate erforderlich -
dsig:X509CRL erforderlich Eine mit diesem XML-Element kodierte Widerrufsliste muss zwar von der Bürgerkarten-Umgebung verstanden, aber nicht notwendigerweise verwendet werden (z.B. weil eine aktuellere Widerrufsliste von einem Verteilungspunkt abgerufen werden kann).
dsig:RetrievalMethod mit Verweis auf dsig:X509Data erforderlich Für die XML-Kindelemente des dsig:X509Data, auf das verwiesen wird, gelten wiederum die Anforderungslevels dieser Tabelle.
dsig:RetrievalMethod mit direktem Verweis auf ein X509- Zertifikat erforderlich -

5.2.6 Auflösung von Referenzen

Die nachfolgende Tabelle spezifiziert die Anforderungslevels an die Bürgerkarten-Umgebung betreffend die Protokolle bei der Auflösung von Referenzen im Kontext des Befehls VerifyXMLSignature.

Protokoll http https ldap formdata ID-Referenz XPointer-Referenz(2)
K
o
n
t
e
x
t		 sl:SignatureInfo/
sl:SignatureEnvironment/
@Reference
erforderlich
 erforderlich optional erforderlich n.a. n.a.
sl:Supplement/
sl:Content/
sl:LocRefContent
erforderlich
 erforderlich optional erforderlich n.a. n.a.
Importierte Stylesheets(1) erforderlich erforderlich optional erforderlich n.a. n.a.
dsig:Signature/
dsig:SignedInfo/
dsig:Reference/
@URI 		erforderlich erforderlich optional erforderlich erforderlich empfohlen
dsig:Manifest/
dsig:Reference/
@URI 		erforderlich erforderlich optional erforderlich erforderlich empfohlen
dsig:Signature/
dsig:KeyInfo/
dsig:RetrievalMethod/
@URI 		erforderlich erforderlich erforderlich erforderlich erforderlich empfohlen

(1) Stylesheet-Imports, die in einer XSLT-Transformation der XML-Signatur enthalten sind.

(2) XPointer nach [XPointerFW], die xmlns (vgl. [XPointerNS]) und element (vgl. [XPointerEL]) XPointer Parts enthalten.

6 Profil für CMS-Verschlüsselung

6.1 Verschlüsselung

Dieser Abschnitt spezifiziert ein Profil von [CMS], das von einer Bürgerkarten-Umgebung im Kontext des Befehls EncryptCMS verwendet werden muss.

6.1.1 Algorithmen

Für erzeugte verschlüsselte CMS-Nachrichten muss eine Bürgerkarten-Umgebung für den Schlüsseltransport bzw. für die Datenverschlüsselung einen der in den Abschnitten 6.2.1.1 bzw. 6.2.1.2 genannten Algorithmen verwenden.

Angesichts der weiten Verbreitung wird derzeit empfohlen, für den Schlüsseltransport den Algorithmus PKCS #1 v1.5, sowie für die Datenverschlüsselung den Algorithmus Triple DES CBC zu verwenden.

6.1.2 Auflösung von Referenzen

Die nachfolgende Tabelle spezifiziert die Anforderungslevels an die Bürgerkarten-Umgebung betreffend die Protokolle bei der Auflösung von Referenzen.

Protokoll
Kontext
sl:ToBeEncrypted/@Reference
http
erforderlich
https
erforderlich
formdata(1) erforderlich

(1) Vergleiche Transportprotokolle Security-Layer, Abschnitt 3.3.1.2

6.2 Entschlüsselung

Dieser Abschnitt spezifiziert ein Profil von [CMS], das von einer Bürgerkarten-Umgebung im Kontext des Befehls DecryptCMS mindestens beherrscht werden muss.

6.2.1 Algorithmen

Dieser Abschnitt spezifiziert die Anforderungslevels an die Bürgerkarten-Umgebung betreffend die Unterstützung von Algorithmen in der zu entschlüsselnden CMS-Nachricht. Prinzipiell muss eine Bürgerkarten-Umgebung hinsichtlich der Verschlüsselung des Datenverschlüsselungsschlüssels nur den Schlüsseltransport zu unterstützen. Deshalb werden in diesem Abschnitt auch keine Angaben zu anderen Techniken des Schlüsselmanagements gemacht.

6.2.1.1 Schlüsseltransport

Die nachfolgende Tabelle spezifiziert die Anforderungslevels an die Bürgerkarten-Umgebung betreffend die Unterstützung von Algorithmen zum Schlüsseltransport (Feld ktri der CMS-Nachricht).

Bezeichnung
OID
normative Referenz
Anforderung
PKCS #1 v1.5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 } [CMS-Alg], 4.2.1 erforderlich
RSAES-OAEP { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 } [CMS-RSAES-OAEP] empfohlen

6.2.1.2 Datenverschlüsselung

Die nachfolgende Tabelle spezifiziert die Anforderungslevels an die Bürgerkarten-Umgebung betreffend die Unterstützung von Algorithmen zur Datenverschlüsselung (Feld contentEncryptionAlgorithm der CMS-Nachricht).

Bezeichnung
OID
normative Referenz
Anforderung
Triple-DES CBC { des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 7 } [CMS-Alg], 5.1 erforderlich
AES CBC 128 Bit { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithms(4) 1 2 } [CMS-AES] empfohlen
AES CBC 256 Bit { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithms(4) 1 42 } [CMS-AES] empfohlen

6.2.2 Auflösung von Referenzen

Die nachfolgende Tabelle spezifiziert die Anforderungslevels an die Bürgerkarten-Umgebung betreffend die Protokolle bei der Auflösung von Referenzen.

Protokoll
Kontext
sl:EncryptedContent/sl:Content/@Reference
http
erforderlich
https
erforderlich
formdata(1) erforderlich

(1) Vergleiche Transportprotokolle Security-Layer, Abschnitt 3.3.1.2.

7 Profil für XML-Verschlüsselung

7.1 Verschlüsselung

Dieser Abschnitt spezifiziert ein Profil von [XMLEnc], das von einer Bürgerkarten-Umgebung im Kontext des Befehls EncryptXML verwendet werden muss.

7.1.1 Algorithmen

Für erzeugte verschlüsselte XML-Nachrichten muss die Bürgerkarten-Umgebung für die Datenverschlüsselung einen der im Abschnitt 7.2.1.1 genannten Algorithmen für Blockverschlüsselung bzw. für den Schlüsseltransport einen der in Abschnitt 7.2.1.2 genannten Algorithmen verwenden.

Angesichts der weiten Verbreitung wird derzeit empfohlen, für den Schlüsseltransport den Algorithmus RSA Version 1.5, sowie für die Datenverschlüsselung den Algorithmus Triple DES zu verwenden.

7.1.2 Auflösung von Referenzen

Die nachfolgende Tabelle spezifiziert die Anforderungslevels an die Bürgerkarten-Umgebung betreffend die Protokolle bei der Auflösung von Referenzen.

Protokoll
Kontext
sl:ToBeEncrypted/
sl:New/
sl:LocRefContent		 sl:EncryptionInfo/
sl:EncryptionEnvironment/
@Reference		 sl:EncryptionInfo/
sl:Supplement/
sl:Content/
sl:LocRefContent
http erforderlich erforderlich erforderlich
https erforderlich erforderlich erforderlich
formdata(1) erforderlich erforderlich erforderlich

(1) Vergleiche Transportprotokolle Security-Layer, Abschnitt 3.3.1.2

7.2 Entschlüsselung

Dieser Abschnitt spezifiziert ein Profil von [XMLEnc], das von einer Bürgerkarten-Umgebung im Kontext des Befehls DecryptXML mindestens beherrscht werden muss.

7.2.1 Algorithmen

7.2.1.1 Algorithmen für xenc:EncryptedData

Die nachfolgende Tabelle spezifiziert die Anforderungslevels an die Bürgerkarten-Umgebung betreffend Algorithmen in xenc:EncryptedData/xenc:EncryptionMethod/@Algorithm.

Bezeichnung
URI
normative Referenz
Anforderung
Blockverschlüsselung
Triple DES http://www.w3.org/2001/04/xmlenc#tripledes-cbc [XMLEnc], 5.2.1 erforderlich
AES CBC 128 Bit http://www.w3.org/2001/04/xmlenc#aes128-cbc [XMLEnc], 5.2.2 erforderlich
AES CBC 256 Bit http://www.w3.org/2001/04/xmlenc#aes256-cbc [XMLEnc], 5.2.2 erforderlich
Schlüsseltransport (1)
RSA Version 1.5 http://www.w3.org/2001/04/xmlenc#rsa-1_5 [XMLEnc], 5.4.1 erforderlich
RSA-OAEP http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p [XMLEnc], 5.4.2 erforderlich

(1)Siehe Hinweis in [XMLEnc], Abschnitt 5.4.

7.2.1.2 Algorithmen für xenc:EncryptedKey

Die nachfolgende Tabelle spezifiziert die Anforderungslevels an die Bürgerkarten-Umgebung betreffend Algorithmen in xenc:EncryptedKey/xenc:EncryptionMethod/@Algorithm.

Bezeichnung
URI
normative Referenz
Anforderung
Schlüsseltransport
RSA Version 1.5 http://www.w3.org/2001/04/xmlenc#rsa-1_5 [XMLEnc], 5.4.1 erforderlich
RSA-OAEP http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p [XMLEnc], 5.4.2 erforderlich

7.2.2 Schlüsselhinweise

7.2.2.1 Schlüsselhinweise in xenc:EncryptedData

Die nachfolgende Tabelle spezifiziert die Anforderungslevels an die Bürgerkarten-Umgebung betreffend Schlüsselhinweise in xenc:EncryptedData/dsig:KeyInfo.

Elementname
Anmerkung
normative Referenz
Anforderung
dsig:KeyName Muss den KeyboxIdentifier eines in der Bürgerkarten-Umgebung vorhandenen Schlüsselpaares enthalten, das für Verschlüsselung geeignet ist. [XMLDSIG], 4.4.1 erforderlich
dsig:KeyValue Muss den öffentlichen Schlüssel eines in der Bürgerkarten-Umgebung vorhandenen Schlüsselpaares enthalten, das für Verschlüsselung geeignet ist. [XMLDSIG], 4.4.2 erforderlich
dsig:X509Data Muss genau ein Element dsig:X509Certificate mit dem Zertifikat für den öffentlichen Schlüssel eines in der Bürgerkarten-Umgebung vorhandenen Schlüsselpaares enthalten. [XMLDSIG], 4.4.4 erforderlich
xenc:EncryptedKey   [XMLEnc], 3.5.1 erforderlich
dsig:RetrievalInfo Muss auf ein Element xenc:EncryptedKey im gleichen XML-Dokument verweisen. Transformationen müssen von der Bürgerkarten-Umgebung nicht unterstützt werden. [XMLEnc], 3.5.2 erforderlich

7.2.2.2 Schlüsselhinweise in xenc:EncryptedKey

Die nachfolgende Tabelle spezifiziert die Anforderungslevels an die Bürgerkarten-Umgebung betreffend Schlüsselhinweise in xenc:EncryptedKey/dsig:KeyInfo.

Elementname Anmerkung normative Referenz Anforderung
dsig:KeyName Muss den KeyboxIdentifier eines in der Bürgerkarten-Umgebung vorhandenen Schlüsselpaares enthalten, das für Verschlüsselung geeignet ist. [XMLDSIG], 4.4.1 erforderlich
dsig:KeyValue Muss den öffentlichen Schlüssel eines in der Bürgerkarten-Umgebung vorhandenen Schlüsselpaares enthalten, das für Verschlüsselung geeignet ist. [XMLDSIG], 4.4.2 erforderlich
dsig:X509Data Muss genau ein Element dsig:X509Certificate mit dem Zertifikat für den öffentlichen Schlüssel eines in der Bürgerkarten-Umgebung vorhandenen Schlüsselpaares enthalten. [XMLDSIG], 4.4.4 erforderlich

7.2.3 Auflösung von Referenzen

Die nachfolgende Tabelle spezifiziert die Anforderungslevels an die Bürgerkarten-Umgebung betreffend die Protokolle bei der Auflösung von Referenzen in unterschiedlichen Kontexten.

Protokoll
Kontext
dsig:RetrievalMethod xenc:EncryptedData/
xenc:Value		 xenc:EncryptedKey/
xenc:Value		 sl:Supplement/
sl:Content/
sl:LocRefContent
http
optional
erforderlich
erforderlich
erforderlich
https
optional
erforderlich
erforderlich
erforderlich
formdata(1)
optional
erforderlich
erforderlich
erforderlich
relative URI(2)
optional(4)
erforderlich(4)
erforderlich(4)
darf nicht
ID-Referenz(3)
erforderlich
optional
optional
darf nicht

(1) Vergleiche Transportprotokolle Security-Layer, Abschnitt 3.3.1.2.

(2) Eine relative URI ist eine URI, die keinen Protokoll-Teil enthält (vgl. [RFC2396], 3.1).

(3) Eine ID-Referenz ist eine Same Document Reference nach [RFC2396], 4.2, die den Wert eines Attributs vom Typ IDREF nach [XML] enthält.

(4) Eine relative URI darf nur über ein für diese URI angegebenes Supplement aufgelöst werden; eine direkte Auflösung (z.B. über ein Absolut-Machen gegen das lokale Dateisystem) darf nicht erfolgen.

8 Profil für Hashwerte

8.1 Hashwert-Berechnung

Dieser Abschnitt spezifiziert ein Profil für den Befehl CreateHash, das von einer Bürgerkarten-Umgebung mindestens beherrscht werden muss.

8.1.1 Digest-Algorithmen

Die Bürgerkarten-Umgebung muss alle in [XMLDSIG], Abschnitt 6.2 gelisteten Algorithmen zur Berechnung des Message Digest unterstützen (SHA-1).

8.1.2 Auflösung von Referenzen

Die nachfolgende Tabelle spezifiziert die Anforderungslevels an die Bürgerkarten-Umgebung betreffend die Protokolle bei der Auflösung von Referenzen.

Protokoll
Kontext
sl:HashInfo/
sl:HashData/
sl:Content/
@Reference
http erforderlich
https erforderlich
formdata(1) erforderlich

(1) Vergleiche Transportprotokolle Security-Layer, Abschnitt 3.3.1.2

8.2 Hashwert-Verifikation

Dieser Abschnitt spezifiziert ein Profil für den Befehl VerifyHash, das von einer Bürgerkarten-Umgebung mindestens beherrscht werden muss.

8.2.1 Digest-Algorithmen

Die Bürgerkarten-Umgebung muss alle in [XMLDSIG], Abschnitt 6.2 gelisteten Algorithmen zur Berechnung des Message Digest unterstützen (SHA-1).

8.2.2 Auflösung von Referenzen

Die nachfolgende Tabelle spezifiziert die Anforderungslevels an die Bürgerkarten-Umgebung betreffend die Protokolle bei der Auflösung von Referenzen.

Protokoll
Kontext
sl:HashInfo/
sl:HashData/
sl:Content/
@Reference
http erforderlich
https erforderlich
formdata(1) erforderlich

(1) Vergleiche Transportprotokolle Security-Layer, Abschnitt 3.3.1.2

9 Anzeigeformate und Zeichensätze

9.1 Formate für die Anzeige der Bürgerkarten-Umgebung

Für die Abarbeitung der Schnittstellenbefehle zur Signaturerstellung (CreateCMSSignature, CreateXMLSignature) sowie zur Signaturprüfung (VerifyCMSSignature, VerifyXMLSignature) benötigt die Bürgerkarten-Umgebung eine Anzeige, um dem Bürger die zu signierenden bzw. die signierten Daten darstellen zu können. Dieser Abschnitt legt fest, welche Anzeigeformate die Anzeige der Bürgerkarten-Umgebung jedenfalls unterstützen muss.

9.1.1 Text

Als einfaches Format muss die Anzeige der Bürgerkarten-Umgebung die Darstellung von Text beherrschen. Die nachfolgende Tabelle listet jene Unicode-Zeichen [Unicode] auf, die jedenfalls dargestellt werden können müssen.

Anmerkung: Es handelt sich dabei um jene Zeichen, die notwendig sind, um die Zeichensätze [ISO-8859-1], [ISO-8859-2], [ISO-8859-3], [ISO-8859-9], [ISO-8859-10] und [ISO-8859-15] mit Ausnahme der meisten dort enthaltenen Steuerzeichen darstellen zu können.

Code Chart Zeichennummer(n) Code Chart Zeichennummer(n)
C0 Controls and Basic Latin 0x0009-0x000A Latin Extended-A 0x014A-0x014D
C0 Controls and Basic Latin 0x000C-0x000D Latin Extended-A 0x0150-0x0155
C0 Controls and Basic Latin 0x0020-0x007E Latin Extended-A 0x0158-0x0173
C1 Controls and Latin-1 Supplement 0x00A1-0x00FF Latin Extended-A 0x0178-0x017E
Latin Extended-A 0x0100-0x0114 Spacing Modifier Letters 0x02C7
Latin Extended-A 0x0116-0x012B Spacing Modifier Letters 0x02D8-0x02D9
Latin Extended-A 0x012E-0x0131 Spacing Modifier Letters 0x02DB
Latin Extended-A 0x0134-0x013E Spacing Modifier Letters 0x02DD
Latin Extended-A 0x0141-0x0148 General Punctuation 0x2015

Folgende Daten muss die Bürgerkarten-Umgebung versuchen, als Text zu interpretieren:

Für die Darstellung von Text muss die Bürgerkarten-Umgebung eine Schriftart mit konstanter Breite für jedes Zeichen (monospaced) verwenden. Für das Zeichen 0x0009 (Tabulator) muss die Bürgerkarten-Umgebung eine Tabulatorbreite von acht Zeichen verwenden.

9.1.2 Standard-Anzeigeformat des Security-Layers

Als Format für die Darstellung von komplexeren Dokumenten muss die Bürgerkarten-Umgebung die Darstellung des Standard-Anzeigeformats beherrschen. Hinsichtlich der Zeichen, die die Bürgerkarten-Umgebung jedenfalls darstellen können muss, gelten die Vorgaben aus Abschnitt 9.1.1.

Folgende Daten muss die Bürgerkarten-Umgebung versuchen, im Sinne dieses Formats zu interpretieren:

9.2 Zeichensätze für das Schnittstellenprotokoll

Beim Empfang von Anfrage-Befehlen über die Schnittstelle des Security-Layer muss die Bürgerkarten-Umgebung die drei Zeichensätze ISO-8859-1 [ISO-8859-1], ISO-8859-15 [ISO-8859-15] sowie UTF-8 [Unicode] unterstützen. Die Applikation muss den verwendeten Zeichensatz in der XML-Deklaration des XML-Dokuments angeben, welches den Anfrage-Befehl beinhaltet.

10 Referenzen

CMS
Hously, R.: RFC 3369: Cryptographic Message Syntax (CMS). IETF Request For Comment, August 2002. Abgerufen aus dem World Wide Web am 14. 05. 2004 unter http://www.ietf.org/rfc/rfc3369.txt.
CMS-AES
Schaad, J.: RFC 3565: Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS). IETF Request For Comment, Juli 2003. Abgerufen aus dem World Wide Web am 14. 05. 2004 unter http://www.ietf.org/rfc/rfc3565.txt.
CMS-Alg
Hously, R.: RFC 3370: Cryptographic Message Syntax (CMS) Algorithms. IETF Request For Comment, August 2002. Abgerufen aus dem World Wide Web am 14. 05. 2004 unter http://www.ietf.org/rfc/rfc3370.txt.
CMS-RSAES-OAEP
Hously, R.: RFC 3560: Use of the RSAES-OAEP Key Transport Algorithm in the Cryptographic Message Syntax (CMS). IETF Request For Comment, Juli 2003. Abgerufen aus dem World Wide Web am 14. 05. 2004 unter http://www.ietf.org/rfc/rfc3560.txt.
EC14N
Boyer, John, Eastlake, Donald und Reagle, Joseph: Exclusive XML Canonicalization. W3C Recommendation, Juli 2002. Abgerufen aus dem World Wide Web am 14. 05. 2004 unter http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/.
ECDSA-CMS
Blake-Wilson, S., Brown, D., Lampert, D.: RFC 3278: Use of Elliptic Curve Cryptography (ECC) Algorithms
in Cryptographic Message Syntax (CMS). IETF Request For Comment, April 2002. Abgerufen aus dem World Wide Web am 14. 05. 2004 unter http://www.ietf.org/rfc/rfc3278.txt.
ECDSA-XML
Blake-Wilson, S., Karlinger, G. und Wang, Y.: ECDSA with XML-Signature Syntax. Internet-Draft, Jänner 2004. Abgerufen aus dem World Wide Web am 14. 05. 2004 unter http://www.ietf.org/internet-drafts/draft-blake-wilson-xmldsig-ecdsa-08.txt.
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-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.
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.
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.
MIME
Freed, N. und Borenstein, N.: RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. IETF Request For Comment, November 1996. Abgerufen aus dem World Wide Web am 14. 05. 2004 unter http://www.ietf.org/rfc/rfc2046.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 14. 05. 2004 unter http://www.ietf.org/rfc/rfc2396.txt.
XML
Bray, Tim, Paoli, Jean, Sperberg-McQueen, C.M. und Maler, Eve: Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation, Oktober 2000. Abgerufen aus dem World Wide Web am 14. 05. 2004 unter http://www.w3.org/TR/2000/REC-xml-20001006.
XMLDecTF
Hughes, Merlin, Imamura, Takeshi und Maruyama, Hiroshi: Decryption Transform for XML Signature. W3C Recommendation, Dezember 2002. Abgerufen aus dem World Wide Web am 14. 05. 2004 unter http://www.w3.org/TR/2002/REC-xmlenc-decrypt-20021210.
XMLEnc
Eastlake, Donald und Reagle, Joseph: XML Encryption Syntax and Processing. W3C Recommendation, Dezember 2002. Abgerufen aus dem World Wide Web am 14. 05. 2004 unter http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/.
XMLDSIG
Eastlake, Donald, Reagle, Joseph und Solo, David: XML-Signature Syntax and Processing. W3C Recommendation, Februar 2002. Abgerufen aus dem World Wide Web am 14. 05. 2004 unter http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/.
XPointer-EL
Grosso, Paul, Maler, Eve, Marsh, Jonathan und Walsh, Norman: XPointer Framework. W3C Recommendation, März 2003. Abgerufen aus dem World Wide Web am 14. 05. 2004 unter http://www.w3.org/TR/2003/REC-xptr-element-20030325/.
XPointer-FW
Grosso, Paul, Maler, Eve, Marsh, Jonathan und Walsh, Norman: XPointer Framework. W3C Recommendation, März 2003. Abgerufen aus dem World Wide Web am 14. 05. 2004 unter http://www.w3.org/TR/2003/REC-xptr-framework-20030325/.
XPointer-NS
DeRose, Steven J., Daniel, Ron Jr, Marsh, Jonathan und Walsh, Norman: XPointer Framework. W3C Recommendation, März 2003. Abgerufen aus dem World Wide Web am 14. 05. 2004 unter http://www.w3.org/TR/2003/REC-xptr-xmlns-20030325/.
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). Abgerufen aus dem World Wide Web am 14. 05. 2004 unter http://www.unicode.org/versions/Unicode4.0.0/.
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 14. 05. 2004 unter http://www.w3.org/TR/2002/CR-xmldsig-filter2-20020718/.

11 Historie

Datum
Version
 Änderungen
29.02.2004
1.2.0
  • Erratum 3 laut Errata-Dokument ausgebessert.
  • Schnittstellenbefehl CreateSymmetricSecret aus Liste der Schnittstellenbefehle entfernt.
  • Schnittstellenbefehle EncryptCMS, EncryptXML, DecryptCMS, DecryptXML, CreateHash, VerifyHash, InfoboxCreate, InfoboxDelete, NullOperation in die Liste der Schnittstellenbefehle hinzugefügt.
  • Abschnitte 4 über Profil für CMS-Signaturen hinzugefügt.
  • Ehemaligen Abschnitt 3 über XML-Signaturen in Abschnitt 5 neu organisert (Trennung in Erstellung und Prüfung).
  • Abschnitte 6 und 7 über Profil für CMS-Verschlüsselung und XML-Verschlüsselung hinzugefügt.
  • Abschnitt 8 über Profil für Hashwert-Berechnung und -Verifikation hinzugefügt.
  • Abschnitt 9 über Anzeigeformate und Zeichensätze hinzugefügt.
  • Ehemaligen Abschnitt 8 in Unterkapitel der Abschnitte 4 bis 7 eingegliedert.
31.08.2002
1.1.0
  • Schnittstellenbefehle Signaturerstellung und Signaturprüfung nach CMS von erforderlich auf empfohlen geändert.
  • Schnittstellenbefehl zur Erzeugung eines Sitzungszertifikats entfernt.
  • Profil für XML-Signaturen (Prüfung einer XML-Signatur, Erstellung einer XML-Signatur, Aushandeln eines symmetrischen Geheimnisses) hinzugefügt.
  • Anforderungen an die Auflösung von URIs in Request-Befehlen und zu prüfenden XML-Signaturen hinzugefügt.
  • Abschnitt 1.1 Namenskonventionen hinzugefügt.
n class="glossaryTerm">Bürgerkarten-Umgebung betreffend die Protokolle bei der Auflösung von Referenzen im Kontext des Befehls CreateXMLSignature.

Protokoll http https formdata ID-Referenz XPointer-Referenz(2)
K
o
n
t
e
x
t		 sl:DataObjectInfo/
sl:DataObject/
@Reference
erforderlich
 erforderlich erforderlich erforderlich empfohlen
sl:DataObjectInfo/
sl:DataObject/
sl:LocRefContent
erforderlich
 erforderlich erforderlich n.a. n.a.
Importierte Stylesheets(1) erforderlich erforderlich erforderlich n.a. n.a.
sl:DataObjectInfo/
sl:Supplement/
sl:Content/
sl:LocRefContent		 erforderlich erforderlich erforderlich n.a. n.a.
sl:SignatureInfo/
sl:SignatureEnvironment/
@Reference 		erforderlich erforderlich erforderlich n.a. n.a.
sl:SignatureInfo/
sl:Supplement/
sl:Content/
sl:LocRefContent 		erforderlich erforderlich erforderlich n.a. n.a.

(1) Stylesheet-Imports, die in einer XSLT-Transformation zu einem Datenobjekt angegeben sind.

(2) XPointer nach [XPointerFW], die xmlns (vgl. [XPointerNS]) und element (vgl. [XPointerEL]) XPointer Parts enthalten.

5.2 Signaturprüfung

Dieser Abschnitt spezifiziert ein Profil von [XMLDSIG], das von einer Bürgerkarten-Umgebung im Kontext des Befehls VerifyXMLSignature mindestens beherrscht werden muss.

5.2.1 Digest-Algorithmen

Die Bürgerkarten-Umgebung muss alle in [XMLDSIG], Abschnitt 6.2 gelisteten Algorithmen zur Berechnung des Message Digest im Rahmen der Signaturprüfung nach [XMLDSIG], Abschnitt 3.2 unterstützen (SHA-1).

5.2.2 Signaturalgorithmen

Die nachfolgende Tabelle spezifiziert die Anforderungslevels an die Bürgerkarten-Umgebung betreffend die Unterstützung von Signaturalgorithmen im Rahmen der Signaturprüfung nach [XMLDSIG], Abschnitt 3.2.

Bezeichnung URI normative Referenz Anforderung
RSA-SHA1 http://www.w3.org/2000/09/xmldsig#dsa-sha1 [XMLDSIG], 6.4.2 erforderlich
DSA-SHA1 http://www.w3.org/2000/09/xmldsig#rsa-sha1 [CMS-Alg], 6.4.1 erforderlich
ECDSA-SHA1 http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1 [ECDSA-XML], 3 erforderlich

5.2.3 Kanonisierungsalgorithmen

Für die Tabelle der Anforderungslevels an die Bürgerkarten-Umgebung betreffend die Unterstützung von Kanonisierungsalgorithmen im Rahmen der Signaturprüfung nach [XMLDSIG], Abschnitt 3.2 siehe Abschnitt 5.1.3.

5.2.4 Transformationsalgorithmen

Für die Tabelle der Anforderungslevels an die Bürgerkarten-Umgebung betreffend die Unterstützung von Transformationsalgorithmen im Rahmen der Signaturprüfung nach [XMLDSIG], Abschnitt 3.2 siehe Abschnitt 5.1.4.

Für diese beiden Tranformationen Binary Mode Decryption und XML Mode Decryption gelten sinngemäß die Vorgaben aus Applikationsschnittstelle Security-Layer, Abschnitt 5.2 sowie jene aus diesem Dokument, Abschnitt 7.2.

5.2.5 Schlüsselinformationen

In einer XML-Signatur können Informationen zum Auffinden des Prüfschlüssels im XML-Element dsig:KeyInfo (vgl. [XMLDSIG], Abschnitt 4.4) angegeben sein. Die nachfolgende Ta