On 11/11/2010 12:44 PM, Sandra Murphy wrote:
The input to our testbed is a specification file that defines (1) the
resources of the trust anchor, (2) a number of CA types and the
*amount* of resources assigned to each type, and (3) the parent-child
relationships + branching factors.
CA "types"??
Sorry, unfortunate terminology. Internally we call them "CA blueprints"
or "CA factories". In the RPKI, obviously nothing distinguishes an RIR
CA cert from anyone else's CA cert. However, for hierarchy generation
purposes, there are significant differences between:
1. RIRs (they all have very different distributions of resources)
2. Large ISPs (a small number of these with a large amount of resources)
3. Small ISPs (a large number of these with few resources)
We model this by allowing the definition of an arbitrary number of
blueprints for CAs and ROAs. These blueprints do not contain specific
resources ("110.35/16") but rather amounts of resources ("/16").
Blueprints also contain a list of pointers to other blueprints (for
future children).
To instantiate a child CA, start from an already instantiated parent,
suballocate the appropriate amount of resources as defined by the
child's blueprint, and create/sign the appropriate child certificate.
Then, take the child's "future children" blueprints (i.e. for
grandchildren) and append to a todo list. Process the todo list using
the same procedure.
Clear as mud?
-Andrew
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
