Yes, I know I'm an author, but I'm going to review this anyway.
Section 3.2.3: "The serial attribute must be an unbounded, unsigned positive integer indicating the current version of the repository." On the relying party side, unbounded integers make me a bit nervous. If the serial number is terabytes long, I'd really prefer to reject the entire file. Can we instead restrict the serial attribute to fit in a 64-bit unsigned integer? Changing sessions once every 2^64-1 serials doesn't seem like a significant burden.
(nit) Section 3.2.4 uses the term "version" when I think it means "serial".
In section 3.2.5, "A new delta file MUST be generated", but "The [notification] file SHOULD also include available delta files for this and previous updates". Is there any point to generating a delta file and not listing it in the notification file? I'd recommend changing both to MUST or both to SHOULD.
Section 3.4.3: "Including the hashes in this manner allows relying parties to identify specific objects by their hash rather than the URI where they are found." If some RPs use just the URI and some use just the hash, it might be possible for a cooperating CA and repository to cause the two types of RP to see two completely different views of the RPKI. A paranoid RP could check both the hashes and the URIs to make sure that never happens, but that defeats the purpose of having both identifiers. Is the flexibility here worth the potential risk?
-- David Eric Mandelberg / dseomn http://david.mandelberg.org/ _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
