>>>>> "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.
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf