RFC Errata
Found 4 records.
Status: Verified (3)
RFC 6482, "A Profile for Route Origin Authorizations (ROAs)", February 2012
Source of RFC: sidr (rtg)
Errata ID: 3166
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Andrew Chi
Date Reported: 2012-03-25
Verifier Name: Stewart Bryant
Date Verified: 2012-10-26
Section 4 says:
...EE certificate's IP address delegation extension.
It should say:
...EE certificate's IP address delegation extension. The EE certificate MUST NOT use "inherit" elements as described in [RFC3779].
Notes:
Having spoken to the authors, the authors' intent was to disallow "inherit" in ROA EE certificates in order to simplify validation of ROAs. Implementers agree, and as of March 2012, the three public validator implementations already enforce this.
This erratum simply states it explicitly, whereas the original text might be misread as leaving room for indirectly-specified resources via "inherit".
This errata was discussed by the WG, please see SIDR list archive.
Errata ID: 5881
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-10-23
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2019-10-24
Section Appendix A says:
END
It should say:
id-ct-routeOriginAuthz OBJECT IDENTIFIER ::= { 1 2 840 113549 1 9 16 1 24 }
END
Notes:
The object identifier for the ROA content type is mentioned in the document, but it is not included in the ASN.1 Module.
Errata ID: 5609
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: John Kristoff
Date Reported: 2019-01-20
Verifier Name: RFC Editor
Date Verified: 2019-01-22
Section Table of Contents says:
5. Security Considerations .........................................5
6. Acknowledgments .................................................6
7. References ......................................................6
7.1. Normative References .......................................6
7.2. Informative References .....................................6
It should say:
5. Security Considerations .........................................5
6. IANA Considerations .............................................6
7. Acknowledgments .................................................6
8. References ......................................................6
8.1. Normative References .......................................6
8.2. Informative References .....................................6
Notes:
The Table of Contents omits the "IANA Considerations" section, which should be section 6, which consequently causes the numbered sections to be follow be labeled incorrectly.
Status: Rejected (1)
RFC 6482, "A Profile for Route Origin Authorizations (ROAs)", February 2012
Source of RFC: sidr (rtg)
Errata ID: 7079
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Job Snijders
Date Reported: 2022-08-10
Rejected by: John Scudder
Date Rejected: 2022-09-06
Section 4 says:
Before a relying party can use a ROA to validate a routing
announcement, the relying party MUST first validate the ROA. 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.
It should say:
Before a relying party can use a ROA to validate a routing
announcement, the relying party MUST first validate the ROA. 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.
o The AS Resources extension is not used in Route Origin Authorizations
and MUST be omitted.
Notes:
The ROA RFC is a bit under-specified compared to other RPKI Signed Object profile definitions. (For example, RFC 8209 § 3.1.3.4 is less ambiguous on the matter of RFC3779 extensions.)
--VERIFIER NOTES--
This is a material (albeit small) change to the spec and doesn't appear to reflect the WG consensus at time of publication. Therefore rejecting, see https://mailarchive.ietf.org/arch/msg/sidr/A_2jMTLbpgpK1H0G3QsVJ44T-kE/ as well.