From: Job Snijders <job@sobornost.net>
Date: Wed, 24 Jul 2024 19:54:50 +0000 (+0000)
Subject: Clarify why CRL Number extensions do not need to be processed
X-Git-Tag: 1.6.3~10
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=refs%2Fpull%2F142%2Fhead;p=thirdparty%2FFORT-validator.git

Clarify why CRL Number extensions do not need to be processed
---

diff --git a/src/object/crl.c b/src/object/crl.c
index 78e9bfbe..b075dca6 100644
--- a/src/object/crl.c
+++ b/src/object/crl.c
@@ -106,9 +106,22 @@ static int
 handle_crlnum(void *ext, void *arg)
 {
 	/*
-	 * We're allowing only one CRL per RPP, so there's nothing to do here I
-	 * think.
+	 * From draft-spaghetti-sidrops-rpki-crl-numbers:
+	 *
+	 * In the RPKI, a wellformed Manifest FileList contains exactly one
+	 * entry for its associated CRL, together with a collision-resistant
+	 * message digest of that CRLs contents (see Section 2.2 of RFC6481
+	 * and Section 2 of RFC9286). Additionally, the target of the CRL
+	 * Distribution Points extension in an RPKI Resource Certificate is the
+	 * same CRL object listed on the issuing CAs current manifest (see
+	 * Section 4.8.6 of RFC6487). Together, these properties guarantee
+	 * that RPKI RPs will always be able to unambiguously identify exactly
+	 * one current CRL for each RPKI CA. Thus, in the RPKI, the ordering
+	 * functionality provided by CRL Numbers is fully subsumed by monotonically
+	 * increasing Manifest Numbers (Section 4.2.1 of RFC9286), thereby
+	 * obviating the need for RPKI RPs to process CRL Number extensions.
 	 */
+
 	return 0;
 }