I noticed that an update to draft-ietf-sidr-rpki-validation-reconsidered has been posted. I remain confused.
Section 3 includes these paragraphs: The first is that of the robustness of the operational management procedures in the issuance of certificates. If a subordinate Certification Authority (CA) issues a certificate that contains an Internet Number Resource (INR) collection that is not either exactly equal to, or a strict subset of, its parent CA, then this issued certificate, and all subordinate certificates of this issued certificate are invalid. These certificates are not only defined as invalid when being considered to validate an INR that is not in the parent CA certificate, but are defined as invalid for all INRs in the certificate. This constraint creates a degree of operational fragility in the issuance of certificates, as all CA's are now required to exercise extreme care in the issuance and reissuance of certificates to ensure that at no time do they overclaim on the resources described in the parent CA, as the consequences of an operational lapse or oversight implies that all the subordinate certificates from the point of INR mismatch are invalid. It would be preferred if the consequences of such an operational lapse were limited in scope to the specific INRs that formed the mismatch, rather than including the entire set of INRs within the scope of damage from this point of mismatch downward across the entire sub-tree of descendant certificates in the RPKI certificate hierarchy. I do not understand why it is hard for a CA to not overclaim. I cannot figure out why a CA at any level of the RPKI would ever issue a certificate that includes INRs that are outside its scope. From previous discussions, I understand the desire to add INRs to one certificate before they are removed from another. This seems to mean that the new INRs get added to the receiving CA and subordinate certificates before they are removed from the previous one. Since this seems to work in a straightforward way, I'm just not seeing the motivation for this reconsideration. Russ _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
