[Gen-art] Re: draft-ietf-sidrops-rpki-ta-tiebreaker-04 ietf last call Genart review

[Christer Holmberg <[e-mail]>]

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