a positive test proves Ze does what the requirement demands and a negative one proves it refuses what the requirement forbids
No row in the public ledger
RFC 6482 - A Profile for Route Origin Authorizations (ROAs)
Every requirement this repository extracted from RFC 6482, the tests bound to it, and what a reader has verified about them. This summary is not enrolled.
Overview
Positive
what Ze has
the requirement admits no counter-case, so one polarity plus a recorded reason is the whole proof available for it
one direction is tested, the other is neither tested nor excused, and nothing states which
scoped tests exist; the remaining obligation is unmet or unproven, with zero whole-requirement credit
no test carries the requirement id, whether or not a gap states why
a red was observed once under a recorded procedure, and the unit, the claim and the producer it rested on still hash to what was recorded. The break is not re-run. A test pair is not a proof until one has been observed
Neutral
measures that are neither good news nor bad
MUST-level requirements this summary DECLARES. The gate holds none of them, because this RFC is not enrolled (third-party), so every share below reads what the summary records rather than what the gate enforces
an obligation that does not bind Ze. A {not-applicable} annotation says it never bound; a {feature-declined} annotation says its condition is an optional feature Ze does not offer, and quotes the RFC sentence that makes it optional. Scope, not coverage: it stays in the denominator every share on this page is taken over
a {not-applicable} annotation says the obligation does not bind Ze, so no test is owed for it. It stays in the denominator every share here is taken over
a {lower-layer} annotation says a layer under Ze performs the behavior, on state Ze installs into that layer, and names the producer that installs it. The obligation binds Ze and is met; Ze proves none of it, because its own boundary carries no value the behavior reads
a {feature-declined} annotation says the obligation is conditional on a feature the RFC makes optional and Ze does not offer, and it quotes the sentence that makes it optional. The condition is false, so nothing is owed and nothing is missing. It stays in the denominator every share here is taken over
The 8 shares marked as a part above are the whole of the 9 gated MUSTs: they add to 100%. Proven by a recorded break is a share of TAGGED UNITS, a different population, so it is not one of them.
How to read the colors
A color names what the measure MEANS, not how well Ze scores on it. Green is a good outcome at any value, red is a bad one, and neither a population nor a scope count is an outcome, so both take no color. The number under the label is what says how far Ze has got.
| Card | Tone here | Why that color |
|---|---|---|
| MUSTs declared | neutral | no color: a population is a scale, and a larger one is neither good news nor bad. It is the accounting total |
| Out of scope | neutral | no color: an obligation that never bound Ze is neither an achievement nor a failure, and counting it either way would be a claim |
| Tested both ways | ok | green at every value: a test pair is the outcome this gate exists to produce, and the share under the label is what says how far Ze has got |
| One polarity plus reason | ok | green at every value: where no counter-case exists, one polarity IS the complete answer, and a recorded reason is what the gate demands beside it |
| One polarity, unexcused | ok | green at zero, RED above it: half a proof with no reason for the other half |
| Partial proof; remaining gap | ok | green at zero, RED above it: a tested clause cannot prove the whole requirement |
| No test at all | ok | green at zero, RED above it: a binding obligation nothing exercises is a claim with nothing behind it, whether or not a reason is stated |
| Not applicable | neutral | no color: an obligation that never bound Ze is neither an achievement nor a failure, and counting it either way would be a claim |
| Met below Ze | neutral | no color: an obligation met below Ze is neither a test Ze wrote nor work Ze owes, and the two green shares above are what says how much Ze proves itself |
| Optional feature declined | neutral | no color: an obligation whose condition Ze never meets is neither an achievement nor a failure. The absent FEATURE is disclosed on the RFC's own status row, as an implementation gap a later scope decision can revisit |
| Proven by a recorded break | ok | green at every value: an observed break is the outcome the discrimination gate exists to produce. The denominator is TAGGED UNITS, not obligations, so this share is not one of the parts above |
| Audit verdicts | warn | RED on the first weak, wrong or unimplemented verdict, amber while a verdict is no longer current or a gated MUST is unjudged, green when every one is judged sound and current |
At a glance
| Field | Value |
|---|---|
| Public status | No row in the public ledger |
| Enrolment | Not enrolled (third-party) |
| Requirements | 10 |
| Gated MUST-level | 9 |
| Not applicable, so out of scope | 9 |
| Declared gaps | 0 |
| Declared gaps a test demonstrates | 0 |
| Gated with no test | 0 |
| Nightly-only evidence | 0 |
| Test tags | 0 |
| Tagged units | 0 |
| Recorded audit verdicts | 0 |
| Discrimination records | 0 |
| Summary | rfc/short/rfc6482.md |
| Requirement shard | rfc/requirements/rfc6482.md |
| RFC text | rfc/full/rfc6482.txt |
Enrolment
Not enrolled (third-party, a layer under or beside Ze performs the document and Ze holds no Go code for it, so the reason beside this kind names the component that does): The RPKI cache validates the CMS-signed ROA object. Ze consumes an already-validated payload over the RTR protocol, internal/component/bgp/plugins/rpki/rtr_pdu.go.
What the public ledger says
No row in the public ledger, so its summary declares `| Support | - |` and docs/features/rfc-status.md carries no row for RFC 6482.
Coverage
| Bucket | Count | What it counts |
|---|---|---|
| Positive and negative tests | 0 | one part of the gated population |
| Annotated (including scoped evidence) | 9 | one part of the gated population |
| One polarity only | 0 | one part of the gated population |
| No test and no annotation | 0 | one part of the gated population |
| Partial proof; remaining gap (subset of annotated; zero whole-requirement credit) | 0 | an overlay: each of these is also counted by the part it falls in |
| Evidence that runs nightly only | 0 | an overlay: each of these is also counted by the part it falls in |
| Derived from other rows | 0 | outside the gated population: each asserts nothing and derives its state from the rows it names, which the parts above already count |
| Gated MUST-level requirements | 9 | every gated MUST falls in exactly one bucket above |
Annotated (including scoped evidence) (9): RFC6482-3.1-1, RFC6482-2-1, RFC6482-3.3-1, RFC6482-3.3-2, RFC6482-4-1, RFC6482-4-2, RFC6482-4-3, RFC6482-5-1, RFC6482-5-2
Requirements
| Requirement | Level | Section | Tests |
|---|---|---|---|
RFC6482-3.1-1 | The version number of the RouteOriginAttestation MUST be 0. (Section 3.1) | ||
| MUST | 3.1 | positive
no testno positive testnegative
no testno negative test{not-applicable}: ze is neither a ROA producer nor a relying-party validator; it consumes Validated ROA Payloads over the RTR protocol (RFC 8210; internal/component/bgp/plugins/rpki/rtr_pdu.go parsePrefixPDU builds VRPs) and never parses or constructs the RFC 6482 CMS-signed ROA object, so it never inspects the ROA object's version field |
|
RFC6482-2-1 | This OID MUST appear both within the eContentType in the encapContentInfo object as well as the content-type signed attribute in the signerInfo object (see [RFC6488]). (Section 2) | ||
| MUST | 2 | positive
no testno positive testnegative
no testno negative test{not-applicable}: ze is neither a ROA producer nor a relying-party validator; it consumes Validated ROA Payloads over the RTR protocol (RFC 8210; internal/component/bgp/plugins/rpki/rtr_pdu.go parsePrefixPDU builds VRPs) and never parses or constructs the RFC 6482 CMS-signed ROA object; there is no CMS/ASN.1 ROA decode in the RPKI path, so no eContentType/content-type OID is ever checked |
|
RFC6482-3.3-1 | This specification only supports IPv4 and IPv6. Therefore, addressFamily MUST be either 0001 or 0002. (Section 3.3) | ||
| MUST | 3.3 | positive
no testno positive testnegative
no testno negative test{not-applicable}: ze is neither a ROA producer nor a relying-party validator; it consumes Validated ROA Payloads over the RTR protocol (RFC 8210; internal/component/bgp/plugins/rpki/rtr_pdu.go parsePrefixPDU builds VRPs) and never parses or constructs the RFC 6482 CMS-signed ROA object; ze receives per-address-family RTR Prefix PDUs (IPv4 Type 4 / IPv6 Type 6), not ROA ipAddrBlocks with an addressFamily field |
|
RFC6482-3.3-2 | If present, the maxLength MUST be an integer greater than or equal to the length of the accompanying prefix, and less than or equal to the length (in bits) of an IP address in the address family (32 for IPv4 and 128 for IPv6). (Section 3.3) | ||
| MUST | 3.3 | positive
no testno positive testnegative
no testno negative test{not-applicable}: ze is neither a ROA producer nor a relying-party validator; it consumes Validated ROA Payloads over the RTR protocol (RFC 8210; internal/component/bgp/plugins/rpki/rtr_pdu.go parsePrefixPDU builds VRPs) and never parses or constructs the RFC 6482 CMS-signed ROA object; the equivalent maxLength sanity (maxLen within prefixLen..AF-max) is enforced on the RTR PDU wire format per RFC 8210 at internal/component/bgp/plugins/rpki/rtr_pdu.go:125, not on a ROA object |
|
RFC6482-4-1 | Before a relying party can use a ROA to validate a routing announcement, the relying party MUST first validate the ROA. (Section 4) | ||
| MUST | 4 | positive
no testno positive testnegative
no testno negative test{not-applicable}: ze is neither a ROA producer nor a relying-party validator; it consumes Validated ROA Payloads over the RTR protocol (RFC 8210; internal/component/bgp/plugins/rpki/rtr_pdu.go parsePrefixPDU builds VRPs) and never parses or constructs the RFC 6482 CMS-signed ROA object; validating the ROA before use is a relying-party duty performed by the RPKI cache, and ze consumes only the already-validated VRPs |
|
RFC6482-4-2 | To validate a ROA, the relying party MUST perform all the validation checks specified in [RFC6488] as well as the following additional ROA-specific validation step. (Section 4) | ||
| MUST | 4 | positive
no testno positive testnegative
no testno negative test{not-applicable}: ze is neither a ROA producer nor a relying-party validator; it consumes Validated ROA Payloads over the RTR protocol (RFC 8210; internal/component/bgp/plugins/rpki/rtr_pdu.go parsePrefixPDU builds VRPs) and never parses or constructs the RFC 6482 CMS-signed ROA object; the RFC 6488 and ROA-specific validation checks are performed by the relying-party cache, not by ze |
|
RFC6482-4-3 | To validate a ROA, the relying party MUST perform all the validation checks specified in [RFC6488] as well as the following additional ROA-specific validation step. o The IP address delegation extension [RFC3779] is present in the end-entity (EE) certificate (contained within the ROA), and each IP address prefix(es) in the ROA is contained within the set of IP addresses specified by the EE certificate's IP address delegation extension. (Section 4) | ||
| MUST | 4 | positive
no testno positive testnegative
no testno negative test{not-applicable}: ze is neither a ROA producer nor a relying-party validator; it consumes Validated ROA Payloads over the RTR protocol (RFC 8210; internal/component/bgp/plugins/rpki/rtr_pdu.go parsePrefixPDU builds VRPs) and never parses or constructs the RFC 6482 CMS-signed ROA object; checking each prefix against the EE certificate's IP delegation extension requires the ROA CMS and EE certificate that ze never handles |
|
RFC6482-5-1 | Thus, the integrity of a ROA MUST be established. (Section 5) | ||
| MUST | 5 | positive
no testno positive testnegative
no testno negative test{not-applicable}: ze is neither a ROA producer nor a relying-party validator; it consumes Validated ROA Payloads over the RTR protocol (RFC 8210; internal/component/bgp/plugins/rpki/rtr_pdu.go parsePrefixPDU builds VRPs) and never parses or constructs the RFC 6482 CMS-signed ROA object; establishing ROA integrity is a relying-party/cache responsibility |
|
RFC6482-5-2 | Specifically, one MUST verify the signature on the ROA using an X.509 certificate issued under this PKI, and check that the prefix(es) in the ROA match those in the certificate's address space extension. (Section 5) | ||
| MUST | 5 | positive
no testno positive testnegative
no testno negative test{not-applicable}: ze is neither a ROA producer nor a relying-party validator; it consumes Validated ROA Payloads over the RTR protocol (RFC 8210; internal/component/bgp/plugins/rpki/rtr_pdu.go parsePrefixPDU builds VRPs) and never parses or constructs the RFC 6482 CMS-signed ROA object; verifying the ROA's X.509 signature and address-space match is a relying-party/cache responsibility ze does not perform |
|
RFC6482-3.3-3 | Additionally, a ROA MAY contain two ROAIPAddress elements, where the IP address prefix is identical in both cases. However, this is NOT RECOMMENDED as, in such a case, the ROAIPAddress with the shorter maxLength grants no additional privileges to the indicated AS and thus can be omitted without changing the meaning of the ROA. (Section 3.3) | ||
| NOT RECOMMENDED | 3.3 | positive
no testno positive testnegative
no testno negative test |
|
Gaps and untested MUSTs
| Requirement | State | Reason |
|---|---|---|
RFC6482-3.1-1 The version number of the RouteOriginAttestation MUST be 0. (Section 3.1) |
no test | no test carries this requirement id; annotated {not-applicable}: ze is neither a ROA producer nor a relying-party validator; it consumes Validated ROA Payloads over the RTR protocol (RFC 8210; internal/component/bgp/plugins/rpki/rtr_pdu.go parsePrefixPDU builds VRPs) and never parses or constructs the RFC 6482 CMS-signed ROA object, so it never inspects the ROA object's version field |
RFC6482-2-1 This OID MUST appear both within the eContentType in the encapContentInfo object as well as the content-type signed attribute in the signerInfo object (see [RFC6488]). (Section 2) |
no test | no test carries this requirement id; annotated {not-applicable}: ze is neither a ROA producer nor a relying-party validator; it consumes Validated ROA Payloads over the RTR protocol (RFC 8210; internal/component/bgp/plugins/rpki/rtr_pdu.go parsePrefixPDU builds VRPs) and never parses or constructs the RFC 6482 CMS-signed ROA object; there is no CMS/ASN.1 ROA decode in the RPKI path, so no eContentType/content-type OID is ever checked |
RFC6482-3.3-1 This specification only supports IPv4 and IPv6. Therefore, addressFamily MUST be either 0001 or 0002. (Section 3.3) |
no test | no test carries this requirement id; annotated {not-applicable}: ze is neither a ROA producer nor a relying-party validator; it consumes Validated ROA Payloads over the RTR protocol (RFC 8210; internal/component/bgp/plugins/rpki/rtr_pdu.go parsePrefixPDU builds VRPs) and never parses or constructs the RFC 6482 CMS-signed ROA object; ze receives per-address-family RTR Prefix PDUs (IPv4 Type 4 / IPv6 Type 6), not ROA ipAddrBlocks with an addressFamily field |
RFC6482-3.3-2 If present, the maxLength MUST be an integer greater than or equal to the length of the accompanying prefix, and less than or equal to the length (in bits) of an IP address in the address family (32 for IPv4 and 128 for IPv6). (Section 3.3) |
no test | no test carries this requirement id; annotated {not-applicable}: ze is neither a ROA producer nor a relying-party validator; it consumes Validated ROA Payloads over the RTR protocol (RFC 8210; internal/component/bgp/plugins/rpki/rtr_pdu.go parsePrefixPDU builds VRPs) and never parses or constructs the RFC 6482 CMS-signed ROA object; the equivalent maxLength sanity (maxLen within prefixLen..AF-max) is enforced on the RTR PDU wire format per RFC 8210 at internal/component/bgp/plugins/rpki/rtr_pdu.go:125, not on a ROA object |
RFC6482-4-1 Before a relying party can use a ROA to validate a routing announcement, the relying party MUST first validate the ROA. (Section 4) |
no test | no test carries this requirement id; annotated {not-applicable}: ze is neither a ROA producer nor a relying-party validator; it consumes Validated ROA Payloads over the RTR protocol (RFC 8210; internal/component/bgp/plugins/rpki/rtr_pdu.go parsePrefixPDU builds VRPs) and never parses or constructs the RFC 6482 CMS-signed ROA object; validating the ROA before use is a relying-party duty performed by the RPKI cache, and ze consumes only the already-validated VRPs |
RFC6482-4-2 To validate a ROA, the relying party MUST perform all the validation checks specified in [RFC6488] as well as the following additional ROA-specific validation step. (Section 4) |
no test | no test carries this requirement id; annotated {not-applicable}: ze is neither a ROA producer nor a relying-party validator; it consumes Validated ROA Payloads over the RTR protocol (RFC 8210; internal/component/bgp/plugins/rpki/rtr_pdu.go parsePrefixPDU builds VRPs) and never parses or constructs the RFC 6482 CMS-signed ROA object; the RFC 6488 and ROA-specific validation checks are performed by the relying-party cache, not by ze |
RFC6482-4-3 To validate a ROA, the relying party MUST perform all the validation checks specified in [RFC6488] as well as the following additional ROA-specific validation step. o The IP address delegation extension [RFC3779] is present in the end-entity (EE) certificate (contained within the ROA), and each IP address prefix(es) in the ROA is contained within the set of IP addresses specified by the EE certificate's IP address delegation extension. (Section 4) |
no test | no test carries this requirement id; annotated {not-applicable}: ze is neither a ROA producer nor a relying-party validator; it consumes Validated ROA Payloads over the RTR protocol (RFC 8210; internal/component/bgp/plugins/rpki/rtr_pdu.go parsePrefixPDU builds VRPs) and never parses or constructs the RFC 6482 CMS-signed ROA object; checking each prefix against the EE certificate's IP delegation extension requires the ROA CMS and EE certificate that ze never handles |
RFC6482-5-1 Thus, the integrity of a ROA MUST be established. (Section 5) |
no test | no test carries this requirement id; annotated {not-applicable}: ze is neither a ROA producer nor a relying-party validator; it consumes Validated ROA Payloads over the RTR protocol (RFC 8210; internal/component/bgp/plugins/rpki/rtr_pdu.go parsePrefixPDU builds VRPs) and never parses or constructs the RFC 6482 CMS-signed ROA object; establishing ROA integrity is a relying-party/cache responsibility |
RFC6482-5-2 Specifically, one MUST verify the signature on the ROA using an X.509 certificate issued under this PKI, and check that the prefix(es) in the ROA match those in the certificate's address space extension. (Section 5) |
no test | no test carries this requirement id; annotated {not-applicable}: ze is neither a ROA producer nor a relying-party validator; it consumes Validated ROA Payloads over the RTR protocol (RFC 8210; internal/component/bgp/plugins/rpki/rtr_pdu.go parsePrefixPDU builds VRPs) and never parses or constructs the RFC 6482 CMS-signed ROA object; verifying the ROA's X.509 signature and address-space match is a relying-party/cache responsibility ze does not perform |
Proof state
A tagged unit reads unproven where no discrimination record exists for it: nothing in this tree has been observed to break it, so the claim its tag makes is unproven.
RFC6482-3.1-1
The version number of the RouteOriginAttestation MUST be 0. (Section 3.1)
Audit verdict: not audited: no reader has judged these tests
No test carries RFC6482-3.1-1, so no unit is bound to it.
RFC6482-2-1
This OID MUST appear both within the eContentType in the encapContentInfo object as well as the content-type signed attribute in the signerInfo object (see [RFC6488]). (Section 2)
Audit verdict: not audited: no reader has judged these tests
No test carries RFC6482-2-1, so no unit is bound to it.
RFC6482-3.3-1
This specification only supports IPv4 and IPv6. Therefore, addressFamily MUST be either 0001 or 0002. (Section 3.3)
Audit verdict: not audited: no reader has judged these tests
No test carries RFC6482-3.3-1, so no unit is bound to it.
RFC6482-3.3-2
If present, the maxLength MUST be an integer greater than or equal to the length of the accompanying prefix, and less than or equal to the length (in bits) of an IP address in the address family (32 for IPv4 and 128 for IPv6). (Section 3.3)
Audit verdict: not audited: no reader has judged these tests
No test carries RFC6482-3.3-2, so no unit is bound to it.
RFC6482-4-1
Before a relying party can use a ROA to validate a routing announcement, the relying party MUST first validate the ROA. (Section 4)
Audit verdict: not audited: no reader has judged these tests
No test carries RFC6482-4-1, so no unit is bound to it.
RFC6482-4-2
To validate a ROA, the relying party MUST perform all the validation checks specified in [RFC6488] as well as the following additional ROA-specific validation step. (Section 4)
Audit verdict: not audited: no reader has judged these tests
No test carries RFC6482-4-2, so no unit is bound to it.
RFC6482-4-3
To validate a ROA, the relying party MUST perform all the validation checks specified in [RFC6488] as well as the following additional ROA-specific validation step. o The IP address delegation extension [RFC3779] is present in the end-entity (EE) certificate (contained within the ROA), and each IP address prefix(es) in the ROA is contained within the set of IP addresses specified by the EE certificate's IP address delegation extension. (Section 4)
Audit verdict: not audited: no reader has judged these tests
No test carries RFC6482-4-3, so no unit is bound to it.
RFC6482-5-1
Thus, the integrity of a ROA MUST be established. (Section 5)
Audit verdict: not audited: no reader has judged these tests
No test carries RFC6482-5-1, so no unit is bound to it.
RFC6482-5-2
Specifically, one MUST verify the signature on the ROA using an X.509 certificate issued under this PKI, and check that the prefix(es) in the ROA match those in the certificate's address space extension. (Section 5)
Audit verdict: not audited: no reader has judged these tests
No test carries RFC6482-5-2, so no unit is bound to it.
Extraction sign-off
| Field | Value |
|---|---|
| Reviewer | claude |
| Signed off | 2026-09-27 |
| Register | prose |
| Source | rfc/full/rfc6482.txt |
| Source fingerprint | 035b0b690b67aecd |
| Record | rfc/extraction/rfc6482.json |
| Mapped sentences | 8 |
| Declined as scope | 2 |
| Relocated to a spec, which Ze OWES | 0 |
| Unclassified | 0 |
Sections
| Section | Name | Sites | Disposition | Reason |
|---|---|---|---|---|
front |
not stated | 1 | walked | not stated |
1 |
not stated | 1 | walked | not stated |
1.1 |
not stated | 0 | walked | not stated |
2 |
not stated | 1 | walked | not stated |
3 |
not stated | 0 | walked | not stated |
3.1 |
not stated | 1 | walked | not stated |
3.2 |
not stated | 0 | walked | not stated |
3.3 |
not stated | 2 | walked | not stated |
4 |
not stated | 2 | walked | not stated |
5 |
not stated | 2 | walked | not stated |
6 |
not stated | 0 | walked | not stated |
7 |
not stated | 0 | walked | not stated |
8 |
not stated | 0 | walked | not stated |
8.1 |
not stated | 0 | walked | not stated |
8.2 |
not stated | 0 | walked | not stated |
A |
Appendix A | 0 | walked | Appendix A. Until 2026-09-27 the heading reader did not read this appendix's heading, so its text was read as part of the section before it. It carries no site, so no decision moved. |
Excluded sentences
| Site | Excluded kind | Reason | Quote |
|---|---|---|---|
front:1 |
not-a-requirementnever bound Ze the sentence states a fact or describes another document, and directs no implementation |
IETF Trust Legal Provisions boilerplate on the status page. The lowercase 'must include Simplified BSD License text' governs reuse of the document's code components, not ROA behaviour. | Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. |
1:1 |
not-a-requirementnever bound Ze the sentence states a fact or describes another document, and directs no implementation |
Item 3 of the Introduction's list of what this document specifies. It describes the document's own contents; the obligation itself is Section 4's 'the relying party MUST perform all the validation checks specified in [RFC6488] as well as the following additional ROA-specific validation step', which site 4:2 maps. | An additional step required to validate ROAs (in addition to the validation steps specified in [RFC6488]). |
Superseded
No document obsoletes RFC 6482, so its obligations are stated where they were written.