> First: > There should be operational BCP recommendation based on the principle of > make-before-break > ( in doc like https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-05 ): > 1. Certificate should be renewed and pre-published in advance of expiry of > the current certificate; > There should be overlapping validity period bridging the two (current and new > certs). > (See https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover-03 and > https://www.ietf.org/proceedings/92/slides/slides-92-sidr-5.pdf ) > 2. The update for the prefix should be re-originated (by origin AS) or > re-propagated (by a transit AS). > Basically, whoever got a new certificate should do this refresh within the > above overlap period. > > The above two BCP steps, if followed, will help prevent "couldn't validate > because of certificate lifetime". > > Second: > The operational BCP can also say: > Allow a certain grace period before you act on the update that became 'Not > Valid' due to cert expiry. > (Earlier Sandy also mentioned this.) > > Your other scenario "validation failed because of a bad signature or bad > certificate chain" is fine. > In this scenario, the update is labeled 'Not Valid' for good reason.
From: Randy Bush <ra...@psg.com> Subject: Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11 To: Roque Gagliano <rogag...@cisco.com> Cc: idr wg <i...@ietf.org>, sidr wg <sidr@ietf.org> Date: Wed, 29 Apr 2015 12:07:02 +0900 ca software should warn the user of upcoming expiration of certs, ee certs, roas, crls, drivers' licenses, ... but what is the user gonna do? they're gonna renew. so maybe renew automagically and tell the user? randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
