On Sat, Sep 06, 2025 at 05:15:04AM +0000, Job Snijders wrote:
> This diff makes it so that the SubjectKeyIdentifiers of the valid & used Trust
> Anchor certificates are added to the CCR output.
> 
> 	$ cat /var/db/rpki-client/rpki.ccr | der2ascii | tail -n 13 | head -n 9
> 		[4] {
> 		  SEQUENCE {
> 		    OCTET_STRING { `0b9cca90dd0d7a8a37666b19217fe0d84037b7a2` }
> 		    OCTET_STRING { `13d4f24f9a9fcd98db36f930631808c88f3974bc` }
> 		    OCTET_STRING { `e8552b1fd6d1a4f7e404c6d8e5680d1ebc163fc3` }
> 		    OCTET_STRING { `eb680f38f5d6c71bb4b106b8bd06585012da31b6` }
> 		    OCTET_STRING { `fc8a9cb3ed184e17d30eea1e0fa7615ce4b1af47` }
> 		  }
> 		}

The overall approach seems fine given that CCR already has its tentacles
everywhere. It feels like using an RB tree for 1-15 entries where a list
would do is a bit much, but I guess it's ok to match the rest of the CCR
construction, so all 4 main constituents are handled the same way.

Speaking of which. This is weirdly asymmetric with the inlined SEQUENCE
and SIZE constraint:

> @@ -78,11 +74,13 @@
>   *   mfts      [1]     ManifestState OPTIONAL,
>   *   vrps      [2]     ROAPayloadState OPTIONAL,
>   *   vaps      [3]     ASPAPayloadState OPTIONAL,
> + *   taskis    [4]     SEQUENCE (SIZE(1..MAX)) OF SubjectKeyIdentifier OPTIONAL,

Doesn't this want to have a wrapper type such as

	taskis    [4]     TASubjectKeyIdentifiers OPTIONAL
	... }
[...]
     TASubjectKeyIdentifiers ::= SEQUENCE {
       skis               SEQUENCE (SIZE(1..MAX)) OF SubjectKeyIdentifier
     }

This shouldn't change the encoding but make both the code and the ASN.1
look a bit more uniform.