Uzyskanie klucza PGP jest łatwe, ale podzielenie się nim z innymi może być kłopotliwe.

Dlaczego używać Web Key Directory

Udostępnianie swojego publicznego klucza jest ważne dla zabezpieczenia komunikacji, ponieważ pozwala innym na szyfrowanie wiadomości, które tylko Ty z odpowiadającym prywatnym kluczem możesz odszyfrować i zweryfikować, że wiadomości pochodzą od Ciebie. Jest to szczególnie ważne dla poczty e-mail, która domyślnie nie jest szyfrowana i może być przechwycona i odczytana przez podmiot obsługujący e-mail. Wymaga to jednak, aby odbiorca miał Twój publiczny klucz, który musi być udostępniony.

Tradycyjne sposoby udostępniania publicznego klucza

Tradycyjnym sposobem udostępniania publicznego klucza jest przesłanie go na serwer kluczy, ale ta metoda ma swoje wady. Każdy może przesłać klucz na serwer kluczy, a nie ma sposobu na zweryfikowanie, czy klucz rzeczywiście należy do osoby, do której twierdzi, że należy.

Inną opcją byłoby pobranie klucza ze strony internetowej osoby, ale znalezienie klucza byłoby o wiele trudniejsze, ponieważ strona każdego byłaby inna i nadal wymagałoby ręcznej pracy, aby uzyskać klucz.

Nawet wysłanie klucza przez e-mail nie jest dobre, ponieważ pierwszy e-mail byłby nieszyfrowany, a klucz mógłby być przechwycony i zastąpiony złośliwym, a nadal wymagałby ręcznej pracy do importu klucza.

Rozwiązanie

Tutaj pojawia się Web Key Directory. WKD to protokół umożliwiający odkrywanie publicznych kluczy OpenPGP przesłanych na serwery osób, omijając potrzebę dedykowanych serwerów kluczy i umożliwiając większą kontrolę nad kluczami. Korzystając z HTTPs do uzyskania klucza, możesz być trochę pewniejszy, że klucz używany dla adresu e-mail został dystrybuowany przez właściciela domeny, który może być tą samą osobą.

WKD pozwala klientom poczty e-mail, takim jak Thunderbird, na automatyczne odkrywanie publicznego klucza odbiorcy i bezpośrednie użycie go podczas pierwszej rozmowy.

Konfiguracja Web Key Directory

WKD ma dwa rodzaje konfiguracji: konfigurację bezpośrednią i zaawansowaną. Pomimo swoich nazw, obie wymagają mniej więcej tych samych kroków. Konfiguracja bezpośrednia nie wymaga dodatkowych wpisów DNS, podczas gdy konfiguracja zaawansowana wymaga utworzenia subdomeny o nazwie openpgpkey, która zostanie najpierw przetestowana, zanim przejdzie do konfiguracji bezpośredniej.

Wymagania

  1. Domena:

    Domena jest wymagana do hostowania publicznego klucza, ponieważ w przeciwnym razie nie mogłbyś używać WKD. Dla podstawowej konfiguracji wystarczy umiejętność umieszczenia plików w katalogu .well-known Twojej domeny. Dla zaawansowanej konfiguracji musisz być w stanie utworzyć subdomenę o nazwie openpgpkey i umieścić pliki w katalogu .well-known tej subdomeny.

  2. Publiczny klucz, który pasuje do adresu e-mail hostowanego na domenie

  3. Serwer WWW:

    Serwer WWW jest wymagany do hostowania publicznego klucza. Jeśli nie masz hostingu WWW lub nie możesz kontrolować serwera WWW, możesz skorzystać z WKD-as-a-service Openpgp.org. Ta usługa pozwala na hostowanie publicznego klucza na ich serwerach, wykorzystując zaawansowaną konfigurację. Ten sposób ma wadę braku pełnej kontroli nad kluczem i zawiera wszystkie dostępne klucze dla tej tożsamości.

Uzyskanie hasza

Podstawowy tryb oczekuje klucza pod tym adresem: https://{domena}/.well-known/openpgpkey/hu/{hash}?l={nazwa-e-mail} gdzie {domena} to domena adresu e-mail, {hash} to hash WKD adresu e-mail i {nazwa-e-mail} to część nazwy adresu e-mail przed @ z użyciem odpowiedniego unikania znaków.

Zaawansowany tryb jest podobny, ale używa subdomeny openpgpkey i zawiera domenę w małych literach w ścieżce, tak jak poniżej: https://openpgpkey.{domena}/.well-known/openpgpkey/{domena}/hu/{hash}?l={nazwa-e-mail}

Hash jest obliczany przez wzięcie adresu e-mail, zamienienie go na małe litery i zahashowanie go za pomocą algorytmu SHA-1. Wynikowy 160-bitowy skrót jest kodowany za pomocą metody Z-Base-32 w celu utworzenia 32-oktetowego ciągu. Ten ciąg jest następnie używany jako hash w adresie URL. Nie musisz jednak robić tego ręcznie, ponieważ narzędzie wiersza poleceń gpg może to zrobić za Ciebie.

1
2
3
4
5

# Konkretny klucz:
gpg --with-wkd-hash --fingerprint jan@example.com

# Wszystkie przechowywane klucze:
gpg --list-keys --with-wkd-hash

Otrzymasz coś w rodzaju:

1
2
3
4
5

pub   ed25519 2024-03-17 [SC] [expires: 2026-03-17]
      9D8A 1793 98A8 9449 29C2  AAE6 00ED 46C4 145C 61FE
uid           [ultimate] Jan Kowalski <jan@example.com>
              nuu38srs5zrcw4etqt3nt4drcu8wrydf@example.com
sub   cv25519 2024-03-17 [E] [expires: 2026-03-17]

Hash jest przed @ w adresie e-mail, który w tym przypadku to

Teraz, gdy masz hash, musisz zapisać niezamaskowaną wersję klucza publicznego w lokalizacji hasha, co możesz zrobić za pomocą następującego polecenia:

1

gpg --no-armor --export jan@example.com

Bądź ostrożny na Windows, ponieważ nie używa operatora przekierowania > poprawnie i dane binarne zostają pomieszane. Rozważ użycie Git Bash lub WSL, aby temu zapobiec.

DNS

Jeśli planujesz korzystać z zaawansowanej konfiguracji, musisz utworzyć subdomenę o nazwie openpgpkey i mieć serwer www serwujący klucze stamtąd. Jeśli korzystasz z metody bezpośredniej, musisz upewnić się, że subdomena openpgpkey nie odpowiada. Na przykład, gdy używasz rekordów DNS typu wildcard, upewnij się, że subdomena openpgpkey nie jest objęta wildcardingiem. Można to zrobić, dodając pusty rekord TXT dla tej subdomeny, co zapobiegnie wpływowi rekordów DNS typu wildcard na rekord DNS openpgp, ponieważ najpierw próbuje się metody zaawansowanej, zanim nastąpi powrót do metody bezpośredniej.

Przesyłanie klucza

Klucz musi być przesłany na serwer www w lokalizacji hasha odpowiedniej dla wybranej konfiguracji. Powinien być serwowany jako application/octet-stream i zezwalać na dostęp z dowolnego miejsca za pomocą nagłówka Access-Control-Allow-Origin: *.

Przykładowe konfiguracje dla nginx mogą wyglądać tak:

1
2
3
4
5

location ^~ /.well-known/openpgpkey {
   default_type application/octet-stream;
   add_header Access-Control-Allow-Origin *;
   alias /path/to/openpgpkey;
}

albo dla Clodflare pages przez utworzenie pliku _headers w katalogu wyjściowym:

1
2
3

/.well-known/openpgpkey/*
   Content-Type: application/octet-stream
   Access-Control-Allow-Origin: *

Dodanie pliku policy

Specyfikacja wymaga, aby plik flag polityki był serwowany. Ten plik jest wymagany nawet jeśli protokół aktualizacji Web Key Directory nie jest obsługiwany, co jest protokołem, który umożliwia automatyczną aktualizację i dodawanie klucza publicznego. Ale to nie będzie potrzebne, ponieważ klucze będą statycznie hostowane i serwowane.

Plik flag polityki może być pustym plikiem, ale musi być serwowana pod /.well-known/openpgpkey/policy zarówno dla konfiguracji bezpośredniej, jak i zaawansowanej.

Testowanie konfiguracji

Możesz przetestować swoją konfigurację za pomocą następującego polecenia GnuPG, które spróbuje pobrać klucz z serwera:

1

gpg --auto-key-locate clear,nodefault,wkd --locate-keys jan@example.com

1
2
3
4
5
6

gpg: key 00ED46C4145C61FE: public key "jan@example.com" imported
gpg: Total number processed: 1
gpg:               imported: 1
pub   ed25519 2024-03-17 [SC] [expires: 2026-03-17]
      9D8A179398A8944929C2AAE600ED46C4145C61FE
uid           jan@example.com

Dla codziennego użytku możesz po prostu użyć --locate-keys w gpg, aby automatycznie pobrać klucz z serwera lub poszukać odpowiedniej opcji w swoim kliencie poczty.

Podsumowanie

Ustawienie Web Key Directory to świetny sposób na udostępnianie swojego publicznego klucza innym. Pozwala na automatyczne odkrywanie publicznego klucza na przykład w klientach poczty e-mail i umożliwia większą kontrolę nad kluczem, ponieważ jest hostowany na Twoim własnym serwerze i umożliwia komunikację bez ręcznej wymiany klucza. Pozwala również na usunięcie starych lub unieważnionych kluczy z serwera, co nie jest możliwe z tradycyjnymi serwerami kluczy, które będą przechowywać klucz na zawsze, zatruwając serwer kluczy starymi kluczami.

Źródła: