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

[Rob Austein <[e-mail]>]

At Mon, 13 Mar 2017 15:25:13 +0100, Tim Bruijnzeels wrote:
> 
> 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.

The problem is that you're talking about applications, while I'm
talking about libraries.

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

You are making assumptions about how the library code works.  As it
happens, those assumptions are incorrect for the OpenSSL case.

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

I disagree.

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

Old-policy-OID requires old-extension-OIDs.  New-policy-OID requires
new-extension-OIDs.  Simple, unambiguous, no magic required.

> If we need to end up in a place where 'validation reconsidered' is
> the default, then these operational impacts can be minimised.

Hiding the change does not solve the problem, it just makes it harder
to debug when it breaks.

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

That's what I've been trying to tell you.

At least in OpenSSL's case, certificate extensions are processed down
in the guts of the library.  Certificates with critical extensions
which do not pass validation are rejected by the library, regardless
of any policy setting.  Policy OID constraints require cooperation by
the application.

So while your scheme sort of works for RPKI-aware applications which
enforce an RPKI policy OID, it does not work for non-RPKI applications
which encounter RFC 3997 extensions: you will get the same certificate
looking valid to one validation engine and invalid to another, because
the same OIDs trigger different processing in the two engines.

Don't go there.  Please, don't go there.  This is dangerous.

Please just keep the new separate extension OIDs and stop trying to
pretend that we can sweep the flag days for an incompatible change
under the rug.  We can't.  Accept that and move on.