I have read and reviewed this document. The problem described is one that concerns me greatly as the operator of a near-apex CA and repository. While all due care is taken to ensure correctness of action, good engineering practice is to identify risks through frequency and impact and take steps to mitigate those risks. In this case, the frequency is low but the current impact is extremely high. With solutions to mitigate the impact at hand, it seems straightforward to me that those solutions should be pursued: removing the occurrence of events of this nature altogether is impractical.
Regarding the content of the document, the last paragraph of section 2 offers a very clear description of the problem: a technical choice, not driven by any system requirements, is imposing a significant consequence on operations. Section 3 covers scenarios related to movement of resources between CAs, but does not consider the additional impact of cache refresh cycles. Each CA in a chain must wait until it is confident that all clients have refreshed, which introduces at least 24 hours delay at each tier in the hierarchy. This cascade of delays up and down the hierarchy, plus coordination lag across timezones, is likely to extend the time it takes to move resources within the RPKI by days at best. Perhaps the document should make some reference to this issue? And one minor typo at the top of page 4 with the resources listed as ".../24/24". Fortunately this typo doesn't invalidate the rest of the document :-) Byron On 2/07/2014 11:27 am, "[email protected]" <[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 : RPKI Validation Reconsidered > Authors : Geoff Huston > George Michaelson > Carlos M. Martinez > Tim Bruijnzeels > Andrew Lee Newton > Alain Aina > Filename : draft-ietf-sidr-rpki-validation-reconsidered-00.txt > Pages : 10 > Date : 2014-07-01 > >Abstract: > This document reviews the certificate validation procedure specified > in RFC6487 and highlights aspects of potentially acute operational > fragility in the management of certificates in the RPKI in response > to the movement of resources across registries, and the associated > actions of Certification Authorities to maintain continuity of > validation of certification of resources during this movement. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconside >red/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-sidr-rpki-validation-reconsidered-00 > > >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/ > >_______________________________________________ >sidr mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
