Steve, all, On Jul 23, 2014, at 2:30 PM, Stephen Kent <[email protected]> wrote:
> Tim, > >> Hi, >> >> As you may have noticed my name was added to the author list, so it will >> come as no surprise that I read this document and agree with its content. >> >> I believe that all RIRs share both operational concerns outlined in section >> 3: (1) Operational fragility, and (2) resource transfers. One thing to note >> about the second case is that we don't have this problem right now because >> we only offer a hosted service where our members cannot create delegated >> certificates. However, this will change when we enable the provisioning >> (up-down) system and support non-hosted CAs that may delegate further. >> >> Section 4 describes, in very general terms, two alternative approaches to >> counter these concerns. >> >> The first approach has my strong preference. I believe it's simple to >> explain and implement, effective against both concerns, and I do not see any >> security issues with it. The change boils down to this: when doing top-down >> validation, just accept the *intersection* of resources listed on a >> certificate, and its parent. The idea of keeping track of resources >> explicitly is not new: we already have this when using 'inherit'. We have >> running code in our validator for this. It took us a day to implement this. >> The feature is off by default of course, but it's enabled without problems >> on a public instance that we're running: http://localcert.ripe.net:8088/ What I forgot to mention above is that we do issue warnings on over claiming certificates. So this is visible, although so-far we have not seen these warnings in the RIR production repositories. > Since you implemented this capability based on what we all agree is a rough > description of the > intended functionality, can you be very confident that it is "correct"? It's a beta feature for a reason. But I do believe there is value in running code and getting experience with this. That said I think the approach safe. And what we implemented is my, quite specific, understanding of the intended approach. I tried to explain it in brief above, but if this is not clear enough and the WG prefers, I would be happy to provide more formal text for this. > More to the point, we all agree that it is very bad for an RIR or NIR to > issue a cert > that would break the current validation algoroithm. In a prior message I > suggested several > checks that I thought every CA operating should perform to detect and avoid > such errors. > Has RIPE been performing check such as these? Might adoption of relaxed > validation rules > minimize the perceived need to perform such checks, i.e., encourage > sloppiness? It is not my intention, and I believe it's safe to say that it's not the intention of others, to encourage sloppiness, but to minimise impact and improve resiliency if an error does occur. Speaking for our own CA implementation. We have code in place to ensure that we cannot create over-claiming certificates. We also have code to re-issue products as needed when resources are shrunk (e.g. omitting certain ROA prefixes when the resources are no longer held by the CA). However, there are a lot of moving parts here, and no software is without bugs. This problem gets worse when certificates are received from, or issued to third parties. In our current software we manage all CAs in our hierarchy locally, so we *know* when something changes and we can do the above. When dealing with 3rd parties there may be a significant time that parent and child are out of sync about the resources held by the child. >> The second approach in section 4 was presented at the last IETF >> (draft-barnes-sidr-tao). Essentially it allows for transfer signalling >> through an up-down like protocol. Technically this approach can help to deal >> with transfer issues (2). > The cited approach approach is designed expressly to deal with transfer > issues, not with the > more general problem of errors by CAs. One ought not conflate these two > issues. Okay, fair enough. As long as it's clear that this is the scope. >> The 'happy case' scenarios assume though that all involved parties play nice >> - and keep playing nice. There are many moving parts here, and it's not >> clear to me what happens when one party walks away (e.g. goes offline >> permanently). Additionally the timing of certificate shrinking in case of a >> cancel is not clear to me and introduces complexity: live transfer or not?, >> who signals the transfer?, when is it canceled, before or after shrinking >> and/or swinging? Can a cancel be canceled? But, more importantly, this >> approach offers no protection against the operational fragility case (1). >> Furthermore it adds a lot of complexity and this has huge costs in >> development (many months) and maintenance and introduces more operational >> fragility and potential interop issues between implementations. > Since we have NO description of resource transfer at the level of detail > provided in the TAO I-D, it seems a bit premature to describe it as being > more complex than the suggested alternative. Okay, fair enough as well. I will maintain that in my opinion the TAO introduces a lot of complexity (and open questions above), but my belief that it's more complicated than the alternative is based on implicit interpretation and informal discussions about this, and not on a detailed document. > > Steve > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
