On Mon, May 09, 2022 at 02:59:06PM +0200, Claudio Jeker wrote: > On Mon, May 09, 2022 at 12:53:05PM +0200, Theo Buehler wrote: > > Regarding the spec: > > > > * isn't it a bit unfortunate that the ResourceBlock contains an ipAddrBlocks > > member which isn't an IPAddrBlocks as in RFC 3779 but rather an IPList? > > > > The (somewhat) subtle difference is that an IPAddressFamilyItem has > > an iPAddressOrRange where an IPAddressFamily has an IPAddressChoice. > > I assume this was done because inheritance is excluded in this draft. > > Uh, yes, it would be good to be able to use RFC 3779 parser functions on > can limit the usage of inheritance after parsing the objects.
Indeed. After some refactoring we may be able to reduce the low level ASN.1 bashing in rsc.c somewhat, but I fear the RFC 3779 parser functions are only of limited help due to these unfortunate discrepancies. The asID can't be deserialized directly for similar reasons. That's also why I think it's important that the spec is more specific on how the ResourceBlock is encoded. There's ambiguity there (see the quoted bit below). It should at least say that analogous rules as in RFC 3779 apply and preferably be more precise. > I really have the goal to replace all the ASN.1 fumbling around ASid and > IPAddress in rpki-client using not the low-level OpenSSL ASN.1 functions. I need to dust off my diffs. I held them back since I wasn't sure if we wanted to introduce a dependency on LibreSSL 3.5 already. With this diff that's a done deal, so there's no more reason for me to wait. > > * 4.2 requires that the resources in the checklist match the EE cert's > > resources. > > > > In your code there is the implicit assumption that the asID and > > ipAddrBlocks > > are subject to the rules in RFC 3779 (sorted, no overlap, no adjacency), > > specifically the rules in 3.2.3.4 and 2.2.3.6. That isn't really spelled > > out > > in the spec as far as I can see. Also, multiple IPLists per AFI seem a > > priori > > permitted (which is not allowed in RFC 3779 2.2.3.3). > > > > I think something should explicitly be said to tighten the requirements > > on the > > resource lists.
