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

Tim Bruijnzeels <tim@nlnetlabs.nl> Thu, 14 May 2020 07:36 UTC

Return-Path: <tim@nlnetlabs.nl>
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 E8A603A0400 for <sidrops@ietfa.amsl.com>; Thu, 14 May 2020 00:36:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl
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 5VFkOx0k3s4n for <sidrops@ietfa.amsl.com>; Thu, 14 May 2020 00:36:01 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (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 15CF63A03F6 for <sidrops@ietf.org>; Thu, 14 May 2020 00:35:52 -0700 (PDT)
Received: from [IPv6:2001:981:4b52:1:edc9:447a:8576:9b98] (unknown [IPv6:2001:981:4b52:1:edc9:447a:8576:9b98]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 4282937389; Thu, 14 May 2020 09:35:50 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl
Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1589441750; bh=oSuLmQoAJOLsq2OA6jgvgfwX0o23I/DUoDrZlcJiuIQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=XnaXwaauu81oXU4hSEtTeykOmMttSjljMi7WZoCREhWHMDhE1kc5UpjQwtfUhs4AG tHtlErUGPsUCgersqKjE5Eeb0ZuEm41Zbw9xPHeotcaBqUlEjVsBqlQpQNb7t8D1s4 NT8u1BdWWk+8Y6g0F/8j/zwBtwTckbt7ESE3xKS0=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <076ad9b0-ea5d-47a4-52f7-8b913dc6c1ae@verizon.net>
Date: Thu, 14 May 2020 09:35:49 +0200
Cc: "sidrops@ietf.org" <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C49A008F-02FE-4A97-9E96-5EAAFBA5AC48@nlnetlabs.nl>
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>
To: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/Crd-TKibbifALOdpb39V0r4TJOA>
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: Thu, 14 May 2020 07:36:04 -0000

Hi,

> On 13 May 2020, at 18:11, Stephen Kent <stkent=40verizon.net@dmarc.ietf.org> wrote:
> 
> Guys,
>>> I will revise the text describing how to handle this case, based on WG
>>> consensus. Your approach is very robust, but also complex. Since there
>>> should be only one CRL in the manifest, and since Tim says that no
>>> RPKI CA generates more than??? one, I tend to favor a simple
>>> requirement here, but ...
>> indeed no ca SHOULD push more than one CRL.  but i do not think i would
>> recommend not defending against it.
>> 
>> randy
> 
> I think we all agree that the revised Section 6 text needs to accommodate the possibility that a manifest will list more than one CRL, even though this OUGHT NOT happen (see RFC 6919). The only question?? is how hard do we require an RP to work if it encounters more than one CRL. I prefer a simple approach to selecting one, and a mandatory warning. Rob has offered a more sophisticated, and complex approach, based on his working RP code.

What may not have been clear from my earlier message is that I agree that in today's world it's worth supporting the possibility of more than one .crl like Rob A. has done.

That said, we are looking to improve things here, and reducing corner cases is good.

This is about the number of current .crl files on a manifest, not about files that may still linger in the repository under the directory - e.g. for other keys. Even if it is not explicit, RFC 6480 certainly points at having one CRL per keypair. And 6 out of 6 independent CA implementations have done exactly that. Therefore I think it would be perfectly safe to add a requirement in the MFT RFC update that there MUST be one CRL only. This will simplify things greatly for RPs.

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.

Tim





> 
> I await a consensus from the WG.
> 
> Steve
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops