I think there is a discussion here that needs to occur. I'm not convinced that this document is the complete embodiment of that which should be adopted or it's the sole answer to the problem space.
However I do share the concerns that in the growing complexity of RPKI certificate structures any incorrect construction of the 3779 extensions affects all subordinate certificates, even if some other lineage of INRs in that certificate chain is pristine throughout, thus impacting the IN holder's / routing operator's attestations. My reading of this problem statement reaches the conclusion that the impact on a route degrades the security posture (invalid certificate hence invalid ROA) such that the RP's decision should interpreted as 'NotFound' (RFC6907/RFC6811). Clearly a degradation of the security posture isn't ideal, and may cause the litigious parts of the internet community to initiate action (clearly not a desirable thing for any CA operator) as it allows any permutation of routing attacks. But I also wonder if this is a facet of the tight binding of the secure routing operations to the RPKI hierarchy and in the efforts of reaching 'perfect' security attestations we have caused ourselves some disservice in introducing unacceptable[1] levels of operational fragility. [[1] I'm quite sure this is subjective.] Or perhaps (humour me for a minute) x.509 certificates might be the wrong tool to use. When I consider a pure view of an x.509 certificate I view it as "this certificate attests that all of it's contents are 100% correct". For me, changing that position is a slippery slope - I'm not allergic to it but I want the hiking boots on all the same. For me this is then conditional support, if the authors (and the WG) are willing to think of this document as the germination of the discussion (which I believe I saw in George's email), then I will support adoption. Cheers Terry On 26/04/2014 2:05 am, "Sandra Murphy" <sa...@tislabs.com> wrote: >The authors of draft-huston-rpki-validation-01.txt, RPKI Validation >Reconsidered, have requested wg adoption. > >See http://tools.ietf.org/html/draft-huston-rpki-validation-01. > >Please do respond to the list as to whether you support the wg adopting >this as a work item. You do not need to comment on the content of this >draft at this time. You are asked to indicate if you think that this is >work that the wg should be doing and whether this draft is an acceptable >starting point. Adding whether you can/will review or not is useful. > >Note that active support is required for adoption. Silence is a vote >against adoption. > >This adoption call will end on 9 May 2014. > >--Sandy, speaking as wg co-chair >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
