Re: Proposed Agenda items of Tallinn meeting

[Rob Austein <sra@hactrn.net>]

At Fri, 27 Apr 2007 14:35:47 +1000, Robert Loomans wrote:
> 
> > When doing a top-down walk of the distributed repository, rcynic
> > examines at any particular SIA collection for a specific reason:
> > it's there because some cert said "this is where to find stuff I
> > publish".
> 
> All fine to here.
> 
> > rcynic therefore expects anything in that collection to be signed by
> > the private key corresponding to that cert.
> 
> That's where I think you are reaching too far. All the SIA says is "this
> is where to find stuff I publish", it does not say that is *all* you'll
> find there.
> 
> > If it finds anything else, it throws it away.
> 
> That's an implementation decision you've made.

Sorry, "throws it away" is the wrong way of stating what rcynic does.

It doesn't delete it from the unvalidated cache.  It just doesn't copy
it into the validated cache, because it can't (at this time).  It has
to check everything in the collection because it has no way of knowing
what cert signed any given object without reading it.

> > So if you have multiple certs pointing at the same directory,
> > rcynic is going to have to process the contents of that directory
> > multiple times, which is a waste of effort.  Probably not a huge
> > waste of effort except in pathological cases, but remember that
> > every relying party in the system is running rcynic periodically,
> > so multiply that small hit by the number of relying parties, then
> > remember that every relying party is doing this daily (or perhaps
> > hourly).  It adds up.
> 
> I expect it will work out about even.
> 
> Yes, checking a signature is expensive, but reading the AKI of a cert is
> not.

It's more expensive than not having to read it at all.

> You pull the repository down once, sweep for things signed by the
> current key/certificate and move on. At some later stage while
> processing another key/cert you find the same SIA, note that you already
> have updated your cache of it and sweep for that one.
> 
> It's very little different from your current implementation in terms of
> costs.

You're describing what rcynic already does if one insists on
structuring a repository in this silly way.  It's still wastes effort.

> An example:
> 
> APNIC has two certs: <from IANA> (a self-signed cert) and <from RIPE>
> (issued by RIPE).
> 
> Each list rsync://repository.apnic.net/APNIC/ as their SIA, but local
> repository policy places their products in
> rsync://repository.apnic.net/APNIC/02536FF and
> rsync://repository.apnic.net/APNIC/865767A, respectively.

That's not the structure you have now, and as described it appears to
violate the rule that the products can be found in the directory to
which the SIA URI points.  Or are you assuming that relying parties
are going to do a recursive tree walk of everything under the SIA URI?
If the latter, we can stop worrying about small performance hits
because now relying parties have to walk your entire repository
multiple times.

Bottom line: badly designed repositories impose costs on relying
parties.  This is an externality: the entity structuring the
repository doesn't pay the cost, so there's no cost feedback loop to
force reasonable repository design.  So it requires environmental
regulation.