h1. EID-Server-Issues
h2. media transfer AG
(Adresse der Anwendung: http://willow.mtg.de/eidavs/static/index.html)
Neue Adresse der Anwendung: https://willow.mtg.de/eid-server-demo-app/index.html
Adresse eID-Server: https://fry.mtg.de:443
h3. Protocol-URI
In AuthenticationProtocolData der DIDAuthenticate-PAOS-Nachrichten für EAC fehlt die Protocol-URI.
h3. StartPAOS
Server verlangt in dem ConnectionHandle ein SlotHandle. Fehler "SlotHandle is not set". Log File siehe "hier":https://redmine.vserver-001.urospace.de/attachments/55/MTG%20Server%20Debug.txt
h3. TLS
Kein TLS1.1 oder höher.
h3. TCToken
Das Element "ServerAddress" ist keine URL.
fry.mtg.de:443
h2. bremen online services GmbH & Co KG
Adresse der Anwendung: https://test.governikus-eid.de/Autent-DemoApplication/
Adresse eID-Server: https://testpaos.governikus-eid.de:443
Abweichungen:
1. Die Protocol-URI in AuthenticationProtocolData der DIDAuthenticate-PAOS-Nachrichten für EAC ist "urn:oid:1.0.24727.3.0.0.7.2", sollte laut TR-03112-7 v1.1.2 Kap. 4.6 aber "urn:oid:1.3.162.15480.3.0.14" sein.
2. In den DIDAuthenticateResponse-Nachrichten muss der Präfix für den Namensraum "urn:iso:std:iso-iec:24727:tech:schema" zwingend "iso" sein. (eventuell Vergleich des xsi:type auf "iso:EAC1InputType")
3. Sender der Client die SNI-Extension im TLS (siehe RFC 4366) verhält sich der Server nicht spezifikationskonform. Laut RFC sind folgende Rückgabewerte zulässig:
> a) Ignorieren der Extension wenn unbekannt/nicht unterstützt
> b) antworten mit einer "leeren" extension wenn erfolgreich
> c) antworten mit "unrecognized_name" wenn servername unbekannt
Der eID-Server antwortet allerdings mit "testpaos.governikus-eid." und sendet bei einer späteren Handshake-Nachricht falsche Daten, wodurch keine Verbindung zustande kommt.
h2. Ageto AG
Adresse der Anwendung: https://eid.services.ageto.net/gw/
Adresse eID-Server: https://eid-ref.eid-service.de:443
Abweichungen:
h3. AuthenticationProtocolData
In AuthenticationProtocolData der DIDAuthenticate-PAOS-Nachrichten für EAC fehlt die Protocol-URI.
h3. TLS
1. Die eID-Kommunikation läuft auch mit einer nicht-PSK-Ciphersuite (TLS_RSA_WITH_AES_128_CBC_SHA). Log File siehe "hier":https://redmine.vserver-001.urospace.de/attachments/57/ageto%20ohne%20psk.txt
2. kein TLS1.1 oder höher
h3. StartPAOS
StartPAOS muss ein ConnectionHandle enthalten. Es erfolgt keine Fehlermeldung von Server. Siehe TR-03112-7, Kapitel 2.6 StartPAOS.
h3. Interessante UTF-8 Kodierung der CertificateDescription
308202D5060A04007F00070301030101A10E0C0C442D547275737420476D6248A2181316687474703A2F2F7777772E642D74727573742E6E6574A3120C1053594E4348524F4E49545920476D6248A429132768747470733A2F2F7777772E73796E6368726F6E6974792E6E65742F64656D6F706F7274616C2FA58201F20C8201EE4E616D652C20416E7363687269667420756E6420452D4D61696C2D4164726573736520646573204469656E7374616E626965746572733A0D0A53594E4348524F4E49545920476D62480D0A57696E7A65726C616572205374722E20320D0A3037373435204A656E610D0A6E70614073796E6368726F6E6974792E64650D0A0D0A5A7765636B2064657220446174656EEFBFBD6265726D6974746C756E673A0D0A4964656E746966697A696572756E6720756E642052656769737472696572756E67207A756D2070657273EFBFBD6E6C696368656E204B756E64656E6B6F6E746F0D0A0D0A5A757374EFBFBD6E6469676520446174656E73636875747A626568EFBFBD7264653A0D0A5468EFBFBD72696E676572204C616E64657376657277616C74756E6773616D74205265666572617420486F6865697473616E67656C6567656E68656974656E2C20476566616872656E6162776568720D0A5765696D6172706C61747A20340D0A3939343233205765696D61720D0A54656C3A20283033203631292033372037332037322035380D0A4661783A20283033203631292033372037332037332034360D0A706F73747374656C6C6540746C7677612E7468756572696E67656E2E64650D0A416E737072656368706172746E65723A204672617520416E6B65204E65756D616E6E0D0AA7683166042012054BDCDD69F93AFDBC8666B908C386B009821730C96C3C066F8E6A20D0BE0D0420D97D56EB57F16D0510FD77DE1B964D186E69CED9E6E17FBEA7DBB0F5B3A814650420E9B2B7E1430EFDE9E99A25603AD32E2671EFB6B00D921439428DF982CE168D44
ergibt (siehe "Screenshot":https://redmine.vserver-001.urospace.de/attachments/56/oca%20ageto2.png)
Name, Anschrift und E-Mail-Adresse des Dienstanbieters:
SYNCHRONITY GmbH
Winzerlaer Str. 2
07745 Jena
npa@synchronity.de
Zweck der Daten?bermittlung:
Identifizierung und Registrierung zum pers?nlichen Kundenkonto
Zust?ndige Datenschutzbeh?rde:
Th?ringer Landesverwaltungsamt Referat Hoheitsangelegenheiten, Gefahrenabwehr
Weimarplatz 4
99423 Weimar
Tel: (03 61) 37 73 72 58
Fax: (03 61) 37 73 73 46
poststelle@tlvwa.thueringen.de
Ansprechpartner: Frau Anke Neumann
Die ganzen Umlaute sind mit "EFBFBD" kodiert. Siehe "hier":http://www.fileformat.info/info/unicode/char/fffd/index.htm
h1. Gesendete CV-Zertifikate
Siehe TR-03110-3, Kapitel A.6.1. Public Key References
Zitat:
@Note: As a consequence the Certification Authority Reference contained in a certificate MUST be equal to the Certificate Holder Reference in the corresponding certificate of the issuing certification authority.@
Ich leite aus der Aussage ab, dass bei CVCA Zertifikat CHR = CAR sein muss.
h2. media transfer AG
*EAC1Input*: Terminal-Zertifikat, DV-Zertifikat, CVCA-Zertifikat (CHR!=CAR)
*EAC2Input*: DV-Zertifikat
h2. bremen online services GmbH & Co KG
*EAC1Input*: Terminal-Zertifikat, DV-Zertifikat, CVCA-Zertifikat (CHR!=CAR)
*EAC2Input*: DV-Zertifikat, Terminal-Zertifikat
h2. Ageto AG
*EAC1Input*: Terminal-Zertifikat, DV-Zertifikat
*EAC2Input*: DV-Zertifikat, Terminal-Zertifikat