Re: [sidr] RPKI validator testing summary

[Tim Bruijnzeels <[e-mail]>]

On Dec 6, 2011, at 5:20 PM, Andrew Chi wrote:

> On 12/3/2011 12:47 AM, Randy Bush wrote:
>>>> so are you saying bottom up is just a no-go?
>>> I believe I am, in that by following the AIA pointers you may be lead
>>> to places that may not match your chosen trust anchors.
>>> This is particularly the case for those who want to set up local TAs
>>> as per some draft or another.
>> 
>> as at least one validation implementation, bbn, is bottom up, and was
>> done by clueful folk next to some draft or another, i suspect we need to
>> document this in a warning some place.
>> 
>> randy
> 
> BBN's validator does have both top-down and bottom-up capability (currently, both run by default).  This was intended to handle any future use cases where a child is somehow obtained before its parent. As it turns out, all use cases that we've tested so far only require top-down.  And the bottom-up capability only leads us to old, abandoned data.
> 
> Note that Local TA is unaffected; that "tree" is shallow, locally managed, and processed in a manner that doesn't require AIAs.
> 
> As others have mentioned, bottom-up introduces complexity with (1) stray AIA pointers, and (2) multiple issuers if AIAs must be strict.  We have a countermeasure for 1, and currently we aren't strict about 2.  But if no bottom-up use cases ever come up, we will default the BBN validator to run top-down only.



Our command line validator supports ad-hoc bottom-up validation at this time, meaning:
- it will follow the AIA pointers up to a self-signed cert, the FIRST rsync pointer is used.
- insist that the self-signed cert matches (one of) your chosen trust anchor(s)
- perform a top-down validation for this chain only

But it needs some work. We are thinking of this:
- from the next release of our validator we will start supporting doing top-down validation, and most importantly re-validation, as a background service
- when asked to do bottom-up validation (in a future release):
	- we check if we have seen an exact binary match for the object content from a previous top-down run
	- if not we follow pointers up and fetch missing certificates until we find a pointer to something in our cache
	- I would define a match as a CA certificate with the correct subject (matching issuer) and public key, publication point may differ
	- The big assumption here is that people use unique key pairs, but I should hope that's a safe bet


I think bottom-up validation has a use for manual validation of objects that disappeared from the rpki (but may still be valid). And possibly in future for other (non-sidr even) object types that an address holder may not necessarily want to publish in the global rpki, but send directly to any RP for validation instead. In that case, assuming a CMS is used with an embedded EE with an AIA pointer to the normal CA cert for this holder, it's just one hop up into the 'known territory'.


Tim