Re: [Sidrops] Manifest entry filename validation

Robert Kisteleki <robert@ripe.net> Tue, 24 November 2020 13:29 UTC

Return-Path: <robert@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 DCFD03A0D45 for <sidrops@ietfa.amsl.com>; Tue, 24 Nov 2020 05:29:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level:
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, 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 VfVhgXfXeoFH for <sidrops@ietfa.amsl.com>; Tue, 24 Nov 2020 05:29:27 -0800 (PST)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 25B003A0D44 for <sidrops@ietf.org>; Tue, 24 Nov 2020 05:29:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=Content-Type:MIME-Version:Date:Message-ID:From:To:Subject: CC; bh=BbUAVDzGjgCG3FqOmJyoUpWb90vHroc9CjNzqEbnkpg=; b=Luu8Im3b22IxGqh4sKqWxg qMbvee2LKTGyGxPzv3e1B1CafzTnpzqRuk6EQj9lOcfo6uiuIW3uynF6VCjCqVaaFVuzDVp+8yo5l BJa2qSNrhTSSU7oZhNIEJm6Kun/b8CGvk5cCB9yq0A5UuXWM2ToBm2IWXGOHnbhkXTBmyBkkVni8G VWp3/HHotanMxHhtCbjg1B9NqqcwzxiyxVeLgQll0U14NWZdek+84zRQZzi30lo1uK8UmTX5P1B1P i29SBJ5lQcaYA+KS2Wh5lcL3uLURuRL/wfRYRLdCVL30sK1Mb7b5xV9kSJJW3fXZnOf99ISL3xrW5 uAawIu8+V52g==;
Received: from bufobufo.ripe.net ([193.0.23.13]:58288) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from <robert@ripe.net>) id 1khYNp-0005lv-S3 for sidrops@ietf.org; Tue, 24 Nov 2020 14:29:25 +0100
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::aff]) by bufobufo.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from <robert@ripe.net>) id 1khYNp-00068L-PH for sidrops@ietf.org; Tue, 24 Nov 2020 14:29:25 +0100
To: sidrops@ietf.org
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> <47A14E7B-89DA-4C9D-AFEF-41F1C1CDC607@ripe.net>
From: Robert Kisteleki <robert@ripe.net>
Organization: RIPE NCC
Message-ID: <ceab2000-8b06-afb6-39a4-d4ad72cb5cc0@ripe.net>
Date: Tue, 24 Nov 2020 14:29:25 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <47A14E7B-89DA-4C9D-AFEF-41F1C1CDC607@ripe.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
X-ACL-Warn: Delaying message
X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a2747d2a27f8077b27bd418cc82affcccdf3
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/7BUGi6NAlZO-Vm9ooTN2luICYhA>
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:29:29 -0000

>> 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.

At this point perhaps a regexp would be simpler to specify?

I also note that both miss a clause saying the filenames are case 
sensitive, thus 'vixxBTS_TVXQ-2pmGOT7.cer' and 
'VixxBTS_TVXQ-2pmGOT7.cer' are different certificates.

Robert