CCP: Support für OPENPGPKEY RR im DNS nach RFC7929

  • Am 08.08.2016 wurde RFC 7929 veröffentlicht und ermöglicht das Verteilen öffentlicher PGP-Schlüssel über DNS. Hierzu ist ein OPENPGPKEY RR im DNS notwendig.


    DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP
    RFC 7929
    RFC 7929


    Um das ganze bei netcup pflegen zu können, bräuchte man
    - die Möglichkeit, den RR OPENPGPKEY im DNS pflegen zu können
    - die Veröffentlichung des Eintrags im DNS


    DNSSEC/DANE ist ja bereits möglich bei netcup, insofern liegt es auf der Hand, DANE um weitere Anwendungsmöglichkeiten zu erweitern. Die hierzu nötige Änderung beschränkt sich im Wesentlichen auf die Einführung des neuen RR.

    • Offizieller Beitrag

    Liebe Kundinnen und Kunden,

    Hallo m_ueberall  Saalbuerger  thomas303,


    Ihre Wünsche wurden wahr. Herzlichen Dank für Ihre Geduld.


    DNS-Einträge der Typen 53 (SMIMEA), 61 (OPENPGPKEY) und 44 (SSHFP) können jetzt im netcup DNS Server via CCP und API eintragen werden.


    Hier der Link zur offiziellen News: https://www.netcup-news.de/201…n-fuer-unsere-dns-server/

  • Liebe Kundinnen und Kunden,

    Hallo m_ueberall  Saalbuerger  thomas303,

    Ihre Wünsche wurden wahr. Herzlichen Dank für Ihre Geduld.

    :love:


    Kurze Nachfrage: Wie lange dürfen entsprechende Einträge denn sein? Mein Test-Minimal-GPG-Schlüssel-Export hat (im Binärformat) 19268 Bytes[*], und in Hexadezimalformat gemäß RFC7929 wird's doppelt so lang. Via CCP läßt sich das so nicht hineinkopieren.


    [*] Es gibt sicherlich kürzere, aber der Schlüssel wurde seinerzeit absichtlich zur Abdeckung mehrerer Domains erstellt, um die öffentlichen PGP-Schlüssel-Server nicht mit Schlüsseln/"redundanten Attributen" zu "fluten".

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • [netcup] Johannes B. : Bei den OPENPGPKEY-Einträgen, bei welchen man die (öffentlichen!) Schlüssel im Base64-Format in das CCP hineinkopiert – wie es das Bildschirmfoto der heutigen Pressemitteilung suggeriert – erfolgt derzeit vor Abspeicherung wohl eine zweite Base64-Konvertierung? (Dies ist IMHO daran zu erkennen, dass die (um Füllzeichen gefilterte) "dig +vc openpgp [...]"-Ausgabe mittels "base64 -d" mit der Originaleingabe im CCP übereinstimmt.)


    Infolgedessen schlägt ein "gpg --verbose --auto-key-locate clear,dane --locate-keys info@example.org" fehl.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • [netcup] Johannes B. : Auch beim Test der SSHFP-Einträge liefert "dig +vc sshfp example.org" nicht die Ergebnisse zurück, welche man erwarten würde und im CCP sieht. Ich habe die (anonymisierten) dig-Ausgaben einer im CCP verwalteten Domäne (.org) und einer Fremdomäne (.ch) angehängt. Zum Vergleich: RFC4255-Beispiel


    ccp-sshfp.png

  • Hallo liebe DNS-Admins,


    ich kann leider mit den Funktionen noch immer nichts anfangen. Meine Probleme begannen damit, dass der Eintrag zwar „OPENPGPKEY“ heißt, jedoch Einträge im Format „TYPE 61“ erstellt werden müssen, nicht im Format „OPENPGPKEY“ (ersteres ist BASE64-kodiert, letzteres in ASCII). Das hat mich schon sehr lange aufgehalten. Nachdem ich dies jedoch herausgefunden hatte, scheitere ich an der Beschränkung auf 10.000 Zeichen.


    Mein Key lässt sich nicht in 10.000 Zeichen packen, wenn er BASE64-kodiert sein muss, er ist bereits in ASCII ca. 7.000 Zeichen lang. Und das ist ohne alle Signaturen, die man eventuell ganz gerne beifügen würde - lediglich der Key selbst, mit seinen beiden Subkeys zum Signieren und Verschlüsseln. Ich benötige also entweder eine Unterstützung des OPENPGPKEY-Formats (das Format der bisherigen Einträge sollte sowieso in „TYPE 61“ umbenannt werden, um Verwirrung zu vermeiden) oder eine Anhebung der Längenbeschränkung.


    Beste Grüße,
    Sebastian Bork

    • Offizieller Beitrag

    Hallo sebidotorg ,


    danke für Ihre Nachricht.


    Unser System übernimmt die Konvertierung in base64 für Sie. Daher sollte es für Sie keinen Unterschied machen das wir hier TYPE 61 im Hintergrund verwenden.


    Welche Länge würden sie bevorzugen?


    Ein schönes Wochenende.

  • Hallo,


    herzlichen Dank für die schnelle Antwort. Mein Problem hat sich mittlerweile erledigt, ich habe den Key letztendlich doch so eingetragen bekommen, dass nun alles passt. Nachdem ich an den Fehlermeldungen über die angeblich überschrittene Länge von 10.000 fast verzweifelt bin, scheint es eigentlich doch um einen Fehler beim Eingabeformat gegangen zu sein (ich habe auf dem iPad einfach die Whitespaces/Newlines nicht vollständig wegbekommen). Die Fehlermeldung hatte mich nur längere Zeit irregeführt.

    Es wäre trotzdem schön, wenn irgendwie darauf hingewiesen werden könnte, dass es sich um einen Eintrag im Format „TYPE 61“ handelt, da ich bei der Auswahl „OPENPGPKEY“ bei den ersten Versuchen erwartet hatte, das Format aus RFC 7929 verwenden zu können, wie es auch unter „Standard (OPENPGPKEY)“ auf https://www.huque.com/bin/openpgpkey ausgegeben wird, also im Prinzip einen Key im regulären ASCII-Format, anstatt dort „Generic encoding (TYPE61)“ auswählen zu müssen. Und richtig komfortabel wäre natürlich, wenn Whitespace in der Eingabe automatisch entfernt würde. Dann könnte man nämlich den Output eines solchen Generators direkt per Copy&Paste in Safari verwenden, ohne erst noch in mehreren Schritten einen akzeptierten String daraus machen zu müssen.


    Trotz dieser Verbesserungsvorschläge muss ich sagen, dass ich die Umsetzung des DNS bei netcup wirklich großartig finde. Eben habe ich auch noch die SSHFP-Einträge gemacht, da wurde ja echt an alles gedacht. Die Unterstützung von DNSSEC für .org hat mich damals zum Wechsel bewogen, und durch die Möglichkeit, vom SSL-Zertifikat über den SSH-Host-Key bis hin zum GnuPG-Key alles im DNS zu hinterlegen, kann man die Vorteile von DNSSEC tatsächlich richtig nutzen. Vielen Dank dafür, und ebenfalls ein tolles Wochenende!

  • Erkennt das System (mittlerweile), ob die Eingabe bereits base64 codiert ist?

    Klare Antwort: nein.

    Meine Hinweise bezüglich TYPE61 vs. OPENPGPKEY bitte vergessen. Ich habe mich davon verwirren lassen, dass das System schliesslich beim Versuch, einen BASE64-kodierten Key einzugeben, auf den Fehler „maximale Länge der Destination 10.000“ gewechselt hat, nachdem ich davor mit der Eingabe in ASCII-armored mehrfach mit Meldungen zu „falschem Format der Destination“ gescheitert war (wohl weil noch Zeilenumbrüche oder Whitespace drin waren, die der von mir verwendete Generator geliefert hatte, bzw. die beim Copy&Paste aus dem SSH-Client entstanden waren). Nach der geänderten Fehlermeldung dachte ich, das Format wäre nun wie erwartet, nur der Key zu lang. Sobald ich den String dann in sauberem BASE64 und kurz genug hatte, wurde der Eintrag akzeptiert, was mich im falschen Glauben bestätigte, die Eingabe müsse in BASE64 erfolgen. Allerdings konnte GPG nichts damit anfangen, also habe ich es doch noch einmal mit der Eingabe ohne vorherige BASE64-Kodierung versucht, also im Format nach RFC 7929, die diesmal auch akzeptiert wurde. Nachdem nun die Aktualisierung des DNS erfolgt ist, konnte ich es erfolgreich mit GPG testen.

    Es ist also alles so, wie es sein soll. Das einzige, was ich mir wünschen würde, wäre eine kleine Erläuterung zum vorgesehenen Eingabeformat anzuzeigen, wenn eine der beiden etwas verwirrenden Fehlermeldungen über ein falsches Format oder die maximale Länge angezeigt wird.

  • Klare Antwort: nein.

    Meine Hinweise bezüglich TYPE61 vs. OPENPGPKEY bitte vergessen. Ich habe mich davon verwirren lassen, dass das System schliesslich beim Versuch, einen BASE64-kodierten Key einzugeben, auf den Fehler „maximale Länge der Destination 10.000“ gewechselt hat, nachdem ich davor mit der Eingabe in ASCII-armored mehrfach mit Meldungen zu „falschem Format der Destination“ gescheitert war (wohl weil noch Zeilenumbrüche oder Whitespace drin waren, die der von mir verwendete Generator geliefert hatte, bzw. die beim Copy&Paste aus dem SSH-Client entstanden waren). Nach der geänderten Fehlermeldung dachte ich, das Format wäre nun wie erwartet, nur der Key zu lang. Sobald ich den String dann in sauberem BASE64 und kurz genug hatte, wurde der Eintrag akzeptiert, was mich im falschen Glauben bestätigte, die Eingabe müsse in BASE64 erfolgen. Allerdings konnte GPG nichts damit anfangen, also habe ich es doch noch einmal mit der Eingabe ohne vorherige BASE64-Kodierung versucht, also im Format nach RFC 7929, die diesmal auch akzeptiert wurde. Nachdem nun die Aktualisierung des DNS erfolgt ist, konnte ich es erfolgreich mit GPG testen.

    Es ist also alles so, wie es sein soll. Das einzige, was ich mir wünschen würde, wäre eine kleine Erläuterung zum vorgesehenen Eingabeformat anzuzeigen, wenn eine der beiden etwas verwirrenden Fehlermeldungen über ein falsches Format oder die maximale Länge angezeigt wird.

    Oh weh, ich sollte heute nichts mehr schreiben, die Temperaturen hier unter dem Dach tun mir nicht gut. Ich habe leider dort oben durchgehend BASE64- und HEX-Encoding verwechselt. Also habe ich zuerst BASE64 ausprobiert („mQINBFkkPzwBEADMx8EfD76Aih/8K“), was zunächst aus anderen Gründen nicht ging, dann habe ich den Key HEX-kodiert eingegeben, also so, wie der Generator ihn für TYPE61-Einträge liefert („99020d0459243f3c011000ccc7c11f0fbe808a1ffc2aab4262bad937c1b7“), das wurde im DNS angenommen, aber hat in GPG nicht funktioniert. Und dann ganz am Ende habe ich es nochmal BASE64-kodiert eingegeben, und das funktioniert jetzt. Jegliche entstandene Verwirrung bitte ich zu entschuldigen.