Summary

  • LACNIC’s RPKI Trust Anchors page displays /rpki/lacnic.tal and /rpki/lacnic-as0.tal on its public host, but its stored links point to two /innovaportal/file/4983/1/ targets.
  • On 30 August, both displayed addresses returned HTTP 200, text/html, 7,014 bytes and the same SHA-256. The two link targets returned distinct 502- and 518-byte TAL text files.
  • The ordinary and AS0 TALs named different trust-anchor certificates, and both certificate URLs were retrievable. The evidence therefore shows a label/target distribution mismatch, not a broken repository, invalid key or validator failure.
  • A TAL publication receipt should test what the page prints and what it links, then bind media type, TAL grammar, artifact hash, named certificate and correction lineage to one public edition.

The same instruction has two execution paths

LACNIC’s public page is titled RPKI Trust Anchors - TAL. It explains the role of the ordinary LACNIC TAL, then presents a separate TAL for the AS0 policy. Near the end, it says that the files can be downloaded from two links.

The visible text is unambiguous:

  • /rpki/lacnic.tal on LACNIC’s public host
  • /rpki/lacnic-as0.tal on LACNIC’s public host

The underlying CMS record for content 4984 preserves a different action. The first label has an href of /innovaportal/file/4983/1/lacnic.tal; the second points to /innovaportal/file/4983/1/lacnic-as0.tal. LACNIC’s current frontend environment declares innova.lacnic.net/innovaportal as the Innovaportal base.

That produces a subtle but reproducible fork. Follow the link and the browser resolves a legacy content target. Copy the words shown on screen and the request goes to the new site’s /rpki/ route. To a human, those actions look interchangeable. To a machine, they are different URLs with different response grammars.

Two successful HTTP responses were not two TALs

At 04:48 UTC on 30 August 2026, cache-bypassed requests were made to both visible addresses. The ordinary visible address returned HTTP 200 and text/html. The AS0 visible address did the same.

Each response contained 7,014 bytes. Each had SHA-256 7a17eab5484db68fe84e396d8fb7b6326cfff37d10c7467c0296655a899dc416. Each carried the same last-modified time, 28 August at 13:20:15 GMT. The bytes were LACNIC’s HTML application shell, not two TAL documents.

The common timestamp is useful response metadata; it is not a start time for the mismatch. The capture does not establish how long the two paths have behaved this way, how caches elsewhere answered, or whether anyone copied the labels. Nor does a 200 response make the requested object valid. HTTP success says the server returned a representation. It does not say that the representation satisfies TAL grammar.

The distinction is material because filenames ending in .tal invite unattended retrieval. A health check that records only status code and latency would mark both addresses healthy. A check that expects an ordered set of certificate URIs followed by public-key material would reject both HTML responses immediately.

The click targets preserve two real artifacts

The other half of the evidence prevents the finding from becoming an outage claim. The actual ordinary Innovaportal target returned HTTP 200, application/aux, 502 bytes and SHA-256 d44bb9394ab009c8b53e5efebf2a1c9450bab61a27efe00de5a3e4587a3a2f6a. Its first two lines name the HTTPS and rsync locations of LACNIC’s ordinary trust-anchor certificate.

The AS0 target returned HTTP 200, application/aux, 518 bytes and SHA-256 671a1b78c51ac023e7500212f0039699e94f4143eab05260284eccc3858e9eff. It names a different certificate under the AS0 repository path and carries different public-key material.

Both named HTTPS certificates were then fetched. The ordinary certificate returned 1,166 bytes; the AS0 certificate returned 1,160. They were distinct binary objects.

This sequence establishes a distribution-layer asymmetry. It does not establish that either certificate is wrongly issued, that either key is wrong, that a relying party rejected anything, or that one route changed. The page itself also says most validation tools already include the necessary TAL files. No downstream impact was found.

A TAL is more than a suffix

RFC 8630 gives a TAL a simple but consequential structure: one or more ordered certificate URIs, a blank line, and the Base64-encoded SubjectPublicKeyInfo of the trust anchor. A relying party retrieves a certificate, verifies that it is a current self-signed RPKI CA certificate and checks that its public key matches the TAL.

That sequence separates at least five states: the URL resolved; an HTTP representation arrived; the representation parsed as a TAL; a named certificate could be retrieved; and the certificate’s key matched. None can be replaced by the statement “the request returned 200.”

The current LACNIC page makes a sixth state visible: the address printed for the reader and the address activated by the link may differ. HTML permits that difference, and redirects or download services routinely use it legitimately. The problem is not that the href uses a legacy store. The problem is that the page tells an operator that one URL is the file while relying on another URL to deliver it.

For an ordinary web brochure, that may be cosmetic. For bootstrap trust material, labels are operational data. They are copied into scripts, tickets, runbooks, configuration reviews and incident notes. A URL that works only when clicked is not the same published object as a URL that works when copied.

The strongest benign reading

The evidence favours a restrained explanation. LACNIC’s new frontend serves the same application shell for the two /rpki/*.tal paths, while the CMS retains functioning legacy file targets. The ordinary and AS0 TAL bytes remain distinct, and the certificates named inside them remain available. That looks like a route-alias or content-migration mismatch, not destruction of the trust material.

It may be fixed by making the visible labels equal the resolved targets, or by configuring the two visible paths to serve or redirect to their respective TALs. LACNIC can choose either architecture. The public requirement is only that click, copy and automated retrieval converge on the same declared artifact.

Silently changing the labels would repair future use but leave no account of what an earlier script received. A short correction or machine-readable receipt would preserve the observation without inflating it into an incident. It could say which page edition changed, which aliases are canonical, and when the two retrieval paths began returning the same TAL grammar.

One receipt for label, action and object

A compact publication receipt can make this class of drift difficult to ship. For each download element, it would record the page and content version, the visible label, the raw href, the fully resolved target, the expected media type and the artifact role—ordinary or AS0.

A canary would then fetch both the visible URL and resolved target. It would store status, content type, byte length and a strong digest; parse the expected TAL grammar; extract the ordered certificate URIs and public key; retrieve the preferred certificate; and record whether the certificate is current, self-signed and key-matched. A mismatch would block a new page edition or raise a narrow distribution alert, not pronounce the RPKI invalid.

Corrections need memory. The receipt should retain the preceding page hash, the preceding URL pair, detection time, reason category, replacement state and any intentionally supported aliases. Consumers can then distinguish an old captured response from a current canonical object without pretending the old observation never existed.

The policy burden is modest. LACNIC already publishes the page, the TAL contents and the certificates. The missing join is between what the page says, what the browser does and what the server returns.

Both clicks worked in the capture. Both printed addresses also returned 200. Only one path in each pair returned the object the label promised. That is exactly why HTTP availability and publication identity need separate receipts.

Sources