On Jul 24, 2014, at 11:30 AM, Sandra Murphy <[email protected]> wrote: > On Jul 24, 2014, at 10:37 AM, Russ Housley <[email protected]> wrote: > …
>> RFC 3779 has been implemented. For example, OpenSSL implements RFC 3779, >> and others make use of this certificate handling software. We are not >> talking about a little tweak to such a library. Implementation would >> require a path validation parameter to pass the content of the ROA. > > Not sure that's the case. I think all RPKI recipients now need to do a > computation of which of a cert's resources are valid, which are not. The > *recipients* decide what the certificate says. This will impact > interpretation of a ROA but I don't think it requires something that has to > get passed around with the ROA. Okay, let me elaborate a bit on how we do this.. We don't use openssl for this. We have our own implementation and the way we do this is fully top-down. We don't pass the content of the ROA we are interested in around at all. We just keep track of the resources we *accept* at each stage in the top-down validation. We then insist (as know) that the ROA EE certificate has the resources (we accepted) for all the prefixes mentioned on it, and if not we reject it. Resource certificates can already have the inherit flag in RFC3779. In such cases we already implicitly copy the parent resources, rather than reading them from the certificate itself. So we are already keeping a set of validated resources for each step in the chain in the context of a top-down validation. The change is that rather than rejecting an over-claiming cert and everything below, we will only accept the intersection of resources mentioned on an otherwise valid child certificate and its parent certificate. And this is applied recursively down the chain. In other words: we don't necessarily believe what the certificate says, but we always evaluate this in the context of a top-down walk. The main idea here is that these certificates do nothing more than tying a set of validated resources to validated keys. Whether over-claiming actually is a problem is only relevant when we look at other statements about these resources, such as ROAs, router certificates etc. If they refer to a resource that was over-claimed, they are rejected. As mentioned before this change was actually trivial to implement for us as a beta feature. Tim _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
