WG char hat off On 07/10/2008, at 1:23 PM, Rob Austein wrote:
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.
What I understand from your posting is that this makes ROA validation horrendously complex. An algorithm that attempts to validate everything at a repository publication point before moving on to the next repository publication point will have problems with any form of multi-signed object. On the other hand an algorithm that validates certificates (and CRLs) in a first pass and signed objects in a second pass would not encounter the same problems, as the collection of ee certificates required to validate the multisigned object would be already validated in the first pass.
So is what I'm hearing here from your posting: "I implemented it one way and if the draft is changed then my code will need to change, and I really don't want to do that, therefore I'm opposed to any change in the draft"?
But in that case there is a problem here for this type of algorithm in validating any form of multi-signed object, not just ROAs.
What about proxy aggregation in BGP? How can one validate any element that is constructed from a set of components other than by multo- signed objects? How are those multi-signed objects to be validated?
What about if one wanted to implement the RPSS security framework where the analogous security mechanism to the Route Object is that the AS holder and the prefix holder sign the route object? How are those multi-signed objects to be validated?
What about an AS adjacency attestation that is signed by both AS's? How are those multi-signed objects to be validated?
What about a generic form of AS Path validation where the credentials are progressively signed by the sequence of AS's? How are those multi- signed objects to be validated?
Is what you are really voicing here an opposition to any form of multiple RPKI signatures being placed on any signed object within this framework? If that's the case I _personally_ see that as a very short- sighted limitation, a I for one see multiple signatures in the RPKI as being a valuable attribute in the long run in terms of the flexibility of the PKI to suit a broad as possible number of potential areas of application including BGP itself.
Geoff _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
