IETF Logo Mail Archive

Re: [Sidrops] Manifest entry filename validation

Tim Bruijnzeels <tim@nlnetlabs.nl> Tue, 24 November 2020 08:21 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 6288A3A19D1 for <sidrops@ietfa.amsl.com>; Tue, 24 Nov 2020 00:21:29 -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, 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=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 e1SUIezU3tRz for <sidrops@ietfa.amsl.com>; Tue, 24 Nov 2020 00:21:26 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.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 173203A19D0 for <sidrops@ietf.org>; Tue, 24 Nov 2020 00:21:25 -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 61CC2601C8; Tue, 24 Nov 2020 08:21:23 +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=1606206082; bh=BTb7BCIOURHxM6leJCVSC+0fIAjFgBFeLBavBzEnDdQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=cqxtnhie/+a9buRvBPYDI2JKkZ0dD4LCt/67eN8vtB0vsKn4nBVl09kD3Ng0GYQrM e275yJ8YIHf8i+u3aOPS+fs84b0CGOrKEO1Fn9YcyO4nCaigQZ6nA3W+F0WNRFVEtE oLzEbGO3bsGbkhCReq2D+wc7RivUYAtM1TtKOhDzx994/lngsSuXZf6XWmQdKFfsAj C/RpWhCwEUs/mqhJOPeunk+Kra2vx1kNv3dJFqWXAWArbLkzWVPN9vL5WEEfpRmed7 HXCXh3mMj8Hsqe0mQhEPdWWj5cNLdpVHp8zwmQQWI/9S8R7jXhXgxfm1yb+Q+Yn44a /VXU1S0GNKWRA==
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: <X7vQ+ff7yAHYuF3e@bench.sobornost.net>
Date: Tue, 24 Nov 2020 09:21:20 +0100
Cc: Ties de Kock <tdekock@ripe.net>, sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <515DD1D6-C265-4EFE-9937-8E7B003B2068@nlnetlabs.nl>
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>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/D_h-VY4qYYX78ckjwwN7Zr3GFwc>
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 08:21:29 -0000

Hi Job, Steve, all,

I am losing track a bit, but I believe this text below was the latest suggestion by Job to Steve, right?

Question / suggestion on extensions below.

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

I think we should probably have a normative reference here to section 7.2 of RFC 6481 (Repository Structure), or better yet to the "RPKI Repository Naming Scheme" registry maintained by IANA:

https://www.iana.org/assignments/rpki/rpki.xhtml

As that section says the extensions are supposed to be "three-letter", presumably to make file name parsing safe. Not sure if that needs to be repeated here explicitly.

As a side note, while I am here.. I would also like to note that it's a bit unfortunate that '.cer' can be _any_ resource certificate. So it could be:
- An RPKI CA certificate used for delegations
- A 'naked' EE certificate (as possibly used by RFC 7909)
- A BGPSec Router certificate

At least my quick scanning of RFC 6481 seems to imply this, as it uses the term 'certificate' without applying further constraints. However, it would be nicer for RPs if these cases used different extensions. This could simplify parsing quite a bit. And while this would be a breaking change in theory, I think it could be done without impact in practice since currently *all* .cer files found in the wild are CA certificates.

> 
> 3. The . (DOT) character MUST appear exactly once.
> 
> As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename.

Looks good to me.

Tim

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

v2.23.0 | Report a Bug | By Email