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

["Alvaro Retana (aretana)" <[e-mail]>]

Dear authors:

Hi!

It’s been 3 months since this e-mail, which was the last of the thread started from my review.

I am expecting a revised ID – what are the plans to move forward?

Thanks!

Alvaro.



On 3/15/17, 10:24 AM, "sidr on behalf of Tim Bruijnzeels" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:

Hi Chris,

On 13 Mar 2017, at 15:21, Chris Morrow <[e-mail]<mailto:[e-mail]>> wrote:

but, having 2 versions of the validation
algorithm and seeing published data for both OID sets for a single
prefix/publication bundle will be very problematic. There's no
proscribed 'prefer new over old' action here, so a CA must only
publish one version of their data.

Why is this a problem, really?

The OIDs are set on a per certificate basis by the issuing CA. FWIW, in our hosted set up we *will* be able to pro-actively re-issue everything using the new OIDs without user interaction, but there are cases in hosted CA deployments where a hosted CA can automatically re-issue manifests, but ROAs can only be re-issued by explicit user request, one by one.

So we may see hosted CAs with products like this:

1 CRL (validation algorithm does not apply)
1 MFT (new validation, although it won't matter because inherit is used)
1 ROA with new validation (which has been re-issued by the user)
1 ROA with old validation (which has NOT yet been re-issued)

This might seem confusing, but since the OIDs make it very explicit which algorithm the CA intended to use, I really do not see any ambiguity here.

My main concern is that we need to be quite confident that new RP code that understands the new OIDs has been available and is deployed. Because old RPs will reject EVERYTHING once CAs start using the new OIDs.

That is why I would have preferred to not need new OIDs, and just agree on a day that the new algorithm should be preferred. Rob seems adamant that the RFC3779 extension library code does not have access to the context of the full certificate with the RPKI CP OID - so there is no way to have something like:

if (FULL certificate has RPKI CP OID && Date is after 'switch' day) {
  do NEW on RFC3779 extension
} else {
  do OLD on RFC3779 extension
}

The impact of RP software not using the new library on 'switch' day is fairly limited. They would not reject the full repository, but only reject the exceptional cases where certificates ARE over-claiming. And of course the date check can be removed in releases of the library after 'switch' day..

It seems to me that this is a design issue with OpenSSL itself, but be that as it may - it may be unsurmountable. Rob knows this code much better than I do.

Still the consequence of all this is is that we will have to have a mix, and that despite our best efforts to warn everyone to upgrade their RP software I expect that we WILL see a number of operators that suddenly find that their old RP software has reject our full repository when start using the new OIDs.

If it can't be avoided than so be it, but I believe this perspective should be considered as well.



Cheers

Tim