Daer Job, > > > > 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. > > The introduction states: > > "Periodic reissuance of TA certificates is a way of ensuring that the > RPKI remains healthy at its root by avoiding ossification and > retaining > agility, consequently RPs re-fetch the certificates to adopt changes > in > the TA's INR [RFC3779] and SIA [RFC5280] extensions." > > The tiebreaker algorithm specified in this draft is intended to help avoid > that > RPs fetch a certificate and then stick to that particular issuance for the > next > 100 years. This is what i meant with 'deadlocking' in the previous email. The > preference for shorter validity window is not because of stolen keys or new > algoritms. > > Nowadays the RPKI Trust Anchors use much shorter validity windows, but > some certificate issuances (with the 100 year validity window) are still > valid, > and could be brought back into circulation by a determined attacker or > operational mishap. The tiebreaker algorithm prefering shorter validity > windows helps avoid those ultra long-lived issuances from becoming the > preferred one and in doing so deadlock the RP.
Ok, fair enough. That should be enough :) > > > > 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. > > Agreed. This is why the words 'more recently' are enclosed in quotes in the > draft. The algorithm itself uses the notBefore timestamp and does not rely on > such a guarantee. > > > Also, the data of issue/notBefore alone do not define the validity or > > the certificate, does it? > > The notBefore is one of the parameters that determines the validity of the > certificate: a RPKI Trust Anchor certificate is not valid if the RP's wall > clock is at > a time before the certificate's notBefore. > > > Shouldn’t you FIRST compare the validity period? Then, if equal, you > > check the notBefore? > > Why? The text says: "This document specifies a tiebreaking scheme for RPs, preferring (1) the 'more recently' issued TA certificate, (2) the TA certificate with the shortest validity period among certificates with equal notBefore (Section 4.6.1 of [RFC6487])," Assume you have 2 certificate options: Option A: notBefore/issued one week ago (i.e., most recent). Valid for 10 years (I am using a large value for clarify) Option B: notBefore/issued two weeks ago. Valid for 6 months. Now, if I understand correctly, the tie breaking scheme would choose Option A , as it has a more recent notBefore - even if the validity is much longer than B. Only if the netBefore/issued are identical for A and B would B be chosen, due to shorter validity. Is that the wanted outcome, or have I missunderstood? Regards, Christer _______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
