From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 Date: Fri, 10 Aug 2018 17:51:50 +0300 From: "Alexey V. Vissarionov" To: ALT Linux Team development discussions Message-ID: <20180810145150.GE6301@altlinux.org> References: <20180808163302.GG30895@altlinux.org> <4dc9df5d-c0f3-39d4-e287-9af074f2f446@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4dc9df5d-c0f3-39d4-e287-9af074f2f446@altlinux.org> Subject: Re: [devel] X509v3: CRL Distribution Points: help is needed X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 14:51:53 -0000 Archived-At: List-Archive: List-Post: On 2018-08-10 15:52:26 +0300, Paul Wolneykien wrote: >>> А это значит, что издатель подписи (сертификата) рассчитывал >>> на то, что оба указанных им адреса будут расценены как >>> альтернативные и, при недоступности первого, проверяющий >>> перейдёт по второму. >> Именно так. Локальное зеркало - best practice, ибо недоступность >> CRL может привести к тому, что отозванный сертификат будет >> принят как рабочий. >>> Но dirmngr (из пакета gnupg2) считает иначе: он расценивает >>> указанную информацию как список из двух различных CRL, которые, >>> следовательно, оба требуются для проверки подписи. >> Идея здравая, но реализована, мягко говоря, per rectum. >> ... >> Проверять, действительно, нужно все источники (на случай, если >> какое-то свежее изменение в апстриме не доехало до зеркала), но >> отваливаться по UTV (unable to verify|validate) следует только >> когда недоступны _все_ источники. > А вот теперь вопрос, чья это идея (последний абзац выше): это > твоё личное представление о том, как должно быть или всё таки > нечто общепринятое? Это мое личное мнение, основанное на моих же представлениях о том, как можно злоупотребить некорректной реализацией :-) > Допустим, ты сомневаешься насчёт верности реализации в GnuPG. > Но как тебе такое: > [...] > Это я обнаружил в OpenSSL. И там, как видно, внутри цикла выход > по return на _первой_ же непустой DistributionPoint. То, что эти реализации различаются между собой, свидетельствует о том, что как минимум одна из них некорректна. Я же придерживаюсь мнения о том, что некорректны обе :-) > Получаем тот же результат, что и через GnuPG. С той лишь разницей, > что в GnuPG заложен перебор нескольких альтернативных URI для > одной DistributionPoint, а вот OpenSSL даже не предполагает > альтернатив --- все должны быть доступны. Дурь. Ибо кладем один источник - и вся система огребает DoS. > Получается, что предположение о том, что в разбираемом > сертификате оба URI нужно расценивать как альтернативные, не > подтверждается ни теорией (структурой в ASN.1), ни практикой > (openssl verify). Или скажешь, что OpenSSL тоже не аргумент? > А кто же тогда у них главный? Да как всегда: каждый суслик сам себе агроном... Я, конечно, не собираюсь писать свою реализацию, но вполне способен видеть явные ошибки в существующих. А такое поведение софта, которым можно злоупотребить, я считаю ошибкой :-/ -- Alexey V. Vissarionov gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net