IETF Logo Mail Archive

Re: [Sidrops] Manifest entry filename validation

Tim Bruijnzeels <tim@nlnetlabs.nl> Thu, 19 November 2020 16:47 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 CE46E3A0BED for <sidrops@ietfa.amsl.com>; Thu, 19 Nov 2020 08:47:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 DohJrecq7XI3 for <sidrops@ietfa.amsl.com>; Thu, 19 Nov 2020 08:47:32 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD9253A0AB1 for <sidrops@ietf.org>; Thu, 19 Nov 2020 08:47:31 -0800 (PST)
Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 43FDB60577; Thu, 19 Nov 2020 16:47:29 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1605804448; bh=JnmAy6ywetfK2WbvO/vm1l9T/T+6A4HWWdvAlX0Pcjw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=mwVJTAi4n/dOPoNEKKat9pjicBmspsmh95m5VcxYNOG46RQXEJfectGnvR8j4HiLG ZVh5j0l05PkxrTc//d8DC/V9vscpabED4yxv5+YPNORTs8ci7TLlSmMGbPJcs0+JOh jCC79F41wHsK5hLZmN7h0ws/UH55VpIHmHkK48cyikZ+aP00D+nlAWQh3Ptn3DkxbP Ftr6TfL0mxij6zHQffvVNZlGK/GXhJvDUQ4tLxj8dVlqvvQsXgpXhJhQJtJHNYlrXL wkmA2Zt0paWnRsYqegsNEIkAp0ANnBgBusS3ZafqtoCgNyinjxGwQkCuTmStLW1Qt5 XIzwu7FwA6xqQ==
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <FBEEE5E8-2A49-45E5-A840-F4E0BEEFC659@ripe.net>
Date: Thu, 19 Nov 2020 17:47:27 +0100
Cc: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>, sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0A014A96-D583-4319-8660-C3EBB1FEE446@nlnetlabs.nl>
References: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> <3078ef7c-e282-a196-9f07-21789276673d@verizon.net> <FBEEE5E8-2A49-45E5-A840-F4E0BEEFC659@ripe.net>
To: Erik Rozendaal <erozendaal@ripe.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/CHkeMAYhcYWeGGluxkAIPD6kRYs>
Subject: Re: [Sidrops] Manifest entry filename validation
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, 19 Nov 2020 16:47:39 -0000

Hi,

> On 19 Nov 2020, at 16:53, Erik Rozendaal <erozendaal@ripe.net> wrote:
> 
> Hi Steve,
> 
>> On 19 Nov 2020, at 15:59, Stephen Kent <stkent=40verizon.net@dmarc.ietf.org> wrote:
>> 
>> I believe the character set restrictions are appropriate, as is prohibiting single and double period directory entry names, and mandating the presence of the 3-character suffix. I also have no problem with prohibiting a specific set of names, such as the Windows-centric ones you mention.
>> 
>> The proposal to prohibit entries that differ only due to capitalization is worrisome. All of the other syntactic tests are easy to perform on individual entries. This test seems to require examining all entries at once to detect a violation. I'd rather not include this rule, because of the added complexity. Would folks like to mandate use of only upper or lower case characters as an alternative?
> 
> Most of the additional proposed rules are an (probably incomplete) attempt to make rsync work on non-Unix systems. Maybe we can just make this a recommendation or SHOULD, or just forget about this. RRDP should not be affected unless you directly map object URIs to filenames on a file system. 
> 
> Only allowing lower- or uppercase characters will break existing objects in the RPKI and require changes at the CA level, so that's probably a no-go.

Indeed this would be hard for my CA implementation. Or well, it's easy enough to fix in future, but there are versions deployed today that use both lower and uppercase.

So, where was this coming from? Case-preserving, but insensitive, file systems?

I could live with some normative language that instructs a CA to avoid creating case-insensitive collisions between filenames.



Tim



> 
> Kind regards,
> Erik
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops

v2.23.0 | Report a Bug | By Email