Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)

Mikhail Puzanov <mpuzanov@ripe.net> Fri, 15 May 2020 09:38 UTC

Return-Path: <mpuzanov@ripe.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C66F3A084F for <sidrops@ietfa.amsl.com>; Fri, 15 May 2020 02:38:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CVFY-lK9mvO for <sidrops@ietfa.amsl.com>; Fri, 15 May 2020 02:38:44 -0700 (PDT)
Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D63213A084D for <sidrops@ietf.org>; Fri, 15 May 2020 02:38:43 -0700 (PDT)
Received: from allealle.ripe.net ([193.0.23.12]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <mpuzanov@ripe.net>) id 1jZWni-000BV1-DI for sidrops@ietf.org; Fri, 15 May 2020 11:38:42 +0200
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::4dd]) by allealle.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from <mpuzanov@ripe.net>) id 1jZWni-0003mW-99; Fri, 15 May 2020 11:38:42 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Mikhail Puzanov <mpuzanov@ripe.net>
In-Reply-To: <2F7B5AE6-8250-4937-B246-12F6F1C978CD@ripe.net>
Date: Fri, 15 May 2020 11:38:41 +0200
Cc: sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3BA5C557-E5C7-448B-86CC-539BA921E439@ripe.net>
References: <be9450ba-fe9c-465f-98a2-919772b3b32a.ref@verizon.net> <be9450ba-fe9c-465f-98a2-919772b3b32a@verizon.net> <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net> <73b88326-d537-93eb-b0d0-a0a82507081c@verizon.net> <m2imh0x750.wl-randy@psg.com> <076ad9b0-ea5d-47a4-52f7-8b913dc6c1ae@verizon.net> <C49A008F-02FE-4A97-9E96-5EAAFBA5AC48@nlnetlabs.nl> <156c83ba-d4d8-8baa-7f87-a2600cb9c19a@verizon.net> <20200515090840.12a9464a@grisu.home.partim.org> <2F7B5AE6-8250-4937-B246-12F6F1C978CD@ripe.net>
To: Oleg Muravskiy <oleg@ripe.net>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
X-ACL-Warn: Delaying message
X-RIPE-Signature: e2494821e8eb7112beaeaa277e8c25e0b764c6f7fd51a44148e4d8bec2c8752d
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/Pm7fzqySl3pEv8EwnokFfVK3Z7k>
Subject: Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 May 2020 09:38:47 -0000

Agree.

RIPE NCC’s validator 2 implemented somewhat complicated logic for 
picking up “the latest valid manifest with the latest valid CRL”
and in the validator 3 it had been changed to a much simpler version
“pick up the latest manifest, validate it, and makes sure it has 
a hash pointing to a valid CRL”.

In the last 2 years of running both versions we have not seen any 
discrepancies in the results reported by them that would be attributed 
to this specific change of the algorithm. So for all (99.9% of?) 
practical purposes, nailing it down to “manifest MUST include exactly 
one hash pointing to a CRL” would be preferable. Let alone it would 
allow for simpler and more efficient RP code.

--
Mikhail Puzanov,
Senior Software Engineer,
RIPE NCC


> On 15 May 2020, at 11:18, Oleg Muravskiy <oleg@ripe.net> wrote:
> 
> On 15 May 2020, at 09:08, Martin Hoffmann <martin@opennetlabs.com> wrote:
>> 
>> Stephen Kent wrote:
>>> Tim,
>>> 
>>>> If not, then indeed we need to have a discussion about how to deal
>>>> properly with multiple CRLS. E.g. do you check *all* of them for
>>>> each issued certificate, or do you only check the CRL matching the
>>>> CRLDP of that certificate? I would also be very curious to know
>>>> which use case warrants having this complexity.  
>>> 
>>> My suggestion is the KISS approach - first .crl file that has a valid 
>>> hash is the one to use, and others are ignored. That's less forgiving 
>>> than what Rob accommodates, but being forgiving here might take
>>> pressure of a CA to do its job properly.
>> 
>> I’m not sure it really does. Rather, it will lead to strange looking
>> issues: If the wrong CRL accidentally made it onto the manifest and it
>> comes first, all objects are invalid even though everything sort of
>> looks fine. This may even come and go if a CA reorders the CRLs when
>> it reissues the manifest[0]. If all CRLs are referenced by objects, some
>> objects suddenly are invalid while others aren’t.
>> 
>> I think invalidating the manifest with a clear warning is the more
>> straightforward approach and much easier to debug.
> 
> I tend to agree with this approach. It will keep RFC and validator’s code simple and force CAs to fix their bugs.
> 
> Oleg
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops