On 3/10/11 11:07 AM, Sam Hartman wrote:
"Paul" == Paul Hoffman<paul.hoffman@xxxxxxxx> 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.
I don't think either of us is missing something, we just disagree about what needs to happen if a fix that changes the semantics of the certs needs to be made to the system as a whole. For changes that don't change the semantics, you change an existing extension or other part of the certificate; for changes that need to change the system's semantics, you change the certificates in a way that relying parties that don't understand the change won't accept the certificate.
Maybe you and I are envisioning different choices being made about those changes. I trust the IETF not to make a change that will cause a lot of relying parties to fail unless the IETF really thinks that is necessary; you may have less faith than I do. (You were on the IESG, so you get to be in the sausage-making more than I have...)
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf