[GTER] Registro.br RPKI issues?

[Job Snijders]

Dear all,

I noticed on multiple RPKI validators that there was some kind of issue
with the NIC.BR RPKI publication. Seems that PacketVis also noticed the
problem: https://packetvis.com/bgp/event/162b37bf73b78d0cae60830ee73ea634-a707a5b4-c870-4b14-b069-fa5d63a3fc31/b03dfeda75472ffa75eab542a78d20946aafb92f

The first hint of trouble was that validators were expecting SHA256
'GN5NeoONbJ1kTAmWGPzPgkiVNPT4M0k8MfHCPOghhUA=' for file
'36EFA7014D84E8575931BE947541B85295240D78.cer' according to
rpki-repo.registro.br/repo/nicbr_repo/0/EE917EBC7A158783B44BC6ED82217434F28ADEFB.mft
with manifestNumber 929D.

The 'EE917EBC7A158783B44BC6ED82217434F28ADEFB.mft' is an important
Manifest in the critical path towards all ROAs for .BR IP space.
Here is a more detailed decoding of the above mentioned manifest:

	Hash identifier:          wC+VYiXRsY1F8uWzxrFMIdNgkOzK0uAP+WRDdTkicow=
	Subject key identifier:   28:9B:00:5B:48:21:B4:BD:2F:E7:8E:C8:FB:DC:D0:27:46:E8:2C:6E
	Authority key identifier: EE:91:7E:BC:7A:15:87:83:B4:4B:C6:ED:82:21:74:34:F2:8A:DE:FB
	Certificate issuer:       /CN=EE917EBC7A158783B44BC6ED82217434F28ADEFB
	Certificate serial:       2545023AF7B66D64FA9EC3E826A90BDE24AEBA30
	Authority info access:    rsync://repository.lacnic.net/rpki/lacnic/48f083bb-f603-4893-9990-0284c04ceb85/fd25c9bb7e5cac7419fa9193770f64a6edf20c19.cer
	Subject info access:      rsync://rpki-repo.registro.br/repo/nicbr_repo/0/EE917EBC7A158783B44BC6ED82217434F28ADEFB.mft
	Manifest number:          929D
	Signing time:             Mon 15 May 2023 18:10:30 +0000
	Manifest this update:     Mon 15 May 2023 18:05:30 +0000
	Manifest next update:     Tue 16 May 2023 18:29:30 +0000

The above Manifest was distributed as part of an RRDP delta with 127073
in RRDP session 98b30a79-a85f-4f0b-94d0-f969146a0bfd:
https://rpki-repo.registro.br/rrdp/98b30a79-a85f-4f0b-94d0-f969146a0bfd/127073/d5015a7673a46da3/delta.xml

Then a bit later on something very strange happens in RRDP *snapshot* 127087:

$ fgrep rsync://rpki-repo.registro.br/repo/nicbr_repo/0/36EFA7014D84E8575931BE947541B85295240D78.cer ./127087/4215b8949d6653d7/snapshot.xml
  <publish uri="rsync://rpki-repo.registro.br/repo/nicbr_repo/0/36EFA7014D84E8575931BE947541B85295240D78.cer">
  <publish uri="rsync://rpki-repo.registro.br/repo/nicbr_repo/0/36EFA7014D84E8575931BE947541B85295240D78.cer">
  <publish uri="rsync://rpki-repo.registro.br/repo/nicbr_repo/0/36EFA7014D84E8575931BE947541B85295240D78.cer">

Snapshots are supposed to contain only a single copy of each file, yet
this snapshot seems to contain 3 <publish> elements for 1 file.

Calculating the SHA256 hash of the RRDP's Base64 encoded DER of
36EFA7014D84E8575931BE947541B85295240D78.cer shows 3 versions:

SHA256 hash                                  (X.509 NotBefore)                certificate serial
/+rUqKXC/FYQc26Y07okhHe5w2mJTQnTU1WB+KZjT5M= (Mon 15 May 2023 17:54:25 +0000) 0FB038326D0285931149ACC3F4D5E0924B908294
GN5NeoONbJ1kTAmWGPzPgkiVNPT4M0k8MfHCPOghhUA= (Mon 15 May 2023 18:05:16 +0000) 170D8496F58FD1F9976D642F5BF096871D6FD797
IgtLtFuEl1X8JrxncXPkXDfrp0ppiE2vJYKfquUMY1g= (Mon 15 May 2023 18:25:17 +0000) 73F933C7C0A4577D29834E0E775E19C26E662E54

A RRDP snapshot is supposed to be an internally consistent atomic
reflection of the state of the publication point.

RFC 8182 doesn't explicitly spell it out, but I cannot conceive of a
situation in which multiple <publish/> elements for the same 'uri' with
different base64 data is a recoverable situation. Chances are that such
a problematic state confuses some validator implementations.

Any idea what happened?

Kind regards,

Job