aol ignas < rant >
sorry, i may be misusing "CA." an op's server (a Certificate Authority) holds one or more certificates; at least one per parent for which it has subsidiary objects. [ CA != cert ] i do not use the term 'operator' because an operator could have multiple whole CA set-ups. ] each certificate has a publication point (a directory?). in theory, each cert in a multi-cert CA _could_ use a separate publication service, but i am not aware of any CA software which has ever supported this. one publication service can host multiple publication points for the multiple certs of that CA and for multiple CAs. and, when an 8183 request arrives at a publication server, it would be able to accept the request only if the requester was a descendent of the favorite (e.g. parent) CA of the publisher, or payes them a lot of zlotys, or whatever. the problem is that wanting to separate them all to have some kind of publication racial purity is inappropriate because, unlike IRR, RPKI subtrees are all supposed to be equally rigorous. unlike the IRR (where it all sucks), the NCC's subtree is no better than ARIN's or LACNIC's. my worry is that complicating the CA and publication software to maintain racial purity in publication will encourage an already broken ecosystem to be even more fragile and more vulnerable. there are a bunch of folk measuring the ecosystem and the software components, and it is horrifying. nothing is rigorously 100% correct. i do not want to encourage CA components to make it even worse, or the NCC to make their publication service even more brittle by asking it to detect racial impurities that don't make a damned bit of difference. randy -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/routing-wg
