From nobody Tue Nov 24 07:12:09 2020 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; 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 In-Reply-To: <515DD1D6-C265-4EFE-9937-8E7B003B2068@nlnetlabs.nl> Date: Tue, 24 Nov 2020 10:12:02 -0500 Cc: SIDR Operations WG 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> <515DD1D6-C265-4EFE-9937-8E7B003B2068@nlnetlabs.nl> To: Tim Bruijnzeels X-Mailer: Apple Mail (2.3445.104.17) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: >=20 > Hi Job, Steve, all, >=20 > I am losing track a bit, but I believe this text below was the latest = suggestion by Job to Steve, right? >=20 > Question / suggestion on extensions below. >=20 >> On 23 Nov 2020, at 16:10, Job Snijders wrote: >>=20 >> Thanks Ties, how about: >>=20 >> -------------------- >>=20 >> Section 4.2.2 "Names in FileAndHash objects" >>=20 >> The following restrictions are imposed on the names that appear in = the >> fileList: >>=20 >> 1. Only a subset of IA5string characters are permitted: a-z, A-Z, = 0-9, . (DOT), - (HYPHEN), and _ (UNDERSCORE). >>=20 >> 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'. >=20 > 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: >=20 > https://www.iana.org/assignments/rpki/rpki.xhtml >=20 > 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. >=20 > 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 >=20 > 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. >=20 >>=20 >> 3. The . (DOT) character MUST appear exactly once. >>=20 >> As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename. >=20 > Looks good to me. >=20 > Tim >=20 >>=20 >> _______________________________________________ >> Sidrops mailing list >> Sidrops@ietf.org >> https://www.ietf.org/mailman/listinfo/sidrops >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops