Zpět na Domovská stránka Software - Domovská stránka Software Assessment - Dokumentační oblast vývoje softwaru

Bug#1464: Protokol ACME

Tato stránka souvisí s chybou bug#1464 na webu bugtracker.

Toto je nyní oblast brainstormingu o způsobu implementace protokolu ACME pro CAcert.

Contents

  1. Bug#1464: Protokol ACME
    1. Protokol ACME - přehled
      1. Instance klientů / Účty
        1. Hledisko CAcert
        2. Alternativní přístupy
        3. Právní důsledky
    2. Otázky zásad CAcert
      1. DV certifikáty od CAcert?
  2. Zdroje
  3. Pod čarou

Protokol ACME - přehled

Protokol ACME je primárně používán automatizovanými klienty k registraci nových domén a k vyžádání nových serverových certifikátů. I když to může být také vhodné pro vyžádání klientských certifikátů, není to jeho primární zaměření.

Protože vytváření certifikátů ve webovém prohlížeči se značně ztížilo se zastaráním značek HTML <keygen> (generování klíčů a CSR), nabídnutí takového standardního rozhraní by našim uživatelům otevřelo použití mnoha existujících nástrojů pro vytváření certifikátů pomocí CAcert. A to může umožnit implementaci nových nástrojů, které mohou zavést pohodlnější nebo k chybám méně náchylné přístupy při některých úkolech souvisejících s certifikáty.

Instance klientů / Účty

ACME pracuje s „účty“ pro instance klienta, které jsou dynamicky vytvářeny samotnými instancemi. Každá instance klienta vytvoří pár veřejných klíčů a odešle veřejnou část klíče na server ACME. Server tak může ověřit, že následné požadavky jsou zasílány stejnou instancí klienta.

Každá klientská instance obvykle (ale ne nutně) zpracovává certifikáty jednoho serveru, vyžaduje počáteční server a obnovuje / vydává certifikát pokaždé, když vyprší.

Tyto účty ACME mohou být propojeny s „externím účtem“, což je popsáno v sekci 7.3.4 dokumentu RFC8555.

Hledisko CAcert

Z pohledu CAcert by tyto účty ACME měly pravděpodobně být novými objekty v databázi, které jsou pak propojeny s uživatelskými účty CAcert pomocí mechanismu „externích účtů“.

Uživatelské rozhraní organizace CAmin na webu CAcert bude pravděpodobně muset být rozšířeno o novou položku nabídky „Klienti Org ACME“. 1 Pomocí této položky menu by měl být Org Admin schopen vytvořit MAC klíče a identifikátory klíčů vyžadované RFC8555. Rozhraní CAcert ACME musí pak být schopno propojit žádost o nový účet ACME s uživatelským účtem CAcert s těmito přihlašovacími údaji.

Uživatel CAcert by měl mít možnost přiřadit ke každému ze svých účtů ACME nějaký druh „přístupového práva“, například: * může zaregistrovat nové domény pro uživatele CAcert * smí používat pouze domény již zaregistrované u účtu CAcert 2 * může vytvářet certifikáty pouze pro konkrétní název hostitele

Autorizace pro účet ACME musí být zrušitelná, aby klient používající tento účet již nemohl vytvářet certifikáty a musí být možné zrušit všechny (neprošlé) certifikáty vydané konkrétním účtem ACME.

Při prvním vyhodnocení jsem nezaznamenal kritické problémy, které by bránily použití rozhraní ACME pro "osobní certifikáty" použitelné pro provoz S/MIME. Než se však podrobněji podíváme na tuto variantu, je třeba provést další výzkum.

Alternativní přístupy

Jedním jednoduchým přístupem by bylo rozšíření databázových tabulek Domains a OrgDomains, které obsahují záznam pro každou ověřenou doménu účtu CAcert, připojit MAC klíč a identifikátor klíče. Tento klíč MAC by pak umožnil vydání nových certifikátů pro tuto konkrétní doménu.

Implementace sice může být velmi jednoduchá, ale nepodporuje mnoho užitečných funkcí pro doladění, jako je omezení MAC klíče pro vytváření certifikátů pouze pro konkrétní název hostitele nebo subdoménu.

Další možností by bylo rozšíření tabulek DomainCerts a OrgDomainCerts, které obsahují jeden záznam pro každý vydaný certifikát serveru. Klíč MAC uložený v této tabulce klientovi umožní vyžádat si nový certifikát (nebo může obnovit stávající certifikát) pro stejnou entitu.

Přestože by tato varianta umožňovala jemnou „granularitu přístupu“, můžeme narazit na problémy s nadbytečnými daty a „intuitivní interpretací“ dat. Jedna entita již může mít přiřazeno několik certifikátů; který z těchto záznamů by byl zkontrolován na správný klíč? Každá z nich 3? Pouze platné/nevypršené? Je třeba zkopírovat klíč MAC do nově vydaného certifikátu?

I když můžeme získat některé pěkné funkce implementované v tomto přístupu, považuji přístup „nové tabulky“ uvedený v předchozím odstavci za intuitivnější, a proto méně náchylný k chybám.

Právní důsledky

Uvědomte si, že z právního hlediska musí uživatel CAcert uložením těchto MAC klíčů v klientovi ACME převzít odpovědnost za všechny akce klienta ACME! “„ Vzhledem k tomu, že mohou existovat podvodní klienti ACME, CAcert uživatel by měl mít možnost omezit povolené akce klienta.

Uživatel musí být o tom výrazně informován!

Otázky zásad CAcert

DV certifikáty od CAcert?

V současné době CAcert nevydává certifikáty DV („Domain Validated“), nejnižší z „úrovní důvěryhodnosti“, které v současné době používají CA 4. Certifikáty DV pouze ověřují kontrolu nad doménou, kde CAcert vždy propojuje certifikáty s uživatelským účtem a má proto vždy nějaký odkaz na „entitu skutečného světa“, která certifikát požadovala.

Certifikát CAcert je aktuálně vždy propojen s uživatelským účtem. Pokud chce CAcert vstoupit do soutěže s Let's Encrypt 5 čisté DV certifikáty musí být nejprve oprávněny odpovídajícími zásadami!

Zdroje

Pod čarou

  1. Tato položka menu samozřejmě také dává smysl pro „běžného“ uživatele CAcert, ale já to považuji za důležitější pro organizace ... (1)

  2. I když bych to nepovažoval za nejnaléhavější funkci k implementaci, bylo by hezké, kdybychom ji mohli mít, možná ve druhém kroku. (2)

  3. Mohlo by to umožnit přístup několika klíčů k certifikátům pro jednu entitu, což by umožnilo mechanismy "zpět po selhání" (3)

  4. Samozřejmě certifikáty podepsané samy sebou jsou o jednu úroveň důvěryhodnosti níže (4)

  5. velmi pochybuji, že je to dobrý nápad, ale ostatní si mohou myslet něco jiného... (5)

Software/Projects/Bug-1464-ACME_protocol/CZ (last edited 2020-08-03 15:44:58 by AlesKastner)