#language cs ## 20200803 AK ## page was renamed from Software/Projects/Bug#1464: ACME protocol/CZ ---- '''česky''' | [[Software/Projects/Bug%231464%3A%20ACME%20protocol|english]] ---- ## page was renamed from Software/Projects/Bug#1464: ACME protocoll ---- '''Zpět na''' '''[[Software|Domovská stránka Software]]''' - '''[[Software/Assessment|Domovská stránka Software Assessment]]''' - '''[[Software/Projects|Dokumentační oblast vývoje softwaru]]''' ### Sem přidejte další řádky. ---- = Bug#1464: Protokol ACME = Tato stránka souvisí s [[https://bugs.cacert.org/view.php?id=1464|chybou bug#1464 na webu bugtracker]]. Toto je nyní oblast brainstormingu o způsobu implementace [[https://tools.ietf.org/html/rfc8555|protokolu ACME]] pro CAcert. <> == 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 (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 [[https://tools.ietf.org/html/rfc8555#section-7.3.4|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“. <> 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 <> * 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 [[Software/Database/StructureDefined#Domains|Domains]] a [[Software/Database/StructureDefined#OrgDomains|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 [[Software/Database/StructureDefined#DomainCerts|DomainCerts]] a [[Software/Database/StructureDefined#OrgDomainCerts|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 <>? 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 <>. 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 <> čisté DV certifikáty musí být nejprve oprávněny odpovídajícími zásadami! = Zdroje = * [[https://tools.ietf.org/html/rfc8555]] RFC definice protokolu ACME * [[https://letsencrypt.org/docs/client-options/]] Přehled klientských implementací od Let's encrypt = Pod čarou = <> ---- ### Snad ještě přidat další kategorie . CategorySoftware . CategorySoftwareProjects