From: Job Snijders <job@openbsd.org>
Subject: Re: rpki-client: encode Trust Anchor SubjectKeyIdentifiers into CCR output
To: Theo Buehler <tb@theobuehler.org>
Cc: tech@openbsd.org
Date: Sat, 6 Sep 2025 05:56:56 +0000

On Sat, Sep 06, 2025 at 07:48:17AM +0200, Theo Buehler wrote:
> 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.

Might seem overkill, OTOH, I intend for taskis field values to be sorted
in ascending order, which is trivial using RB_*.

> 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.

I think it changes the encoding? Doesn't your approach introduce an
additional SEQUENCE { } enveloppe? We can do it that way but it seemed a
bit like superfluous nesting to me.

Kind regards,

Job