IETF Logo Mail Archive

Re: [Sidrops] Manifest entry filename validation

Tim Bruijnzeels <tim@nlnetlabs.nl> Tue, 01 December 2020 07:25 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 545FE3A02BB for <sidrops@ietfa.amsl.com>; Mon, 30 Nov 2020 23:25:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8QVXt_XM8LXk for <sidrops@ietfa.amsl.com>; Mon, 30 Nov 2020 23:25:10 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::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 37BAA3A00C9 for <sidrops@ietf.org>; Mon, 30 Nov 2020 23:25:09 -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 9A79C600E3; Tue, 1 Dec 2020 07:25:07 +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=1606807507; bh=gFBgLidGPgDysQiS7l4Q9eHK/2wFfDODy56KWPMCH5Y=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Mnw9s/H6pJvNZS3rwAx9dxReLNl6TX3+RV9oAZsGOyNKfZ+qNJ1L1ftBnV47kgmSN n8PAQcgNiiqCwh9QbJeipl6K2nYuiZwrbjv0+92+s8YTm0ON3vQR1JfM41x09imCIL DWhEtfI+Ntw3ZxH+tgadyfOXdFEYYyuoEeNjvtfjbQbZyFBPZbbHQ4c+COr/1FFoO+ l5UmiwckJXBYGO4QmTt5w0mv2JIQfic52wJUCUyoE5gOpkDbZML3yAxk1KybvFnnmZ m74P0YLl0SaSbo2wkeEx9embHn2lZlFM3QneX7C2JCnO3Sav/pleIcbtFC+tSxRKCE JX/RYPZOXc2Ig==
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: <ab0f06f4-43ff-6d7d-0a8a-0ff51f7f8773@verizon.net>
Date: Tue, 01 Dec 2020 08:25:04 +0100
Cc: sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <8C6FEDBA-C3C1-48AF-B4A6-9C5C69244D15@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> <47A14E7B-89DA-4C9D-AFEF-41F1C1CDC607@ripe.net> <1a26db25-a898-2a19-77c1-70e620def269@verizon.net> <ab0f06f4-43ff-6d7d-0a8a-0ff51f7f8773@verizon.net>
To: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/xKk7NAZ6pCm0IbisnziKVWy3Apw>
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, 01 Dec 2020 07:25:13 -0000

Hi Steve,

> On 30 Nov 2020, at 21:21, Stephen Kent <stkent=40verizon.net@dmarc.ietf.org> wrote:
> 
> I've seen no responses to Tim's suggestion to create alternate extension types for certs used to other purposes, e.g., router certs, so I will ask my buddies to issue another version of the ID with the text below. Thanks to everyone for their contributions to this additional, clarifying text.

Works for me. If we should ever think about updating the manifest structure (out of scope for now clearly), then we could consider to include specific type information fields rather than depending on filename extensions.

Tim

> 
> Steve
>> Section 4.2.2 "Names in FileAndHash objects"
>> 
>> Names that appear in the fileList MUST consist of one or more characters chosen
>> from the set a-z, A-Z, 0-9, - (HYPHEN), or _ (UNDERSCORE), followed by a single .
>> (DOT), followed by a three-letter extension. The extension MUST be one of those
>> enumerated in the "RPKI Repository Naming Scheme" registry maintained by IANA [IANA]
>> 
>> As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename.
>> 
>> 
>> add the following Normative Reference entry:
>> 
>> [IANA] https://www.iana.org/assignments/rpki/rpki.xhtml#name-schemes 
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops

v2.23.0 | Report a Bug | By Email