SubCA/Serverzertifikate ed25519 sinnvoll?

[Pummeluff]

Hallo,

ich bin gerade dabei, für unsere Abteilung eine neue SubCA zu erstellen, die dann von den Netzwerkkollegen signiert wird.

Dabei hab ich die freie Wahl, welchen Algorithmus ich verwende. Bis vor einigen Jahren war das noch RSA mit 2048 bit. Standard wäre jetzt eigentlich RSA mit 4096 bit.

Da kam ich auf den Gedanken, dass ich ja auch mal was Modernes hernehmen könnte. Bei SSH nutz ich bereits seit einigen Jahren ed25519.

Spricht irgendwas dagegen, ed25519 auch für Serverzertifikate zu verwenden? Nach meinen bisherigen Recherchen sollten das mittlerweile alle gängigen Browser unterstützen.

Anleitung dazu:
https://blog.pinterjann.is/ed25519-certificates.html

 

[dahkenny]

Spricht irgendwas dagegen, ed25519 auch für Serverzertifikate zu verwenden?

Sofern ihr nicht uralte oder anderweitige legacy Systeme in Verwendung habt, an sich nicht.

 

[SirKhan]

Hm, wenn es X22519 ist, denn geht es wohl; bei ED22519 (und Chromium-Browsern) eher nicht: https://caniuse.com/?search=25519

Kommt also bisschen darauf an, was genau damit gemacht werden soll, sprich "key exchange" ja, "signature" nein (so wie ich das sehe).

 

[konkretor]

Frage ist halt was für Server hast du? Also Tomcat, Jetty etc.

Alles was niedriger als Java 15 ist läuft damit nicht
Erst ab Java 15 geht das ohne Probleme
https://openjdk.org/jeps/339

 

[KillerCow]

Warum nicht etwas etablierteres, wie secp384r1 oder secp256r1/prime256v1, womit es eher weniger Probleme geben sollte, als mit ed22519?

 

[Tornhoof]

Spricht irgendwas dagegen

Ist halt nicht erlaubt von Seiten der Baseline Requirements für TLS der Cert Authorities:
siehe Dokument
https://cabforum.org/working-groups/server/baseline-requirements/documents/
https://cabforum.org/working-groups...s/documents/CA-Browser-Forum-TLS-BR-2.1.4.pdf

Seite 109:

7.1.3.1.2 ECDSA
The CA SHALL indicate an ECDSA key using the id‐ecPublicKey (OID: 1.2.840.10045.2.1) algorithm
identifier. The parameters MUST use the namedCurve encoding.
• For P‐256 keys, the namedCurve MUST be secp256r1 (OID: 1.2.840.10045.3.1.7).
• For P‐384 keys, the namedCurve MUST be secp384r1 (OID: 1.3.132.0.34).
• For P‐521 keys, the namedCurve MUST be secp521r1 (OID: 1.3.132.0.35).
When encoded, the AlgorithmIdentifier for ECDSA keys MUST be byte‐for‐byte identical
with the following hex‐encoded bytes:
• For P‐256 keys, 301306072a8648ce3d020106082a8648ce3d030107.
• For P‐384 keys, 301006072a8648ce3d020106052b81040022.
• For P‐521 keys, 301006072a8648ce3d020106052b81040023.

 

[Pummeluff]

Frage ist halt was für Server hast du? Also Tomcat, Jetty etc.

Hauptsächlich Apache und Nginx. Hat sich so etabliert, dass wir diese Webserver als Reverse Proxy nutzen und dann die Application Server wie Jetty oder Tomcat dahinterschalten.

Ist halt nicht erlaubt von Seiten der Baseline Requirements für TLS der Cert Authorities:

Ok, dann bleib ich bei rsa mit 4096 bit.

Danke.

 

[norKoeri]

Weil ich das gerade sehe, was hat denn das CA/Browser-Forum mit meinen eigenen Zertifikaten zu tun? Selbst wenn, lese ich das eher nur als Beispiel-Liste. Ist das wirklich eine Ausschlussliste?

Ok, dann bleib ich bei rsa mit 4096 bit.

Selbst wenn Du das CA/Browser-Forum für Dich autoritativ ansiehst und selbst wenn Du jene Liste als einzig möglichen Alternativen ansiehst, kannst Du trotzdem statt RSA dann ECC verwenden.

die dann von den Netzwerkkollegen signiert wird

Hast Du dort gefragt, was erlaubt bzw. gewünscht ist? Gibt zwar Theorien dass man sich darunter aufhalten sollte. Aber rein technisch kannst Du wild mischen, also in der Kurve bzw. Tiefe stärker werden als Deine Root bzw. von RSA auf ECC wechseln.