feature: Handling of ASPA

[ties]

I have added a trust anchor with ASPA objects to my routinator instance. Afterwards I realised that there is no (optional) support for ASPA in routinator at the moment.

Based on that I have two feature requests: [ ] Track unsupported, but upcoming object types in another state than type="other", state="invalid" in metrics (e.g. type="aspa", state="unsupported". As a user this allows me to monitor for invalid objects in my repository, even when routinator does not support them yet. [ ] Add ASPA support for object validation. As a CA developer this would help me ensure that make sure that our implementation is what is expected by routinator. [ ] Draft 8210bis ASPA support in RTR

There is a major gap in that there is no specification for the JSON, but for me the first two steps already have value - because right now I need to remove an alert for invalid objects.

# HELP routinator_ta_objects_total VRPs per trust anchor
# TYPE routinator_ta_objects_total gauge
routinator_ta_objects_total{name="localhost", type="manifest", state="valid"} 34113
routinator_ta_objects_total{name="localhost", type="manifest", state="invalid"} 0
routinator_ta_objects_total{name="localhost", type="manifest", state="premature"} 0
routinator_ta_objects_total{name="localhost", type="manifest", state="stale"} 0
routinator_ta_objects_total{name="localhost", type="manifest", state="missing"} 556
routinator_ta_objects_total{name="localhost", type="crl", state="valid"} 34113
routinator_ta_objects_total{name="localhost", type="crl", state="invalid"} 0
routinator_ta_objects_total{name="localhost", type="crl", state="stale"} 0
routinator_ta_objects_total{name="localhost", type="crl", state="stray"} 0
routinator_ta_objects_total{name="localhost", type="ca_cert", state="valid"} 34668
routinator_ta_objects_total{name="localhost", type="router_cert", state="valid"} 0
routinator_ta_objects_total{name="localhost", type="cert", state="invalid"} 0
routinator_ta_objects_total{name="localhost", type="roa", state="valid"} 23817
routinator_ta_objects_total{name="localhost", type="roa", state="invalid"} 0
routinator_ta_objects_total{name="localhost", type="gbr", state="valid"} 0
routinator_ta_objects_total{name="localhost", type="gbr", state="invalid"} 0
routinator_ta_objects_total{name="localhost", type="other", state="invalid"} 60

[partim]

We have postponed ASPA support primarily because there was still discussions about changes to the ASN.1 specification in SIDROPS. Having Routinator versions with two different ASPA implementations seemed a cause for trouble down the line.

With a new version of the draft now published with the same specification, I assume that those discussions have concluded and we can now indeed implement ASPA in the next version of Routinator.

[ties]

I do understand not implementing ASPA at the moment because there still is a chance of the profile changing.

Handling it differently in metrics would be a good improvement from my point of view though. Right now I probably should remove type="other" from the alerts we have.

routinator_repository_objects_total{instance="host.example.org:9556", job="routinator_pilot", state="invalid", support="office-hours", type="other", uri="https://localcert.ripe.net/rrdp/notification.xml"}

[ties]

For other readers, of course you can filter out this alert, and accept the risk that you miss other unknown files that appear in your repo:

routinator_repository_objects_total{uri="https://my.repo.example.org/notification.xml", state!="valid"} > 0
unless
routinator_repository_objects_total{uri="https://my.repo.example.org/notification.xml", type="other", state="invalid"}

[partim]

One thing we could do is drop "other" altogether and instead add separate metrics for each file extension.

[ties]

That would work, but could cause issues (metric explosion) when someone adds a lot of random extensions on a manifest.

Using other for stuff not on the iana registry feels safe to me

[ties]

Logging about ASPA objects is causing a significant amount of log volume for us. Could you consider adjusting this warning?

[partim]

Looks like the ASPA profile draft made it to working group last call, so I feel reasonably confident to implement initial ASPA support.

[ties]

Looks like the ASPA profile draft made it to working group last call, so I feel reasonably confident to implement initial ASPA support.

That would be perfect!