Re: [Sidrops] 6486bis: Failed Fetches

[Tim Bruijnzeels <[e-mail]>]

Hi,

On 7 Sep 2020, at 13:17, Tim Bruijnzeels <[e-mail]> wrote:
> 
>>> 
>>> If we do go down this road then I think that we should also look at the manifest object itself, and let it convey which object (types) are critical (and while we are at it, we can specify types instead of using filename extensions). That way future object types could introduced more easily perhaps - this obviously needs more discussion but it could even allow for semantics like: 1) new object please test, don't use, 2) new objects, use if you can, 3) new objects, critical - fail if you don't understand.
>> 
>> One could combine the new SIA URI and a revised manifest, in which the manifest contains the per-object flag, rather than redefining the basic object format to accommodate the flag. That would reduce the number of RFCs that need to change. Good idea.
> 
> Upon reflection I realised that even the introduction of an SIA in the issuing CA certificate will lead to issues. RPs would reject the CA certificate, and as a result the whole PP of the parent CA. This means that the SIA cannot be deployed without leaving a significant number of RP installations behind. E.g. if I run a delegated CA under an RIR which wants to adopt ASPA, and I get a new CA certificate with the additional SIA from my parent, then 1000s (RIPE NCC >12k) other CAs will also be rejected.


I have done some testing on this.

Section 4.8.8.1 of RFC 6487 seems to say that additional SIA OIDs for CA certificates can be expected and can be ignored. And indeed it seems that all current RP software will accept (and ignore) additional SIAs.

At least that's the result from adding an extra SIA in a Krill branch and running the end to end tests using the following validator versions:

fortvalidator 1.4.0
OctoRPKI v1.1.4 (2019-08-06T16:51:07-0700)
rcynic version believed to be buildbot-1.0.1544679302
routinator 0.7.1
rpkiclient 6.7p1
rpkivalidator3 3.1-2020.08.06.14.39

I am still not very happy about the overhead that this approach implies:

Additional publication points which need to be maintained, which may be out of sync. What if MFT A has a certain ROA and MFT B doesn't? This can lead to serious operational impact if an announcement would be valid under one, but not the other.

It would also require much more fundamental code changes for producing CAs - one cannot just support a new object type. One has to support an additional publication model. Parent CAs have to be willing to include the new SIAs as well affecting the ability to deploy for delegated CAs.

But, at least it seems that it can be introduced without breaking things immediately for existing deployed validators.

Tim