On Jul 24, 2014, at 10:37 AM, Russ Housley <[email protected]> wrote:
> The Introduction says: > > This document reviews the certificate validation procedure specified > in RFC6487 and highlights aspects of potentially acute operational > fragility in the management of certificates in the RPKI in response > to the movement of resources across registries, and the associated > actions of Certification Authorities to maintain continuity of > validation of certification of resources during this movement. > > When this working group was developing the RPKI specifications, the RIRs > essentially asked us not to specify how the "movement of resources across > registries" would take place. I for one accepted this at the time because it > looked like an issue between RIRs. This document is calling for a > make-before-break certificate issuance capability. Maybe there are other > motives too. There are two cases. One is the transfer case and the need to revise certs upward on the giving side and downward on the receiving side. That's the make-before-break part. The other is the problem of removing resources from certs - one CA reissues a "smaller" cert, and reissuing has to take place down the chain for the resources that are retained, in order to keep the encompassing rules valid. The pain is felt in the CA's descendants until other CAs get their re-issuance done. > > 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. > > As I understand the situation, the existing specification works, but it > imposes some restrictions on the order that certificates that must be issued > and distributed. There's a order problem in the transfer case and a timing problem in the reduction case. > > I really want to see the RPKI deployed, and deployed really soon. I worry > greatly that this proposed change will result in a very significant delay. > > To change my mind, I'd need to see a serious impact on operators by the > current specification. Can it be demonstrated with the various > implementations that we already have in front of us? I think the case they point to can occur - but it is a matter of timing. It will be a problem until the CA who needs to reissue does the reissue, and then the world picks that up. > > Russ > > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
