[Sidrops] Re: Call for WG Adoption of draft-snij-sidrops-constraining-rpki-trust-anchors

[Job Snijders <[e-mail]>]

Hi Tim, WG,

On Tue, Jan 20, 2026 at 10:52:53AM +0100, Tim Bruijnzeels wrote:
> I agree that this needs discussing and I support adopting it for that.
> 
> I understand the need. I have some issues with trust put into the
> inputs of the constraints. 

You raise a good point - perhaps the draft at hand should adapt some
language from the SLURM specification (RFC8416, section 6), along the
lines of: "These mechanisms are only applied locally; they do not
influence how other network operators interpret RPKI data." and
additionally, "The mechanism to update trust anchor constraints to
guarantee authenticity and integrity is out of the scope of this
document."

> The RIRs have a responsibility here. As presented at the last IETF the
> RIRs are committed to give better, signed, inputs with regards to
> resources managed under each RIR. This is still in its early stages.
> An updated document incorporating feedback is in the making. It may
> well turn out that that effort can serve as validatable input to the
> approach outlined in this document.  It may also be that ultimately
> that effort removes the need for this, but only time and discussion
> will tell. So, in the meantime I think it's good to discuss this
> approach.

Indeed. My hope is that draft-snij-sidrops-constraining-rpki-trust-anchors
can provide a building block for the NRO draft about constraints (and
other initiatives). Whether RIRs end up proposing to publish
JSON-formatted-GPG-signed listings, or cross-signed-CMS-messages, or
something else entirely, it would be nice if those concepts can
(programatically) be transformed into the 'policy structure' specified
in this draft (and in turn, this 'structure' was consciously designed to
align with RFC 3779 containment checks).

I'd like to:

1) make the concept of trust anchor-specific constraints tangible by
   publishing a specification
2) formalize a structure how to express constraints (note: this is not
   encoding - whether it is plain ASCII or JSON or XML is irrelevant)
3) specify an attachment point in the validation process for these
   expressions, in order to achieve interoperability

In short - I consider where the "constraints content" actually
originates out-of-scope for this specification, there definitely is more
work to be done in the space of automating distribution & verification
of constraints content.

Another use case for TA constraints would be to facilitate
narrow-purpose trust anchors, for example, a trust anchor specific to
the DNS root zone servers. It doesn't seem entirely unreasonable for the
Internet community to wish for more redundancy in terms of route origin
authorizations for certain routing attestations (redundancy through
multiple Trust Anchors), and at the same time the Internet community may
desire to restrict such a DNS-root-specific trust anchor to a very
limited set of resources.

Kind regards,

Job