[Gelöst] Neues Zertifikat wird bei Verwendung der edi@energy-Richtlinie abgelehnt

[GeHe]

Moin,
ein Marktpartner (50Hertz) hat ein neues Zertifikat übermittelt. Nun ist gestern die erste damit verschlüsselte Nachricht empfangen worden, diese wird von NSP abgewiesen mit "Die Signatur-Parameter der Nachricht und des Zertifikats sind nicht kompatibel (RFC 4056, Abschnitt 3)"
Wenn ich altes und neues Zertifikat vergleiche ist (neben dem anderen Aussteller) der einzige Unterschied der Schlüsseltyp (alt RSA 2048, neu RSA 4096).
Wir benutzen NSP 4.0.5.39 und haben die edi@energy-Richtlinie aktiviert.

Gibt es dazu bekannte Probleme?

Danke und Gruß
Georg

 

[Sören]

ein Marktpartner (50Hertz)

die sollten eigtl. wissen was sie tun

Gibt es dazu bekannte Probleme?

nein, nichts bekannt... kannst du mir mal bitte das Zertifikat von denen per PN zukommen lassen?

 

[Sören]

Lösung, falls das mal einer lesen sollte:

Die Signatur die aufgebracht wurde auf die Mail war SHA256, allerdings ist das signierende Zertifikat SHA512

In der RFC dazu steht klar:

RFC 4056: Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS)

1. The hashAlgorithm field in the certificate
subjectPublicKey.algorithm parameters and the signatureAlgorithm
parameters MUST be the same.

 

[Sören]

kleines Update:

so war es auch, denn sie haben es korrigiert und nun kommen die edi Mails auch wieder auch durch, weil nun die Signatur der BDEW Richtlinie entspricht

 

[GeHe]

Hallo Sören,
ja, sie haben es geändert, weil dies der schnellste Weg war. Allerdings interpretieren Sie den Abschnitt
"5.3 Algorithmen und Schlüssellängen
für S/MIMEEs sind folgende Algorithmen und Schlüssel mit den genannten Schlüssellängen zu verwenden:
Einstellungen in der Software:
Signatur:

• Hashfunktion (Hash algorithm): SHA-256 oder SHA-512 (gemäß IETF RFC 5754).
• Signaturverfahren (Signature algorithm): RSASSA-PSS (gemäß IETF RFC 4056)."

so, dass die Wahlfreiheit bei der Hashfunktion unabhängig von der bei der Signatur verwendeten Funktion besteht. Bislang seien wir auch der einzige Marktpartner, der das bemängelt habe.
Ich habe eine entsprechende Frage im BDEW-Forum gestellt, die ich hier verlinke, sobald sie beantwortet wurde. Falls der BDEW der Interpretation des Marktpartners folgt wäre eine Anpassung im NSP notwendig, ich erwarte dies aber nicht.

 

[Sören]

Allerdings interpretieren

da gibt es nichts zu interpretieren, sie müssen sich an die RFC für RSASSA-PSS halten und da steht ganz klar:
1. The hashAlgorithm field in the certificate
subjectPublicKey.algorithm parameters and the signatureAlgorithm
parameters MUST be the same.

Signatur:

• Hashfunktion (Hash algorithm): SHA-256 oder SHA-512 (gemäß IETF RFC 5754).
• Signaturverfahren (Signature algorithm): RSASSA-PSS (gemäß IETF RFC 4056)."

Der Teil hier kommt von EDI@ENERGY.... das bedeutet, aber nicht, dass man an der RFC vorbei operieren darf

Natürlich dürfen und haben sie die Wahl ob sie eine SHA256 oder SHA512 aufbringen, sie dürfen dabei aber nicht die RFC 4056 brechen. Wenn sie eine SHA512Signatur aufbringen wollen, dann MUSS der Signaturhashalgorithmus des verwendeten Keys ebenfalls SHA512 sein.

ich erwarte dies aber nicht

ich auch nicht, auch das BDEW muss sich an gängige Standards, auf die sie ja selbst auch verweisen, halten

Bislang seien wir auch der einzige Marktpartner, der das bemängelt habe.

Da fehlen mir etwas die Worte, wenn man so anfängt zu argumentieren

Ich danke für deinen Einsatz Bin mal gespannt ob irgendeine Meldung aus dem BDEW-Forum dazu kommt.

 

[StefanCink]

Ich habe eine entsprechende Frage im BDEW-Forum gestellt, die ich hier verlinke, sobald sie beantwortet wurde. Falls der BDEW der Interpretation des Marktpartners folgt wäre eine Anpassung im NSP notwendig, ich erwarte dies aber nicht.

Ich wäre Dir sehr dankbar, wenn Du in dem Forum darauf drängst, dass die RFC eingehalten werden muss. Alles andere wäre absolut lächerlich und der Sache in keinster Weise dienlich. Ich verweise gerne noch einmal auf den jüngsten Vorfall, der unter dem Namen "SMTP Smuggling" bekannt wurde. Grund für diesen durchaus gravierenden Vorfall war eine Nichtbeachtung der RFC.

 

[wewert]

Vielen Dank für den Hinweis,
ja, wir haben ebenfalls das Problem gehabt und deswegen auch ein Ticket bei Euch, NSP, erstellt. Das kann demnach geschlossen werden (schreibe ich extra).
Ja, der Zertifikatsaussteller procilon hat beim Signieren der von ihm ausgestellten Zertifikate auf SHA-512 umgestellt. Das habe aber wohl nur wenige von deren Kunden (50hertz.com am 8.2. 11:00) mitbekommen und versenden ihre GPKE-Nachrichten mit dem procilon-als-Aussteller-Zertifikat weiterhin mit SHA-256 gehasht. Dann knallt es entsprechend. Also müssen diese Partner auf diesen hier diskutierten Umstand hingewiesen werden.

 

[wewert]

.... Bislang seien wir auch der einzige Marktpartner, der das bemängelt habe.

Wir hatten das auch bei mehreren (7 oder mehr) Marktpartnern bemängelt, konnten aber nicht die exakte Ursache benennen. Jetzt können wir das so an diese weitergeben - vielen Dank

 

[GeHe]

Ich wäre Dir sehr dankbar, wenn Du in dem Forum darauf drängst, dass die RFC eingehalten werden muss. Alles andere wäre absolut lächerlich und der Sache in keinster Weise dienlich. Ich verweise gerne noch einmal auf den jüngsten Vorfall, der unter dem Namen "SMTP Smuggling" bekannt wurde. Grund für diesen durchaus gravierenden Vorfall war eine Nichtbeachtung der RFC.

Da musste ich nicht drängen

Fragen

 

[StefanCink]

Danke für den Hinweis @wewert , aber aus meiner Sicht muss das schon die Software-Lösung von alleine machen. Die Lösung muss automatisch den verwendeten Hash im Zertifikat erkennen und dementsprechend auch die richtige Hash-Funktion beim Signieren verwenden. Wie schon gesagt, die RFC ist da mehr als eindeutig. Dass man das manuell umstellen kann, ist kein Feature, sondern ein Bug. </ragemode> ;-)

 

[wewert]

Danke für den Hinweis @wewert , aber aus meiner Sicht muss das schon die Software-Lösung von alleine machen.... die RFC ist da mehr als eindeutig. Dass man das manuell umstellen kann, ist kein Feature, sondern ein Bug. </ragemode> ;-)

Ja, nur das ist deren Software-Lösung; wir können trotzdem nur unsere Kommunikationspartner darauf hinweisen. ;-)