On 29 Apr 2015, at 23:47, Sriram, Kotikalapudi <[email protected]> wrote:
> The above two BCP steps, if followed, will help prevent "couldn't validate > because of certificate lifetime". Of course, most of the time this would happen correctly. People aren't stupid. But experience with HTTPS has shown that expired certificates can't be prevented 100%, and with routing the results are much more severe than with the web, as the user can't decide to go ahead anyway. The user wouldn't even know what happened. And fixing the problem may not be possible because of the unreachability caused by the problem. > 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.) Ok. So what do you propose? That a path with signatures based on expired certificates remains "valid" for some additional grace period? Then you simply postpone the problem by that period. Or should operators have a way to differentiate between paths that are actually invalid and paths that are merely affected by expired certificates? In that case we are saying the same thing. It might even be useful to have valid / expired-but-otherwise-valid / unknown / invalid rather than valid / unknown / invalid. Or maybe valid-algo1 / valid-algo2 / expired-but-otherwise-valid / unknown / invalid, so I can prefer paths protected with the strongest hashing algorithm over paths protected with a weaker algorithm and those over paths protected with expired certificates and those over paths not protected by BGPsec. (IMO invalid paths should not be allowed at all.) Iljitsch _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
