Re: [Sidrops] Manifest entry filename validation

Russ Housley <housley@vigilsec.com> Tue, 24 November 2020 15:12 UTC

Return-Path: <housley@vigilsec.com>
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 8CB2C3A10D4 for <sidrops@ietfa.amsl.com>; Tue, 24 Nov 2020 07:12:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Level:
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 DCQmHKHGUvOA for <sidrops@ietfa.amsl.com>; Tue, 24 Nov 2020 07:12:05 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01A973A10D2 for <sidrops@ietf.org>; Tue, 24 Nov 2020 07:12:05 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6A325300B96 for <sidrops@ietf.org>; Tue, 24 Nov 2020 10:12:02 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xgYzrzDLLjKI for <sidrops@ietf.org>; Tue, 24 Nov 2020 10:12:00 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id AC6FD300670; Tue, 24 Nov 2020 10:12:00 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <515DD1D6-C265-4EFE-9937-8E7B003B2068@nlnetlabs.nl>
Date: Tue, 24 Nov 2020 10:12:02 -0500
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3324ED41-816A-4EAB-9629-6C2712F9A58C@vigilsec.com>
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> <515DD1D6-C265-4EFE-9937-8E7B003B2068@nlnetlabs.nl>
To: Tim Bruijnzeels <tim@nlnetlabs.nl>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/FB6w65E3aQIkVGqsoSvRr-EYyHY>
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 15:12:08 -0000

Tim:

RFC 2585 is the document that specifies the conventions of ".cer" and ".crl" for X.509 certificates and X,509 CRLs, respectively.

Russ


> On Nov 24, 2020, at 3:21 AM, Tim Bruijnzeels <tim@nlnetlabs.nl> wrote:
> 
> 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
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops