Dear Christer, Many thanks for your review! Jump to bottom of this email for a link to a proposed changeset to address your feedback.
> Major issues: > > Q_MA_1: Is it explained why a shorter validity period is preferred in the > tiebreaking scheme? The Introduction does talk about "unreasonably long > validity periods", but that is not a generic explanation. I think this should > be explained, both in the Introduction and in the the normative text in > Section > 2. Unfortunately there are still some trust anchor certificate issuances in circulation with a 100 year validity period. I do not expect those to expire during my lifetime (but one can hope!). Having the tiebreaker scheme prefer shorter-lived validity periods prevents a form of deadlocking if these long-lived issuances are encountered. I'm not sure how I'd change the document to capture this in more detail. Do you have a specific suggestion? > Q_MA_2: The Introduction says that the 'more recently' issued TA certificate > is > preferred. But, Section 2 talks about using the "more recent notBefore". Those > are 2 different things. Introduction explains the overall goal, Section 2 describes the various process steps to achieve the goal. I'm not sure I see an issue? Can you elaborate? > Minor issues: > > N/A > > Nits/editorial comments: > > Q_ED_1: The document talks about "objects" and "certificates". What is the > difference? Unless there is a reason for using both, please be consistent. The wording was choosen to remain aligned with the wording choices of RFC 8630. Perhaps the authors of that 8630 document wished to differentiate between 'a not-yet-validated binary blob' and 'ah, the binary blob turned out to be a validly self-signed certificate'. I.e., at process step 1 "Retrieve the object referenced by (one of) the TA URI(s) contained in the TAL." it will not yet known to the RP what the content of the object is. I've changed some instances to 'object' to 'certificate' aligning with the logical steps in the validation process. Let me know it works better now! > Q_ED_2: The document talks about "locally cached copy" and "cached copy". > Please be consistent. Thanks! Changed. > Q_ED_3: The document talks about "retrieved object" and "retrieved TA". Unless > there is a reason for using both, please be consistent. I've refined this. How does https://github.com/job/draft-sidrops-rpki-ta-tiebreaker/commit/0fd3874963afea52e15a73c07df4f7de040cc32a look to you? Kind regards, Job _______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
