clearly, I am not Geoff.
But in any case, I don't understand why you only analyze the costs of
this test in the context of complete chain-validation tests,
validating signed objects.
Why can you not test signed objects and the EE certificates against a
*pre-validated* information structure for the hierarchy, and so only
have to test the EE cert, and object validation at one level, instead
of completely to the root?
what am I mis-understanding about end-sign validation?
I don't believe at this time that any multi-sign outcomes would exist
except at the edge: end-entity objects.
so I don't see why an entire tree-validation is needed, if you have a
pre-validated repository of known good certificate chains. The end-
entity certs, the signed objects, surely the validation is far simpler
than you imply?
On 07/10/2008, at 12:23 PM, Rob Austein wrote:
I look forward to reading your code, Geoff.
The process of retrieving and checking an RPKI tree is already a
fairly complex recursive tree walk with many fiddly checks that have
to be done in the right order to avoid various attack scenarios. The
last thing this traversal algorithm needs is a gratuitous requirement
that at each ROA it finds it must be prepared to go haring off after
an arbitrarily large number of new certificate chains in different
parts of the tree on a pointless quest to solve a non-problem.
Do you have ANY evidence whatsoever for compelling real world cases?
post rundown, the likelihood that resources do not compress simply to
single certificate chains seems to me a likely scenario. ie, people
will be holding large sets of dis-aggregated resources, and need to
assert route validation over them effectively.
if they do this as a set of disjoint end objects you move validation
costs to a simpler process per object, that then has to be
(re)combined to make the real information you need.
If we can find a way to make multi-sign work, there could be
significantly less objects in play, in the system as a whole.
Rob, I don't mean to be dis-respectful, but I find the vehemance "this
can't work: its too expensive" over-stated. I don't buy it. I think
you're at risk of entrenching a view that is as equally shakey as my
belief multi-sign may turn out to be needed.
Don't talk theory. Show me a real case where this would matter.
Its hard for anyone to do that in a world where no routing security
exists. But I am tempted to observe that in the WG discussions we
seemed to be confident the *intended* security model in respect of IRR
demanded more than one participant sign information to validate the
relationship between AS in routing, and prefix being routed. (I do not
mean ROA here, I am talking about things beyond the ROA. So I have
moved the agenda sideways)
I know that others believe this is irrelevant, but I still see it
documented in the RFCs and in the actual code which implements checks
on who authorizes updates in WHOIS..
cheers
-George
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
