Wes, Randy and I bashed some text around; would this work:
When it is decided that an active router key is to be revoked, the process of requesting the CA to revoke, the process of the CA actually revoking the router’s certificate, and then the process of rekeying/renewing the router’s certificate, (possibly distributing a new key and certificate to the router), and distributing the status takes time during which the operator must decide how they wish to maintain continuity of operations, with or without the compromised private key, or whether they wish to to bring the router offline to address the compromise. Keeping the router operational and BGPsec-speaking is the ideal goal, but if operational practices do not allow this then reconfiguring the router to disabling BGPsec is likely preferred to bringing the router offline. Routers which support more than one private key, where one is operational and the other(s) are soon-to-be-opertional, facilitate revocation events because the operator can configure the router to make a soon-to-be-operational key operational, request revocation of the compromised key, and then make a new soon-to-be-operational key, all hopefully without needing to take offline or reboot the router. For routers which support only one operational key, the operators should create or install the new private key, and then request revocation of the compromised private key. spt On Apr 30, 2014, at 16:26, George, Wes <[email protected]> wrote: > This update address my comments on the document, and I think it’s in good > shape now. The new section 4 is really good. The one thing I might > recommend adding for completeness is a few additional words around > revocation process at the end of section 4, specifically if there is any > difference or recommendation in process for make before break (provision > new key, then revoke old) or when that may not be a good idea compared > with the risk of outage caused by revoking and then rekeying. It may be as > simple as saying something similar to the above about whether a router > supports multiple private keys or not, but I’m not sure if there are > additional considerations that need to be discussed. > > Thanks, > > Wes > > > > On 4/29/14, 10:14 AM, "Sean Turner" <[email protected]> wrote: > >> Hi, >> >> This version includes a new section 4 that addresses key management >> (i.e., keep a timer to make sure your cert doesn’t expire). There’s also >> some editorial/readability corrections. Please review as the authors >> think this version pretty much wraps up what we wanted to say. >> >> spt >> >> On Apr 29, 2014, at 10:10, [email protected] wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Secure Inter-Domain Routing Working >>> Group of the IETF. >>> >>> Title : Router Keying for BGPsec >>> Authors : Sean Turner >>> Keyur Patel >>> Randy Bush >>> Filename : draft-ietf-sidr-rtr-keying-05.txt >>> Pages : 10 >>> Date : 2014-04-29 >>> >>> Abstract: >>> BGPsec-speaking routers are provisioned with private keys to sign BGP >>> messages; the corresponding public keys are published in the global >>> RPKI (Resource Public Key Infrastructure) thereby enabling >>> verification of BGPsec messages. This document describes two ways of >>> provisioning the public-private key-pairs: router-driven and >>> operator-driven. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-05 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rtr-keying-05 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> _______________________________________________ >> sidr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/sidr > > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely for > the use of the individual or entity to which it is addressed. If you are not > the intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the > contents of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify the sender > immediately and permanently delete the original and any copy of this E-mail > and any printout. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
