Re: [Sidrops] I-D Action: draft-ietf-sidrops-deprecate-rsync-00.txt

Tim Bruijnzeels <> Mon, 07 September 2020 12:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8E87D3A0CA2 for <>; Mon, 7 Sep 2020 05:42:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SBLs1CM_ssIH for <>; Mon, 7 Sep 2020 05:42:54 -0700 (PDT)
Received: from ( [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 479D43A0CA1 for <>; Mon, 7 Sep 2020 05:42:54 -0700 (PDT)
Received: from (unknown [IPv6:2001:981:4b52:1:fce7:462d:d025:2a3d]) by (Postfix) with ESMTPSA id 768DF26399; Mon, 7 Sep 2020 14:42:51 +0200 (CEST)
Authentication-Results:; dmarc=fail (p=none dis=none)
Authentication-Results:; spf=fail
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1599482571; bh=NXY3GdtHi2333PlFM6U5CiJbMzEuwDEWfRPl5C9Oxtc=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=jf8tYePVjYLmxfz08KDzVAa6tRqOZy6tYeggT/Uz2Kxn1kGYvEYjnOpfXa/8rfY4O MdlSIdPq0kUdGItOl6jD/j/eLXe6m0cq79fTOSuQMPArYvAHIUziJrZW0pTpbUmRZ0 C90QucUsfcKj3bjs/84JUMXtOu6i6HGQ1iQScLuE=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Tim Bruijnzeels <>
In-Reply-To: <>
Date: Mon, 07 Sep 2020 14:42:51 +0200
Cc: SIDR Operations WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Russ Housley <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-deprecate-rsync-00.txt
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: Mon, 07 Sep 2020 12:42:56 -0000


> On 4 Sep 2020, at 22:34, Russ Housley <> wrote:
> Tim:
>>> I think that RFC 6487 should also be updated to adjust the RPKI certificate profile.
>> Can you please elaborate why?
>> My personal drive with this draft, despite its name perhaps, is to deprecate the *operational* dependency on rsync. In my opinion the rsync URIs can stay and serve as namespaces, even if the servers are not guaranteed to be available. Think XML name spaces. I don't think we need to forbid running rsyncd either.
> For example, RFC 6487, Section 4.8.6 says:
>   ... The preferred URI access mechanism is a single rsync
>   URI ("rsync://") [RFC5781] that references a single inclusive CRL for
>   each issuer.
>   ... Other access form URIs MAY be used in addition to the
>   rsync URI, representing alternate access mechanisms for this CRL.
> There are similar words in Sections 4.8.7,, and
> It seem to me you are changing the "preferred" way to handle these, even if both are allowed for decades.

Right, thank you for this pointer!

I think I have misremembered some of what RFC 6487 said. It seems that even though only 'rsync' is used to today for the CRL DP, SIA and AIA - other access mechanisms are explicitly allowed.

I would not feel safe about including https in there today without some proper field testing, but it seems that updating this may indeed be less problematic than I thought. It would still leave questions around certificate provisioning (6492) and publication (8181). I need to think about this a bit.


>>> In phase 1, several URLs in the certificate could offer rsync:// and rrdp://, and then in Phase 4 (not documented), the rsync:// can get dropped.
>> It may not be aesthetically pleasing, but removing the rsync URIs completely is a much, much bigger effort. Incomplete dump of pointers of what would be affected
> I agree, and that it is why I called it Phase 4, which is beyond the scope of this document.
> Russ