My take-away from the meeting today is this: - the documents talk about solutions instead of problems.
- perhaps this is because they use terms from a particular design, rather than generic terms - knowing WHO to talk to is a separate problem from HOW to talk to them My comments were that the "how" portion should be relatively simple. I assume a base set of interconnections done via RadSec. These connections are provisioned off-line (contracts, legal, phone calls, etc.) If A has provisioned a RadSec connection to B, then they share a TLS session key. That key can be used to derive additional credentials. e.g. A connects to B, and B to C. If A wants an introduction to C, it asks B how to find C. B responds, and gives A and identity based on the A->B TLS data. A then connects to C, using the credentials derived from B. C can then use it's connection to B in order to validate those credentials. The process can be chained, to allow A to connect to B, then C, then D, etc. Each node can decide whether or not it provides an introduction to another one. This means that B (above) and be a "registrar", with a list of members. It will introduce the members to each other, but not to anyone else. This design is simple, and flat. It means that each system is nearly identical. There are no central registration authorities, except by prior convention. Alan DeKok. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
