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

[Tim Bruijnzeels <[e-mail]>]

Hi Rob, all,

> On 13 Mar 2017, at 14:11, Rob Austein <[e-mail]> wrote:
> 
> 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.

I understand that. I meant to say that the switch should be based on the RPKI CA certificate policy qualifier. That is specific to RPKI so, other applications would not break.

Non-RPKI use of RFC3779, would not have this same OID, and therefore would still have the path validation from section 2.3 in RFC3779.


> 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?

The reason why I keep talking about this, is because other people indicated that it could be desirable that validation reconsidered is not a choice (that would need flagging, so OIDs are appropriate) - but should become the default.

In that case it's much simpler to have a switch on the unique RPKI CP OID from section 1.2 of RFC6484. 

The proposed OIDs itself are cheap, and the code changes are simple. The difficulty is that we need a deployment plan:

1= RPs MUST support new OIDs, before
2= CAs MAY use new OIDs

and an open question still is whether there needs to be a later
3= CAs MUST use new OIDs and RPs MUST reject old OIDs

Step 2 has operational impact if operators did not upgrade their RP software. Step 3 has operational impact in case a CA cannot re-issue certain objects.

If we need to end up in a place where 'validation reconsidered' is the default, then these operational impacts can be minimised. It would boil down to deciding a date X by which RPs MUST use reconsidered when they encounter the RPKI CP OID, and a date Y (before X) that these should be available. Operators that don't upgrade before date X could find that they consider certain objects invalid, that would be (partially) valid.

In any case, I know that you know more about how the openssl code works. So if there is a reason why the switch cannot work on the RPKI CP OID without affecting non-RPKI use, or if there is a strong reason for having both algorithms alongside each other, than I am (still) open to the OIDs that I painstakingly added to the document.


Tim