Re: [secdir] Secdir review of draft-ietf-sidr-res-certs

[Paul Hoffman <[e-mail]>]

On 3/10/11 11:07 AM, Sam Hartman wrote:
>>>>>> "Paul" == Paul Hoffman<[e-mail]>  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...)