On 09 Aug 2014, at 04:42, Randy Bush <[email protected]> wrote: >>>> The question was about why, in this effort, we are using 3779 >>>> validation rules >>> because we understand how they work formally from considerable >>> experience with PKIs. they are deployed and working today. >> Well ok. Where else are the 3779 rules used? > > the validation for 3779 is essentially the same as for X.509, a rigid > hierarchy.
Personally I am not challenging this general approach. The *one* thing I (and I believe we..) challenge is whether the an overclaimed resource should invalidate a complete certificate, instead of invalidating just the resources at hand, but allowing the remainder. >>> the wg is considering an other validation process. it is still a bit >>> wobbly, and the need for it is poorly motivated. if you remember, i >>> advocated looking at this as a work item, and came up with the one >>> rather subtle motivation for it. >> I’m not seeing the relevance of this history lesson to the question >> that was asked. How does this relate to the technical reasons of why >> we are using 3779 rules? > > because they are working. you are proposing a change to a deployed > rfc. what is the motivation for the change? be technically explicit. Resource certificates are always evaluated in context. Under RFC3779 we accept the resources listed for the trust anchor as-is, but for everything down the chain we insist that *everything* is also held by the parent. I.e. we know exactly which resources we are willing to accept. So we do not believe the listed resources at face value. I understand that conceptually this is an attractive simple model. However I believe that are reasons why certificates can end up overclaiming, and *importantly* this is not always something that a CA has full control over. Essentially I see two causes, that can be caused by various reasons: 1 = the parent certificate is shrunk and published before the, now overclaiming, certificate is shrunk and re-published 2 = the certificate is grown and republished, before the grown parent certificate is republished, so it looks overclaiming Some possible causes, there may be more: The following two we may be able to mitigate technically, because we are dealing with co-operating parties: @1 There is a mis-timing in certificate shrinking in a transfer between co-operating parties. @2 There is a mis-timing in the parent publishing a cert with extended resource, and issuing it to the child, and the child using those resources in turn. But this is the one that has me scared. It is not the issuing CA being sloppy, it’s a problem between them and *their* parent: @1 The *grand*-parent shrinks the *parent* certificate without the parent knowing about this, and some of these resources appear on the, now overclaiming, child certificate. The grand-parent and parent are not involved in an active transfer process. They may not agree that the resource in question should be removed, or the grand-parent may have shrunk these resources in error. By rejecting the overclaiming child certificate completely I think we are being too harsh, or pedantic even. We know better, so we are just not going to trust this one. But.. there is a very real possibility that we actually *do* know better than the issuing CA at this point. So, what exactly is the problem with accepting the remaining resources? i.e. the intersection between the parent certificate’s resources and this certificate. We know the context, this evaluation is very easy and well-defined. If the CA really intended that the remaining resources should not be tied to the certificate, they would have revoked. If the grand-parent really intended that those resources should not be certified anymore, they would have removed them as well. > the point of the history lesson of the rirs blocking the definition and > documentation of transfer is that it seems to be the only serious reason > for the change those very same rirs are proposing. so, if you want your > proposal to change rfced running code to be taken seriously, you had > best document it technically, not just throw perjoratives and hyperbole. I think a formal specification for transfers can mitigate the problem of transfers between co-operative CAs, but this can not mitigate errors. But, more importantly our transfer policies are set in the address policy working group, and our implementation is based on the directives that we get from our community there. Other RIRs have similar, but slightly different policies. The ‘rules’ regarding these transfers can be changed at any time. As an RIR employee I feel a lot of reluctance against engaging in a technical definition of a transfer, as it can be perceived to compete with our community process. > i just want clear and well-understood technical reasons for a > change to deployed running documented code that seems to be working. I hope that the third case above (CA unaware that its own certificate has shrunk) made my motivations more clear. I understand that changing running code is a pain, but I don’t think it’s impossible. We have running code that warns about overclaiming, but accepts remaining. Tim _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
