Dear Christer,
On Thu, May 28, 2026 at 06:46:19AM +0000, Christer Holmberg wrote:
> > > 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.
> > > 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 editorial modifications seem fine, but please address my replies on the
> major issues :)
Thanks & see above! :)
Kind regards,
Job
_______________________________________________
Gen-art mailing list -- [email protected]
To unsubscribe send an email to [email protected]
