I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a certificate profile for resource certificates in the RPKI. That is, this is a profile of RFC 5280 that describes behavior for CAs and RPs in the RPKI with regard to resource certificates. I have one large issue I'd like to call to the IETF's attention; I think the WG has made an incorrect technical decision and I'd like the IESG both to review whether they believe that decision is correct and to see if that decision has sufficient support in the broader security and routing community. The basic issue surrounds extensibility and extensions. The working group concluded that they want to closely control how resource certificates are used. To me, that seems like a reasonable decision. So, they mandate that only a specific set of options from RFC 5280 are permitted in resource certificates. This is a constraint on the behavior of CAs. A CA could not for example generate a certificate useful both as a resource certificate and for a purpose requiring a specific subjectAlternativeName. Again, doing so seems entirely reasonable. The document also requires that relying parties reject certificates that include unknown extensions. The rationale explained in section 8 is that it is undesirable to have a situation where if an RP implemented more extensions it would reject certificates that a more minimal RP would accept. In other words the profile picks security and minimalism over extensibility. I'm a fan of security, but I believe this decision is misplaced because I believe it provides the IETF insufficient flexibility to correct errors or evolve the RPKI in the future. Remember that CAs are trusted entities typically within an organization or that you have a contract with. Examples of CAs in the RPKI include RIRs, your ISP and potentially a RPKI CA within your organization. We're saying that the possibility that one of these entities would include an unexpected extension and cause some harm is worth giving up the mechanisms we'd likely use to fix problems or deploy additions to the RPKI in a backward compatible manner. How realistic is it that we would end up finding errors?Well let's take a look at changes in information managed by the RPKI over the last few years. The most obvious change I can think of is that we've moved from 16-bit AS numbers to 32-bit AS numbers (or at least we're trying to get there.) Now it turns out that RFC 3779 handles this correctly and that we don't have a problem in this area. It's also likely given that RFC 3779 uses an unconstrained ASN.1 integer that we wouldn't have run across this specific problem. However I argue that if we've had a transition that could potentially have issues that's a good argument that we need to have a strategy for dealing with errors. There is no discussion in draft-ietf-sidr-arch or draft-ietf-sidr-res-certs that I was able to find out explaining how we'll add information to the RPKI if we find we need to do so in a backward compatible manner. I believe that this needs to be considered by the WG. I also recommend that the restrictions in draft-ietf-sidr-res-certs be relaxed. The restrictions on certificate issuance should remain. The restrictions on validation should be relaxed to permit unknown non-critical Extensions. If we decide that for some certificate we do wish to break backward compatibility we can always introduce a critical Extension. Nothing in section 8 of draft-ietf-sidr-res-certs causes me to believe that the extensibility model of the RPKI is significantly differnt than the model already described in RFC 5280. There's also a consistency problem between RFC 5280 and draft-ietf-sidr-res-certs. Section 4.6 and 4.7 describe validFrom and ValidTo elements. Shouldn't these be notBefore and notAfter? Thanks, --Sam _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf