Re: [Sidrops] Manifest entry filename validation

Tim Bruijnzeels <tim@nlnetlabs.nl> Tue, 24 November 2020 15:44 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 A16E43A110F for <sidrops@ietfa.amsl.com>; Tue, 24 Nov 2020 07:44:51 -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 ljnnShIl4XtI for <sidrops@ietfa.amsl.com>; Tue, 24 Nov 2020 07:44:49 -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 2BD5C3A110E for <sidrops@ietf.org>; Tue, 24 Nov 2020 07:44:48 -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 C2B276029D; Tue, 24 Nov 2020 15:44:46 +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=1606232686; bh=66SMSajjrjYE1eAQZTjTAmLkqclWZCBwpB+lusa+L8o=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Gg2Gt/MisLqNQyzqnetN3cc/kpF8HBepAd/3NEd23hNDLD18o23X2prsLttcCzU5b 1kE+AiJd9DFDGPUIlmoal1L5L1/lQNvWcBGm0x9bPn1+VmiS4Mm8pLrTly797/XSkc xx2L8K8FpbO5LaXw1S37gXPRd2+v1zPcBGRMkYh8c3EoXdMloCFojJvfZdaUlq2IxK dt6Bbf1JA/5WrDDGh+wN/hU8kIlXBFATJ5zw2fCiJX7NKrEy9fZV5IVD7RZY1kMJrP 5Vhq/uL1E6qXYlhP278SRN78NgGkCLlQ4xstCJpbrJ5Gp1+/BXbnTuo9NlEiNC9QW0 5XqZ/o+n4TzTA==
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: <3324ED41-816A-4EAB-9629-6C2712F9A58C@vigilsec.com>
Date: Tue, 24 Nov 2020 16:44:44 +0100
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F643B1EE-D849-4465-A589-E9F82E0C67A4@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> <515DD1D6-C265-4EFE-9937-8E7B003B2068@nlnetlabs.nl> <3324ED41-816A-4EAB-9629-6C2712F9A58C@vigilsec.com>
To: Russ Housley <housley@vigilsec.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/U2zCboaZ_ejomq6NQLClg71jjuE>
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:44:52 -0000

Hi Russ,

> On 24 Nov 2020, at 16:12, Russ Housley <housley@vigilsec.com> wrote:
> 
> Tim:
> 
> RFC 2585 is the document that specifies the conventions of ".cer" and ".crl" for X.509 certificates and X,509 CRLs, respectively.

That may well be, but I still think it would be useful, in the context of RPKI, to be able to differentiate between different types of .cer *before* parsing rather than differentiate while parsing. And if we did, then an entry in the IANA registry "RPKI Repository Naming Scheme" could be appropriate. Anyway, I don't want to complicate things - if RP implementers don't speak up that they want this, then I would say we just leave it as an aside..

The other more important reason for bringing up that registry is because it already defines the extensions one can expect. So I would suggest that the following in item 2

  extension defined for the object type

Becomes:

  extension defined for the object type in the IANA registry "RPKI Repository Name Scheme" 

Tim

> 
> 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
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops