Jeff
Steve noted a desire to limit the liability of entities acting as CAs in
the RPKI. I agree that goal is desirable, and restrictions on what
certificates issued by those CAs can contain help to do that (provided
the CAs actually comply). However, requiring compliant RPs to treat all
extensions as critical does _not_ help, because an RP which incorrectly
accepts an over-broad RPKI certificate for some other purpose is
probably not an implementation of this profile and thus not bound by the
restriction.
My comments also noted that part of the strategy to limit the utility of
resource certs in other contexts is to restrict their content. In principle,
establishing constraints on what RPKI C As issue would do this, but
experience suggests otherwise :-). Thus, in order to provide
immediate feedback to a CA that the certs it is issuing are
non-compliant, we would like to have RPs reject the certs (when used
in the intended context). Thus having RPs be very strict in what they
accept is important as well.
Steve
P.S.
Sam noted that there are potentially lots of RPs. In principle,
there are just as many CAs, since every ISP is a CA as well as an RP.
In reality we anticipate that many small ISPs will take advantage of
managed CA services (the RIRs are already offering such services), so
there should be many fewer distinct CAs vs. RPs. Balancing that is
the possibility that a number of ISPs, ones that rely on default
routes, will also not be RPs. So, it's not clear whether we have more
(distinct) CA or RPs. I am hopeful that the RIRs will do a good job
of generating compliant certs in their primary and managed service CA
roles.
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
