Clarify why CRL Number extensions do not need to be processed

diff --git a/src/object/crl.c b/src/object/crl.c
index 78e9bfbed22e5bab0ec7ac413de32743a3f196fc..b075dca64052eb03c10c9a7c05b58cb8fbde42ca 100644 (file)
--- 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;
 }