Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11

Hi,

> On 30 Apr 2015, at 01:18, Randy Bush <randy@psg.com> wrote:
> 
>> 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 <randy@psg.com>
> Subject: Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11
> To: Roque Gagliano <rogaglia@cisco.com>
> Cc: idr wg <idr@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?

For the record in the RIPE NCC software we automagically re-issue CA certificates to members 6 months before they expire (and log errors in case of problems, so we have time to respond). Our system currently only supports non-hosted setups where a member runs their own remote CA in our pilot environment, but there too we pro-actively re-issue.. we don't tell the CA because in the provisioning protocol model the child CA can contact us, but we can't contact them. We do tell them about the new certificate when the CA queries, as they do regularly. We believe that this is safe to do. The new certificate is equivalent in every way to the last requested and issued certificate except that the validity time is longer, so we don't see any scenario where the child would not agree to this - i.e. we can be pro-active.

For hosted member CAs we also re-issue ROAs 6 months before the expire, and we re-issue MFTs 16 hours before their 'next update time' and 6 days and 16 hours before their EE certificate expiration.

> 
> randy
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr