Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-07

[Rob Austein <[e-mail]>]

At Mon, 13 Mar 2017 10:55:56 +0100, Tim Bruijnzeels wrote:
> 
> So, to me it seems that having new OIDs makes perfect sense as long
> as there is a choice of two validation algorithms. Then having an
> explicit flag set by CAs tells RPs decide which way to go. Because
> of this I also do not see an immediate need to have a time line for
> all CAs to use the new protocol for all its products. It's all
> explicit.
> 
> Now, if the ambition is to have reconsidered as the only algorithm
> for doing RPKI validation, then I think that the RPKI Certificate
> Policy OID is enough (section 4.8.9 of RCF4587 - which delegates to
> section 1.2 of RFC6484). I realise that RFC3779 section 2.3 has text
> on path validation as well, but I think could can recognise that a
> different algorithm should apply in the context of *RPKI*
> validation.
> 
> If I understand Rob's concerns though he feels that this will cause
> issues, and that therefore the RFC3779 OID cannot be used. Rob, is
> this correct? Why can't RP/OpenSSL code just make the switch based
> on the CA certificate profile?

The problem is that there are one or two things out there besides RPKI
which use X.509, and it would be nice to avoid breaking them.

The OIDs which MUST be changed are the ones labeling the extensions
themselves.  The semantics of X.509v3 critical extensions says,
basically, "If you don't understand the meaning of this extension, you
MUST consider this certificate invalid".  Changing the meaning of the
extensions while retaining the existing OIDs would break this: there
is code out there which thinks it does understand the RFC 3779
extensions, but which would now be incorrect, because the RFC 3779
OIDs would now be used to label things that are not RFC 3779
extensions.

Granted, the probability that some random X.509 CA is going to include
RFC 3779 extensions in certificates for any purpose other than RPKI is
fairly low, but it would be nice to avoid creating a situation in
which users of such certificates got inconsistent results depending on
which version of a stock library they happened to use.  If this were
OpenSSL doing something stupid I wouldn't care so much, but this was
OpenSSL implementing an IETF proposed standard to the best of the
author's ability, and you're talking about retroactively breaking that
for gratuitous reasons.  This is irresponsible.  Don't do it.

I don't understand why we're wasting time debating this (again).  OIDs
are cheap, and (I thought) this was a done deal.  Can we please just
admit that we're talking about new extensions with new semantics which
borrow syntax from the existing extensions, label them accordingly,
and move on?