Re: [Sidrops] Manifest entry filename validation

Ties de Kock <tdekock@ripe.net> Tue, 24 November 2020 13:20 UTC

Return-Path: <tdekock@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 C0E083A0CBE for <sidrops@ietfa.amsl.com>; Tue, 24 Nov 2020 05:20:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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 (2048-bit key) header.d=ripe.net
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 RxD-bOs9LYw5 for <sidrops@ietfa.amsl.com>; Tue, 24 Nov 2020 05:20:42 -0800 (PST)
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 956E03A0CBA for <sidrops@ietf.org>; Tue, 24 Nov 2020 05:20:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version: Content-Type; bh=wpI+ZliWKastm7v8+BDJGabDAM5NgTk4/xlBiXZfzLA=; b=sBA9lkkaFhYT /7MNC9LIFy4rqYW2ofPri4zoJhBABozrFOgY+YqN5tLQ4hpMSl+b2TVs++8fKp8brSAKgrt7L6PxT P3G+N1sZCNqYvDHcuVI808F9gyqWJX2HSkpZFUpHutgMypVsBuqelq630SmINtH0a8nvgL3xHCErz Hz5FDA87NS0lHws9yOBv0M0K1fR0HzEa8rM6k6AU5HW4o9UxDg0uvmsWBPa+u8k3iTyMs64jXCFeL G1pgse3liUxLebguR3k7IoZI03bPxAmG32qIIB+LRIUHXp3DYuVot3IsBudkXW18SHpidpPBZ88Xr 5khq4g5aj7I5C8aZitvJgA==;
Received: from allealle.ripe.net ([193.0.23.12]:51748) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from <tdekock@ripe.net>) id 1khYFM-0001m6-Vo; Tue, 24 Nov 2020 14:20:40 +0100
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::136]) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from <tdekock@ripe.net>) id 1khYFM-0004hU-TR; Tue, 24 Nov 2020 14:20:40 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Ties de Kock <tdekock@ripe.net>
In-Reply-To: <X7vQ+ff7yAHYuF3e@bench.sobornost.net>
Date: Tue, 24 Nov 2020 14:20:40 +0100
Cc: sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <47A14E7B-89DA-4C9D-AFEF-41F1C1CDC607@ripe.net>
References: <18CC986C-97FA-41F6-A530-F782D3104A31@ripe.net> <73eae8a5-a400-cb45-7fbc-9cc7f79be804@verizon.net> <X7aywnRgq3ubVUBu@bench.sobornost.net> <X7bVOm2uzffEWbMY@bench.sobornost.net> <DB542A6C-A0CB-4F0A-9D15-B06AA3B98875@ripe.net> <X7vQ+ff7yAHYuF3e@bench.sobornost.net>
To: Job Snijders <job@ntt.net>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-ACL-Warn: Delaying message
X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e152a0938c22201691620927beeed855d9
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/ZyKcsGDHYcIrz8qrAYsEbh9mA34>
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: Tue, 24 Nov 2020 13:20:44 -0000

Hi Job, all,

> On 23 Nov 2020, at 16:10, Job Snijders <job@ntt.net> wrote:
> 
> Thanks Ties, how about:
> 
> --------------------
> 
> Section 4.2.2 "Names in FileAndHash objects"
> 
> The following restrictions are imposed on the names that appear in the
> fileList:
> 
> 1. Only a subset of IA5string characters are permitted: a-z, A-Z, 0-9, . (DOT), - (HYPHEN), and _ (UNDERSCORE).
> 
> 2. Each name MUST be suffixed with the appropriate filename extension defined for the object type, and the filename extension MUST be lowercase, e.g., '.cer' or '.roa'.
> 
> 3. The . (DOT) character MUST appear exactly once.
> 
> As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename.


Looks good. However, after an internal discussion during which we realised that
empty names (e.g. .cer) were valid filenames under the previous proposal, and
after validating that all current valid objects from the major trust anchors
adhere to our proposal, we would like to propose:

----------
Section 4.2.2 "Names in FileAndHash objects"

Names that appear in the fileList MUST consist of one or more characters from
the set a-z, A-Z, 0-9, - (HYPHEN), or _ (UNDERSCORE), followed by a single .
(DOT), followed by a three-letter extension a-z.

As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename.