A Profile for Resource Public Key Infrastructure (RPKI) Canonical Cache Representation (CCR)
draft-ietf-sidrops-rpki-ccr-11

Thanks to Joe S. for the SECDIR review.

Thanks for the well written draft.

My only comment is to second Deb's comment about SHA-1.  It is being used as a hash, but you can create collisions in it - what would happen if someone engineered the rpki certificates to cause a hash collision?

I would appreciate consideration, most of these can be resolved pretty easily. 

Thanks to Joe Salowey for their secdir review. I agree with Joe's assessment: 

 - The continued use of SHA-1 (Section 3.4.1.1 Subordinates and Section 3.4.4): At some point, a migration will have to happen, because at some point implementations won't have SHA-1 implemented.  If it doesn't make sense to fix this issue in this draft, I recommend that the risks be mentioned in Section 6.

 - Privacy/sensitive information:  The ramifications of the information not being public should be explained in Section 6 where it is mentioned in the last para.

Section 5.1:  Verifying a hash value that isn't signed isn't actually an integrity check, except in the case of unintentional integrity issues.  Certainly an attacker can modify both the original data and the hash.  Please clarify what type of integrity is required/intended.

Section 6, last para:  I'm not sure how the fact that CCRs are not signed is related to whether the RPKI information is public (or not).  Perhaps two paragraphs are needed?  Move the middle sentence out into its own paragraph (since it has nothing to do with signatures or authenticity.

Thanks for the work done, clear cut draft with the correct use of BCP14 terms per https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

Hi Authors, WG,

# Gunter Van de Velde, RTG AD, comments for draft-ietf-sidrops-rpki-ccr-08

# line numbers are rendered from the idnits tool found at https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-sidrops-rpki-ccr-08.txt

# Potential Missing References
Would these references improve the document?
RFC 8897 (Requirements for RPKI Relying Parties): CCR is fundamentally a validated-cache export format. A citation to RP requirements could provide useful context for implementers regarding cache behavior and validation assumptions.
RFC 9323 (RPKI Signed Checklists): The document conceptually resembles a compact signed representation of validated state. While not required, a brief informative comparison may help readers understand why CCR exists and how it differs from RSCs.

# Section 1 Introduction: The introduction states CCR represents the state of a validated cache at a point in time.
Question "Is the representation intended to be deterministic across implementations given identical validated inputs?"
The term "Canonical" strongly implies byte-for-byte reproducibility. If this is a design goal, I recommend stating it explicitly.
If deterministic output is not guaranteed, the introduction should clarify what properties are canonical.

# Section 2 (CCR Structure): Would the document benefit from a stronger statement regarding ordering rules?
Questions: Are all contained elements required to be sorted? If so, what exact sort order is required?,  Is DER alone sufficient to guarantee canonical representation, or are additional ordering constraints required?
DER canonicalizes encoding but not necessarily semantic ordering of collections.

Kind Regards,
Gunter Van de Velde
Routing Area Director

Thanks to the authors and the WG for their work on this document.

I have a few comments, questions, and suggestions for consideration by the authors and the WG:

1) Section 3: Is the hard lower limit size of 1000 fully thought out ... for today, tomorrow (e.g., something changes to reduce/compress?)

ManifestInstance ::= SEQUENCE {
  hash              Digest,
  size              INTEGER (1000..MAX), <<<< this one!
  aki               KeyIdentifier,
  manifestNumber    INTEGER (0..MAX),
  thisUpdate        GeneralizedTime,
  locations         SEQUENCE (SIZE(1..MAX)) OF AccessDescription,
  subordinates      SEQUENCE (SIZE(1..MAX)) OF SubjectKeyIdentifier
                      OPTIONAL }

2) Section 3 - not an expert on ASN.1 nor this particular feature/technology ... but CertificateSerialNumber FROM PKIX1Explicit-2009 is unused. Please cross-check if there hasn't been an error or remove unused.

3) section 3.1

"In this version of the specification, it MUST be 0." seems a bit odd.

Perhaps: Version MUST be set to 0 for the CCR content specified in this document.

4) section 5.3 ... a nit

"CCRs compress very well due to its data layout characteristics"

Perhaps: "CCRs compress very well due to their data layout characteristics" or "A CCR file compresses very well due to its data layout characteristics"

Section 8.1, Normative References, [I-D.ietf-sidrops-aspa-profile] entry:

659 >    [I-D.ietf-sidrops-aspa-profile]
660 >               Snijders, J., Azimov, A., Uskov, E., Bush, R., Housley,
661 >               R., and B. Maddison, "A Profile for Autonomous System
662 >               Provider Authorization", Work in Progress, Internet-Draft,
663 >               draft-ietf-sidrops-aspa-profile-26, 19 April 2026,
664 >               <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
665 >               aspa-profile-26>.

I note for awareness that draft-ietf-sidrops-aspa-profile is a normative
reference that, as of the telechat date, remains a WG document in "I-D
Exists" state: it has not been submitted to the IESG and is not in the RFC
Editor queue. I imagine it will sit in MISREF in the RFC Editor queue.

----------------------------------------------------------------------
NIT
----------------------------------------------------------------------

All comments below are about very minor potential issues that you may
choose to address in some way - or ignore - as you see fit. Some were
flagged by automated tools (via
https://github.com/larseggert/ietf-reviewtool), so there will likely
be some false positives. There is no need to let me know what you did
with these suggestions.

Section 6, Security Considerations, contextual bounds example:

528 >    stop further processing on failure.  For example, the maxLength
529 >    element in a ROAIPAddress cannot contain an integer smaller than the
530 >    length of the accompanying prefix, the manifestNumber field is cannot
531 >    be longer than 20 octets, etc.

s/the manifestNumber field is cannot/the manifestNumber field cannot/

---

Appendix A, Acknowledgements:

800 >    The authors wish to thank Russ Housley, Luuk Hendriks, Fedor Vompe,
801 >    Tom Harrison, Changwang Lin, Luigi Iannone, Luuk Hendriks, Mohamed
802 >    Boucadair, Deb Cooley, and Gunter van de Velde for their generous
803 >    feedback on this specification.

Luuk Hendriks appears twice (lines 800 and 801). Twice the credit :-)

Thank you to Behcet Sarikaya for the GENART review.