>>>>> "Paul" == Paul Hoffman <paul.hoff...@vpnc.org> writes:
Paul> On 3/10/11 9:37 AM, Sam Hartman wrote: >> 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. Paul> This statement is too narrow, and it causes your analysis to Paul> come to a too narrow conclusion. The profile picks security Paul> and minimalism over extensibility *of this profile only*. If a Paul> flaw is later found that requires an extension, that extension Paul> will be written up in a standards-track document that will Paul> obsolete this profile. An implementation that conforms to that Paul> new profile will use the extension. Thus, errors can be Paul> corrected with new profiles, and the RPKI will have multiple Paul> profiles running on it, just as the Internet has multiple Paul> versions of some protocols running on it. Paul, that's a great argument for why it's OK to prohibit issuing certificates with new extensions in this profile. We absolutely can change CA behavior with a new profile. However, I don't think your argument makes sense for RP behavior. Under this profile, if an RP is presented with a certificate issued under a new RPKI profile, it will reject that certificate. So, it sounds a lot like you'd need to upgrade all the RPs that might need to rely on a particular resource certificate before you could issue that certificate under a new profile. Given that resource certificates can be used by a lot of RPs--for example anyone who needs to verify origins of a route presumably--that's a long wait. I think that's unjustified. One of us is clearly missing something. I would be happy if it's me. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf