Dear Job, Thank You for commenting on my issues. Please see inline.
> 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? As far as I know, the preference of shorter validity period is due to a number of security-related issues: stolen keys, new algorithms etc. This may be obvious to the experts, but I think a couple of sentences about that in the Introduction would be useful. > > 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? The date when a certificate is issued, and the earliest day when it can be used (notBefore) are 2 separate things. There is no guarantee that the "more recent notBefore" is the most recently issued certificate. Also, the data of issue/notBefore alone do not define the validity or the certificate, does it? Shouldn’t you FIRST compare the validity period? Then, if equal, you check the notBefore? > > 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! Alignment with RFC 8630 is a fair argument, as the text is updating the RFC :) > > 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. > com%2Fjob%2Fdraft-sidrops-rpki-ta- > tiebreaker%2Fcommit%2F0fd3874963afea52e15a73c07df4f7de040cc32a&dat > a=05%7C02%7Cchrister.holmberg%40ericsson.com%7C4a468080829f45e34a2 > f08debb418328%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C6391 > 54087222770346%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRyd > WUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3 > D%3D%7C0%7C%7C%7C&sdata=fUvMUp1u80iax6ZGGM0iFJkL7kiMGpfvrfnVgf > cPXc4%3D&reserved=0 look to you? The editorial modifications seem fine, but please address my replies on the major issues :) Thanks! Regards, Christer _______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
