Open eCard

h1. EID-Server-Issues

h2. media transfer AG

Adresse der Anwendung: http://willow.mtg.de/eidavs/static/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. 

<pre>fry.mtg.de:443</pre>

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

<pre>

308202D5060A04007F00070301030101A10E0C0C442D547275737420476D6248A2181316687474703A2F2F7777772E642D74727573742E6E6574A3120C1053594E4348524F4E49545920476D6248A429132768747470733A2F2F7777772E73796E6368726F6E6974792E6E65742F64656D6F706F7274616C2FA58201F20C8201EE4E616D652C20416E7363687269667420756E6420452D4D61696C2D4164726573736520646573204469656E7374616E626965746572733A0D0A53594E4348524F4E49545920476D62480D0A57696E7A65726C616572205374722E20320D0A3037373435204A656E610D0A6E70614073796E6368726F6E6974792E64650D0A0D0A5A7765636B2064657220446174656EEFBFBD6265726D6974746C756E673A0D0A4964656E746966697A696572756E6720756E642052656769737472696572756E67207A756D2070657273EFBFBD6E6C696368656E204B756E64656E6B6F6E746F0D0A0D0A5A757374EFBFBD6E6469676520446174656E73636875747A626568EFBFBD7264653A0D0A5468EFBFBD72696E676572204C616E64657376657277616C74756E6773616D74205265666572617420486F6865697473616E67656C6567656E68656974656E2C20476566616872656E6162776568720D0A5765696D6172706C61747A20340D0A3939343233205765696D61720D0A54656C3A20283033203631292033372037332037322035380D0A4661783A20283033203631292033372037332037332034360D0A706F73747374656C6C6540746C7677612E7468756572696E67656E2E64650D0A416E737072656368706172746E65723A204672617520416E6B65204E65756D616E6E0D0AA7683166042012054BDCDD69F93AFDBC8666B908C386B009821730C96C3C066F8E6A20D0BE0D0420D97D56EB57F16D0510FD77DE1B964D186E69CED9E6E17FBEA7DBB0F5B3A814650420E9B2B7E1430EFDE9E99A25603AD32E2671EFB6B00D921439428DF982CE168D44

</pre>

ergibt (siehe "Screenshot":https://redmine.vserver-001.urospace.de/attachments/56/oca%20ageto2.png)

<pre>

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

</pre>

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